Использование функции шага для синхронизации первичного источника данных с вторичными источниками данных и запуска действий на основе обновлений данных

Question

У меня есть приложение, которое действует как уровень данных и отвечает за выполнение всех операций CRUD в базе данных. Из-за проблемы доступности мы поддерживаем кэш Redis поверх него, который в конечном итоге будет выступать в качестве вторичного источника данных. Попадание в первичные источники данных часто приводит к проблемам с удушением и задержкой.

Определенные действия также запускаются на основе обновлений, опубликованных в базе данных.

Я пытаюсь абстрагироваться от обновлений вторичного источника данных и действий, запускаемых на основе этих обновлений, от уровня доступа к данным до безсерверной архитектуры.

Подходит ли пошаговая функция для упомянутого варианта использования? Или мне стоит подумать о другой архитектуре?

Текущая архитектура

Answer 1

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

Я бы использовал SNS для раздачи обновлений в несколько очередей SQS:

• Очередь #1 запускает лямбда-функцию, которая обновляет ваши данные в Redis
• Очередь № 2 используется для клиентских обновлений (что бы это ни значило в вашем случае)

Я не вижу причины использовать здесь пошаговые функции, поскольку SQS гарантирует, что каждое сообщение обрабатывается хотя бы один раз.

          +----------+
     +---->Primary DB|
     |    +----------+      +----------------+      +------------+    +-----+
     +                      |                |      |            |    |     |
Change                +----->  SQS-Queue #1  +------>   Lambda   +---->Redis|
     +                |     |                |      |            |    |     |
     |                |     +----------------+      +------------+    +-----+
     |    +-----------+
     |    |           |
     +---->   SNS     |
          |           |
          +-----------+
                      |     +----------------+
                      |     |                |
                      +-----> SQS-Queue #2   | <------ Clients
                            |                |
                            +----------------+

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

Answer 2

Согласно часто задаваемым вопросам AWS StepFunctions:

Вам следует рассмотреть AWS StepFunctions , когда вам нужно координировать сервисные компоненты при разработке масштабируемых и проверяемых приложений. Вам следует рассмотреть возможность использования Amazon Simple Queue Service(Amazon SQS), когда вам нужна надежная, хорошо масштабируемая размещенная очередь .для отправки, хранения и получения сообщений между службами. StepFunctions отслеживает все задачи и события в приложении.Amazon SQS требует, чтобы вы реализовали собственное отслеживание на уровне приложения, особенно если ваше приложение использует несколько очередей. Консоль StepFunctions и API-интерфейсы видимости предоставляют представление, ориентированное на приложение, которое позволяет искать выполнения, детализировать детали выполнения и администрировать выполнения.Amazon SQS требует реализации такой дополнительной функциональности. StepFunctions предлагает несколько функций, облегчающих разработку приложений, таких как передача данных между задачами и гибкость в распределении задач. Amazon SQS требует, чтобы вы реализовали некоторые функции на уровне приложения.. Хотя вы можете использовать Amazon SQS для создания базовых рабочих процессов для координации вашего распределенного приложения, вы можете получить это готовое средство с помощью StepFunctions наряду с другими возможностями уровня приложения.

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

1. Важен ли порядок обработки? Вы хотите предотвратить обработку одной записи, которая идет первой, после того, как запись идет позже?

2. Важен ли порядок вставки во вторичный источник данных?

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

Обратите внимание, что если передаваемые фрагменты данных невелики и происходят очень часто, возможно, лучше использовать AWS Kinesis Data Streams и AWS Kinesis Firehose. Если вы все же решите использовать пошаговые функции для высокой частоты событий и короткой продолжительности, выберите экспресс-процессы , а не стандартные рабочие процессы .

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