Создание масштабируемой и отказоустойчивой системы с использованием AWS ECS

Question

Мы разрабатываем запланированное задание C # (запускаемое каждые несколько часов), которое будет выполняться на экземплярах AWS ECS, которые будут собирать данные о транзакциях в пакетном режиме для тысяч клиентов из конечной точки, изменять данные и затем отправлять их в другую веб-службу.Мы будем поддерживать состояние последней успешной партии в отдельной базе данных (используя некоторую дату создания транзакций).Нам нужно, чтобы система была масштабируемой, чтобы по мере добавления большего количества клиентов мы добавляли дополнительные контейнеры ECS для обработки данных.Есть варианты, которые мы рассматриваем:

1. Каждый контейнер обрабатывает только определенное подмножество данных.Чем больше клиентов добавлено, тем больше содержимого добавлено.Нам нужно было бы поддерживать логическое разделение того, что включает в себя обработку данных клиентов.
2. Все контейнеры обрабатывают всех клиентов.Мы используем какие-то флаги блокировки в базе данных, чтобы другие процессы знали, что данные клиентов обрабатываются.
3. Какой-то другой подход.

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

Answer 1

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

Один контейнер будет запускаться периодически каждые несколько часов и быть генератором заданий. Это создаст один элемент в очереди SQS для каждого клиента, который должен быть обработан. В ответ на элементы, появляющиеся в очереди, ECS запускает несколько «рабочих» контейнеров для потребления элементов из очереди. Это можно сделать для автоматического масштабирования относительно количества элементов в очереди, чтобы быстро раскрутить множество контейнеров, которые могут работать параллельно.

Каждый контейнер будет использовать свой собственный высокопроизводительный параллельный опросщик, подобный этому (https://www.npmjs.com/package/squiss), чтобы начать извлечение элементов из очереди и их обработку. Если работник потерпел неудачу или потерпел крах из-за ошибки, то SQS автоматически восстановит и после того, как истекло время ожидания, элементы из очереди, над которыми работник работал, были сброшены в очередь.

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