How Render Services Stayed Up During the AWS October Outage

Bài tóm tắt Render 2025 3. Quy mô lớn Độ khó: Trung bình

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

Bối cảnh

  • 20/10/2025: AWS us-east-1 gặp sự cố gần 15 giờ. Theo một bên giám sát mà bài dẫn, khoảng 30% trong hơn 7.000 nhà cung cấp cloud được theo dõi bị ảnh hưởng. Theo bản tóm tắt của AWS, gốc là hệ quản lý DNS của DynamoDB, rồi lan sang các dịch vụ cấp cao phụ thuộc vào nó.
  • Render (nền tảng PaaS) bị suy giảm build và deploy ở region Virginia, nhưng không khách nào bị sập hoàn toàn: workload đang chạy vẫn chạy.

Diễn biến

  • Khoảng 90 phút đầu Render vẫn khoẻ. Sau đó không provision được EC2 ở us-east-1, nên build chậm vì hết chỗ.
  • Khi EC2 mở lại thì phát sinh lỗi khác:
    • node mới lên ở trạng thái hỏng mạng;
    • workload kẹt khi start/stop;
    • gắn EBS lỗi nên tạo DB chậm hoặc hỏng;
    • Network Load Balancer chậm làm tăng latency của proxy.
  • Khoảng 22:53 UTC, AWS xác nhận đã hồi phục hoàn toàn.

Vì sao ít bị ảnh hưởng (theo Render)

Kết quả của các quyết định kiến trúc trong hơn 6 năm, "cộng thêm chút may mắn":

  • Chỉ dùng dịch vụ AWS nền tảng (EC2, S3, ELB), không dùng DynamoDB, RDS, Lambda cho phần lõi. Vì vậy đợt lỗi đầu tiên không chạm tới họ; họ chỉ dính ở cuối chuỗi (EC2, NLB). Theo Render, họ dùng dịch vụ bên thứ ba cho thứ không phải lõi, còn compute và điều phối thì tự giữ, và thường xuyên xem lại để tránh mặc định "không dùng của người khác".
  • Tự chạy Kubernetes thay vì EKS; control plane Kubernetes không nằm ở us-east-1 và tách khỏi cụm chạy workload, nên vẫn thấy và điều khiển được trong suốt sự cố.
    • Mặt trái: họ giữ cụm chậm vài phiên bản để ổn định, nên chưa dùng được bản EBS CSI driver mới đã sửa một phần lỗi gắn volume.
  • Né us-east-1 cho hạ tầng lõi từ đầu, vì đây là region cũ nhất, lớn nhất và hay sự cố nhất. Phần lớn khách không chạy ở đó. Theo Render, nếu cùng lỗi này xảy ra ở us-west-2 thì hậu quả sẽ lớn hơn nhiều.
  • Can thiệp trong sự cố:
    • đặt min của Auto Scaling group bằng giá trị hiện tại để không bị thu hẹp;
    • dời node proxy từ gói miễn phí sang khách trả phí;
    • dọn tay các persistent volume claim bị kẹt.

Còn thiếu (Render tự nêu)

  • Nhiều can thiệp là ứng biến; cần thành quy trình đã test hoặc tự động hoá.
  • Công cụ liên lạc khi sự cố cũng hỏng vì cùng sự cố; phải đăng cập nhật trên Twitter.
  • Cần test định kỳ đơn giản (ví dụ thử provision một EC2 nhỏ) để sớm phân biệt lỗi của mình với lỗi nhà cung cấp.

Bài học cho SWE

  • Quyết định kiến trúc từ nhiều năm trước quyết định "bị ảnh hưởng" nghĩa là gì trong sự cố hôm nay.
  • Build vs buy cũng là chọn failure domain: dịch vụ managed càng cao tầng thì càng nhiều phụ thuộc ẩn. Đổi lại, tự vận hành tốn công thường xuyên (Chi phí hạ tầng và build vs buy).
  • Control plane đặt ở region khác với data plane; tránh dồn mọi thứ vào một region "mặc định" (Độ tin cậy và multi-region).
  • So với PlanetScale cùng sự cố (PlanetScale 2025): cả hai đều sống nhờ tách control/data plane, và cả hai đều giữ chặt máy đang có khi không launch được máy mới.

Liên quan