ทำความเข้าใจรูปแบบในการสร้าง resilience architecture และ trade-off เพื่อตัดสินใจสร้าง architecture ที่มีประสิทธิภาพบนคลาวด์

การออกแบบ workload บนคลาวด์ให้ resilience อีกนัยหนึ่งคือทำให้มีความทนทานต่อความล้มเหลว หรือมีความยืดหยุ่นแม้จะเกิดเหตุไม่คาดฝันนั้น เราจะต้องประเมินหลายปัจจัยประกับกัน เพื่อให้ architecture ที่ได้นั้นเหมาะสำหรับ workload ที่เราต้องการใช้งาน

บทความนี้แปลมาจาก Understand resiliency patterns and trade-offs to architect efficiently in the cloud โดยคุณ Haresh Nandwani, คุณ Lewis Taylor, และคุณ Bonnie McClure

ในองค์กรหนึ่งๆ แม้จะมีการใช้งาน application หลายตัว แต่ความสำคัญของแต่ละ application ก็ไม่เท่ากัน ดังนั้นแต่ละ application ก็จะมีความต้องการความยืดหยุ่น, มีความซับซ้อน หรือค่าใช้จ่ายที่ไม่เท่ากัน เรามีทางเลือกในการออกแบบมากมาย แต่ทางเลือกไหนล่ะ ที่เหมาะสม workload ของเรามากที่สุด? และเราควรจะพิจารณาจากจุดไหนให้เหมาะสำหรับ application มากที่สุด? เรามาลองพิจารณาไปพร้อมกันในบทความนี้ค่ะ

สำหรับคำถามดังกล่าวนั้นเราสามารถหาคำตอบได้ โดยเริ่มต้นจากในภาพที่ 1 ซึ่งแสดงให้เห็นภาพรวมของ resilience 5 รูปแบบด้วยกัน ซึ่งในแต่ละรูปแบบจะส่งผลกระทบในมุมมองต่างๆ แตกต่างกัน ไม่ว่าจะเป็นด้านความซับซ้อนของการออกแบบ, ต้นทุน, การดำเนินงาน, ความปลอดภัย, รวมถึงด้านสิ่งแวดล้อม ดังนั้นเราจึงควรพิจารณาในแต่ละมุมมองและเลือกรูปแบบที่เหมาะสมสำหรับ workload ของเรามากที่สุด ทั้งนี้ทั้งนั้นภาพดังกล่าวเป็นการแสดงให้ภาพรวมของแต่ละรูปแบบเท่านั้น สำหรับรายละเอียดเพิ่มเติม เราจะกล่าวถึงในลำดับถัดไปค่ะ

Note: สำหรับการตัดสินใจเลือกใช้งาน เราไม่จำเป็นต้องเลือกรูปแบบใดรูปแบบหนึ่งเท่านั้น เราสามารถ implement หลายรูปแบบร่วมกันก็ได้

ภาพที่ 1. Resilience patterns and trade-offs

Resiliency คืออะไร? และมีความสำคัญอย่างไร?

ใน AWS Well-Architected Framework ได้นิยามคำว่า resilience ไว้ว่า “ความสามารถในการฟื้นคืนสู่สภาวะปกติ เมื่อมี load หรือ request จำนวนมาก, เมื่อถูกโจมตี (ไม่ว่าจะเกิดจากความตั้งใจ หรือไม่ได้ตั้งใจก็ตาม) และเมื่อเกิดการล้มเหลวจาก component ใด component หนึ่งของตัว workload

ซึ่งการ design workload ให้มี resilience และตอบโจทย์ทางธุรกิจนั้น เราควรพิจารณาจากปัจจัยหลักดังต่อไปนี้

• Design complexity – แต่ละ component นั้นควรมีความสามารถในการฟื้นตัว และเราควรที่จะกำจัด single point of failure ไม่ว่าจะเป็นในด้านเทคโนโลยี, บุคลากร, หรือแม้กระทั่งขั้นตอนการทำงาน ซึ่งโดยทั่วไปเมื่อมีระบบมี component เพิ่มมากขึ้น ก็มักจะส่งผลให้ระบบมีความซับซ้อนมากขึ้นตามกันไปด้วย ดังนั้นเราควรจะพิจารณาความต้องการหรือความจำเป็นในเรื่อง resilience ของแต่ละระบบของเราให้ดี และตัดสินใจว่าควรจะเพิ่มความซับซ้อนของระบบเพื่อให้ระบบมีความยืดหยุ่นและมีผลลัพธ์ที่ดี หรือจะเลือกทางที่เรียบง่าย และใช้แผน disaster recovery (DR) ก็เพียงพอแล้ว
• Cost to Implement – เมื่อเราเลือก implement ให้ระบบมีความยืดหยุ่นมากขึ้น ต้นทุนก็มักจะสูงขึ้นตามกันไปด้วย ไม่ว่าจะเกิดจากค่า software ใหม่ๆ หรือ infrastructure component ที่ใช้ในการ operate ทั้งนี้เราไม่ควรพิจารณาแค่ต้นทุนเพียงอย่างเดียว เราควรจะต้องคำนึงถึงมูลค่าความสูญเสียที่อาจจะเกิดขึ้นในอนาคตถ้าหากระบบเราไม่มี resilience ที่เพียงพอด้วย
• Operational effort – หากเราต้องการให้ระบบของเรามี resilience ในระดับสูง สิ่งที่ตามมาคือความซับซ้อนในการบริหารจัดการ และ operational process อีกทั้งยังต้องตั้งใช้ผู้เชี่ยวชาญในการบริหารจัดการอีกด้วย ดังนั้นก่อนที่จะตัดสินใจ design หรือ implement resilience architecture แบบใด เราก็ควรที่จะประเมินความซับซ้อนของ operation ด้วยว่าเรามี process อื่นๆที่เพียงพอที่จะจัดการต่อไหม หรือความรู้ความสามารถของทีมงานมีความพร้อมหรือไม่
• Effort to secure – แม้ว่า resilience นั้นอาจจะไม่ได้ส่งผลโดยตรง หรือเพิ่มความซับซ้อนในด้านความปลอดภัยมากนัก แต่อย่างไรก็ดียิ่งระบบของเรา resilience มากยิ่งขึ้น ก็ย่อมต้องมี component ที่เราจะต้องดูแลให้มีความปลอดภัยมากขึ้นตามไปด้วยเช่นกัน ซึ่งในกรณีที่เราออกแบบหรือ deploy ระบบบน cloud ตาม security best practices แล้วนั้น ก็ย่อมทำให้ระบบของเรามีความปลอดภัย โดยที่ไม่ได้เพิ่มความซับซ้อนในการจัดการถึงแม้ว่าจะมีจำนวน component ที่ต้องดูแลมากขึ้นก็ตาม
• Environmental Impact – เมื่อเราเพิ่ม component ในระบบมากขึ้น เพื่อให้ระบบของเรามี resilience ที่สูงขึ้นนั้น ก็ย่อมมีการใช้งาน resource บน cloud เพิ่มมากขึ้น ซึ่งก็จะส่งผลกับสิ่งแวดล้อมด้วยเช่นเดียวกัน ดังนั้นเราสามารถนำ AWS Well-Architected Sustainability Pillar ซึ่งเป็น best practice ในด้าน sustainability มาเป็นแนวทางในการประเมินเรื่องความยั่งยืนก่อนที่จะเลือกใช้งาน resilience pattern ก็ได้

Pattern 1 (P1): Multi-AZ

P1 เป็น cloud-based architecture (รูปที่ 2) ที่ใช้ประโยชน์จาก Availability Zones (AZs) เพื่อทำให้ระบบของเรามี resilience ที่สูงยิ่งขึ้น โดยใน P1 นั้น application จะสามารถทำงานอยู่มากกว่าหนึ่ง AZ ภายใน AWS Region เดียวกัน ซึ่งจะช่วยให้ application สามารถทำงานได้ถึงแม้ว่าจะมีปัญหาในระดับ AZ ก็ตาม

จากภาพที่ 2 เป็นตัวอย่างของ internal application ที่มีการใช้งานภายใน ซึ่งมีผลกระทบกับธุรกิจไม่สูง และความต้องการด้าน resiliency ก็ไม่สูงเช่นกัน ดังนั้นจึงมีการ deploy Amazon Elastic Compute Cloud (Amazon EC2) เพียงแค่ 1 instance เท่านั้น และได้มีการตั้งค่า Auto scaling group เอาไว้ โดยให้สามารถทำได้งานได้ 2 AZ และให้ User เรียกใช้งานผ่าน Load balancer ซึ่ง Amazon EC2 จะมี health check ในการตรวจสอบสถานะของเครื่องอยู่ ถ้าหาก AZ fail Amazon EC2 Auto Scaling group ก็จะ recreate ตัว application ขึ้นมาใหม่ใน AZ ที่ไม่มีผลกระทบโดยอัตโนมัติ

ภาพที่ 2. Multi-AZ deployment pattern (P1)

Trade-offs

ถ้าลองดูจากตารางสรุปในภาพที่ 1 จะเห็นได้ว่า P1 นั้นถูกประเมินในอยู่ในระดับต่ำทั้ง 5 ด้าน ทั้งในด้าน design complexity, cost to implement, operational effort, effort to secure และ environment impact แต่ก็ต้องแลกมาด้วยผลกระทบของผู้ใช้งานในระหว่างที่ application recovery กล่าวคือ application มีการ deploy Amazon EC2 เพียงแค่ 1 instance ดังนั้นเมื่อ AZ down จะส่งผลกระทบกับ user ทำให้ user ไม่สามารถใช้งาน application ได้ ในขณะที่กำลัง re-provisioned resource ใน AZ ใหม่นั่นเอง

Pattern 2 (P2): Multi-AZ with Static stability

P2 คือการ deploy หลายๆ instance กระจายไว้ในหลาย AZ ภายใน Region เดียวกัน เพื่อเพิ่มระดับความยืดหยุ่นให้กับระบบของเราและป้องกันผลกระทบกับ user เราควรที่จะวางแผนให้มีจำนวนของ resource ให้เพียงพอในการรองรับ request แม้ในขณะเกิด disruption

จากตัวอย่างในภาพที่ 3 เป็นตัวอย่าง architecture ของเว็บไซต์ที่ให้ลูกค้าเข้ามาใช้งาน ซึ่งมีลูกค้าเข้ามาใช้งานตลอดเวลา หากเว็บไซต์ล่มจะส่งผลกระทบกับรายได้ของบริษัทโดยตรง ซึ่งเป็นเว็บไซต์ที่ของเราจำเป็นต้องใช้ Amazon EC2 อย่างน้อง 2 instance ในการรองรับ request ในช่วงเวลาทั่วไป ซึ่งจาก architecture นี้มีการวาง Amazon EC2 4 instance วางกระจายอยู่ใน 2 AZ โดยให้ user เรียกเข้าใช้งานผ่าน Elastic Load Balancer (ELB) โดยที่ตัว ELB จะมี health check ในการมอนิเตอร์และกระจาย traffic  ซึ่งจาก design นี้จะเห็นได้ว่าหากเกิด disruption ที่ AZ ใด AZ หนึ่ง ก็ยังคงมี resource เพียงพอในการรองรับ request ทั้งหมด โดยที่ health check ของ ELB จะจัดการ traffic ให้ส่งไปยังเครื่องที่อยู่ในสถานะที่พร้อมใช้งานแล้วเท่านั้น

เราสามารถศึกษาวิธีการ Implementing health checks จากบทความใน Amazon Builder’s Library ได้ค่ะ.

ภาพที่ 3. Multi-AZ with static stability pattern (P2)

Trade-offs

P2 สามารถช่วยในกรณีที่เกิด AZ disruption โดยที่ไม่มีผลกระทบกับ client แต่ก็ต้องแลกมาด้วยต้นทุนหรือค่าใช้จ่ายที่เพิ่มสูงขึ้น เมื่อเทียบกัน P1 นั้นจะมีต้นทุนด้าน infrastructure ที่ต่ำกว่า ซึ่งการ implement P2 นั้น application ของเราจะต้องรองรับรองการทำงานแบบหลาย instance ร่วมกันได้ ซึ่งถ้า application สามารถรองรับได้นั้น เราสามารถ deploy workload ไปยังทุกๆ AZ ที่พร้อมใช้งานใน Region ที่ต้องการได้ทันที (ในแต่ละ Region จะมีอย่างน้อย 3 AZ พร้อมให้บริการ) ยิ่งเมื่อเรา provision workload ในหลาย AZ ก็จะช่วยลดต้นทุนในการ over-provisioning ได้ ยกตัวอย่างเช่นในภาพที่ 3 application ของเราจำเป็นต้องใช้ Amazon EC2 เพียงแค่ 2 instance เพื่อเพิ่มความยืดหยุ่นตามรูปแบบ P2 ถ้าเราวาง application ใน 2 AZ เราจะต้อง provision Amazon EC2 ทั้งหมด 4 instances (200%) ในขณะที่ถ้าเราใช้งาน 3 AZ เราสามารถ provision เพียงแค่ AZ ละ 1 instance (150%) ก็เพียงพอแล้ว เป็นต้น

Pattern 3 (P3): Application Portfolio Distribution

ในรูปแบบนี้เป็นการใช้งาน Multi-Region ในการเพิ่มความยืดหยุ่น โดยมีการกระจาย application ที่แตกต่างกัน ไปใช้งานยัง Region ที่ต่างกัน

ตัวอย่างเช่น บริษัทผู้ให้บริการทางการเงินแห่งหนึ่ง มีช่องทางในการให้บริการลูกค้าหลากหลายช่องทาง ไม่ว่าจะเป็น mobile application, contact center และ web-based application ซึ่งจากภาพที่ 4 จะเห็นได้ว่าบริษัทตัวอย่างได้ deploy web-based application ไปยัง Region A ในขณะที่ Mobile App อยู่ที่ Region B

จากตัวอย่าง ถ้าเกิดเหตุ disruption ที่ Region B ที่ mobile application ทำงานอยู่จนส่งผลให้ ลูกค้าไม่สามารถใช้งาน mobile application ได้นั้น ลูกค้าก็ยังมีช่องทางในการใช้งานผ่าน web-based application ซึ่งทำงานอยู่ในอีก Region หนึ่งแทนได้ ถึงแม้ว่าเหตุการณ์ที่ทำให้ Regional service ไม่สามารถให้บริการได้จะเกิดขึ้นได้ยาก แต่การ implement ในรูปแบบนี้ก็ถือเป็นการเตรียมความพร้อม และทำให้มั่นใจได้ว่า เรายังสามารถให้บริการ application ที่มีความสำคัญต่อธุรกิจต่อไปได้ ในขณะที่เกิด disruption นั่นเอง

ภาพที่ 4. Application portfolio distribution pattern (P3)

Trade-offs

P3 จะช่วยลดผลกระทบที่เกิดจากเหตุการณ์ที่ regional service ไม่สามารถให้บริการได้ โดยจะช่วยให้ระบบทั้งหมดของเราไม่มีปัญหาพร้อมกันทั้งหมด แต่สิ่งที่ต้องแลกมาคือการบริหารจัดการ application portfolio ที่ต้องกระจายตัวไปยังหลาย Region ซึ่งจะต้องอาศัยการวางแผน operation และการบริหารจัดการอย่างดี ซึ่งบาง application อาจจะยังมีข้อจำกัดบางอย่างทำให้ไม่สามารถแยกส่วนกันได้เด็ดขาดเช่น บาง function จำเป็นต้องใช้ระบบหลังบ้านร่วมกัน หรือต้องใช้ข้อมูลชุดเดียวกัน ซึ่งระบบหรือข้อมูลดังกล่าวถูก deploy อยู่ใน Region เดียวเป็นต้น ในกรณีนี้เหตุความขัดข้องในระดับ Region ก็จะส่งผลกระทบกับระบบของเราได้ แต่การ implement pattern นี้ก็จะช่วยลดพื้นที่ที่ได้รับผลกระทบได้เช่นกัน

Pattern 4 (P4): Multi-AZ deployment (multi-Region DR)

ในกรณีที่เราต้องดูแล service ที่มีความสำคัญของธุรกิจจำนวนมาก และ ซึ่งเราไม่ต้องการให้เกิดความขัดข้องในการให้บริการ service เหล่านั้น เราสามารถพิจารณาการทำ DR เป็นหนึ่งในทางเลือกในการเพิ่มความยืดหยุ่นได้ โดยรูปแบบในการทำ DR นั้นประกอบด้วย 4 รูปแบบด้วยกัน (ดังที่ได้ระบุไว้ใน Disaster Recovery of Workloads on AWS: Recovery in the Cloud) แต่สำหรับ P4 เราจะพูดถึง 2 รูปแบบย่อยสำหรับการสร้าง multi-Region application ดังนี้

• Pilot Light – ในรูปแบบนี้จะมีการ replicate ข้อมูล รวมถึงมีการ pre-provision ตัว application infrastructure รอไว้ที่ Region ที่ต้องการใช้เป็น DR ซึ่งในรูปแบบนี้จะช่วยให้เราสามารถ optimize ค่าใช้จ่ายได้ เนื่องจาก application infrastructure ที่ DR นั้นจะถูกปิดไว้ และจะถูกเปิดขึ้นมาก็ต้องเมื่อมีความจำเป็นต้องกู้คืนระบบเท่านั้น
• Warm Standby – ในรูปแบบนี้จะช่วยลดเวลาในการกู้คืนระบบเมื่อเทียบกับ pilot light โดยเราจะรัน application ในด้วย capacity ที่จำกัดไว้ที่ DR Region ซึ่งเมื่อเกิดเหตุขัดข้องขึ้นที่ Region หลัก เราก็สามารถเพิ่ม capacity ที่ DR ได้แบบอัตโนมัติ และสามารถลดการจัดการแบบ manual ได้ ซึ่งเราสามารถนำรูปแบบนี้ไป implement เพื่อตอบสนองกับความต้องการ RPO/RTO ในระดับหลักนาทีได้

Trade-Offs

P4 จะช่วยลดผลดกระทบที่เกิดจากเหตุขัดข้องที่เกิดกับ regional service ในขณะที่สามารถจัดค่าใช้จ่ายในการจัดการได้ อย่างไรก็ดีการทำ DR ข้าม Region นั้นก็ส่งผลให้ระบบของเรามีความซับซ้อนเพิ่มมากขึ้น เนื่องจากต้องมีการ synchronize ทุกๆการเปลี่ยนแปลงไปยัง Region DR การจำลองสถานการณ์ที่เกิดเหตุขัดข้องที่ Region และการทดสอบการทำงานของ application ที่ DR ก็เป็นอีกหนึ่งส่วนที่ทำให้เพิ่มความซับซ้อนให้กับการจัดการ ในกรณีนี้การใช้งาน Infrastructure as a Code ก็เป็นทางเลือกที่ช่วยทำให้เกิด automate deployment หรือลดขั้นตอนการทำงานแบบ manual ได้

Pattern 5 (P5): Multi-Region active-active

สำหรับระบบที่มีความสำคัญของธุรกิจ และไม่สามารถเกิดเหตุขัดข้องได้นั้น P5 ก็ถือเป็นทางเลือกหนึ่งสำหรับระบบดังกล่าว ตัวอย่างเช่น บริษัทให้บริการทางการเงินแห่งหนึ่งมีระบบ core banking เป็นหัวใจของธุรกิจ โดยที่ application ดังกล่าวต้องสามารถให้บริการได้ตลอดเวลา ห้ามเกิดเหตุขัดข้องเด็ดขาด จากภาพที่ 5 จะเห็นได้ว่า application ดังกล่าวถูก deploy และให้ทำงานคู่ขนานกันใน 2 Region โดยที่ User จะสามารถเรียกใช้งาน application ได้จากทั้งสอง Region ซึ่งการ implement ในรูปแบบนี้จะช่วยลดผลกระทบที่เกิดจากความขัดข้องในระดับ Region ได้ และสามารถตอบโจทย์สำหรับ application ที่ไม่สามารถเกิดเหตุขัดข้องได้อย่างเด็ดขาด

ภาพที่ 5. Multi-Region active-active pattern (P5)

Trade-offs

P5 จะช่วยลดผลกระทบที่เกิดจากความขัดข้องในระดับ regional service ซึ่งเพื่อให้ตอบโจทย์ RTO ที่ใกล้เคียงศูนย์ ก็จะต้องแลกมาด้วยค่าใช้จ่าย และความซับซ้อนของระบบที่เพิ่มสูงขึ้น การ implement ในรูปแบบนี้จะต้องคำนึงถึงการทำ asynchronous replication สำหรับข้อมูลระหว่าง Region รวมถึงความสอดคล้องของข้อมูลอีกด้วย

เนื่องจากระบบมีความซับซ้อน ดังนั้นการจัดการในรูปแบบนี้ต้องอาศัยความเชี่ยวชาญและ process ที่แม่นยำ ดังนั้นหากเราต้องการ implement ใน pattern นี้ เราขอแนะนำให้คุณค่อยๆสร้างโดยการปรับใช้ pattern อื่นๆที่ได้อธิบายไว้ก่อนหน้านี้

บทสรุป

ในบทความนี้เราได้แนะนำ 5 resilience pattern รวมถึงข้อดีข้อเสียในแต่ละ pattern เพื่อช่วยในการตัดสินใจเลือกใช้งานแต่ละ pattern ให้เหมาะสมกับ application ของคุณได้ดียิ่งขึ้น