GCP Cloud Load Balancer з Terraform і Cloud Armor: налаштування під ключ

GCP Cloud Load Balancer: де ламається налаштування

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

Балансувальник Google Cloud вважає бекенди здоровими, а користувач отримує 502 — і так рівно доти, доки хтось не виправить руками прямо в консолі.

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

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

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

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

Що дає кероване балансування навантаження

Єдина точка входу в сервіс замінює десяток розрізнених точок: одна зовнішня адреса, одна термінація TLS, далі — правила маршрутизації за хостом і шляхом.

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

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

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

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

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

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

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

Режими балансування: порівняння підходів

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

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

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

Порядок упровадження: аудит, налаштування, перевірка

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

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

1. Аудит поточної інфраструктури. Знімаємо фактичну схему: точки входу трафіку, цільові сервіси, правила маршрутизації, перевірки стану, налаштування захисту й те, що налаштовано руками й ніде не зафіксовано.
2. Опис інфраструктури як конфігурації. Балансувальник, цільові сервіси, перевірки стану й правила Cloud Armor переносимо в модулі Terraform з розділенням за середовищами. Стан зберігається віддалено з блокуванням, зміни проходять погодження.
3. Налаштування маршрутизації та захисту. Правила за шляхами й хостами, час очікування відповіді, привʼязка до регіонів, обмеження частоти запитів і фільтрація за ознаками запиту.
4. Перемикання трафіку. Спочатку на нову схему йде мала частка запитів, метрики звіряються з попереднім контуром, потім частка зростає. Відкат — повернення розподілу за одну правку.
5. Перевірка під навантаженням. Профіль повторює пікові сценарії: сплеск запитів, відмова однієї зони, довгі зʼєднання. Дивимося, де спрацьовують перевірки стану і як поводяться ліміти.
6. Спостережуваність. Метрики затримок, частки помилок і стану цільових сервісів зводимо в дашборд, оповіщення привʼязуємо до симптомів відмови, а не до окремих вузлів.
7. Передача конфігурації. Віддаємо репозиторій, схему середовищ, порядок типових змін і регламент відкату, розбираємо все з вашою командою на живій правці.

Що передаємо: модулі Terraform, політики, регламенти

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

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

Кейс: як скоротили відмови балансувальника

Проєкт — сервіс із нерівномірним трафіком: піки за розписом, кілька серверних пулів за балансувальником.

Конфігурацію правили руками у вебконсолі Google Cloud: перевірки здоровʼя, правила маршрутизації та привʼязки груп інстансів жили в розрізнених налаштуваннях, без історії змін.

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

Що змінили

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

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

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

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

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

У Google Cloud це два різні продукти, а не два режими одного. Глобальний балансувальник застосунків тримає одну адресу, яка анонсується з усіх периферійних точок: запит входить у найближчу, HTTPS-сесія завершується там же, далі трафік іде в здоровий регіон зі списку бекендів. Регіональний привʼязаний до одного регіону — адреса й точка відмови в нього збігаються.

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

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

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

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

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

Робоче правило: публічний HTTP(S)-сервіс з користувачами в різних країнах — глобальний; вимога тримати трафік в одному регіоні або нестандартний протокол — регіональний.

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

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

Захист не почне блокувати реальних користувачів?

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

Що залишиться в команди після запуску?

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

Наскільки складно підтримувати це своїми силами?

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

Обговоримо вашу схему балансування та захист

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

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

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