Amazon DOP-C02: Хранилища, базы данных и управление данными — Руководство по подготовке

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Часть AWS DevOps Engineer Professional DOP-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Обзор

Хранилища, базы данных и перемещение данных в AWS должны проектироваться с учётом долговечности, доступности, экономической эффективности и автоматизации. Глубокое понимание классов хранения и репликации S3, управления производительностью и глобального распределения DynamoDB, настроек конфигурации и моделей резервного копирования RDS/Aurora, кэширования в памяти, общих файловых систем и сервисов миграции данных позволяет создавать надёжные системы с низкой задержкой, предсказуемым поведением при восстановлении и контролируемыми расходами.

Amazon S3: классы хранения, жизненный цикл, Intelligent-Tiering и репликация

Классы хранения S3 позволяют согласовать стоимость с шаблонами доступа:

Standard: несколько зон доступности (multi-AZ), низкая задержка, без платы за извлечение. Стандартный выбор для «горячих» данных.
Intelligent-Tiering (S3 INT): multi-AZ с автоматическим перемещением между уровнями Frequent Access и Infrequent Access, а также опциональными архивными уровнями. Взимается плата за мониторинг и автоматизацию для каждого объекта; объекты размером менее 128 КБ не перемещаются автоматически. Уровни Archive Access и Deep Archive Access являются опциональными и активируются по порогам последнего доступа; при извлечении данных с уровней, отличных от Frequent, взимается плата.
Standard-IA и One Zone-IA: более низкая стоимость хранения, но с платой за извлечение; минимальный срок хранения — 30 дней. One Zone-IA размещается в одной зоне доступности (single-AZ) и подходит для данных, которые можно воссоздать.
Glacier Instant Retrieval: доступ за миллисекунды по цене архивного хранения; минимальный срок хранения — 90 дней.
Glacier Flexible Retrieval: извлечение от нескольких минут до часов, есть опции bulk/standard/expedited; минимальный срок хранения — 90 дней.
Glacier Deep Archive: извлечение от нескольких часов до 12 часов; минимальный срок хранения — 180 дней. Выбирайте самый «холодный» подходящий уровень, учитывая плату за минимальный срок хранения, плату за извлечение и требуемое время доступа.

Политики жизненного цикла (Lifecycle policies) автоматизируют перемещение и удаление объектов с использованием фильтров (по префиксу, тегам) для гранулярного контроля. Ключевые действия включают перемещение на уровни IA/Glacier по истечении порогов неактивности, перемещение/удаление неактуальных версий в версионируемых бакетах, удаление маркеров удаления и прерывание незавершённых многосоставных загрузок. Политики жизненного цикла и тегирование объектов имеют решающее значение для обеспечения хранения данных и обоснованного удаления (defensible deletion) наряду с S3 Object Lock (режимы governance/compliance), когда требуется неизменяемость данных.

Intelligent-Tiering идеально подходит, когда шаблоны доступа неизвестны или меняются. Он сохраняет производительность (нет задержки при извлечении с уровней frequent/IA), избавляет от необходимости перепроектировать архитектуру при изменении шаблонов доступа и может опционально автоматически архивировать данные на «глубокие» уровни на основе последнего доступа, обеспечивая наилучшее сочетание гибкости и контроля затрат для долгоживущих наборов данных со спорадическим доступом.

Репликация S3 обеспечивает долговечное асинхронное копирование объектов:

Требования: на исходном и целевом бакетах должно быть включено версионирование. Конфигурация репликации определяет целевой бакет/аккаунт/регион, фильтр по префиксу/тегам, репликацию метаданных (ACL, теги, S3 Object Lock), класс хранения, а также необходимость репликации маркеров удаления и существующих объектов.
Same-Region Replication (SRR): соответствие требованиям (compliance)/суверенитет данных, агрегация логов, атомарная обработка между аккаунтами.
Cross-Region Replication (CRR): аварийное восстановление (DR), снижение задержки, глобальное распределение, соответствие требованиям.
Объекты, зашифрованные с помощью KMS: роль репликации должна иметь разрешение на расшифровку с помощью исходного ключа KMS и на шифрование с помощью целевого ключа KMS. Укажите ключ KMS для реплики в правиле репликации в

undefined

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

Существующие объекты: используйте S3 Batch Replication для их репликации.
Replication Time Control (RTC): добавляет SLA в 15 минут на завершение репликации, с метриками и уведомлениями для мониторинга SLA. Полезно для соответствия требованиям и строгих RPO.
Владение и доступ: при репликации между аккаунтами включите bucket owner preferred или Object Ownership bucket owner enforced, чтобы избежать сложностей с ACL и гарантировать, что целевой аккаунт будет владеть репликами.

Базы данных в AWS: DynamoDB, RDS и Aurora

Режимы ёмкости и масштабирование DynamoDB:

On-demand (по требованию): не требует планирования ёмкости; оплата за каждый запрос; идеально для непредсказуемых или пиковых нагрузок и для новых таблиц с неизвестным трафиком.
Provisioned (подготовленная ёмкость): установка RCUs/WCUs с помощью DynamoDB Application Auto Scaling по целевому уровню утилизации; подходит для стабильного или предсказуемого трафика и контроля затрат.
Адаптивная ёмкость (Adaptive capacity): автоматически перераспределяет пропускную способность партиций на «горячие» ключи, но для экстремально «горячих» партиций все равно требуется выравнивание нагрузки (например, шардирование записей). GSI имеют отдельную ёмкость; тщательно моделируйте, чтобы избежать троттлинга.
Размер элемента влияет на ёмкость: 1 WCU на 1 КБ записи; 1 RCU на 4 КБ строго согласованного чтения или на 8 КБ согласованного в конечном счёте чтения.

Потоки DynamoDB и DAX:

Потоки (Streams) фиксируют изменения на уровне элементов с хранением в течение 24 часов. Выбирайте типы представлений, чтобы включать образы NEW/OLD. Распространённые паттерны: триггеры Lambda для CQRS/записей на основе событий, синхронизация между таблицами и журналы аудита. Порядок гарантируется в пределах ключа партиции, доставка — как минимум один раз (at-least-once).
DAX — это управляемый, API-совместимый кеш в памяти для DynamoDB, который кардинально снижает задержку чтения. Он поддерживает согласованное в конечном счёте чтение; строго согласованные чтения должны выполняться в обход DAX. Предлагает сквозную запись (write-through) для изменений элементов и инвалидацию на основе TTL. Используйте кластеры multi-AZ для высокой доступности и размещайте подсети DAX близко к клиентам.

Глобальные таблицы DynamoDB:

Мультирегиональная репликация multi-master с использованием потоков и разрешением конфликтов по принципу «побеждает последняя запись» (last-writer-wins) на основе системной временной метки. Проектируйте так, чтобы избежать одновременных обновлений одних и тех же атрибутов в разных регионах, или реализуйте сверку на стороне приложения.
Атрибут TTL реплицируется как обычные данные элемента; удаления на основе TTL обрабатываются в каждом регионе отдельно и не реплицируются как явные операции удаления.
Резервные копии и PITR привязаны к региону; восстановление производится в новые таблицы в каждом регионе, после чего (опционально) их можно заново объединить в новую глобальную таблицу.

Конфигурация и резервное копирование Amazon RDS:

Группы параметров (Parameter groups) определяют параметры движка. Статические параметры требуют перезагрузки; динамические применяются немедленно, если это поддерживается. Используйте группы параметров БД (DB parameter groups) для движков на уровне инстанса и группы параметров кластера (cluster parameter groups) для Aurora.
Группы опций (Option groups) включают нативные функции движка (например, Oracle TDE/OEM, нативное резервное копирование/восстановление SQL Server, плагины MySQL/MariaDB). Некоторые опции могут требовать перезапуска движка; тщательно планируйте окна для изменений.
Автоматические резервные копии позволяют выполнять восстановление на момент времени (PITR) в пределах окна хранения (до 35 дней). Они создают ежедневные снимки и сохраняют журналы транзакций в S3; при восстановлении создаются новые инстансы.
Снимки, созданные вручную, хранятся до удаления, могут копироваться между регионами и предоставляться другим аккаунтам (с учётом разрешений ключа KMS для зашифрованных снимков). Используйте копирование снимков между регионами для создания основы для аварийного восстановления (DR).

Особенности Amazon Aurora:

Эндпоинты: эндпоинт кластера (writer) всегда указывает на основной инстанс для операций записи. Эндпоинт чтения (reader) распределяет нагрузку между репликами. Пользовательские эндпоинты (Custom endpoints) могут выбирать подмножество реплик для многоуровневых пулов чтения или специализированных нагрузок. Всегда направляйте запись на эндпоинт writer, а чтение — на эндпоинт reader или соответствующий пользовательский эндпоинт для минимизации сбоев при отработке отказа.
Serverless v2: гранулярное, мгновенное масштабирование ACU без перезапуска. Работает внутри кластера Aurora, поддерживает смешанные конфигурации из serverless и provisioned инстансов и хорошо подходит для пиковых нагрузок, сред разработки/тестирования или мульти-арендных приложений с неравномерным спросом. Сохраняет стабильность соединений лучше, чем v1, благодаря непрерывному масштабированию.
Клонирование: быстрые клоны по принципу copy-on-write в пределах одного региона для разработки/тестирования, анализа данных или проверки изменений по схеме blue/green. Клоны эффективно используют пространство и занимают дополнительное место только для изменённых страниц. Можно создавать цепочки клонов; удаляйте их по завершении работы, чтобы освободить хранилище.

Кеширование и общие файловые системы: ElastiCache и EFS

ElastiCache for Redis в сравнении с Memcached:

Redis: продвинутые структуры данных, репликация, Pub/Sub, Lua, потоки, геопространственные данные, отсортированные наборы и персистентность через снимки; поддерживает автоматическое переключение при сбоях Multi-AZ и Redis Global Datastore для создания реплик чтения между регионами. Выбирайте Redis, когда вам нужны сложные типы данных, долговечность (восстановление из снимка) или высокая доступность с отработкой отказа.
Memcached: простой, многопоточный, без репликации и персистентности; горизонтальное масштабирование через шардирование на стороне клиента; не хранит состояние (stateless) и легко масштабируется горизонтально. Выбирайте Memcached для эфемерного, чистого кеширования с очень высокой пропускной способностью и когда вы хотите управлять шардированием на клиенте. Режим кластера Redis и группы репликации:
Режим кластера отключён (Cluster mode disabled): один шард с основным узлом и репликами; вертикальное масштабирование или ограниченное горизонтальное масштабирование через реплики чтения.
Режим кластера включён (Cluster mode enabled): шардирование по хеш-слотам между несколькими основными шардами, каждый с репликами, что обеспечивает почти линейное горизонтальное масштабирование. Группы репликации (Replication groups) определяют топологию основной узел/реплики и отработку отказа Multi-AZ. Резервные копии создаются для каждой группы репликации; тестируйте отработку отказа для проверки RTO.

Amazon EFS для общих файлов POSIX:

Точки монтирования (Mount targets): создайте по одной в каждой AZ вашего VPC, чтобы обеспечить пути доступа внутри AZ и доступность. Группы безопасности на точках монтирования контролируют трафик NFS; используйте EFS mount helper для шифрования TLS при передаче и авторизации через IAM, если это необходимо.
Точки доступа (Access points): принудительно устанавливают корневой каталог и идентификатор POSIX (UID/GID) для приложений, обеспечивая изоляцию мульти-арендных сред и простое монтирование с минимальными привилегиями для ECS/EKS/EC2 без необходимости координировать управление пользователями на уровне ОС.
Управление жизненным циклом и классы хранения: EFS Standard и Standard-IA (региональные, multi-AZ) и One Zone/One Zone-IA (в одной AZ). Интеллектуальное распределение по уровням (Intelligent tiering) автоматически перемещает файлы между классами Standard и IA на основе времени последнего доступа; также можно задать явные политики перехода. Выбирайте варианты One Zone для воссоздаваемых или некритичных данных для экономии затрат. Комбинируйте с AWS Backup для централизованных политик и резервного копирования между аккаунтами/регионами.

Миграция данных: DMS, Snowball и DataSync

AWS Database Migration Service (DMS): онлайн-миграция с минимальным временем простоя, использующая полную загрузку и захват измененных данных (change data capture, CDC). Поддерживает гомогенные и гетерогенные миграции с помощью встроенного преобразования схем (с использованием AWS Schema Conversion Tool для сложных преобразований). Используйте для миграции по типу lift-and-shift в RDS/Aurora, в DynamoDB (через сопоставление JSON) или для постоянной репликации с целью снятия нагрузки чтения или поэтапного переключения. Подбирайте размер инстансов репликации с учетом пиковых скоростей изменений; убедитесь, что исходные журналы (например, binlog/redo) хранят достаточно истории.
AWS Snowball (Edge Storage/Compute Optimized): офлайн-передача данных петабайтного масштаба, когда сети ограничены/дороги или когда необходимо быстро заполнить большие наборы данных в S3/EFS. Объединяйте несколько устройств в цепочку для загрузки данных объемом в много петабайт. Используйте для начальной массовой загрузки, сбора данных в удаленных/периферийных точках или для миграции из центров обработки данных с ограниченными ресурсами. Данные шифруются сквозным образом с помощью KMS; отслеживание устройств и пломбы для контроля вскрытия обеспечивают сохранность цепочки поставок.
AWS DataSync: ускоренная онлайн-передача данных с NFS/SMB в S3/EFS/FSx и между сервисами хранения/регионами AWS. Сервис управляет обнаружением инкрементальных изменений, распараллеливанием, сжатием, контролем пропускной способности, планированием и проверками целостности. Используйте для перемещения повторяющихся дельта-изменений, для гибридных рабочих процессов и для замены пользовательских скриптов rsync управляемой автоматизацией. Разверните агент DataSync в локальной среде для доступа к локальному хранилищу.

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

Shopify необходимо модернизировать свой глобальный конвейер обработки медиафайлов продуктов и данных каталога, одновременно повышая отказоустойчивость и снижая задержки для покупателей по всему миру. Компании необходимо: реплицировать изображения продуктов между регионами и аккаунтами со строгим RPO, сократить задержку чтения из DynamoDB в Северной Америке и Европе, мигрировать локальные NFS-ресурсы с постоянными дельта-изменениями и упростить операции с RDS с помощью надежных резервных копий.

Реализовать S3 CRR с Replication Time Control из основного бакета с медиафайлами в us-east-1 (аккаунт мерчандайзинга) в целевой бакет в eu-west-1 (аккаунт доставки).

Почему: CRR обеспечивает межрегиональное и межаккаунтное разделение для соблюдения принципа наименьших привилегий и суверенитета данных. RTC предоставляет SLA на репликацию в 15 минут и мониторинг для RPO, соответствующего требованиям комплаенса. Межаккаунтная политика бакета гарантирует, что исходная роль репликации имеет права на запись, а указание целевого ключа KMS сохраняет домены шифрования.

Определить правила репликации S3 с фильтрацией по префиксу и тегу для разделения оригиналов, миниатюр и логов, а также включить репликацию маркеров удаления. Использовать S3 Batch Replication для заполнения устаревших объектов.

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

Преобразовать каталог продуктов и данные об остатках в глобальную таблицу DynamoDB в регионах us-east-1 и eu-west-1; переключить таблицы на режим on-demand capacity и добавить кластеры DAX в каждом регионе для API с высокой нагрузкой на чтение.

Почему: Глобальные таблицы обеспечивают режим active-active для записи с низкими задержками при локальном чтении/записи и непрерывной репликацией. Режим on-demand устраняет риск, связанный с планированием пропускной способности во время всплесков трафика. DAX снижает задержки P99 для «горячих» чтений, защищая DynamoDB от пиковых нагрузок.

Перевести реляционную нагрузку заказов на Amazon Aurora MySQL с эндпоинтами для записи и чтения; добавить небольшой ридер Aurora Serverless v2 для аналитики с пиковыми нагрузками и включить автоматическое резервное копирование с политикой хранения 14 дней.

Почему: Эндпоинты кластера/ридера разделяют чтение и запись и минимизируют сбои во время обслуживания или аварийного переключения. Serverless v2 экономично поглощает непредсказуемые всплески аналитической нагрузки. Автоматическое резервное копирование обеспечивает восстановление на определенный момент времени (PITR) и упрощает процессы восстановления.

Внедрить ElastiCache for Redis (в режиме кластера) для хранения сессий и кэширования доступности продуктов с Multi-AZ и резервным копированием через снимки; установить TTL в соответствии с бизнес-SLA.

Почему: Структуры данных Redis и отказоустойчивость Multi-AZ обеспечивают быстрые сессии с сохранением состояния и инвалидацию кэша почти в реальном времени. Режим кластера позволяет горизонтально масштабироваться по мере роста размера каталога и трафика.

Создать региональную файловую систему EFS с точками монтирования в каждой AZ приложения и точками доступа (Access Points) для рабочих нагрузок, требующих общего хранилища POSIX (например, обработчики медиафайлов). Включить переходы жизненного цикла EFS в класс IA через 30 дней.

Почему: EFS предоставляет эластичное общее хранилище в нескольких AZ; Access Points обеспечивают изоляцию для каждого приложения и идентификацию POSIX. Управление жизненным циклом автоматически сокращает затраты на «холодные» данные, которые остаются доступными.

Мигрировать локальные медиабиблиотеки NFS с помощью AWS DataSync, используя запланированные задачи для ночной инкрементальной синхронизации в S3 и EFS.

Почему: DataSync лучше справляется с обнаружением изменений, распараллеливанием, проверкой целостности и контролем пропускной способности, чем специальные скрипты rsync, автоматизируя обработку постоянных дельта-изменений с минимальными операционными затратами.

Перенести устаревший каталог PostgreSQL в Aurora с помощью AWS DMS (полная загрузка плюс CDC) и AWS Schema Conversion Tool, где это необходимо; выполнить переключение после того, как отставание CDC будет устранено.

Почему: DMS обеспечивает миграцию почти без простоя, а непрерывная репликация гарантирует паритет данных на момент переключения. SCT выполняет преобразования, специфичные для движка базы данных.

Загрузить исторические медиафайлы объемом в несколько петабайт в S3 с помощью устройств Snowball Edge, а затем переключиться на DataSync для постоянных инкрементальных обновлений.

Почему: Snowball ускоряет начальную массовую передачу, не перегружая WAN-каналы; DataSync поддерживает непрерывные обновления после начальной загрузки с проверкой и планированием.

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

← Событийно-ориентированные архитектуры и автоматизация · Все домены · Сетевое взаимодействие и доставка контента →

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