Migrating Millions of Concurrent Websockets to Envoy

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

Bối cảnh

• Hàng triệu user kết nối đồng thời lúc cao điểm, gửi nhau rất nhiều tin nhắn nhỏ qua websocket vào hệ "wss" (tin nhắn, presence, app). Từ đầu Slack dùng HAProxy ở nhiều region AWS để kết thúc websocket gần user.
• Vấn đề reload: danh sách backend đổi thường xuyên. Cách Runtime API đã gây sự cố trước đây; cách render backend vào file cấu hình rồi reload thì mỗi lần reload sinh tiến trình mới, tiến trình cũ phải giữ hàng giờ cho websocket dài sống rút dần, phải định kỳ dọn tiến trình cũ và giới hạn tần suất reload. Cả hai cách đều cần hạ tầng phụ.

Thay đổi chính

• Lý do chọn Envoy (quyết định 2019): cluster và endpoint cấu hình động (EDS) nên đổi endpoint không cần reload; đổi code/cấu hình thì hot restart không rớt kết nối, giữ cả số liệu thống kê; zone-aware routing, outlier detection, panic routing (khi tỷ lệ host khoẻ dưới ngưỡng thì gửi cho mọi host, theo Slack đã giúp trong sự cố 4/1/2021, Slack 2021). Thêm nữa: Envoy đã là data plane của service mesh, có người giỏi Envoy trong nhà, và dùng một phần mềm thay vì hai.
• Sinh cấu hình: template Chef dễ sai nên viết thư viện Chef và custom resource; cấu hình là singleton mỗi host, các resource thêm listener/route/cluster vào đó, cuối lần chạy Chef mới sinh envoy.yaml, chạy envoy --mode validate rồi mới cài, không bao giờ ghi cấu hình trung gian. Một số tính năng thiếu được viết và đóng góp upstream.
• Kiểm thử: prototype bằng cấu hình viết tay trên máy dev, kiểm routing theo header, cookie, path, query, cert bằng curl; debug log của Envoy giải thích vì sao request đi vào cluster nào; admin endpoint /clusters, /certs, /listeners.
• Rollout: dựng stack Envoy song song tương đương với HAProxy (tốn gấp đôi tài nguyên AWS trong lúc chuyển), dùng weighted DNS của NS1 chuyển dần từ NLB của HAProxy sang NLB của Envoy: region đầu theo bậc 10/25/50/75/100% trong khoảng một tuần, các region cuối 25→100% trong hai ngày. Lỗi nhỏ (timeout, header khác nhau) thì lùi, sửa, chạy lại nhiều lần. 6 tháng, không ảnh hưởng khách hàng.

Vì sao

• Giảm vận hành (không còn dịch vụ phụ quản lý reload) và chuẩn hoá một proxy cho cả ingress lẫn mesh.

Bài học cho SWE

• Theo Slack: migration "nhàm chán" là thành công.
• Cấu hình cũ là nợ kỹ thuật không có tài liệu: khó biết luật nào cố ý, luật nào vô tình, ai đang dựa vào hành vi nào. Có service chỉ nên nằm dưới một vhost nhưng thực tế truy cập được từ cả hai, và phải giữ nguyên lỗi đó vì code đã dựa vào. Đã lỡ làm hỏng metric DAU một thời gian.
• Thiếu test cho cấu hình load balancer nên phải hỏi từng chủ service; sau đó Slack thêm bộ test sinh lại toàn bộ cấu hình của các team dùng thư viện để thấy thay đổi thư viện ảnh hưởng ai.
• Thư viện chỉ hỗ trợ tập tính năng đang dùng thì gọn, nhưng mỗi tính năng mới phải thêm vào thư viện; phần vhost thành hack khó sửa vì đã có nhiều người dùng.
• Đội CSKH theo dõi ticket là một tín hiệu rollout.

Liên quan

• Migration không downtime · Realtime và fan-out · Deploy và release an toàn
• Dropbox đổi Nginx sang Envoy cùng thời kỳ: Dropbox 2020
• Chef ở Slack: Slack 2024