25% or 6 to 4: The 11/6/23 Authentication Outage

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

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

Bối cảnh

  • Cụm ScyllaDB scylla-authentication giữ session người dùng, đứng sau service xác thực viết bằng Rust; mọi request API đều qua đây. Topology chuẩn của Discord: "super-disk" RAID gương giữa NVMe local SSD (mất khi reboot) và persistent disk; replication qua 3 zone, đọc quorum, nên chịu được mất một zone. Khởi động node phải chép dữ liệu từ persistent disk sang NVMe khoảng 40 phút.
  • Từ 3/11/2023 đội persistence nâng cấp OS cho các cụm Scylla theo từng zone (tháo disk, tạo instance mới, gắn lại, rebuild RAID), nhanh hơn nhiều so với từng node và cũng là cách thử khả năng chịu mất zone; đã qua hơn 100 node an toàn.

Thay đổi chính (diễn biến)

  • Trước khi làm cụm xác thực, thử tắt zone b 10 phút: không suy giảm. Khi nâng cấp zone b, một node rebuild RAID chậm bất thường; bị coi là chuyện lạ thú vị.
  • 10:52, script rút kết nối zone c: tỉ lệ HTTP 2xx của Discord rơi xuống khoảng 25% trong khoảng 50 phút. Nguyên nhân chồng nhau: cụm thiếu capacity; một NVMe ở node b-2 suy giảm; row cache của các node b vừa restart còn trống (với vài cụm, tỉ lệ cache hit phải đạt ngưỡng mới restart an toàn, mà quy trình không kiểm); app retry lỗi xác thực tạo retry storm.
  • Alert đầu tiên sau khoảng 4 phút (đã có cuộc gọi sự cố từ trước). Biểu đồ "thời gian chờ service phía dưới" chỉ ra xác thực. Disk zone c đã tháo nên phải chờ khoảng 45 phút rebuild.
  • Cắt tải: tắt sự kiện đang gõ và đánh dấu đã đọc (11:05), khôi phục khoảng 50% người dùng. Cân nhắc restart node để xoá query bị bỏ rơi nhưng với một zone đã mất thì restart sẽ phá quorum; restart nhầm node có thể sập hẳn. Một thông báo lỗi gây hiểu lầm làm chậm chẩn đoán. Chọn chờ 5 phút cho RAID xong; 11:41 zone c lên, restart từng node b, 11:43 hồi phục.
  • Sau sự cố: nhân đôi cụm; thay disk suy giảm và làm cách phát hiện suy giảm disk ở mức chưa làm tăng latency chung; đưa thao tác nâng cấp vào control plane tự động kiểm được cả cache hit rate; cụm nhỏ nhưng tối quan trọng sẽ vận hành khác cụm lớn (tăng replication factor, hoặc cụm hot-standby ở region khác, cái sau làm phức tạp mô hình nhất quán của xác thực).

Vì sao

  • "Chịu được mất một zone" chỉ đúng khi phần còn lại khoẻ; một thao tác cố ý bỏ một zone làm biên an toàn bằng 0, và lỗi thứ hai (disk suy giảm, cache nguội) không có chỗ đứng.

Bài học cho SWE

  • Thao tác bảo trì theo zone nên kiểm trạng thái thật của phần còn lại (disk, cache hit) trước mỗi bước, không chỉ thời gian chờ cố định; tín hiệu lạ trong lúc thao tác là lý do dừng.
  • Phép thử trước (tắt zone 10 phút với cache đầy) có thể cho tự tin sai khi điều kiện thật khác (cache trống sau restart).
  • Retry ở client khuếch đại quá tải; cần nút cắt tải có sẵn cho tính năng không thiết yếu.

Liên quan