KEDA autoscaling позволяет масштабировать Kubernetes по backlog в SQS. Это меняет сигнал масштабирования с CPU на реальную нагрузку.
В event-driven системах на Kubernetes классические метрики, такие как CPU и memory, часто не отражают реальное давление на систему. Под может быть почти idle, но очередь Amazon SQS уже содержит тысячи сообщений. Обратная ситуация тоже типична: поды продолжают работать после того, как всплеск трафика уже прошёл. В таких условиях autoscaling по CPU приводит либо к задержкам обработки, либо к избыточным ресурсам. Ключевая проблема — неверный сигнал масштабирования. В очередях сигналом является backlog, а не утилизация инфраструктуры.
Решение строится вокруг KEDA autoscaling и интеграции с Amazon SQS. KEDA наблюдает за метриками очереди и управляет Kubernetes HPA. Это смещает фокус с ресурсных метрик на объём работы. Основной trade-off — зависимость от внешнего источника метрик (SQS) и необходимость корректно настроить параметры масштабирования. Взамен система начинает реагировать на фактическую нагрузку: быстрее обрабатывает пики и не держит лишние поды при пустой очереди. Такой подход давно обсуждается в индустрии как более точный для асинхронных workload.
Архитектура включает KEDA operator, metrics API server и CRD-ресурсы, такие как ScaledObject и TriggerAuthentication. Установка выполняется через Helm, что упрощает внедрение. Доступ к SQS настраивается через IAM с принципом least privilege. Это важно, так как KEDA требует доступ только к конкретной очереди. Связка deployment и очереди реализуется через ScaledObject. Параметр queueURLFromEnv позволяет избежать хардкода. KEDA вычисляет backlog как сумму ApproximateNumberOfMessages и ApproximateNumberOfMessagesNotVisible, при необходимости учитываются delayed сообщения.
Модель масштабирования строится вокруг queueLength. Например, если задано значение 10, один под обрабатывает 10 сообщений. Формула проста: desired replicas = ceil(outstanding messages / queueLength). Итоговое число подов ограничивается minReplicaCount и maxReplicaCount. Поддерживается scale-to-zero, что важно для экономии ресурсов. Проверка поведения системы выполняется через отправку сообщений в очередь и наблюдение за ScaledObject и подами через kubectl. Возможные проблемы включают отсутствие scale-out, избыточное количество подов или невозможность вернуться к нулю.
Результат — более точное соответствие между нагрузкой и масштабированием. Система быстрее реагирует на пики и снижает idle-затраты при пустой очереди. Конкретные метрики улучшений в исходном материале не указаны, но поведение системы становится более предсказуемым. Такой подход универсален и применим не только к SQS, но и к другим messaging системам. Ключевой принцип — выбирать метрику, которая отражает реальную работу, а не косвенные признаки нагрузки.