ความเสถียรคงที่โดยใช้ Availability Zone

ที่ Amazon บริการที่เราสร้างจะต้องตอบสนองเป้าหมายด้านความพร้อมในการใช้งานที่สูงมาก ซึ่งหมายความว่าเราจำเป็นต้องพิจารณาอย่างระมัดระวังเกี่ยวกับการขึ้นต่อกันที่ระบบของเราใช้ เราออกแบบระบบของเราให้ยังคงฟื้นตัวได้ แม้ในเวลาที่การขึ้นต่อกันเหล่านั้นได้รับความเสียหาย ในบทความนี้ เราจะกำหนดรูปแบบที่เราใช้ที่เรียกว่าความเสถียรคงที่ เพื่อให้ได้รับความสามารถในการฟื้นตัวในระดับนี้ เราจะแสดงให้คุณเห็นว่าเราใช้แนวความคิดนี้อย่างไรกับ Availability Zone องค์ประกอบโครงสร้างพื้นฐานหลักใน AWS ดังนั้นจึงเป็นการขึ้นต่อกันขั้นพื้นฐานอันเป็นที่สร้างบริการทั้งหมดของเรา

ในการออกแบบที่มีความเสถียรคงที่ ระบบโดยรวมจะยังคงทำงานได้แม้ว่าการขึ้นต่อกันจะเกิดความเสียหายก็ตาม บางครั้ง ระบบอาจไม่เห็นข้อมูลที่อัปเดตใดๆ (เช่น สิ่งใหม่ๆ สิ่งที่ถูกลบออก หรือสิ่งที่มีการเปลี่ยนแปลงแก้ไข) ที่การขึ้นต่อกันควรจะทำให้เกิดขึ้น อย่างไรก็ตาม ทุกสิ่งทุกอย่างที่ทำขึ้นก่อนที่การขึ้นต่อกันจะเสียหายนั้น ยังคงทำงานได้แม้ว่าจะมีการขึ้นต่อกันที่เสียหายก็ตาม เราจะอธิบายว่าเราสร้าง Amazon Elastic Compute Cloud (EC2) ให้มีความเสถียรคงที่ได้อย่างไร จากนั้น เราจะแสดงสถาปัตยกรรมตัวอย่างที่มีความเสถียรคงที่สองตัวอย่างสำหรับการสร้างระบบระดับเขตที่มีความพร้อมใช้งานสูงไว้บน Availability Zone

สุดท้าย เราจะลงรายละเอียดมากขึ้นในปรัชญาการออกแบบเบื้องหลัง Amazon EC2 รวมทั้งวิธีการออกแบบเพื่อให้ความเป็นอิสระของ Availability Zone ที่ระดับซอฟต์แวร์ นอกจากนี้ เราจะพูดถึงข้อดีข้อเสียที่มาพร้อมกับการสร้างบริการด้วยสถาปัตยกรรมประเภทนี้

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

ในกรณีที่เกิดความเสียหายต่อ Availability Zone สถาปัตยกรรมที่แสดงในผังก่อนหน้านี้ไม่ต้องมีการดำเนินการใดๆ EC2 instance ใน Availability Zone ที่เสียหายจะเริ่มล้มเหลวในการตรวจสถานะ และ Application Load Balancer จะย้ายปริมาณงานออกมาจากนั้น ความจริงแล้ว บริการ Elastic Load Balancing ได้รับการออกแบบตามหลักการนี้ โดยจัดเตรียมความจุในการจัดสมดุลปริมาณงานมากพอที่จะทนต่อความเสียหายของ Availability Zone ได้โดยไม่จำเป็นต้องขยายขนาด

นอกจากนี้ เรายังใช้รูปแบบนี้แม้ในกรณีที่ไม่มีโหลดบาลานเซอร์หรือบริการ HTTPS ตัวอย่างเช่น กลุ่ม EC2 instance ที่ประมวลผลข้อความจากคิว Amazon Simple Queue Service (SQS) สามารถทำตามรูปแบบนี้ได้เช่นกัน อินสแตนซ์เหล่านี้ถูกปรับใช้ใน Auto Scaling group ข้ามหลาย Availability Zone ที่ัจัดเตรียมเผื่อเกินไว้อย่างเหมาะสม ในกรณีของ Availability Zone ที่เสียหาย บริการไม่ต้องทำอะไรเลย อินสแตนซ์ที่ได้รับความเสียหายจะหยุดทำงาน และอินสแตนซ์อื่นจะรับงานไปทำ

เช่นเดียวกับกรณีของตัวอย่าง Active-Active แบบไม่มีสถานะ เมื่อ Availability Zone ที่มีโหนดหลักเกิดความเสียหาย บริการแบบมีสถานะจะไม่ทำอะไรกับโครงสร้างพื้นฐาน สำหรับบริการที่ใช้ Amazon RDS, RDS จะจัดการการเปลี่ยนระบบเมื่อมีข้อผิดพลาด และเปลี่ยนการชี้จุดชื่อ DNS ไปยังโหนดหลักอันใหม่ใน Availability Zone ที่กำลังทำงาน รูปแบบนี้ยังใช้กับรูปแบบ Active-Standby อื่นๆ อีกด้วย แม้ว่าจะไม่ได้ใช้ฐานข้อมูลเชิงสัมพันธ์ก็ตาม โดยเฉพาะอย่างยิ่ง เราใช้รูปแบบนี้กับสถาปัตยกรรมคลัสเตอร์ที่มีโหนดผู้นำ เราติดตั้งคลัสเตอร์เหล่านี้เพื่อปรับใช้ใน Availability Zone และเลือกโหนดผู้นำใหม่จากอินสแตนซ์สแตนด์บาย แทนที่จะเรียกใช้การเปลี่ยนแบบ “ทันเวลา”

สิ่งที่สองรูปแบบนี้มีร่วมกันก็คือทั้งคู่ได้จัดเตรียมความจุที่ต้องการไปแล้วในกรณีความเสียหายของ Availability Zone ล่วงหน้าการเกิดความเสียหายจริง ไม่มีกรณีใดเลยที่บริการใช้การขึ้นต่อกันของ Control Plane โดยจงใจ เช่น การจัดเตรียมโครงสร้างพื้นฐานใหม่ หรือการปรับเปลี่ยนใดๆ เพื่อตอบสนองต่อความเสียหายของ Availability Zone

หัวข้อสุดท้ายของบทความนี้จะลงลึกไปหนึ่งระดับของสถาปัตยกรรม Availability Zone ที่ฟื้นตัวได้ โดยครอบคลุมวิธีการบางส่วนที่เราทำตามหลักการความเป็นอิสระของ Availability Zone ใน Amazon EC2 การทำความเข้าใจแนวความคิดเหล่านี้มีประโยชน์เมื่อเราสร้างบริการที่ไม่เพียงแค่ต้องมีความพร้อมใช้งานสูงในตัวเอง แต่ยังต้องให้โครงสร้างพื้นฐานที่ส่วนอื่นๆ สามารถมีความพร้อมใช้งานสูงได้ด้วย Amazon EC2 ในฐานะที่เป็นผู้จัดหาโครงสร้างพื้นฐานของ AWS ระดับล่าง เป็นโครงสร้างพื้นฐานที่แอปพลิเคชันสามารถใช้เพื่อให้มีความพร้อมใช้งานสูงได้ มีบางครั้งที่ระบบอื่นๆ อาจต้องการนำเอากลยุทธ์นี้ไปใช้เช่นกัน

เราทำตามหลักการความเป็นอิสระของ Availability Zone ใน Amazon EC2 ในข้อปฏิบัติในการปรับใช้ของเรา ใน Amazon EC2 จะถูกปรับใช้บนเซิร์ฟเวอร์จริงที่โฮสต์ EC2 instance, อุปกรณ์ Edge, ตัวจำแนกชื่อ DNS, ส่วนประกอบของ Control Plane ในพาธการเรียกใช้ EC2 instance และส่วนประกอบอื่นๆ หลายตัวที่ EC2 instance ต้องใช้ การปรับใช้เหล่านี้เป็นไปตามปฏิทินการปรับใช้ระดับโซน ซึ่งหมายความว่าสอง Availability Zone ในเขตเดียวกันจะได้รับการปรับใช้ที่กำหนดในวันที่ต่างกัน ในทั่ว AWS เราใช้การปรับใช้ที่แบ่งออกเป็นระยะ ตัวอย่างเช่น เราทำตามข้อปฏิบัติที่ดีที่สุด (โดยไม่คำนึงถึงประเภทของบริการที่เราปรับใช้) ของการปรับใช้ครั้งแรก One-box จากนั้น 1/N ของเซิร์ฟเวอร์ ฯลฯ อย่างไรก็ตาม ในกรณีเฉพาะของบริการเช่นใน Amazon EC2 การปรับใช้ของเราจะก้าวไปอีกหนึ่งขั้น และจงใจปรับให้ตรงกับขอบเขตของ Availability Zone วิธีดังกล่าวจะทำให้ปัญหาที่มีการปรับใช้กระทบต่อ Availability Zone เดียว และถูกย้อนดำเนินการและแก้ไข โดยไม่กระทบต่อ Availability Zone อื่นๆ ซึ่งยังคงทำงานต่อไปตามปกติ

อีกวิธีที่เราใช้หลักการ Availability Zone อิสระเมื่อเราสร้างใน Amazon EC2 ก็คือ ออกแบบการเดินทางของแพ็คเก็ตทั้งหมดให้อยู่ภายใน Availability Zone แทนที่จะข้ามขอบเขต ประเด็นที่สองนี้ ซึ่งปริมาณงานของเครือข่ายถูกเก็บไว้ในเครื่องของ Availability Zone ก็สมควรสำรวจในรายละเอียดเพิ่มเติม โดยเป็นภาพอันน่าตื่นเต้นที่แสดงให้เห็นว่าเราคิดแตกต่างอย่างไร เมื่อสร้างระบบที่มีความพร้อมใช้งานสูงระดับเขต ซึ่งเป็นผู้ใช้ Availability Zone อิสระ (หมายความว่าจะใช้การรับประกันถึงความเป็นอิสระของ Availability Zone เป็นพื้นฐานสำหรับการสร้างบริการความพร้อมใช้งานสูง) ซึ่งตรงข้ามกับเมื่อเราจัดเตรียมโครงสร้างพื้นฐานอิสระของ Availability Zone ให้แก่ส่วนอื่นๆ ซึ่งจะทำให้ส่วนนั้นๆ สร้างสำหรับความพร้อมใช้งานสูงได้

ผังต่อไปนี้แสดงภาพบริการภายนอกที่มีความพร้อมใช้งานสูงตามที่แสดงเป็นสีส้ม ซึ่งต้องอาศัยบริการภายในอีกตัวตามที่แสดงเป็นสีเขียว การออกแบบที่ตรงไปตรงมาปฏิบัติกับบริการทั้งสองว่าเป็นผู้ใช้ EC2 Availability Zone อิสระ แต่ละบริการในสีส้มและสีเขียวอยู่คู่กับ Application Load Balancer และแต่ละบริการก็มีกลุ่มโฮสต์แบ็คเอนด์ที่จัดเตรียมไว้อย่างดีกระจายไปในสาม Availability Zone บริการระดับเขตที่มีความพร้อมใช้งานสูงตัวหนึ่งเรียกใช้บริการระดับเขตที่มีความพร้อมใช้งานสูงอีกตัวหนึ่ง ซึ่งเป็นการออกแบบที่เรียบง่าย และสำหรับหลายๆ บริการที่เราสร้างขึ้น เป็นการออกแบบที่ดี

อย่างไรก็ตาม สมมติว่าบริการสีเขียวเป็นบริการพื้นฐาน กล่าวคือสมมติว่าบริการดังกล่าวไม่ได้มีจุดมุ่งหมายเพื่อให้มีความพร้อมใช้งานสูงเพียงอย่างเดียว แต่ยังทำหน้าที่เป็นองค์ประกอบสำหรับการจัดเตรียมความเป็นอิสระของ Availability Zone อีกด้วย ในกรณีดังกล่าว เราอาจออกเป็นสามอินสแตนซ์ของบริการภายในโซน ซึ่งเราทำตามข้อปฏิบัติในการปรับใช้ที่รู้จัก Availability Zone แผนผังต่อไปนี้แสดงให้เห็นการออกแบบที่บริการระดับเขตที่มีความพร้อมใช้งานสูงเรียกใช้บริการระดับโซนที่มีความพร้อมใช้งานสูง

เหตุผลที่เราออกแบบบริการองค์ประกอบของเราให้เป็นอิสระจาก Availability Zone มาจากการคำนวณง่ายๆ สมมติว่า Availability Zone หนึ่งได้รับความเสียหาย สำหรับความล้มเหลวที่เห็นได้ชัด Application Load Balancer จะย้ายจากโหนดที่ได้รับผลกระทบโดยอัตโนมัติ อย่างไรก็ตาม ความล้มเหลวไม่ได้เห็นได้ชัดอย่างนั้นทั้งหมด อาจมีความล้มเหลวที่ก้ำกึ่ง เช่น จุดบกพร่องในซอฟต์แวร์ ซึ่งโหลดบาลานเซอร์จะมองไม่เห็นการตรวจสอบสถานะและจัดการอย่างเรียบร้อยได้

ในตัวอย่างก่อนหน้า ซึ่งบริการระดับเขตที่มีความพร้อมใช้งานสูงตัวหนึ่งเรียกใช้บริการระดับเขตที่มีความพร้อมใช้งานสูงอีกตัวหนึ่ง หากมีการส่งคำขอผ่านทางระบบ ด้วยสมมติฐานแบบง่ายๆ โอกาสของคำขอที่เลี่ยง Availability Zone ที่เสียหายคือ 2/3 * 2/3 = 4/9 หมายความว่าคำขอนั้นมีโอกาสเสียมากกว่าได้ที่จะแก้ไขปัญหานั้นสำเร็จ ในทางตรงข้าม หากเราสร้างบริการสีเขียวให้เป็นบริการระดับโซนเช่นในตัวอย่างปัจจุบัน โฮสต์ในบริการสีส้มจะสามารถเรียกใช้ตำแหน่งข้อมูลสีเขียวใน Availability Zone เดียวกันได้ ด้วยสถาปัตยกรรมนี้ โอกาสในการเลี่ยง Availability Zone ที่เสียหายจึงเป็น 2/3 ถ้าบริการ N รายการเป็นส่วนหนึ่งของพาธการเรียกใช้นี้ ตัวเลขเหล่านี้ก็จะสรุปเป็น (2/3)^N สำหรับบริการระดับเขต N รายการเทียบกับค่าคงที่ที่เหลืออยู่ 2/3 สำหรับบริการระดับโซน N รายการ

ด้วยเหตุผลดังกล่าว เราจึงสร้างเกตเวย์ Amazon EC2 NAT เป็นบริการระดับโซน เกตเวย์ NAT เป็นคุณสมบัติของ Amazon EC2 ที่อนุญาตให้มีการส่งข่อมูลผ่านอินเทอร์เน็ตขาออกจากซับเน็ตส่วนตัว และไม่ปรากฏเป็นเกตเวย์ที่ใช้ทั่ว VPC ระดับเขต แต่เป็นทรัพยากรระดับโซน ซึ่งลูกค้าสร้างอินสแตนซ์ต่างหากตาม Availability Zone ตามที่แสดงในแผนผังต่อไปนี้ เกตเวย์ NAT ตั้งอยู่ในพาธของการเชื่อมต่ออินเทอร์เน็ตสำหรับ VPC ดังนั้นจึงเป็นส่วนของ Data Plane ของ EC2 instance ใดๆ ภายใน VPC นั้น หากมีความเสียหายในการเชื่อมต่อในหนึ่ง Availability Zone เราจะต้องการเก็บความเสียหายนั้นไว้ภายใน Availability Zone นั้น แทนที่จะแพร่ออกไปยังโซนอื่นๆ ในตอนสุดท้าย เราต้องการลูกค้าที่สร้างสถาปัตยกรรมคล้ายคลึงกับที่กล่าวมาข้างต้นในบทความนี้ (หมายความว่า การจัดเตรียมกลุ่มข้ามสาม Availability Zone ที่มีความจุเพียงพอในสองโหนดใดๆ ที่จะรับปริมาณงานทั้งหมดได้) เพื่อให้ทราบว่า Availability Zone อื่นๆ จะไม่ได้รับผลกระทบโดยสิ้นเชิงจากสิ่งใดก็ตามที่เกิดขึ้นใน Availability Zone ที่เสียหาย วิธีเดียวที่เราทำได้ก็คือต้องแน่ใจว่าองค์ประกอบพื้นฐานทั้งหมด เช่น เกตเวย์ NAT อยู่ภายใน Availability Zone นั้นจริงๆ

ทางเลือกนี้มาพร้อมกับต้นทุนความซับซ้อนที่เพิ่มขึ้น สำหรับเราใน Amazon EC2 ความซับซ้อนที่เพิ่มขึ้นมาในรูปแบบของการจัดการสภาพแวดล้อมของบริการระดับโซน แทนที่จะเป็นระดับเขต สำหรับลูกค้าเกตเวย์ NAT ความซับซ้อนที่เพิ่มขึ้นมาในรูปแบบของการมีเกตเวย์ NAT และตารางการกำหนดเส้นทางหลายตัวสำหรับการใช้งานใน Availability Zone ที่แตกต่างกันของ VPC ความซับซ้อนเพิ่มเติมนี้มีความเหมาะสม เพราะเกตเวย์ NAT เองเป็นบริการพื้นฐาน โดยเป็นส่วนหนึ่งของ Data Plane ของ Amazon EC2 ที่จะต้องให้การรับประกันความพร้อมใช้งานระดับโซน

ยังมีข้อพิจารณาอีกข้อหนึ่งที่เราทำขึ้นเมื่อสร้างบริการที่เป็นอิสระจาก Availability Zone และมีความคงทนด้านข้อมูล ถึงแม้ว่าแต่ละสถาปัตยกรรมระดับโซนที่อธิบายไว้ก่อนหน้านี้จะแสดงทั้งสแตกที่มีอยู่ภายใน Availability Zone เดียว เราจำลองแบบสถานะที่ระบุชัดเจนใดๆ ไว้ในหลาย Availability Zone เพื่อวัตถุประสงค์ในการกู้คืนจากภัยพิบัติ ตัวอย่างเช่น โดยปกติ เราจัดเก็บข้อมูลสำรองของฐานข้อมูลตามระยะเวลาใน Amazon S3 และรักษาแบบจำลองการอ่านของที่เก็บข้อมูลของเราข้ามขอบเขต Availability Zone แบบจำลองเหล่านี้ไม่มีความจำเป็นเพื่อให้ Availability Zone หลักทำงานได้ แต่จะช่วยให้แน่ใจได้ว่าเราจัดเก็บข้อมูลที่มีความสำคัญสูงต่อลูกค้าหรือธุรกิจไว้ในหลายสถานที่

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

• รูปแบบง่ายๆ: เขตเรียกใช้เขต รูปแบบนี้มักจะเป็นทางเลือกที่ดีที่สุดสำหรับบริการที่ใช้งานภายนอก และเหมาะสมสำหรับบริการภายในส่วนใหญ่เช่นกัน ตัวอย่างเช่น เมื่อสร้างบริการของแอปพลิเคชันระดับที่สูงกว่าใน AWS เช่น Amazon API Gateway และเทคโนโลยีไร้เซิร์ฟเวอร์ของ AWS เราใช้รูปแบบนี้เพื่อจัดเตรียมความพร้อมใช้งานสูง แม้เมื่อในเวลาที่พบกับความเสียหายของ Availability Zone
• รูปแบบที่ซับซ้อนยิ่งขึ้น: เขตเรียกใช้โซน หรือโซนเรียกใช้เขต เมื่อออกแบบส่วนประกอบของ Data Plane ภายในและบางนอกในบางครั้งภายใน Amazon EC2 (ตัวอย่างเช่น อุปกรณ์เครือข่ายหรือโครงสร้างพื้นฐานอื่นๆ ที่อยู่ในพาธข้อมูลวิกฤตโดยตรง) เราทำตามรูปแบบความเป็นอิสระของ Availability Zone และใช้อินสแตนซ์ที่เก็บไว้ใน Availability Zones เพื่อให้ปริมาณงานบนเครือข่ายยังคงอยู่ใน Availability Zone เดิม รูปแบบนี้ไม่เพียงแต่ช่วยเก็บความเสียหายให้แยกออกจาก Availability Zone เท่านั้น แต่ยังมีคุณลักษณะของต้นทุนปริมาณงานบนเครือข่ายที่น่าพอใจใน AWS อีกด้วย

ในบทความนี้ เราได้พูดถึงกลยุทธ์ง่ายๆ บางอย่างที่เราใช้ที่ AWS สำหรับการจัดการการขึ้นต่อกันบน Availability Zone อย่างเป็นผลสำเร็จ เราได้เรียนรู้ว่าปัจจัยสำคัญเพื่อให้ได้รับความเสถียรคงที่นั้น คือการเตรียมรับมือกับความเสียหายก่อนที่จะเกิดขึ้นจริง ไม่ว่าระบบจะทำงานบนกลุ่มที่ปรับขนาดได้ตามแนวนอนแบบ Active-Active หรือไม่ว่าจะเป็นรูปแบบ Active-Standby แบบมีสถานะ เราสามารถใช้ Availability Zone เพื่อตั้งเป้าหมายความพร้อมใช้งานในระดับสูงได้ เราปรับใช้ระบบของเราเพื่อให้ความจุทั้งหมดที่จะต้องใช้ในกรณีที่เกิดความเสียหายนั้น ได้รับการจัดเตรียมอย่างสมบูรณ์ไว้แล้ว และพร้อมทำงานได้ตลอดเวลา สุดท้าย เราได้พิจารณาโดยละเอียดยิ่งขึ้นว่า Amazon EC2 เองใช้แนวความคิดความเสถียรคงที่อย่างไร เพื่อรักษา Availability Zone ให้เป็นอิสระจากกันและกัน