AWS Amazon Cloud Dealer: สอนการกำหนดค่า AWS Multi-Available Area (Multi-Available Area) และสถาปัตยกรรมการกู้คืนระบบอัตโนมัติข้ามภูมิภาค

เพื่อนทางเทคนิคน่าจะเคยได้ยินประโยคหนึ่ง: "ทุกอย่างจะล้มเหลวมันเป็นเพียงเรื่องของเวลา"

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

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

สถาปัตยกรรมทองคำทางอินเทอร์เน็ตที่คำนึงถึงความพร้อมใช้งานสูงของ "Multi-AZ ในภูมิภาคเดียวกัน" และ "การกู้คืนระบบอัตโนมัติข้ามภูมิภาค (Cross-Region)"

。

ขั้นตอนแรก: Multi-Available Area (Multi-AZ) ในพื้นที่เดียวกัน-ดับเปลวไฟแห่งความล้มเหลวเพียงจุดเดียว

"Available Zone" เป็นแนวคิดหลักของ AWS ภูมิภาค (เช่นโอเรกอน

Us-west-2

) ประกอบด้วยพื้นที่ว่างหลายแห่ง (เช่น

Us-west-2a

、

Us-west-2b

) การแยกทางกายภาพระหว่างพื้นที่ว่างแต่ละแห่ง (แหล่งจ่ายไฟอิสระการกระจายความร้อนและเครือข่าย) แต่มีการเชื่อมต่อโครงข่ายใยแก้วนำแสงความเร็วสูงพิเศษ

เป้าหมายแรกของเราคือ:

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

1.การออกแบบที่ดีของ VPC และ Subnet (Subnet)

นี่คือรากฐานคุณไม่สามารถโยนเซิร์ฟเวอร์ทั้งหมดลงในซับเน็ตได้

การดำเนินงานมาตรฐาน: ใน VPC ของคุณเลือกพื้นที่ว่างอย่างน้อยสองแห่ง (เช่น AZ-A และ AZ-B)

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

2.ชั้นการคำนวณ: ALB โหลดบาลานซ์ Auto Scaling (กลุ่มกล้องส่องทางไกลอัตโนมัติ)

อย่าผูก IP เครือข่ายสาธารณะของ EC2เดียวกับแอปพลิเคชันของผู้ใช้โดยตรง

สร้างแอปพลิเคชัน Load Balancer (ALB) และติดตั้งบนเครือข่ายย่อยสาธารณะของสองพื้นที่ที่มีอยู่ ALB จะถูกเปลี่ยนเป็นประตูหลังจากการรับส่งข้อมูลเข้ามามันจะกระจายคำขอไปยังเซิร์ฟเวอร์ส่วนหลังอย่างเท่าเทียมกัน

สร้างกลุ่ม Auto Scaling (ASG): เริ่มต้นแม่แบบเพื่อเลือกมิเรอร์ธุรกิจของคุณการกำหนดค่าที่สำคัญ: เมื่อเลือกเครือข่ายให้ตรวจสอบเครือข่ายย่อยส่วนตัวทั้งหมดในสองพื้นที่ที่มีอยู่ตั้งค่าความจุที่ต้องการเป็น2 (หมายถึงการเก็บ2เครื่องเพื่อดำเนินธุรกิจ) ตรรกะพื้นฐาน: AWS จะเปิดใช้งาน EC2ใน AZ-A และ AZ-B อย่างชาญฉลาดหากวันหนึ่ง AZ-A เครื่องล้มเหลวกะทันหัน

, ASG จะรับรู้ทันทีและดึงเครื่องใหม่โดยอัตโนมัติเพื่อเสริมใน AZ-B ที่มีสุขภาพดีและร่วมมือกับ ALB เพื่อกำจัดเครื่องที่ตายโดยอัตโนมัติและทำให้กระบวนการทั้งหมดเป็นไปโดยอัตโนมัติ

3.ชั้นข้อมูล: ฐานข้อมูล RDS ในคลิกเดียว Multi-AZ

หากเซิร์ฟเวอร์หยุดทำงานคุณสามารถรีสตาร์ทได้ตามต้องการหากข้อมูลหยุดทำงานหรือยุ่งเหยิงบริษัทจะเปิดที่นั่งโดยตรง

เมื่อสร้าง AWS RDS (เช่น MySQL) จะมีสวิตช์สีทองที่เรียกว่า "Multi-AZ Deployment" และตรวจสอบโดยไม่ลังเล

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

ในกรณีที่เกิดภัยพิบัติใน AZ-A RDS จะเริ่ม Failover โดยอัตโนมัติวางไลบรารีสแตนด์บายลงในไลบรารีหลักและแก้ไขชื่อโดเมนที่เชื่อมต่อของฐานข้อมูล (Endpoint) ไปยังไลบรารีหลักใหม่โดยอัตโนมัติโค้ดแบ็กเอนด์ของคุณไม่จำเป็นต้องแก้ไขที่อยู่ IP ใดๆและโดยปกติจะฟื้นคืนชีพโดยอัตโนมัติภายใน30วินาที

ขั้นตอนที่สอง: การเตรียมภัยพิบัติข้ามภูมิภาค-ป้องกันศัตรูจากระยะทางหลายพันไมล์

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

ข้ามภูมิภาค (Cross-Region) การกู้คืนระบบอัตโนมัติ

。

เราถือว่า:

พื้นที่การผลิต (Primary) ในโตเกียว (ap-northeast-1) และพื้นที่กู้คืนภัยพิบัติ (DR) ในสิงคโปร์ (ap-southeast-1)

1.การจำลองข้อมูลข้ามภูมิภาค

เพื่อซิงโครไนซ์ข้อมูลของโตเกียวกับสิงคโปร์แบบเรียลไทม์

ระดับฐานข้อมูล: บนไลบรารีหลัก RDS ในโตเกียวคลิกการดำเนินการ-> "สร้างสำเนาอ่านข้ามภูมิภาคอย่างเดียว" และเลือกสิงคโปร์ตามภูมิภาค AWS จะใช้เครือข่ายกระดูกสันหลังทั่วโลกเพื่อคัดลอกข้อมูลของโตเกียวไปยังสิงคโปร์แบบอะซิงโครนัส

ระดับการจัดเก็บไฟล์: หากคุณใช้ถังเก็บข้อมูล S3เพื่อจัดเก็บรูปภาพหรือไฟล์ของผู้ใช้ให้เปิดฟังก์ชัน "CRR, Cross-Region Replication" ของถังเก็บข้อมูลเพื่อให้ไฟล์ในถังโตเกียวบินไปยังถังสิงคโปร์โดยอัตโนมัติ

2.การสำรองข้อมูลโครงสร้างพื้นฐานในพื้นที่กู้คืนภัยพิบัติ (สิงคโปร์)

ในสิงคโปร์ยังมีการติดตั้งกลุ่ม VPC, ALB และ Auto Scaling

เคล็ดลับในการประหยัดเงิน: เพื่อประหยัดเงินคุณสามารถตั้งค่า "ความจุขั้นต่ำ" และ "ความจุที่คาดหวัง" ของกลุ่ม Auto Scaling ของสิงคโปร์เป็น0 (หรือเครื่องที่มีรายละเอียดต่ำ1เครื่องสำหรับการทดสอบการเต้นของหัวใจ) ในขณะนี้สิงคโปร์ไม่ได้สร้างต้นทุนการคำนวณ EC2จำนวนมาก

เฉพาะค่าธรรมเนียมการจัดเก็บราคาถูกและค่าธรรมเนียมการซิงค์ฐานข้อมูล

3.Soul Commander: Route 53 Smart Routing และ Fault Switch

จะเปลี่ยนการเข้าชมของผู้ใช้ทั่วโลกจากโตเกียวไปยังสิงคโปร์ได้อย่างไรเมื่อเกิดภัยพิบัติสิ่งนี้ต้องการบริการ DNS ของ AWS-

Route 53

。

กำหนดค่า "Failover Routing Policy" สำหรับชื่อโดเมนของเว็บไซต์ของคุณ (เช่น api.yourcompany.com) ใน Route 53

กำหนดค่าระเบียนสองรายการ: Primary: ตัวจัดสรรภาระงาน ALB ชี้ไปที่โตเกียว Secondary: ตัวปรับภาระงาน ALB ชี้ไปที่สิงคโปร์

การตรวจสุขภาพที่มีผลผูกพัน: ติดตั้ง ALB ของโตเกียวด้วยการตรวจสุขภาพ Route 53ทำให้ AWS สามารถตรวจสอบหน้าแรกของเว็บไซต์โตเกียวได้ทุกๆ10วินาที

ตรรกะการฝึกซ้อมภัยพิบัติ: หากภูมิภาคโตเกียวทั้งหมดระเบิดการตรวจสุขภาพของ Route 53จะสว่างขึ้นหลังจากความล้มเหลวติดต่อกันหลายครั้งมันจะเปิดใช้งานกลไกฟิวส์ทันทีและตัดความละเอียดชื่อโดเมนไปยัง ALB ในสิงคโปร์โดยตรง

ขั้นตอนที่สาม: กระบวนการฟื้นคืนชีพในสถานที่จริงเมื่อเกิดภัยพิบัติ

เมื่อ Tokyo Region ขาดการติดต่ออย่างแท้จริง Route 53ได้นำการจราจรไปยังสิงคโปร์โดยอัตโนมัติในขณะนี้เจ้าหน้าที่ปฏิบัติการและบำรุงรักษาจะต้องดำเนินการ "เพิ่มสิทธิ์" สองขั้นตอนสุดท้ายเท่านั้นและระบบสามารถกลับมาผลิตได้อย่างสมบูรณ์:

โปรโมชั่น: ลงชื่อเข้าใช้คอนโซล AWS ในสิงคโปร์เลือกสำเนาแบบอ่านอย่างเดียวที่ซิงโครไนซ์จากโตเกียวแล้วคลิก "โปรโมต Read Replica" มันจะตัดการเชื่อมต่อการซิงโครไนซ์กับโตเกียวภายในไม่กี่นาทีและกลายเป็นไลบรารีหลักมาตรฐานที่อ่านได้และเขียนได้

ชั้นคอมพิวเตอร์ปลุกด้วยคลิกเดียว: เปลี่ยนความจุที่คาดว่าจะได้รับของกลุ่ม Scaling Auto ของสิงคโปร์จาก0เป็นปริมาณการผลิตที่คุณต้องการ (เช่น10) ภายในไม่กี่นาทีเซิร์ฟเวอร์ EC2จำนวนมากก็โผล่ขึ้นมาในสิงคโปร์เพื่ออ่านฐานข้อมูลใหม่ที่อัปเกรดโดยอัตโนมัติ

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

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

Data Transfer Fee: AWS กำหนดว่าการส่งข้อมูลข้ามพื้นที่พร้อมใช้งานภายใน VPC เดียวกันจะถูกเรียกเก็บเงิน (แม้ว่าจะถูกมากก็ตาม) ดังนั้นพยายามทำให้ EC2ส่วนหน้าและบริการอินทราเน็ตส่วนหลังของคุณโต้ตอบภายใน AZ เดียวกันเฉพาะเมื่อทำการซิงโครไนซ์ฐานข้อมูลหรือการซิงโครไนซ์โหนดคลัสเตอร์แบบกระจายให้ใช้การรับส่งข้อมูลข้าม AZ

การแลกเปลี่ยนระหว่าง RPO และ RTO: RPO (ช่วงเวลาใดที่สามารถกู้คืนข้อมูลได้): เนื่องจากฐานข้อมูลข้ามภูมิภาค "แตกต่างกัน

"คัดลอกทีละขั้นตอน" ในขณะที่โตเกียวล้มลงอาจมีเวลาส่งข้อมูลหนึ่งหรือสองวินาทีไปยังสิงคโปร์และข้อมูลส่วนนี้จะถูกเก็บไว้ชั่วคราวองค์กรต้องเตรียมพร้อมสำหรับการกระทบยอดข้อมูล RTO (การกู้คืนใช้เวลานานแค่ไหน): การใช้สถาปัตยกรรมของบทความนี้ระบบอัตโนมัติและการแทรกแซงด้วยตนเองเล็กน้อยสามารถควบคุม RTO ได้ภายใน5ถึง15นาที

การก่อวินาศกรรมเป็นประจำ (Chaos Engineering): โครงสร้างที่มีความพร้อมใช้งานสูงเป็นสิ่งที่ต้องห้ามที่สุดในการ "วางไว้ที่นั่นหลังจากจับคู่" หลายบริษัทติดตั้งการกู้คืนระบบข้ามภูมิภาคและไม่ได้ย้ายมาเป็นเวลาสามปีเมื่อเกิดอุบัติเหตุในปีที่4พบว่าภาพสะท้อนของสิงคโปร์หมดอายุไปนานแล้วและไม่สามารถใช้งานได้ขอแนะนำให้เลือกเช้าตรู่ของวันหยุดสุดสัปดาห์ทุกๆหกเดือนตัด Route 53ไปยังพื้นที่กู้คืนภัยพิบัติด้วยตนเองและทำการเจาะตัดการเชื่อมต่อจริง

สรุป

ความล้มเหลวของจุดเดียวไม่ได้ขึ้นอยู่กับโชคแต่ขึ้นอยู่กับการออกแบบสถาปัตยกรรมทางวิทยาศาสตร์

"ความพร้อมใช้งานสูง (HA)" ได้รับการแก้ไขในพื้นที่ที่มีอยู่หลายแห่งในภูมิภาคเดียวกันเพื่อให้แน่ใจว่าไม่มีการตัดการเชื่อมต่อรายวันการกู้คืนระบบอัตโนมัติข้ามภูมิภาคช่วยแก้ปัญหา "การกู้คืนระบบ (DR)" เพื่อให้แน่ใจว่าบริษัทสามารถอยู่รอดได้ภายใต้สภาวะที่รุนแรง

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