Behind the scenes: Redpanda Cloud's response to the GCP outage

Redpanda · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp (Kafka-compatible streaming), có phần quảng bá; mọi nhận định là theo Redpanda. Cùng ngày sự cố với Cloudflare 2025.

Bối cảnh

12/6/2025, GCP sập toàn cầu do một bản cập nhật quota tự động vào hệ quản lý API. Cloudflare cũng bị kéo theo.
Redpanda Cloud (mô hình BYOC: cluster chạy trong tài khoản cloud của khách, Redpanda vận hành) có hàng trăm cluster trên GCP.

TAM của Google báo trước khi có ticket nào. Monitoring suy giảm: dữ liệu observability tự host, nhưng dashboard và cảnh báo dùng bên thứ ba, bên đó bị ảnh hưởng nên metric vẫn xem được mà không có thông báo cảnh báo. Họ tự query stack metric/log của mình để đánh giá.
Chủ động mở một sự cố mức thấp để điều phối nhiều sự cố tiềm năng. Vendor quản lý marketplace cũng hỏng (vì Cloudflare), xếp sau vì không quan trọng.
Cảnh báo đến trễ, chủ yếu là lỗi tiered storage (không phải storage chính); không có cảnh báo đầy đĩa. Họ chủ động liên hệ khách có tỉ lệ lỗi cao nhất. Kết thúc ở SEV4, không thấy ảnh hưởng tiêu cực tới khách.
Về sau phát hiện một cluster staging ở us-central-1 mất một node và GCP mất khoảng hai giờ mới cấp được node thay.

Cluster không đẩy metadata hay dịch vụ quan trọng ra ngoài: mọi thứ để đọc ghi, quản lý topic, ACL nằm cùng chỗ (một binary). Kiến trúc cell-based được đưa thành nguyên tắc sản phẩm. Theo Redpanda, các sản phẩm có metadata tập trung và kiến trúc diskless thì chịu toàn bộ sức nặng của sự cố (so sánh: WarpStream 2025 đặt metadata ở DynamoDB/Spanner).
Dữ liệu chính trên NVMe cục bộ, dữ liệu cũ đẩy bất đồng bộ lên tiered storage; replication factor bắt buộc ít nhất 3; Kafka API, Schema Registry, HTTP Proxy đều dư thừa.
Đường găng chỉ có VPC, compute, đĩa gắn trực tiếp (trừ khi bật Private Service Connect).
Chừa dung lượng đĩa trống và dung lượng cache có thể thu hồi khi cần.
Chaos test và load test liên tục; chứng nhận throughput từng tier trên từng cloud; rollout theo pha có vòng phản hồi (dừng khi thấy lỗi phía người dùng).
Mất hai năm sau khi ra mắt mới dám cam kết SLA 99,99%; cụm multi-AZ thiết kế cho SLO ít nhất 99,999%.
Năm trước đã chuyển sang observability tự host vì quy mô và chi phí; nếu còn dựa hết vào bên thứ ba thì đã mất khả năng tìm log toàn fleet.

Đếm dependency trên đường găng: mỗi dịch vụ ngoài (metadata, control plane, alerting) là một cách để sự cố của người khác thành sự cố của mình (Độ tin cậy và multi-region).
Cảnh báo cũng là dependency: có đường thứ hai để biết hệ đang thế nào khi alerting hỏng (Sự cố và postmortem).
Mở sự cố sớm ở mức thấp để điều phối, thay vì chờ chắc chắn có ảnh hưởng.
Sự cố dây chuyền (GCP → Cloudflare → vendor marketplace) có thể chạm mình qua đường không ngờ.