Cloudflare API ล่ม
(news.ycombinator.com)- เหตุขัดข้องของ Cloudflare Dashboard และ API ถูกปรับเป็นสถานะ resolved หลังจากย้าย Control Plane API และบริการผลิตภัณฑ์กลับไปยังศูนย์ข้อมูลหลักที่ Portland
- ฟังก์ชันของ Dashboard, Alerts, Zero Trust, WARP, Pages, Workers และบริการอื่น ๆ ที่พึ่งพาโครงสร้างพื้นฐาน API อาจพบ คำขอล้มเหลวและการแสดงข้อผิดพลาด
- Cloudflare ทำ failover บริการระหว่างประเมิน การสูญเสียพลังงานไฟฟ้า ในศูนย์ข้อมูล และหลังจากไฟฟ้าในศูนย์ข้อมูลหลักของอเมริกาเหนือกลับคืนมาบางส่วน ก็ย้ายบริการหลักไปยังศูนย์ข้อมูลสำรองเพื่อลดผลกระทบ
- ผลกระทบถูกแบ่งเป็น data plane และ control plane โดย Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates ฯลฯ มีสถานะสลับไปมาระหว่าง unavailable, degraded และ restored ตามช่วงเวลา
- Logpush logs และข้อมูลวิเคราะห์ บางส่วนสูญหายระหว่าง incident และแม้ logs ใกล้ช่วงสิ้นสุด incident อาจกู้คืนได้ แต่ระหว่างที่เหตุการณ์ยังดำเนินอยู่ยังไม่สามารถยืนยันขอบเขตผลกระทบทั้งหมดได้
ขอบเขตผลกระทบจากเหตุขัดข้องของ Dashboard และ API
- Cloudflare ตรวจสอบและกู้คืนปัญหาที่เกี่ยวข้องกับ Cloudflare Dashboard และ API โดยผู้ใช้อาจพบคำขอ Dashboard/API ล้มเหลวหรือมีการแสดงข้อผิดพลาด
- เหตุขัดข้องลุกลามไปยังหลายบริการที่พึ่งพาโครงสร้างพื้นฐาน Cloudflare API
- Alerts
- Dashboard functionality
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare ระบุว่าปัญหานี้ไม่กระทบต่อ การให้บริการไฟล์แคชของ Cloudflare CDN หรือฟีเจอร์ความปลอดภัยอื่น ๆ บน Cloudflare Edge
Failover หลังไฟฟ้าดับและการกู้คืน Portland
- Cloudflare ทำ failover บริการไปพร้อมกับประเมิน การสูญเสียพลังงานไฟฟ้า ที่กระทบต่อศูนย์ข้อมูล
- หลังจากไฟฟ้าในศูนย์ข้อมูลหลักของอเมริกาเหนือกลับคืนมาบางส่วน บริการหลักบางส่วนถูก failover ไปยัง ศูนย์ข้อมูลสำรอง เพื่อลดผลกระทบ
- ระหว่างกระบวนการกู้คืน มีการอัปเดตสถานะ “gradual improvement” และ “restore full functionality” ซ้ำหลายครั้ง
- ในขั้นตอนสุดท้าย ได้ย้าย Control Plane API และบริการผลิตภัณฑ์กลับไปยังศูนย์ข้อมูลหลักที่ Portland
- ตั้งแต่ 2023-11-06 17:00 UTC เริ่มกู้คืน Control Plane API และ Product Services ไปยัง primary HA datacenters ที่ Portland
- งานกู้คืนถูกแจ้งว่าจะใช้เวลาประมาณ 2 ชั่วโมง และในช่วงนี้ความพร้อมใช้งานของ Cloudflare API และ Dashboard อาจลดลง
- ตั้งแต่ 2023-11-06 18:30 UTC Pages และ Workers Control Plane API รวมถึง Product Services ก็เริ่มถูกกู้คืนไปยังศูนย์ข้อมูลหลักที่ Portland เช่นกัน
- หลังการกู้คืนเสร็จสิ้น Cloudflare ยังคงมอนิเตอร์เสถียรภาพและ edge case ต่าง ๆ
ฟังก์ชันที่เสียหายใน data plane
- ผลกระทบต่อ data plane ถูกนิยามว่าเป็นขอบเขตที่ฟังก์ชันโดยรวมของผลิตภัณฑ์ได้รับผลกระทบ บางส่วนหรือทั้งหมด
- บริการที่ได้รับผลกระทบตั้งแต่ช่วงแรกประกอบด้วย Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API และ Alert Notification System
- บริการหลักที่สถานะเปลี่ยนไประหว่างการกู้คืนมีดังนี้
- Logpush: ลูกค้าจำนวนมากไม่ได้รับ logs และ logs บางส่วนอาจสูญหาย ต่อมามี jobs จำนวนมากขึ้นถูกกู้คืน และแจ้งว่า jobs ส่วนใหญ่จะถูกกู้คืนภายใน 07:00 UTC
- Analytics / GraphQL API: analytics data ของลูกค้าจำนวนมากอยู่ในสถานะ unavailable บน Dashboard และ API ต่อมาข้อมูล analytics บางส่วนหรือส่วนใหญ่ถูกกู้คืน แต่ยังมี dataset บางส่วนคงเหลืออยู่
- Workers Analytics Engine: ยังคงอยู่ในสถานะ unavailable ในหลายอัปเดต
- Stream API: เปลี่ยนจาก not available ไปเป็น degraded performance but available และต่อมาเป็นสถานะ restored
- Healthchecks: เปลี่ยนจาก not available เป็น restored โดยไม่มี analytics และต่อมา Healthcheck analytics ก็เปลี่ยนเป็น restored ด้วย
- Radar: อยู่ในสถานะ degraded ต่อเนื่อง ก่อนที่ Cloudflare Radar จะกู้คืนเป็น operational status
- Support Services: ระหว่างที่ Support portal อยู่ในสถานะ unavailable ลูกค้า Enterprise สามารถเปิด ticket ผ่าน Enterprise support email address ได้ และต่อมา Portal·Phone·Chat กลับมาเป็นสถานะ operational
- CASB: อยู่ในสถานะ not available หรือ degraded performance โดยยังดู CASB Findings เดิมได้ แต่ scanning อยู่ในสถานะ offline ต่อมา CASB API กลับมา online และ scanning engine อยู่ระหว่างกู้คืน โดยแจ้งว่าไม่คาดว่าจะมีข้อมูลสูญหาย
- DEX: เปลี่ยนจากสถานะ not available เป็น DEX API online โดย fleet status, HTTP และ Traceroute Test Result data อยู่ระหว่างกู้คืน และคาดว่าจะกู้คืนได้ราว Saturday Nov 4 15:00 UTC
- DNS Updates: เปลี่ยนจาก degraded เป็น restored
การเปลี่ยนแปลง configuration ที่ถูกจำกัดใน control plane
- ผลกระทบต่อ control plane ถูกนิยามว่าเป็นขอบเขตที่ฟังก์ชันผลิตภัณฑ์ยังทำงานที่ edge แต่ การเปลี่ยนแปลง configuration เดิม ได้รับผลกระทบ
- บริการที่ได้รับผลกระทบตั้งแต่ช่วงแรกประกอบด้วย Magic Transit, Argo Smart Routing, Workers KV, WAF, Rate Limiting, Rules, WARP/Zero Trust Registration, Waiting Room, Load Balancing and Healthchecks, Cloudflare Pages, Zero Trust Gateway, DNS Authoritative and Secondary, Cloudflare Tunnel, Workers KV namespace operations, Magic WAN และ Cloudflare Images
- บริการหลักที่สถานะเปลี่ยนไประหว่างการกู้คืนมีดังนี้
- Cloudflare API: ถูกอัปเดตเป็นสถานะ degraded but accessible หรือ restored
- Cloudflare Pages: เปลี่ยนจาก degraded but online เป็น restored และช่วงหนึ่งการสร้าง/ลบ project รวมถึง direct upload deployments อยู่ในสถานะ degraded
- Magic Transit / Magic WAN: เปลี่ยนจากสถานะที่ไม่สามารถแก้ไขได้ ไปเป็น configuration plane ทำงานภายในได้ โดยมีคำแนะนำให้ติดต่อ account team หากต้องเปลี่ยนแปลงเร่งด่วน
- Argo Smart Routing: configuration ทำงานได้ แต่ smart updates และ analytics อยู่ในสถานะ offline
- Billing API / Registrar API: ทำได้เฉพาะ read-only operations อยู่ช่วงหนึ่ง
- Lists: การอัปเดต list item ถูกระงับชั่วคราว และแม้จะทำงานได้ใน Dashboard แต่ใน API อาจส่งกลับข้อผิดพลาด 429 ต่อมาเปลี่ยนเป็น restored status แต่ยังแก้ไขได้ผ่าน Dashboard เท่านั้นอยู่ช่วงหนึ่ง
- SSL / SSL for SaaS: มี SSL provisioning delay และ custom hostname validation delay ก่อนจะกลับเป็นสถานะ restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments ก็มีสถานะสลับไปมาระหว่าง degraded, unavailable และ restored ตามแต่ละอัปเดต
Logs ที่สูญหายและการวิเคราะห์หลังเหตุการณ์
- Cloudflare ระบุว่า Logpush logs และ analytics data บางส่วนสูญหาย ระหว่าง incident
- logs ใกล้ช่วงสิ้นสุด incident อาจกู้คืนได้ แต่ระหว่างที่เหตุการณ์ยังดำเนินอยู่ ยังไม่ทราบขอบเขตผลกระทบทั้งหมด
- ในอัปเดตหนึ่งระบุว่า logs และ analytics pipeline ทั้งหมดจะกลับมาอยู่ในสถานะ operational ภายใน Saturday 4th November 2023 7AM UTC
- ในอัปเดตภายหลังระบุว่า “logs ส่วนใหญ่สูญหายระหว่าง incident” และจะให้การประเมินทั้งหมดหลังจากแก้ไข incident แล้ว
- อ่านรายละเอียดเพิ่มเติมได้ที่ post-mortem on Cloudflare control plane and analytics outage ของ Cloudflare
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนที่ผมทำงานอยู่เมื่อราว ๆ 3 ปีก่อน โครงสร้างยังเป็นแบบที่ถ้า PDX ล่ม ระบบศูนย์กลาง ก็ล่มตามไปด้วย
เรื่องอย่างการป้องกัน DDoS นั้นจัดการกันในแต่ละ PoP อยู่แล้ว เลยยังรับมือ L3/L7 flood หรือการโจมตีรูปแบบใหม่ ๆ ได้ แต่แทบทุกอย่างที่เหลือจะคำนวณที่ PDX แล้วค่อยกระจายออกไปยังแต่ละ PoP ในรูปข้อมูลการตั้งค่า
ลำดับการไหลคือ PoP สร้าง/เก็บข้อมูล → ส่งไป PDX → คำนวณที่ PDX → กระจายอัปเดต/ข้อมูลกลับไปยัง PoP และถ้า PDX ตาย ฟังก์ชันจำนวนมากที่ต้องพึ่งข้อมูลล่าสุดก็จะค่อย ๆ ทำงานต่อไปในสภาพข้อมูลเก่า
ผมไม่คิดว่าหลังจากนั้นทุกอย่างจะเปลี่ยนไปหมด ดังนั้นแทนที่จะเป็นแค่ “API ล่ม” อย่างเดียว มีความเป็นไปได้สูงว่านี่คือภาวะประสิทธิภาพถดถอยที่ฟีเจอร์อย่าง load balancing, hierarchical cache, Argo Smart Routing, Warp/Zero Trust ทำงานอยู่บน ข้อมูลสถานะที่ล้าสมัย โดยไม่มีการอัปเดตจาก PDX
ต่อให้เป็นแค่ “API ล่ม” จริง ๆ ระบบอัตโนมัติของลูกค้าจำนวนมากก็ใช้ API call เพื่อบล็อกการโจมตีอยู่ดี สำหรับผู้โจมตีจึงนับเป็นหน้าต่างโอกาสที่ค่อนข้างใหญ่
ก่อนผมลาออก บริษัทกำลังลงทุนตั้ง AMS อยู่ แต่การทดสอบ failover ครั้งใหญ่ไม่เคยสำเร็จ และบริการส่วนใหญ่ที่ต้องใช้สถานะล่าสุดก็ไม่รู้จักวิธีนั้นด้วย
เสริมอีกอย่างคือระบบ observability ส่วนใหญ่ก็อิงกับ PDX เหมือนกัน ขอส่งกำลังใจให้ทีมและ SRE ที่ตอนนี้คงต้องวิ่งแก้ปัญหาแบบแทบมองอะไรไม่เห็น
Cloudflare บอกว่ากำลังประเมินการสูญเสียพลังงานไฟฟ้าที่ส่งผลต่อดาต้าเซ็นเตอร์ พร้อมกับดำเนินการ failover ของบริการไปด้วย
ไฟจากยูทิลิตีดับแล้วระบบสลับไปใช้เครื่องปั่นไฟ แต่เครื่องปั่นไฟก็ล้มเหลวเช่นกัน และดูเหมือนว่าไฟจากยูทิลิตีบางส่วนกลับมาแล้ว ทำให้กำลังกู้คืนบางส่วนของไซต์ได้
https://puck.nether.net/pipermail/outages/2023-November/0149...
แต่เจตนากับความเป็นจริงมักห่างกันเสมอ และผมเคยได้ยินเหตุผลหลายอย่างว่าทำไมการทำ failover อัตโนมัติหรือแบบฉุกเฉินด้วยมือไปยังดาต้าเซ็นเตอร์อีกซีกโลกหนึ่ง จึงไม่ใช่ทางออกที่ใช้ได้จริงสำหรับเวิร์กโหลดจำนวนมาก
Cloudflare ทำ chaos testing เยอะมาก และยังทดสอบการแยกเครือข่ายทั้งดาต้าเซ็นเตอร์เป็นประจำมากด้วย
อยากแอบเข้าไปนั่งฟังประชุมที่คุยกันว่างานนี้ต่างจากครั้งอื่นตรงไหนจริง ๆ
ผมสร้างเองโดยตรงแค่อย่างใดอย่างหนึ่ง แต่ฝั่งการตลาดมักเรียกรวมกันตลอด
ถ้าคุณไม่ใช่ผู้ใช้ระดับ enterprise ที่ปรับแต่ง topology ของ hierarchical cache ผ่าน API เอง ต่อให้ topology ของ cache เก่าไปหลายวันหรือหลายสัปดาห์ก็น่าจะยังพอไหว
แต่ก็อย่างที่บอก หลายอย่างอื่นอาจมีปัญหาได้
ไม่ว่าการบำรุงรักษาและการวางแผนล่วงหน้าจะดีแค่ไหน ก็ไม่มีทางทำให้ความเป็นไปได้ที่โครงสร้างพื้นฐานสำคัญจะล่มจากเงื่อนไขที่ไม่คาดคิดหรือไม่คุ้มต้นทุนจะเตรียมรับมือ ลดลงเหลือศูนย์ได้
ดูเหมือนว่า dashboard UI ใช้ API สำหรับการอัปเดต จึงน่าจะเป็นผลจากประสิทธิภาพการเข้าถึง API ที่ลดลง
แม้ใน UI จะดูเหมือนว่า DNS อัปเดตแล้ว แต่การเผยแพร่จริงไม่ได้เกิดขึ้น และหลังเหตุขัดข้องต้องลบโดเมนทั้งก้อนออกจาก Cloudflare dashboard แล้วสร้างใหม่ ถึงจะทำให้ SSL และการเผยแพร่ DNS กลับมาทำงานอีกครั้ง
ผ่านไป 12 ชั่วโมงแล้วปัญหาก็ยังไม่หาย
ผมกำลังเรียนคอร์สทำเพลงออนไลน์อยู่ วิดีโอถูกอัปโหลดไว้บน Cloudflare Stream และเล่นไม่ได้สักคลิป
https://www.cloudflare.com/products/cloudflare-stream/
ปัญหา จุดล้มเหลวจุดเดียว ของอินเทอร์เน็ตครึ่งโลกยังคงโผล่หัวขึ้นมาเรื่อย ๆ
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
ตอนแรกผมนึกว่ากระทบแค่ dashboard กับฟังก์ชันใน dashboard แต่พอเห็นว่า Cloudflare วิดีโอสตรีมมิงใช้ไม่ได้ ก็เลยเริ่มไม่แน่ใจว่าใช่แค่นั้นหรือเปล่า
ผมก็ไม่แน่ใจนัก แต่ Cloudflare ดูชวนให้รู้สึกไม่ค่อยสบายใจ
ไม่เข้าใจว่าทำไมหลายคนถึงคิดว่าปล่อยให้ส่วนใหญ่ของอินเทอร์เน็ตพึ่งพา บริษัทเดียว ได้
อาจเป็นเพราะการรับรู้ของผมเองก็ได้ แต่ Cloudflare ดูเหมือนผู้ท้าชิงที่น่าเชื่อถือซึ่งยืนสู้กับบริษัทยักษ์กึ่งผูกขาด และผมก็อยากให้มี Cloudflare แบบนี้มากขึ้น
เอาจริง ๆ ผมไม่ค่อยรู้จักบริการคล้ายกันที่ให้ free tier ใจกว้างแบบ Cloudflare
ถ้าใช้ TLS อย่างถูกต้อง มันควรให้ความปลอดภัยแบบ end-to-end แต่เมื่อใช้ Cloudflare แล้ว Cloudflare ก็เข้าถึงทราฟฟิก plaintext ทั้งหมดได้
ถ้าไซต์เล็ก ๆ มีโอกาสตกเป็นเป้า DoS สุดท้ายก็ต้องใช้ Cloudflare อยู่ดี
นี่เป็นความรู้สึกส่วนตัวของผม และก็อาจจะผิดก็ได้
เมื่อไม่กี่วันก่อนนึกว่าเขาเผลอคอมมิตบั๊กนั้นกลับเข้าไปอีกแล้ว
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
แต่ไม่ใช่ ดูเหมือนจะเป็น ไฟฟ้าขัดข้องที่ดาต้าเซ็นเตอร์หลัก
รายละเอียดอยู่ในคอมเมนต์อื่น ๆ
มาถึงจุดนี้ก็เหมือนสุนัขของพาฟลอฟไปแล้ว คือเริ่มรู้สึกสนุกกับเหตุขัดข้อง
นี่เป็น การล่มครั้งที่สอง แล้วในสัปดาห์เดียว
เสริมจากการตอบคอมเมนต์ที่ตายไปแล้ว เรื่องนี้ไม่เกี่ยวอะไรกับการเลือกภาษาโปรแกรมมิงเลย
DreamHost ก็มีปัญหาที่ PDX ตั้งแต่ 4:54 AM ตามเวลาแปซิฟิก
https://www.dreamhoststatus.com
มีรายงานว่า Flexential PDX02 สูญเสียไฟฟ้าในช่วงเวลาใกล้เคียงกับตอนที่เหตุการณ์นี้เริ่มขึ้น
Cloudflare เพิ่งประกาศว่ากำลังดำเนินการแก้ไขบริการขัดข้องไปพร้อมกับประเมินเหตุไฟฟ้าดับที่ส่งผลต่อดาต้าเซ็นเตอร์
ฝั่ง Flexential ที่เราใช้มีเครื่องปั่นไฟ 5 เครื่อง แบตเตอรี่สำรองใต้ดิน และโซนแยกกั้น
สิ่งที่น่าประทับใจที่สุดคือ หน้าสถานะ ใช้งานได้จริง
แน่นอนว่าอาจโฮสต์ไว้ที่อื่น แต่ทุกครั้งที่เกิดเหตุใหญ่ก็ทำให้นึกถึงเรื่องนี้แล้วหลุดขำตลอด
ดูไม่ค่อยดีเท่าไร
หวังว่าเหตุการณ์นี้จะไม่ทำให้พวกเขาเลิก ใช้บริการตัวเอง
ฝั่ง Vercel deployments และ edge functions ก็ใช้งานไม่ได้เหมือนกัน
ในหน้าสถานะบอกว่า “เราระบุได้แล้วว่าต้นตอคือปัญหาจากผู้ให้บริการต้นน้ำรายหนึ่ง และกำลังร่วมมือกันเพื่อบรรเทาผลกระทบ”
เลยสงสัยว่า edge functions ใช้ Workers ภายในหรือเปล่า
ลิงก์: https://www.vercel-status.com/
ลิงก์อื่นในเธรดเดียวกันระบุว่า Flexential PDX02 สูญเสียไฟฟ้าในเวลาเดียวกัน
ดูเหมือนว่าไฟจากการไฟฟ้าดับลงแล้วสลับไปใช้เครื่องปั่นไฟ แต่เครื่องปั่นไฟก็ล้มเหลว จากนั้นไฟจากการไฟฟ้ากลับมาบางส่วนและกำลังทยอยกู้คืนบางส่วนของไซต์
ฟังดูเหมือนดาต้าเซ็นเตอร์ทั้งแห่งดับลง และ การแก้ไขฉุกเฉิน ของ Cloudflare ไม่ได้ลื่นไหลอย่างที่ควรจะเป็น
https://puck.nether.net/pipermail/outages/2023-November/0149...
ไม่รู้ว่าควรภูมิใจหรือหวาดหวั่นกับความจริงที่ว่าผลิตภัณฑ์พวกนี้จำนวนมากเป็นแค่ตัวครอบผลิตภัณฑ์ของ Cloudflare
แต่ในกรณีนี้ดูเหมือนจะไม่ใช่แค่ตัวครอบ เพราะ App Platform ของ DO ก็ซับซ้อนพอสมควรเกินกว่าจะวางอยู่บน Workers อย่างเดียว
เดาว่ามีเวิร์กโหลดแกนหลักหลายตัวที่ใช้ Workers อยู่
จังหวะแย่มาก
ช่วงบ่ายวันนี้มี ประกาศผลประกอบการรายไตรมาส