เปิดสาเหตุ AWS ล่มระนาว ต้นตอจากจุดเล็ก ๆ ที่คาดไม่ถึง
-cropped-1761365253286.jpg?w=1200&q=75)
เหตุการณ์ Amazon Web Services (AWS) ล่มครั้งใหญ่ที่กระทบผู้ใช้ทั่วโลกนานกว่า 15 ชั่วโมง มีต้นตอมาจากความผิดพลาดเพียงจุดเดียว (Single Point of Failure) ในระบบจัดการ DNS ของ DynamoDB ซึ่งเป็นความผิดพลาดที่ลุกลามบานปลายไปทั่วทั้งเครือข่าย
เรียกว่าสะเทือนกันทั้งวงการ เมื่อ Amazon Web Services (AWS) เกิดเหตุล่มครั้งใหญ่เป็นเวลานานถึง 15 ชั่วโมง 32 นาที ส่งผลกระทบเป็นวงกว้างไปทั่วโลก โดย Ookla บริษัทวิเคราะห์เครือข่ายระบุว่า บริการ DownDetector ของตนได้รับรายงานปัญหากว่า 17 ล้านครั้งจาก 3,500 องค์กรทั่วโลก โดยเฉพาะในสหรัฐฯ, สหราชอาณาจักร และเยอรมนี ซึ่งบริการที่โดนผลกระทบหนัก ๆ ก็มีทั้ง Snapchat, AWS เอง และ Roblox จนถูกยกให้เป็นหนึ่งในเหตุการณ์อินเทอร์เน็ตล่มครั้งใหญ่ที่สุดเท่าที่เคยบันทึกมา
ทาง Amazon ออกมาชี้แจงถึงต้นตอของปัญหาว่ามาจาก Software Bug ในระบบจัดการ DNS ของ DynamoDB ซึ่งเป็นระบบหลังบ้านสำคัญ โดยเกิดข้อผิดพลาดที่เรียกว่า Race Condition (สถานการณ์ที่การทำงานของโปรแกรมขึ้นอยู่กับจังหวะเวลาที่ควบคุมไม่ได้) ภายในส่วนประกอบที่ชื่อว่า DNS Enactor
พูดง่าย ๆ คือ โปรแกรมตัวหนึ่งทำงานช้ากว่าปกติ ในขณะที่อีกตัวก็สร้างแผนงานใหม่ขึ้นมาซ้อน แล้วดันไปสั่งลบแผนงานเก่าที่ตัวแรกยังใช้ไม่เสร็จ ผลลัพธ์คือ IP Address ของระบบในโซนนั้นหายเกลี้ยง! ทำให้ระบบทั้งหมดค้างเติ่งและไม่สามารถอัปเดตอะไรต่อได้ จนต้องใช้คนเข้าไปแก้ไขด้วยตัวเอง ซึ่งความผิดพลาดนี้เริ่มต้นที่โซน US-East-1 ซึ่งเป็นโซนที่เก่าแก่และใช้งานหนักที่สุดของ AWS
ผลกระทบไม่ได้จบแค่ที่ DynamoDB เพราะมันลุกลามเป็นโดมิโน่ไปยังบริการอื่น ๆ เช่น EC2 ที่ต้องมารับภาระหนักจนทำงานล่าช้าตามไปด้วย แม้ว่า DynamoDB จะกลับมาใช้งานได้แล้ว แต่ผลกระทบต่อเนื่องก็ยังทำให้บริการอื่น ๆ ของ AWS เช่น Lambda และ Fargate มีปัญหาการเชื่อมต่อตามมาเป็นทอด ๆ
ที่น่าสนใจคือ Ookla ได้ให้ความเห็นเสริมว่า ปัญหาใหญ่ส่วนหนึ่งมาจากการที่ลูกค้าจำนวนมากกระจุกตัวใช้งานผ่านโซน US-East-1 เพียงแห่งเดียว เมื่อโซนนี้ล่ม ทุกอย่างที่พึ่งพามันอยู่ก็พังตามกันไปทั่วโลก บทเรียนครั้งนี้จึงไม่ใช่แค่การแก้ Bug แต่เป็นการย้ำเตือนเหล่าผู้ให้บริการ Cloud ทั้งหลายว่า การออกแบบสถาปัตยกรรมเพื่อลดความเสี่ยงจากความผิดพลาดเพียงจุดเดียว (Single Point of Failure) นั้นสำคัญกว่าการป้องกัน Bug เสียอีก
ดูเหมือนว่าบทเรียนราคาแพงครั้งนี้ คงทำให้หลายบริษัทต้องกลับไปทบทวนแผนสำรองของตัวเองกันยกใหญ่...ถ้ามีน่ะนะ
ความเห็น (0)
เข้าสู่ระบบเพื่อแสดงความเห็น
เข้าสู่ระบบยังไม่มีความเห็น
เป็นคนแรกที่แสดงความเห็นในบทความนี้