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, порядок этапов с точками проверки и планом отката. Обсудим задачу — опишите её письмом или на созвоне, и мы скажем, что стоит уточнить до старта.