Сервис под перегрузкой: сброс нагрузки и грациозная деградация

Есть уровень нагрузки, выше которого твой сервис не может обслужить каждый запрос, как бы он ни был написан — и единственный выбор у тебя в том, как он падает, дойдя до него. Наивный инстинкт — попытаться обслужить всех: принять каждое соединение, поставить в очередь каждый запрос, переретраить каждый сбой. Этот инстинкт ровно и рождает коллапс из урока двумя ранее, потому что приём работы, что не можешь закончить, не помогает пользователю, чей запрос ты принял, и крадёт ресурсы у пользователей, чьи запросы ты мог бы закончить. Контринтуитивная истина перегрузки в том, что отвергая часть запросов, ты обслуживаешь остальные — сервис, что сбрасывает 20% нагрузки на двери и обслуживает другие 80% быстро, несравнимо здоровее того, что принимает 100% и обслуживает всё слишком медленно, чтобы быть полезным, затем валится и обслуживает 0%. Это сдвиг от мышления о throughput (обработанные запросы) к goodput (запросы, обработанные с пользой, внутри их дедлайна). И вот синтез: каждый механизм, что ты выучил, втайне ручка контроля нагрузки. Пул ограничивает конкурентную работу. Таймауты освобождают ресурсы от обречённых запросов. Breaker сбрасывает нагрузку с падающей зависимости. Shutdown сбрасывает нагрузку с уходящего инстанса. Перегрузка — условие, что заставляет их все действовать разом, и эксплуатировать бэкенд значит настраивать их так, чтобы сервис гнулся, а не ломался.

Throughput — неверная цель; goodput — верная

Метрика, что важна под перегрузкой, — не сколько запросов ты принимаешь, а сколько завершаешь с пользой — достаточно быстро, чтобы ответ ещё значил что-то для вызывающего. Зови это goodput. Запрос, что ты принял, держал 8 секунд и наконец ответил после того, как клиент уже таймаутнулся и переретраил, — чистая трата: он съел соединение, слот loop и CPU и произвёл отрицательную ценность, потому что ещё и задержал реальную работу. За точкой насыщения подъём принятой нагрузки снижает goodput — классическая кривая перегрузки, где throughput лезет, пикует, затем падает с обрыва, как система тратит себя на работу, что больше не важна. Вся дисциплина обработки перегрузки в удержании системы на вершине той кривой вместо сползания по дальней стороне, а это значит отказ от работы, что не можешь завершить вовремя.

Сброс нагрузки: отвергай рано, отвергай дёшево

Сброс нагрузки — намеренное, раннее отвержение излишних запросов, чтобы принятые преуспели. Три свойства заставляют его работать:

• Рано. Сбрасывай на краю, до того как запрос съест пуловое соединение или даунстрим-вызов. Запрос, отвергнутый на приёме, стоит почти ничего; запрос, отвергнутый после захвата ресурсов, уже нанёс урон. Вот почему проверка приёма или ограничитель конкуренции сидит перед дорогими слоями.
• Дёшево и честно. Отвержение — быстрый 503 Service Unavailable с Retry-After, не медленная ошибка. Оно говорит клиенту не долби меня — что противоположно тихой медлительности, что запускает штормы ретраев.
• С приоритетом. Не вся нагрузка равна. Сбрасывай наименее ценное первым — фоновые обновления до пользовательских чтений, анонимных до платных, ретраи до первых попыток. Хороший сбрасыватель роняет правильные 20%, сохраняя goodput там, где он важен.

Backpressure: толкаем лимит вверх по течению

Двойник сброса — backpressure: вместо приёма работы и её сброса ты сигналишь вверх по течению замедлиться. Ограниченная очередь, что отвергает новые входы при заполнении, пул, что делает получение быстро падающим вместо безграничной очереди, HTTP-слой, что перестаёт читать сокет — каждый распространяет «я полон» обратно к источнику, так что давление чувствуется там, где его реально можно снизить (клиент отступает, вышестоящий сервис маршрутизирует иначе), а не поглощается тихо, пока что-то не сломается. Сброс и backpressure — две половины одной идеи: сделай лимит явным и обеспечь его на границе, а не позволяй неявному лимиту (память, файловые дескрипторы, пул) обеспечить себя коллапсом.

Каждый механизм — ручка контроля нагрузки

Синтез, к которому весь юнит строился: семь механизмов — не просто инструменты корректности, они актуаторы контроля нагрузки, и перегрузка — когда они комбинируются:

• Пул / лимит конкуренции — жёсткий потолок на работу в полёте. Важнейшая защита от перегрузки: он превращает «безграничную медлительность» в «ограниченную работу плюс явное отвержение».
• Таймауты — освобождают ресурсы от запросов, что не закончатся вовремя, так что обречённая работа перестаёт красть ёмкость у жизнеспособной.
• Circuit breaker — сбрасывает нагрузку с падающей зависимости, что есть перегрузка, локализованная на одном даунстриме.
• Ретраи (ограниченные, с backoff и jitter) — усилитель нагрузки, что надо ограничить, потому что неограниченные ретраи превращают перегрузку в коллапс.
• Graceful shutdown — сбрасывает нагрузку с уходящего инстанса, не роняя его работу в полёте на пол.
• Наблюдаемость — обратная связь, что говорит тебе, где ты на кривой goodput, так что сброс может запускаться реальным насыщением, не догадками.

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