Google ACE: Управление затратами, производительность и оптимизация емкости — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Экономика хранения и обработки данных

• Классы хранения и жизненный цикл Cloud Storage:

  • Выбирайте классы в зависимости от характера доступа: Standard (для «горячих» данных), Nearline (мин. 30 дней), Coldline (мин. 90 дней), Archive (мин. 365 дней). Применяйте правила жизненного цикла для автоматического понижения класса и удаления по расписанию.
  • Компромиссы при извлечении данных: Классы с более низкой стоимостью хранения имеют плату за извлечение каждого ГБ и сборы за минимальный срок хранения; частое чтение из Coldline/Archive сводит на нет всю экономию. Планируйте процессы восстановления с учётом пиковых затрат на чтение.
  • Управление: Используйте политики хранения и блокировки объектов для соблюдения нормативных требований; включайте опцию «Платит запрашивающий» (requester-pays) для общих наборов данных, чтобы избежать неожиданных счетов между командами.

• Пример политики жизненного цикла (понижение класса и удаление):

  • Определите действия SetStorageClass и Delete на основе возраста данных, чтобы автоматизировать переходы между классами и очистку устаревших данных.

• Контроль затрат в BigQuery:

  • Запросы по требованию (on-demand) тарифицируются за объём обработанных байт; минимизируйте его с помощью отсечения партиций (partition pruning) и кластеризации. Партиционируйте по дате загрузки или по столбцу с датой; кластеризуйте до четырёх столбцов с высокой кардинальностью/селективностью.
  • Используйте пробные запуски (dry run) для оценки стоимости, материализованные представления для часто используемых агрегаций и декораторы таблиц для сужения временных окон.
  • Резервирования (слоты) обеспечивают предсказуемую производительность и расходы; используйте назначения на уровне проекта/папки и рассмотрите гибкие обязательства (flex commitments) для краткосрочных всплесков.
  • Сценарии неэффективности: Сканирование непартиционированных таблиц, SELECT * в широких таблицах или неправильный порядок столбцов в кластере приводят к огромному объёму сканируемых байт; эфемерные промежуточные таблицы могут раздувать хранилище, если для них не настроено удаление по истечении срока.

Краткий пример (фрагмент JSON жизненного цикла Cloud Storage):

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Сеть, базы данных и масштабирование с учётом квот

• Исходящий сетевой трафик (egress) и его влияние на архитектуру:

  • Исходящий трафик в интернет, между регионами и через внешние IP-адреса платный; трафик в пределах одного региона по внутренним IP-адресам, как правило, бесплатный. Выбирайте Premium Network Tier для производительности или Standard для чувствительных к стоимости нагрузок с менее строгими требованиями к задержке/джиттеру.
  • Балансировщики нагрузки: L7 HTTP(S) и L4 TCP/UDP имеют плату за обработку данных и за правила пересылки; межрегиональные балансировщики могут добавлять плату за межрегиональный исходящий трафик. Консолидация балансировщиков экономит постоянные затраты, но может увеличить радиус поражения (blast radius).
  • Оптимизация: Держите трафик внутри одного региона; используйте региональные бакеты и сервисы; избегайте «шпилек» (hairpinning) через внешние IP-адреса. Кэшируйте статические ресурсы на границе сети (edge), чтобы уменьшить исходящий трафик от источника (origin).
  • Сценарии неэффективности: Случайное использование внешних IP-адресов между сервисами в одном VPC приводит к ненужному исходящему трафику; межрегиональная репликация удваивает исходящий трафик для операций записи.

• Выбор размера БД, реплики и доступность:

  • Cloud SQL: Подбирайте vCPU/RAM под 95-й перцентиль нагрузки; включите автоматическое расширение хранилища; используйте реплики чтения для горизонтального масштабирования операций чтения; режим высокой доступности (HA) удваивает стоимость вычислений, но сокращает RTO при отказе. Пулинг соединений позволяет избежать избыточных накладных расходов на установку соединений.
  • Spanner: Ёмкость выделяется в виде узлов или вычислительных единиц (processing units); межрегиональные конфигурации улучшают доступность и задержку чтения, но увеличивают стоимость и задержку записи; тщательно планируйте разделения (splits) и избегайте «горячих точек» (hotspots).
  • Bigtable: Количество узлов определяет пропускную способность; автомасштабирование помогает отслеживать трафик; межкластерная репликация повышает доступность и стоимость; используйте схему для равномерного распределения ключей.
  • Компромиссы: Реплики улучшают пропускную способность чтения и доступность, но увеличивают коэффициент усиления записи (write amplification) и исходящий трафик; строгая согласованность и межрегиональные операции записи добавляют задержку.

• Квоты, ограничения скорости и противодавление (backpressure):

  • Изучите квоты для каждого API и лимиты одновременных запросов для каждого сервиса. Реализуйте экспоненциальную выдержку (exponential backoff) с джиттером для ответов 429/5xx. Применяйте выравнивание нагрузки на основе очередей с помощью Pub/Sub и заданий Dataflow или Cloud Run.
  • Настройки параллелизма: В Cloud Run более высокий параллелизм снижает затраты, но создаёт риск длинного хвоста задержек (tail latency); настраивайте выделение CPU при обработке запроса для стабильной пропускной способности.
  • Противодавление (Backpressure): Используйте управление потоком (flow control) в подписчиках Pub/Sub, автоматические выключатели (circuit breakers) и контроль доступа (admission control) для предотвращения каскадных сбоев.
  • Сценарии неэффективности: Игнорирование квот приводит к внезапному троттлингу; автомасштабирование может усилить нагрузку на нижестоящие сервисы (downstreams) при отсутствии противодавления, вызывая повторные попытки и увеличивая затраты.

Управление измерением производительности и оптимизацией

• Измерение и нагрузочное тестирование:

  • Установите SLI/SLO для задержки, частоты ошибок и насыщенности. Используйте дашборды Cloud Monitoring, проверки времени безотказной работы и оповещения. Внедрите трассировку (Cloud Trace) и профилирование (Cloud Profiler) для выявления «горячих» участков кода и состязания за блокировки.
  • Проводите нагрузочное тестирование с реалистичными моделями трафика, кардинальностью данных и временем на обдумывание. Проверяйте параметры автомасштабирования, время прогрева и проверки готовности (readiness gates). Включайте сценарии отказа и хаос-инжиниринга для оценки запаса производительности и времени восстановления.
  • Диагностика узких мест: используйте метод USE (Utilization, Saturation, Errors — утилизация, насыщенность, ошибки) для CPU, памяти, дисков, сети и нижестоящих зависимостей; сопоставляйте результаты с логами и трассировками.

• Управление: баланс между затратами, безопасностью и надежностью:

  • Защитные механизмы FinOps: обязательные метки/теги; бюджеты с оповещениями о прогнозируемом превышении; централизованный экспорт биллинга и регулярный пересмотр затрат. Включайте рекомендации Recommender (неиспользуемые IP-адреса/диски, оптимизация размеров) в бэклог с SLA для ответственных.
  • Безопасность: отдавайте предпочтение приватному подключению (без внешних IP-адресов), используйте VPC Service Controls для снижения рисков утечки данных. Помните, что приватные маршруты могут изменить шаблоны исходящего трафика и затраты. Шифруйте неактивные данные и данные при передаче; учитывайте использование KMS в моделях затрат.
  • Надежность: резервируйте базовую мощность с помощью CUD или резервирований BigQuery; сохраняйте запас производительности для пиковых нагрузок для соблюдения SLO; регулярно проводите учения (game days). Документируйте случаи, когда использование Spot-инстансов или агрессивного автомасштабирования недопустимо для критически важных путей.
  • Управление изменениями: рассматривайте параметры, влияющие на стоимость (ограничения автомасштабирования, резервирования BigQuery, топология LB), как код (IaC), с планами ревью и отката.

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

Компания Contoso Media управляет многорегиональной платформой видеоаналитики, у которой растут затраты и периодически нарушаются SLO по задержке во время всплесков трафика. Руководство хочет сократить расходы на 20%, не нарушая SLO по задержке p95 в 300 мс для API и SLA в 2 часа на завершение ночных пакетных заданий.

1. Определить базовые показатели затрат и производительности

• Действие: включить экспорт Cloud Billing в BigQuery и создать дашборды, сопоставляющие затраты по SKU с SLI из Cloud Monitoring (задержка, CPU, исходящий трафик в байтах). Выполнить bq dry runs для 20 самых частых запросов, чтобы оценить объем сканируемых данных.
• Обоснование: базовые показатели помогают выявить наиболее влияющие сервисы и связать расходы с факторами производительности, что позволяет проводить целенаправленную оптимизацию.

2. Внедрить обязательное тегирование ресурсов и бюджетирование

• Действие: требовать использования меток/тегов (env, service, owner, cost-center) через шаблоны развертывания; установить бюджеты для каждой среды с отправкой оповещений о прогнозах в топик Pub/Sub для FinOps.
• Обоснование: полные данные о распределении ресурсов и проактивные оповещения позволяют быстро определить ответственных и принять меры до превышения бюджета.

3. Оптимизировать размеры и зарезервировать базовые вычислительные мощности

• Действие: применить рекомендации Recommender по оптимизации размеров VM для сервисов со стабильной нагрузкой; преобразовать мощности для постоянной нагрузки в региональные CUD на 1 год; оставить буфер в 20–30% в максимальном значении автомасштабирования для пиковых нагрузок.
• Обоснование: оптимизация размеров и резервирование снижают стоимость единицы мощности для предсказуемых нагрузок, сохраняя запас производительности для соблюдения SLO.

4. Оптимизировать автомасштабирование и готовность

• Действие: для MIG переключить сигналы автомасштабирования на метрики на основе запросов или пользовательские метрики QPS/задержки, установить период стабилизации (cool-down) в 120–180 секунд и согласовать начальную задержку проверки работоспособности со временем прогрева приложения. Включить элементы управления для scale-in, чтобы предотвратить слишком быстрое уменьшение масштаба.
• Обоснование: сигналы, учитывающие нагрузку, и стабилизация помогают избежать частых переключений (thrashing) и избыточного выделения ресурсов, которые увеличивают затраты и ухудшают задержку.

5. Сократить исходящий сетевой трафик и накладные расходы балансировщика нагрузки

• Действие: устранить обмен данными между сервисами по внешним IP-адресам; убедиться, что весь трафик east-west использует внутреннюю балансировку нагрузки; размещать сервисы с интенсивным обменом данными в одном регионе; кэшировать статические ресурсы на границе сети (edge).
• Обоснование: внутренние маршруты устраняют ненужный исходящий трафик и сокращают обработку на уровне L7, улучшая задержку и снижая затраты.

6. Жизненный цикл и архивация хранилища

• Действие: применить правила жизненного цикла Cloud Storage для перемещения «холодных» артефактов в Coldline через 90 дней и удаления через 365 дней; включить опцию «Платит запрашивающий» (requester-pays) для общих бакетов; проанализировать последствия минимального срока хранения для данных с редким доступом.
• Обоснование: разделение на уровни и политики хранения сокращают затраты на хранение и извлечение данных, обеспечивая при этом соответствие требованиям.

7. Оптимизация запросов и мощности BigQuery

• Действие: партиционировать большие таблицы фактов по дате, кластеризовать по столбцам с высокой селективностью; заменить SELECT * на выборку конкретных столбцов; внедрить материализованные представления для самых частых агрегаций; приобрести небольшое резервирование для пиковых окон ETL и использовать flex slots во время всплесков пакетной обработки.
• Обоснование: партиционирование/кластеризация уменьшают объем сканируемых данных; резервирование мощностей стабилизирует производительность и затраты для критически важных нагрузок.

8. Масштабирование и реплики базы данных

• Действие: для сервисов с высокой нагрузкой на чтение в Cloud SQL добавить реплики чтения; настроить пулы соединений; настроить автоматическое изменение размера хранилища; протестировать отработку отказа для проверки RTO/RPO. Для Bigtable включить автомасштабирование и решить проблему «горячих» ключей (hotspot keys).
• Обоснование: реплики снимают нагрузку с операций чтения и защищают пути записи; автомасштабирование поддерживает пропускную способность на уровне спроса без ручного избыточного выделения ресурсов.

9. Квоты, параллелизм и обратное давление (backpressure)

• Действие: реализовать экспоненциальную выдержку с джиттером (exponential backoff with jitter); настроить управление потоком (flow control) для подписчиков Pub/Sub; настроить параллелизм (concurrency) в Cloud Run для баланса между пропускной способностью и задержкой; добавить прерыватели цепи (circuit breakers) на границах с нижестоящими сервисами.
• Обоснование: правильно настроенное обратное давление предотвращает каскадные сбои и неконтролируемые повторные попытки, которые ухудшают SLO и увеличивают затраты.

10. Непрерывная проверка и управление

• Действие: ежемесячно проводить нагрузочные тесты и учения по хаос-инжинирингу; отслеживать SLO и бюджеты ошибок; интегрировать рекомендации Recommender и аномалии затрат в планирование спринтов с указанием ответственных и сроков.
• Обоснование: итеративная проверка гарантирует, что экономия сохраняется, а SLO остаются в «зеленой зоне» по мере развития рабочих нагрузок.

← Надежность · Все домены

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

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