Retry storm или как не задудосить себя
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Бэкенд-инженеры и SRE, работающие с высоконагруженными синхронными путями (gRPC/HTTP), особенно в финтехе. Слушатель унесёт: методику разложения хвостовой задержки по слоям, диагностические признаки метастабильного отказа и фреймворк для проектирования retry-политики в многослойной системе.
Тезисы
- Контекст: платёжный путь, сервис aquaphor как тонкий фильтр перед payment-cards
- Проблема: на хаммере с x27 нагрузки, q99 aquaphor'а вырос с 25ms до 3.3s при живых картах (rt ~53ms)
- Расследование: ложные гипотезы (рост rt карт, "плохой ЦОД" из-за пары медленных подов) -> разложение задержки между сервисами -> 89% хвоста внутри сервиса
- Механика: deadline 45ms + Polly retry на статусах, которые уже означают перегрузку = самоподдерживающийся цикл (DeadlineExceeded -> retry -> больше объектов и загрузки CPU -> больше шанс еще раз словить DeadlineExceeded)
- Решение: эволюция от "выключить логи" до полного удаления локальных ретраев - retry-политика остается только на верхнем слое (у обоих клиентов свои ретраи)
- Результат: 62.8K RPS / q99 3.3s в день инцидента -> 72.9K RPS / q99 47ms после фикса
- Выводы: как искать nested retries, метрики для ранней диагностики
Больше 6 лет коммерческого опыта. Последние 2.5 года в Озон. Вел подготовку к сезону распродаж команды ядра платежей в 2025 году и веду в 2026. Основной стек: .NET, PostgreSQL, Kafka, Kubernetes.
Видео
Другие доклады секции
Высокопроизводительные вычисления
