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

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Обзор

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

Compute Engine и архитектуры на базе VM

Compute Engine предоставляет детальный контроль над операционными системами, сетевыми настройками и формами машин. Выбирайте семейства машин в зависимости от характеристик рабочей нагрузки:

E2: экономичные, общего назначения; подходят для разработки/тестирования и приложений с пиковыми нагрузками.
N2/N2D: сбалансированное соотношение цены и производительности для большинства производственных нагрузок; N2D использует процессоры AMD с высокой пропускной способностью памяти.
C2/C2D/C3: оптимизированные для вычислений, для задач с высокой нагрузкой на CPU (например, API с высоким QPS, пакетные вычисления).
M3: оптимизированные для памяти, для больших наборов данных в памяти (кэши, аналитика в памяти).
A3: оптимизированные для GPU (NVIDIA) для обучения/инференса; GPU также можно подключать к другим семействам.
Confidential VMs (на поддерживаемых CPU) шифруют используемые данные с минимальными изменениями в коде.

Управляемые группы инстансов (MIG) обеспечивают эластичность и отказоустойчивость:

Используйте Instance Templates для неизменяемой конфигурации и MIG для горизонтального масштабирования между зонами.
Политики автомасштабирования: по CPU, утилизации балансировщика нагрузки, метрикам Cloud Monitoring или длине очереди через кастомные метрики. Установите минимальное/максимальное количество реплик и cooldown, чтобы избежать резких колебаний при пиковых нагрузках.
Постепенные (rolling) и канареечные (canary) обновления снижают риски; используйте консервативные настройки surge и unavailable для stateful-сервисов или сервисов с долгим холодным стартом.

Балансировка нагрузки и проверки состояния (health checks):

Глобальный внешний HTTP(S) балансировщик нагрузки терминирует TLS, поддерживает сопоставление URL и является стандартным фронтендом для веб-API; внутренний HTTP(S) LB используется для трафика east–west.
Проверки состояния должны иметь доступ к бэкендам. Распространенная ошибка — блокировка запросов проверки, что приводит к постоянным перезапускам инстансов и потере трафика. Разрешите доступ с диапазонов IP-адресов проверок состояния к портам бэкендов с помощью правил брандмауэра VPC и тегов таргетинга.

Пример разрешения HTTP-проверок состояния для MIG:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

Аспекты жизненного цикла VM:

Используйте startup-скрипты или метаданные образа для начальной настройки; храните конфигурацию времени выполнения в Secret Manager, а не встраивайте ее в образы.
Для Preemptible/Spot VM добавьте shutdown-script для корректного завершения работы при получении уведомления о прекращении.
Применяйте патчи через подготовленные образы и постепенную замену, чтобы избежать расхождения конфигурации (configuration drift).
Изменение размера Persistent Disk происходит онлайн: увеличьте размер диска, затем расширьте файловую систему (например, с помощью resize2fs для ext4) с минимальным простоем.

Пример изменения размера PD:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

Безопасная идентификация и наблюдаемость:

Привязывайте к инстансам сервисные аккаунты с минимальными привилегиями; не встраивайте статические учетные данные.
Установите Ops Agent для Cloud Logging и Cloud Monitoring. Используйте Cloud Trace и Cloud Profiler для уменьшения хвостовой задержки (tail latency) и выявления «горячих точек».
Экспортируйте данные аудита и метрик в BigQuery или Cloud Storage для долгосрочного хранения и анализа.

Пакетные и специализированные вычисления:

Используйте Cloud Batch или MIG с Preemptible VM для отказоустойчивых пакетных задач, чтобы снизить затраты; реализуйте сохранение контрольных точек (checkpointing).
Подключайте GPU/TPU там, где требуется ускорение ML. Используйте выделенные пулы узлов или узлы с единоличным владением (sole-tenant nodes) для соблюдения требований к соответствию/изоляции.
Confidential VMs защищают конфиденциальные данные в памяти; оцените накладные расходы в сравнении с требованиями.

Работа с состоянием (state):

Делайте инстансы приложений stateless; выносите сессии во внешнее общее хранилище (например, Memorystore, Cloud SQL), чтобы избежать видимых пользователю аномалий при масштабировании.
Для состояния, привязанного к VM, используйте региональные постоянные диски или реплицируемые базы данных; тестируйте сценарии аварийного переключения.

Kubernetes и контейнерные платформы (GKE)

GKE предоставляет управляемый control plane с гибкими пулами рабочих узлов:

Региональные кластеры реплицируют control plane и узлы между зонами для высокой доступности; зональные кластеры концентрируют ресурсы для снижения стоимости и чувствительности к задержкам.
Используйте несколько пулов узлов для сегментации рабочих нагрузок (например, общего назначения, с GPU, с большим объемом памяти, spot). Применяйте taints/tolerations и affinity/anti-affinity для управления размещением и уменьшения эффекта «шумного соседа».
Уровни автомасштабирования: cluster autoscaler добавляет/удаляет узлы; Horizontal Pod Autoscaler (HPA) масштабирует реплики по CPU/пользовательским метрикам; Vertical Pod Autoscaler (VPA) подбирает оптимальные requests. Комбинируйте HPA с cluster autoscaler для эластичности.

Планирование рабочих нагрузок и сервисы:

Правильно подбирайте requests/limits для CPU/памяти, чтобы минимизировать риск вытеснения (eviction) и максимизировать эффективность уплотнения (binpacking).
Используйте PodDisruptionBudgets для сохранения доступности во время обновлений.
Типы Service: ClusterIP (внутри кластера), NodePort/LoadBalancer (north–south) и Ingress для маршрутизации HTTP(S) с помощью глобального LB. Для канареечных развертываний направляйте трафик через отдельные бэкенды Service/Ingress или через service mesh.

Обновления и отказоустойчивость:

Используйте surge upgrades и maxUnavailable для контроля над изменениями; закрепляйте критически важные рабочие нагрузки за несколькими зонами и пулами.
Устанавливайте окна/исключения для обслуживания на время, критичное для бизнеса.
Проверяйте изменения в предпромышленной среде и на канареечных пулах узлов перед широким развертыванием.

Образы и безопасность:

Храните образы контейнеров в Artifact Registry; включите сканирование уязвимостей и настройте binary authorization или attestations для подтверждения происхождения.
Используйте Workload Identity для сопоставления GSA с KSA для беспарольного доступа к Google API с минимальными привилегиями.
Получайте конфигурацию во время выполнения из Secret Manager через CSI-драйвер; избегайте использования Kubernetes Secrets для особо конфиденциальных данных, если они не зашифрованы с помощью CMEK и не настроен строгий RBAC.

Развертывания и откат:

Предпочитайте последовательные обновления (rolling updates) для Deployment с небольшими шагами и проверками работоспособности (health probes); для систем с низкой отказоустойчивостью используйте blue-green развертывание с двумя Deployment за одним Service и переключением labels/selector.
Всегда определяйте readiness и liveness probes; неверно настроенные проверки вызывают каскадные перезапуски или «черные дыры» (blackholes) во время развертывания.

Бессерверные и событийно-ориентированные платформы

Бессерверные платформы Google Cloud абстрагируют инфраструктуру, предоставляя при этом мощные средства контроля над масштабированием, безопасностью и затратами:

Cloud Run: нативная поддержка контейнеров, запуск по HTTP-запросу или триггеру Eventarc. Масштабируется до нуля; настраиваемая конкурентность (concurrency); разделение трафика по ревизиям для канареечных развертываний и отката. Установите min instances, чтобы уменьшить холодные старты для чувствительных к задержкам эндпоинтов. Интегрируется с VPC через Serverless VPC Access для частного исходящего трафика.
App Engine: платформенно-ориентированный PaaS. Среда Standard предлагает быстрое масштабирование и ограничения конкурентности на запрос для каждого языка; среда Flexible запускает контейнеры на ВМ с большим контролем. Избегайте хранения состояния сессии локально на экземпляре; выносите его во внешнее общее хранилище, чтобы предотвратить устаревший или дублирующийся пользовательский опыт под нагрузкой.
Cloud Functions: гранулярность на уровне функций для событийно-ориентированной логики. Используйте триггеры Pub/Sub, Cloud Storage или Eventarc для легковесных микроопераций; делайте функции идемпотентными и не хранящими состояние (stateless). Для комбинированных пакетных/потоковых конвейеров без существующего кода Dataflow предоставляет унифицированную обработку с автомасштабированием.

Компромиссы при выборе платформы:

Операционный контроль: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Портативность: на основе контейнеров (GKE/Cloud Run/App Engine Flex) > образы ВМ > функции и App Engine Standard.
Задержка (Latency): Cloud Run с min instances или GKE для низкой хвостовой задержки (tail latency); избегайте холодных стартов для интерактивных рабочих нагрузок.
Масштабирование: Cloud Functions/Run масштабируются быстрее всего; GKE HPA плюс cluster autoscaler; MIG требуют прогрева и проверок работоспособности.
Стоимость: бессерверные с оплатой по факту использования для пиковых/низких постоянных нагрузок; GKE/ВМ с committed use discounts для стабильных, высокопроизводительных сервисов; preemptible/Spot для пакетной обработки.

Идентификаторы и конфигурация:

Каждый сервис должен использовать выделенный сервисный аккаунт с минимальными привилегиями.
Для Cloud Run и Functions явно указывайте сервисный аккаунт времени выполнения.
Храните секреты в Secret Manager и привязывайте доступ через IAM; внедряйте их через переменные окружения или монтируемые тома.

Архитектурные паттерны, доставка и эксплуатация

Декомпозиция сервисов и их границы:

Монолит: простейшее развертывание и транзакции, но ограничивает независимое масштабирование и контроль радиуса поражения (blast radius); может маскировать проблемы с производительностью в глубине цепочек вызовов.
Модульный монолит: четкие внутренние модули, общий процесс; хороший промежуточный шаг — обеспечивает соблюдение интерфейсов без недостатков распределенных систем.
Микросервисы: независимое развертывание и масштабирование; вносит сетевые задержки, распределенные транзакции и проблемы с согласованностью данных. Определяйте четкие ограниченные контексты (bounded contexts) и владение данными; избегайте общих баз данных для предотвращения сильной связанности (coupling).

Паттерны модернизации:

Удушающий инжир (Strangler-fig): постепенно направлять часть трафика на новые компоненты, постепенно выводя из эксплуатации устаревшие эндпоинты.
Lift and shift: сначала контейнеризировать или мигрировать на ВМ для стабилизации, затем проводить рефакторинг.
Слой-антикоррупционер/фасад (Anti-corruption layer/facade): изолировать устаревшие контракты при создании новых сервисов.
В первую очередь отдавайте приоритет доменам с высокой частотой изменений и сложностью, чтобы максимизировать ценность для бизнеса и снизить риски.

Доставка и выкатка:

CI/CD с автоматизированными тестами и промежуточными средами (staged environments) сокращает количество откатов. Добавьте канареечный анализ, бюджеты ошибок (error budgets) и прогрессивную доставку.
Сине-зеленое развертывание (Blue-green) минимизирует время простоя и упрощает откат за счет удвоенной емкости.
Разделение трафика: Cloud Run/App Engine поддерживают маршрутизацию на основе процентов трафика между ревизиями/версиями; тестируйте под реальным трафиком с жесткими бюджетами ошибок SLO.

Балансировка нагрузки и проверка работоспособности:

Используйте глобальный L7 для HTTP и TCP-прокси для протоколов, отличных от HTTP; внутренние балансировщики (internal LBs) для приватных сервисов. Настраивайте привязку сессий (session affinity) только при необходимости и выносите состояние сессии вовне.
Проверки работоспособности (health checks) должны отражать доступность приложения (например, работоспособность зависимостей); простой ответ 200 OK, маскирующий сбой хранилища данных, может привести к неверному направлению трафика.

Наблюдаемость и управление (Observability and governance):

Инструментируйте трассировки (traces) для атрибуции сквозных задержек между сервисами; включите логирование идентификаторов запросов для корреляции логов и трассировок.
Экспортируйте логи/метрики/аудиторские журналы в BigQuery или Cloud Storage для хранения и аудита; обеспечьте безопасный доступ через представления (views) и IAM.
Для логов ВМ установите Ops Agent; определите правила хранения и приемники (sinks) для контроля затрат и соответствия требованиям.

Безопасность цепочки поставок ПО:

Используйте Artifact Registry со сканированием; делайте образы минимальными. Оптимизируйте Dockerfiles: предпочитайте slim-образы, сначала устанавливайте зависимости, а затем копируйте исходный код, чтобы использовать кэш сборки.

Сеть и сегментация:

Обеспечьте многоуровневый доступ с помощью тегов и правил брандмауэра VPC, чтобы разрешать только ожидаемые потоки (например, web → API → DB). Запретите прямой доступ web → DB.

Производительность, мощность и специализированные вычисления

Проектирование для переменной нагрузки:

GCE: автомасштабируйте MIG по опережающим индикаторам (длина очереди), чтобы избежать насыщения ЦП; добавьте ограничение частоты запросов и обратное давление (backpressure) для защиты нижестоящих сервисов.
GKE: комбинируйте HPA по количеству запросов в секунду или пользовательским метрикам с автомасштабированием кластера; создайте небольшой буфер, чтобы избежать задержки при масштабировании.
Serverless: настраивайте параллелизм (concurrency) и минимальное количество экземпляров (min instances) для баланса между стоимостью и задержкой; используйте региональное развертывание для минимальной задержки для пользователя.

Отказоустойчивость и тестирование:

Запускайте синтетическую нагрузку для проверки автомасштабирования и SLO; включите хаос-тестирование (например, случайное удаление экземпляров/подов), чтобы убедиться, что система сохраняет доступность во время сбоев и обновлений.
Настройте PodDisruptionBudgets и хуки корректного завершения (graceful termination hooks), чтобы завершить обработку текущих соединений перед выключением пода/ВМ.

Производительность и выбор хранилища:

Прием данных временных рядов и потоков кликов (clickstream) с высокой пропускной способностью и низкой задержкой хорошо подходит для Bigtable; проектируйте широкие строки и ключи, сгруппированные по временным интервалам, чтобы избежать хотспотов.
Для Spark/Hadoop с минимальными операционными изменениями используйте Dataproc; подбирайте оптимальный размер кластеров с помощью автомасштабирования.
Для комбинированной ежечасной пакетной и потоковой обработки без существующего кода используйте Dataflow с автомасштабированием и оконными функциями (windowing) для объединения конвейеров.

Перемещение данных и связность:

Для постоянной, высокоскоростной, частной репликации (например, многотерабайтных баз данных) рассмотрите Dedicated Interconnect; используйте подключения VLAN (VLAN attachments) и Cloud Router для динамической маршрутизации. Для разовых задач или более низкой пропускной способности достаточно Cloud VPN.

Нагрузки с сохранением состояния:

В GKE используйте StatefulSets с постоянными томами (региональные PD для высокой доступности) и упорядоченными, стабильными идентификаторами; рассмотрите Filestore для семантики NFS.
По возможности используйте управляемые базы данных (Cloud SQL, AlloyDB, Spanner) для обеспечения надежности и масштабирования; планируйте реплики чтения и аварийное переключение (failover).

Безопасность и соответствие требованиям:

Рассмотрите Confidential VMs для защиты данных в процессе использования с ограниченными накладными расходами на производительность; оцените их соответствие требованиям вашей нагрузки.
Используйте CMEK, когда ключи должны находиться под контролем клиента; обеспечьте изоляцию для каждой среды и разделяйте проекты для разработки, тестирования и продакшена.

Контроль затрат:

Используйте скидки за долгосрочное (committed use) и постоянное (sustained use) использование для стабильных вычислительных нагрузок; прерываемые (preemptible/Spot) ВМ для отказоустойчивых пакетных задач; автомасштабирование до нуля для бессерверных сервисов.
Оптимизируйте размер ресурсов с помощью рекомендаций Monitoring; удаляйте простаивающие сервисы и устанавливайте квоты для метрик на основе логов, чтобы избежать непредвиденных расходов.

Устранение проблем с задержкой:

Используйте Cloud Trace для выявления микросервиса, вносящего наибольшую задержку; оптимизируйте путь выполнения кода, кеширование или индексы базы данных этого сервиса. Проверяйте улучшения с помощью A/B-тестирования и канареечных развертываний.

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

Компания FerroLine Logistics планирует модернизировать монолит J2EE, который обрабатывает отслеживание отправлений и уведомления клиентов. Нагрузка имеет взрывной характер во время региональных дедлайнов, должна соответствовать целевому показателю доступности 99,9%, и команда хочет обеспечить переносимость с минимальными рутинными операционными задачами, внедряя при этом функциональность, управляемую событиями.

Стабилизация и наблюдение за текущей системой

Обоснование: Перед внесением изменений определите базовое поведение и ошибки, чтобы снизить риск отката. Разверните Ops Agent на существующих ВМ для Cloud Logging и Monitoring и внедрите распределенную трассировку в путях запросов с высокой задержкой. Экспортируйте логи и метрики в BigQuery для исторического анализа и отчетности по SLO.

Поэтапный выбор целевой зоны и набора платформ

Обоснование: Сбалансируйте контроль и скорость разработки. Перенесите монолит в виде контейнера в Cloud Run jobs для пакетных компонентов и в Cloud Run services для stateless HTTP API, установив min instances для критичных к задержкам эндпоинтов. Изначально оставьте базу данных Oracle с состоянием на Compute Engine, используя региональный внутренний балансировщик нагрузки HTTP(S) в качестве фронтенда для внутренних API, и запланируйте будущий переезд на AlloyDB.

Вынесение состояния сессий и конфигурации вовне

Обоснование: Избегайте проблем с сессиями, локальными для экземпляра, и обеспечьте безопасное автомасштабирование. Храните секреты в Secret Manager, используя отдельные сервисные аккаунты для доступа с минимальными привилегиями. Перенесите состояние сессий в Memorystore, а общие файлы — в Cloud Storage. Это предотвратит получение пользователями устаревших данных при пиковой нагрузке.

Настройка контроля идентификации и реестров

Обоснование: Обеспечьте принцип минимальных привилегий и отслеживаемость. Храните образы в Artifact Registry с включенным сканированием на уязвимости. Назначьте уникальный сервисный аккаунт времени выполнения каждому сервису Cloud Run и нагрузке GKE (для компонентов, которые будут декомпозированы позже), и предоставьте только необходимые роли (например, Pub/Sub Publisher).

Внедрение CI/CD со стратегиями безопасного развертывания

Обоснование: Сократите количество незапланированных откатов. Создайте конвейер, который запускает модульные/интеграционные тесты и развертывает изменения в промежуточной среде (staging). Используйте разделение трафика в Cloud Run для канареечного развертывания 5–10% трафика на новые ревизии и обеспечения быстрого отката. Для изменений в базе данных на ВМ используйте шаблоны миграции схемы blue-green, чтобы разделить развертывания приложения и базы данных.

В первую очередь декомпозировать домены с высокой частотой изменений

Обоснование: Инкрементальная ценность при меньшем риске. Примените шаблон «душитель» (strangler pattern): выделите доставку уведомлений в отдельный микросервис на GKE, чтобы использовать HPA для обработки всплесков нагрузки и Pub/Sub для разделения компонентов. Оставшуюся часть монолита оставьте в виде модульного монолита на Cloud Run, пока интерфейсы не стабилизируются.

Проектирование автомасштабирования и сброса нагрузки

Обоснование: Обрабатывайте всплески нагрузки без каскадных сбоев. Настройте параллелизм (concurrency) и min instances в Cloud Run для каждого эндпоинта; установите ограничения частоты запросов в Cloud Armor на глобальном балансировщике нагрузки HTTP(S) для защиты

← Организационный дизайн · Все домены · Хранение данных →

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