Subscribe to receive notifications of new posts:

ระบบ Cloudflare ขัดข้องเมื่อวันที่ 21 มิถุนายน 2022

2022-06-21

2 min read
Cloudflare outage on June 21, 2022

บทนำ

เมื่อวันที่ 21 มิถุนายน 2022 ที่ผ่านมา Cloudflare ประสบปัญหาระบบขัดข้องซึ่งส่งผลต่อการรับส่งข้อมูลในศูนย์ข้อมูล 19 แห่งของเรา ซึ่งศูนย์ข้อมูลทั้ง 19 แห่งเหล่านี้เป็นศูนย์ที่ใหญ่ที่สุดของเราและจัดการการรับส่งข้อมูลทั่วโลกในสัดส่วนที่สูงมาก เหตุระบบขัดข้องเป็นผลมาจากการเปลี่ยนแปลงที่เป็นส่วนหนึ่งของโครงการระยะยาวเพื่อเพิ่มความยืดหยุ่นภายในศูนย์ข้อมูลที่ใหญ่ที่สุดของเรา เนื่องจากศูนย์เหล่านี้เป็นส่วนสำคัญของโครงสร้างพื้นฐานของเรา และรองรับปริมาณการรับส่งข้อมูลของ Cloudflare ในสัดส่วนที่สูง การเปลี่ยนแปลงการกำหนดค่าเครือข่ายภายในตำแหน่งที่ตั้งเหล่านั้นเป็นเหตุให้ระบบขัดข้อง โดยระบบเริ่มขัดข้องเมื่อเวลา 06:27 ตามเวลา UTC แต่เมื่อเวลา 06:58 ตามเวลา UTC ศูนย์ข้อมูลแห่งแรกกลับมาออนไลน์ได้อีกครั้ง และศูนย์ข้อมูลทั้งหมดกลับมาออนไลน์และทำงานได้ตามปกติอีกครั้งเมื่อเวลา 07:42 ตามเวลา UTC

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

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

ภูมิหลัง

ตลอดช่วง 18 เดือนที่ผ่านมา Cloudflare ทำงานมาโดยตลอดเพื่อปรับเปลี่ยนศูนย์ข้อมูลที่ใหญ่ที่สุดทั้งหมดของเราให้กลายเป็นสถาปัตยกรรมที่ซับซ้อนมากขึ้น โดยปัจจุบัน เราได้พลิกโฉมศูนย์ข้อมูล 19 แห่งของเราให้ก้าวสู่การเป็นสถาปัตยกรรมลักษณะนี้ ซึ่งเรียกขานเป็นการภายในว่า Multi-Colo PoP (MCP): อัมสเตอร์ดัม, แอตแลนต้า, แอชเบิร์น, ชิคาโก, แฟรงก์เฟิร์ต, ลอนดอน, ลอสแองเจลิส, มาดริด, แมนเชสเตอร์, ไมอามี, มิลาน, มุมไบ, นวร์ก, โอซาก้า, เซาเปาโล, ซานโฮเซ, สิงคโปร์, ซิดนีย์, โตเกียว

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

สถาปัตยกรรมใหม่นี้ช่วยให้เราปรับปรุงความน่าเชื่อถือได้อย่างมีนัยสำคัญ เรายังสามารถทำการบำรุงรักษาในสถานที่เหล่านี้ได้โดยไม่ส่งผลต่อการรับส่งข้อมูลของลูกค้า เนื่องจากสถานที่เหล่านี้มีสัดส่วนการรับส่งข้อมูล Cloudflare ที่มีนัยสำคัญ ปัญหาอะไรก็ตามที่เกิดจากที่นี่อาจส่งผลกระทบในวงกว้าง และเป็นเรื่องน่าเศร้าที่เรื่องนี้เกิดขึ้นแล้วที่นี่วันนี้

เส้นเวลาของเหตุการณ์ (UTC) และผลกระทบ

การเข้าถึงบนอินเทอร์เน็ตจะเกิดขึ้นได้ เครือข่ายอย่าง Cloudflare จะใช้โปรโตคอลที่เรียกว่า BGP ในฐานะที่เป็นส่วนหนึ่งของโปรโตคอลนี้ ผู้ให้บริการจะกำหนดนโยบายที่เป็นตัวเลือกว่าให้มี prefix (กลุ่มที่อยู่ IP ที่อยู่ใกล้เคียงกัน) ใดบ้าง ที่จะประกาศไปยังเพียร์ต่างๆ (เครือข่ายอื่น ๆ ที่พวกเขาเชื่อมต่อ) หรือยอมรับการประกาศจากเพียร์เหล่านั้น

นโยบายเหล่านี้จะมีองค์ประกอบย่อยๆ ซึ่งได้รับการประเมินตามลำดับ ผลลัพธ์ขั้นสุดท้ายคือ prefix ที่ระบุ จะมีการประกาศหรือไม่ประกาศ การเปลี่ยนแปลงนโยบายอาจหมายความว่าจะไม่มีการประกาศ prefix ที่ประกาศก่อนหน้านี้อีกต่อไป ซึ่งในกรณีนี้ prefix จะถูกลบออกและที่อยู่ IP เหล่านั้นก็จะไม่สามารถเข้าถึงได้ทางอินเทอร์เน็ตได้อีกต่อไป

ขณะที่เรานำการเปลี่ยนแปลงดังกล่าวมาใช้กับนโยบายการประกาศ prefix การเรียงลำดับคำต่าง ๆ ใหม่ ทำให้เราต้องถอนซับเซ็ตที่สำคัญของ prefix ออกด้วย

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

03:56: เรานำการเปลี่ยนแปลงมาใช้กับตำแหน่งที่ตั้งแรกของเรา สถานที่ตั้งของเราทุกแห่งไม่ได้รับผลกระทบจากการเปลี่ยนแปลง เนื่องจากสถานที่เหล่านี้ใช้สถาปัตยกรรมแบบเก่า
06:17: การเปลี่ยนแปลงนี้นำไปใช้กับสถานที่ตั้งที่ใหญ่ที่สุดของเรา แต่ไม่ใช่สถานที่ที่มีสถาปัตยกรรมใหม่
06:27: มีการนำการเปลี่ยนแปลงออกใช้กับสถานที่ที่ใหญ่ที่สุดของเราที่มาพร้อมสถาปัตยกรรมใหม่ และการเปลี่ยนแปลงนี้นำไปใช้กับส่วนแกนหลักของเราด้วย นี่คือตอนที่เกิดเหตุการณ์ดังกล่าวขึ้น ทำให้ศูนย์ข้อมูลทั้ง 19 แห่งออฟไลน์ลงอย่างฉับพลันทันที
06:32: Cloudflare ประกาศแจ้งเหตุการณ์เป็นการภายใน
06:51: ทำการเปลี่ยนแปลงครั้งแรกบนเราเตอร์เพื่อตรวจสอบถึงต้นตอที่แท้จริงที่อาจเป็นไปได้
06:58: พบต้นเหตุของปัญหาและทำความเข้าใจ เริ่มดำเนินการเพื่อแก้ไขการเปลี่ยนแปลงที่เป็นปัญหา
07:42: การคืนค่ากลับในลำดับสุดท้ายเสร็จเรียบร้อย การดำเนินการนี้ล่าช้าออกไปเนื่องจากทีมวิศวกรเครือข่ายต้องตรวจสอบการเปลี่ยนแปลงที่แต่ละส่วนทำขึ้นมา คืนค่าจากการคืนค่าก่อนหน้านั้น เป็นเหตุให้ปัญหากลับมาเกิดขึ้นอีกเป็นระยะๆ
08:00: ปิดเหตุการณ์

ความสำคัญของศูนย์ข้อมูลเหล่านี้เห็นได้อย่างชัดเจนจากจำนวนคำขอสำเร็จที่เราส่งค่ากลับทั่วโลก:

แม้ว่าศูนย์ข้อมูลเหล่านี้จะเป็นเพียงส่วนเล็ก ๆ ของเครือข่ายทั้งหมดของเรา (4%) แต่ 50% ของคำขอทั้งหมดของเราได้รับผลกระทบ เหตุการณ์ทำนองนี้ปรากฏในแบนด์วิดธ์ขาออกของเราด้วย:

คำอธิบายทางเทคนิคของข้อผิดพลาดและวิธีที่เกิดข้อผิดพลาด

เราพยายามอย่างต่อเนื่องเพื่อกำหนดค่าโครงสร้างพื้นฐานให้เป็นมาตรฐาน ส่วนหนึ่งของความพยายามดังกล่าวคือการเปลี่ยนแปลงเพื่อสร้างมาตรฐานให้กับชุมชน BGP ที่เรารวมเข้ากับซับเซ็ตของ prefix ที่เราประกาศ กล่าวให้เฉพาะเจาะจงคือ เรากำลังเพิ่มชุมชนข้อมูลไว้รวมกับ prefix ในไซต์ของเรา prefix เหล่านี้ช่วยให้โหนดการประมวลผลของเราสามารถสื่อสารระหว่างกัน หรือเชื่อมต่อกับข้อมูลต้นทางของลูกค้าได้ นอกจากนี้ ส่วนหนึ่งของขั้นตอนการเปลี่ยนแปลงที่ Cloudflare คือการสร้างตั๋วคำขอเปลี่ยนแปลง (CR) ซึ่งรวมถึงการดำเนินการเปลี่ยนแปลงแบบ dry-run และขั้นตอนการเปลี่ยนแปลงแบบเป็นลำดับขั้น แต่ก่อนจะเปิดตัวขั้นตอนดังกล่าวนี้ ทีมวิศวกรจะต้องเข้ามาตรวจสอบก่อน ซึ่งน่าเสียดายที่ในกรณีนี้ ขั้นตอนนั้นไม่เล็กพอที่จะตรวจจับข้อผิดพลาดได้ก่อนส่งกระทบโครงสร้างทั้งหมดของเรา

การเปลี่ยนแปลงเกิดขึ้นในลักษณะนี้บนเราเตอร์ตัวใดตัวหนึ่ง:

[edit policy-options policy-statement 4-COGENT-TRANSIT-OUT term ADV-SITELOCAL then]
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add TLL01;
+      community add EUROPE;
[edit policy-options policy-statement 4-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL then]
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add TLL01;
+      community add EUROPE;
[edit policy-options policy-statement 6-COGENT-TRANSIT-OUT term ADV-SITELOCAL then]
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add TLL01;
+      community add EUROPE;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL then]
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add TLL01;
+      community add EUROPE;

การเปลี่ยนแปลงดังกล่าวไม่เป็นอันตราย และเพิ่งเพิ่มเติมข้อมูลใหม่ ๆ รวมเข้ากับการประกาศ prefix เหล่านี้ การเปลี่ยนแปลงบนโครงสร้างมีดังต่อไปนี้:

[edit policy-options policy-statement AGGREGATES-OUT]
term 6-DISABLED_PREFIXES { ... }
!    term 6-ADV-TRAFFIC-PREDICTOR { ... }
!    term 4-ADV-TRAFFIC-PREDICTOR { ... }
!    term ADV-FREE { ... }
!    term ADV-PRO { ... }
!    term ADV-BIZ { ... }
!    term ADV-ENT { ... }
!    term ADV-DNS { ... }
!    term REJECT-THE-REST { ... }
!    term 4-ADV-SITE-LOCALS { ... }
!    term 6-ADV-SITE-LOCALS { ... }
[edit policy-options policy-statement AGGREGATES-OUT term 4-ADV-SITE-LOCALS then]
community delete NO-EXPORT { ... }
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add AMS07;
+      community add EUROPE;
[edit policy-options policy-statement AGGREGATES-OUT term 6-ADV-SITE-LOCALS then]
community delete NO-EXPORT { ... }
+      community add STATIC-ROUTE;
+      community add SITE-LOCAL-ROUTE;
+      community add AMS07;
+      community add EUROPE;

หากดู Diff นี้คร่าว ๆ ในเบื้องต้นจะให้ความรู้สึกว่าการเปลี่ยนแปลงนี้เหมือนกัน แต่จริง ๆ แล้ว มันไม่เกี่ยวกับเรื่องนี้ หากเราเน้นที่ส่วนที่ 1 ของ Diff เราอาจหาสาเหตุได้ชัดเจนยิ่งขึ้น:

!    term REJECT-THE-REST { ... }
!    term 4-ADV-SITE-LOCALS { ... }
!    term 6-ADV-SITE-LOCALS { ... }

ในรูปแบบ Diff นี้ เครื่องหมายอัศเจรีย์ด้านหน้าคำต่าง ๆ หมายถึงการเรียงลำดับคำใหม่ ในกรณีนี้ คำหลาย ๆ คำจะถูกเลื่อนขึ้น และมีการเพิ่มคำสองคำที่ด้านล่าง กล่าวให้เฉพาะเจาะจงคือ คำว่า 4-ADV-SITE-LOCALS ถูกย้ายจากด้านบนลงมาด้านล่าง ตอนนี้ คำนี้จะมาอยู่หลังคำว่า REJECT-THE-REST และชื่อนี้บอกถึงการปฏิเสธได้อย่างชัดแจ้ง

term REJECT-THE-REST {
    then reject;
} 

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

นอกเหนือจากการที่ไม่สามารถติดต่อกับต้นทางได้แล้ว การนำ prefix ภายในของไซต์เหล่านี้ออก ยังทำให้ระบบ Multimog ของโหลดบาลานซ์ภายในของเรา (อีกรูปแบบของ Unimog load-balancer ของเรา) หยุดการทำงานด้วย เนื่องจากไม่สามารถส่งต่อคำขอระหว่างเซิร์ฟเวอร์ใน MCP ได้ ซึ่งหมายความว่าคลัสเตอร์ประมวลผลที่เล็กกว่าของเราใน MCP ได้รับปริมาณการรับส่งข้อมูลเท่ากับคลัสเตอร์ที่ใหญ่ที่สุดของเรา ทำให้คลัสเตอร์ที่มีขนาดเล็กกว่าอยู่ในสภาวะโอเวอร์โหลด

ขั้นตอนการแก้ไขและติดตามผล

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

สิ่งที่เราดำเนินการในทันทีคือ:

ขั้นตอน: แม้ว่าโปรแกรม MCP ได้รับการออกแบบมาเพื่อปรับปรุงความพร้อมใช้งาน ช่องว่างระหว่างขั้นตอนวิธีการอัปเดตศูนย์ข้อมูลเหล่านี้ทำให้เกิดผลกระทบในวงกว้างขึ้นโดยเฉพาะภายในตำแหน่งที่ตั้งของ MCP แม้ว่าเราจะใช้กระบวนการ stagger รองรับการเปลี่ยนแปลงนี้ แต่นโยบาย stagger ไม่ได้รวมศูนย์ข้อมูล MCP ไว้จนกว่าจะถึงขั้นตอนสุดท้าย ขั้นตอนการเปลี่ยนแปลงและระบบอัตโนมัติจำเป็นต้องรวมขั้นตอนการทดสอบและปรับใช้เฉพาะ MCP เพื่อยืนยันว่าจะไม่เกิดผลลัพธ์ที่ไม่คาดคิด

สถาปัตยกรรม: การกำหนดค่าเราเตอร์ที่ไม่ถูกต้องทำให้ไม่สามารถประกาศเส้นทางที่เหมาะสมไปยัง Edge ของเราได้ จนเป็นสาเหตุให้การรับส่งข้อมูลไม่เคลื่อนไหวไปยังโครงสร้างพื้นฐานของเรา นอกจากนี้ประกาศนโยบายที่ทำให้เกิดการประกาศเส้นทางที่ไม่ถูกต้องจะได้รับการออกแบบใหม่ทั้งหมดเพื่อป้องกันการออกคำสั่งผิดโดยไม่ตั้งใจ

การทำงานอัตโนมัติ: ชุดการทำงานอัตโนมัติของเรามาพร้อมโอกาสมากมายที่จะช่วยบรรเทาผลกระทบบางส่วนหรือทั้งหมดที่มองเห็นได้จากเหตุการณ์นี้ โดยในขั้นต้น เราจะเน้นที่การปรับปรุงระบบอัตโนมัติที่บังคับใช้นโยบาย stagger ที่ปรับปรุงให้ดีขึ้นเพื่อรองรับการเปิดตัวการกำหนดค่าเครือข่ายและให้การย้อนกลับแบบ “commit-confirm” โดยอัตโนมัติ การปรับปรุงแบบเดิมจะช่วยลดผลกระทบโดยรวมได้อย่างมาก และการปรับปรุงครั้งหลังจะลดเวลาในการแก้ไขในช่วงที่เกิดเหตุการณ์ลงอย่างเห็นได้ชัด

บทสรุป

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

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Outage (TH)Post Mortem (TH)ไทย

Follow on X

Tom Strickx|@tstrickx
Cloudflare|@cloudflare