Потолок очереди задач: с какой глубины воркеры не догонят её уже никогда

MAATRIX

Очередь фоновых задач растёт третий день подряд, а дашборд по-прежнему зелёный: воркеры работают, ошибок нет, CPU в пределах нормы. Команда решает подождать — «сейчас нагрузка спадёт, и очередь сама рассосётся». Иногда действительно рассасывается. А иногда нет, потому что скорость поступления задач стабильно выше скорости их обработки — и это не временный всплеск, а системное неравенство, которое ожиданием не лечится. Разберём математику, которая точно отвечает на вопрос «догоним или нет», как посчитать нужное число воркеров под конкретный поток и в какой момент пора не ждать, а масштабировать горизонтально.

Little's Law простыми словами: как связаны очередь, время ожидания и поток

Есть один закон теории очередей, который объясняет почти всё поведение любой очереди задач — от Celery до кассы в супермаркете. Формулируется он до неприличия просто:

L = λ × W

Где L — среднее число задач в системе (в очереди плюс в обработке), λ (лямбда) — скорость поступления новых задач в единицу времени (задач в секунду), W — среднее время, которое задача проводит в системе от постановки до завершения.

Смысл на пальцах: если в очередь каждую секунду прилетает 10 задач, и каждая в среднем проводит в системе 5 секунд (ждёт плюс выполняется), то в любой момент времени в системе одновременно находится примерно 50 задач. Это не приближение и не эвристика — это математически точное соотношение для любой стабильной системы массового обслуживания, будь то очередь в Redis, буфер сетевой карты или очередь на кассе.

Дальше вводим второй показатель — производительность одного воркера, μ (мю): сколько задач он способен закончить за секунду. Если у вас n воркеров, суммарная пропускная способность системы — n × μ. Отношение входящего потока к суммарной пропускной способности называется загрузкой (utilization):

ρ = λ / (n × μ)

Это единственное число, от которого зависит, догонит очередь себя сама или нет. Всё остальное — детали конкретного стека.

Условие устойчивости: когда очередь стабилизируется, а когда растёт без предела

Если ρ < 1 — система стабильна. Очередь колеблется вокруг какого-то среднего уровня: растёт в пиковые часы, проседает ночью, но не уходит в бесконечность. Чем ближе ρ к единице, тем выше это среднее и тем длиннее и болезненнее случайные всплески — но система в целом справляется.

Если ρ ≥ 1 — стабильного состояния не существует в принципе. Средняя длина очереди по формуле Литтла растёт линейно со временем без предела, и никакой размер буфера, никакой SSD под очередью, никакое терпение это не остановит. Рост упрётся не в математику, а в физику: закончится память Redis или диск RabbitMQ, сработает TTL и задачи начнут молча удаляться, или брокер начнёт отклонять новые публикации — но это не решение проблемы, а её отказ в аварийном режиме.

Важный практический нюанс: даже при ρ, близком к единице снизу (скажем, 0.9-0.95), среднее время ожидания в очереди растёт не линейно, а гораздо резче — по мере приближения ρ к 1 задержка уходит в разгон. Пока запас пропускной способности большой, задержки маленькие и стабильные; когда запас истончается, та же самая нагрузка даёт непропорционально длинные очереди и хвостовые задержки. Поэтому «воркеры справляются, просто впритык» на практике часто означает, что вы уже в зоне, где любой случайный всплеск входящего потока даёт многочасовую задержку, даже если в среднем ρ пока меньше единицы.

Отсюда и ключевая методологическая ошибка: смотреть на мгновенное значение ρ вместо тренда за представительный период. Ночной всплеск batch-задач, после которого очередь днём стабильно возвращается к нулю — это нормальное дыхание системы, а не проблема. А вот если усреднённая за сутки (или за неделю, если есть недельная сезонность) скорость поступления стабильно выше усреднённой пропускной способности — это структурная проблема независимо от того, как выглядит график в конкретный час.

Как посчитать нужное число воркеров под известный поток задач

Расчёт делается в четыре шага, и все нужные числа обычно уже есть в мониторинге.

Шаг 1. Измерьте λ — скорость поступления задач. Берите не мгновенное значение, а среднее за представительное окно: если нагрузка выражено дневная, считайте по пиковым часам, а не по суточному среднему — иначе система будет прекрасно справляться ночью и копить долг днём. Источники:

# RabbitMQ: скорость публикации, задач/сек
rabbitmq_queue_messages_published_total (Prometheus, rate() за 5m)

# Celery: тот же брокер, либо через flower/events
celery -A myapp events --camera=camera.MyCamera

# Sidekiq: Sidekiq Web UI, вкладка Dashboard — Processed/Enqueued по времени
# или Sidekiq::Stats.new.processed за интервал

# BullMQ
await queue.getMetrics('completed', 0, -1) # с шагом времени

Шаг 2. Измерьте μ — пропускную способность одного воркера. При последовательной обработке это просто обратная величина от среднего времени выполнения: μ = 1 / avg_duration. При конкурентности (потоки, prefork, корутины) c — приблизительно μ_воркера ≈ c / avg_duration, но только пока задача не упирается в тот же процессор, что и соседние потоки: для CPU-bound задач конкурентность выше числа физических ядер прироста почти не даёт.

# Celery: средняя длительность задачи по типам
celery -A myapp inspect stats
# либо метрика celery_task_runtime_seconds из prometheus-exporter'а

# RabbitMQ/произвольный consumer: время между consume и ack, из логов приложения

# Sidekiq: Sidekiq::Queue#latency и время выполнения из метрик мидлвари

Шаг 3. Посчитайте минимум для устойчивости. n_min = λ / μ_воркера — это граница, за которой ρ = 1. На этом уровне система формально не растёт бесконечно, но и не сокращает уже накопленный backlog, а любой всплеск толкает её в нестабильность.

Шаг 4. Заложите запас. На практике целятся не в ρ = 1, а в ρ около 0.6-0.8 — это даёт запас на переваривание всплесков и реальное сокращение очереди после инцидентов, а не хождение по кромке:

n_safe = ceil(n_min / target_ρ)

Иллюстрация (условные числа, не бенчмарк — у вас будут другие): входящий поток λ = 50 задач/сек, средняя длительность задачи 2 секунды при однопоточной обработке, значит μ_воркера = 0.5 задач/сек.

Разница между 100 и 143 — это не запас «на всякий случай», а разница между системой, которая едва держится на грани, и системой, которая реально успевает разгребать всплески и сокращать накопленный долг после них.

Признаки того, что «не догоним»: что смотреть на графиках

Прежде чем добавлять воркеров, стоит подтвердить диагноз — иначе есть риск добавить мощности не туда, где реальное узкое место. Смотрите на четыре сигнала вместе, а не по отдельности:

• Глубина очереди на многодневном тренде. Не разовое число, а линия за несколько дней или недель. Монотонный рост, включая ночные и выходные провалы — но провалы не до нуля, а до всё более высокой планки каждый раз — это и есть сигнал накопления долга.
• Время ожидания задачи в очереди (queue latency, time-to-pickup) растёт, а время выполнения — нет. Это ключевой различитель: если бы воркеры замедлились сами по себе, росла бы длительность выполнения. Растёт именно ожидание — значит, задачи копятся быстрее, чем их успевают взять в работу.
• Consumer lag для потоковых систем. Для Kafka это kafka-consumer-groups.sh --describe --group my-group или метрика kafka_consumergroup_lag — устойчивый рост lag при стабильном или растущем входящем потоке означает то же самое неравенство λ и n×μ.
• Плато по завершённым задачам в минуту при растущей очереди. Если метрика "completed jobs/min" перестала расти вместе с очередью — система уже работает на максимуме своей суммарной пропускной способности n × μ и физически не может ускориться сама. Это отличает «воркеры пока справляются, но впритык» от «воркеры уже упёрлись в потолок», и во втором случае ждать бессмысленно: быстрее она сама не станет.

Практическое правило: посчитайте λ_средн за представительное окно (сутки или неделя с учётом сезонности) и μ_total_средн — фактическую пропускную способность при текущем n. Если λ_средн стабильно больше μ_total_средн дольше одного полного цикла нагрузки (обычно сутки) — это не колебание, а тренд, и с ним не разбирается ожидание.

С какой глубины воркеры физически не догонят очередь

Здесь кроется частая ловушка: искать конкретное число — «если очередь больше 50 000 задач, всё, приехали» — как будто существует универсальный порог глубины, после которого возврат невозможен. Такого порога нет. Глубина очереди — это симптом, а не причина: она сама по себе не меняет знак неравенства λ и n × μ. Очередь и с глубиной 5000, и с глубиной 500 000 одинаково успешно вернётся к норме, если добавить воркеров или ускорить обработку — математика не завязана на текущий backlog.

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

долг(T) = ∫ (λ(t) − n × μ(t)) dt  за период T

Если за сутки или неделю этот интеграл положительный — то есть суммарно за период задач пришло больше, чем ушло, — система не успевает восстановиться даже в свои лучшие часы, и разрыв нарастает от цикла к циклу. Вот это и есть настоящий признак «не догоним»: не абсолютная цифра в LLEN, а знак накопленного за представительный период баланса. Проверить это проще, чем считать интеграл руками — достаточно сравнить глубину очереди в одно и то же время суток (например, каждое утро в 6:00, после ночного затишья) неделю подряд. Если эта опорная точка растёт от дня к дню, долг не гасится, и ждать больше нет смысла.

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

Когда нужно горизонтальное масштабирование, а не терпение

Если диагноз подтверждён — ρ устойчиво больше или около единицы на представительном окне, а не в моменте — терпение не вариант, и дальше вопрос только в том, что именно масштабировать.

Здесь два разных случая, которые важно не путать:

Случай A: не хватает мощности (n мало). Классический ответ — добавить воркеров: больше процессов, больше подов, больше реплик consumer-группы. Это горизонтальное масштабирование в чистом виде, и для очередей задач оно почти всегда даётся легче, чем для веб-слоя — воркеры обычно не хранят состояние между задачами, поэтому добавление нового процесса не требует переделки архитектуры так, как это нужно для стейтфул веб-приложений (подробнее о разнице экономики вертикального и горизонтального роста — в статье «Стоимость масштабирования: что дороже, вверх или вширь»).

Случай B: мало пропускной способности на одну задачу (μ мало). Если каждая задача сама по себе медленная — например, синхронно дёргает внешний API без таймаута или делает N+1 запросов к базе — иногда дешевле и правильнее ускорить саму задачу (батчинг, кэш, асинхронные вызовы, индекс в базе), чем бесконечно множить воркеры вокруг медленного кода. Рост n при низком μ на задачу быстро упирается в следующий потолок — общий для всех воркеров ресурс.

Скрытый потолок горизонтального масштабирования. Добавление воркеров повышает n × μ только пока узкое место — сами воркеры. За какой-то точкой ограничением становится общий ресурс ниже по стеку: пул соединений базы данных, rate limit стороннего API, единственный инстанс Redis, который сам упирается в CPU. Тогда формула суммарной пропускной способности превращается в:

μ_total = min(n × μ_воркера, лимит_внешнего_ресурса)

Признак этого — воркеров становится больше, а completed jobs/min не растёт, зато растут ошибки вида "too many connections" или 429 от API. В этом случае горизонтальное масштабирование воркеров бесполезно и даже вредно, пока не расширен сам ограничивающий ресурс (пул соединений, шардирование Redis, повышение лимита у провайдера API).

Автомасштабирование по тренду, а не по мгновенной глубине. Если воркеры разворачиваются в Kubernetes, KEDA умеет масштабировать Deployment по метрике длины очереди RabbitMQ/Redis напрямую через ScaledObject; у Celery есть встроенный флаг --autoscale=max,min на процесс. Но триггерить масштабирование стоит по тренду или по устойчивому превышению порога за окно в несколько минут, а не по мгновенному значению глубины — иначе система будет то добавлять, то убирать воркеров на каждый локальный всплеск, тратя время на прогрев процессов вместо реальной работы.

Частые вопросы