Google PCD: Стоимость, управление и устойчивая эксплуатация приложений — Руководство по подготовке

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

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

Обзор

Управление затратами, контроль и устойчивость операций неразрывно связаны в современной разработке приложений в Google Cloud. Цель — обеспечить прозрачность и контроль расходов, проектировать сервисы, которые масштабируются экономично, и внедрять защитные механизмы, поддерживающие безопасность, соответствие требованиям и чистоту сред, — при этом сохраняя баланс между производительностью и надёжностью. В этом разделе подробно рассматриваются практические механизмы (биллинг и метки, параметры автомасштабирования, квоты и политики), экономика для конкретных рабочих нагрузок (Cloud Run, GKE, платформы данных) и подходы, ориентированные на устойчивое развитие, которые сокращают избыточные простои и углеродный след без ущерба для пользовательского опыта.

Контроль и прозрачность затрат

• Платёжные аккаунты, метки, распределение затрат, бюджеты, оповещения и прозрачность
  • Используйте отдельный платёжный аккаунт для каждого бизнес-подразделения или источника финансирования, чтобы разграничить ответственность и настроить гранулярные разрешения. Экспортируйте данные биллинга в BigQuery для детального анализа, прогнозирования и возмещения затрат.
  • Метки — это пары «ключ-значение» на ресурсах для атрибуции затрат. Стандартизируйте ключи меток (team, app, env, cost-center) и обеспечивайте их применение с помощью политик организации и проверок в CI. Важно: метки не применяются ретроактивно; ресурсы без меток искажают отчёты.
  • Используйте бюджеты и оповещения на уровне платёжного аккаунта и проекта. Комбинируйте пороговые значения (например, 50, 90, 100 процентов) и триггеры на основе прогнозов. Направляйте уведомления о бюджете в Pub/Sub и пересылайте их в инструменты Chat/Ops. Бюджеты только оповещают, но не применяют ограничений.
  • Для общих платформ (например, GKE, BigQuery) используйте метки на уровне неймспейсов или заданий и прикрепляйте их к логам и данным об использовании, чтобы обеспечить возможность внутренней отчётности (showback) и возмещения затрат (chargeback).

Пример: добавление меток

undefined

• Квоты, лимиты, прогнозирование потребления и управление ёмкостью
  • Квоты защищают сервисы и ограничивают неконтролируемый рост затрат. Регулярно пересматривайте квоты сервисов, подбирайте их размер для каждого проекта и запрашивайте увеличение заблаговременно до запусков. Внедряйте проверки перед развёртыванием, которые сравнивают ожидаемое пиковое использование с квотами.
  • Прогнозируйте расходы, используя экспорт данных биллинга и телеметрию использования продуктов (метрики Cloud Monitoring, метрики на основе логов). Моделируйте сценарии (ожидаемое количество запросов в секунду (QPS), объём сканируемых данных) и проверяйте их в предпромышленной среде.
  • Сценарии сбоев: достижение квоты в разгар инцидента или запуска продукта приводит к троттлингу (ограничению запросов, 429/403), частичным сбоям или скрытой деградации производительности. Избыточно выделенные квоты увеличивают радиус поражения (blast radius) при сбое заданий.

Пример: просмотр квот Compute Engine

undefined

Управление затратами на данные, аналитику и сеть

• Классы хранения, управление жизненным циклом, масштабирование баз данных и проектирование исходящего сетевого трафика
  • Выбирайте классы Cloud Storage в зависимости от характера доступа: Standard для «горячих» данных; Nearline, Coldline или Archive для более «холодных» данных. Помните о плате за извлечение и минимальных сроках хранения для «холодных» уровней.
  • Правила жизненного цикла автоматизируют перемещение и удаление данных. Используйте dual-region для отказоустойчивости, если задержка multi-region приемлема; размещайте вычислительные ресурсы и данные в одном месте, чтобы сократить исходящий трафик и задержку.
  • Масштабирование баз данных:
    • Cloud SQL: выполняйте вертикальное масштабирование с осторожностью; используйте реплики чтения для операций чтения; автомасштабирование хранилища; используйте планы запросов и пулы соединений. Высокая пропускная способность записи может потребовать шардирования или перехода на Spanner/Bigtable.
    • Spanner: горизонтальное масштабирование путем добавления узлов; конфигурации multi-region для доступности и глобальных операций чтения; проектируйте схемы и ключи для сбалансированной нагрузки.
    • Bigtable: проектируйте ключи строк так, чтобы избежать «горячих точек» (hotspots); масштабируйте узлы кластера и хранилище независимо друг от друга.
  • Исходящий сетевой трафик (egress): избегайте трафика между регионами; по возможности размещайте клиентов и данные в одном регионе. Используйте Cloud CDN для контента интернет-масштаба, Cloud Interconnect/Peering для гибридных сред, а также Private Google Access или Private Service Connect для частного доступа к Google API. Ненужный трафик между зонами/регионами увеличивает затраты и задержку.

Пример: жизненный цикл Cloud Storage

undefined

• Управление запросами BigQuery, хранением данных и стоимостью использования аналитики
  • Контролируйте объем сканируемых байт: всегда фильтруйте по ключам секционирования/кластеризации; избегайте SELECT *; используйте материализованные представления и кеширование результатов для повторяющихся запросов; по возможности используйте приблизительные агрегации.
  • Ограничивайте стоимость сканирования с помощью параметра maximum bytes billed и устанавливайте приоритет batch для несрочных заданий, чтобы уменьшить взаимное влияние и затраты.
  • Выбирайте модель ценообразования: on-demand для спорадических нагрузок; резервирования (слоты) с обязательствами для стабильных высокообъемных нагрузок. Используйте отдельные резервирования и назначения для изоляции команд.
  • Хранение данных: устанавливайте срок хранения для наборов данных/таблиц и секций в целях управления; внедряйте многоуровневое хранение или экспорт для архивации.
  • Сценарии сбоев: большие несекционированные таблицы приводят к взрывному росту затрат; запросы без фильтров по секциям сканируют таблицы целиком; слишком агрессивные сроки хранения приводят к удалению нужных данных; чрезмерная борьба за слоты ухудшает SLA.

Пример: ограничение стоимости запроса

undefined

Организационное управление и гигиена сред

• Политики организации, именование ресурсов, присвоение тегов и разделение проектов

  • Используйте политики организации для установки защитных ограничений: ограничивайте местоположение ресурсов, запрещайте внешние IP-адреса, требуйте использования CMEK, ограничивайте разрешённые сервисы, контролируйте пиринг VPC и предписывайте использование OS Login, где это необходимо. Применяйте на уровне организации или папки с исключениями, смоделированными через иерархию.
  • Стандартизируйте именование ресурсов для кодирования среды, проекта, приложения и региона (например, app-env-region-suffix). Обеспечивайте соблюдение через проверки в CI или с помощью «политик как код» (policy-as-code).
  • Различайте:
    • Метки (Labels): для атрибуции в биллинге/операционной деятельности.
    • Теги (Tags) (первоклассные объекты): прикрепляются к ресурсам и используются в условиях IAM и для таргетинга политик организации.
    • Сетевые теги (Network tags): для правил брандмауэра в Compute Engine.
  • Разделение проектов: изолируйте среды (prod, staging, dev) и чувствительные рабочие нагрузки. Используйте Shared VPC для централизованного управления сетью и сервисные проекты с минимальными привилегиями. Это уменьшает радиус поражения и упрощает IAM.

• Жизненный цикл сред, эфемерные тестовые среды и автоматизация очистки

  • Разворачивайте среды с помощью IaC (Terraform) и создавайте эфемерные среды для каждого pull request. Устанавливайте метки TTL и автоматический демонтаж после слияния или периода неактивности.
  • Используйте Cloud Scheduler в связке с заданиями Cloud Run или Functions для поиска и удаления устаревших ресурсов по меткам/возрасту. Экспортируйте инвентарные данные через Cloud Asset Inventory для проведения аудитов.
  • Сценарии сбоев: заброшенные «песочницы» влекут за собой расходы; отсутствие TTL или меток мешает очистке; слишком агрессивная очистка может удалить активные ресурсы — добавляйте списки разрешений и льготные периоды.

• Архитектура с учётом принципов устойчивого развития и баланс между стоимостью, производительностью и надёжностью

  • Отдавайте предпочтение управляемым и бессерверным сервисам, чтобы сократить время простоя и улучшить утилизацию ресурсов.
  • Выбирайте регионы с меньшей углеродоёмкостью, если это соответствует требованиям; планируйте пакетные рабочие нагрузки на периоды с более высоким уровнем доступности безуглеродной энергии, когда это возможно.
  • Оптимизируйте «гравитацию данных» и кэширование для снижения энергопотребления сети. Настраивайте автомасштабирование и параллелизм для уменьшения недоиспользования ресурсов. Используйте профилирование для удаления расточительных участков кода, которые вызывают избыточные вычисления или операции ввода-вывода.
  • Баланс: добавляйте минимальное количество инстансов или реплик только там, где этого требуют SLO; оценивайте хвостовую задержку в сравнении с параллелизмом и избыточность в сравнении с использованием Spot-инстансов. Проверяйте с помощью нагрузочного тестирования на основе SLO и моделирования затрат/производительности.

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

NimbusMarket, компания в сфере электронной коммерции, сталкивается со скачкообразным трафиком во время мгновенных распродаж и ростом расходов на аналитику. API для клиентов работают на Cloud Run, фоновые обработчики — на GKE, а аналитика продуктов — в BigQuery. Руководство требует сократить расходы на 25 процентов без ущерба для SLO API в 99,9 процента.

Подход:

1. Обеспечение прозрачности затрат и установка защитных ограничений

   • Создайте бюджеты с оповещениями о прогнозируемых расходах при достижении 60, 90 и 100 процентов для биллингового аккаунта, с уведомлениями через Pub/Sub, направляемыми дежурной команде.
   • Стандартизируйте метки (team, app, env, cost-center) и обеспечьте их применение через CI для планов Terraform; добавьте политику организации, которая ограничивает размещение ресурсов только в утверждённых регионах. Обоснование: Бюджеты обеспечивают раннее предупреждение; метки позволяют создавать отчёты по командам; политики предотвращают случайное использование регионов с высоким исходящим трафиком и улучшают соответствие требованиям.

2. Настройка Cloud Run для экономичного масштабирования

   • Установите containerConcurrency равным 40 для stateless API после профилирования, подтвердившего среднее время CPU 30 мс и неблокирующий ввод-вывод. Настройте minScale=2, чтобы избежать холодных стартов в обычные часы; установите политику по расписанию для снижения minScale до 0 в ночное время. Обоснование: Более высокий параллелизм улучшает утилизацию и сокращает количество инстансов; минимальное количество постоянно работающих инстансов поддерживает SLO с ограниченными базовыми затратами, которые устраняются в нерабочее время.

3. Оптимизация размеров рабочих нагрузок GKE и включение эффективного автомасштабирования

   • Примените запросы (requests) 500m CPU/512Mi и лимиты (limits) 1 CPU/768Mi к подам обработчиков на основе профилирования. Включите HPA по глубине очереди и задержке обработки, а также VPA в режиме рекомендаций для итеративного уточнения запросов. Убедитесь, что PodDisruptionBudgets разрешают уменьшение масштаба. Включите Cluster Autoscaler для пула с несколькими узлами меньшего размера. Обоснование: Точные запросы обеспечивают эффективное планирование и автомасштабирование; HPA приводит ёмкость в соответствие с объёмом необработанных задач; VPA предотвращает дрейф; несколько небольших узлов уменьшают количество изолированных (неиспользуемых) ресурсов и ускоряют события масштабирования.

4. Использование Spot-мощностей для отказоустойчивых пакетных задач

   • Перенесите генерацию миниатюр изображений в пул узлов на базе Spot-инстансов с созданием контрольных точек (checkpointing). Реализуйте хуки preStop для завершения выполняемой работы и контроллер для перепланирования прерванных заданий. Обоснование: Генерация миниатюр является идемпотентной и гибкой по времени задачей, что делает её идеальной для экономии с помощью Spot-инстансов с минимальным влиянием на пользовательский опыт.

5. Снижение затрат на сканирование в аналитике и изоляция рабочих нагрузок

   • Партиционируйте и кластеризуйте таблицу событий по event_date и customer_id. Добавьте срок хранения для необработанных событий в 180 дней. Выделите для маркетологов-аналитиков отдельную резервацию BigQuery с ограничением по слотам; принудительно установите maximum_bytes_billed в их запросах, выполняемых по расписанию. Преобразуйте ночные отчёты для выполнения с приоритетом пакетной обработки (batch). Обоснование: Партиционирование и кластеризация сокращают объём сканируемых байтов на запрос; срок хранения обеспечивает управление данными; резервации изолируют «шумных соседей»; пакетный режим снижает конкуренцию за ресурсы и стоимость для несрочных заданий.

6. Оптимизация жизненного цикла хранилища и исходящего трафика

   • Храните изображения продуктов в хранилище dual-region рядом с клиентами; перемещайте изображения, к которым не обращались 30 дней, в Coldline с помощью правил жизненного цикла; раздавайте контент через Cloud CDN. Размещайте сервисы Cloud Run в одном регионе с Cloud SQL и включите Private Service Connect для доступа к API Google. Обоснование: CDN сокращает исходящий трафик и задержку; жизненный цикл перемещает «холодные» данные в более дешёвое хранилище; совместное размещение минимизирует исходящий трафик и улучшает производительность.

7. Внедрение автоматизации очистки и проверок на устойчивость

   • Присваивайте эфемерным средам тег ttl-hours и запускайте ночное задание Cloud Run, которое удаляет ресурсы с истёкшим сроком жизни. Используйте отчёты Carbon Footprint, чтобы рассмотреть возможность переноса пакетных заданий в регион с меньшей углеродоёмкостью и планировать их выполнение в часы пиковой доступности безуглеродной энергии. Обоснование: Автоматическая очистка предотвращает утечки средств; планирование с учётом выбросов углерода снижает воздействие на окружающую среду, не влияя на SLO.

8. Валидация с помощью нагрузочных тестов на основе SLO и моделей затрат

   • Запустите нагрузочные тесты, воспроизводящие паттерны мгновенных распродаж; проверьте задержку p95 и бюджеты ошибок. Сравните затраты до и после, используя дашборды на основе экспорта биллинга. Обоснование: Подтверждает, что оптимизация соответствует целям по надёжности и при этом обеспечивает измеримую экономию в соответствии с поставленными задачами.

Выполнив эти шаги, NimbusMarket приводит расходы в соответствие со спросом, предотвращает потери из-за простоя ресурсов и обеспечивает управление, достигая целевой экономии при сохранении SLO API в 99,9% и улучшая свои показатели устойчивого развития.

← Тестирование · Все домены

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

Просмотреть Google →