เมื่อ Amazon Web Services ประสบปัญหาขัดข้องครั้งใหญ่ในภูมิภาค Northern Virginia ระหว่างวันที่ 19-20 ตุลาคม 2025 สาเหตุเบื้องต้นที่ปรากฏดูเหมือนจะตรงไปตรงมา นั่นคือปัญหา race condition ในระบบจัดการ DNS ของ DynamoDB แต่เมื่อชุมชนด้านเทคนิคได้ศึกษารายงานการวิเคราะห์เหตุการณ์ (postmortem) โดยละเอียดของ Amazon เรื่องราวที่ซับซ้อนยิ่งกว่าก็ปรากฏขึ้นเกี่ยวกับความท้าทายโดยธรรมชาติของการจัดการระบบแบบกระจาย (distributed systems) ที่มีความซับซ้อนอย่างมหาศาล และว่าวิธีการดั้งเดิมในการสร้างความน่าเชื่อถือนั้นเพียงพอสำหรับระดับคลาวด์แล้วหรือไม่
ปัญหา Race Condition ของ DNS ที่จุดประกายทุกอย่าง
การขัดข้องเริ่มต้นขึ้นด้วยปัญหาคลาสสิกของระบบแบบกระจาย นั่นคือเมื่อ DNS Enactor หลายตัวที่ทำงานอย่างอิสระใน Availability Zones ต่างกันขาดการประสานงานกัน DNS Enactor หนึ่งตัวประสบความล่าช้าอย่างผิดปกติขณะประมวลผลการอัปเดต ในขณะที่อีกตัวทำงานนำหน้ากับแผนงานที่ใหม่กว่า จังหวะเวลาดังกล่าวสร้างพายุที่สมบูรณ์แบบเมื่อแผน DNS ที่ล้าสมัยเขียนทับแผนปัจจุบัน จากนั้นกระบวนการทำความสะอาดก็ลบแผนที่ใช้งานอยู่ทั้งหมด สิ่งนี้ทำให้ endpoint ระดับภูมิภาคของ DynamoDB ไม่มีที่อยู่ IP เหลืออยู่ ซึ่งส่งผลให้ไม่สามารถเข้าถึงบริการได้อย่างมีประสิทธิภาพ
สิ่งที่ทำให้วิศวกรกังวลเป็นพิเศษคือการขาดการป้องกันพื้นฐานของระบบแบบกระจายที่เห็นได้ชัด ดังที่ผู้ใช้ท่านหนึ่งแสดงความคิดเห็นว่า ฟังดูเหมือนเป็นกรณีศึกษาเรื่อง 'การสร้างอัลกอริทึมระบบแบบกระจายขึ้นมาใช้เอง' โดยไม่มีการลงทุนล่วงหน้าในการนำระบบแบบกระจายที่แท้จริงและแข็งแรงมาประยุกต์ใช้ ระบบขาดการดำเนินการ compare-and-swap ที่เหมาะสม หรือการตรวจสอบเวอร์ชัน ซึ่งอาจป้องกันไม่ให้แผนข้อมูลที่ล้าสมัยเขียนทับข้อมูลที่ใหม่กว่าได้
ระบบภายในของ AWS ที่ถูกกล่าวถึง
- DNS Planner: ตรวจสอบสถานะของ load balancer และสร้างแผน DNS
- DNS Enactor: ทำการเปลี่ยนแปลง DNS ใน Route53 (ทำงานใน 3 AZs)
- DWFM (Droplet Workflow Manager): จัดการเซิร์ฟเวอร์ทางกายภาพสำหรับ EC2
- Network Manager: จัดการการกระจายการตั้งค่าเครือข่าย
- NLB Health Check Subsystem: ตรวจสอบสถานะของ load balancer node
ความล้มเหลวแบบโดมิโนเผยให้เห็นปัญหาทางสถาปัตยกรรมที่ลึกยิ่งขึ้น
ในขณะที่ปัญหา DNS ถูกแก้ไขภายในไม่กี่ชั่วโมง ความเสียหายที่แท้จริงมาจากความล้มเหลวแบบโดมิโนทั่วทั้งโครงสร้างพื้นฐานของ AWS ระบบ Droplet Workflow Manager (DWFM) ซึ่งจัดการเซิร์ฟเวอร์ทางกายภาพสำหรับ EC2 instances เข้าสู่สภาวะที่วิศวกรเรียกว่า congestive collapse ขณะที่ DWFM พยายามสร้างสัญญาเช่า (leases) ใหม่กับ droplets ทั่วทั้งกองเรือ EC2 ปริมาณงานที่มากมายก่ายกองสร้างการตอบรับแบบลูป (feedback loop) ที่การพยายามเชื่อมต่อหมดเวลาและเพิ่มงานลองเชื่อมต่อใหม่เข้าไปในคิวมากขึ้น ซึ่งขัดขวางไม่ให้เกิดความคืบหน้าใดๆ ไปข้างหน้า
เนื่องจากสถานการณ์นี้ไม่มีขั้นตอนการกู้คืนการดำเนินงานที่กำหนดไว้ วิศวกรจึงต้องดำเนินการด้วยความระมัดระวังในการพยายามแก้ไขปัญหาเกี่ยวกับ DWFM โดยไม่ก่อให้เกิดปัญหาต่อไป
ข้อความยอมรับนี้ในรายงานของ Amazon ทำให้ชุมชนด้านเทคนิคตื่นตระหนกเป็นพิเศษ การที่ส่วนประกอบหลักของโครงสร้างพื้นฐาน EC2 เช่นนี้ขาดขั้นตอนการกู้คืนที่กำหนดไว้สำหรับรูปแบบความล้มเหลวดังกล่าว ชี้ให้เห็นถึงปัญหาที่ลึกกว่าด้วยความพร้อมในการดำเนินงาน (operational readiness) วิธีแก้ไขในที่สุด นั่นคือการควบคุมปริมาณงานขาเข้า (throttling) และการรีสตาร์ทโฮสต์ DWFM บางส่วน เป็นเสมือนการผ่าตัดฉุกเฉณบนระบบที่ยังทำงานอยู่
การถกเถียงเกี่ยวกับระบบที่ซับซ้อน
การขัดข้องครั้งนี้จุดประกายการอภิปรายอย่างจริงจังเกี่ยวกับวิธีที่เราคิดถึงความล้มเหลวในระบบที่ซับซ้อน วิศวกรจำนวนมากชี้ไปที่เรียงความของ Richard Cook เรื่อง How Complex Systems Fail ว่าให้บริบทที่สำคัญ Cook ให้เหตุผลว่าในระบบที่ซับซ้อนอย่างแท้จริง แนวคิดของการหาสาเหตุรากฐานเดียวเป็นสิ่งที่เข้าใจผิด เพราะความล้มเหลวเกิดขึ้นจากการรวมตัวของเงื่อนไขแฝง (latent conditions) ซึ่งแต่ละเงื่อนไขอาจไม่เป็นอันตรายหากอยู่เดี่ยวๆ
มุมมองนี้ท้าทายแนวทางการตอบสนองต่อเหตุการณ์แบบดั้งเดิม ดังที่ผู้แสดงความคิดเห็นหนึ่งอธิบาย เมื่อพิจารณาจากทรัพยากรที่มีจำกัด คุณควรตอบสนองต่อเหตุการณ์นี้โดยการตรวจสอบระบบจัดการ DNS ของคุณเพื่อหาปัญหา race condition หรือคุณควรหาวิธีทำให้ Droplet Manager รอดพ้นจากการตัดขาดจาก DynamoDB โดยไม่เข้าสู่สภาวะ congestive collapse คำตอบน่าจะเกี่ยวข้องกับทั้งสองอย่าง แต่การจัดลำดับความสำคัญว่าการปรับปรุงใดให้ผลตอบแทนในด้านความน่าเชื่อถือมากที่สุดนั้น ยากขึ้นเรื่อยๆ เมื่อระบบมีความซับซ้อนมากขึ้น
ความเป็นจริงในการดำเนินงาน กับ ความสมบูรณ์แบบในทางทฤษฎี
การอภิปรายเผยให้เห็นความตึงเครียดระหว่างแนวปฏิบัติที่ดีที่สุดของระบบแบบกระจายในทางทฤษฎี กับความเป็นจริงในการดำเนินงานของการให้บริการในระดับขนาดของ AWS ผู้แสดงความคิดเห็นหลายท่านที่มีประสบการณ์ในบริษัทเทคโนโลยีขนาดใหญ่ได้อธิบายถึงความท้าทายของการอยู่เวร (on-call) และการสะสมหนี้ทางเทคนิค (technical debt) อย่างค่อยเป็นค่อยไป ซึ่งทำให้ระบบเปราะบางมากขึ้นเมื่อเวลาผ่านไป
ผู้รับจ้างท่านหนึ่งแบ่งปันประสบการณ์ว่า ฉันไม่เคยทำงานในบริษัทที่ปฏิบัติต่อการอยู่เวรอย่างจริงจังเลย บนกระดาษ พวกเขาต่างก็บอกว่ามันสำคัญและตั้งค่า SLA ต่างๆ ไว้ทั้งหมด แต่ในความเป็นจริงแล้ว ไม่มีสิ่งรองรับที่เพียงพอ สิ่งนี้ชี้ให้เห็นว่าแม้แต่ที่ผู้ให้บริการคลาวด์รายใหญ่ ปัจจัยด้านมนุษย์และองค์กรอาจมีความสำคัญไม่น้อยไปกว่าด้านเทคนิค ในการรักษาความน่าเชื่อถือ
เหตุการณ์นี้ยังเน้นย้ำถึงความท้าทายของการพึ่งพาข้ามภูมิภาค (cross-region dependencies) แม้โมเดลภูมิภาคของ AWS จะถูกนำเสนอว่าเป็นอิสระโดยสมบูรณ์ แต่การขัดข้องครั้งนี้เผยให้เห็นว่าบริการระดับโลกหลายบริการยังคงพึ่งพา us-east-1 อยู่ ซึ่งสร้างจุดล้มเหลวเดียว (single point of failure) ที่ส่งผลกระทบต่อลูกค้าทั่วโลก นี่ไม่ใช่ครั้งแรกที่สิ่งนี้เกิดขึ้น ซึ่งชี้ให้เห็นว่าการกำจัดการพึ่งพาเหล่านี้มีความท้าทายมากกว่าที่ปรากฏ
บริการ AWS ที่ได้รับผลกระทบ
- หลัก: DynamoDB, EC2, Network Load Balancer
- การประมวลผล: Lambda, ECS, EKS, Fargate
- การจัดการตัวตน: IAM, AWS Management Console, Security Token Service
- การวิเคราะห์: Redshift
- ธุรกิจ: Amazon Connect
- สนับสนุน: Managed Workflows for Apache Airflow, Outposts, Support Center
มองไปข้างหน้า
Amazon ได้ดำเนินการทันทีแล้วโดยปิดการทำงานระบบอัตโนมัติ DNS ที่มีปัญหาทั่วโลก การแก้ไขที่พวกเขาวางแผนไว้รวมถึงการจัดการปัญหา race condition การเพิ่มการควบคุมความเร็ว (velocity controls) ให้กับการสลับการทำงานเมื่อ NLB health check ล้มเหลว และการสร้างการทดสอบที่ดีขึ้นสำหรับลำดับงานการกู้คืน DWFM แต่คำถามที่กว้างกว่ายังคงอยู่ องค์กรใดๆ สามารถคาดการณ์และป้องกันรูปแบบความล้มเหลวทั้งหมดในระบบที่ซับซ้อนขนาดนี้ได้จริงหรือ?
การอภิปรายในชุมชนด้านเทคนิคชี้ให้เห็นว่าเมื่อระบบมีความซับซ้อนมากขึ้น แนวทางของเราต่อความน่าเชื่อถือต้องพัฒนาขึ้นไปกว่าการหาและแก้ไขสาเหตุรากฐาน ไปสู่การออกแบบระบบที่สามารถลดระดับการทำงานอย่างนุ่มนวล (degrade gracefully) และฟื้นตัวได้อย่างรวดเร็ว การขัดข้องของ AWS ทำหน้าที่เป็นเครื่องเตือนใจว่าในระบบแบบกระจาย ความล้มเหลวเป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ความล้มเหลวครั้งใหญ่ไม่จำเป็นต้องเกิดขึ้น
การสนทนายังคงดำเนินต่อไปเกี่ยวกับว่าปัญญาประดิษฐ์ในปัจจุบันสามารถช่วยในสถานการณ์การแก้ไขปัญหาที่ซับซ้อนเช่นนี้ได้หรือไม่ โดยมีความเห็นที่แบ่งออกเป็นสองฝั่งว่าการจดจำรูปแบบเพียงอย่างเดียวสามารถแก้ปัญหาที่ต้องใช้ความเข้าใจอย่างลึกซึ้งเกี่ยวกับปฏิสัมพันธ์ของระบบได้หรือไม่ สิ่งที่ชัดเจนคือ เมื่อโครงสร้างพื้นฐานคลาวด์มีความสำคัญมากขึ้นต่อธุรกิจระดับโลก ผลประโยชน์ที่ได้จากการทำสิ่งนี้ให้ถูกต้องก็เพิ่มสูงขึ้นเรื่อยๆ
อ้างอิง: สรุปการขัดข้องของบริการ Amazon DynamoDB ในภูมิภาค Northern Virginia (US-EAST-1)