Налаштування хмарної інфраструктури на AWS під production

Налаштування AWS під бойове навантаження: що ламається

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

Першою відмовляє не сервер, а зв’язки між сервісами. Пул з’єднань до бази вичерпується на піку, частина запитів чекає на звільнення, час відповіді зростає, і повторні спроби клієнтів добивають те, що ще трималося.

Додати екземпляри під навантаження нічим: образи, змінні середовища й мережеві правила живуть в інтерфейсі та в голові інженера, який усе це збирав.

Далі проявляється розходження середовищ. Бойовий контур відрізняється від тестового правками, накопиченими за місяці: розгорнути його з нуля не можна, а відкат до попереднього стану перетворюється на нічну роботу з непередбачуваним результатом.

Тому вузькі місця інфраструктури не видно до піку — спостереження налаштовано на ознаку «живий чи ні», а не на насичення черг, і відмова за пікового навантаження приходить без попередження.

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

Що дає вибудувана інфраструктура: вимірюваний ефект

Інфраструктуру варто оцінювати за чотирма вимірюваними величинами, а не за кількістю піднятих сервісів. Нижче — орієнтири, за якими видно, що робота справді зроблена, а не просто «налаштовано»: за кожним пунктом фіксуємо значення до старту та після здачі.

• Швидкість викочування змін. Конвеєр збирає, перевіряє й доставляє кожну зміну без ручної участі: шлях від коміту до продуктивного контуру займає хвилини, а відкат на попередню версію — одна команда. Викочування перестає бути подією, що потребує вікна та чергування.
• Час відновлення після збою. Резервні копії регулярно перевіряються відновленням на окремому контурі, резервні вузли прогріті в іншій зоні доступності. Перемикання трафіку автоматичне, тому відновлення вкладається в десятки хвилин, а не в години ручних розборів.
• Зменшення ручних операцій. Середовища описані декларативно й піднімаються з коду, тому розходження між стендами зникають, а частка правок через вебконсоль падає майже до нуля. Новий контур розгортається тією ж конфігурацією, що й продуктивний.
• Усунений клас відмов. Автоматичні перевірки перед викочуванням і контроль конфігурації прибирають цілу групу збоїв — через незаплановані ручні правки й різні налаштування на стендах. Інциденти цього типу просто перестають з’являтися в журналі.

У AWS всі чотири величини знімаються штатними засобами моніторингу, тож прогрес видно на дашборді, а не у звітах «на словах». Якщо хоч одна з метрик не зрушила — отже, вузьке місце залишилося і його потрібно дотискати.

Варіанти налаштування AWS: порівняння підходів

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

На практиці варіанти не суперничають, а змінюють один одного: єдиний акаунт поступається розділеним середовищам, поверх яких додається резервування за зонами доступності.

Перехід — не переписування з нуля, а перенесення вже працюючих налаштувань в опис, тому простоїв на цьому кроці можна уникнути.

Етапи впровадження: від аудиту до передачі в роботу

Налаштування AWS під промислову експлуатацію — не разове встановлення сервісів, а послідовність кроків, де кожен спирається на результат попереднього. Якщо проєктувати цільову конфігурацію до аудиту, частина неявних зв’язків і обмежень спливе вже під навантаженням. Нижче — шість етапів із перевірюваним результатом на кожному.

1. Аудит інфраструктури. Збираємо фактичний стан: що розгорнуто, як ходять запити, де конфігурація розходиться з документацією, які доступи видані із запасом. Результат — карта залежностей і перелік вузьких місць за пріоритетом.
2. Схема цільової конфігурації. Ізольовані середовища, сегментація мережі, ролі доступу, керування секретами, ліміти та правила масштабування. Узгоджуємо схему до початку робіт: правки тут дешевші за правки в коді.
3. Реалізація. Переносимо конфігурацію в код — середовища піднімаються із шаблонів, зміни проходять перевірку, ручні правки в консолі виключені. Стан інфраструктури стає відтворюваним, а розходження видні одразу.
4. Перевірка відмовою. Свідомо ламаємо: гасимо вузол, відкликаємо доступ, розриваємо зв’язок між сегментами. Дивимося, чи відновлюється система сама й за який час, — до того, як це станеться випадково.
5. Документація. Схема, змінні середовища, порядок відновлення, власники сервісів і точки контролю. Новий інженер піднімає стенд за нею без усних пояснень.
6. Передача в супровід. Розбираємо з вашою командою регламент змін і чергувань, передаємо доступи, фіксуємо порядок ескалації та межі відповідальності.

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

Комплект документів і конфігурацій на виході

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

• Інфраструктура як код — мережі, підмережі, групи безпеки, балансувальники й бази описані в репозиторії. Будь-яка зміна проходить перевірку й залишається в історії, ручних правок у консолі не залишається.
• Політики доступу та ролі — матриця «хто що може», мінімально необхідні права, окремі ролі для сервісів, чергових інженерів і збірки. Секрети лежать у захищеному сховищі з ротацією.
• Схема мережі та потоків даних — які сервіси куди звертаються, де приватні й публічні сегменти, як влаштовані точки входу й що закрито від зовнішнього доступу.
• Регламент резервного копіювання та відновлення — що копіюється, з якою періодичністю, де зберігається, як перевіряється відновлення й скільки воно займає за фактичними вимірами.
• Документація з інфраструктури — архітектурна схема, опис середовищ, змінні та залежності, порядок розгортання й відкату релізу.
• Моніторинг і сповіщення — набір метрик і порогів спрацьовування, маршрутизація повідомлень за черговими, розбір типових інцидентів і дій за ними.
• Передача знань команді — спільні розбори й парне чергування: ваші інженери проходять шлях «зміна → розгортання → відкат» своїми руками.

Комплект залишається у вашому репозиторії та внутрішній базі знань — не в чужому акаунті й не в голові підрядника.

Кейс: пікове навантаження без аварій і ручних правок

Магазин із сезонними розпродажами: трафік зростав у десять разів за хвилини, а інфраструктура на AWS масштабувалася вручну. Черговий інженер піднімав віртуальні машини за чек-лістом, правив маршрутизацію балансувальника й уночі стежив за графіками.

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

Що змінили

Інфраструктуру описали як код: мережа, права доступу, бази й черги збираються з репозиторію, а не в консолі.

Автомасштабування перевели із добового середнього на поточне навантаження, додали перевірки живучості застосунку й заздалегідь прописали поведінку за відмови зони доступності. Зміни проходять через рев’ю й повторюються на тестовому контурі один в один.

Метрики до й після: час відновлення — з 40 хвилин до 3–4; частка операцій, що потребують ручної роботи, — з 70% до 9%; інциденти на піках — п’ять за квартал проти нуля за пів року спостережень.

Образи й конфігурації версіонуються, тому відкат до попереднього релізу займає хвилини, а не години.

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

Стійкість сервісу тримається рівно доти, доки схеми резервування та регламенти оновлюються разом із продуктом.

Чим керований сервіс відрізняється від власного сервера?

Суперечку «сервіс чи власний сервер» зазвичай ведуть не про технології, а про те, де проходить межа зони відповідальності. У керованій моделі провайдер тримає фізичні вузли, відмовостійкість, оновлення й резервні копії, а ви відповідаєте за конфігурацію, доступи та схему даних.

На власних серверах уся вертикаль — від заліза до прикладного патча — залишається на команді, і її не можна винести за межі договору.

Керовані сервіси знімають роботу там, де завдання типове: реляційна база, черга повідомлень, кеш, об’єктне сховище. Заміна вузла, що вийшов з ладу, реплікація та оновлення мінорної версії проходять без участі ваших інженерів — у AWS це закладено в конструкцію самих сервісів.

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

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

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

У компромісу є своя плата. Чим глибше ви використовуєте унікальні можливості провайдера, тим дорожчим є перенесення: прив’язка зростає разом з обсягом знятої рутини.

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

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

Технічні сумніви перед початком робіт

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

Чи можна впроваджувати частинами?

Так, контур розбивається на етапи: мережа й доступи, збірка та доставка коду, спостережуваність і резервне копіювання. Кожен етап закриває своє завдання й працює окремо — можна зупинитися після будь-якого й продовжити пізніше.

Середовища будуть відтворюваними?

Інфраструктура описується декларативно й зберігається в системі контролю версій. Середовище піднімається з одного опису, відмінності виносяться в параметри — тестовий стенд можна розгорнути заново й отримати ту саму конфігурацію, що й у робочий контур.

Що з відповідальністю після передачі?

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

Чи можна відкотити зміну?

Так. Конфігурація версіонується, відкат — повернення до попереднього опису та його застосування. Дані відновлюємо зі знімків, якщо зміна зачіпала сховище.

Обговоримо завдання й повернемося з оцінкою та планом

Щоб оцінка спиралася на факти, а не на припущення, для старту достатньо кількох вхідних даних. Зберіть те, що є під рукою — чернетки схем і нотатки підійдуть, відновлювати за вас документацію не доведеться.

• Перелік сервісів та їхня роль у продукті: що обслуговує користувачів, що працює у фоні.
• Поточний профіль навантаження — пікові запити, обсяги даних, сезонні сплески.
• Вимоги до середовищ: скільки потрібно контурів і чим вони різняться за доступами.
• Обмеження: терміни, зафіксовані інтеграції, вимоги безпеки та аудиту.
• Цільові показники: допустимий час простою, швидкість відновлення, глибина зберігання копій.
• Регламент релізів — хто і як часто викочує зміни, чи потрібен автоматичний відкат.

У відповідь приходить робочий пакет, а не загальні слова.

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

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