Google ACE: Хранилища, базы данных и сервисы данных — Руководство по подготовке

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

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

Обзор

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

Cloud Storage: проектирование, доступ, жизненный цикл и защита

Cloud Storage — это долговечное, высокодоступное объектное хранилище для неструктурированных данных и резервных копий.

• Бакеты и объекты: Бакеты — это глобальные пространства имен в определенном местоположении (регионе, двойном или мультирегионе), которые содержат неизменяемые версии объектов. Выбирайте местоположение бакета так, чтобы минимизировать исходящий трафик и соответствовать требованиям к местонахождению данных.
• Классы хранения: Используйте Standard (горячий), Nearline (минимум ~30 дней), Coldline (минимум ~90 дней) и Archive (минимум ~365 дней) в зависимости от частоты доступа. Для резервных копий в целях аварийного восстановления (DR) Coldline часто используется по умолчанию. Вы можете смешивать классы для разных объектов в одном бакете.
• Правила жизненного цикла: Автоматизируйте перемещение и удаление с помощью условий Age, CreatedBefore, MatchesStorageClass и NoncurrentVersion. Пример для перемещения через 90 дней и удаления через 365 дней:
  1. lifecycle.json:

undefined

2. Применить:

undefined

• Хранение и юридическое удержание: Политики хранения (Retention policies) предотвращают удаление или изменение объектов до истечения установленного срока; блокировка политики необратима. Юридическое удержание (Legal holds) применяется к отдельным объектам и должно быть снято перед удалением.

Контроль доступа и совместное использование:

• Единый и детальный доступ: Предпочитайте единый доступ на уровне бакета (Uniform bucket-level access, UBLA), чтобы управлять разрешениями только через IAM. Детальный доступ (ACL на уровне объектов) является устаревшим подходом и усложняет аудит и распространение прав. Включение UBLA отключает ACL и может немедленно повлиять на существующие интеграции, которые на них полагались.
• Подписанные URL: Для краткосрочного доступа без учетной записи Google используйте подписанные URL. Избегайте использования файлов ключей сервисных аккаунтов, подписывая запросы с помощью IAM:

undefined

Убедитесь, что у сервисного аккаунта есть роль создателя токенов сервисного аккаунта (service account token creator) для самого себя или через роль подписывающего (signer role).

• Шифрование: Шифрование на стороне сервера включено по умолчанию; используйте CMEK на уровне бакета или объекта, когда вам нужен контроль над ключами и журналами аудита. Следите за доступностью и ротацией ключей KMS; недоступность CMEK заблокирует загрузку и расшифровку данных.
• Версионирование: Включите версионирование объектов, чтобы сохранять неактуальные версии после перезаписи/удаления. Комбинируйте с правилами жизненного цикла для удаления неактуальных версий и контроля роста хранилища. Учитывайте логику листинга на стороне клиента при наличии большого количества версий.

Сценарии сбоев и их предотвращение:

• Случайное удаление или перезапись: Используйте версионирование и политики хранения. Для строгого соответствия требованиям заблокируйте политику хранения.
• Неправильно настроенный публичный доступ: Принудительно включайте предотвращение публичного доступа (Public Access Prevention) и UBLA. Периодически проводите аудит с помощью Cloud Asset Inventory и анализатора политик.
• Избыточные расходы: Правила жизненного цикла, классы на уровне объектов и режим “requester pays” (оплата за счет запрашивающего) помогают избежать неожиданных трат. Отслеживайте с помощью метрик Cloud Monitoring и бюджетов.

Полезные команды:

• Создание бакета с UBLA и политикой хранения:

undefined

undefined

Блочные и файловые хранилища для вычислительных нагрузок

Выбирайте хранилище в зависимости от шаблона доступа, требований к производительности и долговечности для Compute Engine и GKE.

• Persistent Disk (PD): Долговечное блочное хранилище, зональное или региональное. Типы: Standard (HDD) для последовательной пропускной способности; Balanced (pd-balanced) и SSD (pd-ssd) для низкой задержки и высокого IOPS. Региональный PD синхронно реплицируется между зонами, обеспечивая более быстрое восстановление. Для PD можно создавать снэпшоты, изменять размер на лету и подключать в режиме «только чтение» к нескольким ВМ (или в режиме «один писатель» для чтения-записи).
  • Компромиссы: более высокая стоимость IOPS на SSD; HDD экономичен, но имеет высокую задержку для случайного ввода-вывода. Региональный PD стоит дороже, но сокращает RTO.
• Local SSD: Эфемерное хранилище, подключенное по NVMe или SCSI, с очень высоким IOPS и низкой задержкой. Данные теряются при остановке ВМ или обслуживании хоста; используйте его только для эфемерных кэшей или реплицируемых данных. Создавайте резервные копии или реплицируйте данные в другое место, чтобы избежать их потери.
• Filestore: Управляемый NFS для семантики общего доступа к файлам POSIX. Базовые уровни (Basic) являются зональными; Enterprise и более высокие уровни предлагают региональную высокую доступность (HA) с синхронной репликацией и более высоким IOPS. Идеально подходит для GCVE, временных хранилищ HPC, рендеринга медиа и приложений, требующих общей блокировки файлов.
  • Компромиссы: NFS вводит кэширование на стороне клиента и семантику блокировок; пропускная способность и задержка различаются в зависимости от уровня; не подходит для небольших случайных операций ввода-вывода с задержками в единицы микросекунд, как Local SSD.

Вопросы, связанные со сбоями:

• Обслуживание хоста: Потеря данных на Local SSD; защищайтесь с помощью репликации на уровне приложения.
• Сбои в зоне: Перебои в работе зональных PD и Filestore уровня Basic; используйте региональный PD или Filestore Enterprise для высокой доступности (HA).
• Консистентность снэпшотов: Для создания консистентных на уровне приложений снэпшотов PD, координируйте процесс с заморозкой файловой системы (filesystem freeze) или «успокоением» базы данных (database native quiesce), чтобы избежать необходимости аварийного восстановления.

Компромиссы при перемещении, миграции, проверке и эксплуатации данных

Миграция и передача:

• Database Migration Service (DMS): Для гомогенных миграций в Cloud SQL с минимальным временем простоя с помощью репликации. Проверяйте переключение с помощью метрик отставания и сравнения контрольных сумм.
• Передача данных в Cloud Storage: Storage Transfer Service для повторяющихся или управляемых событиями передач; gsutil -m rsync для разовых синхронизированных копий с контрольными суммами; Transfer Appliance для крупных офлайн-переносов.
• Импорт/экспорт: Cloud SQL экспортирует данные в Cloud Storage; повторный импорт поддерживает начальную загрузку для PITR и проверку данных. BigQuery поддерживает пакетные загрузки из Cloud Storage и экспорт в Avro/Parquet для дальнейшего использования.
• Проверка: Используйте контрольные суммы объектов (CRC32C), подсчет строк, выборочные запросы и инварианты на уровне приложения. Для BigQuery сравнивайте результаты GROUP BY по количеству или хэшам между источником и приемником.

Компромиссы между производительностью, доступностью, емкостью и стоимостью:

• Cloud Storage: Оптимизируйте исходящий трафик (egress), размещая вычислительные ресурсы в том же регионе; выбирайте классы хранения в зависимости от частоты доступа; используйте двух- или мультирегиональные бакеты для устойчивости к сбоям в зонах и повышения доступности за счет более высокой стоимости хранения.
• PD/Filestore: SSD для операций ввода-вывода с низкой задержкой; HDD для высокой пропускной способности; региональная репликация для высокой доступности (HA); правильно подбирайте количество IOPS, чтобы избежать регулирования (throttling).
• Cloud SQL: Вертикальное масштабирование простое, но ограниченное; реплики чтения снимают нагрузку с операций чтения; высокая доступность (HA) повышает доступность, но не емкость для чтения; класс хранения влияет на задержку и стоимость.
• Spanner: Горизонтально масштабируется со строгой согласованностью; высокая стоимость компенсируется глобальными RPO/RTO и упрощенным шардированием. Операции записи чувствительны к дизайну ключей и задержке в регионе-лидере.
• Firestore/Bigtable/Memorystore: Выбирайте в зависимости от требований к задержке, модели данных и согласованности. Кэши в памяти снижают нагрузку на базу данных, но добавляют сложность инвалидации кэша.
• BigQuery: Стоимость по запросу пропорциональна объему сканированных данных; секционирование/кластеризация и проталкивание предиката (predicate pushdown) сокращают расходы. Резервирование с фиксированной ставкой обеспечивает предсказуемость в обмен на обязательства.

Поиск и устранение неисправностей и безопасное восстановление:

• Cloud Storage: Используйте версионирование объектов и политики хранения для восстановления; изучайте журналы доступа к данным в Cloud Logging для аудита событий чтения/записи; убедитесь, что ключи CMEK включены во время восстановления.
• PD/Filestore: Восстанавливайте из снимков или резервных копий; запускайте fsck и режимы восстановления базы данных; обеспечивайте согласованность путем “заморозки” на уровне приложения перед созданием снимка.
• Cloud SQL: Для PITR восстанавливайте данные в новый экземпляр, чтобы избежать потери данных на основном; проверяйте с помощью тестов в режиме “только для чтения”; поддерживайте брандмауэр и частный DNS для безопасных схем переключения.
• Spanner/Bigtable: Исследуйте возникновение “горячих точек” (hotspotting) из-за неравномерного доступа к ключам; используйте Monitoring для отслеживания задержки и регулирования; реализуйте экспоненциальную выдержку и повторные попытки для прерванных транзакций или операций, ограниченных по частоте.
• BigQuery: Диагностируйте медленные запросы с помощью деталей выполнения; добавляйте секции и кластеризацию; ограничивайте использование SELECT *; материализуйте промежуточные результаты, когда это целесообразно. Восстанавливайте удаленные таблицы в пределах окна “путешествия во времени” (time travel), восстанавливая снимок или копируя данные из снимка на определенный момент времени.

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

Компания Contoso Retail консолидирует резервные копии и аналитические данные, одновременно усиливая контроль доступа и включая восстановление на определенный момент времени (PITR) для своих транзакционных систем. Им необходимо: хранить резервные копии приложений с автоматическим распределением по уровням хранения, предоставлять краткосрочный доступ к файлам третьим сторонам, включить PITR для небольшой реляционной рабочей нагрузки и оценивать стоимость аналитических запросов перед их выполнением.

Подход:

1. Создать региональный бакет Cloud Storage с UBLA, политикой хранения и жизненным циклом.
   • Команда:

undefined

undefined

undefined

• Обоснование: UBLA (единообразный доступ на уровне бакета) централизует авторизацию в IAM и улучшает возможности аудита. Годовой срок хранения предотвращает случайное удаление. Жизненный цикл перемещает резервные копии в Coldline через 90 дней и удаляет их по истечении срока для контроля затрат.

2. Предоставить доступ только на запись для заданий резервного копирования через выделенный сервисный аккаунт.
   • Команда:

undefined

• Обоснование: Роль roles/storage.objectCreator предотвращает изменение метаданных и обратное чтение конфиденциальных резервных копий, соблюдая принцип наименьших привилегий.

3. Предоставить доступ к конфиденциальной резервной копии поставщику на четыре часа с помощью подписанного URL, не распространяя ключи.
   • Команда:

undefined

• Обоснование: Ограниченный по времени доступ без идентификации позволяет избежать создания внешних удостоверений или долгоживущих секретов. Имперсонация использует централизованное подписание на основе KMS и устраняет риски утечки ключей.

4. Включить резервное копирование и PITR для базы данных заказов в Cloud SQL.
   • Команда:

undefined

• Обоснование: Автоматическое резервное копирование в сочетании с ведением двоичных журналов/журналов предзаписи (WAL) обеспечивает точки восстановления с точностью до секунды в пределах окна хранения, защищая от логического повреждения и ошибок оператора.

5. Протестировать восстановление путем развертывания в новый экземпляр и проверки данных перед переключением.
   • Команда:

undefined

undefined

• Обоснование: Восстановление в отдельный экземпляр позволяет избежать влияния на производственную среду и дает возможность провести проверку с помощью контрольных сумм и выборочных запросов перед любым переключением на уровне DNS или приложения.

6. Оценить стоимость запроса в BigQuery с помощью пробного запуска (dry run) и оптимизировать его с помощью секционирования.
   • Команда:

undefined

• Обоснование: Пробные запуски показывают количество байтов, которые будут отсканированы; использование sale_date в качестве столбца секционирования с ограниченным предикатом уменьшает объем сканируемых данных и контролирует затраты при оплате по запросу.

7. Мониторить и проводить аудит доступа.

   • Шаги:
     • Включить журналы доступа к данным для Cloud Storage и BigQuery.
     • Настроить оповещения Cloud Monitoring для соединений Cloud SQL, использования диска и сбоев резервного копирования.
   • Обоснование: Журналы доступа к данным обеспечивают видимость операций чтения/записи на уровне объектов для соответствия требованиям. Проактивные оповещения сокращают среднее время восстановления (MTTR) и гарантируют эффективность резервного копирования и PITR.

8. Документировать режимы отказа и сценарии действий (runbooks).

   • Шаги:
     • Задокументировать процедуры восстановления версий объектов, отзыва подписанных URL, PITR в Cloud SQL и восстановления таблиц BigQuery с помощью “путешествия во времени”.
   • Обоснование: Четкие, протестированные сценарии действий (runbooks) снижают операционные риски во время инцидентов и стандартизируют безопасные практики восстановления для всех команд.

← Сети VPC · Все домены · Развертывание →

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

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