Kiểm thử API retry storm: backoff, jitter và retry budget

Một request người dùng có thể đi qua SDK, API gateway, service A và service B. Nếu mỗi lớp thử lại ba lần, tải thực tế không còn tỷ lệ 1:1 với request đầu vào. Khi timeout của lớp ngoài ngắn hơn thời gian hoàn tất của lớp trong, request cũ vẫn tiêu thụ tài nguyên trong lúc request mới đã được phát sinh.

Retry storm thường bộc lộ bằng request rate tăng dù offered load không đổi, hàng đợi dài, p99 latency tăng và tỷ lệ timeout lan sang service khỏe. Vì vậy baseline phải ghi riêng số request gốc, attempt và request downstream.

Topology tối thiểu gồm load generator, client hoặc SDK thật, gateway, service under test, dependency và bộ network emulation. Telemetry cần lấy ở cả phía phát, gateway và dependency để tránh kết luận từ một dashboard duy nhất.

Chèn riêng từng loại suy giảm: thêm latency cố định, jitter, packet loss, HTTP 429/503, reset kết nối, hoặc giảm concurrency của dependency. Không trộn nhiều lỗi trong lượt đầu; nếu không, rất khó chỉ ra cơ chế nào kích hoạt retry.

• Điểm đo: Client · Dữ liệu bắt buộc: request gốc, attempt, timeout · Mục đích: Tính retry/request
• Điểm đo: Gateway · Dữ liệu bắt buộc: request rate, queue, mã trạng thái · Mục đích: Phát hiện khuếch đại và overload
• Điểm đo: Service · Dữ liệu bắt buộc: active request, thread/connection pool · Mục đích: Tìm điểm bão hòa
• Điểm đo: Dependency · Dữ liệu bắt buộc: RPS nhận, latency, lỗi · Mục đích: Xác nhận tải thực tế
• Điểm đo: Network · Dữ liệu bắt buộc: latency, loss, reset đã chèn · Mục đích: Chứng minh điều kiện đo

Ghi rõ maximum attempts, backoff ban đầu, hệ số nhân, jitter, timeout mỗi attempt và deadline toàn request. Cũng phải khóa connection pool, keep-alive, circuit breaker, rate limit, số instance và autoscaling; thay đổi một biến giữa hai lượt sẽ làm so sánh mất ý nghĩa.

Traffic profile nên có steady state, burst và mix endpoint. Tách idempotent GET khỏi POST có side effect. Một retry thành công về mặt HTTP vẫn có thể tạo giao dịch trùng nếu idempotency key hoặc deduplication không hoạt động.

KPI trung tâm là retry amplification factor: tổng attempt chia cho request gốc. Đi kèm là goodput thành công, p50/p95/p99 latency, tỷ lệ deadline exceeded, 429/503, queue depth, CPU, connection pool và thời gian trở về baseline sau khi bỏ lỗi.

Đặt SLO theo nghiệp vụ trước khi chạy. Ví dụ minh họa, không phải ngưỡng chung: dưới lỗi 503 trong 30 giây, hệ thống có thể yêu cầu amplification không vượt 1,4; p99 không vượt deadline; và phục hồi trong 60 giây. Các giá trị phải được chủ hệ thống phê duyệt theo capacity thực tế.

HTTP định nghĩa ngữ nghĩa cho 429, 503 và Retry-After, nhưng tiêu chuẩn không đảm bảo mọi client tự động triển khai đúng. Phải kiểm tra hành vi của đúng SDK, gateway và phiên bản đang sử dụng.

• Kịch bản: Baseline · Điều kiện: Không chèn lỗi · Điều cần chứng minh: Retry xấp xỉ 0 · Dấu hiệu fail: Retry xuất hiện thường xuyên
• Kịch bản: Slow dependency · Điều kiện: +100–500 ms theo bậc · Điều cần chứng minh: Deadline và backoff đúng · Dấu hiệu fail: Attempt chồng lấn
• Kịch bản: 429 + Retry-After · Điều kiện: Trả 429 có header · Điều cần chứng minh: Client tôn trọng chỉ dẫn · Dấu hiệu fail: Retry ngay lập tức
• Kịch bản: 503 burst · Điều kiện: 10–60 giây · Điều cần chứng minh: Jitter phân tán tải · Dấu hiệu fail: Spike đồng bộ
• Kịch bản: Partial failure · Điều kiện: 10–30% instance lỗi · Điều cần chứng minh: Load không dồn quá mức · Dấu hiệu fail: Instance khỏe bị quá tải
• Kịch bản: Recovery · Điều kiện: Bỏ lỗi · Điều cần chứng minh: Hàng đợi và latency hạ · Dấu hiệu fail: Tiếp tục retry sau hồi phục

Pha 1 chạy baseline đủ lâu để hệ thống đạt trạng thái ổn định. Pha 2 chèn một lỗi với biên độ tăng theo bậc. Pha 3 giữ offered load nhưng đổi retry policy. Pha 4 bỏ lỗi và đo recovery. Mỗi lượt cần cùng seed hoặc phân phối request tương đương.

• 1. Xác nhận đồng bộ thời gian và correlation ID.
• 2. Warm-up cache, connection pool và autoscaling.
• 3. Chạy baseline; lưu trace, metric và log.
• 4. Chèn latency hoặc 503 trong cửa sổ định trước.
• 5. So sánh no-retry, fixed delay, exponential backoff và full jitter.
• 6. Lặp lại với circuit breaker/rate limit.
• 7. Bỏ lỗi; đo drain queue và recovery time.
• 8. Xuất bảng pass/fail kèm cấu hình thực tế.

• Chỉ retry thao tác an toàn hoặc có idempotency control.
• Dùng exponential backoff có jitter, không dùng delay cố định cho toàn fleet.
• Tôn trọng Retry-After khi phù hợp.
• Giới hạn attempt bằng deadline và retry budget.
• Không để nhiều lớp retry độc lập mà không có ownership.
• Circuit breaker có trạng thái half-open được kiểm thử.
• Rate limit phân biệt request gốc và retry nếu hệ thống cần.
• Dashboard hiển thị request gốc, attempt và downstream RPS.
• Runbook có điều kiện dừng để bảo vệ dependency.

Backoff làm giảm spike không đồng nghĩa hệ thống đã an toàn. Nếu deadline quá dài, request vẫn giữ tài nguyên; nếu retry budget chỉ giới hạn theo từng instance, autoscaling có thể làm tổng retry tăng. Hãy kiểm tra ở cấp fleet và trong cửa sổ đủ dài.

Kết quả lab chỉ đúng với traffic profile, phiên bản client, topology và capacity đã ghi. Không suy rộng sang production nếu khác cache hit ratio, payload, locality, TLS handshake hoặc autoscaling policy. Pass/fail phải gắn với bằng chứng thô và commit cấu hình.

• Backoff: Khoảng chờ tăng dần trước lần thử tiếp theo.
• Jitter: Thành phần ngẫu nhiên giúp các client không retry cùng lúc.
• Retry budget: Giới hạn lượng retry trong một cửa sổ.
• Deadline: Thời hạn tổng cho toàn request.
• Idempotency: Lặp thao tác không làm thay đổi kết quả ngoài ý muốn.
• Amplification factor: Tỷ lệ attempt thực tế trên request gốc.
• Circuit breaker: Cơ chế tạm ngừng gọi dependency đang lỗi.