AWS Application Load Balancer WebSocket на основе метаданных липкость? - PullRequest
0 голосов
/ 10 октября 2018

У нас есть кластер некоторого сервиса.Клиенты подключаются к кластеру через Websocket.Клиенты ориентированы на узлы в зависимости от группы, к которой они принадлежат (давайте назовем это «конференцией»).

Другими словами, целая группа клиентов (конференция) обслуживается одним конкретным узлом.Таким образом, целевой узел должен быть выбран на основе некоторых метаданных, отправленных при инициализации соединения WebSocket.

Client Tom Hanks connects to Actors     conference -> LB routes to node EU Server
Client Tom Hanks connects to Tesla fans conference -> LB routes to node USA Server

Client Ada Zizkova connects to Actors     conference -> LB routes to node EU Server
Client Ada Zizkova connects to Tesla fans conference -> LB routes to node USA Server
...

Обратите внимание, что это НЕ залипание на основе сеанса HTTP. Сеанс HTTP - этото же самое для того же пользователя.

Все это то, что мы хотели бы иметь.Но в настоящее время мы работаем над простым AWS Elastic Load Balancer, и мы собираемся внедрить эту липкость внутри компании и обойти ELB.

Прежде чем сделать это, я выясняю, может ли ALB сделать то, что я описал выше.Ничего не могу найти, только вот это: Поддерживает ли балансировщик нагрузки приложения WebSockets? Что выглядит как общая липкость соединения.См. Документы AWS здесь .

Как я могу сделать привязку WebSocket на основе метаданных к ALB?(Или с чем-то еще в AWS).

1 Ответ

0 голосов
/ 10 октября 2018

Для большинства приложений вы можете использовать AWS ELB (Классические балансировщики нагрузки) с помощью функции «Sticky Sessions».

enter image description here

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

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

Кроме того, соединения WebSockets по своей природе являются липкими.Если клиент запрашивает обновление соединения до WebSockets, целью, которая возвращает код состояния HTTP 101, чтобы принять обновление соединения, является цель, используемая в соединении WebSockets.После завершения обновления WebSockets прилипание на основе файлов cookie не используется.

Для получения дополнительной информации ознакомьтесь со следующим документом на веб-сайте AWS: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

В конце концов, вы можете использовать AWS ALB(Application Load Balancer), ALB поддерживает веб-сокеты.

Просто замените ELB на ALB и включите липкие сеансы.

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

Для получения дополнительной информации о AWS ALB прочитайте следующий документ на веб-сайте AWS:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html

...