Google PCNE: Балансировка нагрузки, Cloud CDN и глобальное управление трафиком — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Часть Google Professional Cloud Network Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

В этом разделе объясняется, как Google Cloud Load Balancing, Cloud CDN и глобальное управление трафиком совместно обеспечивают отказоустойчивые, производительные и безопасные сервисы. Рассматриваются семейства балансировщиков нагрузки и их выбор, поведение в режимах прокси и сквозной пересылки (passthrough), компоненты бэкенда и маршрутизации, отказоустойчивость и управление мощностью, кеширование в Cloud CDN и защита источников (origin), архитектуры с использованием anycast и между регионами, управление через DNS и проверки работоспособности, наблюдаемость (observability) и шаблоны проектирования для создания надежных глобальных точек входа.

Семейства балансировщиков нагрузки, их выбор и поведение на уровне данных (data-plane)

Google Cloud предлагает внешние и внутренние балансировщики нагрузки с различными областями действия, протоколами и характеристиками на уровне данных. Правильный выбор позволяет согласовать требования к протоколам, географическое расположение и средства операционного контроля.

• Внешний прокси L7 (глобальный): External Application Load Balancer для HTTP(S) и gRPC. Терминирует TLS, применяет политики L7, поддерживает карты URL, Cloud CDN, Cloud Armor, функции для запросов/ответов и anycast IPv4/IPv6. Оптимален для веб-API и сайтов, доступных из интернета, которым требуются расширенная маршрутизация, безопасность и кеширование.

• Внешний прокси L4.5: External TCP Proxy Load Balancer (глобальный) и External UDP Proxy Load Balancer (региональный) терминируют клиентские соединения и проксируют их на бэкенды. Используйте, когда вам нужен глобальный VIP и функции L4 (политика TLS, сохранение IP-адреса клиента через заголовки для TCP) без маршрутизации L7.

• Внешний сквозной (passthrough) L3/L4 (региональный): External Network Load Balancer пересылает пакеты, не терминируя соединение. Обеспечивает минимальную задержку и максимальную простоту; поддерживает TCP/UDP/ESP/ICMP. Подходит для миграции lift-and-shift, гетерогенных бэкендов или протоколов, несовместимых с терминированием на прокси. Классический NLB использует целевые пулы (target pools); более новый региональный passthrough NLB использует сервисы бэкенда (backend services).

• Внутренний прокси (региональный): Internal HTTP(S) Load Balancer (L7) и Internal TCP Proxy Load Balancer (L4.5) терминируют и проксируют трафик внутри VPC для взаимодействий микросервисов по модели «север-юг» (north-south) и «сервис-сервис» (service-to-service). Поддерживают маршрутизацию по хосту/пути (HTTP), mTLS с клиентами через приложение и политики безопасности для каждого сервиса.

• Внутренний сквозной (passthrough) (региональный): Internal TCP/UDP Load Balancer распределяет соединения на бэкенды по частным адресам RFC1918, сохраняя IP-адрес клиента и используя хеширование MAGLEV. Идеален для трафика «восток-запад» (east-west) между сервисами (базы данных, пользовательские протоколы), требующими распределения с учетом зон и низких накладных расходов.

Компромиссы между уровнями и терминированием:

• Прокси L7/4.5 предоставляет расширенную маршрутизацию, разгрузку TLS (TLS offload), наблюдаемость, Cloud Armor/CDN и межрегиональную отказоустойчивость ценой дополнительных переходов (hops) и возможных изменений в заголовках/NAT. Подходит для публичных точек входа и service mesh.
• Сквозной (Passthrough) L3/L4 сохраняет IP-адрес клиента на всем пути (end-to-end) и минимизирует задержку, но не имеет функций L7 и предоставляет меньше инструментов для наблюдаемости. Поведение сессий основано на хешировании; проверки работоспособности проще.

Область действия и семейства IP-адресов:

• Глобальные anycast VIP доступны для External Application LB и External TCP Proxy LB, предоставляя единые адреса IPv4/IPv6, доступные отовсюду. Региональные балансировщики нагрузки используют региональные unicast VIP. Предоставление публичным сервисам доступа по IPv6 достигается путем настройки внешнего глобального балансировщика нагрузки с адресом IPv6.

Основные критерии выбора:

• Нужна маршрутизация по хосту/пути, перенаправления, Cloud CDN, Cloud Armor или gRPC: External Application LB.
• Нужен глобальный TCP без L7: External TCP Proxy LB.
• Протоколы, несовместимые с прокси (например, некоторые устаревшие UDP/TFTP): внешний или внутренний сквозной (passthrough) балансировщик.
• Внутреннее взаимодействие «сервис-сервис» с HTTP-маршрутизацией: Internal HTTP(S) LB.
• Минимизация стоимости/количества переходов для трафика внутри VPC: внутренний сквозной (passthrough) балансировщик.

Сервисы бэкенда, объекты маршрутизации, проверка работоспособности и привязка трафика

Основные объекты уровня данных:

• Сервисы бэкенда (Backend services): Определяют бэкенды (группы инстансов, зональные NEG, гибридные NEG, бессерверные NEG), проверки работоспособности, режим балансировки, ёмкость, привязку сессий, тайм-аут и политику отработки отказа. Требуются для прокси-балансировщиков нагрузки и более новых сквозных балансировщиков.
• Целевые пулы (Target pools): Устаревшая конструкция для классического внешнего NLB. Подходит для простого распределения TCP/UDP и для разнородных ВМ при миграции lift-and-shift.
• Именованные порты (Named ports): Ключи в группах инстансов, сопоставляющие логические имена (например, http) с номерами портов, на которые ссылаются сервисы бэкенда и карты URL. Обеспечьте согласованность между всеми членами группы.

Проверки работоспособности и отработка отказа:

• Типы: HTTP(S), HTTP/2, gRPC, TCP, SSL. Выбирайте проверку, которая подтверждает фактическую готовность сервиса, а не просто доступность ОС.
• Область действия: Проверки работоспособности являются региональными; у каждого бэкенда должна быть проверка работоспособности, ограниченная регионом его обслуживания.
• Политика отработки отказа: Сервис бэкенда может определить основные и резервные бэкенды. Трафик переключается на резервный бэкенд, когда основной неработоспособен или исчерпал свою ёмкость (если включена опция failover-on-capacity и достигнут пороговый уровень). Рассмотрите возможность осушения соединений и резервирования ёмкости, чтобы избежать эффекта «набегающей толпы» (thundering herd).

Карты URL и маршрутизация:

• Карта URL (URL map) прикрепляется к внешнему или внутреннему HTTP(S) LB и определяет правила для хостов и сопоставления путей.
• Сервис по умолчанию: Бэкенд для всех запросов, не подошедших ни под одно правило; если не задан, возвращается ошибка 404.
• Перенаправления и перезаписи: Используйте действия карты URL для выполнения перенаправлений на HTTPS, канонических перенаправлений хостов или перезаписи путей перед маршрутизацией.

Пример: минимальная карта URL с перенаправлением на HTTPS и бэкендом по умолчанию

• Создайте правило для хоста example.com, перенаправляйте HTTP на HTTPS, маршрутизируйте /static на бакет бэкенда с включенным CDN и по умолчанию направляйте трафик на региональный сервис бэкенда.

Привязка сессий и осушение соединений:

• Параметры привязки зависят от типа балансировщика. Распространенные варианты:
  • Нет: Лучше всего для stateless-сервисов; максимизирует распределение нагрузки.
  • IP клиента: Привязка по IP-адресу источника на уровнях L4/L7; используется, когда несколько протоколов (например, HTTP и TFTP) должны быть привязаны к одному и тому же бэкенду.
  • Сгенерированный cookie (только L7): Балансировщик устанавливает cookie для привязки к бэкенду; обеспечивает лучшее распределение, чем IP клиента, для клиентов за NAT.
• Компромиссы: Привязка сессий может вызывать «горячие точки» (hotspotting) и усложнять автомасштабирование. По возможности отдавайте предпочтение stateless-архитектуре.
• Осушение соединений: При уменьшении масштаба или удалении бэкенда балансировщик соблюдает тайм-аут осушения, позволяя существующим соединениям корректно завершиться. Настройте время осушения в соответствии с самым длинным ожидаемым запросом, чтобы предотвратить сбросы соединений.

Ёмкость и автомасштабирование:

• Режимы балансировки: На основе утилизации (например, CPU), RPS или количества соединений. Каждый бэкенд сообщает о своей ёмкости; балансировщик сбрасывает нагрузку или выполняет отработку отказа при насыщении.
• Автомасштабирование: Управляемые группы инстансов масштабируются на основе сигналов (CPU, пользовательские метрики). Задержка при горизонтальном масштабировании может вызвать ошибки 503, если у балансировщика закончится ёмкость; выполняйте «прогрев» с помощью минимального количества реплик или предиктивного автомасштабирования для суточных колебаний трафика.
• Отработка отказа и переполнение: Включение failover-on-capacity с подходящим порогом обеспечивает плавное перенаправление избыточного трафика между регионами.

Безопасность на бэкендах:

• Ограничьте доступ к бэкендам с помощью правил брандмауэра, нацеленных на теги инстансов или сервисные аккаунты. Разрешайте трафик только от балансировщика нагрузки Google, диапазонов IP-адресов для проверки работоспособности и утвержденных диапазонов клиентов, если внутренним клиентам требуется прямой доступ.

Пример: ограничение доступа для клиентов и проверок работоспособности к группе с тегами бэкенда

• Присвойте инстансам тег application.
• Создайте разрешающее правило для входящего трафика (ingress) по tcp:80 от ваших CIDR-диапазонов клиентов и диапазонов IP-адресов для проверок работоспособности Google, нацеленное на тег application.
• Рекомендуется использовать политику «запрещено по умолчанию», чтобы отброшенный трафик отображался в логах.

Cloud CDN, политика кеширования и защита origin-сервера

Cloud CDN интегрируется с внешним Application Load Balancer для кеширования ответов на пограничных точках присутствия (edge POPs), что снижает задержку и нагрузку на origin-серверы.

Режимы кеширования и TTL:

• Использовать заголовки origin-сервера: Учитывает заголовки Cache-Control и Expires от вашего origin-сервера. Предпочтительный способ для обеспечения корректности.
• Принудительное кеширование: Кеширует все ответы с настроенным TTL по умолчанию, с возможностью переопределения или игнорирования заголовков origin-сервера для статического контента. Используйте с осторожностью, чтобы избежать кеширования динамических данных.
• Обход кеша: Полезно для путей, которые никогда не должны кешироваться.

Ключи кеша:

• Поля ключа включают протокол, хост, путь, параметры запроса, заголовки и cookie. Настройте политику для строки запроса (включать все, включать выбранные или игнорировать), выборочное включение заголовков и cookie, а также сегментацию по устройствам по мере необходимости.
• Делайте ключи минимальными, чтобы максимизировать долю кеш-попаданий (hit ratio); различайте их только по полям, которые изменяют представление контента.

Подписанные запросы:

• Подписанные URL: Прикрепите подпись HMAC или RSA с указанием срока действия и области действия (пути), чтобы предоставить ограниченный по времени доступ к определенным ресурсам. Хорошо подходит для использования CDN в качестве ускорителя с авторизацией для каждого объекта.
• Подписанные cookie: Авторизуйте набор путей с помощью cookie; полезно для контента с ограниченным доступом на всем сайте.
• Выполняйте ротацию ключей и устанавливайте короткие сроки действия, чтобы снизить риск атак повторного воспроизведения (replay attacks).

Сжатие и корректность:

• Origin-серверы должны сжимать данные, даже если запросы содержат заголовок Via. Если CDN отдает несжатые объекты, в то время как origin-сервер «поддерживает сжатие», убедитесь, что origin-сервер настроен на сжатие при наличии заголовка Via.

Безопасность origin-сервера:

• Используйте HTTPS для связи между edge-прокси и origin-серверами с современными политиками TLS.
• Ограничьте доступность origin-сервера: правила брандмауэра для бэкенда, которые разрешают трафик только из диапазонов IP-адресов балансировщика нагрузки и систем проверки работоспособности Google, а также от известных частных источников. Экземпляры бэкенда не должны принимать произвольный входящий трафик из интернета.
• Используйте в паре с Cloud Armor для защиты от L7 DDoS/WAF, ограничения частоты запросов и обнаружения угроз. Используйте режим предварительного просмотра (preview mode) для новых правил, чтобы уменьшить количество ложных срабатываний.
• Целенаправленно инвалидируйте контент с помощью API инвалидации кеша, когда необходимо очистить его до истечения TTL. Для динамического контента предпочитайте короткие TTL и повторную валидацию (revalidation) с помощью ETag/If-None-Match.

Режимы отказа и компромиссы:

• Слишком общие ключи кеша приводят к неэффективному использованию кеша и снижают долю кеш-попаданий; слишком специфичные ключи создают риск отдачи некорректных вариантов контента.
• Принудительное кеширование динамических данных может привести к утечке персонализированного контента.
• Подписанные URL/cookie защищают доступ на пограничных узлах (edge), но обход CDN и прямой доступ к origin-серверу все равно должен быть запрещен на уровне сетевой политики.

Глобальное управление трафиком, DNS-маршрутизация, наблюдаемость и отказоустойчивые точки входа

Внешние интерфейсы Anycast и межрегиональное аварийное переключение:

• Внешний Application LB и внешний TCP Proxy LB используют глобальные Anycast VIP для привлечения клиентов к ближайшей пограничной точке Google. Затем трафик проксируется на самый работоспособный и ближайший бэкенд с доступной емкостью. Настройте несколько регионов бэкенда с согласованными проверками работоспособности и настройками емкости для бесшовного аварийного переключения и переполнения.
• Заранее подготовьте емкость во вторичных регионах, чтобы избежать штрафов за холодный запуск; согласуйте min/max автомасштабирования с порогами емкости балансировщика нагрузки.

Региональное управление внутренним трафиком:

• Внутренний HTTP(S) LB и внутренний сквозной LB являются региональными; проектируйте с учетом разнообразия зон в пределах региона и, при необходимости, для нескольких регионов, используя отдельные балансировщики нагрузки с Private Service Connect или клиенты, осведомленные о сервисах, для выбора региональных конечных точек.
• Поддерживайте низкую задержку восток-запад, размещая взаимодействующие сервисы в одном регионе и VPC. Используйте адресацию RFC1918 с одной VPC или соединенными VPC для минимальных затрат и простоты эксплуатации.

Политики маршрутизации и проверки работоспособности Cloud DNS:

• Политики: взвешенный циклический перебор (разделение трафика), геолокация (отправка пользователей на ближайший региональный VIP) и аварийное переключение (основной/резервный). Комбинируйте политики для соответствия бизнес-правилам.
• Проверки работоспособности: привяжите проверки работоспособности DNS (HTTP/HTTPS/TCP) к записям A/AAAA, используемым в маршрутизации, чтобы неработоспособные конечные точки исключались. Учитывайте кэширование резолвера (TTL), которое задерживает реакцию; устанавливайте низкие значения TTL для записей, участвующих в маршрутизации, чтобы повысить скорость реакции на сбой за счет большего количества DNS-запросов.
• Управление трафиком: используйте взвешенные политики для поэтапной миграции или перераспределения нагрузки между регионами. Избегайте направления трафика из интернета на частные адреса, если не используется DNS с разделением горизонтов.

Наблюдаемость и диагностика:

• Ведение журналов балансировщика нагрузки: включите ведение журналов для всех балансировщиков. Журналы HTTP(S) включают метод/URI запроса, задержку, попадание/промах в кэш, сервис бэкенда, правило карты URL, детали TLS и коды ответа. Журналы TCP/UDP предоставляют метаданные соединения и статус проб работоспособности.
• Метрики: отслеживайте работоспособность бэкенда, утилизацию, RPS, количество соединений, задержку, коэффициент попадания в кэш, частоту ошибок 4xx/5xx и насыщение емкости. Настройте оповещения на внезапные изменения и устойчивое превышение порогов.
• Распространенные шаблоны ошибок HTTP(S):
  • 404: нет совпадения в карте URL; проверьте правила хоста/пути и сервис по умолчанию.
  • 301/302: преднамеренные перенаправления; проверьте на наличие циклов перенаправления.
  • 502: сбой соединения с бэкендом или несоответствие протоколов (например, HTTP/1.1 и gRPC); проверьте работоспособность и конфигурацию протокола бэкенда.
  • 503: нет работоспособных бэкендов или нет свободной емкости; проверьте проверки работоспособности, квоты и поведение автомасштабирования.
• Трассировка запросов: используйте X-Forwarded-For, X-Forwarded-Proto и идентификаторы трассировки, передаваемые вашим приложением. Сопоставляйте журналы балансировщика с журналами бэкенда, используя идентификаторы запросов.
• Аналитика брандмауэра: включите ведение журналов брандмауэра VPC для разрешающих и запрещающих правил. Чтобы явно регистрировать отброшенные пакеты, добавьте правило deny-all с низким приоритетом и включенным ведением журналов.

Проектирование отказоустойчивой глобальной точки входа:

• Используйте один глобальный Anycast VIP на внешнем Application LB, который обслуживает несколько региональных бэкендов. Размещайте бессерверные/VM/контейнерные бэкенды как минимум в двух регионах. Включите межрегиональное аварийное переключение и переполнение, настройте консервативные проверки работоспособности и отрегулируйте плавное отключение и тайм-ауты для ваших рабочих нагрузок.
• Защитите точку входа с помощью Cloud Armor и политик ограничения квот. Используйте Cloud CDN для статического и кэшируемого динамического контента, чтобы поглощать всплески трафика на пограничных узлах.
• Предоставьте доступ по двойному стеку IPv4/IPv6 на глобальном балансировщике для обслуживания всех сетей. Для строгого контроля доступа клиентов примените правила брандмауэра на бэкенде с точными диапазонами источников и тегами экземпляров или сервисными аккаунтами.

Пример: правило брандмауэра, ограничивающее доступ для клиентов и проверок работоспособности к бэкендам с тегами

• Присвойте экземплярам тег application.
• Создайте разрешающее правило для входящего трафика tcp:443 с диапазонами источников 203.0.113.0/24, 198.51.100.0/24 и диапазонами проверок работоспособности Google, нацеленное на тег application.
• Убедитесь, что существует правило deny-all с более низким приоритетом и включенным ведением журналов для фиксации трафика из непредвиденных источников.

Практический сценарий

Компания Acme Retail запускает глобальную платформу электронной коммерции, которой требуется низкая задержка, надежная безопасность и прозрачное аварийное переключение между us-east1 и europe-west1, а также эффективная раздача статического медиаконтента. Только корпоративные офисы и промежуточная сеть CDN партнера должны иметь доступ к частному интерфейсу администратора.

1. Внешний интерфейс и бэкенды

• Создайте внешний Application Load Balancer с Anycast VIP двойного стека и TLS-сертификатами для публичного имени хоста витрины.
• Определите два сервиса бэкенда, каждый из которых указывает на региональную группу управляемых экземпляров в us-east1 и europe-west1. Включите проверки работоспособности (HTTPS) и установите режим балансировки на утилизацию с порогом емкости 80%. Обоснование: Anycast в сочетании с многорегиональными бэкендами гарантирует, что пользователи попадают на ближайший пограничный узел и бесшовно переключаются в случае сбоя или перегрузки региона.

2. Карта URL, маршрутизация и перенаправления

• Настройте карту URL с правилами хостов для публичной витрины и частных имен хостов администратора. Направьте /static в бакет бэкенда с включенным Cloud CDN; направьте /api и / на бэкенды ВМ. Добавьте перенаправление с HTTP на HTTPS. Обоснование: маршрутизация по хосту/пути разделяет статический и динамический трафик и обеспечивает безопасный доступ.

3. Политика Cloud CDN

• Для бакета бэкенда /static установите режим кэширования на использование заголовков источника и определите ключ кэша, который игнорирует нефункциональные параметры запроса и включает только заголовок Accept-Encoding. Включите негативное кэширование для распространенных ошибок 404 с коротким TTL. Обоснование: это позволяет соблюдать семантику контента, максимизировать коэффициент попадания в кэш и избегать кэширования неверных вариантов.

4. Привязка сеанса и плавное отключение

• Установите привязку по сгенерированному cookie для публичной витрины и не устанавливайте ее для статических ресурсов; установите время плавного отключения соединений на 60 секунд. Обоснование: файлы cookie обеспечивают стабильность сеансов корзины покупок, допуская при этом широкое распределение; плавное отключение предотвращает видимые пользователю ошибки во время горизонтального сжатия или аварийного переключения.

5. Межрегиональное аварийное переключение и автомасштабирование

• Включите аварийное переключение по емкости с порогом переполнения 90% для перенаправления избыточного трафика в другой регион. Настройте автомасштабирование MIG с минимальным количеством реплик 4 на регион и целевыми показателями ЦП, соответствующими утилизации балансировщика нагрузки. Обоснование: это позволяет избежать резких падений производительности и координирует решения балансировщика нагрузки и автомасштабирования для плавного масштабирования.

6. Ограничение доступа к интерфейсу администратора

• Создайте внутренний HTTP(S) Load Balancer для частного имени хоста администратора, доступный только внутри VPC. Опубликуйте Cloud DNS с разделением горизонтов, чтобы внутренние клиенты разрешали имя в VIP внутреннего балансировщика, а внешние клиенты получали NXDOMAIN. Обоснование: это позволяет сохранить трафик администратора частным и контролируемым, не открывая публичные конечные точки.

7. Брандмауэр бэкенда и безопасность источника

• Присвойте тег application административным и веб-бэкендам и добавьте разрешающее правило для tcp:443 из корпоративных и промежуточных CIDR, а также из диапазонов источников балансировщика нагрузки и проверок работоспособности Google; добавьте правило deny-all с ведением журналов и более низким приоритетом. Обоснование: это гарантирует, что только предполагаемые клиенты и инфраструктура Google могут достичь бэкендов, и обеспечивает видимость отброшенных пакетов.

8. Cloud Armor

• Примените политику безопасности с управляемыми правилами WAF и ограничением частоты запросов в режиме предварительного просмотра для всплесков трафика на /api. Обоснование: защита на уровне L7 и поэтапное применение правил снижают риски во время настройки.

9. Управление трафиком через Cloud DNS и проверки работоспособности

• Опубликуйте записи A и AAAA для публичного имени хоста витрины, указывающие на Anycast VIP ALB. Для сине-зеленого канареечного развертывания создайте взвешенную политику для выделенного канареечного имени хоста, разделяя 5% трафика на ALB только в europe-west1 и 95% на глобальное развертывание. Привяжите проверки работоспособности HTTPS для исключения канареечного развертывания в случае сбоя и установите TTL на 20 секунд. Обоснование: канареечное развертывание на основе DNS обеспечивает постепенное внедрение с удалением неработоспособных экземпляров и быстрой сходимостью.

10. Наблюдаемость

• Включите журналы балансировщика нагрузки и CDN; экспортируйте их в BigQuery для анализа. Настройте оповещения на частоту ошибок 5xx, емкость бэкенда, сбои проверок работоспособности и коэффициент попадания в кэш CDN. Используйте тесты карты URL и журналы запросов для диагностики ошибок маршрутизации; анализируйте всплески ошибок 502/503 на предмет насыщения бэкенда или несоответствия протоколов. Обоснование: проактивный мониторинг и быстрая диагностика минимизируют MTTR и сохраняют качество пользовательского опыта.

← Гибридное подключение · Все домены · Cloud DNS →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →