Контейнеры на AWS: ECS, автоскалинг и CI/CD для продакшена

Настройка AWS ECS: где контейнеры падают в продакшене

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

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

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

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

Что меняется после перевода сервисов в управляемые контейнеры

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

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

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

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

Порядок внедрения: от аудита схемы до передачи в поддержку

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

1. Аудит инфраструктуры. Разбираем, где запущены контейнеры, как собираются образы, какие лимиты выставлены и сколько операций выполняется руками. На выходе — карта зависимостей и список узких мест, из-за которых схема отказывает под нагрузкой.

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

3. Настройка автоскалирования. Политики привязываем к метрикам, которые отражают реальную нагрузку, а не к косвенным признакам. Масштабирование срабатывает за минуты, а не после того, как очередь запросов выросла; отдельно задаём верхнюю и нижнюю границы, чтобы не уйти в бесконечный рост и не гасить сервис раньше времени.

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

5. Нагрузочная проверка. Прогоняем профиль, близкий к пиковому: смотрим, как отрабатывает автоскалирование, где упирается база, какие запросы деградируют первыми. По результатам правим пороги и лимиты по факту замеров.

6. Передача в эксплуатацию. Отдаём документацию по схеме и политикам, регламент обновления и отката, доступы и инструкции для дежурного. Команда заказчика проводит первый релиз при нашем сопровождении — передача подтверждается практикой, а не списком файлов.

Политики доступа, схемы сети и регламенты выпуска

Кластер, собранный без зафиксированных правил, живёт до первого нового инженера: права выдаются «чтобы точно работало», сеть описана только в памяти автора, а выпуск новой версии сервиса делается вручную из консоли.

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

• Роли и права — описание сервисных ролей для задач, разделение доступа между сборкой, средой исполнения и дежурным инженером, принцип минимально необходимых полномочий и отказ от долгоживущих ключей в пользу временных учётных данных.
• Схема сетевого доступа — какие подсети публичные, какие приватные, где стоят балансировщик и точки входа, что именно разрешают группы безопасности и почему границы проведены так.
• Регламент выпуска — порядок изменений, набор автоматических проверок до выпуска, кто утверждает и как проводится срочная правка в обход обычного окна.
• План отката — критерии, при которых выпуск останавливают, процедура возврата на предыдущую версию задачи и время, за которое сервис снова принимает трафик.
• Политики автомасштабирования — по каким метрикам расширяется и сжимается число задач, какие границы заданы и чем обоснованы.
• Матрица доступа — кто из сотрудников к чему имеет право и как права отзываются при уходе человека или смене подрядчика.
• Инструкции для дежурного — типовые сбои, что смотреть в первую очередь, куда идут логи и метрики, к кому обращаться вне рабочего времени.

Как сократили время выпуска и убрали отказы на пиках

Проект пришёл к нам с типовой картиной: приложение на нескольких постоянно включённых серверах, выпуск вручную по инструкции из внутренней базы знаний, а пики трафика встречал дежурный инженер — с телефоном в руке. Версия доезжала до продакшена 4-5 часов и сопровождалась коротким перерывом в обслуживании, а неудачный выпуск откатывали руками ещё несколько часов.

Что изменили в развёртывании

Заменили ручные шаги на неизменяемые образы и описали инфраструктуру в коде на AWS: сколько задач держать под базовой нагрузкой, по какому показателю добавлять новые, через какую паузу сжиматься обратно. Развёртывание перевели на постепенную замену — новая версия сначала берёт часть трафика, и только при чистом графике ошибок прежняя группа выводится из строя.

Метрики до и после

• выпуск версии: 4-5 часов с перерывом в обслуживании → 12-18 минут без остановки сервиса;
• восстановление после сбоя: 5-6 часов ручного разбора → 20-30 минут откатом на предыдущий образ;
• доля выпусков, дошедших до инцидента: каждый третий → один из двадцати.

Первый серьёзный пик пришёл через несколько недель после перевода: нагрузка выросла кратно за четверть часа. Автоматика добавила задачи, распределила их по зонам доступности и вернулась к базовому числу после спада — время отклика осталось в норме, дежурный вмешался только чтобы сверить графики. Раньше такой сценарий заканчивался отказами и ручной правкой конфигурации.

Частые технические сомнения перед началом работ

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

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

Будет ли простой при переводе?

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

Как закрывается безопасность контейнеров?

Образы собираются на минимальной базе и проверяются на уязвимости при сборке. Задачи работают под отдельными ролями с доступом только к нужным ресурсам, секреты подставляются при запуске из хранилища, а не лежат в образе.

Что с эксплуатацией и поддержкой после передачи?

Логи, метрики и алерты настраиваем до сдачи: видно потребление, число задач и время отклика. Автоскалинг привязан к нагрузке — в пик ёмкость растёт, в спокойные часы не простаивает. Дальше — сопровождение по согласованному объёму: обновления и разбор инцидентов.

Обсудим задачу и вернёмся с оценкой и планом

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

• Схема текущего продакшена: какие сервисы уже в контейнерах, что работает на управляемом оркестраторе, а что осталось на отдельных серверах.
• Как собираются и выкатываются образы: где шаги делаются руками, кто запускает выпуск и каким способом откатывают неудачный релиз.
• Профиль нагрузки: пики по часам и дням недели, сколько запросов держит один экземпляр сервиса, на каком пороге упирались в потолок.
• Требования к отказоустойчивости: сколько зон доступности нужно, какой простой считаете допустимым, что должно восстанавливаться без участия дежурного.
• Доступы и ограничения: учётные записи, сегментация сетей, политики безопасности, требования комплаенса и кто на вашей стороне принимает решения по инфраструктуре.
• Что болит сильнее всего: долгие выкатки, рост расходов на хранение логов и образов, падения под нагрузкой или отсутствие наблюдаемости.

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

Опишите задачу в свободной форме и приложите то, что есть под рукой, — вернёмся с оценкой и планом.

Что делать, если часть сервисов уже развёрнута на серверах?

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

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

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

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

Что уточняем на аудите перед выбором строки таблицы:

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