Потоки DynamoDB и глобальные таблицы

DynamoDB Streams фиксирует упорядоченную по времени последовательность изменений отдельных элементов в таблице DynamoDB. Каждый раз при создании, обновлении или удалении элемента DynamoDB записывает в поток запись с описанием изменения. Записи потока доступны в течение 24 часов после создания.

Потоки являются основой событийных архитектур с DynamoDB. Их часто используют для запуска функций Lambda в режиме реального времени, ведения журнала аудита, репликации данных в другое хранилище или аннулирования кэша при изменении данных.

При включении потока Вы выбираете значение StreamViewType, определяющее, какие данные содержит каждая запись потока:

• KEYS_ONLY: только атрибуты первичного ключа изменённого элемента
• NEW_IMAGE: весь элемент в состоянии после изменения
• OLD_IMAGE: весь элемент в состоянии до изменения
• NEW_AND_OLD_IMAGES: состояние элемента до и после изменения

Выбирайте NEW_AND_OLD_IMAGES для аудита (чтобы видеть, что изменилось), NEW_IMAGE для репликации или обновления кэша, а KEYS_ONLY, если нужно только знать, какой элемент изменился, и получать его текущее состояние отдельно.

Наиболее распространённый способ использовать поток DynamoDB — AWS Lambda. Lambda опрашивает поток и вызывает Вашу функцию, передавая ей пакет записей потока. Lambda автоматически выполняет опрос, фиксацию контрольных точек и повторные попытки.

Основные параметры настройки: размер пакета (число записей за один вызов, до 10 000), разделение при ошибке (разделение неудачного пакета для обнаружения проблемной записи) и назначение при сбое (SQS или SNS для необрабатываемых записей). Lambda читает данные из каждого сегмента параллельно, поэтому степень параллелизма равна числу сегментов в потоке.

Практические варианты использования DynamoDB Streams на экзамене SAA-C03:

• Межрегиональная репликация: Lambda читает поток и записывает изменения в таблицу в другом Region (до появления Global Tables это был стандартный шаблон)
• Аннулирование ElastiCache: при изменении элемента DynamoDB Lambda аннулирует или обновляет соответствующий ключ кэша
• Синхронизация поискового индекса: отправка изменений элементов в OpenSearch Service для полнотекстового поиска по данным DynamoDB
• Журналирование аудита: запись каждого изменения в S3 или хранилище соответствия требованиям законодательства
• Событийные микросервисы: запуск последующих сервисов при изменении определённых элементов

Глобальные таблицы DynamoDB обеспечивают полностью управляемую мультирегиональную репликацию с активными операциями в нескольких регионах. Каждый Region получает полную копию таблицы, и во все копии можно одновременно выполнять запись. Записи из любого Region асинхронно реплицируются во все остальные Region примерно за 1 секунду.

Глобальные таблицы поддерживают два важных сценария: чтение и запись с низкой задержкой для пользователей по всему миру (каждый пользователь выполняет чтение и запись в ближайшем Region) и мультирегиональное аварийное восстановление с активными операциями в нескольких регионах (приложение продолжает работать в любом сохранившемся Region без потери данных после последней репликации).

Чтобы создать глобальную таблицу, сначала создайте таблицу с включённым DynamoDB Streams (NEW_AND_OLD_IMAGES требуется глобальным таблицам для внутренней работы). Затем добавьте реплики в нужных Region. AWS создаёт таблицу-реплику в каждом добавленном Region и начинает двунаправленную синхронизацию данных.

Глобальные таблицы (версия 2019.11.21) являются текущим стандартом и поддерживают пропускную способность по требованию или выделенную пропускную способность с автоматическим масштабированием. Реплика в каждом Region должна иметь одинаковое имя таблицы. Вы можете в любое время добавлять Region в глобальную таблицу и удалять их из неё.

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

На практике это означает, что при двух почти одновременных конфликтующих обновлениях одно из них будет принято, а второе перезапишется. Приложения следует проектировать так, чтобы избегать одновременной записи в один элемент из разных Region. Если конфликты возникают часто, рассмотрите возможность направлять все записи для определённого пользователя или сущности в один основной Region.

В глобальных таблицах записи в одном Region автоматически реплицируются во все остальные Region. Каждая реплицированная запись расходует WCU в целевых Region: если у Вас 3 Region, одна запись обходится примерно в 3× WCU суммарно по всем Region. Планируйте пропускную способность с учётом этого.

Чтение в каждом Region расходует RCU локальной реплики. Чтение с итоговой согласованностью (режим по умолчанию) использует локальные данные, а строго согласованное чтение между Region не поддерживается. Для большинства глобальных приложений итоговая согласованность с задержкой между Region примерно в 1 секунду является приемлемой.

Важное различие для экзамена SAA-C03: глобальные таблицы DynamoDB поддерживают активные операции в нескольких регионах (все Region принимают чтение И запись), тогда как межрегиональные реплики для чтения RDS доступны только для чтения (реплику можно лишь повысить до основной, чтобы разрешить запись, при этом репликация прекращается).

Используйте глобальные таблицы DynamoDB, если Вам нужны: запись в активном режиме в нескольких регионах, доступ из любой точки мира менее чем за 100 мс или межрегиональное аварийное восстановление без потери точки восстановления для данных NoSQL. Используйте межрегиональные реплики RDS, если Вам нужны: глобальное масштабирование чтения для реляционной базы данных или тёплая резервная копия для аварийного восстановления, которую можно повысить до основной при отказе.

Распространённые архитектурные шаблоны, объединяющие Streams и Lambda:

• Разветвление: Lambda читает поток и публикует данные в SNS, который распределяет их по нескольким очередям SQS для независимых потребителей
• Агрегация: Lambda накапливает изменения и обновляет итоговые значения в отдельной таблице DynamoDB (например, ежедневное число заказов)
• Кэш с отложенной записью: при каждом событии потока Lambda обновляет ElastiCache, чтобы данные можно было читать из кэша
• Уведомление: поток запускает Lambda, которая отправляет электронное письмо через SES или push-уведомление через SNS при изменении определённого условия

В качестве альтернативы DynamoDB Streams Вы можете направлять изменения на уровне элементов в поток данных Amazon Kinesis. Это полезно, когда Вам требуется более длительное хранение (до 1 года вместо 24 часов для встроенных DynamoDB Streams), больше потребителей или интеграция с сервисами, которые считывают данные из Kinesis.

Интеграция с Kinesis Data Streams включается отдельно для каждой таблицы и не заменяет DynamoDB Streams — оба механизма можно включить одновременно. Это более новая функция (появилась в 2021 году), которая расширяет конвейер событий изменений DynamoDB без необходимости создавать собственную логику репликации.

Проверьте, насколько хорошо Вы усвоили концепции AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что DynamoDB Streams фиксирует изменения на уровне элементов в течение 24 часов и интегрируется с Lambda для обработки событий, Global Tables обеспечивают мультимастерную репликацию в нескольких Region с разрешением конфликтов по принципу «побеждает последняя запись», а интеграция с Kinesis Data Streams увеличивает срок хранения за пределами 24-часового окна потока. Далее мы рассмотрим размещённые зоны Route 53 и типы записей DNS.