Автоматическое масштабирование на основе памяти: спасаем наши задачи Sidekiq, когда метрики CPU нам лгали

Первоначально автор полагался на масштабирование на основе CPU для своей группы Auto Scaling, что является распространенной практикой, которая часто хорошо работает для веб-серверов. Однако фоновые задания, особенно те, которые используют Sidekiq, выявили существенный недостаток этого подхода. Критические фоновые задачи завершались с ошибками, а процессы-рабочие неожиданно падали, несмотря на низкую загрузку CPU. Основной причиной был определен убийца Out-of-Memory (OOM) Linux, который завершал процессы из-за нехватки памяти. Стандартная система мониторинга облака не отслеживала использование памяти, поэтому система оставалась в неведении о проблеме, в то время как использование CPU оставалось низким. Решение заключалось в установке агента CloudWatch для сбора и отправки метрик использования памяти. Используя новые метрики, автор затем реализовал политику масштабирования на основе памяти для группы Auto Scaling. Это изменение обеспечило предсказуемое масштабирование системы на основе нагрузки на память, добавляя экземпляры до сбоя службы. В результате сбои прекратились немедленно, что повысило стабильность и эффективность системы. Наконец, автор подчеркнул, что фоновые рабочие часто требуют масштабирования, ориентированного на память, по сравнению с веб-серверами.