การออกแบบสถาปัตยกรรมที่มีความพร้อมใช้งานสูงของ Amazon Cloud International: การกู้คืนระบบข้ามพื้นที่พร้อมใช้งาน (AZ) และการจัดสรรภาระงาน ELB

ในยุคของการประมวลผลแบบคลาวด์ "High Availability (HA)" แทบจะเป็นคำที่สถาปนิกทุกประเภทพูดถึงหลายคนคิดว่าตราบใดที่ระบบถูกย้ายไปที่ Amazon Cloud (AWS) มีการซื้อ EC2และมีการจัดสรรภาระงานความพร้อมใช้งานสูงก็จะเกิดขึ้นได้ตามธรรมชาติ

อย่างไรก็ตามสภาพแวดล้อมการผลิตที่แท้จริงมักจะทำให้การมองโลกในแง่ดีของคนตาบอดดังขึ้น

เมื่อพื้นที่ใช้งาน AWS (Available Zone, AZ) เป็นอัมพาตเนื่องจากสายเคเบิลออปติคอลด้านล่างถูกตัดไฟดับหรือเครือข่ายที่กำหนดโดยซอฟต์แวร์ (SDN) ผิดปกติบริการของคุณจะเปลี่ยนไปอย่างราบรื่นโดยอัตโนมัติหรือจะหยุดทำงานและบริการลูกค้าโทรศัพท์ระเบิด?

ที่แท้จริง

สถาปัตยกรรมที่มีความพร้อมใช้งานสูงไม่ได้ซื้อแต่ออกแบบมา

。บทความนี้จะละทิ้งคำ PPT สีดำที่ซับซ้อนโดยสิ้นเชิงและใช้ "ภาษาพื้นถิ่น" ที่เข้าใจง่ายที่สุดเพื่อพาคุณไปรื้อข้อเสนอหลักสองข้อที่มีความพร้อมใช้งานสูงบนเว็บไซต์ Amazon Cloud International:

การกู้คืนระบบข้ามพื้นที่ใช้งาน (Cross-AZ)

กับ

โหลดบาลานซ์ ELB

。

1.นิยามใหม่ของ "ความพร้อมใช้งานสูง": ความจริงพื้นฐานของภูมิภาคและ AZ

ก่อนที่จะออกแบบสถาปัตยกรรมเราต้องรับรู้โครงสร้างพื้นฐานทางกายภาพพื้นฐานของ AWS ก่อนนี่คือรากฐานของการออกแบบที่มีอยู่สูงทั้งหมด

ภูมิภาค: ภูมิภาคที่แยกจากกันโดยสิ้นเชิง (เช่นโตเกียวเวอร์จิเนียไอร์แลนด์) ระยะห่างระหว่างภูมิภาคนั้นไกลมากเว้นแต่จะเกิดภัยพิบัติทางภูมิรัฐศาสตร์ไฟดับในภูมิภาคหนึ่งจะไม่ส่งผลกระทบต่ออีกภูมิภาคหนึ่ง

พื้นที่ว่าง (AZ): พื้นที่หนึ่งมีพื้นที่ว่างหลายแห่งโปรดจำไว้ว่า: AZ ไม่เท่ากับศูนย์ข้อมูล AZ อาจประกอบด้วยกลุ่มศูนย์ข้อมูลหลายกลุ่มที่อยู่ใกล้กันแต่ไฟฟ้าและเครือข่ายเป็นอิสระอย่างสมบูรณ์

💡จุดเจ็บปวดหลัก: ทำไมสถาปัตยกรรม AZ เดียวถึงตาย? เพื่อประหยัดเงินบริษัทในต่างประเทศหลายแห่งทิ้งเว็บเซิร์ฟเวอร์และฐานข้อมูลทั้งหมดไว้ใน AZ เดียวกัน (เช่น ap-northeast-1a) สิ่งนี้เทียบเท่ากับการใส่ไข่ทั้งหมดลงในตะกร้าที่เรียกว่า "กันกระสุน" แต่อาจยังรั่วได้เมื่อเครือข่ายกระดูกสันหลังของ AZ ล้มเหลวธุรกิจของคุณจะขาดการติดต่อทันที

ดังนั้นสถาปัตยกรรมข้าม AZ(Multi-AZ) จึงไม่ใช่ "ตัวเลือกขั้นสูง" แต่เป็นสภาพแวดล้อมการผลิต

เส้นด้านล่างแข็ง

。

2.ตำรวจจราจรจราจร: วิธีที่ถูกต้องในการเปิด ELB (การจัดสรรภาระงานแบบยืดหยุ่น)

เพื่อให้เกิดการกู้คืนระบบข้าม AZ ขั้นตอนแรกต้องมี "ตำรวจจราจรจราจร" เพื่อกระจายคำขอจากผู้ใช้ทั่วโลกไปยังเซิร์ฟเวอร์ในพื้นที่ที่มีอยู่ต่างๆอย่างเท่าเทียมกันและชาญฉลาดใน AWS ตัวละครนี้ประกอบด้วย

ELB(Elastic Load Balancing)

เสิร์ฟ.

AWS มีตัวจัดสรรภาระงานที่หลากหลายแต่ในสถาปัตยกรรมเว็บที่ทันสมัยเรามุ่งเน้นไปที่

ALB(Application Load Balancer)

และ

NLB(Network Load Balancer)

。

1. ALB vs NLB: ไม่เลือก

อาวุธผิด

ลักษณะ

ALB (แอพลิเคชันโหลดควอไลเซอร์)

NLB (เครือข่ายโหลดควอไลเซอร์)

การทำงานระดับ OSI

ชั้น7 (ชั้นการประยุกต์ใช้: HTTP/HTTPS)

ชั้น4 (ชั้นการขนส่ง: TCP/UDP/TLS)

ประโยชน์หลัก

ฉลาดสามารถระบุเส้นทาง URL, คุกกี้, HTTP Header สำหรับการกำหนดเส้นทางขั้นสูงรองรับการถอนการติดตั้งใบรับรอง SSL 。

เร็วมากเวลาแฝงต่ำมากสามารถประมวลผลคำขอพร้อมกันหลายสิบล้านครั้งต่อวินาทีและรองรับ IP คงที่

สถานการณ์ที่เหมาะสม

เว็บแอปพลิเคชันส่วนใหญ่ API ไมโครเซอร์วิสและเว็บไซต์อีคอมเมิร์ซ

เกตเวย์เกมเทอร์มินัลการรับ Internet of Things (IoT) บริการ TCP ดั้งเดิมที่ไม่ใช่โปรโตคอล HTTP

สำหรับบริษัทในต่างประเทศส่วนใหญ่

ALB

เป็นตัวเลือกที่แนะนำมากที่สุด

2.โหลดบาลานซ์ข้ามพื้นที่ว่าง (Cross-Zone Load Balancing)

นี่เป็นสถานที่ที่ง่ายที่สุดในการออกแบบ ELB

โดยค่าเริ่มต้นการจัดสรรภาระงานข้ามพื้นที่ว่างของ ALB คือ

เปิดใช้งาน

และ NLB เป็นค่าเริ่มต้น

ปิด

ของ. อะไรคือความแตกต่าง?

ปิด: หาก DNS จัดสรรการรับส่งข้อมูล50% ให้กับโหนดโหลดบาลานซ์ AZ-A 50% จะถูกจัดสรรให้กับโหนดโหลดบาลานซ์ AZ-B แม้ว่าจะมีเซิร์ฟเวอร์เพียงเครื่องเดียวใน AZ-A และ4เซิร์ฟเวอร์ใน AZ-B แต่เซิร์ฟเวอร์ที่ AZ-A จะหมดไปกับการรับส่งข้อมูล50%

เปิดสถานะ: ไม่ว่าการรับส่งข้อมูลจะไปถึงโหนดโหลดบาลานซ์ AZ ใดก่อน ELB จะกระจายคำขอไปยังอินสแตนซ์แบ็คเอนด์ทั้งหมดใน AZ ทั้งหมดที่อยู่เบื้องหลังอย่างเท่าเทียมกัน

สรุป:

เว้นแต่คุณจะมีข้อกำหนดการหน่วงเวลาที่รุนแรงมาก (ระดับไมโครวินาที)

ขอแนะนำอย่างยิ่งให้เปิดโหลดบาลานซ์ข้ามพื้นที่พร้อมใช้งาน

เพื่อให้แน่ใจว่าความดันส่วนหลังมีค่าเฉลี่ยแน่นอน

3.สามเหลี่ยมเหล็กของการกู้คืนระบบข้าม AZ: คอมพิวเตอร์เครือข่ายและการจัดเก็บ

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

1.ชั้นการคำนวณ: Auto Scaling (กลุ่มขยายอัตโนมัติ) เป็นเพียงท่าทางที่ถูกต้อง

ไม่เคยไปด้วยตนเองเพื่อสร้างสองเครื่องใส่สอง AZ คุณควรใช้

AWS Auto Scaling Group (ASG)

。

คุณต้องกำหนดค่าเทมเพลตเริ่มต้นเท่านั้นและบอก ASG: "ฉันต้องการอย่างน้อย2เครื่องและสูงสุด10เครื่องโปรดช่วยฉันปรับใช้

Ap-northeast-1a

และ

Ap-northeast-1b

ในสอง AZ นี้"

ตรวจสอบสุขภาพ: อย่าปล่อยให้ ELB ตรวจสอบว่า EC2เปิดอยู่หรือไม่ (Ping) หากต้องการกำหนดค่า ELB เพื่อขออินเทอร์เฟซเฉพาะในโค้ดของคุณ (เช่น/health) หากอินเทอร์เฟซนี้ส่งคืน500หรือการเชื่อมต่อฐานข้อมูลล้มเหลว ELB จะทันที

ตรวจสอบอินสแตนซ์ว่า "ไม่แข็งแรง" และหยุดส่งการเข้าชมไป

ความสามารถในการรักษาตัวเอง: เมื่อ AZ บางเครื่องวางสายและเครื่องทั้งหมดใน AZ ขาดการเชื่อมต่อ ASG จะเรียกสัญญาณเตือนทันทีและเปิดเครื่องใหม่โดยอัตโนมัติเพื่อเติมเต็มช่องว่างใน AZ อื่นที่มีสุขภาพดี

2.เลเยอร์เครือข่าย: กฎทองของเครือข่ายย่อย (Subnet) และการกำหนดเส้นทาง

ในการออกแบบเครือข่ายส่วนตัว (VPC) หลายคนทำผิดพลาดในโครงสร้างที่วุ่นวายสถาปัตยกรรมเครือข่ายที่มีความพร้อมใช้งานสูงมาตรฐานควรเป็นไปตามหลักการของ "การเกิดขึ้นเป็นคู่และการแยกที่แน่นอน"

Public Subnet: วางเกตเวย์อินเทอร์เน็ต ELB และ NAT หนึ่งสำหรับแต่ละ AZ

Subnet ส่วนตัว: วางเซิร์ฟเวอร์แอปพลิเคชัน EC2จริงเครื่องเหล่านี้ไม่จำเป็นต้องใช้ IP เครือข่ายสาธารณะและไม่สามารถสัมผัสกับอินเทอร์เน็ตได้โดยตรงหนึ่งสำหรับแต่ละ AZ

กับดักเกตเวย์ NAT ที่มีความพร้อมใช้งานสูง: เพื่อประหยัดเงินหลายทีมได้สร้างเกตเวย์ NAT เพียงแห่งเดียวใน VPC ทั้งหมดและวางไว้ AZ-A เพื่อให้ EC2ส่วนตัวของ AZ-B สามารถข้าม AZ เพื่อท่องอินเทอร์เน็ตได้เมื่อ AZ-A หยุดทำงานแม้ว่าเซิร์ฟเวอร์ของ AZ-B จะยังมีชีวิตอยู่แต่ก็ถูกยกเลิกเนื่องจากไม่สามารถเข้าถึงอินเทอร์เน็ตได้ (ไม่สามารถเข้าถึง API ภายนอกไม่สามารถดาวน์โหลดได้) แนวทางที่ถูกต้อง: แต่ละ AZ มีเกตเวย์ NAT อิสระ

3.การจัดเก็บและฐานข้อมูลเลเยอร์: บอกลาจุดเดียวกอด Multi-AZ

โหนดการคำนวณไม่มีสถานะ (Stateless) และสามารถเปิดใหม่ได้ทุกเมื่อเมื่อตายแต่

ข้อมูลอยู่ในสถานะและข้อมูลจะต้องไม่สูญหาย

ฐานข้อมูลเชิงสัมพันธ์ (RDS / Aurora): เปิดใช้งานการปรับใช้ Multi-AZ อย่างมาก AWS จะสร้างอินสแตนซ์สแตนด์บาย (Standby) ที่ซิงโครไนซ์อย่างสมบูรณ์ใน AZ อื่นโดยอัตโนมัติเมื่อ AZ ซึ่งเป็นที่ตั้งของไลบรารีหลักล้มเหลว RDS จะดำเนินการดริฟท์ DNS โดยอัตโนมัติและอัปเกรดไลบรารีสำรองเป็นไลบรารีหลักภายในไม่กี่วินาทีถึงหลายสิบวินาทีรหัสแอปพลิเคชันของคุณไม่จำเป็นต้องแก้ไขสตริงการเชื่อมต่อ (Endpoint) ด้วยซ้ำ

การจัดเก็บไฟล์ (EFS vs EBS):EBS (Cloud Hard Drive): มันถูกผูกไว้กับ AZ เฉพาะซึ่งหมายความว่า EC2ของ AZ-A ถูกวางสายและคุณไม่สามารถติดตั้ง EBS บน EC2ของ AZ-B ได้โดยตรง EFS (ระบบไฟล์แบบยืดหยุ่น): การสนับสนุนดั้งเดิมข้าม AZ หลาย AZ EC2สามารถอ่านและเขียน EFS เดียวกันในเวลาเดียวกันหากธุรกิจของคุณต้องการจัดเก็บไฟล์ร่วมกัน (เช่นไดเรกทอรีอัปโหลดรูปภาพของ Wordpress) ให้เลือก EFS โดยไม่ลังเล

ประการที่สี่การต่อสู้ที่แท้จริง: แบบฝึกหัดสถาปัตยกรรมที่มีความพร้อมใช้งานสูงหลาย AZ มาตรฐาน

เพื่อให้คุณรู้สึกง่ายขึ้นเรามาจำลองว่าคำขอของผู้ใช้มาตรฐานไหลในสถาปัตยกรรมที่มีความพร้อมใช้งานสูงของ AWS ข้าม AZ ได้อย่างไร

สถานการณ์: ผู้ใช้เยี่ยมชมเว็บไซต์อีคอมเมิร์ซ [https: // example.com]

การแก้ปัญหาชื่อโดเมน: ผู้ใช้เริ่มต้นคำขอและ AWS Route 53 (Smart DNS) แก้ไขชื่อโดเมนเนื่องจากการกำหนดค่า

ด้วยกลยุทธ์ความล่าช้าหรือการสำรวจ Route 53จะชี้การรับส่งข้อมูลไปยัง ALB ที่ใช้งานบนเครือข่ายย่อยสาธารณะ

การกระจายการรับส่งข้อมูล: ALB ได้รับคำขอ HTTPS ทำการถอดรหัสใบรับรอง SSL (การถอนการติดตั้งความดัน) ในเครื่องจากนั้นส่งต่อคำขอไปยังอินสแตนซ์ EC2ที่อยู่ในเครือข่ายย่อยส่วนตัวของ AZ-A หรือ AZ-B ตามกลยุทธ์การจัดสรรภาระงานข้ามพื้นที่ที่มีอยู่

การประมวลผลทางธุรกิจและการอ่านและเขียนข้อมูล: บริการประมวลผลแอปพลิเคชันบน EC2หากคุณต้องการอ่านและเขียนฐานข้อมูลก็จะเชื่อมต่อกับห้องสมุดหลัก RDS (อยู่ใน AZ-A) ณจุดนี้ RDS จะซิงโครไนซ์ข้อมูลไปยังไลบรารี RDS โดยอัตโนมัติ (อยู่ใน AZ-B)

ภัยพิบัติเกิดขึ้น (AZ-A จำลองถูกตัดการเชื่อมต่อโดยสิ้นเชิง): การตอบสนองของ ELB: ALB พบว่าอินสแตนซ์ EC2ใน AZ-A หยุดเต้นหรือการตรวจสุขภาพล้มเหลวอย่างต่อเนื่องและลบ AZ-A ออกจากรายการส่งต่อทันที100% ของการเข้าชมจะถูกนำเข้าสู่ EC2ของ AZ-B ทันทีการรักษาตัวเอง RDS: AWS ตรวจสอบการขาดการเชื่อมต่อกับไลบรารีหลัก RDS และเริ่ม Failover โดยอัตโนมัติไลบรารีสำรองของ AZ-B ได้รับการอัปเกรดเป็นไลบรารีหลักใหม่ภายใน30วินาทีและ Route 53จะอัปเดต Endpoint ภายในของ RDS โดยอัตโนมัติ EC2ของ AZ-B กลับมาอ่านและเขียนตามปกติหลังจากรายงานข้อผิดพลาดสั้นๆการขยาย ASG: Auto Scaling Group พบว่าจำนวนเครื่องที่ยังมีชีวิตอยู่ในปัจจุบันน้อยกว่าค่าที่คาดไว้ขั้นต่ำที่ตั้งไว้และจะปรากฏ EC2ใหม่ใน AZ-B ที่มีสุขภาพดีทันทีและลงทะเบียนโดยอัตโนมัติด้านหลัง ALB

ผลลัพธ์:

ในระหว่างกระบวนการทั้งหมดยกเว้นผู้ใช้เพียงไม่กี่รายที่เริ่มคำขอในขณะที่เปลี่ยนอาจพบการลองใหม่ (502/504) ผู้ใช้99% ไม่สามารถรับรู้ได้เลยว่าพวกเขาประสบกับภัยพิบัติระดับห้องคอมพิวเตอร์ "ความเร็วชีวิตและความตาย" ในพื้นหลัง

5.คำแนะนำในการหลีกเลี่ยงหลุม: ข้อผิดพลาดร้ายแรงสามประการที่สถาปนิกมักทำ

ในการลงจอดจริงของโครงสร้างนี้จากกรณีโรลโอเวอร์จำนวนมากฉันได้สรุปแนวปะการังที่ถูกมองข้ามมากที่สุดสามประการต่อไปนี้:

1.ค่าใช้จ่ายในการโอนข้าม AZ (Cross-AZ Data Transfer Costs)

ปริมาณการใช้งานขาเข้าของ AWS (จากอินเทอร์เน็ต) ฟรีแต่ในภูมิภาคเดียวกัน

การรับส่งข้อมูลข้าม AZ ที่แตกต่างกันจะถูกเรียกเก็บเงิน

(โดยปกติคือ $0.01/GB)

หากไมโครเซอร์วิสของคุณแตกกระจายเกินไปและบริการ A(AZ-A) มักเรียกใช้บริการ B(AZ-B) ผ่าน RPC ภายในสิ้นเดือนคุณจะได้รับใบเรียกเก็บเงินเครือข่ายที่น่ากลัวอย่างยิ่ง

แผนการเพิ่มประสิทธิภาพ: พยายามทำให้การรับส่งข้อมูลเสร็จสมบูรณ์ในวงปิดของอินทราเน็ตใน AZ เดียวกันและข้าม AZ เมื่อเปลี่ยนการกู้คืนระบบเท่านั้น

2.ฐานข้อมูล "สมองแตก" และความล่าช้าในการซิงโครไนซ์

แม้ว่า RDS Multi-AZ จะเป็นสำเนาแบบซิงโครนัสแต่ประสิทธิภาพก็ดีมากแต่หากคุณสร้างคลัสเตอร์ฐานข้อมูลที่สร้างขึ้นเอง (เช่น MySQL MHA ที่ดัดแปลงโดยเวทมนตร์ฮาร์ดคอร์ของคุณเอง) เมื่อเครือข่าย AZ กระวนกระวายใจมันเป็นเรื่องง่ายมากที่ทั้งสองโหนดจะคิดว่าฉันเป็นปรากฏการณ์ "สมองแตก" ของไลบรารีหลักสิ่งนี้นำไปสู่การเขียนข้อมูลที่ไม่เป็นระเบียบ

แผนการเพิ่มประสิทธิภาพ: สิ่งที่เป็นมืออาชีพมอบให้กับเครื่องมือระดับมืออาชีพสภาพแวดล้อมการผลิตที่แข็งแกร่ง

ขอแนะนำให้ใช้ RDS หรือ Aurora ก่อนและปล่อยให้ AWS แก้ปัญหาความสอดคล้องแบบกระจายพื้นฐาน

3.ลืมทดสอบ: สูงที่มีอยู่บนกระดาษไม่สูงที่มีอยู่

โครงสร้างของทีมจำนวนมากได้รับการออกแบบมาอย่างสมบูรณ์แบบแต่พวกเขาไม่เคยทำแบบฝึกหัดการกู้คืนระบบเลยในช่วงสามปีนับตั้งแต่เปิดตัวเมื่อมันล้มเหลวจริงๆฉันพบว่า IP ของฐานข้อมูลถูกเขียนไว้ในรหัสหรือกลุ่มความปลอดภัยลืมที่จะปล่อยกลุ่มเครือข่าย AZ อื่น

โปรแกรมการเพิ่มประสิทธิภาพ: ดำเนินการ Chaos Engineering (Chaos Engineering) เป็นประจำในช่วงที่มีนักท่องเที่ยวน้อยให้ไปที่คอนโซล RDS ด้วยตนเองและคลิก "Failover" หรือจงใจปิด EC2ทั้งหมดของ AZ เพื่อดูว่าระบบสามารถรักษาตัวเองได้ตามที่คาดไว้หรือไม่

บทสรุป

ในยุคดั้งเดิมของคลาวด์

การกู้คืนจากภัยพิบัติไม่ควรเป็นงานทางกายภาพที่มีราคาแพงและยุ่งยากแต่ควรเป็นสัญชาตญาณในการออกแบบ

โดย

การกระจายอัจฉริยะของ ELB

、

การรักษาตัวเองแบบไม่มีสถานะของ Auto Scaling

และ

การจำลองแบบซิงโครนัสข้าม AZ ของ RDS

เมื่อรวมกันแล้วเราใช้บริการ Amazon Cloud International Station เพียงไม่กี่มาตรฐานเพื่อสร้างโครงสร้างเหล็กที่สามารถต้านทานภัยพิบัติระดับห้องคอมพิวเตอร์ได้

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