TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
ท่ามกลางกระแสของธุรกิจในแบบ Data-Driven Business ที่ทุกกลยุทธ์และการตัดสินใจล้วนต้องขับเคลื่อนด้วยข้อมูล ระบบฐานข้อมูล (DBMS) นั้นจึงกลายเป็นหัวใจสำคัญของธุรกิจองค์กรในทุกขนาดและทุกอุตสาหกรรม
ด้วยเหตุนี้ การออกแบบและปรับปรุงระบบ Database Infrastructure จึงกลายเป็นอีกภารกิจสำคัญของผู้บริหารระบบ IT เพื่อให้ระบบฐานข้อมูลขององค์กรมีเสถียรภาพ สามารถให้บริการกับธุรกิจได้อย่างมีประสิทธิภาพ สามารถรองรับการเพิ่มขยายระบบและความสามารถใหม่ๆ ที่ตอบโจทย์ในอนาคตได้ รวมถึงยังคุ้มค่าต่อการลงทุนในระยะยาว
ในบทความนี้ ทีมงาน TN Incorporation (TN) จะมาแบ่งปันขั้นตอนที่ธุรกิจจะต้องเตรียมตัวก่อนการ Migrate Enterprise Database ไปยัง PostgreSQL ระบบ Open Source Database Software ที่ได้รับความนิยมเป็นอย่างมากในปัจจุบัน ทั้งในการใช้งานแบบ On-Premises และ Cloud เพื่อให้ธุรกิจมีทางเลือกในการใช้งานระบบ Database สำหรับธุรกิจได้โดยไม่ต้องกังวลถึงค่าใช้จ่ายด้าน License ในการใช้งานที่เคยมีราคาสูงอย่างการใช้ Commercial Database ในอดีตอีกต่อไป ดังนี้
3 ขั้นตอนการประเมินและกำหนดความต้องการด้าน Service Level Agreement (SLA) ของระบบ Database
ในการย้ายระบบ Database ใหม่ ก็ถือเป็นอีกโอกาสสำคัญที่ธุรกิจจะได้กำหนด Service Level Agreement ใหม่ให้กับระบบ เพื่อเพิ่มความมั่นคงทนทานในแง่มุมต่างๆ ให้สูงยิ่งขึ้นได้
โดยข้อกำหนดทางด้าน Service Level Agreement ที่สำคัญที่ต้องทำการตรวจสอบ ปรับปรุง และตกลงให้เรียบร้อยก่อนทำการ Migrate ระบบ Database นั้นได้แก่
1. การกำหนด System Availability
ขั้นตอนแรกคือการสำรวจว่าระบบ Database ที่ใช้งานอยู่เดิมนั้นมีการใช้งานและมีระดับของ SLA อยู่ที่ระดับใด เช่น สำหรับระบบที่มีผู้ใช้งานใช้เป็นหลักนั้นก็อาจมี ช่วงการใช้งานเพียง 8 ชั่วโมงใน 5 วันทำการ (8×5) สำหรับเฉพาะช่วงเวลาทำงานเท่านั้น แต่สำหรับระบบที่มีความสำคัญสูงและต้องถูกเข้าถึงใช้งานอยู่ตลอดเวลา ก็อาจมีช่วงการใช้งานตลอด 24 ชั่วโมง 7 วันในแต่ละสัปดาห์ (24×7) เป็นต้น
ถัดมาก็คือการกำหนด Availability Target สำหรับแต่ละระบบเพื่อระบุถึงความพร้อมในการให้ใช้งานแต่ระบบในรูปแบบของ % ของ Uptime ในระบบต่อปี (% Availability) เช่น 99% หรือ 99.9% เป็นต้น
การกำหนด Availability ที่ถูกต้องจะทำให้สามารถออกแบบระบบ Database ได้ตรงกับ Business Requirement ภายใต้งบประมาณที่เหมาะสม
2. การกำหนด Performance Target
Performance Target เป็นการประเมินว่า Database จะต้องมีความสามารถในการรองรับ Workload ได้ในประสิทธิภาพระดับใด โดยการประเมิน Performance ของ Database จะมี SLA ที่สำคัญได้แก่
- จำนวน Concurrent Connection สูงสุดสำหรับการเชื่อมต่อ Database
- ปริมาณ Query Throughput เช่น Select, Insert, Update, Delete ว่าจะต้องรองรับได้สูงสุดกี่ Query per Second
- Query Response Time จะต้องใช้เวลาประมวลผลไม่เกินเท่าใด เช่น Average 10 millisecond เป็นต้น
การกำหนด Performance Target ของ Database จะทำให้สามารถออกแบบ Database รวมถึงการเลือกใช้ Platform Infrastructure ได้เหมาะสมต่อ Workload Characteristic ที่จะเกิดขึ้นจริงในการใช้งาน
สำหรับในประเทศไทย โครงการย้ายระบบ Database นั้นมักมีประเด็นเรื่องของการอัปเกรดและเพิ่มขยายประสิทธิภาพของระบบควบคู่เข้ามาด้วย ดังนั้นในหลายโครงการจึงมักพบเห็นการเพิ่ม Performance Target หรือการออกแบบแนวทางในการเพิ่มขยายระบบในภายหลังเพิ่มเติมเผื่อเอาไว้ด้วย
3. การกำหนด Security Baseline
Enterprise Database เป็นระบบที่ต้องเก็บข้อมูลที่มีความสำคัญสำหรับองค์กร ดังนั้นการกำหนดความต้องการทางด้าน Security จึงเป็นเรื่องสำคัญอย่างยิ่ง
ขั้นแรกคือการจัดกลุ่มประเภทของข้อมูลที่เก็บภายใน Database ตาม Confidentiality Level เช่น ระบบหนึ่งอาจจะมีการจัดเก็บเพียงข้อมูลทั่วไป ในขณะที่อีกระบบนั้นอาจมีการจัดเก็บ Sensitive Data แตกต่างกันออกไป
การแบ่งกลุ่มนี้จะทำให้สามารถออกแบบ Database ตามระดับของ Data Security ได้ เช่น การเลือกใช้เทคโนโลยี Data Encryption ประเภทต่างๆ ให้เหมาะสม หรือการกำหนด Access Control Matrix สำหรับผู้ดูแลระบบและ Account ของระบบต่างๆ หรือการกำหนดค่าในการทำ Security Auditing เป็นต้น
โดยทั่วไปแล้วการวางแผนสำหรับการย้ายระบบ Database ในประเทศไทยในระยะหลังนี้ มักจะต้องมีการปรับปรุง Security Baseline ค่อนข้างมากเพื่อให้สอดคล้องต่อการนำไปใช้งาน เช่น การเสริมความมั่นคงปลอดภัยสำหรับการใช้งานบน Cloud, การตอบรับต่อข้อกฎหมายด้านความมั่นคงปลอดภัยและความเป็นส่วนตัวของข้อมูล ไปจนถึงการรองรับ Compliance ต่างๆ ภายในองค์กรที่ถูกกำหนดเพิ่มเติมขึ้นมา
5 ขั้นตอนการเตรียมความพร้อมระบบ Database Infrastructure
เมื่อเราเห็นภาพของความต้องการทั้งของระบบ Database ที่เคยใช้งานอยู่เดิม และโจทย์ในระบบ Database ใหม่ที่ต้องการบรรลุเป้าหมายแล้ว ลำดับถัดไปนั้นก็คือการออกแบบ Database Infrastructure ใหม่ให้ตอบโจทย์เหล่านั้นได้อย่างครอบคลุม
สำหรับประเด็นสำคัญในการเตรียม Platform Infrastructure ให้กับระบบสำหรับระบบฐานข้อมูล ได้แก่
1. การเลือก System Infrastructure ที่เหมาะสมกับความการใช้งานจริง
ในปัจจุบันเทคโนโลยีของ System Infrastructure ที่สามารถเลือกใช้งานสำหรับระบบ Database มีหลายหลายรูปแบบ เช่น การใช้งาน Server แบบ On-premise, การใช้งาน Public หรือ Private Cloud, หรือการใช้ Database-as-a-Service (DBaaS) เป็นต้น Infrastructure ในแต่ละรูปแบบก็จะมีจุดเด่นและข้อจำกัดที่แตกต่างกัน
ด้วยเหตุนี้ การเลือก Infrastructure สำหรับระบบ Database จึงต้องเข้าใจปัจจัยความแตกต่างเหล่านี้ เช่น การใช้งาน Public Cloud มีจุดเด่นสำหรับการเพิ่มขยาย Capacity แต่จะมีข้อจำกัดหรือมีค่าใช้จ่ายในการรับส่งข้อมูลเข้าออก รวมถึงการพิจารณาถึงข้อกำหนดนโยบายของการเก็บข้อมูลในองค์กร การใช้งาน DBaaS ช่วยลดภาระในการบริหารจัดการ Database สำหรับผู้ดูแลระบบ แต่อาจจะไม่เหมาะสำหรับ Database ที่ต้องการประสิทธิภาพสูง ที่ต้องปรับแต่ง Database Parameter ให้สามารถรองรับ Workload ตามที่ต้องการได้ เป็นต้น
2. การเตรียมระบบ Database Backup & Recovery
ผู้ดูแลระบบฐานข้อมูล ล้วนเห็นความสำคัญของการสำรองและการกู้คืนระบบ แต่การออกแบบ Backup and Recovery Strategy ที่สอดคล้องกับ Business Requirement เป็นเรื่องที่ท้าทายและต้องมีการออกแบบที่เหมาะสม
การกำหนด Backup Strategy มีองค์ประกอบที่ต้องพิจารณาได้แก่
- ความครบถ้วนในการสำรองข้อมูล เช่น Database file, Transaction log ที่จำเป็นในการ recover ระบบ รวมถึงระยะเวลาของการเก็บข้อมูล backup ย้อนหลัง (Backup retention) ที่สอดคล้องกับ requirement
- การเลือกใช้วิธีการ Backup ที่ไม่กระทบกับการทำงานของระบบ Application เช่น หาก application มีช่วงเวลาที่อยู่นอก service hour การ backup จะต้องสามารถทำได้โดยมี backup throughput เพียงพอเพื่อให้เสร็จภายใน backup window หรือหากระบบงาน application เป็นแบบ 24×7 การ backup จะต้องทำในลักษณะ online หรือ snapshot โดย application จะยังคงทำงานได้ต่อเนื่องและมี response time เป็นปกติ
นอกเหนือจากการกำหนด Backup Strategy แล้ว การกำหนด Recovery Strategy ก็เป็นอีกส่วนที่มีความสำคัญไม่น้อยไปกว่ากัน โดยประเด็นที่ควรต้องพิจารณานั้นได้แก่
- การกำหนด Target SLA ที่ชัดเจน ได้แก่ Recovery Time Objective (RTO) คือ กรอบเวลาที่ใช้ในการกู้ระบบกลับ เช่น ภายในไม่เกิน 3 ช.ม. และต้องมี Recovery Point Objective (RPO) คือ ระยะเวลาที่สามารถกู้ข้อมูลย้อนหลังได้ เช่น รายการข้อมูลสุดท้าย 30 นาทีก่อนระบบจะมีปัญหา หรือในบางครั้งอาจจะเป็น last transaction ในกรณีที่ระบบมีความสำคัญสูง
- การวาง Recovery Procedure ที่ชัดเจน เช่น การ restore datafile, การ restore transaction log, การ rollback-rollforward recovery รวมไปถึงการตรวจสอบความถูกต้อง data integrity ภายหลังจากการกู้ระบบ
- การทดสอบและซักซ้อมการ Recover ระบบ เพื่อให้มั่นใจว่าสามารถทำได้จริง และทำได้ตามเวลาที่กำหนด ผู้ดูแลระบบฐานข้อมูลจำเป็นต้องเห็นความสัมพันธ์ในภาพรวมเพื่อให้สามารถ correlate และ drill down เพื่อแก้ไขปัญหาได้ตรงจุด
- การเก็บข้อมูล Performance Measurement จะทำให้สามารถบริหารจัดการแบบ pro-active ได้ เช่น การทำ capacity planning และการตรวจสอบ anomaly detection and remediation
3. Failure Recovery
สำหรับระบบฐานข้อมูลที่มีความสำคัญสูง นอกจากการออกแบบ Backup and Recovery ที่ดีแล้ว ยังอาจจำเป็นต้องออกแบบ Database Infrastructure ที่สามารถรองรับ Failure Scenario ต่างๆ ได้ เช่น Hardware component failure, Database server failure, Data center failure เป็นต้น
- Hardware Component Failure เช่น กรณี hard disk มีปัญหา หรือ power supply ของเครื่อง server มีปัญหา โดยส่วนใหญ่ จะสามารถป้องกันได้โดยการใช้ Hardware ที่มี redundancy เช่น การทำ disk RAID หรือการใช้ redundant power supply
- Database Server Failure ในกรณีที่ server ที่ทำหน้าที่เป็น Database server มีปัญหา จะสามารถออกแบบป้องกันได้โดยการให้มี server สำรอง เช่น hot standby server โดยการ failover shared storage หรือการทำ database replication ซึ่งสามารถทำได้ทั้งแบบ synchronous และ asynchronous
- Data Center Failure สำหรับระบบที่มีความสำคัญสูง จะมีการวางแผนให้มี Data Recover Center (DRC) เพื่อสำรองในกรณีที่ Data Center หลักไม่สามารถให้บริการได้ การออกแบบ Infrastructure จะต้องสำรองข้อมูลโดยการ replicate data ไปยัง DRC ซึ่งสามารถทำได้แบบ snapshot sync เป็นระยะ หรือ real time replication ทั้งแบบ synchronous และ asynchronous ซึ่งจะมีข้อดีและข้อจำกัดแตกต่างกันไป
การเลือกออกแบบ solution สำหรับ Failure recover ในลักษณะต่างๆ จะต้องสอดคล้องกับ business requirement และพิจารณาถึงความซับซ้อนของ solution และข้อจำกัดต่างๆ เช่น การใช้ shared storage จะมี single point of failure และต้องการ storage ที่มีเสถียรภาพสูง การเลือกใช้ synchronous replication จะส่งผลกับ application performance และระยะทางระหว่าง data center เป็นต้น นอกจากนั้นผู้ดูแลระบบจำเป็นต้องทดสอบขั้นตอนการกู้ระบบตาม Failure recovery procedure ในลักษณะต่างๆ เป็นประจำเพื่อให้มั่นใจว่า solution และ procedure ที่วางไว้จะสามารถใช้งานได้จริง
4. Monitoring and Alert
การวางระบบ Monitoring and Alert เป็น foundation ที่สำคัญในการ manage DBMS ผู้ดูแลระบบจำเป็นต้องมีเครื่องมือเพื่อให้เห็น workload และ system resource utilization ของระบบ DBMS เมื่อมีความผิดปกติเกิดขึ้น
การออกแบบ Alert channel, Alert level และ Pre-define action ที่ชัดเจนจะทำให้สามารถแก้ไขปัญหาได้อย่างรวดเร็ว ลดผลกระทบหากเกิดปัญหาขึ้นในระบบ
ทั้งนี้ การเลือก tools และ measurement ที่ดีก็เป็นอีกองค์ประกอบสำคัญสำหรับ Monitoring and Alert เช่น ความสามารถในการ monitor ระบบในภาพรวมแบบ Full stack ได้แก่
- Application & End-user Measurement เพื่อรวบรวมและตรวจสอบข้อมูลให้ครบถ้วนทั้งฝั่งของ Server และผู้ใช้งาน ช่วยให้สามารถทำการแก้ไขปัญหาได้อย่างสะดวกรวดเร็วยิ่งขึ้น
- Database Performance Indicator สำหรับชี้วัดประสิทธิภาพการทำงานของ Database ในแต่ละช่วงเวลาหรือแต่ละคำสั่ง
- Slow Query, Expensive SQL เพื่อช่วยในการตรวจสอบและปรับปรุงประสิทธิภาพการทำงานของระบบให้สูงขึ้นอย่างต่อเนื่อง โดยเฉพาะอย่างยิ่งเมื่อมีการเพิ่มชุดคำสั่งใหม่ๆ เข้ามาในระบบ
- CPU, Memory, Disk I/O Utilization สำหรับตรวจสอบประสิทธิภาพในระดับของ Hardware และใช้วางแผนในการลงทุนเพิ่มขยายระบบได้อย่างเหมาะสม
- Network Utilization สำหรับใช้ตรวจสอบประสิทธิภาพในระดับของระบบเครือข่าย เพื่อให้แก้ไขปัญหาคอขวดที่เกิดขึ้นบน Network ได้ทันท่วงที โดยเฉพาะอย่างยิ่งเมื่อเกิดเหตุระบบเครือข่ายล่ม หรือมีการโอนถ่ายข้อมูลปริมาณมหาศาลในระหว่าง Backup หรือเมื่อเกิดเหตุ Data Breach
5. Security
ปัจจุบัน Data security เป็นเรื่องสำคัญที่ทุกองค์กรไม่สามารถปฏิเสธได้ ผลกระทบจากปัญหา security เช่น การขโมยข้อมูลทั้งจากภายนอกและภายในเองค์กรเอง จะส่งผลกระทบต่อความเชื่อมั่นกับทุกธุรกิจ ดังนั้นการออกแบบและบริหารจัดการ security ของระบบฐานข้อมูลจึงเป็นสิ่งจำเป็น โดยมีแนวทางเบื้องต้นดังต่อไปนี้
- การออกแบบ security ควรทำตั้งแต่การเลือก solution และออกแบบ Database infrastructure เช่น ปัจจุบันหลายองค์กรเห็นความจำเป็นในการเข้ารหัสข้อมูล ดังนั้นการออกแบบ data encryption ควรพิจารณาในระดับ design เช่น การกำหนดระดับ data confidential level, การเลือก encryption strategy, การ manage encryption key, การเลือก hardware หรือ software encryption ที่มีประสิทธิภาพตรงกับการใช้งานจริง
- การกำหนดและบังคับใช้ Security Guideline เช่น ข้อกำหนดเรื่อง authentication and authorization, การทำ security monitoring เช่น audit log และการกำหนด process ของการ monitor and action
- การทำ Security Test เช่น VA scan หรือ Penetration test และการแก้ไขปัญหา security vulnerability ที่พบ เช่น การการติดตั้ง security fix หรือ implement workaround ซึ่งผู้ดูแลระบบฐานข้อมูลต้องวางแผนเพื่อป้องกันช่องโหว่ทางด้าน security ในระบบ DBMS
สนใจทำโครงการ Enterprise Database Migration ติดต่อทีมงาน TN ได้ทันที
การบริหารจัดการระบบ DBMS มีความสำคัญสำหรับองค์กร หน่วยงานทางด้าน IT มีความจำเป็นต้องสร้างและพัฒนาศักยภาพของ Database Administrator เพื่อให้สามารถตอบสนองความต้องการขององค์กรได้ T.N. Incorporation เล็งเห็นความสำคัญและมี Professional service สำหรับองค์กร ดังต่อไปนี้
• Database platform consulting ให้บริการออกแบบและให้คำปรึกษาในระดับ database infrastructure เพื่อให้ได้ solution ที่เหมาะสมตรงกับความต้องการ
• Database migration service
• Production technical support แบบ 24×7 โดยทีมงานภายในประเทศไทย ซึ่งมีประสบการณ์ในการ support ระบบในระดับ mission critical มีเข้าใจความต้องการที่เป็นลักษณะเฉพาะของระบบงาน IT ในองค์กรในประเทศไทย
สำหรับผู้ที่สนใจใช้งาน PostgreSQL สามารถติดต่อสอบถามหรือทำการทดสอบระบบได้ทันทีกับทีมงาน TN ที่ Marketing Team หมายเลขโทรศัพท์ 02 3439100 หรือ Email: mkt_bd@tnis.com
