TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
การย้ายระบบ Enterprise Database ของ Business Application สำคัญไปสู่ Open Source Database เพื่อลดค่าใช้จ่ายในระยะยาวขององค์กรนั้นเป็นแนวทางที่ได้รับความนิยมมากขึ้นทุกๆปีและในบทความนี้ทีมงาน TN ก็จะมาแบ่งปันแนวทางและประสบการณ์การย้ายระบบ Enterprise Database ชื่อดังไปสู่ PostgreSQL เพื่อเป็นประโยชน์ให้กับผู้อ่าน TechTalkThai ทุกท่านดังนี้ครับ
1. เตรียมการโครงการ
1.1 สำรวจการทำงานของระบบเดิม เพื่อทำความเข้าใจการใช้งาน
ขั้นตอนแรกสุดของโครงการ Database Migration คือ การสรุปความต้องการของระบบให้ชัดเจน ว่าระบบ Business Application เดิมนั้นเป็นระบบอะไร มีการออกแบบและทำงานอย่างไร ใช้เทคโนโลยีใด มีสถาปัตยกรรมแบบไหน และมีข้อจำกัดในเชิงธุรกิจอย่างไร ด้วยการทำ Application Assessment ในเชิงลึก เพื่อให้ผู้ดำเนินโครงการนั้นเข้าใจถึงความสัมพันธ์ของ Application และข้อมูลทั้งหมด สามารถทำการออกแบบระบบใหม่ เลือกใช้งานเทคโนโลยีและวางแผนการทำงานอย่างถูกต้องแม่นยำที่สุด
ขั้นตอนนี้ถือเป็นขั้นตอนที่มีความสำคัญมาก เพราะหากข้อมูลครบถ้วนถูกต้องมาตั้งแต่แรก การวางแผนการทำงานถัดจากนี้ทั้งหมดก็จะเป็นไปได้อย่างราบรื่น
1.2 ประเมินคุณสมบัติของ Open Source Database ทางเลือกต่างๆ และเลือกใช้เทคโนโลยีที่เหมาะสมกับงาน
เมื่อทีมงาน Migration เข้าใจโจทย์ของการทำงานอย่างชัดเจนแล้ว ขั้นตอนถัดมาก็คือการเลือกใช้งานเทคโนโลยีที่เหมาะสม ซึ่งเป็นขั้นตอนที่ต้องทำการสำรวจและทดสอบเครื่องมือต่างๆที่จะเข้ามาช่วยในการทำงาน เพื่อให้มั่นใจได้ว่าเทคโนโลยี Open Source Database ใหม่ที่จะใช้งานได้นั้นมีความสามารถที่ครอบคลุมและใช้ทดแทนระบบเดิมได้อย่างสมบูรณ์จริงๆ
ทีมงานของ TN ได้ระบุถึง 4 ปัจจัย ในการเลือกใช้ Open Source Database คือ
- Features การสำรวจว่าระบบเดิมนั้นใช้ความสามารถใดบน Enterprise Database ที่เป็น commercial software อยู่บ้าง ความสามารถใดจำเป็นหรือไม่จำเป็น และนำมาเทียบกับ Open Source Database ว่าสำหรับแต่ละความสามารถในระบบเดิมนั้น ระบบใหม่จะนำความสามารถใดมาใช้ทดแทนได้บ้างในเชิงเทคนิค ซึ่งโดยทั่วไปทางทีมงานก็พบว่าธุรกิจส่วนใหญ่ใช้งานความสามารถเพียงแค่ 20-30% ของ Enterprise Database เท่านั้น ซึ่งก็ถือว่ายังไม่คุ้มค่านักกับค่าใช้จ่ายที่เสียไปในแต่ละปี ดังนั้นการเลือกใช้ opensource ที่มีความสามารถครอบคลุมการใช้งานดังกล่าวได้มาทดแทน ก็เพียงพอแล้ว ซึ่ง Open Source Database สมัยนี้สามารถทำงานในเรื่องเหล่านี้ได้ทัดเทียมกับ Commercial Database ได้สบาย
- Performance ควรเป็น Opensource Database ในระดับ Enterprise สามารถรองรับการ scale ในอนาคตที่อาจจะเกิดขึ้นได้
- Community มี Community ที่แข็งแกร่ง เพื่อสนับสนุนการแก้ปัญหาจากการใช้งานจริง และมีการพัฒนาความสามารถต่อยอดเพิ่มเติมในอนาคต
- Site References เพื่อให้ผู้บริหารมีความมั่นใจในการเปลี่ยนเทคโนโลยี การเลือกใช้ Open Source Database ที่ธุรกิจองค์กรใหญ่แห่งอื่นๆเลือกใช้มาแล้ว สามารถเชื่อมั่นได้ว่าทำงานได้จริง
ในหลายโครงการที่ผ่านมา TN ได้เลือกใช้งาน PostgreSQL เพื่อทดแทน Enterprise Database ชื่อดังหลายแบรนด์ให้ลูกค้าของบริษัท เนื่องจากเป็น Open Source Database ที่ตอบโจทย์ข้างต้นนี้ได้อย่างครบถ้วนที่สุด และมีความยืดหยุ่นสำหรับนำไปปรับแต่งใช้งานได้ในหลากหลายสถานการณ์ ทั้งยังมีผู้ให้บริการ Cloud ชั้นนำระดับโลกหลายรายที่นำไปเปิดให้บริการเป็นทางเลือกแกลูกค้า ในการ Deploy ระบบทั้งแบบ On-Premises และ On Cloud
1.3 การเตรียม Resource สำหรับ Migration
เพื่อให้การ Migrate Database ดำเนินการสำเร็จตามเป้าหมายที่วางไว้ การวางแผน Resource ที่จะใช้ในโครงการจึงเป็นสิ่งสำคัญเช่นกัน โดยสามารถแยกออกเป็นสองส่วน คือ
- ด้านเทคนิค จะต้องมีการวางแผนในเรื่อง Workload and Resource Sizing เพื่อประเมินปริมาณ workload ที่ database จะต้องสามารถรองรับได้ เช่น จำนวนผู้ใช้งาน ขนาด data concurrent database connection ปริมาณ database query per second เพื่อกำหนดขนาดของ CPU, memory, disk space และ network bandwidth ที่เพียงพอให้สามารถรองรับปริมาณการใช้งานจริงได้ นอกจากนั้นอาจจะต้องวางวิธีการ scale resource capacity เพิ่มในกรณีที่ workload มากขึ้นในอนาคต
- ด้านบุคคลากร การเตรียมทีมงานโครงการให้พร้อมเป็นส่วนสำคัญมากที่จะทำให้โครงการสำเร็จ ทีมงานปกติจะประกอบไปด้วย ผู้รับผิดชอบโครงการหลัก Project director ผู้ดำเนินโครงการ Project manager บุคคลกรด้าน technical เช่น System engineer, Database Specialist เป็นต้น Key Success Factor หนึ่งที่เป็นสิ่งสำคัญต่อการดำเนินการโครงการ คือ ทางเจ้าของโครงการต้องมีการมอบหมายผู้รับผิดชอบโครงการหลักเพื่อทำงานร่วมกับทีมงานโครงการ รวมถึงมอบหมายแนวทางในการตัดสินใจหรือกำหนดผู้มีอำนาจในการตัดสินใจในการดำเนินโครงการ ก็จะยิ่งทำให้โครงการมีความราบรื่นเป็นไปตามเป้าหมาย
2. วางแผนการทำ Migration
เมื่อมั่นใจแล้วว่าเทคโนโลยี Open Source Database ที่เราเลือกนำมาใช้ทดแทน Enterprise Database นั้นจะสามารถตอบโจทย์การใช้งานในเชิงเทคนิคได้อย่างครบถ้วนแล้ว ก็ถึงขั้นตอนของการวางแผนด้านการทำ Migration โดยจะแบ่งออกเป็น 3 ส่วนใหญ่ๆ ด้วยกัน
ส่วนแรก คือ การวางแผนในการทำ Application Migration ที่จะต้องลงรายละเอียดให้ชัดว่าในแต่ละความสามารถที่เปิดใช้บน Enterprise Database เดิมนั้นจะต้องใช้ความสามารถใดบน Open Source Database ใหม่ หรือแต่ละ Query ที่ใช้งานนั้นจะต้องมีการเปลี่ยนแปลงแก้ไขอย่างไรบ้าง หรือการตั้งค่าใน Enterprise Database เดิมนั้น หากย้ายมายังระบบใหม่จำเป็นที่จะต้องมีการปรับแต่งการตั้งค่าอย่างไรบ้าง
จากประสบการณ์ของ TN 80% ของการใช้งานระบบ Enterprise Database เดิมจะสามารถย้ายไปยังระบบ Open Source Database ใหม่แทบจะทันทีโดยที่ไม่ต้องมีการปรับแต่งแก้ไขใดๆ ในขณะที่อีก 20% ที่เหลือนั้นจะต้องมีการแก้ไขหรือไม่ขึ้นอยู่รายละเอียดของแต่ละโครงการ
มุมหนึ่งที่น่าสนใจนั้นก็คือสำหรับระบบ Enterprise Application ขนาดใหญ่ของหลายๆ องค์กรที่มีการใช้งานอยู่นั้น มักมีการใช้งาน Middleware หรือ Object-Relational Mapping (ORM) อยู่แล้ว ทำให้การย้ายระบบเหล่านี้ง่ายขึ้น เนื่องจากไม่ต้องไปแก้ไข Application ในส่วนของ Query โดยตรง แต่ก็จะเป็นโจทย์ที่ผู้ทำ Migration ระบบจะต้องมีความรู้ความสามารถด้านการจัดการ Middleware หรือ ORM ด้วย ซึ่งทีมงานของ TN เองก็มีประสบการณ์ในส่วนนี้อยู่แล้วจึงสามารถทำงานลักษณะนี้ได้ดี
ส่วนที่สอง คือ การวางแผนในการทำ Data Migration ที่จะมีรายละเอียดปลีกย่อยหลายประการ เช่น
- Schema Migration เป็นการ Migrate โครงสร้างอย่างเช่น Table , View , Index , Function , Sequence , Data Type , Aggregate Function และอื่นๆ
- Role Migration เป็นการ Migrate User และ Role สำหรับระบบ Database
- Administrator เป็นการวางแผนการตั้งค่า Session Manager, Lock Manager และอื่นๆ
- Extension เป็นการติดตั้ง Extension ที่จำเป็นต่อการใช้งานเพิ่มเติม
- Storage วางแผนการตั้งค่า Tablespace
- Data Migration วางแผนในการย้ายข้อมูล โดยเลือกใช้เทคโนโลยีหรือกระบวนการให้เหมาะสมกับการใช้งาน เช่น การ Migrate ข้อมูลส่วนใหญ่โดยไม่กระทบต่อระบบ Production, การอัปเดตข้อมูลย่อยที่ถูกเพิ่มหรือแก้ไขในแต่ละวัน และอื่นๆ
- Data Verification วางแผนการตรวจสอบความถูกต้องของข้อมูลที่ย้ายมา ว่าจะตรวจสอบความถูกต้องและครบถ้วนอย่างไร เพื่อให้มั่นใจก่อนการย้ายระบบทั้งหมดและขึ้นระบบสำหรับการใช้งาน
ส่วนสุดท้าย คือ การวางแผนการ Go Live นำระบบใหม่ขึ้นใช้งานทดแทนระบบเก่าโดยไม่ให้กระทบกับประสบการณ์ของผู้ใช้งาน และตรวจสอบการทำงานของระบบเพื่อให้มั่นใจว่าระบบจะไม่มีปัญหาใดๆ หรือหากมีปัญหาใดๆ เกิดขึ้นก็สามารถแก้ไขได้อย่างทันท่วงที ให้ระบบใหม่สามารถทำงานทดแทนระบบเก่าได้อย่างสมบูรณ์ 100% ให้รวดเร็วที่สุด
3. ลงมือทำ Database Migration
3.1 งาน Infrastructure
เมื่อมีความต้องการของระบบและแผนการที่ชัดเจนแล้ว ขั้นถัดมาก็คือลงมือการออกแบบระบบ Open Source Database ใหม่ว่าจะมีสถาปัตยกรรมการทำงานของระบบเป็นอย่างไร ใช้ Software รุ่นไหน มีส่วนประกอบอื่นๆ ที่จำเป็นอย่างไรบ้าง จะติดตั้งลงบน VM Cloud หรือ Hardware ที่มีขนาดเท่าไหร่อย่างไร ต้องติดตั้งกี่ระบบให้ทำงานร่วมกันด้วยวิธีการใด จะมีการปกป้องข้อมูลอย่างไร จะมีการสำรองหรือกู้คืนข้อมูลได้อย่างไร และอื่นๆ เพื่อให้ระบบมีความพร้อมต่อการนำไปใช้งานจริง
เมื่อทุกอย่างพร้อมแล้ว ก็สามารถทำการติดตั้ง Open Source Database ใหม่ได้ตามการออกแบบที่วางเอาไว้ได้ทันที โดย infrastructure ที่ออกแบบนี้ต้องมีความมั่นคงปลอดภัย ลดความเสี่ยงที่ระบบจะถูกโจมตี รองรับการขยายระบบในอนาคต รวมถึงสามารถรองรับ peak load ที่อาจจะมีโอกาสเพิ่มขึ้น ฯลฯ ไว้ด้วย
3.2 เริ่มต้นทำ Data Migration ให้ข้อมูลถูกย้ายไปอย่างครบถ้วนสมบูรณ์
เมื่อติดตั้งระบบเสร็จแล้ว ขั้นถัดมาก็คือการ Migrate ข้อมูลซึ่งเป็นหัวใจของธุรกิจที่จะให้มีความผิดพลาดไม่ได้ และผู้ใช้งานจะต้องสามารถทำงานต่อจากที่ค้างไว้ก่อนการทำ Migration ได้โดยไม่ติดขัด
จากประสบการณ์ของ TN พบว่าวิธีการทำ Data Migration และเครื่องมือสำหรับจัดการงานเหล่านี้มีด้วยกันหลากหลาย แต่ในการทดสอบและใช้งานจริงนั้นไม่มีเครื่องมือใดเลยที่สามารถจะ Migrate ได้ครบถ้วน 100% ดังนั้นทีมผู้ทำ Migration จึงจำเป็นจะต้องมีทักษะในการพัฒนาเครื่องมือเพื่อ Migrate ข้อมูลเหล่านี้ด้วย และยังต้องมีความเข้าใจในข้อจำกัดต่างๆ ของระบบเป็นอย่างดีเพื่อให้เครื่องมือและกระบวนการนี้เป็นไปได้อย่างราบรื่นที่สุด
แนวทางหนึ่งที่ TN แนะนำนั้นก็คือการเพิ่มแผนในส่วนของการซ้อม Migration ข้อมูลแต่ละส่วนเอาไว้ในโครงการด้วย เพื่อให้ผู้ที่เกี่ยวข้องทั้งหมดมีโอกาสในการซักซ้อมและทดลองใช้เครื่องมือในการย้ายข้อมูลที่พัฒนาขึ้นมา ให้เกิดความมั่นใจว่าเมื่อถึงเวลาจริงแล้วข้อมูลทั้งหมดจะสามารถถูกย้ายได้อย่างสมบูรณ์ พร้อมมีข้อมูลสำหรับประเมินระยะเวลาในการย้ายระบบหรือย้ายข้อมูลประกอบการวางแผนให้สามารถย้ายระบบและเปิดใช้งานได้ทันโดยไม่กระทบต่อประสบการณ์ของผู้ใช้งาน
นอกจากนี้ ขั้นตอนการทำ Data Verification เพื่อตรวจสอบความถูกต้องของข้อมูลที่ย้ายมา และการทำ Data Sign-Off เพื่อยืนยันว่าข้อมูลเหล่านี้ถูกต้องและสามารถนำไปใช้งานได้นั้นก็สำคัญเช่นกัน การตกลงวิธีการและกระบวนการเหล่านี้ให้ชัดรวมถึงการทดสอบให้มั่นใจเป็นอีกปัจจัยสำคัญที่ทำให้การย้ายระบบครั้งใหญ่นี้มีความราบรื่น
3.3 ทำ Application Migration ให้ระบบพร้อมใช้งาน
แต่ละระบบนั้นอาจมีการทำ Application Migration ในระดับที่ต่างกัน บางระบบนั้นอาจแทบไม่ต้องทำการปรับแต่งแก้ไขในส่วนของ Application เลย ในขณะที่บางระบบก็อาจต้องมีโค้ดอีกชุดเพื่อรองรับการทำงานร่วมกับระบบ Open Source Database ใหม่โดยเฉพาะ รวมถึงยังต้องมีการตั้งค่าให้กับระบบ Application Server หรือ Parameter ต่างๆ ให้ทำงานร่วมกับ Open Source Database ได้อีกด้วย
การเตรียมระบบ Application ให้พร้อมใช้งานหลังจากที่ย้าย Database เอาไว้แต่เนิ่นๆ จะช่วยให้การทดสอบระบบและการย้ายระบบโดยรวมมีความราบรื่นเป็นอย่างมาก โดยควรต้องคำนึงถึงประเด็นด้านประสบการณ์ของผู้ใช้งานที่จะต้องใช้ระบบใหม่ได้โดยไม่ต้องเปลี่ยนแปลงพฤติกรรมการใช้งานเลยหรือเปลี่ยนแปลงให้น้อยที่สุดและต้องคำนึงถึงประเด็นด้าน Security ของระบบด้วยเช่นกัน
3.4 การทดสอบ performance test
การทำ performance test มีความสำคัญเพื่อทดสอบว่าระบบฐานข้อมูลจะสามารถทำงานได้อย่างมีประสิทธิภาพหลังจาก migrate data แล้ว การทดสอบ performance ระบบจะต้องประเมินจากลักษณะ load pattern ที่จะเกิดขึ้นจริง เพื่อทดสอบว่าระบบมี response time เป็นไปตามข้อกำหนด SLA ที่ตั้งไว้ ผลของการทดสอบ performance test จะทำให้ทราบถึง resource utilization ที่จะเกิดขึ้นจริงก่อนการใช้งานระบบ และนอกจากนั้นจะทำให้ทราบถึงปัญหาหรือ bottleneck ยกตัวอย่างเช่น การ lock record, expensive SQL, หรือค่า database parameter ที่ควรปรับปรุง เพื่อที่จะได้ปรับปรุงทั้งในส่วนของ system parameter หรือ query tuning ก่อนที่จะใช้งานจริงบนระบบ production
4. เก็บรายละเอียดของระบบให้ครบถ้วน ก่อนส่งมอบงาน
สุดท้ายแล้วในการย้ายระบบแต่ละครั้งนั้นก็ยังอาจมีจุดผิดพลาดเล็กๆ น้อยๆ ที่หลงเหลืออยู่บ้าง ดังนั้นการเตรียมรับ Feedback ของผู้ใช้งานถึงจุดผิดพลาดที่คาดไม่ถึงเหล่านี้และเตรียมตัวแก้ไขระบบให้ทำงานได้อย่างถูกต้องจึงเป็นอีกขั้นตอนที่จำเป็นก่อนที่จะส่งมอบงานสุดท้ายซึ่งเสร็จสมบูรณ์แล้วให้กับเจ้าของระบบนั่นเอง
จะเห็นได้ว่าการย้ายระบบ Enterprise Database ไปสู่ Open Source Database นั้นนอกจากจะมีประเด็นทางด้านเทคนิคที่ต้องคำนึงถึงแล้ว ประเด็นทางด้านกระบวนการการทำงานที่เหมาะสมนั้นก็มีส่วนสำคัญไม่น้อย ดังนั้นในโครงการทำ Database Migration ที่ผ่านมาของ TN นี้จึงต้องมีการวางแผนอย่างรอบคอบ และต้องอาศัยความมีส่วนร่วมกันของทั้งเจ้าหน้าที่ฝ่าย IT และฝ่ายธุรกิจในองค์กร เพื่อให้โครงการดำเนินออกมาได้อย่างราบรื่น บรรลุเป้าหมาย ซึ่งทาง TN จะจัดเตรียมทีมงานซึ่งประกอบไปด้วยผู้รับผิดชอบโครงการหลัก (Project director) ผู้ดำเนินโครงการ (Project manager)
และ บุคลากรที่มีความชำนาญในด้านต่าง ๆ เช่น System engineer, Database Specialist, Application Analyst เป็นต้น ซึ่งทาง TN มีผู้เชี่ยวชาญ local support ที่เป็นคนไทย สามารถให้บริการได้ทันที ไม่จำเป็นต้องรอผู้เชี่ยวชาญจากต่างประเทศ เข้าใจวัฒนธรรมการทำงานแบบไทย ทำงานสำเร็จมาแล้วและเรายังมีช่องทางการเข้าถึง world class support กรณีโครงการมีความซับซ้อนอย่างมาก เพื่อให้ลูกค้ามั่นใจใน support ของบริษัท
ทั้งนี้ทีมงาน TN ก็พร้อมที่จะช่วยธุรกิจองค์กรไทยลดค่าใช้จ่ายด้วยการย้ายมาใช้งานระบบ Open Source Database แทน Enterprise Database ที่มีอยู่เดิม หากธุรกิจองค์กรใดสนใจย้ายระบบมาใช้งาน Open Source Database สามารถติดต่อทีมงาน TN เพื่อพูดคุยและทำ Assessment ประเมินความพร้อมและตรวจสอบประเด็นทางเทคนิคได้ทันที
สนใจเปลี่ยนมาใช้งาน PostgreSQL แทนระบบ Commercial Database Software เดิม ติดต่อ TN ได้ที่
Marketing Team หมายเลขโทรศัพท์ 081 4429591 หรือ Email: mkt_bd@tnis.com
