Google Cloud Professional Cloud Developer
Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене PCD. Читайте сверху вниз или переходите к нужному разделу.
Микросервисам требуется как синхронная связь запрос/ответ, так и асинхронная, управляемая событиями.
Используйте gRPC или HTTP для синхронных вызовов. Используйте Pub/Sub для асинхронной обработки событий и веерной рассылки.
Почему: Pub/Sub полностью отделяет сервисы для обеспечения надежности и независимого масштабирования. Прямые вызовы обеспечивают синхронные ответы с низкой задержкой.
Сервис бессерверных вычислений (Cloud Run, Cloud Functions) должен обрабатывать временные файлы.
Используйте Cloud Storage для всего ввода-вывода временных файлов.
Почему: Локальная файловая система бессерверных платформ является эфемерной, находится в памяти и не является общей. Cloud Storage предоставляет надежное, масштабируемое хранилище, доступное для всех экземпляров.
Управляйте специфичной для среды конфигурацией и секретами для рабочих нагрузок GKE в соответствии с принципами 12-факторного приложения.
Используйте K8s ConfigMaps для нечувствительной конфигурации. Используйте Secret Manager для конфиденциальных значений, доступ к которым осуществляется безопасно через Workload Identity.
Почему: Secret Manager — это более безопасное, управляемое и поддающееся аудиту решение, чем K8s Secrets. Workload Identity позволяет избежать управления и распространения ключей сервисных аккаунтов.
Приложение имеет экстремальные пики трафика, но длительные периоды простоя, когда затраты должны быть минимизированы.
Используйте Cloud Run с `min-instances`, установленным в 0.
Почему: Cloud Run может масштабироваться до нуля, устраняя все затраты на вычисления в периоды простоя. GKE и Compute Engine требуют минимального количества запущенных узлов/экземпляров.
Внедрите повторные попытки, автоматические выключатели (circuit breakers) и mTLS единообразно во всех микросервисах без изменения кода приложения.
Разверните service mesh (Anthos Service Mesh) на GKE.
Почему: Service mesh внедряет отказоустойчивость, безопасность и наблюдаемость на уровне платформы, сохраняя чистоту кода приложения и обеспечивая согласованное поведение.
Предоставьте доступ к бэкэнд-сервисам внешним партнерам или мобильным приложениям с ограничением скорости, ключами API и аналитикой использования.
Используйте API Gateway перед бэкэнд-сервисами (например, Cloud Run, GKE).
Почему: API Gateway предоставляет полностью управляемое решение для вопросов жизненного цикла API (безопасность, мониторинг, версионирование), разгружая от них бэкэнд-сервис.
Выберите надежное, масштабируемое и строго согласованное хранилище для журнала событий с добавлением записей.
Используйте Cloud Spanner для хранилища событий.
Почему: Spanner обеспечивает горизонтальное масштабирование со строгой глобальной согласованностью, что крайне важно для поддержания целостности журнала событий в масштабе.
API для длительной задачи должен отвечать немедленно, пока обработка продолжается в фоновом режиме.
Конечная точка API ставит задачу в очередь Pub/Sub или Cloud Tasks и возвращает 202 Accepted с идентификатором задачи. Отдельный работник (Cloud Run, Cloud Function) обрабатывает задачу.
Почему: Это отделяет время ответа для пользователя от времени обработки на бэкэнде, улучшая UX и надежность системы. Используйте Cloud Storage для обновления статуса.
Поддерживайте согласованность данных между несколькими микросервисами без общей базы данных.
Реализуйте паттерн Saga с использованием оркестратора (Cloud Workflows) или хореографии (события Pub/Sub) с компенсирующими транзакциями.
Почему: Позволяет избежать сложных и склонных к блокировкам двухфазных коммитов, отдавая предпочтение конечной согласованности, которая лучше подходит для распределенных систем.
Приложение вызывает сторонний API с ограничением скорости, данные в котором изменяются нечасто.
Используйте Memorystore для Redis в качестве распределенного кэша. Реализуйте паттерн cache-aside с TTL. Используйте распределенную блокировку (например, Redis SETNX) для предотвращения «штампов кэша».
Почему: Распределенный кэш совместно использует данные между всеми экземплярами приложения, значительно сокращая количество вызовов внешнего API, улучшая задержку и соблюдая ограничения скорости.
Команде разработчиков требуются согласованные, предварительно настроенные, безопасные среды разработки с доступом к частным ресурсам VPC.
Используйте Cloud Workstations.
Почему: Cloud Workstations предоставляет управляемые, контейнерные среды разработки с интегрированной безопасностью и доступом к VPC, решая проблему «у меня на машине работает».
SaaS-приложение требует, чтобы клиенты имели полностью изолированные данные, ключи шифрования и местонахождение данных.
Используйте модель «один проект на клиента». Управляйте выделением ресурсов и конфигурацией централизованно с помощью IaC (Terraform).
Почему: Обеспечивает высочайший уровень изоляции для IAM, биллинга, квот, сети и местоположения данных, что часто требуется корпоративным или регулируемым клиентам.
Обеспечьте, чтобы в производство развертывались только доверенные, проверенные образы контейнеров из официального конвейера.
Используйте Cloud Build для генерации SLSA-происхождения, Artifact Registry для сканирования уязвимостей и Binary Authorization для применения политик развертывания на основе аттестаций.
Почему: Создает проверяемую, непробиваемую криптографическую цепочку доверия от кода до развертывания, предотвращая развертывание скомпрометированных или непроверенных артефактов.
Разверните новую версию сервиса Cloud Run, протестируйте ее без влияния на пользователей и мгновенно переключите трафик.
Разверните новую ревизию с флагом `--no-traffic`. Тестируйте, используя уникальный URL ревизии или тег ревизии. Переключите 100% трафика на новую ревизию после ее проверки.
Почему: Встроенное управление трафиком Cloud Run позволяет безопасно выполнять развертывания без простоя, проверяя новую версию до того, как она получит какой-либо производственный трафик.
Постепенно развертывайте новую версию, автоматически анализируя метрики и откатываясь при сбое.
Используйте Cloud Deploy со стратегией канареечного развертывания. Интегрируйте с Cloud Monitoring для автоматического анализа метрик и триггеров отката.
Почему: Cloud Deploy автоматизирует весь рабочий процесс прогрессивной доставки, включая анализ метрик и проверки безопасности, сокращая ручные усилия и риски.
Управляйте манифестами Kubernetes для сред разработки, тестирования и продакшна без дублирования кода.
Используйте Kustomize или Helm. Определите базовую конфигурацию и создайте специфичные для среды оверлеи или файлы значений для внесения различий.
Почему: Следует принципу DRY, упрощая управление конфигурациями и снижая риск расхождения сред.
Уменьшите размер образа контейнера для более быстрого развертывания и меньшей поверхности атаки.
Используйте многоступенчатые сборки. Этап `build` использует полный образ SDK/JDK; финальный этап копирует только скомпилированный артефакт в минимальный базовый образ `distroless`.
Почему: Финальный образ содержит только приложение и его зависимости времени выполнения, удаляя все инструменты сборки, оболочки и менеджеры пакетов.
Автоматически развертывайте эфемерные среды для каждого pull request для проверки перед слиянием.
Используйте триггеры Cloud Build для событий PR для развертывания в Cloud Run с тегом ревизии (например, `pr-123`). Используйте другой триггер при закрытии PR для очистки помеченной ревизии.
Почему: Теги ревизий предоставляют уникальные, временные URL для каждого PR без накладных расходов на создание новых сервисов, что делает их экономически эффективными и легко автоматизируемыми.
Увеличьте скорость сборки CI/CD и надежность, кэшируя публичные программные зависимости (например, из npm, Maven Central).
Используйте удаленный репозиторий Artifact Registry, который действует как прокси-кэш для публичного репозитория.
Почему: Улучшает производительность сборки, защищает сборки от сбоев публичных реестров и позволяет сканировать уязвимости в кэшированных артефактах.
Надежно храните и блокируйте состояние Terraform для одновременного выполнения конвейеров CI/CD.
Используйте бэкэнд Cloud Storage для состояния Terraform с соответствующим IAM для сервисного аккаунта Cloud Build.
Почему: Cloud Storage предоставляет надежный, версионированный и блокируемый бэкэнд, предотвращая повреждение состояния из-за одновременных сборок.
Сервис Cloud Run или Cloud Function должен получить доступ к ресурсу (например, Cloud SQL, Memorystore) в частной сети VPC.
Настройте коннектор Serverless VPC Access.
Почему: Коннектор действует как сетевой мост, позволяя исходящему трафику из бессерверной среды в целевую VPC без публичного exposing ресурсов.
Состояниезависимое приложение на GKE требует стабильной идентификации и постоянного хранилища, которое сохраняется при сбое подов/узлов.
Используйте StatefulSet с Headless Service для идентификации. Используйте PersistentVolumeClaim (PVC) с региональным Persistent Disk для хранилища.
Почему: Это канонический паттерн Kubernetes для состояниезависимых рабочих нагрузок, обеспечивающий постоянство данных, высокую доступность и предсказуемое именование/сеть подов.
Под на GKE должен безопасно получать доступ к GCP API без управления статическими ключами сервисных аккаунтов.
Настройте и используйте Workload Identity.
Почему: Workload Identity связывает сервисный аккаунт Kubernetes с сервисным аккаунтом Google, позволяя подам использовать кратковременные учетные данные GCP, полученные с сервера метаданных.
Запустите пакетное задание, выполнение которого занимает часы (например, обработка большого файла, ночная агрегация данных).
Используйте задания Cloud Run, запускаемые с помощью Eventarc или Cloud Scheduler.
Почему: Задания Cloud Run разработаны для длительных задач (до 24 часов), масштабируются до нуля и являются более экономичными и простыми, чем выделенный кластер GKE или VM для пакетных рабочих нагрузок.
Разверните многоконтейнерное приложение в Cloud Run, где основному контейнеру требуется sidecar для логирования, метрик или в качестве прокси.
Разверните сервис Cloud Run с несколькими указанными образами контейнеров: один в качестве основного контейнера, а другие в качестве sidecar-контейнеров.
Почему: Встроенная поддержка нескольких контейнеров Cloud Run позволяет использовать паттерн sidecar для бессерверных рабочих нагрузок без сложности GKE.
Миграции базы данных должны завершиться до того, как новая ревизия Cloud Run начнет получать трафик.
Выполняйте миграции во время запуска контейнера и используйте Cloud Run startup probe, который успешно завершается только после успешных миграций.
Почему: Проверка запуска (startup probe) задерживает маршрутизацию трафика до полной готовности контейнера, обеспечивая правильность схемы базы данных до обработки каких-либо запросов.
Приложение GKE должно масштабироваться на основе пользовательской метрики, такой как глубина очереди из Pub/Sub, а не только CPU/памяти.
Используйте Horizontal Pod Autoscaler (HPA), настроенный для чтения пользовательских метрик из Cloud Monitoring.
Почему: Это позволяет автоматическому масштабированию управляться бизнес-логикой или специфичными для приложения индикаторами нагрузки, обеспечивая более точное масштабирование, чем общие метрики ресурсов.
Сервис, управляемый сообщениями, должен обрабатывать каждое сообщение ровно один раз, несмотря на повторные попытки и возможные дублирующиеся доставки.
Комбинируйте Pub/Sub (с доставкой at-least-once или exactly-once) с идемпотентным потребителем. Потребитель отслеживает обработанные идентификаторы сообщений в постоянном хранилище (например, Firestore, Memorystore).
Почему: Pub/Sub гарантирует доставку, но потребитель отвечает за идемпотентность для обработки повторных попыток на уровне приложения и достижения истинной однократной обработки.
События, относящиеся к одной и той же сущности (например, конкретному пользователю), должны обрабатываться в том порядке, в котором они были сгенерированы.
Публикуйте сообщения в Pub/Sub с `orderingKey`. Включите упорядочивание сообщений в подписке.
Почему: Pub/Sub гарантирует, что сообщения с одинаковым ключом упорядочивания доставляются по порядку, в то время как сообщения с разными ключами могут обрабатываться параллельно для масштабируемости.
Убедитесь, что задача (например, создание ежедневного отчета пользователя) выполняется только один раз, даже если поступает несколько событий-триггеров.
Используйте Cloud Tasks. Создавайте задачи с явными именами (например, `report-userX-2024-10-26`). Cloud Tasks будет дедуплицировать запросы на создание задачи с уже существующим именем.
Почему: Это перекладывает логику дедупликации на сервис очередей, упрощая код приложения и предотвращая избыточную работу.
Сообщение Pub/Sub постоянно не обрабатывается после нескольких повторных попыток и блокирует очередь.
Настройте тему для недоставленных сообщений (DLQ) в подписке Pub/Sub и установите максимальное количество попыток доставки.
Почему: Pub/Sub автоматически перемещает «ядовитое» сообщение в DLQ, позволяя обрабатывать другие сообщения и сохраняя неудачное сообщение для анализа.
Бизнес-процесс включает последовательность вызовов сервисов с условной логикой, обработкой ошибок и длительными ожиданиями.
Используйте Cloud Workflows для определения и выполнения логики оркестрации.
Почему: Cloud Workflows — это бессерверный оркестратор, который управляет состоянием, повторными попытками и длительными ожиданиями, обеспечивая лучшую надежность и видимость, чем функции, связанные вручную.
Сервис Cloud Function или Cloud Run должен запускаться только определенными облачными событиями (например, определенными типами файлов в Cloud Storage).
Используйте триггер Eventarc с фильтрацией CEL (Common Expression Language) по атрибутам события.
Почему: Фильтрация происходит до вызова сервиса, что экономит затраты и вычислительные циклы, не обрабатывая нерелевантные события.
Ограничьте скорость исходящих вызовов к стороннему API из горизонтально масштабируемого сервиса, такого как Cloud Run.
Поместите вызовы API в очередь Cloud Tasks с настроенными `rateLimits` (например, максимальное количество отправлений в секунду).
Почему: Cloud Tasks предоставляет централизованное, бессерверное ограничение скорости, которое работает для всех масштабированных экземпляров без необходимости использования сложных распределенных счетчиков.
Безопасно аутентифицировать вызовы между двумя сервисами Cloud Run (или Cloud Functions).
Предоставьте сервисному аккаунту вызывающего сервиса роль IAM `roles/run.invoker` в вызываемом сервисе. Вызывающий отправляет подписанный Google ID-токен со своим запросом.
Почему: Это нативный, безопасный и бесключевой метод аутентификации между сервисами, использующий инфраструктуру идентификации Google.
Сервис, управляемый событиями, должен реагировать на изменения на уровне строк в базе данных Cloud SQL почти в реальном времени.
Используйте Datastream (CDC) для потоковой передачи изменений базы данных в Pub/Sub. Используйте Eventarc для запуска сервиса Cloud Run из темы Pub/Sub.
Почему: Это разделенный, надежный паттерн, который позволяет избежать опроса базы данных и не требует изменения приложения, записывающего данные в базу данных.
Длительный бизнес-процесс должен быть приостановлен в ожидании внешнего события, например, нажатия человеком ссылки одобрения в электронном письме.
Используйте Cloud Workflows с конечной точкой обратного вызова. Рабочий процесс приостанавливается (на срок до года) до тех пор, пока не получит HTTP-запрос по своему уникальному URL-адресу обратного вызова.
Почему: Обратные вызовы позволяют рабочим процессам ожидать внешних событий, не потребляя вычислительных ресурсов, что делает их идеальными для длительных процессов с участием человека.
Чувствительное к задержкам бессерверное приложение испытывает медленные начальные ответы после периодов простоя.
Настройте `min-instances` на 1 или более. Для неизбежных холодных стартов используйте `startup-cpu-boost`. Также оптимизируйте приложение (меньший образ, более быстрая инициализация).
Почему: `min-instances` — самый эффективный способ устранения холодных стартов, но он влечет за собой затраты. `startup-cpu-boost` ускоряет сам процесс запуска.
Запрос медленный или завершается сбоем в нескольких микросервисах, и узкое место не очевидно из журналов или отдельных метрик сервисов.
Используйте Cloud Trace с распространением контекста. Инструментируйте приложения для пересылки заголовков трассировки (например, W3C Trace Context).
Почему: Cloud Trace предоставляет водопадную визуализацию всего жизненного цикла запроса по всем сервисам, точно определяя источник задержки или ошибок.
Приложение медленно работает в продакшне, и неясно, связана ли проблема с загрузкой ЦП, утечкой памяти или вводом-выводом.
Используйте Cloud Profiler для непрерывного анализа использования ЦП и кучи в продакшне.
Почему: Cloud Profiler выявляет узкие места производительности на уровне кода (горячие пути, утечки памяти) с очень низкими накладными расходами, без необходимости воспроизводить проблемы в тестовой среде.
Перейдите от простых пороговых оповещений (например, «задержка > 500 мс») к более значимым оповещениям на основе Целей Уровня Обслуживания (SLO).
Определите SLI и SLO в Cloud Monitoring. Создайте политики оповещения на основе «скорости сжигания» бюджета ошибок.
Почему: Оповещение по скорости сжигания более чувствительно к значительным изменениям и менее 'шумно', чем простые пороговые оповещения, сигнализируя о том, что вы движетесь к нарушению вашего SLO.
Агрегируйте исключения приложений из нескольких сервисов для отслеживания частоты, просмотра трассировок стека и получения уведомлений о новых типах ошибок.
Используйте Cloud Error Reporting.
Почему: Error Reporting автоматически собирает, группирует и анализирует исключения из структурированных журналов, предоставляя централизованную панель для управления ошибками приложений.
Мониторинг, визуализация и оповещения о пользовательских бизнес-метриках (например, заказы в минуту, регистрации пользователей).
Инструментируйте код приложения с использованием OpenTelemetry SDK. Настройте экспортер для отправки метрик в Cloud Monitoring.
Почему: Это современный, независимый от поставщика стандарт для пользовательской инструментации. Он позволяет отслеживать любую метрику и использовать все функции Cloud Monitoring для нее.
