TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
ไม่กี่วันที่ผ่านมา เกิดเหตุการณ์ Amazon S3 ในแถบรัฐเวอร์จิเนียตอนเหนือ (N. Virginia หรือ US-EAST-1 Region) ประสบปัญหาทำงานผิดปกติ ซึ่งส่งผลกระทบต่อบริการอื่นๆ ที่เชื่อมโยงกับ S3 และทำให้ผู้ใช้บริการ AWS หลายล้านรายไม่สามารถให้บริการลูกค้าได้ จนถึงตอนนี้ทราบสาเหตุแล้วว่าเกิดจากการที่วิศวกรของ AWS รันคำสั่งผิด
คำถามคือ แล้วเราจะเตรียมรับมือกับเหตุการณ์ที่ระบบ Cloud เกิดปัญหาหรือหยุดให้บริการได้อย่างไร ?
เว็บไซต์ Network World ได้สรุปคำแนะนำ 5 รายการอ้างอิงจาก Best Practices ของ AWS ดังนี้
1. อย่าเก็บทุกอย่างไว้ในที่เดียว
คำแนะนำนี้อาจแตกต่างกันไปตามแต่ละผู้ใช้ แต่โดยพื้นฐานคือ ถ้าคุณเก็บระบบแอพพลิเคชันหรือข้อมูลไว้ในที่ที่เดียว ระบบ Cloud ของคุณจะไม่ Fault Tolerant ทันที คุณควรวางแผนกระจายแอพพลิเคชันและข้อมูลไปไว้ตามจุดต่างๆ ขึ้นอยู่กับว่าต้องการให้มีความพร้อมใช้งาน (Availability) มากน้อยแค่ไหน เช่น
- AWS แนะนำให้กระจาย Workload ไปยังหลายๆ Availability Zone (AZ) ซึ่งแต่ละ Region จะมี AZ พร้อมให้ทำ Backup หรือ DR อยู่แล้วอย่างน้อย 2 AZs (บางที่อาจะมีสูงถึง 5 AZs) AZ แต่ละแห่งใน Region นั้นจะแยกโครงสร้างพื้นฐานออกจากกันอย่างชัดเจน แต่เชื่อมต่อกันด้วยเครือข่ายที่มี Latecy ต่ำ
- ถ้าต้องการเพิ่มความต่อเนื่องในการใช้งานหรือให้บริการ สามารถกระจายแอพพลิเคชันและข้อมูลข้ามไปเก็บไว้ยัง Region อื่นๆ ได้
- สำหรับการป้องกันขั้นสูงสุด แนะนำให้กระจาย Wordload ไปยัง Cloud Provider หลายๆ เจ้า เช่น Microsoft Azure หรือ Google Cloud หรือสำรองข้อมูลเก็บไว้ที่ Data Center ของตน
2. ระบุความผิดปกติให้ได้เร็วที่สุด
หนึ่งสิ่งสำคัญในการรับมือกับเหตุผิดปกติคือต้องทราบให้ได้ว่าเกิดอะไรขึ้นให้เร็วที่สุด AWS มีระบบมอนิเตอร์ให้เลือกใช้หลายรายการ ระบบพื้นฐานที่สุดคือ Health Checks ซึ่งให้บริการการติดตามและเฝ้าระวังสถานะของ AWS ในแต่ละบัญชีรายชื่อ หรือ Amazon CLoudWatch ที่สามารถตั้งค่าให้ติดตามความพร้อมใช้งานของบริการต่างๆ ได้อย่างต่อเนื่อง พร้อมแจ้งเตือนเมื่อพบเหตุผิดปกติ
ความผิดปกติบางอย่างอาจนำไปสู่ผลกระทบแบบลูกโซ่ (เช่น กรณี Amazon S3) ทำให้อาจจำเป็นต้องมีการเตรียมตัวสำหรับรับมือเหตุผิดปกติไว้ล่วงหน้า เช่น การมี DR Site หรือระบบสำรองข้อมูล รวมไปถึงอาจต้องมี Load Balance ไว้สำหรับเปลี่ยนเส้นทางของทราฟฟิกไปยังระบบสำรอง
3. จัดทำระบบสำรองตั้งแต่เริ่มใช้งาน
การรับมือกับเหตุผิดปกติ เช่น ระบบล่ม ณ ขณะเกิดเหตุไม่ใช่ความคิดที่ดีนัก การเตรียมตัวให้พร้อมรับมือเป็นสิ่งที่ควรดำเนินการไว้ตั้งแต่เนิ่นๆ ซึ่งปกติแล้วเราสามารถเตรียมระบบสำรองได้ 2 แบบ คือ
- Active-Standby – เมื่อเกิดเหตุผิดปกติ แอพพลิเคชันจะหันไปใช้ระบบสำรองแทน ซึ่งวิธีนี้โดยปกติแล้วระบบสำรองจะอยู่ในสถานะ Standby ไม่ถูกใช้งานในสภาวะปกติ ข้อเสียของวิธีนี้คืออาจมี Downtime เล็กน้อยระหว่างตรวจพบปัญหาและโยกการทำงานทั้งหมดมาที่ระบบสำรอง
- Active-Active – ระบบหลักและระบบสำรองทำงานไปพร้อมๆ กัน เมื่อระบบใดระบบหนึ่งเกิดปัญหา ทราฟฟิกทั้งหมดจะถูกโยกมาประมวลผลที่อีกระบบหนึ่งแทน วิธีนี้มีข้อดีคือไม่มี Downtime ต่ำมาก หรืออาจจะไม่มีเลย แต่ลงทุนสูงกว่า เพราะต้องจัดเตรียมระบบให้พร้อมรับมือกับปริมาณทราฟฟิกที่เพิ่มสูงขึ้นเมื่อระบบใดระบบหนึ่งตาย
ทั้งนี้อย่าเข้าใจผิดว่าเมื่อใช้งานระบบ Cloud จะเป็นหน้าที่ของ Cloud Provider ที่จะทำระบบสำรอง โยกย้ายข้อมูลและทราฟฟิก เมื่อเกิดเหตุให้ Cloud Provider มีหน้าที่เพียงจัดเตรียมทรัพยากรสำหรับสนับสนุนการทำระบบสำรองเท่านั้น
4. สำรองข้อมูลสม่ำเสมอ
การสำรองข้อมูลต่างจากระบบสำรองตรงที่ ถ้าเกิดความผิดพลาดกับข้อมูล เช่น ข้อมูลสูญหาย หรือแก้ไขข้อมูลผิด เป็นไปได้ที่จะเกิดขึ้นกับระบบสำรองด้วยเช่นกัน เนื่องจากระบบหลักและระบบสำรองต้องซิงค์ข้อมูลหากันตลอดเวลา เพื่อแก้ไขปัญหาดังกล่าวจึงควรมีการสำรองข้อมูลอย่างสม่ำเสมอด้วยเช่นกัน AWS มีวิธีการสำรองข้อมูลให้เลือกหลายวิธี เช่น Synchronous Replication, Asynchronous Replication และ Quorum-based Replication วิธีไหนที่เหมาะสมที่สุดให้พิจารณาจาก RPO (Recovery Point Objective) และ RTO (Recovery Time Objective)
5. ทดสอบระบบ Cloud ที่ใช้
วิธีการที่ดีที่สุดในการเตรียมรับมือกับเหตุผิดปกติ คือ การฝึกซ้อมจากสถานการณ์จำลอง เช่น ทดสอบปิดระบบหรือบริการบางอย่าง แล้วดูว่าแอพพลิเคชันยังคงให้บริการอย่างต่อเนื่องได้หรือไม่ รวมไปถึงฝึกให้ผู้ดูแลระบบพร้อมรับมือกับสถานการณ์ดังกล่าว วิธีนี้ช่วยให้เมื่อเกิดเหตุการณ์จริงทุกคนจะสามารถรับมือได้อย่างรวดเร็วและเป็นระบบ
รายละเอียดเพิ่มเติมเกี่ยวกับ AWS Best Practices สามารถดูได้ที่ AWS White Paper [PDF]
