Retry-бури, circuit breakers и load shedding

У backend GC-пауза 500 мс. Сто клиентов истекают по таймауту. Каждый делает retry. Теперь у backend в очереди 200 запросов к уже приостановленному backend. Retry от retry накапливаются. За секунды сбой 500 мс превращается в полный сбой кластера. Это retry-буря — и автоматические retry её вызвали.

Проблема retry-усиления

Backend даёт сбой (GC-пауза, исчерпание thread pool, кратковременная перегрузка). Запросы истекают по таймауту. Клиенты и LB делают retry. Retry добавляет нагрузку на уже нарушенный backend. Backend ещё больше отстаёт. Накапливается ещё больше retry.

Математика усиления. С N=100 клиентами и 1 retry каждый: 100 оригинальных запросов + 100 retry = 200 запросов на backend, который не мог обработать 100. При 2 retry каждый: 300. При K=10 слоях микросервисов с 1 retry на ошибку, усиление в худшем случае достигает 2^10 = 1024 раз от исходной нагрузки.

Это не теоретическая проблема. Это наиболее частая причина продолжительных сбоев кластера в архитектурах микросервисов.

Почему retry ухудшают, а не улучшают ситуацию. Retry правильны для преходящих сбоев (кратковременная потеря пакетов, мгновенный сбой DNS). Они катастрофичны для перегрузочных сбоев: retry в перегруженный backend добавляет именно ту нагрузку, что вызвала перегрузку. Backend не может разгрузить очередь, потому что retry её постоянно пополняют.

Circuit breakers

Circuit breaker стоит на уровне LB или клиента сервиса и отслеживает частоту отказов для каждого backend. Три состояния:

1. Closed (нормальное): Запросы проходят. Счётчик отказов отслеживается.
2. Open: После N последовательных отказов (или превышения порога частоты отказов) breaker открывается. Все новые запросы получают 503 Service Unavailable немедленно — без очереди, без ожидания.
3. Half-open: После периода остывания один запрос пропускается. Если он успешен, breaker закрывается. Если нет — вновь открывается и период остывания сбрасывается.

Почему быстрый 503 помогает. Когда breaker открыт, клиенты получают 503 немедленно вместо ожидания таймаута (30 с). Они могут перейти к fallback, retry другого сервиса или сбросить запрос. Перегруженный backend не получает новой нагрузки — он может разгрузить существующую очередь и восстановиться.

Конфигурация circuit breaking Envoy:

• max_connections: максимум одновременных TCP-соединений к backend (например, 1 000). 1 001-й запрос: 503 немедленно.
• max_pending_requests: максимум запросов в очереди при занятости всех соединений (например, 100). Избыток: 503 немедленно.
• max_requests: максимум одновременных HTTP/2-запросов на соединение (например, 1 000).

Retry-бюджеты

Вместо неограниченных retry установите глобальный retry-бюджет: ограничьте общее число retry от всех клиентов до ~10% от общей частоты запросов.

Пример: если сервис обрабатывает 10 000 RPS, разрешить не более 1 000 RPS retry. Любой retry сверх этого возвращает 503 немедленно (fail fast). Это предотвращает превышение усиления ограниченного коэффициента независимо от числа одновременно делающих retry клиентов.

Экспоненциальный откат с джиттером

Клиенты не должны делать retry немедленно — это синхронизирует все retry и создаёт thundering herd. Два компонента:

1. Экспоненциальный откат: Задержка retry удваивается при каждой попытке: 1 с → 2 с → 4 с → 8 с → … до максимума (например, 32 с).
2. Джиттер: Добавить случайное значение random(0, base) к каждой задержке. Это рассинхронизирует клиентов, чтобы они делали retry в разное время.

delay = min(base × 2^attempt + random(0, base), max_delay)

Пример с base=1 с, max=32 с:

• Попытка 1: 1 с + rand(0, 1 с).
• Попытка 2: 2 с + rand(0, 2 с).
• Попытка 3: 4 с + rand(0, 4 с).

Без джиттера все 100 клиентов, истёкших по таймауту в t=30 с, делают retry в t=31 с, создавая новый всплеск. С джиттером они делают retry в разное время в диапазоне t=31–32 с.

Load shedding

LB и backend оба принудительно ограничивают глубину очереди. Когда очередь превышает порог, новые запросы немедленно сбрасываются с 503 вместо принятия и постановки в очередь.

Без load shedding:

• Очередь растёт безгранично.
• Задержка каждого запроса в очереди увеличивается.
• Память раздувается.
• В итоге всё истекает по таймауту одновременно.

С load shedding:

• Клиенты получают быстрый 503 — знают, что нужно отступить.
• Очередь backend остаётся ограниченной.
• Запросы, попавшие в очередь, обрабатываются за конечное время.
• Система разгружается и восстанавливается вместо коллапса.

cluster.api_backend.requests: 10000
cluster.api_backend.errors: 245
cluster.api_backend.retries: 189
cluster.api_backend_retry_limit: 1200
upstream_rq_retry.api_backend: 189
upstream_rq_retry_limit_exceeded: 45
upstream_rq_total.api_backend: 10000
upstream_cx: 156
health_checks.failed: 12
health_checks.success: 188
circuit_breaker.default.rq_open: 0
circuit_breaker.default.cx_open: 0
outlier_detection.ejected_count: 0
load_balancer.least_request.unbalanced_requests_delta: 234