Google Cloud vô tình treo tài khoản Railway, gây ra sự cố mất dịch vụ toàn diện kéo dài 8 giờ

Google Cloud vô tình treo tài khoản Railway, gây ra sự cố mất dịch vụ toàn diện kéo dài 8 giờ

Hệ thống tự động của Google Cloud đã khóa tài khoản sản xuất của Railway vào ngày 19 tháng 5, triggering một sự cố ngừng hoạt động toàn diện kéo dài 8 tiếng. Sự cố này khiến bảng điều khiển (dashboard), API, tất cả các bản triển khai và cơ sở dữ liệu của nền tảng trở nên không thể truy cập đối với 3 triệu người dùng.

Theo báo cáo của đội ngũ kỹ thuật Railway, việc đình chỉ tài khoản không phải do lỗi của họ. Google áp dụng biện pháp này như một phần của hành động tự động rộng hơn ảnh hưởng đến nhiều tài khoản khác, mà không có bất kỳ cảnh báo nào đối với từng khách hàng cụ thể.

Cơ chế lan truyền của sự cố

Điều đáng chú ý về mặt kiến trúc là cách sự cố lan rộng. Railway vận hành một mạng lưới dạng lưới (mesh network) trải rộng trên Google Cloud, AWS và hạ tầng máy chủ vật lý riêng (Railway Metal). Mặc dù khi tài khoản GCP bị treo, các khối lượng công việc (workloads) trên AWS và Metal ban đầu vẫn hoạt động nhờ các proxy biên duy trì bộ đệm định tuyến từ mạng điều khiển (control plane).

Tuy nhiên, vấn đề nằm ở chỗ mạng điều khiển này được lưu trữ trên Google Cloud. Khi các tuyến đường được lưu trong bộ đệm hết hạn, lớp biên không còn khả năng phân giải đường dẫn đến các thể hiện đang hoạt động. Kết quả là các khối lượng công việc trên tất cả các khu vực, bao gồm cả Metal và AWS, bắt đầu trả về lỗi 404. Bản thân các ứng dụng vẫn đang chạy, nhưng chúng trở nên không thể tiếp cận.

Quá trình khắc phục khó khăn

Việc khôi phục quyền truy cập tài khoản không đồng nghĩa với việc dịch vụ lập tức trở lại bình thường. Các đĩa lưu trữ (persistent disks), thể hiện tính toán và mạng lưới đều yêu cầu quy trình khôi phục riêng biệt. Đĩa lưu trữ đã sẵn sàng vào lúc 23:54 UTC, nhưng mạng lõi không được khôi phục cho đến 01:30 UTC ngày hôm sau.

Song song với đó, GitHub bắt đầu giới hạn tốc độ (rate-limit) các tích hợp OAuth và webhook của Railway do lượng lớn yêu cầu thử lại, gây ra sự cố tạm thời khi người dùng đăng nhập và triển khai bản dựng.

Phản ứng và thay đổi kiến trúc

Jake Cooper, nhà sáng lập Railway, chia sẻ rằng ông hoàn toàn "bàng hoàng" trước việc đình chỉ tài khoản này. Railway đã xác nhận sẽ hạ cấp Google Cloud xuống trạng thái chỉ dùng để dự phòng. Báo cáo sự cố cho biết Railway đang loại bỏ Google Cloud khỏi đường dẫn chính (hot path) của mặt bằng dữ liệu, mở rộng các shard cơ sở dữ liệu tính sẵn sàng cao (high-availability) trên AWS và Metal, và thiết kế lại mạng lưới để nếu bất kỳ kết nối liên mạng nào thất bại, các bảng định tuyến vẫn có thể được điền từ các đường dẫn còn sống.

Trên Hacker News, nhiều ý kiến tranh luận về nguyên nhân gốc rễ. Một người bình luận nhận định: "Xây dựng trên nền tảng của người khác luôn là một bước đi rủi ro, và xây dựng một nền tảng trên nền tảng của người khác còn rủi ro hơn nữa."

Một khách hàng của Railway chia sẻ rằng họ đã phải thực hiện việc di chuyển khẩn cấp sang Azure do sự cố này: "Thật không may, chúng tôi phải di chuyển khẩn cấp sang Azure hôm qua. Mặc dù chúng tôi rất thích sự đơn giản mà họ mang lại, nhưng đã có quá nhiều sự cố và thiếu sót để chúng tôi tiếp tục chạy ứng dụng doanh nghiệp B2B trên hạ tầng của họ."

Bài học về sự phụ thuộc đơn điểm

Bài học kiến trúc từ vụ việc này vượt xa phạm vi của Railway. Bất kỳ nền tảng nào được xây dựng trên một tài khoản đám mây lớn duy nhất, dù là GCP, AWS hay Azure, đều mang rủi ro rằng một hành động tự động ở cấp độ tài khoản có thể làm sập toàn bộ hệ thống cùng lúc. Các mô hình đa vùng sẵn sàng (multi-AZ) và đa khu vực (multi-region) truyền thống chỉ bảo vệ chống lại các lỗi hạ tầng trong phạm vi nhà cung cấp, nhưng không thể bảo vệ trước việc đình chỉ tài khoản.

Kế hoạch khắc phục của Railway, biến mạng lưới thực sự độc lập với nhà cung cấp và không có bất kỳ đám mây đơn lẻ nào nằm trên đường dẫn chính, là mô hình cần thiết để giải quyết lớp lỗi này.