Когда один сервис тормозит, вызывающие его серверы зависают в ожидании ответа, и останавливаются даже функции, которые с ним не связаны.
Почему Тормозит один сервис, например БД или авторизация → Следствие Потоки и соединения вызывающих серверов заняты ожиданием ответа, а повторные попытки неудачных запросов добавляют нагрузку → На экране Тормозят или останавливаются даже функции, которые кажутся никак не связанными
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Сетевая инфраструктура
Команда разработки: задачи
Ставить таймауты на все вызовы, использовать circuit breaker (предохранитель для вызовов) и изоляцию функций друг от друга (bulkhead), повторять с растущим интервалом и ограничением числа попыток, отделить ответы на health check от тяжёлой работы.
Команда инфраструктуры: задачи
Дать запас по числу неудач и интервалу health check балансировщика, чтобы ненадолго притормозивший сервер не выводился сразу, и ограничить число серверов, выводимых одновременно.
На графике
Упор в лимит (плато) · время ответа и доля ошибок по сервисам, число занятых потоков и соединений
Где смотреть
Вывести на один экран с общей шкалой времени время ответа, долю ошибок и число повторов по сервисам и найти место, которое замедлилось первым. За балансировщиком смотреть время ответа целевых серверов (в AWS ALB это TargetResponseTime), число ответов 5xx от них (HTTPCode_Target_5XX_Count) и число целевых серверов, выведенных как неисправные (UnHealthyHostCount)
Подтверждает
Сначала растёт задержка одного сервиса, затем у вызывающих его сторон число занятых потоков и соединений упирается в лимит, ошибки переходят на другие сервисы, а вместе с ними растут число повторов и число выведенных целевых серверов
Опровергает
Если несколько сервисов замедлились в один и тот же момент, сначала проверить сбой общего ресурса (БД, сеть, хост)
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
Health check (проверка, жив ли сервер) тоже раскручивает каскад. Если занятый сервер отвечает на проверку с опозданием, балансировщик выводит исправный сервер из ротации, его трафик уходит на оставшиеся, и следующий сервер тоже начинает опаздывать с ответами.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Перегруженный сервер не проходит health check и выводится, нагрузка ложится на оставшиеся, а повторы её усиливают. Рекомендуются лимит повторов, экспоненциальная задержка повтора со случайным разбросом и дедлайны
Circuit Breaker PatternMicrosoft Azure Запросы, которые висят до таймаута, держат потоки и соединения с БД, и из-за этого отказывают даже не связанные функции. Если за заданное время накопилось слишком много неудач, вызовы сразу отклоняются
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. В цепочке из 5 вызовов при 3 повторах на каждом уровне нагрузка на БД вырастает в 243 раза. Повторять нужно только в одном месте и ограничивать повторы через token bucket
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (время от выхода запроса из балансировщика до начала ответа целевого сервера), HTTPCode_Target_5XX_Count (число ответов 5xx от целевых серверов), UnHealthyHostCount (число неисправных целевых серверов)
Смотрите также
Тот же слой: L13 Архитектура и эксплуатация серверов