Amazon DVA-C02: Базы данных и кеширование (RDS, Aurora, ElastiCache, Timestream, Proxy) — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

RDS и Aurora: проектирование, масштабирование и шифрование

Проектирование реляционных баз данных на RDS или Aurora начинается с анализа компромиссов рабочей нагрузки между одноузловым RDS и распределенным хранилищем Aurora. Выбирайте Aurora, когда вам требуется высокая масштабируемость чтения и быстрое аварийное переключение: реплики Aurora совместно используют кластерный том, поэтому их «повышение» происходит быстро, в то время как реплики чтения RDS MySQL/Postgres используют асинхронную репликацию на основе binlog и могут отставать. Для масштабирования операций чтения добавляйте реплики чтения и направляйте на них трафик чтения от приложения; используйте эндпоинты чтения (reader endpoints) в Aurora для автоматической балансировки нагрузки между репликами. Для операций записи важны вертикальное масштабирование (класс инстанса) и тщательное проектирование схемы/индексов. Всегда включайте шифрование неактивных данных (at rest) с помощью KMS CMK во время создания — включение шифрования позже потребует создания снимка и восстановления в новый зашифрованный инстанс; это распространенная ловушка. Для защиты данных при передаче (in-transit) используйте принудительное применение TLS/SSL-соединений (RDS предоставляет пакеты CA). Для учетных данных предпочтительно использовать AWS Secrets Manager с автоматической ротацией, применяя встроенный шаблон Lambda для ротации в RDS; программно извлекайте секреты с помощью

undefined

в SDK. Рассмотрите возможность использования IAM-аутентификации для баз данных, чтобы избавиться от статических паролей: сгенерируйте токен через

undefined

(SDK) или

undefined

, а затем подключайтесь с помощью этого кратковременного токена. Используйте для мониторинга Performance Insights, Enhanced Monitoring и CloudWatch; анализируйте журналы медленных запросов и используйте EXPLAIN для выявления «горячих точек» (hotspots).

Пул соединений, RDS Proxy и бессерверные паттерны

Бессерверные функции и приложения с большим количеством подключений часто исчерпывают лимиты соединений с БД. Простой паттерн в Node.js — разместить пул

undefined

в глобальной области видимости Lambda и повторно использовать его между вызовами, но это не решает проблему массового параллельного масштабирования. RDS Proxy — это управляемое решение: создайте прокси с помощью

undefined

, свяжите его с секретами в Secrets Manager и целевыми инстансами RDS/Aurora, а затем используйте эндпоинт прокси в своем приложении. RDS Proxy обеспечивает мультиплексирование соединений, интеграцию с IAM-аутентификацией и аварийное переключение. Для бессерверной Aurora Serverless или когда вы предпочитаете вызовы в стиле HTTP, используйте RDS Data API:

undefined

позволяет Lambda-функциям выполнять SQL-запросы без постоянных TCP-соединений. Распространенный подводный камень — смешивание Data API с подготовленными (provisioned) кластерами. Data API предназначен для бессерверных кластеров и имеет иную семантику задержек и транзакций. Также имейте в виду, что RDS Proxy вводит тайм-аут пула соединений и

undefined

; настраивайте тайм-аут простоя клиента и заимствование соединений для пиковых нагрузок от Lambda. Используйте

undefined

для получения учетных данных и ротируйте их с помощью

undefined

или включите автоматическую ротацию в консоли/SDK.

Стратегии кэширования: ElastiCache, DAX и проектирование кэша

Выбор стратегии кэширования зависит от хранилища данных и паттернов доступа. Для DynamoDB сервис DAX обеспечивает задержку чтения на уровне микросекунд и прозрачную интеграцию с SDK через

undefined

, который является оберткой для

undefined

; он идеально подходит для нагрузок с интенсивным чтением и конечной согласованностью (eventually consistent). Для кэширования данных из реляционных БД или произвольных данных типа «ключ-значение» используйте ElastiCache for Redis для сложных структур данных, персистентности (снимки AOF/RDB), репликации и шардирования в режиме кластера, или Memcached для простого, горизонтально масштабируемого кэширования. Реализуйте паттерн cache-aside для чтения и write-through/write-behind только тогда, когда это приемлемо с точки зрения согласованности данных и сложности реализации. Проектирование ключей критически важно: добавляйте префиксы приложения и версии, используйте разумные значения TTL и избегайте неограниченной кардинальности. Боритесь с лавинообразными обращениями к кэшу (cache stampedes) с помощью паттернов блокировки и обновления (

undefined

или Redlock) или вероятностного заблаговременного обновления TTL. Настраивайте Redis с развертыванием в нескольких зонах доступности (multi-AZ) и автоматическим аварийным переключением; создавайте группы репликации с автоматическим переключением и снимками через

undefined

. Распространенные ловушки включают устаревшие данные в кэше после записи, отсутствие инвалидации при изменении схемы и ожидание абсолютной согласованности. Отслеживайте коэффициент попаданий в кэш (cache hit ratio) и метрики вытеснения (eviction) в CloudWatch и масштабируйте типы узлов или шарды кластера, когда память или CPU становятся узким местом.

Временные ряды с Timestream и паттерны реплик чтения

Amazon Timestream специально разработан для временных рядов: данные загружаются с помощью API WriteRecords из SDK пакетными вызовами WriteRecords, а запрашиваются с помощью TimestreamQuery.query(sql). Проектируйте схему записей с измерениями (dimensions) низкой кардинальности и используйте записи с несколькими показателями (multi-measure records), чтобы уменьшить усиление записи (write amplification). Настраивайте правила хранения в памяти (memory) и на магнитных носителях (magnetic) для каждой таблицы, чтобы хранить свежие данные в «горячем» виде, а старые — дешевле; корректировка хранения критически важна, поскольку размер данных на уровне памяти влияет на стоимость и производительность запросов. Для аналитики используйте специфичные для временных рядов запросы (time_bin или bin) и применяйте фильтры к измерениям (push down filters), чтобы минимизировать объем сканируемых данных. При интеграции временных рядов с реляционными хранилищами выгружайте исторические неизменяемые данные в Timestream, а «горячие» метаданные обслуживайте из RDS/Aurora с помощью ElastiCache. Для масштабирования чтения из реляционных баз данных добавляйте реплики чтения и направляйте на них трафик только для чтения; для Aurora используйте эндпоинты чтения (reader endpoints) и проверяйте задержку репликации (CloudWatch ReplicaLag) перед направлением критически важных запросов на чтение. Распространенная ошибка разработчиков — высокая кардинальность в Timestream или создание ключей кеширования для каждого запроса, что раздувает хранилище и снижает производительность. Используйте пакетную запись и асинхронные конвейеры загрузки данных (Kinesis, Firehose), чтобы сглаживать пики нагрузки и избегать троттлинга.

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

Сценарий: NovaShop управляет мультирегиональной ecommerce-платформой на AWS, используя Aurora MySQL для заказов в us-east-1, API на базе Lambda и глобальный каталог клиентов в DynamoDB. Разработчики используют CI/CD в одном аккаунте AWS и хранят учетные данные БД в Secrets Manager.

Проблема: Во время пиковых распродаж функции Lambda исчерпывают подключения к БД, а каталогу требуется чтение с микросекундной задержкой; разработчикам необходимо обеспечить безопасность с помощью ротации учетных данных и минимальную задержку при чтении данных о продуктах.

Рекомендуемый подход:

1. Создайте RDS Proxy для кластера Aurora с помощью CreateDBProxy, привяжите ARN секрета из Secrets Manager и настройте IAM-аутентификацию; обновите Lambda для использования эндпоинта прокси и получения учетных данных через SecretsManager.getSecretValue().
2. Для каталога разверните кластер Amazon DAX и переключите клиент DynamoDB на AmazonDaxClient({endpoints}), который является оберткой над DynamoDB DocumentClient для чтения с микросекундной задержкой.
3. Включите автоматическую ротацию секрета Aurora в Secrets Manager, используя шаблон Lambda для ротации RDS (rotate-secret или настройте через консоль), и убедитесь, что IAM-роль Lambda имеет право вызывать secretsmanager:GetSecretValue.
4. Добавьте кластер ElastiCache for Redis (в режиме кластера) для кеширования сессий и реализуйте паттерн cache-aside с TTL и блокировкой обновления через SETNX для предотвращения «эффекта толпы» (stampede).

Обоснование: Использование RDS Proxy предотвращает «шторм подключений» при масштабировании Lambda, а IAM/Secrets Manager защищает учетные данные с помощью автоматической ротации; DAX обеспечивает чтение из DynamoDB с микросекундной задержкой, а ElastiCache обрабатывает временное кеширование сессий/чтения, что соответствует лучшим практикам бессерверных вычислений и безопасности.

← Хранилище · Все домены · Обмен сообщениями →

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

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