Контейнери на 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 для цього достатньо: реєстр образів, версіоновані ревізії задач, групи цілей для плавного переведення трафіку.

Ризики знімаємо поетапно, а не всі одразу: спочатку відкат — старий майданчик і попередня ревізія задачі залишаються робочими, потім доступи й мережеві правила, далі збереженість даних у разі відмови вузла.

Автоскейлінг вмикаємо після стабілізації метрик, інакше він маскує перевантаження замість того, щоб їх показувати.