Three months, 30x demand: How we scaled Google Meet during COVID-19

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

Bối cảnh

• Từ 17/2/2020, SRE của Meet nhận page về năng lực theo region (alert kiểu triệu chứng: "quá nhiều task lỗi", "cắt tải quá nhiều"), bắt đầu ở châu Á rồi Ý. Dùng lượng tăng 30 lần trong khoảng ba tháng; lúc kết thúc có hơn 100 triệu người tham gia họp mỗi ngày.
• Không có sự cố đang diễn ra, nhưng họ vẫn khai báo incident cho một rủi ro năng lực toàn cầu, trong lúc cả team chuyển sang làm từ xa.

Cách tổ chức

• Incident Commander, Communications Lead, Operations Lead ở cả Bắc Mỹ và châu Âu để phủ 24 giờ; mỗi vai có một standby dự đủ họp và tài liệu để thay ngay khi người chính ốm hoặc cần nghỉ.
• Năm workstream bán độc lập với giao diện rõ: Capacity (tìm tài nguyên), Dependencies (bảo đảm hệ phụ thuộc như xác thực cũng scale), Bottlenecks (gỡ giới hạn scale), Control knobs (cơ chế giảm thiểu dựng sẵn), Production changes (đưa năng lực lên, deploy bản tối ưu).
• Liên tục hỏi lại cấu trúc có còn hợp: "đủ cấu trúc để làm hiệu quả, không hơn".

Thay đổi kỹ thuật

• Năng lực: tận dụng tài nguyên sẵn có (hơn 20 data center), nhân đôi năng lực phục vụ; rồi làm việc với dự báo 50 lần. Không dựa được vào xu hướng lịch sử nên chuyển sang dự báo, và dựng mô hình đổi "lượng dùng" thành CPU/RAM để công cụ tự động hiểu.
• Giảm tài nguyên cần: phần lớn CPU đi vào overhead (giữ kết nối tới monitoring, load balancer) chứ không vào xử lý request. Chạy task "béo" hơn: cùng tổng CPU, một instance cỡ 4x xử lý được 1,8 lần request so với bốn instance cỡ cơ bản. Gấp đôi reservation, giảm nửa số task, lặp lại tới khi chạm giới hạn; mỗi bước đều qua canary. Viết lại một cache phân tán trong RAM để shard linh hoạt hơn khi số instance tăng.
• "Lối thoát hiểm": nút điều khiển dựng và thử sẵn, mong không phải dùng; ví dụ hạ độ phân giải mặc định khi vào cuộc họp từ HD xuống SD (user vẫn tự nâng lên được) để mua thời gian.
• Tự động hoá: việc scale tốn nhiều công tay nhất; ghi lại quy trình rồi tự động dần từng phần, tới khi tự động hoàn toàn footprint năng lực theo zone và theo job. Kéo dài chu kỳ lập kế hoạch từ ngày sang tuần nhờ dự báo tốt hơn.
• Có lúc chấp nhận rủi ro khác thường: deploy bản sửa hiệu năng với thời gian canary ngắn hơn vì nó mua thêm thời gian trước khi hết năng lực.

Bài học cho SWE

• Dùng khung incident cho một rủi ro chưa thành sự cố, và thiết kế nó cho "marathon": standby, bàn giao, giảm họp (Sự cố và postmortem).
• Chuẩn bị sẵn cách giảm chất lượng có kiểm soát (degrade mặc định, vẫn cho user chọn) trước khi cần (Load shedding, rate limit và backpressure).
• Overhead cố định mỗi process làm nhiều task nhỏ kém hiệu quả; đo throughput trên mỗi CPU.
• Khi không thể chờ thông tin đầy đủ, xếp hạng rủi ro và lợi ích linh hoạt, kéo dài "đường băng" năng lực.

Liên quan

• Load shedding, rate limit và backpressure
• Sự cố và postmortem