เลือกแนวทางความพร้อมใช้งานข้าม zone และ region

เริ่มจากการทำงานของผู้ใช้

High availability (HA) มีเป้าหมายให้บริการยังใช้งานได้แม้ component ขัดข้อง กำหนดความหมายของคำว่าใช้งานได้ก่อนเลือกสถาปัตยกรรม หน้าจองที่โหลดได้แต่คำขอจองทั้งหมดล้มเหลว ไม่ใช่บริการจองที่พร้อมใช้งาน

ตั้ง service level objective (SLO) สำหรับการทำงานที่สำคัญ กำหนดว่าคำขอใดอยู่ในการวัด ความสำเร็จหมายถึงอะไร และวัดในช่วงใด SLA ของบริการ cloud อธิบายข้อผูกพันของผู้ให้บริการรายนั้น ไม่ได้ยืนยันความพร้อมใช้งานที่วัดได้ของแอปพลิเคชันคุณ

ตัวอย่างเช่น ความพร้อมใช้งานตามเวลา 99.9% ยอมให้ใช้งานไม่ได้ 43.2 นาทีในเดือนที่มี 30 วัน SLO ที่วัดตามคำขอใช้ตัวหารต่างกัน ทั้งสองแบบไม่ได้ระบุว่าข้อมูลสูญหายได้มากเพียงใด และไม่ได้รับประกันระยะเวลาสูงสุดของ outage แต่ละครั้ง

เข้าใจขอบเขตความขัดข้อง

AWS Availability Zone (AZ) คือที่ตั้งโครงสร้างพื้นฐานที่แยกจากกันภายใน Region หนึ่ง Region มีหลาย AZ การออกแบบ multi-region กระจาย component ของ workload ไปหลาย Region ผู้ให้บริการรายอื่นมีขอบเขตและพฤติกรรมของบริการต่างกัน ให้ตรวจสอบบริการที่เลือก

สิ่งเหล่านี้เป็นความเป็นไปได้ในการออกแบบ ไม่ใช่คำรับประกันความพร้อมใช้งาน ชื่อเรียกไม่ได้พิสูจน์ว่า component ที่จำเป็นทุกส่วนใช้ขอบเขตตามที่ตั้งใจ

ติดตามเส้นทางคำขอทั้งหมด

พิจารณาบริการจองในสถานการณ์สมมติ Web replica ทำงานในสอง AZ ทั้งคู่ใช้ฐานข้อมูลเดียวและ outbound gateway เดียวใน AZ A ต้องใช้ gateway เพื่อเรียกผู้ให้บริการชำระเงิน

หาก AZ A ขัดข้อง web replica ใน AZ B อาจยังทำงานปกติ แต่การจองยังล้มเหลว ทีมต้องประเมินฐานข้อมูล เส้นทางเครือข่าย ผู้ให้บริการตัวตน dependency ด้านการชำระเงิน และ routing ตรวจสอบโหมดจริงของ managed database เพราะ replication, failover และพฤติกรรมการอ่านต่างกันตามผลิตภัณฑ์และการกำหนดค่า

ตรวจสอบความจุด้วย ทรัพยากรที่เหลือต้องรองรับโหลดที่กำหนด การออกแบบที่พึ่งการสร้างความจุระหว่าง incident จะขึ้นอยู่กับ quota ทรัพยากรที่มี และการทำงานของ control plane

จัดการฝึกที่ควบคุมได้ โดยกำหนดขอบเขต เงื่อนไขหยุด และผู้รับผิดชอบ ตรวจสอบการจองจนจบ รวมถึงการกระทบยอดการชำระเงิน บันทึกคำขอที่ล้มเหลวและเวลาที่ใช้กู้คืนการทำงานที่ใช้งานได้จริง

ตัดสินใจว่า Region เพิ่มเติมแก้ปัญหาได้หรือไม่

การดำเนินงานแบบ multi-region เพิ่มการโอนข้อมูล ทรัพยากรซ้ำ การประสาน deployment และงานดำเนินการ Active/passive เตรียมสภาพแวดล้อมหนึ่งให้พร้อมรับ traffic ส่วน active/active ให้บริการ traffic ในมากกว่าหนึ่งสภาพแวดล้อม ระดับความพร้อมและพฤติกรรมข้อมูลที่ต้องการต่างกัน

สำหรับบริการจอง การเขียนข้อมูลพร้อมกันทำให้ต้องถามว่า สอง Region ขายที่นั่งเดียวกันได้หรือไม่? กำหนดว่าใครมีอำนาจตัดสินการจอง และระบบทำงานอย่างไรเมื่อ replication ถูกขัดจังหวะ “ทำ replication ฐานข้อมูล” ยังไม่ใช่คำตอบที่ครบถ้วน

ตรวจสอบสถานที่เก็บข้อมูลที่อนุญาต encryption key, certificate, DNS, secret และบริการภายนอก บริการตัวตนร่วมที่ล่มหรือ release ที่มีปัญหาอาจกระทบหลาย Region การเพิ่มสถานที่ไม่ได้ขจัดสาเหตุร่วมทุกอย่าง

เชื่อมโยงความพร้อมใช้งานกับการกู้คืน

HA จัดการความขัดข้องที่กำหนดระหว่างดำเนินงาน Disaster recovery กู้คืนบริการให้ใช้งานได้พร้อมข้อมูลหลังเหตุการณ์ที่รบกวนการทำงาน บริการแบบ multi-region ยังต้องมีแผนกู้คืนเมื่อข้อมูลถูกลบหรือเสียหาย

บันทึกสถานการณ์ความขัดข้องที่เลือกจัดการและสถานการณ์ที่ธุรกิจยอมรับ ปรับ test และนิยามโครงสร้างพื้นฐานให้สอดคล้องกันเมื่อแอปพลิเคชันเปลี่ยน เรียนต่อเรื่อง RTO, RPO และ disaster recovery