การเพิ่มขึ้นของ Traffic จากลูกค้ารายเดียวทำให้การเชื่อมต่อ Cloudflare-AWS ล้มเหลว เผยช่องโหว่ในการแยกเครือข่าย

เมื่อวันที่ 21 สิงหาคม 2025 รูปแบบ traffic ที่ผิดปกติของลูกค้ารายเดียวได้ทำให้การเชื่อมต่อระหว่าง Cloudflare และ Amazon Web Services ใน region us-east-1 ขัดข้องเป็นเวลาเกือบสี่ชั่วโมง เหตุการณ์นี้ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนเทคโนโลยีเกี่ยวกับการวางแผนความจุเครือข่าย การแยกลูกค้า และความเปราะบางของโครงสร้างพื้นฐานอินเทอร์เน็ต

การขัดข้องเริ่มต้นเมื่อลูกค้ารายหนึ่งเริ่มส่งคำขอขนาดใหญ่สำหรับเนื้อหาที่เก็บใน cache จาก AWS us-east-1 ซึ่งสร้าง response traffic ที่อิ่มตัวการเชื่อมต่อโดยตรงทั้งหมดระหว่างยักษ์ใหญ่ทางเทคโนโลยีทั้งสอง สิ่งที่ทำให้เกิดความเสียหายอย่างมากคือการไหลของ traffic จาก Cloudflare ไป AWS หมายความว่า Cloudflare กำลังทำให้ลิงก์เครือข่ายของตัวเองล้นด้วยการตอบสนองต่อคำขอที่ถูกต้องตามกฎหมาย

ไทม์ไลน์ของเหตุการณ์

• 16:27 UTC: การเพิ่มขึ้นของ traffic เริ่มต้น โดย traffic รวมจาก Cloudflare ไปยัง AWS เพิ่มขึ้นเป็นสองเท่า
• 16:57 UTC: AWS เริ่มถอน BGP prefixes บนลิงก์ที่มีความแออัด
• 17:22 UTC: การถอน BGP เพิ่มขึ้น ทำให้ traffic ที่หลุดหายและผลกระทบเพิ่มมากขึ้น
• 19:05 UTC: การจำกัดอัตราของลูกค้าที่เป็นปัญหาช่วยลดความแออัด
• 19:27 UTC: การดำเนินการ traffic engineering แก้ไขปัญหาความแออัด
• 20:07 UTC: AWS ดำเนินการคืนค่า BGP prefix เสร็จสมบูรณ์
• ระยะเวลารวม: ประมาณ 3 ชั่วโมง 40 นาที

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

ความท้าทายในการนำไปใช้ทางเทคนิค

ชุมชนได้อภิปรายอย่างกระตือรือร้นเกี่ยวกับวิธีที่ Cloudflare สามารถป้องกันเหตุการณ์ที่คล้ายกันในอนาคต การแก้ไขปัญหาที่เสนอด้วย traffic budget ต่อลูกค้าฟังดูตรงไปตรงมา แต่การนำไปใช้กลับซับซ้อน การประมวลผล packet เพื่อระบุว่าเป็นของลูกค้ารายใดก่อนที่จะทิ้งอาจช้ากว่าการส่งต่อ โดยเฉพาะเมื่อคิว edge router เต็มแล้ว

อย่างไรก็ตาม กรณีเฉพาะนี้เสนอเส้นทางที่ชัดเจนกว่า เนื่องจากปัญหาคือการตอบสนองของ Cloudflare มากกว่าคำขอที่เข้ามา บริษัทสามารถหยุดส่งการตอบสนองหรือส่งรหัส HTTP 429 (rate limit) เมื่อลูกค้าเกินการจัดสรรของพวกเขา ระบบ Linux สมัยใหม่ยังสามารถใช้โปรแกรม BPF-XDP เพื่อทิ้ง traffic ในระดับ driver ก่อนที่จะมีการประมวลผลที่สำคัญใดๆ เกิดขึ้น

มาตรการบรรเทาผลกระทบที่วางแผนไว้

• ระยะสั้น: การลดความสำคัญของการจราจรข้อมูลแบบเลือกสรรสำหรับลูกค้าที่เป็นสาเหตุของความแออัด
• ระยะกลาง: การอัปเกรดความจุของ Data Center Interconnect (DCI) แบบเร่งด่วน
• ระยะยาว: ระบบจัดการการจราจรข้อมูลที่ปรับปรุงแล้วพร้อมงบประมาณทรัพยากรต่อลูกค้า
• การประสานงาน: การปรับปรุงการประสานงานวิศวกรรมการจราจร BGP กับ AWS

การตรวจสอบความเป็นจริงของโครงสร้างพื้นฐาน

เหตุการณ์นี้ได้เน้นย้ำว่าความจุของ internet backbone มีข้อจำกัดอย่างน่าประหลาดใจ แม้แต่ระหว่างผู้ให้บริการรายใหญ่ ในขณะที่ ISP ขนาดเล็กอาจทำงานด้วยการเชื่อมต่อเพียง 10 Gbps กับ peering partner ลิงก์ Cloudflare-AWS ควรจะมีความจุที่สูงกว่ามากตามทฤษฎี แต่ชุมชนสังเกตว่าแม้จะมีการเชื่อมต่อหลาย 100 Gbps ลูกค้าที่มุ่งมั่นซึ่งมีการเข้าถึงทรัพยากรคอมพิวติ้งขนาดใหญ่ของ AWS อาจสามารถสร้าง traffic เพียงพอที่จะทำให้เกิดความแออัด

น่าประหลาดใจที่ cache-hit traffic ของ tenant รายเดียวสามารถทำให้ความจุ interconnect ของ Cloudflare ล้มได้

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

แผนภาพทางเทคนิคแสดงการไหลของข้อมูลระหว่างศูนย์ข้อมูล Cloudflare และ AWS โดยแสดงภาพปฏิสัมพันธ์ที่ส่งผลต่อเหตุการณ์ปัญหาการเชื่อมต่อเมื่อวันที่ 21 สิงหาคม 2025

รูปแบบความล้มเหลวแบบ Swiss Cheese

เหตุการณ์นี้เป็นตัวอย่างของสิ่งที่วิศวกรเรียกว่าความล้มเหลวแบบ Swiss Cheese - ปัญหาเล็กๆ หลายอย่างเรียงตัวกันเพื่อสร้างการขัดข้องครั้งใหญ่ Cloudflare ได้เคยชินกับการเชื่อมต่อ peering ขนาดใหญ่ที่ทำงานได้อย่างน่าเชื่อถือ ซึ่งอาจนำไปสู่ความประมาทเกี่ยวกับการรักษาระบบสำรองและการแก้ไขลิงก์รองที่เสื่อมสภาพอย่างรวดเร็ว

การอภิปรายของชุมชนเผยให้เห็นว่าการถอน route ของ AWS น่าจะเป็นแบบอัตโนมัติ ออกแบบมาเพื่อตรวจจับความแออัดและลด traffic โดยอัตโนมัติ แม้ว่าสิ่งนี้จะทำงานได้ดีตามปกติ แต่กลับส่งผลเสียเมื่อ backup route มีความจุไม่เพียงพอ ทำให้ปัญหาที่จัดการได้กลายเป็นการขัดข้องในวงกว้าง

ปัจจัยทางเทคนิคที่ส่งผลต่อการขัดข้อง

• การเพิ่มขึ้นอย่างกะทันหันของ traffic จากลูกค้ารายเดียวจาก AWS us-east-1 ไปยัง Cloudflare
• การเชื่อมต่อ direct peering link หนึ่งเส้นทำงานที่ความจุ 50% เนื่องจากความเสียหายที่เกิดขึ้นก่อนหน้านี้
• ความจุของ Data Center Interconnect (DCI) ไม่เพียงพอสำหรับ traffic ที่ถูกเปลี่ยนเส้นทาง
• การถอน BGP route อัตโนมัติของ AWS ได้เปลี่ยนเส้นทาง traffic ไปยังลิงก์สำรองที่มีภาระเกินกำลัง
• จำเป็นต้องมีการแทรกแซงด้วยตนเองสำหรับการจำกัดอัตราและการจัดการ traffic

มองไปข้างหน้า

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

บทเรียนที่กว้างขึ้นสำหรับชุมชนโครงสร้างพื้นฐานอินเทอร์เน็ตชัดเจน: เมื่อ cloud computing ช่วยให้ลูกค้าสามารถสร้าง traffic ในปริมาณที่ไม่เคยมีมาก่อนตามต้องการ ผู้ให้บริการต้องสร้างระบบการแยกและ rate limiting ที่ซับซ้อนมากขึ้น ยุคของการจัดหา pipe ขนาดใหญ่และหวังว่าจะดีที่สุดอาจจะใกล้จะสิ้นสุดแล้ว

อ้างอิง: Cloudflare incident on August 21, 2025

แว่นขยายเป็นสัญลักษณ์ของความมุ่งมั่นของ Cloudflare ในการตรวจสอบและปรับปรุงระบบการจัดการการรับส่งข้อมูลเพื่อป้องกันการหยุดทำงานในอนาคตและเสริมสร้างความยืดหยุ่นของโครงสร้างพื้นฐาน