Что произойдёт с хвостовой задержкой запроса, если он ждёт успешного ответа от десяти параллельных подзапросов?
Хвостовая задержка агрегирующего запроса обычно возрастёт: итоговое время определяется самым медленным из десяти подзапросов. Параллельный запуск уменьшает задержку по сравнению с последовательным выполнением, но повышает вероятность попасть в редкий медленный случай.
Если вероятность уложиться в заданный момент у одного подзапроса равна p, то при независимых задержках вероятность, что уложатся все десять, составляет примерно p¹⁰. Поэтому даже небольшие хвосты задержек отдельных зависимостей заметно усиливаются на уровне агрегатора.
Проблема стала особенно заметной с распространением распределённых систем и микросервисов, где один пользовательский запрос часто собирает данные из нескольких внутренних компонентов. Такой подход позволяет разделять ответственность между сервисами, но превращает задержку каждого вызова в часть пользовательского latency-бюджета.
Параллельный fan-out появился как естественный способ не складывать задержки всех зависимостей последовательно. Однако он не устраняет влияние медленных ответов: агрегатор всё равно вынужден ждать последний обязательный результат.
Предположим, API формирует страницу, обращаясь к десяти независимым сервисам параллельно. Девять ответили быстро, но один попал в свой редкий хвост задержки — пользовательский запрос задержится из-за этого одного вызова.
При росте числа подзапросов ухудшается не только p99, но иногда и процент запросов, укладывающихся в заданный SLA. Если каждый подзапрос потребляет ресурсы, fan-out также увеличивает нагрузку на сеть, соединения, планировщики и сами зависимости.
Неверно считать, что параллелизм автоматически делает агрегатор быстрым. Он сокращает сумму задержек, но не устраняет максимум задержек и может сделать хвост существенно тяжелее.
Для обязательных подзапросов итоговая задержка примерно равна максимуму их задержек плюс накладные расходы агрегатора. При независимых задержках число шансов встретить медленный экземпляр растёт вместе с fan-out, поэтому процентиль агрегатора нельзя оценивать по процентилю одной зависимости напрямую.
Сначала нужно разделить подзапросы на обязательные и необязательные. Для необязательных данных применяют частичный ответ, кэширование или заранее рассчитанные представления; это позволяет не блокировать весь пользовательский запрос из-за одного медленного компонента.
Для обязательных зависимостей задают общий deadline и передают оставшийся бюджет времени вниз по цепочке. Deadline ограничивает ущерб от зависания, но сам по себе не уменьшает задержку успешных медленных ответов и может увеличить долю частичных или ошибочных результатов.
Сокращают fan-out через агрегацию данных, кэширование, денормализацию или изменение границ сервисов. Эти варианты уменьшают число сетевых вызовов, но повышают сложность обновления данных, риск устаревания кэша или связанность компонентов.
Наблюдать нужно задержки каждого подзапроса, долю отменённых вызовов, распределение fan-out и вклад зависимостей в общий latency-бюджет. Средняя задержка здесь недостаточна: решение следует проверять по p95, p99 и доле запросов, нарушивших SLO.
API каталога формировало ответ через восемь параллельных зависимостей. Большинство ответов было быстрым, но один сервис рекомендаций периодически отвечал медленно, из-за чего p99 всего API заметно превышал целевой бюджет.
Рассматривались три варианта. Последовательный вызов был простым, но складывал задержки и был заведомо хуже по времени ответа. Полное ожидание всех параллельных ответов сохраняло максимальную полноту данных, но усиливало хвост. Полный отказ от рекомендаций уменьшал задержку, но ухудшал функциональность.
Выбрали deadline для рекомендаций с безопасным частичным ответом, а остальные обязательные зависимости оставили параллельными. Дополнительно начали измерять задержку каждого fan-out-вызова отдельно. Решение ограничило влияние медленного сервиса на пользовательский latency, сохранив основную функциональность; компромиссом стала возможность иногда отдавать страницу без рекомендаций.
Да. При последовательном выполнении итоговая задержка близка к сумме задержек всех подзапросов, поэтому растёт даже типичное время ответа. При параллельном выполнении типичная задержка может быть ниже, но хвост определяется максимумом, поэтому выбор между схемами должен учитывать не только среднее значение, но и целевой процентиль.
Формула с p¹⁰ предполагает независимость и тогда даёт лишь приближение. Общая перегрузка сети, базы данных или площадки может одновременно замедлить несколько зависимостей, поэтому реальный хвост окажется тяжелее, чем предсказывает независимая модель. В такой системе нужно анализировать совместные временные ряды и общие ресурсы, а не только отдельные распределения задержек.
Больший timeout уменьшает число ранних отказов, но позволяет медленным запросам дольше занимать соединения, потоки, память и слоты обработки. При высокой нагрузке это может увеличить очередь и усилить задержки для остальных запросов. Timeout должен быть согласован с пользовательским deadline, допустимой деградацией и бюджетом ресурсов, а не использоваться как замена устранению узкого места.