Google PCD: Производительность, масштабируемость и инженерия отказоустойчивости — Руководство по подготовке

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

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

Обзор

Проектирование производительности, масштабируемости и отказоустойчивости в Google Cloud направлено на поддержание низкой задержки и экономической эффективности сервиса при переменной нагрузке, а также на устойчивость к сбоям без нарушения SLO. Архитектура должна согласовывать сигналы автомасштабирования с характеристиками рабочей нагрузки, размещать данные и вычислительные ресурсы для минимизации хвостовой задержки, а также реализовывать механизмы контроля перегрузки, повторных попыток и аварийного переключения во избежание каскадных сбоев. В этом разделе подробно рассматриваются шаблоны, механизмы контроля и компромиссы, важные для разработчиков приложений на уровнях вычислений, сети и данных.

Масштабирование и распределение нагрузки

Горизонтальное и вертикальное масштабирование

Горизонтальное масштабирование добавляет экземпляры или поды для увеличения мощности и отказоустойчивости. Предпочтительно для сервисов без состояния (stateless) и когда требуется быстрая эластичность. Используйте Managed Instance Groups (MIGs), ревизии Cloud Run или GKE Deployments.
Вертикальное масштабирование увеличивает размер машины. Полезно для однопоточных или ограниченных по памяти рабочих нагрузок, а также для уменьшения меж-узловой координации, но предлагает ограниченный запас производительности и более длительное время перезапуска.
Параллелизм (Concurrency): Настраивайте параллелизм обработки запросов в соответствии с профилем нагрузки: ограниченной CPU или вводом-выводом (I/O). Cloud Run поддерживает настройку параллелизма для каждой ревизии; поды GKE могут обслуживать несколько запросов, если ваша среда выполнения неблокирующая; для строгой изоляции установите параллелизм равным 1.

Сигналы автомасштабирования и прогретый резерв (warm capacity)

Автомасштабирование в MIG поддерживает утилизацию CPU, утилизацию балансировщика нагрузки и пользовательские метрики через Cloud Monitoring. При всплесках трафика основывайте масштабирование на метриках запросов (rps, глубина очереди), а не на CPU.
GKE Horizontal Pod Autoscaler (HPA) может масштабироваться по CPU, памяти или пользовательским/внешним метрикам (например, длина очереди Pub/Sub). Используйте Vertical Pod Autoscaler (VPA) для подбора оптимального размера (right-sizing), но избегайте «живых» обновлений VPA на быстро масштабируемых фронтендах, чтобы предотвратить постоянные изменения (churn).
Cloud Run масштабируется по нагрузке одновременных запросов и, опционально, по пользовательским метрикам. Избегайте холодных стартов, поддерживая прогретый резерв: настройте минимальное количество экземпляров, поддерживайте низкий параллелизм в режиме ожидания и при необходимости выполняйте предварительный прогрев с помощью синтетических проверок работоспособности.
Предиктивное автомасштабирование в MIG и установка min replicas в Deployment/Revision помогают скрыть задержку предоставления ресурсов во время суточных пиков.

Балансировка нагрузки, глобальное распределение трафика, проверки работоспособности и аварийное переключение

Используйте глобальный внешний Application Load Balancer для всемирного anycast VIP, HTTP/2 и HTTP/3, а также для терминирования на границе сети с помощью Cloud CDN. Бэкендами могут быть группы экземпляров, зональные/региональные NEG, бессерверные NEG (Cloud Run/Functions) или GKE Ingress.
Проверки работоспособности отводят трафик от неработоспособных бэкендов. Убедитесь, что ваши эндпоинты для проверок работоспособности проверяют зависимости точечно (например, процесс и критически важные локальные ресурсы), чтобы избежать циклических сбоев при отказах нижестоящих сервисов.
Списки разрешений брандмауэра должны пропускать трафик от систем проверки работоспособности. Если проверки на порт 80 не проходят, разрешите диапазоны Google: gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Аварийное переключение: Настройте основные/резервные бэкенд-сервисы или политики трафика, которые направляют трафик в альтернативные регионы при сбое проверок работоспособности. Для аварийного переключения на уровне DNS используйте политики Cloud DNS с проверками работоспособности для эндпоинтов, не использующих HTTP.

Задержка и эффективность

Бюджеты задержки

Выделяйте сквозной бюджет задержки для каждого уровня (клиент, граница сети, приложение, данные). Отслеживайте p95/p99, а не средние значения. Используйте Cloud Trace для поиска факторов, влияющих на задержку между сервисами, и блокировки начала очереди (head-of-line blocking). Применяйте дедлайны к вызовам RPC, чтобы отмена запроса вышестоящим сервисом освобождала ресурсы.

Использование кэширования и CDN

Многоуровневое кэширование: кэш клиента/браузера, кэш на границе сети (Cloud CDN) и региональные/внутрипроцессные кэши (Memorystore или в памяти процесса). Тщательно выбирайте ключи кэширования и заголовки Vary. Устанавливайте TTL в зависимости от свежести данных и риска использования устаревших данных; рассмотрите возможность негативного кэширования для ответов 404, когда это безопасно.
Раздавайте статические ресурсы из Cloud Storage через Cloud CDN, чтобы снизить нагрузку на источник (origin) и хвостовую задержку. Используйте подписанные URL/заголовки для контролируемого доступа.

Переиспользование соединений

Предпочитайте HTTP/2 или gRPC для мультиплексирования и сжатия заголовков. Включайте keep-alives и пулы соединений, чтобы уменьшить накладные расходы на установку соединения (handshake). Следите за исчерпанием портов NAT; настраивайте пулы клиентских соединений и тайм-ауты простоя, а также, если применимо, выделяйте необходимое количество портов Cloud NAT для каждой ВМ.

Эффективность полезной нагрузки (payload)

Используйте бинарные форматы кодирования (например, protobuf) и сжимайте текстовые данные (gzip/brotli) при превышении определенного порога размера. Тщательно проектируйте поля запросов/ответов; используйте пагинацию, фильтрацию на стороне сервера и избегайте избыточной выборки данных. Используйте ETags и условные запросы (If-None-Match), чтобы избежать избыточной передачи данных. Для Cloud Storage используйте условия на основе поколения (generation preconditions) и чтение диапазонов (Range reads) для получения частичного контента.

Паттерны для защиты от перегрузок и повышения отказоустойчивости

Ограничение скорости, обратное давление, очереди и пакетирование

Применяйте ограничение скорости на периметре (Cloud Armor для ограничения по IP/гео/сервису) и на уровне API (квоты Apigee, токены для каждого клиента API). Реализуйте на стороне сервера алгоритмы token bucket («ведро с токенами») или leaky bucket («дырявое ведро») для справедливого распределения ресурсов.
Обратное давление (backpressure): не опережайте нижестоящие системы (downstreams). Используйте очереди (Pub/Sub для доставки событий по принципу at-least-once; Cloud Tasks для регулирования скорости для каждой очереди и цели с планированием и повторными попытками). Передавайте клиентам ошибки 429 Too Many Requests или 503 с заголовком Retry-After, чтобы оказать на них обратное давление.
Пакетирование может увеличить пропускную способность и снизить накладные расходы на каждый вызов (например, пакетные изменения в базах данных или пакетные подтверждения в Pub/Sub), обменивая возросшую задержку на эффективность. Настраивайте размер пакета и максимальное время ожидания.

Защита от перегрузок

Применяйте тайм-ауты и дедлайны к каждому вызову RPC. Используйте прерыватели цепи (circuit breakers), чтобы прекратить отправку запросов к сбоящим зависимостям и обеспечить быстрое переключение на резервные сценарии (fallback). Реализуйте сброс нагрузки (load shedding) на основе глубины очереди, загрузки ЦП или нарушения SLO по задержке для защиты основной функциональности.

Отказоустойчивые повторные попытки, экспоненциальная выдержка, джиттер, идемпотентность и обработка дубликатов

Повторяйте запросы, только когда это безопасно: при сетевых тайм-аутах, ошибках 5xx или при получении документированных кодов, допускающих повтор (например, 429/5xx для Cloud Storage). Никогда не повторяйте запросы при ошибках 4xx, таких как 400/401/403, если иное не указано в документации.
Используйте усеченную экспоненциальную выдержку (truncated exponential backoff) с джиттером, чтобы избежать синхронизированных повторных попыток. Предпочтительно использовать полный джиттер (full jitter). Пример:

undefined

Обеспечивайте идемпотентность. Используйте ключи идемпотентности (например, уникальный ID операции) и операции upsert или условные записи для обработки дубликатов. В Pub/Sub дедуплицируйте сообщения, используя messageId или ключи на уровне приложения; проектируйте обработчики так, чтобы они были безопасны для семантики доставки at-least-once. При записи в Cloud Storage используйте предусловия generation-match, чтобы избежать перезаписи данных.

Прогрев неактивных ресурсов

Некоторые сервисы применяют адаптивные лимиты. Для Cloud Storage постепенно наращивайте частоту запросов к ранее неактивным бакетам, чтобы уменьшить количество временных ошибок 429/5xx во время внезапных всплесков нагрузки. Ограничивайте отправителей (producers) и «прогревайте» бакеты контролируемым трафиком перед подачей полной нагрузки.

Высокая доступность, данные, аварийное восстановление и тестирование

Мультизональность, региональность, мультирегиональность; active-active и active-passive

Развертывайте инфраструктуру в разных доменах отказа. Используйте региональные MIG или региональные кластеры GKE для отказоустойчивости на уровне зон. Для глобальных сервисов используйте несколько регионов с глобальным балансировщиком нагрузки.
Конфигурация active-active снижает RTO и задержку, но требует бесконфликтных данных и тщательного управления согласованностью. Конфигурация active-passive упрощает семантику записи, но влечет за собой более высокое RTO и потенциальное наличие «холодных» мощностей.

RTO, RPO, резервное копирование, восстановление и тестирование аварийного восстановления

Определите RTO (время восстановления сервиса) и RPO (допустимый объем потерь данных) для каждой рабочей нагрузки. Соотнесите их с возможностями платформы:
- Cloud Spanner: мультирегиональная конфигурация с доступностью «пять девяток» и синхронной репликацией для почти нулевого RPO.
- Cloud SQL: высокая доступность в пределах региона; используйте межрегиональные реплики для аварийного восстановления, включите PITR и проверяйте сценарии отработки отказа и восстановления.
- Firestore и Bigtable предлагают региональные и мультирегиональные варианты; выбирайте в соответствии с требованиями RTO/RPO.
- Баскеты Cloud Storage с двойным или мультирегиональным размещением обеспечивают географическую избыточность; проверяйте процедуры восстановления и перевыпуск подписанных URL-адресов.
Тестирование аварийного восстановления: Регулярно проводите учения по отработке отказа. Проверяйте резервные копии, восстанавливая их в изолированной среде, репетируйте переключение DNS/трафика и измеряйте фактические RTO/RPO.

Производительность баз данных и хранилищ, проектирование индексов, хотспоты и конфликты

Cloud Spanner: Избегайте монотонно возрастающих первичных ключей, которые создают хотспоты. Используйте чередующиеся таблицы (interleaved tables) для локальности данных, вторичные индексы для паттернов чтения и ограниченные транзакции (bounded transactions) для уменьшения конфликтов блокировок. Подбирайте размер узлов под QPS и объем хранения; для производственной среды держите не менее трех узлов для кворума и запаса производительности.
Cloud SQL: Анализируйте запросы, добавляйте покрывающие индексы, избегайте долгих транзакций и используйте пулы соединений. Разумно настраивайте параметры InnoDB или Postgres; масштабируйте реплики чтения для рабочих нагрузок с интенсивным чтением.
Bigtable: Проектируйте ключи строк так, чтобы равномерно распределять нагрузку (используя «соление» или реверсирование полей). Используйте мультикластерную маршрутизацию для высокой доступности между регионами, если она доступна.
Firestore: Используйте составные индексы для запросов по нескольким полям; помните о хотспотах при большом количестве записей в один и тот же путь документа.
Cloud Storage: Строгая согласованность при чтении после записи для новых объектов; используйте параллельные загрузки и разбивку на части для увеличения пропускной способности. Постепенно увеличивайте трафик на неактивные бакеты; для «горячих» чтений предпочитайте пограничные узлы CDN. Если многим ВМ нужен один и тот же большой набор данных только для чтения, подключите постоянный диск в режиме «только для чтения» к нескольким инстансам для быстрого локального доступа по низкой цене.

Нагрузочные тесты, хаос-инжиниринг, внедрение сбоев и планирование мощностей

Нагрузочное тестирование: Симулируйте реалистичные профили трафика и распределения данных. «Прогревайте» кэши и автомасштабаторы; тестируйте задержку p95/p99 под нагрузкой и во время событий масштабирования. Зеркалируйте небольшую часть реального трафика на теневые стеки для проверки поведения в условиях производственной сложности.
Хаос-инжиниринг и внедрение сбоев: Уничтожайте поды/ВМ, изолируйте зону (cordon), вносите задержки/ошибки на уровне service mesh (например, Envoy/Istio), чтобы наблюдать за радиусом поражения и устойчивостью. Проверяйте, что автоматические выключатели (circuit breakers) и повторные попытки ведут себя как положено.
Планирование мощностей: Прогнозируйте на основе исторических данных о спросе и запланированных событий. Поддерживайте запас мощностей для сбоев N+1 и ребалансировки. Согласуйте периоды охлаждения и максимальные скорости автомасштабаторов с ожидаемыми всплесками; заранее выделяйте ресурсы во время предсказуемых пиков.

Компромиссы в доступности между управляемыми сервисами и кастомными архитектурами

Вычислительные ресурсы: Cloud Run предлагает быстрое масштабирование до нуля и низкие операционные издержки, но имеет холодные старты и ограничения по одновременной обработке запросов. GKE предоставляет тонкий контроль и переносимость при более высоких операционных затратах. Виртуальные машины Compute Engine обеспечивают максимальный контроль с наибольшей операционной нагрузкой.
Данные: Cloud Spanner обеспечивает глобальную согласованность и высокую доступность при более высокой стоимости и строгих требованиях к схеме. Cloud SQL подходит для традиционных СУБД с более простым управлением, но ограниченной высокой доступностью/масштабируемостью. Bigtable превосходен для низколатентных, крупномасштабных хранилищ типа «ключ-значение»/временных рядов. Firestore предоставляет гибкие схемы с сильной согласованностью и глобальными опциями.
Сеть: Глобальные балансировщики нагрузки и Cloud CDN обладают высокой доступностью и работают на пограничных узлах Google; самодельные прокси предлагают кастомизацию, но создают операционные риски и риски сбоев.
Предпочитайте управляемые сервисы для более высокой базовой доступности и устойчивости к DDoS-атакам, но учитывайте в своем дизайне квоты, холодные старты и специфическую семантику сервисов.

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

NimbusMart, глобальная компания в сфере электронной коммерции, нуждается в API каталога товаров с низкой задержкой, доступностью «пять девяток» и минимальной задержкой чтения для пользователей в Северной Америке, Европе и Азиатско-Тихоокеанском регионе. Записи должны быть глобально согласованными. Трафик имеет пиковый характер во время флеш-распродаж, а прошлые инциденты включали каскадные повторные попытки и перегрузку источника.

Подход:

Подготовить мультирегиональный инстанс Cloud Spanner, используя конфигурацию nam-asia-eur1, с как минимум тремя узлами.

Обоснование: Обеспечивает глобально согласованные операции чтения/записи с доступностью «пять девяток» и размещает реплики рядом с пользователями для снижения задержки чтения. Минимум три узла обеспечивают надежность кворума и запас производительности для ребалансировки.

Реализовать stateless-слой API в нескольких регионах за глобальным внешним Application Load Balancer.

Обоснование: Anycast VIP и глобальная маршрутизация сокращают время установки соединения и направляют пользователей в ближайший работоспособный регион. Сервисы без сохранения состояния (stateless) упрощают горизонтальное масштабирование и отработку отказа.

Настроить проверки работоспособности и правила брандмауэра для доступности балансировщика нагрузки.

Обоснование: Проверки работоспособности предотвращают маршрутизацию на неработоспособные бэкенды. Разрешите диапазоны IP-адресов проверок работоспособности Google, чтобы проверки проходили успешно:

undefined

Реализовать автомасштабирование на основе метрик запросов с «прогретыми» мощностями.

Обоснование: Масштабируйте MIG или GKE HPA на основе QPS/задержки, а не CPU, чтобы реагировать на трафик флеш-распродаж. Поддерживайте минимальное количество реплик в каждом регионе, чтобы избежать холодных стартов, и включите предиктивное автомасштабирование перед известными событиями.

Добавить Cloud CDN для статического медиаконтента товаров, хранящегося в Cloud Storage.

Обоснование: Кэширование на пограничных узлах снимает нагрузку с источника, снижает хвостовую задержку и смягчает усиление всплесков на уровне приложения и хранилища. Используйте подписанные URL-адреса и соответствующие ключи кэширования/TTL.

Внедрить защиту от перегрузки и ограничение частоты запросов на пограничном уровне и в сервисе.

Обоснование: Настройте ограничения частоты в Cloud Armor для поглощения аномальных всплесков. В сервисе используйте ограничения по методу «ведра с токенами» для каждого клиента и отбрасывайте низкоприоритетные запросы при угрозе нарушения SLO по задержке. Применяйте дедлайны к каждому вызову нижестоящих сервисов.

Использовать отказоустойчивые повторные попытки с усеченной экспоненциальной задержкой и полным джиттером; обеспечить идемпотентность с помощью идентификаторов операций.

Обоснование: Предотвращает эффект «ревущего стада» (thundering herd) и дублирование записей во время частичных сбоев. Ключи идемпотентности обеспечивают безопасные повторные выполнения; для операций с хранилищем используйте условные предварительные проверки (conditional preconditions).

Внедрить очередь записи для сглаживания всплесков и асинхронности там, где это приемлемо.

Обоснование: Pub/Sub буферизует внезапные всплески некритичных записей (например, события аналитики), отделяя производителей от Spanner и защищая основные пути записи от перегрузки.

Определить SLO и бюджеты задержки; внедрить трассировку и дашборды.

Обоснование: Бюджеты для каждого уровня служат ориентиром для оптимизации. SLO в Cloud Monitoring с бюджетами ошибок и Cloud Trace выявляют факторы, влияющие на задержку p99 на межрегиональном уровне и на уровне данных.

Разработать сценарии аварийного восстановления и протестировать отработку отказа.

Обоснование: С мультирегиональным Spanner и мультирегиональными вычислительными ресурсами практикуйте учения по эвакуации региона. Проверяйте RTO с помощью временных шкал отвода и наращивания трафика и убедитесь, что автомасштабаторы и CDN ведут себя корректно во время отработки отказа.

Этот дизайн удовлетворяет целям глобальной доступности и низкой задержки за счет согласования топологии вычислительных ресурсов и данных, применения контроля перегрузок и использования управляемых сервисов, которые обеспечивают проверенную масштабируемость и отказоустойчивость.

← Наблюдаемость · Все домены · Тестирование →

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