Распределение нагрузки приложения AWS: очень большое время начального подключения
С точки зрения наблюдателя симптомы идентичны этой проблеме. Сценарий такой же: приложение Angular, которое отправляет предварительные запросы в API REST, а предварительные запросы занимают примерно от 50% раз до 1,3 секунд (иллюстрация такая же, как на рисунке). связанный вопрос).
Кроме того, websocket часто зависал, пока socket-io наконец не установил соединение. Проблема была более выражена в Chrome и меньше в Safari/Firefox.
Однако мы используем ALB, а не ELB, и все наши подсети общедоступны.
3 ответа
Решение, которое мы нашли работающим, состояло в том, что все подсети должны были проходить через один и тот же интернет-шлюз - одна и та же таблица маршрутов применялась ко всем подсетям.
Когда это было сделано, все запросы начали проходить быстрее, и websocket соединяется немедленно, без повторного соединения.
Была похожая проблема. LB должен быть настроен на использование как минимум 2 зон доступности. Вы должны выбрать, какую подсеть в каждом AZ следует использовать. В моем случае в одной из сетей были неверные настройки ACL, которые в основном запрещали весь трафик. Это будет означать, что служба, по-видимому, будет отключаться в течение минуты или около того, когда DNS решит предоставить вам IP-адрес неработающего интерфейса LB. Затем он снова начнет работать после истечения срока действия кэша DNS и получения IP-адреса для работающего интерфейса.
Мы также столкнулись с той же проблемой и обнаружили, что у нас есть одна общедоступная подсеть в одной зоне и частная подсеть в другой зоне ALB. Мы исправили это, выбрав общедоступную подсеть в обеих зонах доступности. Как правило, для общедоступных ALB все подсети должны быть общедоступными, хотя трафик, куда вы перенаправляете (EC2, лямбда), также может быть в частной подсети.