สรุปต้นเหตุ Canva ล่ม 2025 ล่าสุด Amazon Web Services (AWS) แจงสาเหตุขัดข้องครั้งใหญ่แล้ว

สำนักข่าวบริคอินโฟ – เมื่อวันที่ 19 ถึง 20 ตุลาคม Amazon Web Services (AWS) ประสบเหตุขัดข้องของบริการครั้งใหญ่ในภูมิภาค N. Virginia (US-EAST-1) ซึ่งเป็นศูนย์ข้อมูลที่สำคัญ โดยเหตุการณ์นี้เริ่มต้นตั้งแต่เวลา 23:48 น. ของวันที่ 19 ตุลาคม (ตามเวลาแปซิฟิก, PDT) และสิ้นสุดลงในเวลา 14:20 น. ของวันที่ 20 ตุลาคม โดยมีช่วงเวลาที่บริการหลักได้รับผลกระทบแตกต่างกันไปถึง 3 ช่วงคือ อัตราข้อผิดพลาดของ Amazon DynamoDB API ที่เพิ่มสูงขึ้น, ข้อผิดพลาดในการเชื่อมต่อของ Network Load Balancer (NLB) และความล้มเหลวในการเรียกใช้งาน EC2 instance ใหม่

DynamoDB: ต้นตอของปัญหาจากข้อบกพร่องของระบบ DNS อัตโนมัติ

ระหว่างเวลา 23:48 น. ของวันที่ 19 ตุลาคม ถึง 02:40 น. ของวันที่ 20 ตุลาคม ลูกค้าและบริการอื่น ๆ ของ AWS ที่พึ่งพา DynamoDB ในภูมิภาค N. Virginia (us-east-1) พบกับอัตราข้อผิดพลาดของ API ที่เพิ่มขึ้นอย่างมาก สาเหตุหลักเกิดจาก ข้อบกพร่องที่ซ่อนอยู่ (latent defect) ภายในระบบจัดการ DNS อัตโนมัติของบริการ ซึ่งทำให้เกิดความล้มเหลวในการระบุจุดเชื่อมต่อ (endpoint resolution failures) สำหรับ DynamoDB

ระบบ DNS ของ DynamoDB ถูกแบ่งออกเป็นสองส่วนอิสระเพื่อความพร้อมใช้งาน: DNS Planner ที่ตรวจสอบสถานะและความจุของตัวปรับโหลด (load balancers) และสร้างแผน DNS ใหม่เป็นระยะ และ DNS Enactor ที่ทำหน้าที่นำแผน DNS ไปปรับใช้ในบริการ Amazon Route53 โดยทำงานซ้ำซ้อนกันในสาม Availability Zones (AZs)

AWS อธิบายว่าสาเหตุที่แท้จริงคือ Race Condition (ภาวะการแข่งขัน) ที่เกิดขึ้นในระบบจัดการ DNS ของ DynamoDB เมื่อ DNS Enactor ตัวหนึ่งซึ่งล่าช้าผิดปกติ ได้นำแผน DNS ที่เก่ากว่ามากไปเขียนทับแผนที่ใหม่กว่าสำหรับ endpoint ระดับภูมิภาค ($dynamodb.us-east-1.amazonaws.com$) และในขณะเดียวกัน Enactor ตัวที่สองได้ดำเนินการลบแผนที่เก่ากว่านี้ทิ้ง ทำให้ไม่มีข้อมูล IP Address เหลืออยู่สำหรับ Regional Endpoint ส่งผลให้ระบบอยู่ในสถานะไม่สอดคล้องกันที่ขัดขวางการอัปเดตแผน DNS ในภายหลัง ซึ่งต้องใช้การแทรกแซงด้วยตนเองจากผู้ปฏิบัติงาน

ผลกระทบต่อเนื่องต่อ EC2 และความล้มเหลวในการเปิดตัว Instance ใหม่

เมื่อปัญหา DynamoDB DNS เริ่มต้นขึ้น ระบบย่อยของ Amazon EC2 ที่เรียกว่า DropletWorkflow Manager (DWFM) ซึ่งรับผิดชอบในการจัดการเซิร์ฟเวอร์กายภาพ (droplets) ได้รับผลกระทบเนื่องจากต้องพึ่งพา DynamoDB ในการตรวจสอบสถานะ ทำให้ Lease ระหว่าง DWFM และ droplets เริ่มหมดอายุในช่วงเวลา 23:48 น. ของวันที่ 19 ตุลาคม ถึง 02:24 น. ของวันที่ 20 ตุลาคม แม้ว่า EC2 instance ที่รันอยู่เดิมจะไม่ได้รับผลกระทบ แต่ droplet ที่ไม่มี Lease จะไม่ถูกพิจารณาสำหรับการเปิดตัว EC2 instance ใหม่

แม้จะสามารถกู้คืน DynamoDB API ได้ในเวลา 02:25 น. แต่ความพยายามในการสร้าง Lease ใหม่กับ droplets จำนวนมากของ DWFM ก็ใช้เวลานานจนเกิด Congestive Collapse (การล่มสลายจากการแออัด) และไม่สามารถดำเนินการต่อไปได้ วิศวกร จึงต้องดำเนินการลดปริมาณงานที่เข้ามา (throttled incoming work) และทำการรีสตาร์ท DWFM hosts แบบเลือกสรรในเวลา 04:14 น. ซึ่งช่วยให้สามารถสร้าง Lease กับ droplets ทั้งหมดในภูมิภาคได้ภายในเวลา 05:28 น. หลังจากนั้น การเปิดตัว instance ใหม่จึงเริ่มประสบความสำเร็จ แต่ก็ยังคงเห็นข้อผิดพลาด “request limit exceeded” เนื่องจากการจำกัดปริมาณคำขอที่ถูกตั้งไว้

นอกจากนี้ ระบบ Network Manager ที่จัดการการกำหนดค่าเครือข่ายสำหรับ EC2 instance ใหม่ ก็เกิดปริมาณงานที่ค้างอยู่ (backlog) อย่างมาก ทำให้เวลาในการเผยแพร่การกำหนดค่าเครือข่ายเพิ่มขึ้นจนกระทบกับการเชื่อมต่อของ instance ที่เปิดใหม่ ซึ่งใช้เวลาถึง 10:36 น. ในการกลับสู่ระดับปกติ AWS รายงานว่า EC2 API และการเปิดตัว instance ใหม่ทั้งหมดกลับมาเป็นปกติในเวลา 13:50 น. ของวันที่ 20 ตุลาคม

Network Load Balancer (NLB) ประสบปัญหา Health Check ล้มเหลว

ปัญหาการล่าช้าในการเผยแพร่สถานะเครือข่ายสำหรับ EC2 instance ที่เพิ่งเปิดตัวยังส่งผลกระทบต่อบริการ Network Load Balancer (NLB) ในช่วงเวลา 05:30 น. ถึง 14:09 น. ของวันที่ 20 ตุลาคม ลูกค้าบางรายประสบปัญหาข้อผิดพลาดในการเชื่อมต่อ NLB ที่เพิ่มขึ้น สาเหตุเกิดจากระบบตรวจสอบสถานะ (health checking subsystem) ของ NLB นำ EC2 instance ใหม่เข้าสู่บริการก่อนที่สถานะเครือข่ายจะได้รับการเผยแพร่เสร็จสิ้น ทำให้การตรวจสอบสถานะล้มเหลวเป็นระยะ ส่งผลให้โหนด NLB และเป้าหมายแบ็กเอนด์ (backend targets) ถูกลบออกจาก DNS และถูกนำกลับเข้าสู่บริการสลับกันไปมา

ภาวะนี้เพิ่มภาระงานให้กับระบบตรวจสอบสถานะและกระตุ้นให้เกิดการสำรอง DNS failover ข้าม AZ โดยอัตโนมัติ ซึ่งลดความจุลง การดำเนินการแก้ไขรวมถึงการปิดการใช้งาน health check failover โดยอัตโนมัติในเวลา 09:36 น. เพื่อให้โหนด NLB และเป้าหมายที่พร้อมใช้งานทั้งหมดกลับมาให้บริการได้ ซึ่งช่วยลดข้อผิดพลาดในการเชื่อมต่อที่เพิ่มขึ้นลงได้ NLB กลับมาทำงานปกติในเวลา 14:09 น. หลังจากที่ EC2 ได้รับการกู้คืน

บริการ AWS อื่น ๆ ที่ได้รับผลกระทบ

เหตุการณ์นี้ยังส่งผลกระทบต่อเนื่องต่อบริการอื่น ๆ ของ AWS ในภูมิภาค N. Virginia (us-east-1) อย่างกว้างขวาง:

• AWS Lambda: ประสบปัญหาข้อผิดพลาด API และความหน่วงในการทำงานของฟังก์ชัน ระหว่าง 23:51 น. ของวันที่ 19 ตุลาคม ถึง 14:15 น. ของวันที่ 20 ตุลาคม
• Amazon ECS, EKS, และ Fargate: พบความล้มเหลวในการเปิดตัวคอนเทนเนอร์และความล่าช้าในการปรับขนาดคลัสเตอร์ จนกระทั่งได้รับการกู้คืนในเวลา 14:20 น.
• Amazon Connect: ลูกค้าประสบปัญหาข้อผิดพลาดในการจัดการการโทร, แชท, และเคส ตั้งแต่ 23:56 น. ของวันที่ 19 ตุลาคม ถึง 13:20 น. ของวันที่ 20 ตุลาคม
• AWS Security Token Service (STS): พบข้อผิดพลาดและเวลาแฝงของ API เป็นสองช่วงคือ 23:51 น. ของวันที่ 19 ตุลาคม ถึง 01:19 น. ของวันที่ 20 ตุลาคม และอีกครั้งในช่วง 08:31 น. ถึง 09:59 น. ของวันที่ 20 ตุลาคม เนื่องจากความล้มเหลวในการตรวจสอบสถานะของ NLB

มาตรการแก้ไขของ AWS ในอนาคต

AWS ได้ประกาศมาตรการหลายอย่างเพื่อป้องกันปัญหาที่คล้ายคลึงกันในอนาคต:

• DynamoDB: ได้ปิดการใช้งานระบบ DNS Planner และ DNS Enactor ทั่วโลกชั่วคราว และจะแก้ไขปัญหา Race Condition พร้อมเพิ่มการป้องกันเพิ่มเติมก่อนที่จะเปิดใช้งานอีกครั้ง
• NLB: จะมีการเพิ่มกลไกควบคุมความเร็ว (velocity control mechanism) เพื่อจำกัดความจุที่ NLB เดียวสามารถนำออกไปได้ เมื่อความล้มเหลวในการตรวจสอบสถานะทำให้เกิด AZ failover
• EC2: กำลังสร้างชุดทดสอบเพิ่มเติมเพื่อเสริมการทดสอบขนาดที่มีอยู่ และจะปรับปรุงกลไกการจำกัดปริมาณคำขอ (throttling mechanism) ในระบบเผยแพร่ข้อมูลของ EC2 เพื่อจำกัดปริมาณงานตามขนาดของคิวที่รอ เพื่อปกป้องบริการในช่วงที่มีภาระงานสูง

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