Мультирегиональная архитектура на AWS для уведомлений SNS

Question

Мы тестируем многорегиональную архитектуру для нашего приложения. Который используется несколькими клиентами.

Мы используем aws для репликации баз данных (s3 и dynamicodb), и это решает проблемы доступности данных.

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

Вот несколько соображений / требований, которые мы должны учитывать

1. Клиенты должны иметь возможность получать все уведомления, даже если они находятся только в одном регионе.

2. Приложение должно продолжать работать, даже если один регион выходит из строя. И, если возможно, сообщение может быть воспроизведено при появлении региона.

Вот несколько подходов с плюсами и минусами, которые приходят на ум.

1. Сервер EC2 пишет в оба региона

   Pros.

   а. Требование 1 легко выполняется.

   Cons.

   а. Не уверен, что это выполнимо, так как ни один документ не предлагает сделать это.

   б. не сможет воспроизводить сообщения, если один регион выйдет из строя.

   с. задержка при записи в обоих регионах.

2. Наличие лямбда-функции для записи в обе области. Поскольку лямбда-функции могут подписываться на кросс-регионы sqs и sns. У нас может быть лямбда-функция в обоих регионах, слушающая sns / sqs другого региона и затем записывающая в sns своего региона.

   Плюсы:

   а. Требование 1 выполнено.

   б. Требование 2 будет выполнено, если мы будем использовать sqs вместо sns, где сообщение будет храниться в очереди в течение некоторого времени, если регион не работает, и сообщения будут воспроизводиться при появлении региона. Межрегиональная подписка sqs невозможна и лямбда-функция должна подписаться на sns.

   Минусы:

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

   б. Стоимость лямбда-функции. (хотя это будет минимально)

3. Вместо записи в sns мы пишем в DynamodB и используем глобальную таблицу и потоки DynamodB для отправки уведомлений в обоих регионах.

   Pros.

   а. Требование 1 выполнено.

   б. Требование 2 выполнено, поскольку репликация DynamodBB позаботится о репликации сообщения.

   Cons.

   а. Дорогое решение.

Не могли бы вы предложить, если я что-то упустил или есть какой-то другой шаблон, который мы должны рассмотреть?

глядя на возможные выше подходы, я склоняюсь к подходу 2,

Answer 1

В итоге мы решили, используя этот подход

1. Приложение пишет сообщение в SQS.

2. Лямбда-функция подписана на очередь.

3. Лямбда-функция записывает в sns региона.

Этим мы можем ввести задержки и некоторую предварительную обработку, а также перед отправкой сообщения. Однако IMO лучшим решением было бы использование потока DynamodB для генерации сообщения (не новой таблицы DynamodB, а из таблицы, в которую мы записываем данные), поскольку это означало бы, что когда мы отправляем сообщение в одном конкретном регионе, данные уже был воспроизведен.