Ratequeue: Core Queueing-And-Rate-Limiting System (chaos engineering cho failover)

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

Bối cảnh

Tin nhắn gửi đi của Twilio có thể bị giới hạn tốc độ (quy định nhà mạng, hợp đồng, năng lực), nên mỗi sender ID có một queue tạm và được dequeue theo tốc độ cho phép.
Ratequeue là hệ queue + rate limit tự viết, lưu trên Redis, shard ngang (mỗi instance Ratequeue có Redis cục bộ riêng, nên một shard hỏng không ảnh hưởng shard khác); mỗi shard có primary + replica.
Vấn đề: primary hỏng thì tin nhắn trong shard đó đứng yên tới khi người trực thức dậy, vào VPN, đọc runbook, tìm replica cùng shard, promote, đưa vào load balancer, dựng replica mới. Mất 20 phút trở lên và dễ sai.

Ba mục tiêu: phát hiện primary hỏng; promote replica nếu primary có vẻ đã chết; không mất dữ liệu. Nếu primary chưa chết thật (phân vùng mạng), khi bị rút khỏi load balancer nó vào chế độ xả (drain), đẩy item sang shard khoẻ.
Không dùng Redis Sentinel: sau phân vùng mạng, Sentinel xoá dữ liệu của primary cũ để đồng bộ theo primary mới, trong khi Ratequeue cần chính dữ liệu đó cho chế độ xả.
Tự xây bằng các khối có sẵn:
- replica ping health check của primary mỗi 10 giây, gửi lên Nagios;
- 3 lần lỗi thì Nagios đẩy sự kiện vào Kinesis;
- Lazarus (dịch vụ tự động hoá cụm) đọc sự kiện, kiểm tra trạng thái cả cụm, rồi chạy workflow: xác định shard, tìm replica cùng shard, promote, dựng replica mới.
- Phát hiện trong khoảng 30 giây, failover xong trong hơn 1 phút.
Ratequeue Chaos: chọn một shard (chỉ khi còn ít nhất 2 shard khoẻ), tắt primary bằng Gremlin ("failure as a service"), theo dõi primary cũ rời và primary mới vào load balancer. Chạy trên staging mỗi 4 giờ, đã bắt được nhiều bug không lường trước.
Theo Twilio, chaos engineering thành công cần: một giả thuyết cụ thể ("primary tắt thì tự lành"), một thước đo (khả dụng không cần người), và kế hoạch quay lui.

Failover tay vào nửa đêm là 20 phút cộng rủi ro sai sót; tự động hoá bằng các khối sẵn có (health check, event stream, workflow) là đủ (Độ tin cậy và multi-region).
Công cụ failover có sẵn (Sentinel) có thể không hợp ngữ nghĩa dữ liệu của mình. Đánh giá theo yêu cầu "không mất dữ liệu" trước khi dùng.
Failover tự động chỉ đáng tin khi được kích hoạt thường xuyên bằng chaos test. Ngược lại là GoCardless 2017, nơi failover tự động hỏng đúng lúc cần (Sự cố và postmortem).