Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене PCA. Читайте сверху вниз или переходите к нужному разделу.
Глобальное приложение требует низкой задержки и высокой доступности для пользователей по всему миру.
Используйте Global HTTP(S) Load Balancer с многорегиональными бэкэндами (MIGs/GKE), Cloud CDN для статического контента и Cloud Armor для защиты от DDoS.
Почему: Global Load Balancer предоставляет единый anycast IP, который направляет пользователей к ближайшему работоспособному бэкэнду. CDN кэширует контент на границе сети, уменьшая нагрузку на источник и задержку.
Прием и обработка высокопроизводительных данных в реальном времени с IoT-устройств для немедленного анализа.
Используйте Pub/Sub для масштабируемого приема сообщений, потоковый конвейер Dataflow для обработки в реальном времени и обнаружения аномалий, а также записывайте результаты в BigQuery для аналитики.
Почему: Это канонический бессерверный шаблон для данных в реальном времени. Pub/Sub разъединяет прием данных, Dataflow обрабатывает сложные процессы с автомасштабированием, а BigQuery поддерживает потоковые вставки для аналитики в реальном времени.
Игровой бэкэнд должен хранить состояние игроков и таблицы лидеров с задержкой чтения менее миллисекунды и высокой пропускной способностью.
Используйте Cloud Bigtable для состояния игры/таблиц лидеров и Memorystore (Redis) для кэширования сессий.
Почему: Bigtable обеспечивает задержку в несколько миллисекунд для высокопроизводительных операций чтения/записи, что идеально подходит для временных рядов или больших аналитических наборов данных. Memorystore предлагает задержку в микросекунды для состояния сессий.
Глобально распределенное приложение требует базу данных с сильной транзакционной согласованностью и горизонтальной масштабируемостью.
Используйте Cloud Spanner с многорегиональной конфигурацией.
Почему: Spanner - это единственный сервис, который предоставляет глобальные, строго согласованные транзакции с семантикой SQL и горизонтальной масштабируемостью. Cloud SQL требует ручного шардирования для такого масштаба.
Миграция требовательной локальной базы данных Oracle или PostgreSQL, требующей высокой доступности, производительности и минимального рефакторинга.
Используйте AlloyDB для PostgreSQL.
Почему: AlloyDB - это полностью управляемая, совместимая с PostgreSQL база данных с превосходной производительностью, доступностью 99,99% и функциями совместимости с Oracle, что делает ее идеальной для корпоративных миграций.
Подключение локального центра обработки данных к GCP с требованиями к стабильной, низкой задержке (<10 мс) и высокой пропускной способности (10+ Гбит/с).
Используйте Dedicated Interconnect с избыточными подключениями.
Почему: Dedicated Interconnect обеспечивает частное, высокоскоростное физическое соединение с низкой задержкой. Cloud VPN работает через публичный интернет и не может гарантировать SLAs по задержке или пропускной способности на этом уровне.
Проектирование сети для нескольких команд/проектов, требующих централизованного управления сетью, но децентрализованного владения проектами.
Внедрите модель "hub-and-spoke" с использованием Shared VPC. Центральная сетевая команда управляет хост-проектом, а команды приложений используют сервисные проекты.
Почему: Shared VPC позволяет централизованно контролировать сетевые ресурсы (подсети, межсетевые экраны), делегируя при этом управление ресурсами в сервисных проектах. Это более масштабируемо и безопасно, чем VPC peering.
Последовательное управление кластерами Kubernetes в Google Cloud, AWS, Azure и локальных средах.
Используйте Anthos для обеспечения унифицированной панели управления для многооблачного и гибридного управления кластерами, принудительного применения политик и обеспечения наблюдаемости.
Почему: Anthos расширяет GKE на другие среды, обеспечивая согласованные операции и управление конфигурацией на основе GitOps (Config Management) для всего вашего флота.
Команде специалистов по данным необходимо обучать сложные ML-модели с ускорением GPU без управления инфраструктурой.
Используйте Vertex AI Training с пользовательскими контейнерами и Vertex AI Experiments для отслеживания итераций моделей.
Почему: Vertex AI предоставляет полностью управляемый сервис для обучения, который занимается выделением инфраструктуры, масштабированием и управлением GPU. Он интегрируется с экспериментами для отслеживания и сравнения производительности моделей.
Обслуживание большой ML-модели с низкой задержкой и высокой доступностью, способной к автомасштабированию.
Используйте Vertex AI Prediction с пользовательским контейнером, развернутым в управляемой конечной точке с включенным автомасштабированием.
Почему: Vertex AI Prediction оптимизирован для обслуживания моделей с низкой задержкой. Он обрабатывает автомасштабирование, разделение трафика (для A/B-тестирования) и управление инфраструктурой, абстрагируя сложность от разработчиков.
Сервису Cloud Function или Cloud Run необходимо безопасно подключиться к экземпляру Cloud SQL с частным IP-адресом.
Настройте Serverless VPC Access Connector для соединения бессерверной среды с вашей VPC.
Почему: Коннектор создает туннель в вашу VPC, позволяя бессерверным сервисам получать доступ к внутренним ресурсам по их частным IP-адресам, не выставляя их в интернет.
Миграция stateful приложения, использующего локальное хранилище сессий, на бессерверную, автомасштабируемую платформу, такую как Cloud Run или GKE.
Вынесите состояние сессии во внешнее управляемое хранилище в памяти, такое как Memorystore (Redis).
Почему: Бессерверные вычисления требуют, чтобы данные сессии хранились внешне, чтобы любой экземпляр мог обрабатывать любой запрос пользователя. Memorystore предоставляет общее решение с низкой задержкой для этого.
Создание управляемого конвейера непрерывной доставки для продвижения релизов между несколькими средами (staging, prod) с подтверждениями.
Используйте Cloud Deploy для определения конвейера доставки, который организует развертывания в целевые среды (GKE, Cloud Run) со встроенными воротами подтверждения.
Почему: Cloud Deploy - это полностью управляемый сервис для CD, предоставляющий управление релизами, возможность аудита и автоматический откат без операционных затрат на самостоятельное размещение таких инструментов, как Spinnaker.
Развертывание контейнеризированного приложения на готовом к производству кластере Kubernetes с минимальными операционными и управленческими издержками.
Используйте кластер GKE Autopilot.
Почему: Autopilot управляет панелью управления и узлами кластера, включая выделение ресурсов, масштабирование и усиление безопасности. Вы платите только за ресурсы подов, которые запрашиваете, что упрощает как операции, так и управление затратами.
Постепенная миграция большого монолитного приложения на микросервисную архитектуру с минимальным риском и временем простоя.
Примените шаблон Strangler Fig. Разместите прокси перед монолитом и постепенно перенаправляйте трафик для конкретных функций на новые микросервисы по мере их создания и проверки.
Почему: Этот шаблон позволяет избежать высокорискового "большого взрыва" путем постепенного, контролируемого перехода. Монолит медленно "душится", поскольку новые сервисы берут на себя его функциональность.
Миграция большого количества локальных виртуальных машин в Google Cloud с минимальным временем простоя.
Используйте Migrate to Virtual Machines (ранее Migrate for Compute Engine) для выполнения непрерывной репликации на блочном уровне из локальной среды в GCP, за которой следует быстрое переключение.
Почему: Этот инструмент предназначен для миграции методом "lift-and-shift", минимизируя время простоя до нескольких минут за счет поддержания синхронизации исходных и целевых виртуальных машин до окончательного переключения.
Команда внедряет принципы SRE и должна установить свои начальные SLO.
Сначала определите ориентированные на пользователя индикаторы уровня обслуживания (SLI) (например, доступность, задержка). Проанализируйте исторические данные о производительности, чтобы установить реалистичные начальные цели уровня обслуживания (SLO).
Почему: SLO должны основываться на пользовательском опыте (SLI) и быть достижимыми. Установка их на основе исторических данных гарантирует, что начальный бюджет ошибок будет реалистичным и не будет немедленно нарушен.
Автоматизация создания новых проектов GCP со стандартизированной конфигурацией (APIs, IAM, сеть, безопасность).
Используйте шаблон "Project Factory" с модулем Terraform, запускаемым с помощью Cloud Build. Используйте Service Catalog для предоставления интерфейса самообслуживания.
Почему: Это гарантирует, что все новые проекты соответствуют организационным стандартам и базовым уровням безопасности, сокращая ручной труд и отклонения в конфигурации. Это обеспечивает управление в масштабе.
Предотвращение ручных изменений (отклонений конфигурации) в инфраструктуре, управляемой Terraform.
Используйте CI/CD-конвейер (например, Cloud Build) для всех применений, блокировку состояния Terraform (через бэкэнд GCS), Organization Policies для ограничения действий консоли и регулярное обнаружение отклонений.
Почему: Требуется многоуровневый подход. Конвейер обеспечивает единый путь для изменений, блокировка предотвращает одновременные применения, а Org Policies служат превентивным барьером.
Управление кодом инфраструктуры (Terraform) для нескольких сред (dev, staging, prod) с общими модулями, но разными конфигурациями.
Используйте единый набор повторно используемых модулей Terraform и предоставьте специфичные для среды конфигурации через отдельные файлы `.tfvars` или рабочие области.
Почему: Это соответствует принципу "Не повторяйся" (DRY). Модули обеспечивают согласованность, а файлы переменных предоставляют гибкость для настройки каждой среды.
Внедрение рабочего процесса GitOps для автоматического развертывания манифестов Kubernetes из репозитория Git в кластеры GKE.
Используйте Anthos Config Management (или автономный Config Sync) для непрерывного согласования состояния кластера с конфигурацией в репозитории Git.
Почему: Config Sync предоставляет полностью управляемое решение GitOps, которое обнаруживает и исправляет отклонения конфигурации, гарантируя, что репозиторий Git является единственным источником истины для состояния кластера.
Внедрение сине-зеленого развертывания для веб-приложения с нулевым временем простоя и возможностью мгновенного отката.
Используйте две идентичные управляемые группы экземпляров (или GKE Deployments) за HTTP(S) Load Balancer. Выполните переключение, перенаправив трафик в бэкэнд-сервисе балансировщика нагрузки.
Почему: Разделение трафика на уровне балансировщика нагрузки происходит мгновенно и позволяет легко выполнить откат, просто переключив трафик обратно на исходный бэкэнд. Это превосходит более медленные методы, основанные на DNS.
Безопасное хранение, управление и аудит доступа к секретам, таким как ключи API и пароли баз данных для приложений.
Используйте Secret Manager с IAM для контроля доступа и Workload Identity для беспарольной аутентификации из GKE/Cloud Run.
Почему: Secret Manager - это централизованный управляемый сервис с версионированием, политиками ротации и аудитом. Использование Workload Identity позволяет избежать управления и распространения ключей сервисных учетных записей.
Предотвращение доступа к конфиденциальным данным в сервисах, таких как BigQuery и Cloud Storage, или их копирования в неавторизованные проекты или местоположения.
Используйте VPC Service Controls для создания сервисного периметра вокруг конфиденциальных проектов и ограничения потока данных.
Почему: VPC Service Controls действуют как межсетевой экран для управляемых Google сервисов, предотвращая утечку данных на уровне API. Это критически важный уровень глубокой защиты, дополняющий IAM и сетевые межсетевые экраны.
Шифрование неактивных данных в сервисах Google Cloud с полным контролем над ключами шифрования.
Используйте ключи шифрования, управляемые клиентом (CMEK), с ключами, хранящимися и управляемыми в Cloud KMS.
Почему: CMEK позволяет использовать ваши собственные ключи через Cloud KMS для защиты данных в других сервисах GCP. Вы контролируете ротацию ключей и можете отозвать доступ, отключив ключ, что обеспечивает криптографическое стирание.
Проектирование архитектуры для обработки защищенной медицинской информации (PHI) в соответствии с HIPAA.
Используйте CMEK для контроля шифрования, VPC Service Controls для предотвращения утечки данных, Assured Workloads для границ соответствия, Cloud Audit Logs и Access Transparency для аудита.
Почему: HIPAA требует комбинации технических средств контроля. CMEK обеспечивает контроль ключей, VPC-SC предотвращает утечки данных, а обширное логирование (Audit Logs, Access Transparency) обеспечивает необходимый аудит.
Поду GKE необходимо безопасно подключиться к базе данных Cloud SQL без использования паролей или управления ключами сервисных учетных записей.
Используйте Workload Identity для привязки сервисной учетной записи Kubernetes к сервисной учетной записи Google. Подключайтесь с использованием сайдкара Cloud SQL Auth Proxy и аутентификации базы данных IAM.
Почему: Этот "беспарольный" шаблон является наиболее безопасным. Workload Identity обеспечивает аутентификацию без ключей, Auth Proxy шифрует трафик, а аутентификация базы данных IAM использует IAM для доступа к базе данных вместо статических учетных данных.
Применение политики, согласно которой все облачные ресурсы должны создаваться только в определенных географических регионах (например, ЕС).
Настройте ограничение Organization Policy (`gcp.resourceLocations`) на уровне организации или папки, указав разрешенные регионы.
Почему: Это превентивный контроль, который блокирует создание несоответствующих ресурсов на уровне API. Это авторитетный способ принудительного применения политик резидентности данных во всей организации.
Обеспечение развертывания только доверенных, отсканированных и авторизованных образов контейнеров в производственные кластеры GKE.
Используйте Artifact Registry для сканирования уязвимостей и Binary Authorization для применения политик развертывания, требующих действительных аттестаций (подписей).
Почему: Это создает безопасную цепочку поставок программного обеспечения. Artifact Registry сканирует на наличие уязвимостей, а Binary Authorization выступает в качестве точки применения политики, криптографически проверяя, что образ прошел все необходимые проверки.
Обеспечение безопасного, контекстно-зависимого доступа к внутренним веб-приложениям для удаленных сотрудников без использования традиционного VPN.
Используйте BeyondCorp Enterprise с Identity-Aware Proxy (IAP), Access Context Manager для политик и Endpoint Verification для оценки состояния устройства.
Почему: Это реализует модель нулевого доверия, где доступ предоставляется на основе идентификации пользователя и доверия к устройству, а не местоположения в сети. IAP действует как аутентифицирующий прокси для каждого запроса.
Регулируемая рабочая нагрузка требует, чтобы ключи шифрования хранились и обрабатывались внутри аппаратного модуля безопасности (HSM), сертифицированного по FIPS 140-2 Level 3.
Используйте Cloud KMS с уровнем защиты `HSM` для ключей.
Почему: Cloud HSM - это полностью управляемый сервис, предоставляющий HSM, сертифицированные по FIPS 140-2 Level 3. Ключи, сгенерированные с этим уровнем защиты, никогда не покидают границы HSM в открытом виде.
Автоматическое обнаружение и деидентификация конфиденциальных данных (таких как PII) в Cloud Storage или BigQuery.
Используйте Cloud Data Loss Prevention (DLP) для сканирования конфиденциальных данных и применения методов деидентификации, таких как маскирование, токенизация или ретрансляция.
Почему: DLP предоставляет встроенные и настраиваемые детекторы для широкого спектра типов конфиденциальных данных, что обеспечивает автоматизированную и масштабируемую защиту данных без пользовательских сценариев.
Разрешить сотрудникам из нескольких поставщиков удостоверений (например, Okta, Azure AD) доступ к ресурсам Google Cloud без создания учетных записей Google.
Используйте Workforce Identity Federation для подключения внешних поставщиков удостоверений к Google Cloud IAM.
Почему: Это позволяет использовать ваши существующие системы удостоверений в качестве источника истины, избегая необходимости синхронизировать пользователей или управлять отдельными Google-идентификаторами для ваших сотрудников.
Обработка особо конфиденциальных данных, которые должны оставаться зашифрованными даже во время использования (в памяти).
Используйте Confidential VMs.
Почему: Confidential Computing шифрует данные во время обработки, используя специализированные аппаратные функции (AMD SEV). Это защищает от атак на извлечение данных из памяти и обеспечивает дополнительный уровень безопасности для конфиденциальных рабочих нагрузок.
Оптимизация стоимости и производительности BigQuery для большого хранилища данных.
Реализуйте партиционирование по дате и кластеризацию по часто фильтруемым столбцам. Используйте BI Engine для дашбордов и материализованные представления для общих, дорогостоящих агрегаций.
Почему: Партиционирование и кластеризация являются основополагающими для уменьшения объема данных, сканируемых на запрос, что напрямую снижает затраты и повышает скорость. BI Engine и MVs сокращают избыточные вычисления.
Запуск крупномасштабных, отказоустойчивых заданий пакетной обработки с минимально возможными затратами на вычисления.
Используйте Spot VMs в управляемой группе экземпляров. Убедитесь, что приложение отказоустойчиво и может обрабатывать вытеснения.
Почему: Spot VMs предлагают экономию до 91% по сравнению с экземплярами по требованию. Они идеально подходят для бессерверных, отказоустойчивых рабочих нагрузок, которые можно останавливать и перезапускать, как многие задачи пакетной обработки.
Внедрение практик FinOps для обеспечения прозрачности затрат и ответственности для различных команд или отделов.
Используйте иерархию ресурсов (папки для каждой команды), применяйте метки для распределения затрат и экспортируйте подробные данные о выставлении счетов в BigQuery для анализа и визуализации в Looker Studio.
Почему: Эта комбинация обеспечивает структурированный способ организации ресурсов, детальное отслеживание затрат с помощью меток и создание пользовательских, специфичных для команды дашбордов для showback/chargeback.
Оптимизация стоимости и производительности кластера GKE для приложений с переменной нагрузкой.
Используйте Horizontal Pod Autoscaler (HPA) для масштабирования подов на основе метрик и Cluster Autoscaler для добавления/удаления узлов по мере необходимости.
Почему: Этот двухуровневый подход к автомасштабированию гарантирует, что как приложение (поды), так и инфраструктура (узлы) масштабируются в соответствии со спросом, предотвращая избыточное выделение ресурсов и обеспечивая производительность.
Задача обучения ML показывает низкую утилизацию GPU (<30%), что указывает на узкое место.
Диагностируйте и оптимизируйте конвейер ввода данных. Используйте `tf.data` с предварительной выборкой и параллельным чтением или Cloud Storage FUSE для улучшения производительности ввода/вывода.
Почему: Низкая утилизация GPU почти всегда является узким местом ввода/вывода данных. GPU простаивает в ожидании следующей партии данных. Оптимизация загрузки данных - первый шаг к повышению эффективности обучения.
Сокращение высоких затрат на исходящий сетевой трафик при передаче данных в интернет или между регионами.
Используйте Cloud CDN для кэширования статического контента. Для межрегионального трафика используйте Standard Network Service Tier для рабочих нагрузок, не чувствительных к задержкам.
Почему: CDN обслуживает данные с периферии, что дешевле, чем исходящий трафик с источника. Standard Tier направляет трафик через публичный интернет вместо премиальной сети Google, предлагая более низкую стоимость для массовой передачи данных.
Сокращение затрат на виртуальные машины разработки и тестирования, которые требуются только в рабочее время.
Используйте Cloud Scheduler для запуска Cloud Functions, которые автоматически запускают и останавливают экземпляры по заданному расписанию.
Почему: Этот шаблон "планирования экземпляров" автоматизирует процесс отключения ресурсов, когда они не используются, значительно сокращая затраты для непроизводственных сред.
Критически важное приложение требует реляционной базы данных с автоматическим переключением при сбое зоны.
Настройте экземпляр Cloud SQL с опцией высокой доступности (HA).
Почему: Конфигурация HA создает резервный экземпляр в другой зоне с синхронной репликацией. В случае сбоя основного экземпляра или зоны переключение происходит автоматически и обычно занимает менее 60 секунд.
Автоматическое обнаружение и восстановление после не отвечающих или отказавших экземпляров Compute Engine.
Разверните экземпляры в Managed Instance Group (MIG) и настройте автовосстановление с проверкой работоспособности на основе приложения.
Почему: Автовосстановление MIG активно проверяет приложение на каждом экземпляре. Если приложение не проходит проверку работоспособности, MIG автоматически пересоздает экземпляр, обеспечивая надежность сервиса.
Разработка плана аварийного восстановления с RTO < 1 часа и RPO < 15 минут.
Реализуйте режим "warm standby" во вторичном регионе. Используйте межрегиональные реплики Cloud SQL, многорегиональное хранилище Cloud Storage и предварительно настроенные шаблоны экземпляров для вычислений.
Почему: Этот подход балансирует стоимость и время восстановления. Данные реплицируются почти синхронно для выполнения RPO, и минимальная инфраструктура работает (в режиме "warm standby") для быстрого масштабирования до RTO.
Внедрение комплексной наблюдаемости для микросервисного приложения для быстрого устранения неполадок.
Используйте структурированное логирование с идентификаторами корреляции, Cloud Trace для распределенной трассировки, Cloud Monitoring для метрик и Cloud Error Reporting для автоматической группировки ошибок.
Почему: Сочетание логов, трассировок и метрик ("трех столпов наблюдаемости") является essentiel. Идентификаторы корреляции и распределенная трассировка критически важны для отслеживания одного запроса через несколько сервисов.
Предотвращение того, чтобы сбой в одном микросервисе приводил к каскадному сбою во всем приложении.
Реализуйте шаблоны устойчивости, такие как "автоматический выключатель", повторные попытки с экспоненциальной задержкой и агрессивные тайм-ауты в каждой точке межсервисного взаимодействия.
Почему: Эти шаблоны изолируют сбои. Автоматический выключатель останавливает вызовы к сбойному сервису, предотвращая исчерпание ресурсов вызывающего сервиса и его последующий сбой.
Внедрение лучших практик SRE для снижения риска производственных сбоев, вызванных новыми развертываниями.
Используйте канареечные развертывания для постепенного внедрения изменений, флаги функций для отделения развертывания от выпуска и автоматические триггеры отката на основе мониторинга SLO.
Почему: Эти практики ограничивают "радиус поражения" неудачного развертывания. Канарейки сначала представляют новую версию небольшой части пользователей, а автоматический откат минимизирует среднее время восстановления (MTTR).
Использование бюджетов ошибок SRE для балансирования скорости внедрения функций с надежностью.
Определите политику бюджета ошибок: когда бюджет почти исчерпан, заморозьте новые развертывания функций и приоритизируйте работу, улучшающую надежность.
Почему: Бюджет ошибок - это механизм, основанный на данных, для принятия компромиссных решений. Он дает командам разрешение рисковать, когда бюджет в норме, и заставляет сосредоточиться на стабильности, когда это не так.
Глобально распределенное приложение, использующее Cloud Spanner, сталкивается с высокой задержкой записи в определенных регионах.
Проанализируйте шаблоны записи приложения и настройте ведущий регион экземпляра Spanner так, чтобы он географически был близок к большинству операций записи.
Почему: В Spanner все операции записи маршрутизируются через ведущий регион для обеспечения согласованности. Размещение ведущего региона близко к основному источнику записей минимизирует задержку сети для этих транзакций.