Налаштування Azure SQL Database: де ламається інфраструктура
Налаштування Azure SQL Database починається не з вибору рівня обслуговування, а з відповідей про профіль навантаження: хто читає, хто пише і що станеться в разі відмови вузла.
Міграція бази в хмару проходить спокійно, а вузькі місця під навантаженням проявляються пізніше — коли звітність і фонові завдання починають конкурувати з транзакціями за ті самі ресурси.
Перший збій — зростання навантаження на читання. Важкі аналітичні запити потрапляють на той самий екземпляр, що обслуговує запис, і першими страждають операції оформлення замовлення.
Лікується це не лише підвищенням рівня: частину читання виносять на репліки лише для читання, звіти — на окрему копію або еластичний пул, а гарячі запити отримують покривні індекси.
Друге джерело — блокування. Довга транзакція тримає рядки, застосунок чекає, тайм-аути зростають каскадом.
Перевіряємо режим ізоляції на основі знімків, час життя транзакцій, плани запитів і статистику очікувань: частіше причина в неявних перетвореннях типів і відсутності індексу під конкретний фільтр, а не в нестачі потужності.
Третій — відмовостійкість бази даних без плану перемикання. Георепліка або група відпрацювання відмови налаштовані, але ніхто не перевіряв, за який час застосунок підніметься після аварії та чи вміє драйвер перепідключатися.
Окремий ризик — ручні правки: опис у Terraform розходиться з фактичним станом, і наступне розгортання відкочує налаштування.
Четвертий — неперевірені копії: строк зберігання, момент відновлення та розгортання в окремий сервер ніхто не відпрацьовував. Копія, з якої жодного разу не піднімали базу, гарантією не є. Розбираємо, як ці чотири місця закриваються налаштуванням, регламентом і прогонами.
Що змінюється після впровадження: простій, відновлення, відмови
Після налаштування Azure SQL Database контур описується кодом і поводиться однаково в усіх середовищах: репліки в різних зонах доступності, автоматичне перемикання й застосунок, який переживає його без ручного втручання.
Вікно недоступності під час планових робіт і відмови вузла скорочується з годин до хвилин, а час відновлення стає передбачуваною величиною, а не результатом пошуку причини.
Що зникає назавжди
Цілий клас відмов закривається на рівні конфігурації: втрата даних через відсутність копій, простій в очікуванні адміністратора, розходження налаштувань між середовищами через правки руками.
Відновлення на вибрану точку в часі — штатна процедура: точка вибирається за журналом транзакцій, політика зберігання копій описана й перевіряється на тестовому контурі, тому строк повернення в робочий стан відомий заздалегідь.
Передбачуване навантаження та обсяг
Навантаження стає передбачуваним, коли обмежені паралелізм, розмір пулів з’єднань і профіль обслуговування під пікові запити. Журнал очікувань і статистика запитів показують деградацію до того, як її помітять користувачі.
Обсяг даних при цьому не тягне витрати за собою: гарячі дані залишаються в оперативній частині, історичні йдуть в архів зі стисненням і секціонуванням, старі знімки видаляються за політикою зберігання. Витрати на зберігання перестають зростати, а реєстр резервних копій скорочується в рази.
Порівняння моделей розгортання та рівнів сервісу
В Azure SQL Database вибір складається з двох осей: модель розгортання — окрема база, еластичний пул, керований екземпляр — і рівень сервісу всередині неї.
Окрема база дає ізоляцію та передбачувану поведінку застосунку, пул збирає спільний резерв на десятки баз зі зміщеними в часі піками, керований екземпляр відкриває можливості рівня сервера.
Рівень сервісу визначає, що переїжджає в платформу: у General Purpose сховище винесено за межі обчислювального вузла, тому відгук чутливий до затримки вводу-виводу; у Business Critical додано локальний шар і другу читану репліку; Hyperscale швидко розширює сховище й відновлюється зі знімків.
Логіка в пам’яті, міжбазові запити та агент завдань доступні не всюди — це і є обмеження сумісності, які перевіряють до перенесення.
| Варіант | Коли підходить | Обмеження конфігурації |
|---|---|---|
| Окрема база | один продукт, відоме навантаження, потрібна ізоляція | резерв під пік тримається в кожній базі, міжбазових запитів немає |
| Еластичний пул | 5+ баз зі зміщеними піками, спільний резерв ресурсів | не можна гарантувати окремій базі частку ресурсів, є стеля на кількість баз |
| Керований екземпляр | потрібні агент завдань, міжбазові запити, служби рівня екземпляра | частина сервісних можливостей закрита, масштабування довше, зворотний перехід — лише міграцією |
| Business Critical | критичний відгук, потрібна друга читана репліка | обмеження на частину операцій сховища |
| Hyperscale | швидке зростання обсягу, тривале зберігання історії | частина функцій обслуговування недоступна |
Зміна моделі розгортання майже завжди одностороння, тому конфігурацію фіксуємо до міграції: де потрібен пул, де рівень із локальною реплікою, а де без керованого екземпляра не обійтися. Код застосунку при цьому залишається незмінним — змінюються лише параметри платформи.
Налаштування та впровадження: етапи від аудиту до передачі
Роботи йдуть за одним порядком і для нової бази, і для переїзду наявної: спочатку фіксуємо факти про навантаження, потім проєктуємо, налаштовуємо і лише після перевірки віддаємо в експлуатацію.
Так відсікається типовий сценарій, коли відмовостійкість зібрана за шаблоном і розсипається на реальному профілі запитів Azure SQL Database.
- Аудит навантаження. Знімаємо статистику очікувань, блокувань, зростання даних і піків за годинами, розбираємо важкі плани запитів — рівень сервісу підбирається за профілем, а не на око.
- Схема відмовостійкості. Визначаємо, що саме має пережити відмову: зону, регіон, втрату репліки. Вибираємо топологію реплік, модель резервних копій і цільовий час відновлення.
- Налаштування та інфраструктура як код. Сервер, база, правила доступу й приватні підключення описуються в Terraform: розгортання відтворюється з нуля, зміни проходять рев'ю, ручних правок у консолі не залишається.
- Перевірка під відмову. До виведення в бойовий контур проганяємо примусове перемикання, відмову зони й деградацію під навантаженням, фіксуємо фактичний час відновлення та поведінку застосунку.
- План перемикання. Оформлюємо порядок дій з ролями й точками ухвалення рішень: що відпрацьовує автоматика, що підтверджує черговий інженер за індивідуальним розрахункомПеревірка після впровадження та передача. Знімаємо метрики на бойовому трафіку, звіряємо з цільовими та віддаємо схему, конфігурацію, регламент перемикання й чек-ліст експлуатації.
Конфігурації, схеми відмовостійкості та регламенти
Після здачі проєкту у вашої команди залишається не набір усних домовленостей, а документація, за якою інфраструктуру можна експлуатувати, розширювати й передавати іншому інженеру.
Стан бази Azure SQL Database ми фіксуємо у вигляді коду й додаємо до нього схеми, політики та регламенти — усе у вашому репозиторії, з історією змін і рев'ю.
- Опис інфраструктури в Terraform: сервери, бази, пули, мережеві правила й параметри рівня обслуговування — конфігурація відтворювана, зміни йдуть через рев'ю, а не через ручні правки в консолі.
- Схеми інфраструктури: топологія розміщення, реплікація, перемикання на резервний регіон, точки входу застосунків, зв'язки з приватними мережами й моніторингом.
- Політика резервного копіювання: глибина зберігання повних і диференціальних копій, розклад, регулярна перевірка відновлення на тестовому контурі із заміром часу.
- Регламент доступу: матриця ролей, розділення адміністративних прав і прав читання, порядок видачі й відкликання, підключення лише через захищений шлюз.
- Документація з експлуатації: планове обслуговування, зміна рівня обслуговування й масштабування, розбір типових відмов і порядок дій при деградації.
- Сценарій аварійного відновлення: відкат до точки відновлення, перемикання на репліку й критерії, за якими черговий ухвалює рішення.
- Регламент зміни схеми: правила накочування міграцій, перевірки на тестовому контурі, порядок відкату невдалого релізу.
Кейс: час відновлення й пікове навантаження до і після
Сервіс із короткими піками: навантаження концентрувалося в кілька вікон на добу, і база на універсальному тарифі в ці години йшла в чергу очікування.
Відгук просідав, частина запитів обривалася через перевищення часу очікування, а збій вузла розбирали вручну — відновлення розтягувалося на години.
Перевели базу на керований сервіс Azure SQL Database й описали топологію кодом: тарифний рівень, репліки читання, правила резервного копіювання та порядок відпрацювання відмов тепер відтворюються з опису, а не збираються руками.
Середовища збірки та промислове перестали розходитися — розходження конфігурацій давало половину нічних розборів.
Що змінилося в цифрах
| Показник | До | Після |
|---|---|---|
| Пікове навантаження | запити в черзі, частина не проходить | пік проходить без деградації, запас на зростання вдвічі |
| Час відновлення | години ручних операцій | хвилини за відпрацьованим регламентом |
| Інцидентів на місяць | регулярні, з нічними розборами | поодинокі, причина локалізується за журналом |
| Ручні операції | правки в панелі під кожен реліз | викат з опису, відкат однією командою |
Що це дало команді
Черговий перестав бути вузьким місцем: типова відмова закривається за інструкцією, а не пошуком винної ланки. Звільнений час пішов на розвиток продукту, а не на гасіння піків і ручні правки конфігурацій.
Чим керований екземпляр відрізняється від окремої бази?
Керований екземпляр — майже повноцінний SQL Server у приватній підмережі: працюють міжбазові запити за тричастинними іменами, завдання агента, пов'язані сервери, штатне резервне копіювання й відновлення.
Окрема база — сервіс під одну схему: сусідні бази вона не бачить, а адміністрування зводиться до налаштувань самої бази та її рівня обслуговування.
Перший критерій вибору — сумісність застосунку. Якщо код виріс з моноліту й звертається до сусідньої бази за тричастинним ім'ям, а нічна обробка висить на завданнях агента, перенесення в окрему базу потребує переписати ці звернення й винести завдання назовні.
Зворотний перехід таких обмежень не має: базу з керованого екземпляра виносять в окремий сервіс без правок коду, тому починати з екземпляра безпечніше.
Другий критерій — мережа. Керований екземпляр живе у вашій віртуальній мережі, публічної адреси в нього немає, трафік надходить лише з приватних адрес. Якщо регламент безпеки вимагає закритого контуру, це відразу відсікає сценарії із зовнішнім підключенням окремої бази.
Третій критерій — модель обслуговування. Екземпляр резервує ресурси під себе, і сусідні бази на ваше навантаження не впливають; окрема база гнучкіша за рівнем обслуговування й іде в паузу при простої, але ділить потужності з іншими.
Terraform описує обидві моделі декларативно — рівень сервісу, зона резервування, група відпрацювання відмови.
Звідси робоче правило: систему з перехресними зв'язками переносимо в керований екземпляр, новий сервіс з однією схемою піднімаємо на окремій базі. Рішення ухвалюємо за вимогами застосунку та регламентом безпеки, а не за звичкою.
Часті технічні сумніви та межі застосовності
Межі застосовності фіксуємо до старту: чи підходить виділена база під профіль навантаження або вигідніший еластичний пул, який рівень надлишковості потрібен, як поводитиметься застосунок на репліках лише для читання. Нижче — відповіді на запитання, які найчастіше виникають на етапі оцінки.
Сумісність застосунку — чи доведеться щось переписувати?
Зазвичай ні, якщо застосунок працює через стандартний драйвер і не спирається на серверні файлові шляхи, крос-базові тригери та застарілі способи автентифікації.
Ми проганяємо реальний набір запитів і транзакційний профіль на тестовому контурі до перенесення: розходження за планами виконання й блокуваннями видно заздалегідь, а не після перемикання трафіку.
Як проходить перемикання і чи можливий відкат?
Перемикання кероване: зупиняємо запис, добиваємо чергу реплікації, звіряємо контрольні суми, змінюємо рядок підключення й повертаємо трафік.
Зворотний відкат залишається доступним, поки вихідне середовище не виведене з експлуатації, — точку неповернення фіксуємо в регламенті заздалегідь.
Що з доступом, оновленнями та перевіркою відмовостійкості?
Доступи роздаємо за ролями через єдиний каталог, службові облікові записи — лише під конкретні завдання, секрети зберігаються в захищеному сховищі, а не в конфігураційних файлах. Обслуговування йде за узгодженим вікном; регламент оновлень описує порядок і момент повідомлення.
Перевірку відмовостійкості проводимо до передачі: імітуємо відмову вузла й регіону, заміряємо час відновлення та повноту даних, результат оформлюємо протоколом. Якщо сценарій не вкладається в цільові показники — змінюємо конфігурацію до приймання, а не після.
Обговоримо задачу: що ввійде в план першого етапу
Щоб оцінка строків спиралася на факти, перший етап починаємо з розбору поточного стану: який tier і модель придбання використовуються, як розподілене навантаження за читанням і записом, де вузькі місця за вводом-виводом і блокуваннями, як зараз розгортається інфраструктура.
Далі рахуємо варіанти цільової конфігурації і лише після цього називаємо строки — інакше цифра береться зі стелі й розвалюється на першій же зміні навантаження.
З оцінкою та планом робіт ми повертаємося з конкретним набором артефактів:
- схема цільової конфігурації: tier під профіль навантаження, модель придбання, параметри масштабування й стелі, за які база почне впиратися;
- Terraform-модулі для розгортання бази, правил доступу та пов'язаних ресурсів — з версіонуванням і зрозумілим способом перенести конфігурацію між середовищами;
- політика резервного копіювання й відновлення: строки зберігання копій, відновлення на момент часу, перевірка того, що копія реально розгортається;
- схема відмовостійкості: реплікація, порядок перемикання при відмові регіону, очікуваний час недоступності й точка втрати даних;
- моніторинг і оповіщення: метрики споживання, очікування, взаємні блокування, зростання журналів транзакцій — з порогами, за яких надходить сигнал, а не постфактум розбір;
- план робіт за етапами з оцінкою строків, ролями й точками приймання на кожному кроці;
- порядок експлуатації для вашої команди: типові операції, відкат, що робити при деградації.
Опишіть задачу — поточну конфігурацію, обмеження та що болить найсильніше. Повернемося з оцінкою строків і планом робіт за першим етапом.
