Я работаю над простой онлайн-игрой, в которую будут играть стример и его зрители. Стример инициирует сеанс игры, создает игру, а затем предоставляет ссылку для подключения всем своим зрителям. Одна игровая сессия будет длиться ~ 10 минут.

Мой интерфейс — это SPA, который будет взаимодействовать с серверной частью с помощью REST API.

Я бы хотел развернуть его на AWS из-за их привлекательных возможностей вычислений по требованию и цен. Однако я хотел бы оптимизировать с минимальными затратами, сохраняя при этом параметры масштабируемости, используя мои предварительные знания об ожидаемом взаимодействии frontend-backend.

Предположения

1. Иногда в игру могут играть 1000 (или даже больше) человек, в других случаях это может быть 0, с резкими колебаниями от минуты к минуте
2. Серверная часть хранит состояние игры
3. Стример и зрители чередуются по очереди
4. Время принятия решения для зрителей ограничено (скажем, 10-15 секунд).
5. В очередь зрителей каждый зритель может проголосовать за то, какие действия следует предпринять от имени зрителей
   • интерфейс просмотра позволит пользователям повторно голосовать и обновлять свой голос
   • интерфейс просмотра также будет периодически запрашивать у серверной части некоторую статистику о том, как голосуют все остальные зрители — предполагается, что эта статистика обновляется примерно раз в секунду, все сразу
6. Каждый раз, когда стример или зрители заканчивают свой ход, состояние игры повторяется, и некоторый результат отображается на интерфейсе стримера

В течение одного игрового сеанса необходимо поддерживать следующее состояние:

• состояние игры — содержит текущее состояние игры.
• состояние голосования зрителей — содержит информацию о голосах всех зрителей.
• статистика голосов зрителей — содержит моментальный снимок статистики голосов зрителей.

Архитектура

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

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

Итак, из того, что я собрал, оптимальным способом может быть сохранение всего состояния в DynamoDB, реализация полного REST API с использованием лямбда-функций, а затем периодический вызов лямбда-функции (например, 1 раз в секунду), который обновит статистику голосования зрителей, а также обновит состояние игры, когда будет выполнен ход.принято (эта периодическая задача, вероятно, также может быть выполнена в одном экземпляре EC2, вы бы предпочли это вместо запланированного lambda?).

Итак, мои вопросы к вам::

1. Есть ли в этом смысл?
2. Не могли бы вы выбрать другую архитектуру, учитывая ограничения, которые я предоставил? Если да, то почему?
3. Обмениваю ли я простоту разработки (написание отдельного веб-сервера в node против написания большого количества лямбд) на низкую стоимость развертывания?

Сервер: Rest API могут быть созданы с использованием Api Gateway Lambda вместо сервера узла на ECS / ElasticBeanStack с учетом стоимости и масштаба. Даже если вы настраиваете простой сервер узлов в ECS, состояние хранения должно быть выгружено с сервера во внешнее хранилище данных, хотя с помощью фиксированных сеансов elastic load balancer вы можете пересылать запросы от одной игры / пользователя на тот же сервер.

Хранилище данных: для хранения состояния и статистики я вижу два варианта, учитывая, что долговременное хранилище не требуется.

• Redis: Пока число одновременных пользователей не слишком велико, мы можем масштабироваться с помощью автоматического масштабирования. Преимущества заключаются в низкой задержке, даже меньшей, чем у DynamoDB. Но масштабирование может стать проблемой, если общее количество пользователей колеблется от сверхнизкого до сверхвысокого за короткий промежуток времени без лишних затрат. Вот подробный пример.
• DynamoDB: это наверняка работает и легко масштабируется. Вам не нужно задание, которое выполняется каждые 1 секунду, вы можете легко включить динамические потоки с помощью Lambda для обновления статистики.

В большинстве случаев решением является комбинация DynamoDB и Redis.