Таймауты и хвостовая задержка: бюджеты, дедлайны и ловушка fan-out

Каждый сервис в цепочке здоров: любая зависимость отвечает за 10 мс на 99-м перцентиле. Страница продукта разветвляется к 100 из них параллельно и ждёт всех. И всё же 63% загрузок страницы занимают больше секунды. Ни один сервис не медленный. Медленна математика хвоста — и интуиция большинства инженеров про средние полностью её прячет.

Таймаут на каждом хопе, или зависание на каждом инциденте

Сетевой вызов без таймаута — баг, ждущий инцидента. Когда зависимость перестаёт отвечать (не отказывает — зависает), вызов без таймаута ждёт вечно, удерживая поток или соединение. Достаточно таких вызовов — и пул исчерпан, и одна медленная зависимость роняет здоровый сервис. Каждому исходящему вызову — запросу к БД, кешу, HTTP, RPC — нужен явный таймаут. Дефолт в большинстве клиентов — нет таймаута, и это худший дефолт в backend-инженерии.

Таймауты должны складываться в бюджет

Потаймауты на хоп, выставленные изолированно, лгут. Если у запроса SLA 1 с, но он вызывает сервис A (таймаут 1 с), который вызывает сервис B (таймаут 1 с), то когда B медленный, A ждёт всю секунду, а клиент уже сдался — A теперь делает работу, которую никто не ждёт. Лечение — бюджет таймаута (дедлайн): точка входа выделяет общий объём, и каждый хоп передаёт оставшееся время вниз. gRPC формализует это как дедлайн, распространяемый в метаданных; каждый сервис вычисляет свой локальный таймаут как min(локальный дефолт, оставшийся бюджет).

Почему хвост, а не среднее, — это SLA

Пользователи не переживают ваше среднее. Они переживают свой запрос, и медленные — то, что они запоминают и что срывает алерты. Поэтому задержку отчитывают перцентилями: p50 (медиана), p99 (1 из 100 хуже), p99.9. Разрыв между p50 и p99 — «хвостовая задержка», вызванная паузами GC, очередями, промахами кеша, конкуренцией за блокировки и повторами.

Опасность — усиление хвоста под fan-out. Если один запрос к сервису медленный с вероятностью p, то запрос, разветвляющийся к N сервисам параллельно и ждущий всех, медленный, если медленный любой один — вероятность 1 − (1 − p)^N. При посервисном p99 (p = 1%) и N = 100 это 1 − 0.99^100 ≈ 63%. Это число из Hook, прямо из The Tail at Scale Дина и Барросо: сервис, разветвляющийся к 2000, оставляет около 20% запросов дольше секунды, даже когда p99 каждого бэкенда в норме.

Защита хвоста: хеджирование, а не только таймауты

Таймаут ограничивает худший случай, но не улучшает типичный хвост. Техника из The Tail at Scale — хеджированные запросы: отправьте запрос, и если ответ не пришёл к задержке p95, отправьте вторую копию другой реплике и возьмите ту, что вернётся первой. Поскольку хеджируются только медленные ~5%, лишняя нагрузка мала (~5%), а хвост схлопывается — в измерениях Google отправка хеджа после задержки в 10 мс срезала p99.9 с 1800 мс до 74 мс ценой ~2% лишних запросов. Связанные запросы идут дальше: дубликаты говорят друг другу отмениться, как только один начал выполняться, обрезая зря потраченную работу.