Controlled Chaos with Fault Injection Testing

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

Sheet ghi link trang chủ blog; bài thật tìm được qua Wayback CDX.

Bối cảnh

• Riot Games API (dữ liệu League cho developer bên ngoài) có rate limiter ở edge (ESRL); vì request rơi vào server bất kỳ, tổng số call mỗi khách phải đếm ở một chỗ trung tâm là Redis.
• Khi chuyển Riot API từ VM AWS vào rCluster (cloud nội bộ chạy container), đội chọn chạy Redis trong rCluster bằng một sidecar tự viết (hơn 3.000 dòng). Redis ra đời trước Docker: giả định IP tĩnh, bộ nhớ cố định, hiếm reboot, cụm dựng tay một lần.
• Test thủ công (reboot instance, xem secondary lên thay) đều ổn; bật thật thì mọi cụm Redis sập ở trạng thái không phục hồi được, API mất rate limit (may mà còn beta).

Thay đổi chính

• Framework Mundo Make Fail (MMF): CLI Python, kill instance ngẫu nhiên mà không cần viết code; chế độ service đọc lịch dạng cron từ file cấu hình trong GitHub, chạy qua Parallel-SSH, báo kết quả về Slack.
• Tự động hoá test vì người làm tay không đáng tin: cứ thêm log, thêm terminal là lỗi biến mất; test trong code tốt dần, test trong đầu kém dần.
• Lỗi tìm được:
  • redis://:0: rCluster thu hồi IP của container chết; ở production ít thay đổi nên container mới hay nhận lại đúng IP cũ nhưng UUID mới, driver Redisson rối và ghi node là :0. Node hỏng nằm im ở vai secondary như quả bom hẹn giờ, chỉ nổ khi primary chết và nó được promote: trông như mất hai node cùng lúc. Sửa cùng tác giả Redisson (bản 3.7.2). Dev không thấy vì IP ít khi lặp lại.
  • Bầu leader treo: mọi instance đua ghi "tôi đầu tiên" vào server "trung tâm", nhưng đó là Discoverous (service discovery, 3 node, nhất quán cuối cùng), nên hai instance có thể cùng thắng ở hai node. Không có dịch vụ khoá nhất quán mạnh kiểu Chubby, họ cố định cụm 7 node, chờ đủ 7 trong Discoverous rồi sắp IP: thấp nhất là primary. Yêu cầu: test xoá và dựng lại cụm phải qua 100 lần liên tiếp.
  • Khác: client hỏi trạng thái cụm từ một node có thể nhận tin cũ, phải hỏi từng node; master đầy bộ nhớ bị OOM thì replica (đầy cùng tốc độ) chết theo ngay sau; Docker chỉ giám sát PID 1 nên sidecar phải tự theo dõi tiến trình con.
• Lên production theo hai mốc: qua 100 lần liên tiếp, rồi chạy ở production (giờ hành chính trước, sau đó 24/7, một tuần không lỗi mới bật thật). Hiện khoảng 100 test/ngày trên production (7 cụm × 16 test). Test phá huỷ (dừng cả cụm) chỉ chạy ở QA.
• Test không tự phán pass/fail: ban đầu test tự kiểm sức khoẻ cụm; sau đổi sang để monitoring sẵn có phán. Không có alert khi tiêm lỗi nghĩa là hệ rất tốt hoặc monitoring có lỗ: họ phát hiện không thấy được cụm suy giảm (chỉ thấy khi cả primary lẫn secondary chết), nên thêm kiểm từng node. Slack chỉ báo khi cần người xem (100 tin/ngày thì sau một tuần không ai đọc).

Vì sao

• Theo Riot, FIT "tua nhanh đồng hồ": mô phỏng lỗi của mười năm trong vài giờ, và cho thời gian nghĩ về sự cố khi không mệt hay sợ.
• Kết quả: sidecar tăng lên 6.000 dòng, 10 người đóng góp; Legends of Runeterra dùng FIT trước khi ra mắt và on-call gọi ngày ra mắt là "nhàm chán"; tập phản ứng sự cố hằng tuần ("Failure Fridays").
• Theo tác giả, active/active (mỗi bên 50% tải, hoặc N bên) đáng tin hơn active/backup vì bản dự phòng nằm im thì không biết có chạy không.

Bài học cho SWE

• Phần mềm thiết kế cho IP tĩnh và máy sống lâu cần được kiểm riêng dưới điều kiện container: IP tái dùng, restart liên tục.
• Bầu leader trên kho nhất quán cuối cùng không an toàn; hoặc dùng kho nhất quán mạnh, hoặc biến thành quyết định tất định từ tập thành viên đã biết.
• Lỗi ở secondary chỉ lộ khi failover: phải tiêm lỗi đủ nhiều lần để đi qua đường promote.
• Kill -9 thường xuyên làm cho kill -9 thành đường tắt máy đã được kiểm; tắt "nhẹ nhàng" lại thành đường rủi ro.

Liên quan

• Riot Games 2015 · Riot Games 2021 · Riot Games 2020 · Google 2006 (dịch vụ khoá nhất quán mạnh mà Riot không có) · DoorDash 2022
• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) · Failover, replica và dự phòng dữ liệu