Amazon SOA-C02: Базы данных и кэширование — Руководство по подготовке

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Базы данных и кеширование — это ключевые операционные обязанности администратора SysOps: они обеспечивают постоянное хранилище, доступность и чтение с низкой задержкой для приложений. Эта область знаний охватывает управление реляционными базами данных (RDS и Aurora), масштабирование пропускной способности чтения/записи, репликацию и поведение при сбое, а также использование ElastiCache для снижения нагрузки на БД. Правильная настройка резервных копий, групп параметров, мониторинга и шаблонов инвалидации кеша предотвращает потерю данных и сокращает количество операционных инцидентов.

Операции с RDS и Aurora, резервное копирование и Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) и Amazon Aurora (совместимая с MySQL и PostgreSQL) — это управляемые реляционные движки с разной семантикой эксплуатации. Multi-AZ для RDS создает синхронную резервную копию в другой зоне доступности (AZ) — она управляется AWS, автоматическое переключение на нее происходит в течение нескольких минут, ручное повышение до основного экземпляра не требуется, а резервный экземпляр недоступен для чтения. Aurora разделяет эндпоинты для записи и чтения: эндпоинт для записи — это эндпоинт кластера, обслуживаемый основным экземпляром, а Aurora использует распределенное хранилище, которое автоматически реплицируется между зонами доступности и обычно может выполнять переключение при сбое быстрее, чем RDS, поскольку хранилище является общим.

Настройте резервное копирование и хранение с помощью:

Автоматические резервные копии: включите их, указав срок хранения (например, modify-db-instance --backup-retention-period 7). Они обеспечивают восстановление на определенный момент времени (PITR) с точностью до секунды в пределах окна хранения для поддерживаемых движков.
Снимки вручную: используйте create-db-snapshot (или create-db-cluster-snapshot для Aurora), чтобы создать сохраняемый снимок; снимки существуют до тех пор, пока вы их не удалите.
Восстановление PITR: aws rds restore-db-instance-to-point-in-time для RDS или restore-db-cluster-from-snapshot с последующим созданием экземпляров для Aurora.

Критерии для принятия решений:

Используйте Multi-AZ для высокой доступности и автоматического переключения при сбое, когда критична доступность для записи, а чтение с резервного экземпляра не требуется.
Используйте Aurora (кластерное хранилище), когда вам нужны высокие показатели IOPS, быстрое переключение при сбое и автоматическое масштабирование хранилища.
Используйте реплики чтения для масштабирования операций чтения и для аварийного восстановления в другом регионе (они асинхронны и могут быть повышены до основного экземпляра).

Примеры операционных команд CLI:

Включить Multi-AZ: aws rds modify-db-instance --db-instance-identifier mydb --multi-az --apply-immediately
Создать автоматический снимок: aws rds create-db-snapshot --db-snapshot-identifier snap1 --db-instance-identifier mydb
Восстановить на момент времени (PITR): aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier mydb --target-db-instance-identifier mydb-restore --restore-time "YYYY-MM-DDTHH:MM:SSZ"

Реплики чтения, переключение при сбое и стратегии репликации

Реплики чтения — это асинхронные копии (экземпляры RDS или Aurora для чтения), которые в основном используются для масштабирования трафика чтения и снятия нагрузки от отчетности. У них есть задержка репликации (отслеживайте метрику ReplicaLag), и они не подходят для обеспечения строгой согласованности. Реплики чтения могут быть повышены до самостоятельных экземпляров БД для поддержки аварийного восстановления.

Стратегии репликации и выбор:

Синхронная (резервный экземпляр RDS Multi-AZ) — гарантия отсутствия расхождения данных, нет возможности чтения с резервного экземпляра.
Асинхронные реплики чтения — масштабирование чтения, возможность создания копий в других регионах, риск задержки репликации и потенциальной потери данных при переключении.
Экземпляры чтения Aurora — предоставляют кластерные эндпоинты для чтения, переключение при сбое с низкой задержкой через перенаправление эндпоинта и автоматическую балансировку эндпоинта для чтения.

Операционные шаблоны:

Создать реплику чтения: aws rds create-db-instance-read-replica --db-instance-identifier read1 --source-db-instance-identifier primary
Повысить реплику: aws rds promote-read-replica --db-instance-identifier read1
Мониторинг: используйте метрики CloudWatch DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS и Performance Insights, чтобы принимать решения о добавлении или удалении реплик.

Критерии для принятия решений:

Если вам нужна высокая доступность для записи, выбирайте Multi-AZ. Если вам нужна пропускная способность для чтения и снятие нагрузки от аналитики, выбирайте реплики чтения или экземпляры чтения Aurora.
Для межрегионального аварийного восстановления (DR) создавайте реплики чтения в целевом регионе и рассмотрите возможность автоматического копирования снимков или использования DMS для миграции.

Кеширование с помощью ElastiCache и инвалидация кеша

ElastiCache предлагает Redis и Memcached для снижения нагрузки на БД и уменьшения задержек. Выбирайте Redis, если вам нужны персистентность, репликация, структуры данных и высокая доступность с Multi-AZ и автоматическим переключением при сбое. Выбирайте Memcached для простого горизонтального кеширования, где приоритетами являются шардинг и многопоточная производительность.

Ключевые конфигурации и шаблоны:

Создать кластер Redis с репликами и Multi-AZ: aws elasticache create-replication-group --replication-group-id rg1 --replication-group-description "rg" --engine redis --num-cache-clusters 3 --automatic-failover-enabled
Используйте режим кластера (cluster mode enabled) для Redis, чтобы масштабировать шарды; Memcached требует хеширования на стороне клиента для шардинга.
Политики вытеснения: volatile-lru, allkeys-lru, noeviction — настраивайте в зависимости от того, что вы предпочитаете: вытеснять только ключи с истекшим сроком действия или любые ключи при заполнении памяти.
Отслеживайте CacheHits и CacheMisses для расчета коэффициента попаданий в кеш: hit_ratio = CacheHits / (CacheHits + CacheMisses). Стремитесь к высокому коэффициенту попаданий, чтобы сократить количество чтений из БД.

Стратегии инвалидации кеша:

Cache-aside (кеширование с резервированием): приложение сначала проверяет кеш, при промахе читает данные из БД и заполняет кеш; при записи необходимо явно инвалидировать или удалять данные из кеша.
Write-through/write-behind (сквозная/отложенная запись): запись в кеш распространяется в БД; write-behind выполняет запись в БД пакетами (что усложняет систему).
Time-to-live (TTL): устанавливайте консервативные значения TTL для данных, которые могут устареть; комбинируйте с версионированием кеша или ключами инвалидации для изменений схемы или массовой инвалидации.
Используйте Redis pub/sub или события Lambda для уведомления экземпляров приложения о необходимости распределенной инвалидации.

Группы параметров базы данных, масштабирование и мониторинг

Группы параметров управляют настройками, специфичными для движка (например, max_connections, innodb_buffer_pool_size). RDS использует группы параметров БД для инстансов и группы параметров кластера БД для Aurora. Изменения некоторых параметров требуют перезагрузки (применяются при следующей перезагрузке), другие применяются немедленно.

Паттерны управления:

Создание и изменение группы параметров:

undefined

; затем

undefined

Масштабирование класса инстанса:

undefined

(или во время окна обслуживания, чтобы избежать перезапуска).

Автомасштабирование хранилища: включите для поддерживаемых типов движков; Aurora автоматически масштабирует хранилище.

Сигналы для мониторинга и масштабирования:

Используйте CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) и Performance Insights для выявления медленных SQL-запросов и основных ожиданий.
Включите Enhanced Monitoring и установите гранулярность (например, 1с для устранения неполадок).
Используйте RDS Proxy для управления пулом соединений и уменьшения «шторма соединений» для бессерверных или высоконагруженных приложений.

Процедуры резервного копирования/восстановления и вопросы миграции

Резервное копирование и восстановление должны быть явными и протестированными. Автоматические бэкапы обеспечивают восстановление на точку во времени (PITR) в пределах срока хранения; ручные снэпшоты хранятся до тех пор, пока не будут удалены, и могут быть скопированы в другие регионы и с использованием других ключей KMS. При восстановлении явно указывайте регион и временную метку.

Типичные команды восстановления:

Восстановление на точку во времени (RDS):

undefined

/ или укажите –restore-time

Восстановление из снэпшота (межрегиональное): сначала скопируйте снэпшот (copy-db-snapshot) в целевой регион, а затем восстанавливайте.

Вопросы миграции:

AWS DMS для миграций с минимальным временем простоя (гетерогенных/гомогенных). DMS поддерживает непрерывную репликацию; убедитесь в правильности настроек исходного движка (например, включен binlog для MySQL).
Логическая миграция (mysqldump, pg_dump) для простого экспорта; физическое восстановление из снэпшота для больших наборов данных.
Проверяйте кодировки, различия в группах параметров и ключи KMS для зашифрованных снэпшотов.

Распространенные ошибки и критерии принятия решений

Восстановление бэкапов в неверный регион или на неверное время: всегда проверяйте –region и –restore-time перед восстановлением; используйте скопированный снэпшот в целевом регионе и тестируйте восстановление в тестовой среде.
Предположение, что реплики чтения обеспечивают высокую доступность: помните, что реплики асинхронны; используйте Multi-AZ или Aurora для высокой доступности записи и синхронной репликации.
Игнорирование инвалидации кэша: проектируйте TTL, ключи с версионированием или инвалидацию на основе событий; избегайте الاعتماد исключительно на короткие TTL для обеспечения корректности данных.
Неправильное включение автоматических бэкапов или срока хранения: установите backup-retention-period >0 и проверяйте PITR с помощью тестовых восстановлений; убедитесь, что ключи KMS доступны в целевом регионе для копирования снэпшота.
Изменение групп параметров без перезагрузки: проверяйте ApplyMethod; планируйте перезагрузки в окнах обслуживания для параметров, которые этого требуют, чтобы избежать неожиданных простоев.
Масштабирование без управления соединениями: увеличение класса инстанса без использования RDS Proxy или пула соединений может не решить проблему «шторма соединений»; внедряйте пулинг для управления множеством короткоживущих соединений.

Практическая задача: Сценарий использования

Компания Acme Retail использует основной инстанс MySQL RDS с высокой нагрузкой на чтение и периодическими всплесками аналитических запросов; они сталкиваются с отставанием реплики во время ночных ETL-процессов и наблюдают высокую текучесть соединений, вызывающую всплески CPU.

Включить дополнительную группу реплик чтения для аналитики, изолированную от читателей приложения, и разместить ее в другой AZ или регионе для аварийного восстановления (DR).
Настроить мониторинг реплик (метрика ReplicaLag) и добавить логику автомасштабирования для добавления читателей, когда отставание или ReadLatency превышают пороговые значения.
Развернуть RDS Proxy перед приложением для мультиплексирования соединений и снижения их текучести; соответствующим образом настроить max_connections в группе параметров.
Перенести аналитические задачи на использование аналитической реплики и внедрить кэширование по схеме cache-aside с помощью ElastiCache Redis с подходящими TTL для уменьшения повторяющихся запросов.
Протестировать процедуры аварийного переключения и восстановления: выполнить восстановление на точку во времени (PITR) на тестовом инстансе и проверить шаги по продвижению реплики до основного инстанса.

Этот подход разделяет рабочие нагрузки на чтение, снижает нагрузку от соединений на основной инстанс и использует кэширование для уменьшения объема чтения из БД. Он соответствует лучшим практикам AWS, сочетая масштабирование чтения, пулинг соединений и протестированные процессы резервного копирования/восстановления для поддержания доступности и операционной устойчивости.

← Вычислительные ресурсы и автоматическое масштабирование · Все домены · Бессерверные вычисления и интеграция приложений →

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