Slack's Incident on 2-22-22

Slack · 2022 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Postmortem do Incident Commander của sự cố viết.

Bối cảnh

• Client Slack phải boot (tải danh sách kênh, preference, hội thoại gần nhất) mới dùng được; boot lỗi là trang lỗi.
• Dữ liệu trên Vitess chia nhiều keyspace (Slack 2020). Cache là Memcached, Mcrouter định tuyến bằng consistent hashing. Mcrib là control plane mới của cache: theo dõi Consul, khi một node memcached biến khỏi catalog thì đưa node dự phòng vào thay; node cũ quay lại thì bị flush trước khi dùng. Mcrib thay cơ chế khoá Consul cũ vốn có tranh chấp.

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

• Kích hoạt: đang nâng cấp Consul agent trên toàn fleet theo phần trăm (PBR), mỗi bước cập nhật binary rồi restart agent tuần tự, chậm. Agent tắt thì huỷ đăng ký node khỏi catalog; với node memcached, Mcrib thay bằng node rỗng. Hai bước 25% tuần trước ổn; bước 25% ngày 22/2 trùng cao điểm và vượt điểm tới hạn: cache hit rate tụt.
• Scatter query: lúc boot client lấy danh sách thành viên các GDM (DM nhóm) của mình, đọc từ keyspace shard theo user, nên tìm thành viên của một GDM phải hỏi mọi shard. Bình thường dữ liệu này nằm trong cache theo channel ID với TTL dài (thành viên GDM bất biến). Chỉ cần một channel trượt cache là phải chạy query trên mọi shard; tải đọc tăng siêu tuyến tính theo tỷ lệ miss, query timeout, nên cache không nạp lại được.
• Cascading failure, trạng thái siêu bền (metastable): đã dừng restart Consul từ sớm (lúc chưa biết nó liên quan) nhưng không đủ; hệ ở trạng thái quá tải tự duy trì. Retry của client có backoff và jitter vẫn góp thêm tải.
• Khắc phục: throttle request boot (user chưa boot không vào được, đổi lại user đã boot dùng gần bình thường và DB bớt timeout để cache nạp lại); lần nới đầu tăng quá tay làm tải vọt lại, phải hạ rồi nới từng bước nhỏ; sửa query chỉ đọc từ Vitess phần thiếu trong cache thay vì đọc mọi shard mỗi lần miss; cho phép đọc từ replica vì dữ liệu bất biến chịu được cũ. Sau đó: đổi query sang bảng shard theo channel, rà các query scatter khác đứng sau cache, đổi quy trình rollout Consul, sửa vòng điều khiển của Mcrib.

Vì sao

• Ba thứ đều "đúng" riêng lẻ gặp nhau: rollout chậm có chủ đích, control plane cache hiệu quả hơn hệ cũ, và một query không hiệu quả mà cache che giấu.

Bài học cho SWE

• Theo Slack: Mcrib góp phần vào sự cố không phải vì sai mà vì quá tốt: phát hiện node chết và thay nhanh hơn làm cache churn nhiều hơn. Một thành phần tốt hơn có thể làm cả hệ kém an toàn hơn.
• Query chỉ chạy được vì có cache là một phụ thuộc ẩn; với dữ liệu shard theo khoá khác khoá truy vấn, một lần miss nhân thành N query.
• Hệ ở trạng thái quá tải không tự về trạng thái lành; phải giảm tải hoặc tăng capacity từ bên ngoài, rồi nới dần trong khi giữ goodput.
• Throttle có chọn lọc (chặn boot, giữ phiên đã có) là đổi một phần người dùng để cứu phần còn lại.
• Một sự cố mạng ngắn làm rớt nhiều node cache cùng lúc có thể kích hoạt đúng chuỗi này, còn đồng loạt hơn.

Liên quan

• Sự cố và postmortem · Cache và invalidation · Hot partition và thundering herd · Load shedding, rate limit và backpressure · Sharding và tách database
• Sự cố trước của Slack: Slack 2021
• Consul gây rủi ro toàn fleet ở GitLab 2019: GitLab 2019