Google PCD: Вычислительные ресурсы, контейнеры и платформы бессерверных сред выполнения — Руководство по подготовке

By Laurynas Brazys · 4 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Обзор

Google Cloud предлагает несколько платформ выполнения, охватывающих бессерверные вычисления, контейнеры и виртуальные машины. Выбор подходящей платформы зависит от характеристик рабочей нагрузки, таких как шаблоны запросов, управление состоянием, дисциплина сборки и выпуска, операционная модель и сетевые ограничения. В этом разделе рассматриваются принципы проектирования, режимы отказа и компромиссы для Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) и Compute Engine, а также вспомогательные сервисы для образов, идентификации, сети, конфигурации и эксплуатации.

Бессерверные среды выполнения: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Модель: Полностью управляемые контейнеры с обработкой HTTP-запросов или контейнеризированные задания (Jobs), которые выполняются до завершения.
• Ревизии и трафик: Каждое развёртывание создаёт неизменяемую ревизию. Разделение трафика в процентном соотношении между ревизиями позволяет реализовать канареечные и сине-зелёные развёртывания с возможностью мгновенного отката. Пример:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Параллелизм и масштабирование: Параллелизм по умолчанию — 80; установите значение 1 для кода, ограниченного производительностью ЦП, или непотокобезопасного кода. Более высокий параллелизм снижает усиление эффекта холодного старта и затраты, но может увеличить хвостовую задержку, если ресурсов ЦП/памяти на запрос недостаточно. Cloud Run масштабируется до нуля и вверх в зависимости от интенсивности входящих запросов; управляйте этим с помощью min/max instances, чтобы сократить холодные старты и ограничить затраты.
• Выделение ЦП: Выберите «ЦП выделен постоянно» (CPU always allocated) для фоновой работы между запросами за дополнительную плату; в противном случае ЦП выделяется только во время обработки запросов.
• Задания (Jobs): Cloud Run Jobs выполняют N параллельных задач до их завершения с максимальным количеством повторных попыток для каждой задачи и общими таймаутами; подходят для ETL, пакетной обработки и веерной обработки (fan-out). Режимы отказа включают создание «горячих точек» на бэкендах, когда множество задач обращаются к одной и той же зависимости; добавьте ограничение частоты запросов и повторные попытки с экспоненциальной задержкой.
• Сеть: Публичный доступ, с аутентификацией через IAM, или приватный в VPC через Serverless VPC Access и Private Service Connect.

App Engine

• Среды:
  • Standard: Изолированная песочница, быстрое масштабирование, фиксированные среды выполнения для каждого языка; низкая задержка холодного старта с автоматическим масштабированием; ограниченный доступ к файловой системе, таймауты запросов и лимиты на размер входящих запросов. Для загрузки больших файлов используйте подписанные URL-адреса Cloud Storage.
  • Flexible: На основе Docker, возможности, схожие с ВМ, кастомные среды выполнения, более медленное масштабирование по сравнению со Standard, поддержка фоновых потоков и записи на локальный диск.
• Сервисы и версии: Сервис (микросервис) может содержать несколько версий; маршрутизируйте трафик в процентном соотношении между версиями, аналогично Cloud Run. Используйте dispatch.yaml для маршрутизации определённых путей или хостов на сервисы для простой, централизованной маршрутизации без внешнего балансировщика нагрузки.
• Масштабирование: Ручное, базовое или автоматическое в среде Standard; масштабирование на основе количества ВМ в среде Flexible. Компромисс: агрессивное автомасштабирование улучшает отзывчивость, но может увеличить затраты и конкуренцию за ресурсы бэкенда.
• Частые ошибки: Неограниченное масштабирование экземпляров без квот может перегрузить нижестоящие системы; применяйте квоты и автоматические выключатели (circuit breakers).

Cloud Functions

• Обработчики, управляемые событиями: Запускаются по событиям HTTP, Pub/Sub, Cloud Storage или Eventarc. Используйте функции 2-го поколения, чтобы задействовать модель выполнения Cloud Run, контроль исходящего трафика VPC и параллелизм; функции 1-го поколения обрабатывают один запрос за раз.
• Повторные попытки и идемпотентность: Фоновые функции могут быть повторно запущены в случае сбоя; разрабатывайте идемпотентные обработчики и используйте ключи дедупликации, чтобы избежать двойной обработки. HTTP-триггеры не повторяются платформой; реализуйте повторные попытки на стороне клиента с экспоненциальной задержкой.
• Конфигурация среды выполнения: Переменные окружения, интеграция с Secret Manager и настройка параллелизма/максимального количества экземпляров для каждой функции. Устанавливайте таймауты, чтобы сдерживать неконтролируемый рост затрат. Остерегайтесь длительных холодных стартов при больших зависимостях; старайтесь минимизировать размер пакетов.

Контейнеры в Google Kubernetes Engine

Рабочие нагрузки

• Deployments: Поды без состояния (stateless) с поэтапными обновлениями. Обеспечьте безопасное развёртывание с помощью ограничений на превышение (surge) и недоступность (unavailable):

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSets: Упорядоченные, стабильные сетевые идентификаторы и постоянные тома для сервисов с состоянием (stateful).
• DaemonSets, Jobs, CronJobs: Агенты на уровне узлов и пакетные рабочие нагрузки.

Сервисы (Services) и Ingress

• Типы сервисов (Service):
  • ClusterIP для внутреннего использования.
  • NodePort для простого внешнего доступа (ограничен в эксплуатации).
  • LoadBalancer для региональной внешней/внутренней балансировки нагрузки.
• Ingress: Маршрутизация HTTP(S) и терминирование TLS; для политик L7 предпочтительнее использовать Gateway API или Ingress с управляемыми контроллерами. Режим отказа: проверки состояния не проходят из-за файрвола; разрешите доступ с диапазонов IP-адресов балансировщика к узлам бэкенда.

Автомасштабирование и пулы узлов

• Horizontal Pod Autoscaler (HPA): Масштабирует поды на основе метрик ЦП, памяти или пользовательских метрик; комбинируйте с Pod Disruption Budgets для защиты доступности.
• Vertical Pod Autoscaler (VPA): Подбирает оптимальные размеры запросов/лимитов для подов; избегайте одновременного использования HPA и VPA для одного и того же измерения, чтобы предотвратить циклы обратной связи.
• Cluster Autoscaler: Добавляет/удаляет узлы для удовлетворения ожидающих запросов подов на ресурсы.
• Пулы узлов: Разделяйте пулы по классам рабочих нагрузок. Используйте taints/tolerations и labels для планирования. Смешивайте точечные/прерываемые (spot/preemptible) экземпляры для чувствительных к стоимости рабочих нагрузок с устойчивостью к прерываниям. Выбирайте типы машин с достаточной пропускной способностью памяти/ЦП для лимитов подов, чтобы избежать троттлинга (регулирования).

Проверки состояния и развёртывания

• Проверки liveness, readiness и startup предотвращают отправку трафика на неготовые поды и перезапускают заблокированные контейнеры. Слишком строгие liveness-пробы могут вызывать каскадные перезапуски; настройте начальные задержки и пороги сбоев.
• Откат с помощью kubectl rollout undo. Для канареечного развёртывания используйте несколько Deployments и разделение трафика на уровне Service через Ingress/Gateway.

Compute Engine для рабочих нагрузок приложений

Проектирование ВМ

• Шаблоны инстансов (instance templates) определяют тип машины, образ, диски, области доступа сервисного аккаунта, скрипты запуска и метаданные. Используйте минимальные образы; для детерминированной загрузки применяйте скрипты запуска или образы, созданные с помощью Packer.
• Диски: для приложений, чувствительных к задержкам, используйте сбалансированные (balanced) или SSD постоянные диски. Для обмена большими наборами данных, предназначенных только для чтения, в управляемой группе инстансов используйте постоянный диск в режиме read-only, подключенный к нескольким инстансам. Это обеспечит низкую задержку и быстрый запуск.
• Сеть: при использовании балансировщиков нагрузки создайте правила брандмауэра для проверок состояния (health checkers). Пример:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Управляемые группы инстансов (MIGs)

• Автомасштабирование по CPU, количеству запросов в секунду на балансировщик нагрузки, пользовательским метрикам или по расписанию. Устанавливайте периоды охлаждения (cool-downs), чтобы предотвратить частое срабатывание.
• Автоматическое восстановление (autohealing) с помощью проверок состояния перезапускает неработоспособные ВМ; убедитесь, что проверка состояния тестирует готовность приложения, а не просто доступность порта, чтобы избежать выдачи ошибок 500.
• Поэтапные (rolling) и сине-зеленые (blue-green) обновления: создайте новый шаблон инстансов и запустите канареечное обновление для подмножества инстансов. Если количество ошибок растет, выполните откат к предыдущему шаблону. Проверки доступности (uptime checks) и оповещения на основе SLO помогают быстро обнаруживать сбои.

Сбор логов и мониторинг

• Установите агенты для сбора логов приложений без изменения кода; отправляйте их в Cloud Logging и настраивайте оповещения через Cloud Monitoring. Используйте Debug Logpoints для диагностики в реальном времени с минимальным влиянием на работу.

Сборка, идентификация, сеть, секреты и эксплуатация

Artifact Registry и образы

• Используйте Artifact Registry для образов контейнеров и артефактов языков программирования. Включите сканирование на уязвимости и генерацию сведений о происхождении (provenance). Сохраняйте образы небольшими:
  • Используйте многоэтапные сборки для разделения сред сборки и выполнения.
  • Избегайте инструментов разработки в финальном образе; фиксируйте версии ОС и пакетов. Пример:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Продвижение: присваивайте образам неизменяемые теги (например, app:1.3.7, app:prod-20240901) и продвигайте их путем переназначения тегов в Artifact Registry; избегайте использования изменяемого тега latest в производственной среде. Контролируйте продвижение по результатам интеграционных и канареечных тестов.

Идентификация во время выполнения и принцип наименьших привилегий

• Назначайте выделенный сервисный аккаунт для каждой рабочей нагрузки с минимально необходимыми ролями IAM. Избегайте широких ролей, таких как Editor. В GKE связывайте Kubernetes ServiceAccounts с сервисными аккаунтами Google через Workload Identity. Для бессерверных сред явно указывайте сервисный аккаунт времени выполнения и удаляйте области действия токена по умолчанию (default-token scopes).

Коннекторы VPC и сетевое взаимодействие сервисов

• Коннекторы Serverless VPC Access направляют исходящий трафик (egress) из Cloud Run, Cloud Functions и App Engine в VPC. Выберите режим исходящего трафика:
  • Только частные диапазоны (Private ranges only), чтобы обращаться к службам в диапазонах RFC1918 и подключенным к VPC, в то время как публичный трафик идет напрямую.
  • Весь трафик (All traffic) через коннектор и Cloud NAT для получения детерминированных IP-адресов исходящего трафика и применения ограничивающих политик для исходящих соединений.
• Частные зависимости: предпочитайте Private IP для Cloud SQL и Private Service Connect для API Google или партнерских сервисов. Убедитесь, что коннекторы соответствуют региону и их размер подобран под пропускную способность; отслеживайте загрузку ЦП коннектора, чтобы избежать троттлинга.

Конфигурация, секреты и проверки работоспособности

• Используйте переменные окружения для несекретной конфигурации. Храните секреты в Secret Manager и монтируйте или внедряйте их во время выполнения; регулярно ротируйте ключи. В GKE используйте объекты Secrets и драйвер CSI для Secret Manager. В App Engine и Cloud Run предоставьте сервисному аккаунту доступ к конкретным секретам.
• Проверки работоспособности:
  • Cloud Run: экземпляр перезапускается при сбое; используйте проверки на уровне запросов и SLI по задержке.
  • App Engine: встроенные проверки работоспособности; настройте liveness/readiness для гибкой среды (Flexible).
  • GKE: настройте пробы liveness/readiness/startup.
  • Compute Engine за балансировщиками нагрузки: используйте проверки работоспособности HTTP(S) с эндпоинтами, специфичными для приложения.

Устранение неполадок, откат и шаблоны развертывания

• Сине-зеленое (Blue-green) и канареечное (canary) развертывание с разделением трафика в Cloud Run и App Engine; в GKE используйте параллельные Deployments или контроллеры прогрессивной доставки; в MIG — используйте канареечные подмножества экземпляров. Всегда определяйте критерии прерывания на основе бюджета ошибок SLO и задержки.
• Распространенные режимы сбоев:
  • Эффект «гремящего стада» (Thundering herd) после масштабирования до нуля или крупных выкаток; смягчайте с помощью минимального количества экземпляров (min instances), прогрева и ограничения частоты запросов (rate limiting).
  • Превышение квот бэкенда или лимитов соединений; применяйте экспоненциальную выдержку (exponential backoff) и автоматические выключатели (circuit breakers).
  • Холодные старты из-за больших образов или зависимостей; уменьшайте образы и предварительно инициализируйте клиенты.

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

Компания Acme Retail планирует перенести API для изменения размера изображений с самоуправляемых ВМ на масштабируемую, экономичную платформу с низкой задержкой ответов, частным доступом к региональному бакету Cloud Storage и безопасными канареечными релизами.

Подход

1. Упаковать сервис в небольшой образ контейнера и опубликовать в Artifact Registry.

• Обоснование: Компактная многоэтапная сборка Docker минимизирует холодные старты и передачу данных по сети. Artifact Registry централизует сканирование и рабочие процессы продвижения версий.

2. Развернуть API в Cloud Run с min instances равным 2, concurrency равным 40 и отключенной опцией CPU always allocated.

• Обоснование: Cloud Run обеспечивает мгновенное горизонтальное масштабирование и управляемый HTTPS. Небольшой пул минимального количества экземпляров (min instance) снижает задержку холодного старта во время суточных пиков нагрузки. Параллелизм (concurrency) 40 обеспечивает баланс между стоимостью и хвостовой задержкой (tail latency) для операций преобразования изображений, ограниченных вводом-выводом. Отключение постоянно выделенного ЦП (always-on CPU) позволяет не платить за простаивающие вычислительные ресурсы между запросами.

3. Создать коннектор Serverless VPC Access и установить для исходящего трафика (egress) режим private ranges only; включить Private Google Access в подсети и, при необходимости, настроить эндпоинт VPC-SC или Private Service Connect для Cloud Storage.

• Обоснование: API должен получать и записывать изображения в частном порядке, без использования публичного исходящего трафика. Режим private ranges гарантирует, что через коннектор проходит только трафик VPC, а публичные вызовы остаются прямыми и эффективными. Private Google Access или Private Service Connect обеспечивает частный доступ к API Google из VPC.

4. Предоставить выделенному сервисному аккаунту времени выполнения доступ к целевому бакету Cloud Storage и необходимым секретам по принципу наименьших привилегий.

• Обоснование: Принцип наименьших привилегий ограничивает радиус поражения (blast radius). Идентификатор времени выполнения получает роли storage.objectViewer и storage.objectAdmin для конкретного бакета и роль accessor для нужных секретов в Secret Manager.

5. Хранить ключи API и конфигурацию для каждой среды в Secret Manager и переменных окружения; внедрять секреты во время выполнения.

• Обоснование: Централизованная ротация секретов и аудируемый доступ. Несекретная конфигурация через переменные окружения соответствует практикам 12-факторного приложения.

6. Реализовать экспоненциальную выдержку и идемпотентные операции записи для обработки ошибок 429/5xx от Cloud Storage.

• Обоснование: Во время всплесков нагрузки или региональных сбоев могут возникать временные ошибки. Экспоненциальная выдержка с джиттером (jitter) защищает и API, и Cloud Storage от шторма повторных запросов.

7. Настроить канареечную ревизию и направить на нее 10% трафика; отслеживать частоту ошибок, P95 задержки и сатурацию.

• Обоснование: Разделение трафика в Cloud Run обеспечивает безопасную постепенную выкатку. Мониторинг на основе SLO обеспечивает автоматические триггеры отката, если бюджеты ошибок расходуются слишком быстро.

8. Добавить HTTP-эндпоинт для проверки работоспособности, который проверяет нижестоящие зависимости; настроить оповещения на основе проверок доступности (uptime checks) в Cloud Monitoring и метрик на основе логов.

• Обоснование: Сквозная проверка работоспособности (End-to-end) позволяет на раннем этапе выявлять сбои зависимостей. Проверки доступности (Uptime checks) дают внешний взгляд; метрики на основе логов фиксируют специфичные для приложения шаблоны сбоев.

9. Установить лимиты автомасштабирования и бюджеты; задать максимальное количество экземпляров (max instances) для ограничения расходов и определить обработку ошибок 429 при перегрузке.

• Обоснование: Ограничение масштабирования предотвращает неконтролируемый рост затрат и исчерпание ресурсов бэкенда. Корректная обработка перегрузки поддерживает стабильность сервиса.

10. Задокументировать процедуру отката: переключить 100% трафика обратно на предыдущую ревизию Cloud Run одной командой.

• Обоснование: Неизменяемые ревизии делают откат безопасным и быстрым, минимизируя среднее время восстановления (MTTR).

← Архитектура Cloud-Native приложений и выбор сервисов · Все домены · Проектирование API →

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

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