Как retry может усугубить инцидент

Uber недавно опубликовал разбор реального инцидента, в котором обычный механизм retry мог усугубить деградацию системы.

Это хороший повод посмотреть на retry не только как на защиту от временных ошибок, но и как на источник дополнительной нагрузки. Особенно в распределённых системах, где один запрос может повторяться сразу на нескольких уровнях.

Представим цепочку:

A → B → C → D

D начинает отвечать ошибками.
C делает retry.
B получает ошибку от C и тоже делает retry.
A повторяет запрос к B.

Каждый уровень по отдельности действует логично, но в итоге нагрузка на D растёт именно тогда, когда сервис уже испытывает проблемы.

Особенно опасно, когда retry есть сразу на нескольких уровнях:

клиент → SDK → сервис → service mesh → зависимый сервис

Если каждый из трёх уровней повторяет неудачный вызов один раз, число обращений в худшем случае может вырасти:

1 → 2 → 4 → 8

В случае Uber проблемный сервис находился более чем на пяти уровнях глубины в цепочке зависимостей. Обычная стратегия retry могла увеличить нагрузку на него ещё на 46–135%.

Uber ограничил усиление нагрузки через error ownership: каждый сервис определяет, является ли ошибка его собственной или пришла от зависимости.

Если ошибка возникла ниже по цепочке, сервис не должен автоматически запускать свой retry поверх уже выполняющихся повторных попыток. Иначе один и тот же сбой начинает повторно обрабатываться сразу несколькими уровнями.

По данным Uber, такой подход позволил предотвратить до 9,5 млн лишних retry-запросов.

Что проверить у себя?

⏺Где именно реализован retry: в приложении, SDK, прокси или service mesh?

⏺Может ли один запрос пройти через несколько механизмов повторных запросов?

⏺Сколько запросов к зависимому сервису приходится на один исходный запрос?

⏺Видно ли отдельно количество исходных запросов и повторных попыток?

Полезный показатель можно посчитать напрямую:

коэффициент усиления = запросы к зависимому сервису / исходные запросы

Например, 10 000 исходных запросов → 17 000 запросов к зависимому сервису означает, что часть нагрузки появилась из-за повторных попыток.

Если во время сбоя одновременно растут ошибки, retry и QPS зависимого сервиса, система может сама усиливать собственную деградацию.

Retry должен помогать пережить временный сбой, а не увеличивать нагрузку на то место, которое уже сломалось.

👀 Разбор кейса Uber можно прочитать здесь.

#devops #retry