Breaking News

5 สิ่งที่เราได้เรียนรู้จากการที่ Amazon S3 หยุดให้บริการ

ไม่กี่วันที่ผ่านมา เกิดเหตุการณ์ Amazon S3 ในแถบรัฐเวอร์จิเนียตอนเหนือ (N. Virginia หรือ US-EAST-1 Region) ประสบปัญหาทำงานผิดปกติ ซึ่งส่งผลกระทบต่อบริการอื่นๆ ที่เชื่อมโยงกับ S3 และทำให้ผู้ใช้บริการ AWS หลายล้านรายไม่สามารถให้บริการลูกค้าได้ จนถึงตอนนี้ทราบสาเหตุแล้วว่าเกิดจากการที่วิศวกรของ AWS รันคำสั่งผิด

คำถามคือ แล้วเราจะเตรียมรับมือกับเหตุการณ์ที่ระบบ Cloud เกิดปัญหาหรือหยุดให้บริการได้อย่างไร ?

Credit: Viappy/ShutterStock

เว็บไซต์ 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]

ที่มา: http://www.networkworld.com/article/3175143/cloud-computing/5-lessons-from-amazon-s-s3-cloud-blunder-and-how-to-prepare-for-the-next-one.html


About techtalkthai

ทีมงาน TechTalkThai เป็นกลุ่มบุคคลที่ทำงานในสาย Enterprise IT ที่มีความเชี่ยวชาญทางด้าน Network, Security, Server, Storage, Operating System และ Virtualization มารวมตัวกันเพื่ออัพเดตข่าวสารทางด้าน Enterprise IT ให้แก่ชาว IT ในไทยโดยเฉพาะ

Check Also

[Guest Post] ISS Consulting ร่วมออกบูธในงาน Dell Technologies Forum 2019

จบไปแล้วสำหรับงาน Dell Technologies Forum 2019 ซึ่งจัดขึ้นที่ ชั้น 2 ภิรัชฮอลล์ ศูนย์นิทรรศการและการประชุมไบเทค (BITEC) บางนา โดยในปีนี้ ISS Consulting นำ 2 โซลูชั่นที่น่าสนใจของ SAP มาเสนอในงาน

เปิดตัว Dell EMC PowerOne ระบบ Autonomous Infrastructure สำหรับธุรกิจองค์กร

Autonomous Infrastructure นั้นได้เริ่มกลายเป็นเทรนด์หลักสำหรับ Converged Infrastructure ไปแล้ว และล่าสุดนี้ Dell EMC เองก็ได้ออกมาประกาศเปิดตัว Dell PowerOne โซลูชัน Autonomous Infrastructure จาก Dell EMC ที่ได้ผสานเอาทั้ง Dell EMC PowerEdge, Dell EMC PowerSwitch, Dell EMC PowerMax และ Dell EMC PowerProtect เอาไว้ในหนึ่งเดียว