AWS балансировщик для 2-way streaming

[Igor Sharewell]

Здравствуйте,

Столкнулись с такой проблемой:
У нас есть комнаты для разговоров 1 на 1. Подключение между ними происходит через roomApi.
AWS инстанс стоит за AWS LB. После того, как поднимается второй инстанс, сокет соединения перестают соединяться в одну комнату.
Т.е. из-за балансировщика пользователя каждый раз кидает на разный сервер и из-за этого, он только через раз попадает в комнату ко второму собеседнику.
У вас в документации написано

WebSocket-соединения будут автоматически распределены между активными серверами в балансировщике нагрузки.

Но по какой-то причине, этого не происходит судя по всему, потому что значение connections_websocket, на странице ?action=stat, у каждого из инстансов, тоже разное.

Можете подсказать, в чем может быть проблема или может быть я что-то не так понял в документации?

 

[Max]

Добрый день.

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

К сожалению, это ожидаемое поведение по умолчанию. Балансировщик не знает, что за трафик через него идет и куда он должен пойти.
В документации (п 2.8) приводится пример включения залипания для портов балансирощика. Пример использует куки, генерируемые автоматически на стороне балансировщика. Это работает при подключениях с той же страницы браузера, все они пойдут на один инстанс.
В Вашем случае необходимо выбрать третий пункт

и генерировать куки на стороне клиента. Для двух клиентов, которые хотят войти в одну комнату, куки должны совпадать.
Отметим, что для балансировщика в Google Cloud это недоступно совсем, там возможно только залипание по IP клиента, который для чат-комнат будет в 99% случаев разным. В таком случае (либо если в AWS LB залипание не работает должным образом) выход только один - использовать REST хуки и собственный бэкенд, передавая клиенту адрес конкретного инстанса, где создана чат-комната, чтобы клиент зашел туда, минуя балансировщик.

 

[Igor Sharewell]

Спасибо большое за ответ.

Есть тогда еще 2 вопроса:
1) Правильно ли понимаю, что данная проблема справедлива как для roomApi, так и для обычного соединения? Потому что, следуя вашему гайду, по настройке балансировщика, я не смог добиться того, чтобы у меня отображалось одинаковое кол-во сокет соединений.
2) Подскажите, не предполагается ли поддержка распределенной системы коммуникации между серверами, для простой связи между сокет соединениями? По аналогии с тем, как это реализовано в socket.io через redis. В таком случае, как я понимаю, необходимость в дополнительном backend'е, пропала бы, т.к. каждый из серверов, имел бы информацию о всех сокет соединениях.

 

[Max]

1) Правильно ли понимаю, что данная проблема справедлива как для roomApi, так и для обычного соединения? Потому что, следуя вашему гайду, по настройке балансировщика, я не смог добиться того, чтобы у меня отображалось одинаковое кол-во сокет соединений.

Да. Если есть два инстанса, и балансирощик считает, что может их нагружать, он будет их нагружать случайным образом.

2) Подскажите, не предполагается ли поддержка распределенной системы коммуникации между серверами, для простой связи между сокет соединениями? По аналогии с тем, как это реализовано в socket.io через redis. В таком случае, как я понимаю, необходимость в дополнительном backend'е, пропала бы, т.к. каждый из серверов, имел бы информацию о всех сокет соединениях.

Такая система есть между узлами CDN, Каждый узел знает, какие потоки сейчас опубликованы, и текущее состояние каждого активного узла.
В CDN клиент может подключиться к любому Origin серверу для публикации и к любому Edge серверу для воспроизведения потока.
Бэкенд все равно нужен, чтобы управлять, куда какие паблишеры (WebRTC, RTMP) и подписчики (WebRTC, RTMP, RTSP, HLS) могут подключаться, как правило, эти функции выгоднее разносить по серверам, поскольку они требуют разных настроек. Также бэкенд занимается авторизацией, применяет и раздает подписчикам ключи доступа.