Ссылка: https://socket.io/docs/v4/using-multiple-nodes
Недавно мы столкнулись с интригующим сценарием с залипанием сеанса NLB. Наше приложение использовало длинный HTTP-опрос socket.io, для которого требовалось включить липкую сессию. Наш поток трафика был таким:
CloudFront ->API Gateway-›VPC Link-›NLB-›Backend
поэтому домен api.example.com указывал на CloudFront, а CloudFront имел URL-адрес вызова шлюза API в качестве источника.
Мы включили привязку сеанса, а также балансировку нагрузки между зонами на уровне NLB. Но у нас все еще были такие проблемы, как ошибки HTTP 400 из-за «неизвестного идентификатора сеанса». Это произошло потому, что в середине сеанса IP-адрес клиента изменился, что является очень нормальным сценарием, особенно если вы используете какой-либо прокси или VPN.
Согласно документации AWS о закреплении сеанса NLB: «Для TCP-трафика балансировщик нагрузки выбирает цель с использованием алгоритма хэширования потока на основе протокола, исходного IP-адреса, исходного порта, целевого IP-адреса, целевого порта и порядкового номера TCP. TCP-соединения от клиента имеют разные исходные порты и порядковые номера и могут направляться к разным целям. Каждое отдельное TCP-соединение направляется к одной цели на весь срок действия соединения». Поэтому, если IP-адрес изменится, запрос может перейти к другому серверному экземпляру.
Чтобы решить эту проблему, нам пришлось добавить ALB между NLB и серверной частью. Таким образом, поток трафика стал таким:
CloudFront-›API Gateway-›VPC Link-›NLB-›ALB-›Backend
Эта настройка выглядит довольно просто, если запросы используют протокол HTTP. Но наше серверное приложение ожидает протокол HTTPS, чтобы оно могло устанавливать некоторые безопасные файлы cookie для конкретного приложения. Теперь, чтобы добиться этого, мы выполнили следующие шаги:
Шаг 1. Создайте сертификат ACM для *.example.com.
Шаг 2. Создайте целевую группу, которая прослушивает HTTP:80 и указывает на серверный IP-адрес.
