- การหยุดทำงานของ บริการคลาวด์รายใหญ่ที่สุดของโลกอย่าง AWS ทำให้เว็บไซต์และแอปนับพันหยุดชะงัก และทำให้เกิดคำเตือนว่าโครงสร้างพื้นฐานอินเทอร์เน็ตกำลัง พึ่งพาบริษัทจำนวนน้อยมากเกินไป
- บริการสำคัญอย่าง Snapchat, Roblox, Signal, Duolingo รวมถึง Lloyds Bank, Ring, HMRC และหน่วยงานสาธารณะ/การเงินล้วนอยู่ในขอบเขตผลกระทบของเหตุขัดข้องนี้
- AWS ระบุว่าเหตุขัดข้องเกิดจาก ข้อผิดพลาดระบบภายในรีเจียนทางตะวันออกของสหรัฐฯ และได้ปฏิเสธความเป็นไปได้ของการโจมตีทางไซเบอร์ โดยกู้คืนได้เกือบทั้งหมดภายในไม่กี่ชั่วโมง
- ผู้เชี่ยวชาญกล่าวว่า “ฐานของการอภิปรายเชิงประชาธิปไตยและวารสารศาสตร์ไม่ควรถูกผูกขาดอยู่กับบริษัทเพียงไม่กี่ราย” และเน้นย้ำความสำคัญของ การกระจายโครงสร้างพื้นฐานคลาวด์
- ถูกประเมินว่ารูปแบบที่ยึดบริษัทคลาวด์รายใหญ่เป็นศูนย์กลางได้เผยให้เห็น จุดอ่อนของอินเทอร์เน็ตระดับโลก และจุดประกายการถกเถียงเรื่อง อธิปไตยทางเทคโนโลยีของโครงสร้างพื้นฐานสาธารณะ
ภาพรวมเหตุขัดข้อง
- เกิดการหยุดทำงานขนาดใหญ่ระดับโลกจากข้อผิดพลาดภายใน AWS ในรีเจียน US-East-1 (รีเจียนตะวันออกสหรัฐฯ)
- เริ่มมีเหตุขัดข้องประมาณ 8.00 น. วันจันทร์ตามเวลาท้องถิ่น (16.00 น. ตามเวลาสหราชอาณาจักร)
- Amazon ระบุว่ามีการ API error rate และ latency เพิ่มขึ้น
- ตามข้อมูลของ Downdetector มีธุรกิจทั่วโลกมากกว่า 2,000 แห่งที่ได้รับผลกระทบ และผู้ใช้รายงานปัญหามากกว่า 1.9 ล้านคนในสหรัฐฯ·1 ล้านคนในสหราชอาณาจักร·410,000 คนในออสเตรเลีย
- AWS ชี้ว่าเป็นปัญหาของ ระบบย่อยการตรวจสอบตัวกระจายโหลด (load balancer) ภายใน และปฏิเสธความเป็นไปได้ของการโจมตีทางไซเบอร์
- รายงานว่าเกิดข้อผิดพลาดที่เกี่ยวข้องกับ DynamoDB ทำให้การตอบสนองของ API ล้มเหลว
- เพื่อป้องกันไม่ให้ทราฟฟิกพุ่งสูงเกินไป AWS ได้กำหนด การจำกัดจำนวนคำขอ แบบชั่วคราว
- AWS ประกาศเมื่อช่วงเย็นว่ากลับเข้าสู่การดำเนินงานปกติแล้ว แต่ยังมีบริการบางแห่งที่ยังคงรายงานปัญหาซ้ำต่อเนื่อง
ขอบเขตผลกระทบ
- บริการหลัก: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton และอื่นๆ อีกมาก
- ในสหราชอาณาจักรมีการเข้าถึงเว็บไซต์ของบริการทางการเงินอย่าง Lloyds, Halifax, Bank of Scotland ไม่ได้ และมีปัญหาในเว็บไซต์ HMRC (กรมสรรพากรสหราชอาณาจักร)
- ผู้ใช้ Ring Doorbell ระบุว่าบริการตรวจสอบการเปิดประตูถูกหยุดชะงัก ทำให้เกิดความไม่สะดวก
- บริการระดับโลกอย่าง Epic Games, Pokémon Go, Wordle รายงานว่าการเข้าถึงไม่ได้
การวิเคราะห์ผู้เชี่ยวชาญ
- Dr. Corinne Cath-Speth (Article 19): “การที่รากฐานของการอภิปรายทางประชาธิปไตยและสื่ออิสระต้องพึ่งพาโครงสร้างพื้นฐานของบริษัทไม่กี่รายเป็นเรื่องเสี่ยงมาก การกระจายโครงสร้างคลาวด์จึงจำเป็นเร่งด่วน”
- Cori Crider (Future of Technology Institute): “สหราชอาณาจักรควรหลุดพ้นจากการพึ่งพา Big Tech สหรัฐฯ AWS ต้องหยุดชะงักที่จุดเดียว ทำให้เศรษฐกิจสมัยใหม่ทั้งระบบหยุดชะงัก”
- Madeline Carr (UCL): “ด้วยพลังทางการเงินของผู้ให้บริการคลาวด์รายใหญ่ ระบบความปลอดภัยและการขยายตัวยังคงรักษาไว้ได้ แต่โครงสร้างที่ทำให้โลกทั้งโลกถูกผูกอยู่กับความเสี่ยงเดียวกันนั้นเสี่ยงมาก”
- Steven Murdoch (UCL): “สันนิษฐานว่าเหตุขัดข้องเกิดจาก ความผิดพลาดในการดำเนินงานภายใน AWS ไม่ใช่การโจมตีทางไซเบอร์”
การตอบสนองของรัฐบาลและกฎระเบียบ
- รัฐบาลสหราชอาณาจักร ประกาศว่าได้เปิดใช้งานช่องทางติดต่อฉุกเฉินร่วมกับ AWS และติดตามสถานการณ์การกู้คืน
- คณะกรรมการการเงินสภาสามัญสหราชอาณาจักรเรียกร้องให้ กำหนด AWS ให้เป็น ‘บุคคลที่สามที่สำคัญ (critical third party)’ ในภาคการเงิน
- หากได้รับการกำหนด จะอยู่ภายใต้การกำกับดูแลของหน่วยงานกำกับดูแลทางการเงิน และช่วยเสริม ความมั่นคงของโครงสร้างพื้นฐานทางการเงิน
- ประธานคณะกรรมการ Meg Hillier กล่าววิจารณ์ว่า AWS กล่าวอ้างว่ามอบ “ความยืดหยุ่น” แต่ในทางปฏิบัติกลับเผยให้เห็นความเปราะบางอย่างชัดเจน
ภูมิหลังและนัยสำคัญ
- AWS ครองสัดส่วนตลาดคลาวด์ทั่วโลกมากกว่า 30% และเป็นอันดับหนึ่ง
- ร่วมกับ Microsoft Azure และ Google Cloud กำลังก่อตัวเป็น โครงสร้างผูกขาดคลาวด์ 3 รายใหญ่
- ในปี 2024 ก็เคยเกิดเหตุ “หน้าจอสีน้ำเงิน” ทั่วโลกของเครื่อง Windows PC จาก ข้อผิดพลาดซอฟต์แวร์ของ CrowdStrike มาแล้ว
- เหตุการณ์ครั้งนี้ย้ำให้เห็นอีกครั้งว่า ความเสี่ยงเชิงระบบจากความเข้มข้นของโครงสร้างพื้นฐานดิจิทัล ตลอดจนการอภิปรายของรัฐบาลหลายประเทศเกี่ยวกับ อธิปไตยทางเทคโนโลยีและกลยุทธ์การกระจายคลาวด์ ได้ถูกกระตุ้นขึ้นอีกครั้ง
3 ความคิดเห็น
ไปต่อไป Naver Cloud!
“ไม่ชอบระบบคลาวด์ก็ไปจัดระบบขึ้นมาใช้งานเอง” แล้วมีเรื่องให้ถกเถียงกันต่อได้อีกไหมนะ
มัลติคลาวด์เหรอ? การติดตั้งและการดูแลระบบก็ไม่ใช่ให้ใครทำให้คุณหรอก
ความคิดเห็นจาก Hacker News
กำลังมีการพูดคุยอยู่เกี่ยวกับการหยุดทำงานของบริการหลายตัวใน AWS us-east-1 และมีเธรดยาวที่เกี่ยวข้องอยู่ที่ ที่นี่
แม้ในเหตุขัดข้องของ Fastly ปี 2021 ผู้เชี่ยวชาญคนเหล่านั้นก็เคยตั้งคำถามในทำนองเดียวกัน แต่ในทางปฏิบัติกลับไม่เห็นการเปลี่ยนแปลงที่ชัดเจน เหตุการณ์แบบนี้เมื่อผ่านไปหนึ่งสัปดาห์ก็ไม่ค่อยถูกพูดถึงในสื่ออีกต่อไป ผู้ที่อยู่ในงานจริงทราบดีว่าการดูแลระบบขนาด AWS เป็นเรื่องยากมาก แผนสำรองที่แท้จริงเพื่อรับมือกับเหตุการณ์เช่นนี้มีต้นทุนสูง จึงให้ผลตอบแทนคุ้มค่าสำหรับบริษัทส่วนใหญ่ไม่มาก หากเป็นบริการที่ 'ร้ายแรงจริงๆ' ก็ควรออกแบบให้รองรับความผิดพลาดได้ การที่เข้า Fortnite ไม่ได้ก็แสดงให้เห็นว่าการเตรียมพร้อมเช่นนั้นไม่ใช่เรื่องที่ทำได้ง่ายและต้นทุนสูงเช่นไร สื่อก็ไม่ค่อยพูดถึงความสำคัญของแนวคิด multi-region หรือ multi-cloud เมื่อสถานการณ์ปกติ แล้วค่อยพูดถึงเฉพาะตอนเกิดเหตุและลืมไปอย่างรวดเร็ว ในที่สุดทุกคนจึงเหลือแต่คำถามว่าเหตุใดทางเทคนิคจึงล้มเหลว คำตำหนิของผู้เชี่ยวชาญที่ไม่มีมาตรการตามมาไม่ค่อยมีความหมาย สิ่งที่ควรให้ความสำคัญมากกว่าคือการวิเคราะห์เหตุการณ์อย่างสร้างสรรค์และการทำ postmortem แบบไม่มีการโทษกัน
ผู้ที่เรียกว่า 'ผู้เชี่ยวชาญ' ในที่นี้คือคนที่ขาดประสบการณ์จริงด้าน infrastructure หรือการดำเนินงาน cloud โดยตรง ตัวอย่างเช่น Dr Corinne Cath-Speth เป็นนักมานุษยวิทยา Cori Crider เป็นทนายความ และ Madeline Carr เป็นอาจารย์รัฐศาสตร์ หมายความว่าพวกเขามักทำงานแบบเขียนบทความและสัมภาษณ์สื่อ มากกว่ามีประสบการณ์รัน hosting service จริง
หากจะวิจารณ์การพึ่งพา cloud ในเชิงเข้มข้น สุดท้ายคุณก็คงยอมรับว่าต้องยอมรับ downtime มากกว่า 16 ชั่วโมงต่อปีได้ ความเสียหายระดับไม่กี่ชั่วโมงอาจรู้สึกมากในระดับบุคคล แต่จริงๆ แล้วช่วง 8,742 ชั่วโมงที่เหลือที่มีความเสื่อมประสิทธิภาพอาจมีผลร้ายแรงกว่านั้น หากธุรกิจจะพังจาก downtime 16 ชั่วโมง ก็อาจแปลว่าเราหรืออีกฝ่ายไม่เข้าใจธุรกิจนั้นจริงๆ ฉันให้ความสำคัญกับระบบที่มีความพร้อมใช้งานสูง, geo redundancy และความทนทานสูงกว่า
ไม่จำเป็นต้องใช้เงินมหาศาลเสมอไป บริการแต่ละชนิดก็ไม่จำเป็นต้องรองรับระดับเสี่ยงเท่ากัน การใช้ผู้ให้บริการสองรายขึ้นไปสามารถทำให้ไม่ต้องรับผลกระทบพร้อมกันได้
สื่อพูดถึงว่า multi-region/multi-cloud redundancy มีประสิทธิผลต่ำด้วย หลายครั้งแม้จะดูเหมือนปัญหาอยู่ที่ region เดียว แต่ความจริงหลาย region มักได้รับผลกระทบพร้อมกัน การทำ multi-cloud hot standby จะมีต้นทุนสูงขึ้นมากเมื่อโครงสร้างพื้นฐานซับซ้อน และการนำไปใช้ทีหลังโดยไม่มีการวางแผนล่วงหน้าเป็นเรื่องยากมาก
รายงานของ AWS เองก็ชี้ว่า AWS ให้ความสำคัญกับ region หรือบริการบางอย่างมากเกินไป เช่น DynamoDB ภาพโครงสร้างแบบรวมศูนย์แบบนี้เห็นมานานกว่า 10 ปีแล้ว จึงเป็นคำถามว่าทำไมยังไม่เปลี่ยน ตอนนี้มีบริการมากกว่า 2,000 ตัวที่หยุดทำงานอย่างยาวนาน ดูรายละเอียดได้ที่ AWS Health Dashboard
ถามตัวเองดูว่า ถ้าพูดแทนคำว่า “cloud” หรือ “internet” ด้วย “คลังสินค้าในเวอร์จิเนีย” จะเกิดประโยชน์อย่างไร บทสนทนาอาจเหมือนว่า “บริการของเราพึ่งพาอยู่ทั้งหมดในคลังสินค้าเวอร์จิเนีย” หรือ “ไฟล์ทั้งหมดของฉันอยู่ในคลังสินค้าเวอร์จิเนีย” หรือ “คลังสินค้าเวอร์จิเนียถูกออกแบบมาเพื่อทนต่อสงครามนิวเคลียร์” เป็นต้น ต้นฉบับ
ปัจจุบันมีผู้ให้บริการ VPS มากมายอยู่แล้ว และมีตัวอย่างการย้ายไปที่นั่นแล้วสามารถลดต้นทุนที่ยืนยันกันต่อเนื่อง จึงทำให้เห็นว่าเรื่องที่จริงอาจเป็น vendor lock-in และการตลาดของ cloud
ตอนนี้องค์กรจำนวนมากไม่ได้ใช้ IaaS ระดับพื้นฐานอย่าง EC2 แบบเดิม แต่ใช้บริการ PaaS ระดับสูงของ AWS เช่น DynamoDB, RedShift มากกว่า Azure และ Google Cloud ก็อยู่ในสถานการณ์คล้ายกัน เมื่อผูกกับบริการระดับสูงเหล่านี้ การย้ายไป VPS อย่าง Hetzner หรือการ self-hosting จะต้องติดตั้งและดูแล AWS stack ใหม่ทั้งหมด ทำให้ซับซ้อนอย่างมาก ไม่ใช่เรื่องที่แก้ด้วยการติดตั้ง PostgreSQL อย่างเดียว
บทความที่บอกว่ากำลังลดต้นทุนด้วย VPS มักมีข้อโต้แย้งตามมาว่า “AWS คือ web-scale จึงแทบไม่ล่ม ส่วน VPS มี uptime แค่วันเดียวทั้งเดือน”
Amazon เองก็มี VPS อย่าง EC2 ด้วยเช่นกัน จึงสงสัยว่าคำถามคือ EC2 ก็ได้รับผลกระทบจากเหตุนี้ด้วยหรือไม่
ความคิดเห็นของผู้เชี่ยวชาญหลายคนดูเหมือนว่าชื่นชอบมิติทางการเมืองมากกว่าเทคนิคมากกว่า เช่น ประเด็นว่าระบบระดับประเทศพึ่งพาองค์กรต่างชาติแบบเรียลไทม์มากเกินไป โดยทั่วไปแล้วองค์กรทั่วไปอาจลดความซับซ้อนและความถี่การล่มได้โดยไม่ต้องพึ่งหลายผู้ให้บริการ การใช้เพียงผู้ให้บริการเดียวอาจทำให้ความถี่ downtime ดีขึ้นด้วย หากคุณคิดว่าจำเป็นก็ไม่ต้องใช้ multi-cloud
ผมเชื่อว่าอุตสาหกรรมโดยรวมตกอยู่ในกับดัก cloud vendor lock-in และไม่แน่ใจว่าจะกลับทางได้อย่างไร Docker ก็เป็นหนึ่งในสาเหตุของ lock-in ในลักษณะเดียวกับ hyperscaler รายใหญ่เช่นกัน
ในมุมวิศวกรปฏิบัติการหรือทีม support คนจริง เมื่อพบว่า AWS ทั้งระบบล่มตอนตีหนึ่งและทุกอย่างพังลง เราจะเห็นว่ามีใครก็ไม่เปลี่ยนสภาวะนั้นเลย
อยากรู้ว่า Docker คือประเด็นอะไร
แม้ตอนนี้จะออกจากสายงาน cloud มานานแล้ว แต่สมัยนั้นฟังก์ชันพื้นฐาน (primitive) ของทุกผู้ให้บริการก็กำลังถูกทำให้มาตรฐานสู่ระดับเดียวกัน แล้ว multi-cloud redundancy อาจแพงเกินไปหรือความเหลื่อมล้ำทางเทคโนโลยียังไกลเกินไป หรืองานทางธุรกิจจึงไม่จำเป็นต้องคุยเรื่องนี้ สไลด์ pets vs cattle
การ deploy และ operate บนหลาย cloud ทำให้ทีมแบกรับภาระการจัดการและความซับซ้อนทางความคิดสูงมาก ต้องใช้คนจำนวนมากในการคงความเชี่ยวชาญต่อ infrastructure ของหลาย cloud จึงไม่เหมาะกับทีมเล็กหรือทีมที่ต้องการความรวดเร็ว ความเรียบง่ายของการใช้เพียง cloud เดียวมักผูกกับ uptime ได้ตรงๆ ส่วนใหญ่องค์กรขนาดใหญ่ได้เปรียบจากการซื้อปริมาณมากใน cloud เดียวเพื่อลดต้นทุนต่อหน่วย และไม่มีใครถูกปลดเพียงเพราะเลือก AWS
เรายังเห็นว่าทั้งที่คลาวด์อื่นเจอเหตุใน region ของตนเอง เมื่อล่มก็แก้กันยากอยู่ดี ผู้ให้บริการแต่ละรายยังยึดมาตรฐานของตัวเอง 100% และ control plane ก็ยังเป็น Kubernetes จึงแทบทุกคนจึงยืนยันตัวเองไว้ที่ Kubernetes
ทุก cloud เสนอ compute ในราคาถูก แต่ egress network กลับแพงมาก ถ้าจะสร้าง multi-cloud ค่า traffic จะบานปลายอย่างรวดเร็ว ผมมองว่านี่อาจเป็นสิ่งที่ตั้งใจไว้แล้ว
ดูเหมือนรายได้ของ cloud จะมาจากค่า egress ด้วย เหตุนี้การทำ multi-cloud และแม้กระทั่ง redundancy ระหว่าง region/AZ ภายใน cloud เดียวก็สูงต้นทุนสำหรับ cloud และ app หลายตัว หากระบบระดับโลกล่มภายใน cloud เดียวแล้ว, redundancy ระหว่าง region จึงไม่ช่วยประโยชน์อะไร อีกทั้งเมื่อ cloud หนึ่งล่ม การย้าย traffic ไปยัง cloud อื่นก็ทำได้ยากและต้นทุนแรงงานสูงมากเมื่อเทียบผลลัพธ์ สำหรับแอปส่วนใหญ่คงดีกว่าเสีย downtime สักสองสามชั่วโมงและทุ่มเวลา/เงินไปที่เรื่องอื่น
ผู้ใช้จำนวนมากมีไฟล์และข้อมูลบน cloud และหากข้อมูลอยู่คลาวด์อื่นจากผู้ให้บริการ การบริหารบริการก็ไม่ใช่เรื่องง่ายและอาจไม่ดึงดูดลูกค้าใหม่ เมื่อผู้ให้บริการกลายเป็นมาตรฐานตลาด ลูกค้าก็มีแนวโน้มรวมข้อมูลไว้ที่เดียว จึงทำให้การใช้ที่เก็บข้อมูลบนทั้งสอง cloud ไม่ชอบจังหวะให้คุ้มค่า แม้ผมเองจะพยายามเริ่มต้นให้เป็น platform-independent แต่ในทางปฏิบัติพบว่าลูกค้าเป้าหมายทั้งหมดใช้ cloud เดียวกัน ทำให้ความซับซ้อนลดลง
ไม่สามารถคาดการณ์ได้ล่วงหน้าในตอนต้นปีนี้ว่าปีนี้ AWS us-east-1 จะสามารถให้ uptime ได้แค่ระดับหลัก 9 สองตัว
ในฐานะคนใช้ AWS มานานเกือบ 20 ปี ผมไม่ค่อยเข้าใจเหตุผลที่ใครบางคนเลือก us-east-1 ซึ่งทั้งปริมาณทราฟฟิกสูงสุดและความสำคัญสูงสุด แม้มันจะเป็น region ที่เก่าและไม่เสถียรที่สุด
สงสัยว่า EC2 instances ก็ได้รับผลกระทบจริงหรือไม่
มีคนคิดว่าเมื่อทุกคนล่มพร้อมกันก็เหมือนได้รับการยกเว้น แต่ในกรณีบริการที่คอยรองรับลูกค้าปกติ ความจริงขัดตรงกันข้าม
สาเหตุเหตุขัดข้องครั้งนี้คือปัญหาที่ subsystem ภายในที่ดูแล health check ของ network load balancer โดยอ้างอิงข้อมูลจาก AWS Service Health Dashboard