Я столкнулся с интересной проблемой. Мы запускаем приложение на основе HTTPS, основанное на состоянии. Состояние поддерживается на основе файла cookie сеанса. Приложение разработано таким образом, что если сеанс внезапно завершается, приложение возвращается на главный экран, все несохраненные данные теряются. Поэтому для нас очень важно поддерживать сессию.
В какой-то момент в прошлом было принято решение использовать для этой цели сервисы AWS, и текущая архитектура имеет ELB, который распределяет нагрузку на группу автоматического масштабирования. В первой архитектуре, которая использовалась, была включена липкая сессия на основе HTTP. В ходе тестирования выяснилось, что при уменьшении масштаба существующие сеансы немедленно закрываются и перенаправляются на доступные экземпляры. Это происходит даже после включения слива (время за 5 минут), что, согласно документам, должно предотвратить это. Может ли кто-нибудь сказать мне, что мы делаем неправильно, и так ли это должно работать?
Мой второй вопрос: мы выяснили, что это не тот случай, когда использование ELB используется для балансировки нагрузки на основе TCP-соединений. В этом случае, когда мы уменьшаем масштаб, старые TCP-соединения сохраняются до тех пор, пока они не будут закрыты или не истечет время ожидания, а новые соединения будут перенаправлены на другие экземпляры. Это текущая установка, которую мы используем. Итак, мой вопрос: почему ELB ведет себя по-разному в обоих случаях, и есть ли способ заставить ELB использовать липкий сеанс HTTP и слив на основе соединения tcp?
Если у вас есть ответ, пожалуйста, поделитесь деталями конфигурации. Спасибо.