อย่างปกติที่เราสร้างระบบคลาวด์ เรามักจะ Setup ด้วยแนวทางปฏิบัติพื้นฐานที่ควรทำ อย่างเช่น ไมโครเซอร์วิสและความพร้อมใช้งานสูง (high availability) ก็อาจถือว่าเพียงพอแล้ว แต่… จะเกิดอะไรขึ้นหากมีเหตุการณ์ที่ไม่คาดฝันเกิดขึ้น ? เราจะจัดการกับความล้มเหลวที่เกิดกับบริการที่สำคัญๆ หรือการ Fail Over (แก้สถานการณ์จากความเสียหายที่เกิดขึ้น) ได้อย่างไร ?
เพราะหลักการพื้นฐานนั้นไม่ได้มีมุมมองด้าน Resiliency หรือความยืดหยุ่นของระบบเพื่อรับกับเหตุไม่คาดฝันไว้ด้วย มองว่าทำทีหลังก็ได้ แต่ถ้าความเสียหายเกิดไปแล้ว จะกู้กลับได้ทันหรือเปล่า ? นี่จึงเป็นประเด็นสำคัญมาก เพราะแม้ว่าการหยุดระบบในระยะเวลาสั้นๆ อาจไม่ส่งผลกระทบมากนักในกลุ่มธุรกิจขนาดเล็ก แต่พอเป็นสเกลงานขนาดใหญ่ หยุดเพียงแป๊บเดียว นั่นอาจหมายถึงความสูญเสียมหาศาล เช่น เสียโอกาสในการทำธุรกรรมหลายพันรายการจนทำไปสู่การขาดรายได้นับล้านบาท
การทดสอบเชิง Performance vs. การทดสอบเชิง Resiliency
การทดสอบประสิทธิภาพ (Performance) เป็นขั้นตอนมาตรฐาน แต่การทดสอบความยืดหยุ่น (Resiliency) มักถูกละเลย โดยส่วนหนึ่งอาจเพราะเราไม่ได้ตั้งถามคำถามที่สำคัญ อย่างเช่น
- ถ้าเกิดเหตุล้มเหลวภายใน service instance จะส่งผลกระทบต่อระบบของเราอย่างไรบ้าง
- RabbitMQ แบบคลัสเตอร์ของเราจะเข้าสู่โหมด Fail Over ตามที่ออกแบบไว้หรือไม่
กลุ่มข้อกังวลในระดับโครงสร้างพื้นฐาน (infrastructure-level) เหล่านี้สมควรถูกจัดลำดับความสำคัญในการตัดสินใจมากพิเศษ เพื่อความมั่นใจว่าเราจะได้วางแผนรองรับไว้ล่วงหน้า กรณีมีเหตุการณ์ที่อาจไม่คาดฝันเกิดขึ้นมาจริงๆ สักวันหนึ่ง
บทเรียนจากฝั่ง AWS: สถาปัตยกรรมแบบเซลล์ (Cell-Based) เพื่อความยืดหยุ่นที่ปรับขนาดได้
หนึ่งในเซสชันของอีเว้นต์ AWS re:Invent 2023 ในหัวข้อ [AWS re:Invent 2023 – Resilient architectures at scale: Real-world use cases from Amazon.com] ได้กล่าวถึง Resiliency ในระบบขนาดใหญ่อย่างเว็บไซต์อีคอมเมิร์ซ Amazon.com โดย AWS ได้วางสถาปัตยกรรมแบบแบ่งเซลล์ (Cell-Based) เพื่อกันความล้มเหลวไปกระทบทั้งระบบ โดยจะแยกระบบ (isolate) เป็นส่วนๆ ในแต่ละเซลล์เป็น stack พร้อมใช้ที่ครบครัน คล้ายกับระบบหลายภูมิภาค/หลายคลัสเตอร์ โดยมีเราเตอร์เซลล์ทำหน้าที่เป็นตัวกลางในการรับส่ง traffic/policy ทำให้คลัสเตอร์ที่มีความผิดพลาดบางอย่างไม่ก่อผลกระทบให้ทั้งระบบล่ม เนื่องจากมีเซลล์อื่นสลับทำหน้าที่แทนได้เสมอ
แม้ว่าระบบปัจจุบันของหลาย Use Case อาจยังไม่ต้องการความซับซ้อนในระดับนี้ แต่การทำความเข้าใจแนวทางดังกล่าวก็น่าจะเป็นประโยชน์สำหรับนำไปใช้ในอนาคตที่ใหญ่ขึ้น
สรุป
การจะทำให้ระบบของเรานั้นมีความยืดหยุ่น (Resiliency) ต่อความไม่แน่นอนต่างๆ ได้นั้นเป็นการเดินทางที่ต้องดำเนินต่อไปเรื่อย ๆ เป็นเรื่องที่มีปัจจัยระหว่างทางให้พิจารณา ไม่ใช่สิ่งที่จะมุ่งสู่จุดหมายปลายทางเพียงครั้งเดียวจบ ด้วยการทดสอบอย่างสม่ำเสมอ ประกอบกับการตั้งคำถามบ่อยๆ จนเป็นกิจวัตร และอัปเดตเทรนด์และทริคในด้านนี้อยู่เสมอ เราจะสามารถสร้างระบบที่สามารถทนทานต่อสถานการณ์และความท้าทายที่ไม่คาดคิดได้อย่างสม่ำเสมอแน่นอน
… … …
ติดตามข้อมูลข่าวสารและกิจกรรมของเราได้ที่ช่องทาง Facebook Fanpage, Linkedin หรือดูข้อมูลและติดต่อรับคำปรึกษาได้ที่เว็บไซต์ของเรา
