Google PCD: Архитектура Cloud-Native приложений и выбор сервисов — Руководство по подготовке

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

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

Обзор

Архитектура облачных (cloud-native) приложений в Google Cloud сосредоточена на создании отказоустойчивых сервисов без сохранения состояния (stateless), которые масштабируются горизонтально, минимизируют операционную нагрузку и используют управляемые сервисы там, где это уместно. Эффективный выбор сервисов требует понимания компромиссов между контролем, переносимостью, производительностью, стоимостью и операционной ответственностью. В этом разделе представлены принципы и паттерны, которые помогут вам проектировать, модернизировать и эксплуатировать приложения для глобальных пользователей с предсказуемой надежностью.

Принципы Cloud-Native и архитектурные решения

Двенадцатифакторный (twelve-factor) и stateless-дизайн
- Кодовая база, зависимости и цикл сборка-выпуск-запуск (build-release-run): Фиксируйте точные версии зависимостей, создавайте неизменяемые артефакты и отделяйте сборку от выпуска. Образы контейнеров и конвейеры Cloud Build обеспечивают воспроизводимые релизы.
- Конфигурация в среде выполнения: Выносите конфигурацию вовне, используя переменные окружения, Secret Manager, Kubernetes Secrets или метаданные экземпляра для Compute Engine. Не встраивайте учетные данные или настройки для конкретного развертывания в образы. Для управляемых групп экземпляров Compute Engine используйте метаданные шаблона экземпляра для передачи значений, специфичных для развертывания.
- Вспомогательные сервисы (backing services): Рассматривайте базы данных, очереди и кэши как подключаемые ресурсы. Отдавайте предпочтение управляемым сервисам (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub), чтобы снизить операционную нагрузку.
- Процессы без сохранения состояния (stateless): Масштабируйтесь путем добавления экземпляров; храните состояние сессии во внешних системах (Memorystore for Redis, Firestore или Spanner). Пишите логи в stdout/stderr или в лог-файлы, собираемые агентом Cloud Logging.
- Утилизируемость (disposability): Быстрый запуск и остановка обеспечивают быстрое масштабирование и поэтапные обновления (rolling updates). Обрабатывайте сигнал SIGTERM для корректного завершения работы.
- Логи как потоки событий: Генерируйте структурированные логи; используйте Cloud Logging для сбора данных и Cloud Monitoring для оповещений.
Архитектурные компромиссы
- Монолит
  - Плюсы: Упрощенная разработка/тестирование, меньше сетевых границ, единая единица развертывания.
  - Минусы: Замедленная независимая поставка, ограничения масштабирования, сильная связанность между доменами.
  - Сценарии сбоев: Один нагруженный участок может исчерпать общие ресурсы; регрессии влияют на все функции.
- Модульный монолит
  - Плюсы: Четкие границы внутренних модулей, путь к рефакторингу в сторону сервисов, единый развертываемый артефакт.
  - Минусы: Все еще ограничен монолитным развертыванием и базой данных.
  - Использовать для команд, у которых доменные границы еще не устоялись, перед выделением сервисов.
- Микросервисы
  - Плюсы: Независимое развертывание, целевое масштабирование, автономность команд, изоляция сбоев при правильном использовании паттерна bulkhead (переборок).
  - Минусы: Сложность распределенных систем, согласованность, наблюдаемость и операционные издержки.
  - Сценарии сбоев: Каскадные сбои из-за синхронных вызовов; расхождение схем (schema drift); «болтливые» сети (chatty networks).
- Событийно-ориентированная архитектура (event-driven)
  - Плюсы: Слабая связанность, асинхронная отказоустойчивость, естественная буферизация, возможность аудита через логи/потоки.
  - Минусы: Сложность отладки, согласованность в конечном счете (eventual consistency), сложно обеспечить порядок и семантику «ровно один раз» (exactly-once).
  - Pub/Sub обеспечивает доставку «как минимум один раз» (at-least-once); проектируйте идемпотентные потребители.
- Бессерверные вычисления (Serverless) (Cloud Run, Cloud Functions, App Engine)
  - Плюсы: Минимальные операционные затраты, масштабирование до нуля, автомасштабирование на основе запросов, встроенная безопасность и телеметрия.
  - Минусы: Ограничения на время выполнения и параллелизм, холодные старты, ограничения, специфичные для платформы.
  - Использовать для неравномерных (пиковых) нагрузок, бэкендов для мобильных/веб-приложений и обработки событий.

Паттерны взаимодействия и выбор сервисов

Синхронные и асинхронные вызовы
- Синхронные
  - Используйте для API типа «запрос-ответ», требующих немедленного результата.
  - Протоколы: gRPC (HTTP/2, потоковая передача, компактный формат Protobuf; отлично подходит для мобильных устройств с ограниченной пропускной способностью и для строгих контрактов), HTTP/JSON (широкая совместимость; более простая отладка).
  - Риски: Сильная связанность и увеличение задержки; используйте тайм-ауты, повторные попытки с джиттером (jitter) и паттерн circuit breaker (прерыватель цепи).
- Асинхронные
  - Используйте Pub/Sub или Cloud Tasks, когда работа может быть отложена или сгруппирована в пакеты.
  - Преимущества: Сглаживает пики нагрузки, изолирует сбои, улучшает воспринимаемую пользователем задержку за счет выполнения в конечном итоге.
  - Риски: Требует идемпотентности и компенсирующих действий; необходимо реализовать видимость выполняемой работы.
Критерии выбора сервисов в Google Cloud
- Контроль и переносимость
  - Compute Engine: Полный контроль над ВМ и кастомные образы; более высокая операционная нагрузка.
  - GKE: Переносимые контейнеры и опции service mesh; надежное автомасштабирование; разделяемая ответственность.
  - Cloud Run: Высокая переносимость для контейнеров с минимальными операционными затратами; масштабирование до нуля; ориентирован на обработку запросов.
  - App Engine: «Самодостаточная» PaaS (opinionated) со встроенной маршрутизацией и масштабированием; самый быстрый путь для определенных языков.
- Масштаб и задержка
  - Global HTTP(S) Load Balancing с Cloud CDN для ускорения на границе сети (edge).
  - Хранилища данных:
    - Cloud Spanner: Глобальная согласованность, горизонтальное масштабирование, доступность 99,999% в нескольких регионах.
    - Cloud SQL: Управляемая реляционная БД, региональная, реплики чтения, в том числе межрегиональные.
    - Firestore: Документная БД с глобальной доступностью в нескольких регионах, строгая согласованность для отдельных документов.
    - Cloud Bigtable: Низкая задержка, массивное масштабирование для сценариев с широкими столбцами (wide-column).
    - Memorystore: Кэш с низкой задержкой для «горячих» путей и сессий.
- Операционная ответственность
  - Предпочитайте управляемые сервисы для решения ключевых задач (доступность, установка исправлений, резервное копирование, обновления).
  - Самостоятельное управление дает гибкость, но добавляет ручной работы и увеличивает поверхность отказа (например, самостоятельно развернутый Kafka в сравнении с Pub/Sub).
- Перемещение и интеграция данных
  - Используйте подключение через нативные средства VPC, Private Service Connect и внутренний HTTP(S) Load Balancing для приватного доступа с низкой задержкой.
  - Обнаружение сервисов (Service discovery): Имена Kubernetes Service внутри кластера; внутренний DNS Compute Engine для ВМ.

Пример Kubernetes Service (обнаружение по имени в кластере): apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

port: 80 targetPort: 8080 type: ClusterIP

Границы, совместимость и шаблоны обеспечения надежности

Границы доменов и владение
- Используйте предметно-ориентированное проектирование (DDD) для определения ограниченных контекстов. Каждый сервис владеет своими данными и публикует API/события в качестве контрактов.
- Избегайте использования общих баз данных для нескольких сервисов; используйте четко определенные интерфейсы и распространение событий.
- Владение подразумевает дежурства (on-call), SLO, частоту релизов и ответственность за бюджет для каждого сервиса.
Контракты API и обратная совместимость
- Явно версионируйте API (например, v1 в пути или заголовке). Предпочитайте аддитивные изменения; избегайте изменений, нарушающих работу полей или поведения.
- Используйте контрактное тестирование на стороне потребителя (consumer-driven contract tests) и канареечные релизы. Объявляйте компоненты устаревшими (deprecate) с указанием сроков и сбором телеметрии по их использованию.
- Для мобильных клиентов ожидайте «длинный хвост» старых версий; поддерживайте несколько версий API одновременно.
Изоляция сбоев и отказоустойчивость
- Переборки (Bulkheads): Изолируйте ресурсы по сервисам или классам приоритета (отдельные пулы узлов, группы инстансов, квоты). Предотвращайте ситуации, когда второстепенная функциональность (best-effort) исчерпывает ресурсы, необходимые для критически важных путей.
- Автоматические выключатели (Circuit breakers): Размыкайте цепь после серии последовательных сбоев при обращении к зависимости; сбрасывайте нагрузку и предоставляйте окно для восстановления. Реализуется через service mesh (например, Envoy), политики шлюза или библиотеки.
- Тайм-ауты и повторные попытки: Используйте усеченную экспоненциальную задержку с джиттером (truncated exponential backoff with jitter); обеспечивайте идемпотентность обработчиков.
- Планомерная деградация (Graceful degradation): При тайм-аутах опускайте некритичные компоненты UI; отдавайте кэшированные или приблизительные данные вместо ошибок.
- Проверки состояния (Health checks) и готовности (readiness probes): Направляйте трафик только на готовые к работе инстансы; используйте проверки жизнеспособности (liveness) для самовосстановления.

Пример усеченной экспоненциальной задержки (HTTP 429):

undefined

Глобальные и операционные аспекты

Мультирегиональные архитектуры для глобальных пользователей
- Глобальный фронтенд: используйте глобальную внешнюю балансировку нагрузки HTTP(S) с anycast IP-адресом и Cloud CDN для статического контента. Настройте негативное кеширование и валидацию для снижения нагрузки на origin-серверы.
- Уровень данных:
  - Для обеспечения доступности базы данных на уровне “пяти девяток” (99,999%) и минимизации задержки чтения в глобальном масштабе используйте мультирегиональный экземпляр Cloud Spanner (например, nam-asia-eur1) и выделите достаточное количество узлов для вычислений и кворума (минимум три узла для производственной среды).
  - Для сценариев с высокой нагрузкой на чтение без строгой глобальной согласованности рассмотрите вариант с региональным основным экземпляром и межрегиональными репликами чтения; при этом будьте готовы к более высокой задержке записи между континентами.
- Уровень приложений:
  - Развертывайте сервисы без состояния (stateless) в нескольких регионах с автомасштабированием (GKE или Cloud Run). Используйте backend-сервисы и группы сетевых конечных точек (network endpoint groups) для каждого региона.
  - Маршрутизируйте трафик по наименьшей задержке, соблюдая при этом требования к резидентности данных и нормативные ограничения.
- Кеши: размещайте Memorystore или пограничные кеши (edge caches) ближе к пользователям, чтобы поглощать трафик чтения и защищать origin-серверы.
Управляемые и самоуправляемые решения
- Используйте Cloud Monitoring для метрик, Cloud Logging для логов, Cloud Trace/Profiler для выявления “хвостовых” задержек и узких мест в CPU/памяти. Создайте политики оповещения для скорости сгорания бюджета ошибок SLO и проверки доступности (uptime checks) для внешней доступности.
- Если существующая платформа наблюдаемости (observability) должна оставаться основной системой учёта, сначала принимайте данные в Cloud Logging для оповещений с низкой задержкой, а затем экспортируйте их через приёмники (sinks) на внешнюю платформу.
Модернизация и инкрементальная миграция
- Паттерн “Удушитель” (Strangler): разместите шлюз перед монолитом; маршрутизируйте определенные эндпоинты на новые сервисы. Постепенно заменяйте функциональность.
- Ветвление через абстракцию (Branch by abstraction): введите интерфейс вокруг зависимости и меняйте реализацию за ним (например, базу данных или хранилище).
- Слой-посредник (Anti-corruption layer): преобразуйте данные между устаревшими моделями данных и новыми ограниченными контекстами (bounded contexts).
- Миграция данных: используйте двойную запись с верификацией или источники событий (event sourcing) для заполнения данных; планируйте переключение с механизмами контроля обратного давления (backpressure).
- Поэтапное внедрение: заменяйте функциональность поэтапно, чтобы минимизировать бизнес-риски; постоянно измеряйте SLO.
Анализ архитектуры и оценка компромиссов
- Безопасность: моделирование угроз, принцип наименьших привилегий в IAM, использование сервисных аккаунтов вместо встроенных ключей (используйте Application Default Credentials на GCE/GKE/Cloud Run), CMEK где требуется, приватное подключение, WAF и ограничение частоты запросов (rate limits), сканирование на уязвимости и веб-безопасность.
- Надежность: определение SLO и бюджетов ошибок, планы мультирегионального аварийного переключения, запас производительности, учения по хаос-инжинирингу, карты зависимостей.
- Производительность: анализ “хвостовой” задержки (tail latency), нагрузочное тестирование на периметре и на origin-серверах, повторное использование соединений (HTTP/2, gRPC), сжатие, стратегия кеширования.
- Стоимость: оптимизация размеров ресурсов, политики автомасштабирования, скидки за гарантированное использование (committed use discounts), масштабирование до нуля для пиковых нагрузок, исходящий трафик и разгрузка через CDN.
- Эксплуатация: ранбуки (runbooks), откаты, постепенное развертывание (canary, blue/green), политики как код (policy as code), тесты резервного копирования и аварийного восстановления (DR), интеграция с процессами реагирования на инциденты.

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

Компания Nimbus Retail запускает глобальную e-commerce платформу с персонализированными изображениями, строгими целевыми показателями задержки менее 200 мс на уровне p95 по всему миру и требованием к доступности базы данных заказов 99,999%. Они также должны сохранить свою существующую SIEM-систему, улучшив при этом скорость оповещений.

Создание глобальной, высокодоступной базы данных с помощью Cloud Spanner

Действие: создать мультирегиональный экземпляр Spanner в nam-asia-eur1 как минимум с тремя узлами и разделить таблицы, используя подходящие чередующиеся (interleaved) схемы для локальности данных.
Обоснование: мультирегиональный Spanner обеспечивает доступность на уровне “пяти девяток” и низкую задержку чтения благодаря репликам на трех континентах; три или более узла гарантируют достаточную вычислительную мощность и кворум реплик.

Пример:

undefined

Глобальное развертывание фронтенда и API

Действие: использовать глобальную внешнюю балансировку нагрузки HTTP(S) с Cloud CDN для статических ресурсов и динамической маршрутизации на региональные бэкенды (сервисы GKE в us-central1, europe-west1, asia-east1).
Обоснование: Anycast VIP минимизирует RTT; CDN кеширует изображения рядом с пользователями; backend-сервисы распределяют запросы в ближайший работоспособный регион.

Сервисы без состояния на GKE с внутрикластерным обнаружением

Действие: развернуть сервисы для изменения размера изображений и API на GKE с горизонтальным автомасштабированием подов и сервисами типа ClusterIP для доступа по именам внутри кластера; открыть публичные эндпоинты через Ingress.
Обоснование: поды без состояния позволяют эластично масштабироваться; Kubernetes Service абстрагирует IP-адреса подов и предоставляет стабильный DNS, уменьшая связанность клиентов.

Событийно-ориентированная обработка изображений

Действие: публиковать задачи по обработке изображений в Pub/Sub; запускать сервисы Cloud Run, подписанные через push-уведомления, для обработки объектов, хранящихся в Cloud Storage. Реализовать усеченную экспоненциальную задержку с джиттером (truncated exponential backoff with jitter) при ответах GCS 429/5xx.
Обоснование: Pub/Sub сглаживает пики нагрузки и изолирует сбои; Cloud Run масштабируется на каждое сообщение; экспоненциальная задержка снижает лавинообразное нарастание ошибок и помогает бакетам “прогреваться” постепенно.

Наблюдаемость и быстрые оповещения

Действие: использовать Cloud Logging и Cloud Monitoring для сбора логов и метрик, определить проверки доступности (uptime checks) для API и создать политики оповещения по частоте ошибок и задержке. Настроить приёмник логов (log sink) для экспорта в существующую SIEM-систему.
Обоснование: нативная телеметрия обеспечивает оповещения с низкой задержкой и управляемые проверки доступности; экспорт сохраняет централизованную SIEM-систему без ущерба для скорости оповещений.

Внешнее хранение конфигурации и секретов

Действие: хранить несекретную конфигурацию в ConfigMaps; секреты и ключи API — в Secret Manager с использованием Workload Identity для GKE. Для любых заданий на базе Compute Engine использовать метаданные экземпляра для значений, специфичных для развертывания.
Обоснование: внешняя конфигурация позволяет использовать неизменяемые образы и настройки для конкретной среды; позволяет избежать встраивания секретов; метаданные поддерживают вариативность ВМ без изменения кода.

Изоляция сбоев и плавная деградация

Действие: применить “переборки” (bulkheads) с отдельными пулами узлов для нагрузок по персонализации, выполняемых по мере возможности (best-effort); установить бюджеты запросов и прерыватели цепи (circuit breakers) для сервисов персонализации. В пользовательском интерфейсе скрывать некритичные виджеты при тайм-аутах зависимостей.
Обоснование: изоляция ресурсов предотвращает ситуацию, когда второстепенные функции “отбирают” ресурсы у процесса оформления заказа; прерыватели цепи ограничивают радиус поражения (blast radius); плавная деградация сохраняет ключевые пользовательские сценарии.

Контракты API и совместимость

Действие: определить контракты gRPC для мобильных клиентов (v1) с транскодированием в HTTP/JSON для веба; применять аддитивные изменения и поддерживать как минимум две версии во время развертывания для мобильных устройств.
Обоснование: gRPC уменьшает использование полосы пропускания и обеспечивает строгую типизацию; транскодирование упрощает интеграцию с браузерами и партнерами; версионирование сохраняет обратную совместимость.

Безопасность и идентификация

Действие: использовать отдельные сервисные аккаунты Google для каждого сервиса с наименьшими привилегиями IAM; полагаться на Application Default Credentials. Включить Cloud Armor для защиты на периметре сети и принудительно использовать TLS повсеместно.
Обоснование: Workload Identity устраняет риски, связанные с управлением ключами; WAF и ограничение частоты запросов смягчают последствия злоупотреблений; шифрование при передаче является стандартом и обязательным.

Непрерывная поставка и безопасность релизов

Действие: внедрить канареечные релизы с разделением трафика в процентном соотношении на уровне балансировщика нагрузки и автоматическим откатом при оповещениях о сгорании бюджета ошибок SLO. Поддерживать среды blue/green в каждом регионе.
Обоснование: постепенное развертывание ограничивает риски; региональные среды blue/green ускоряют откат и позволяют безопасно проводить миграции схемы в соответствии с версиями API.

Все домены · Вычислительные ресурсы →

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