Slack's Migration to a Cellular Architecture

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

Bài đầu của một series; phần sau (cách silo service nội bộ, service không silo được) chưa ingest.

Bối cảnh

• Phần lớn hạ tầng lõi ở nhiều AZ trong một region (us-east-1). Ngày 30/6/2021, một đường mạng nối một AZ với các AZ khác lỗi chập chờn hai lần; người dùng thấy lỗi dù kiến trúc nhiều AZ lẽ ra che được.
• Vì sao lộ ra: một request API fan-out ra hàng trăm RPC, frontend phải ghi nhận lỗi rồi mới loại được backend hỏng; Vitess nhất quán mạnh nên mỗi shard chỉ có một primary nhận ghi. Đây là gray failure: mỗi thành phần thấy tính sẵn sàng khác nhau (trong AZ hỏng thấy mọi thứ ổn, ngoài AZ thấy AZ đó chết, kể cả client cùng AZ cũng thấy khác nhau tuỳ đường mạng).
• Trong sự cố, người trực nhìn đồ thị theo AZ là thấy ngay; họ chỉ thiếu một nút "AZ này hỏng, tránh nó".

Thay đổi chính

• Không tự động hoá phát hiện gray failure, mà dựa vào phán đoán của người + một nút rút traffic khỏi AZ. Mục tiêu: rút gần hết trong 5 phút (SLA 99,99% cho dưới 1 giờ downtime/năm); rút không gây lỗi cho người dùng, để dùng như biện pháp chung thử được ngay cả khi chưa rõ nguyên nhân (rút thử, không đỡ thì trả lại); rút và trả lại tăng dần tới mức 1%; cơ chế rút không phụ thuộc tài nguyên trong AZ bị rút.
• Cách ngây thơ (mỗi RPC client nhận tín hiệu tránh AZ) bị loại: service viết bằng Hack, Go, Java, C++; nhiều kiểu service discovery (Envoy xDS, Consul, DNS, mà DNS không có khái niệm AZ); sửa Vitess thì phải fork hoặc đưa upstream.
• Siloing: mỗi service chỉ nhận traffic từ trong AZ và chỉ gọi lên service trong AZ, nên mỗi service như N service ảo, mỗi AZ một bản: AZ là cell. Rút một AZ chỉ cần chuyển request của người dùng ở frontend; service nội bộ trong AZ tự lặng đi vì không còn việc mới.
• Thực hiện ở một chỗ: load balancer edge đều là Envoy (đã chuyển từ HAProxy), cấu hình từ control plane xDS tự viết (Rotor). Rút AZ = đổi trọng số cluster theo AZ qua RTDS; trọng số 0 thì request đang chạy vẫn xong, request mới sang AZ khác. Lan truyền trong vài giây, độ mịn 1%, edge ở region khác và control plane nhân bản theo vùng nên không phụ thuộc AZ bị rút.
• Dự án kéo dài khoảng 1,5 năm cho các service quan trọng nhất phía người dùng.

Vì sao

• Phát hiện lỗi tự động trong gray failure rất khó; một biện pháp chung, nhanh, an toàn, đảo ngược được có giá trị hơn việc hiểu nguyên nhân lúc đang cháy.

Bài học cho SWE

• Nhiều AZ chỉ tăng sẵn sàng nếu có cách loại một AZ nhanh; nếu không, một AZ hỏng một phần kéo cả region.
• Cô lập theo cell biến việc điều khiển traffic từ N ngôn ngữ/N client về một chỗ ở rìa.
• Thiết kế biện pháp giảm nhẹ để thử được (tăng dần, đảo ngược) khi chưa rõ nguyên nhân.

Liên quan

• Độ tin cậy và multi-region · Xử lý sự cố và on-call
• Cùng công ty: Slack 2021 · Slack 2020
• Proxy Envoy và control plane xDS: Dropbox 2020