AWS RDS для production: Terraform, Multi-AZ, моніторинг

Налаштування AWS RDS: де бойова база втрачає стійкість

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

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

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

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

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

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

Розбираємо ці точки відмови та те, як кожна закривається.

Що змінюється після наведення ладу в конфігурації

Якщо керована база прив'язана до однієї зони доступності, її відмова перетворюється на простій сервісу на весь час ручного відновлення зі знімка.

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

Час відновлення стає передбачуваним, бо параметри задані в конфігурації, а не в голові чергового.

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

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

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

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

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

Режими відмовостійкості RDS та їхні реальні обмеження

Режим резервування вибирається один раз — на рівні Terraform-модуля — і майже не змінюється без перестворення екземпляра.

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

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

Тому точку підключення ми описуємо окремо від екземпляра й перевіряємо поведінку на тренувальній відмові до виведення в бій.

Етапи розгортання та перевірки конфігурації

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

1. Аудит конфігурації — фіксуємо клас інстанса, режим Multi-AZ, вікно резервного копіювання, parameter group, доступ із публічних підмереж, термін зберігання знімків.
2. Проєктування схеми — приватні підмережі в двох зонах доступності, security group, шифрування сховища, репліка для читання, вікно обслуговування поза піковими годинами.
3. Інфраструктура як код — інстанс, subnet group, parameter group, правила алертів і політика бекапів описуються в Terraform-модулі; стан — у віддаленому бекенді з блокуванням, зміни лише через рев'ю.
4. Перевірка під навантаженням — відтворюємо реальний профіль запитів, знімаємо метрики в CloudWatch: затримку, кількість з'єднань, чергу на запис. Окремо перевіряємо перемикання під час відмови ведучої ноди.
5. Перемикання продакшену — трафік переносимо через репліку та знімок, вікно запису мінімальне, порядок відкату до попередньої схеми описаний заздалегідь.
6. Передача — дашборди, пороги алертів, регламент планової зміни параметрів та інструкція з відновлення зі знімка.

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

Артефакти й документація, які залишаються в команди

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

• Схема середовищ — скільки їх, чим відрізняються: де увімкнено Multi-AZ, які класи інстансів, терміни зберігання копій і чому.
• Опис конфігурації — структура Terraform-модуля, призначення змінних, де зберігається стан і як підключити до бази новий сервіс.
• Схема мережі й доступів — підмережі, групи безпеки, ролі IAM, через який вузол іде підключення розробників до продакшену.
• Політики доступу — розподіл ролей: хто змінює параметри кластера, хто лише дивиться метрики, як фіксуються дії адміністраторів.
• Регламент резервного копіювання — вікно знімків, глибина зберігання, відновлення на довільну точку в часі, копії в резервному регіоні.
• Регламент відновлення — покроковий сценарій підняття з копії з перевіркою на окремому середовищі та цільовим часом повернення в роботу.
• Набір метрик і алертів — які пороги вважаються проблемою, кому надходить сигнал і що робити за кожним сценарієм.
• Інструкції з типових операцій — зміна класу інстанса, оновлення major-версії, відпрацювання перемикання на резервний вузол.

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

Кейс: бойова база перестала падати під піковим навантаженням

Точка старту

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

Що змінили

Інфраструктуру описали як код і перевели базу на Amazon RDS у режимі Multi-AZ: резервний вузол в окремій зоні доступності та автоматичне перемикання без участі чергового.

Параметри, вікна обслуговування й політику резервного копіювання тепер змінюють через рев'ю в репозиторії, а не руками в консолі.

Увімкнули авторозширення сховища з оповіщенням про поріг заповнення, репліку для аналітичних запитів і шифрування знімків.

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

Що стало

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

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

Чим керована база відрізняється від бази на власних серверах

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

Керований сервіс на кшталт Amazon RDS бере на себе залізо, відмову диска, встановлення оновлень движка, резервні копії та перемикання на резервну ноду в іншій зоні доступності.

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

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

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

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

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

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

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

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

Якщо потрібні непідтримувані розширення або жорсткі вимоги до розміщення даних — рахуйте володіння власними серверами разом із чергуваннями й оновленнями.

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

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

Доведеться переписувати застосунок під репліки для читання?

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

Обсяг резервних копій зростатиме нескінченно?

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

Як проходить передача супроводу?

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

Передаємо стан, доступи через ролі, схему та інструкції — приймальна команда піднімає ідентичний стенд без усних домовленостей і прихованих ручних кроків.

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

Щоб повернутися з планом робіт і реалістичною оцінкою термінів, а не із загальними формулюваннями, потрібен зріз поточного стану.

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

Ввідні, за якими рахується склад робіт:

• поточні параметри бази: движок і його гілка, клас інстанса, режим Multi-AZ, кількість реплік читання;
• схема мережі: VPC, підмережі, групи безпеки, хто і звідки підключається до бази;
• як база живе зараз: ручні правки в консолі чи конфігурація під керуванням Terraform, де зберігається стан;
• вимоги до відмовостійкості: цільовий час відновлення, допустима втрата даних, вікна обслуговування;
• що вже підключено до моніторингу: які метрики знімаються, куди надходять алерти, хто на них реагує;
• обмеження: розподіл середовищ, порядок доступу інженерів до продових даних, регламенти.

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

Готові обговорити задачу предметно — опишіть її у вільній формі, і ми повернемося з планом.