Предполагая, что на EC2 имеется кластер веб-серверов с эластичной балансировкой нагрузки и автоматической загрузкой (то есть экземпляры запускаются и умирают по запросу), может ли кто-нибудь сказать мне, что происходит с сеансом браузера пользователя? Достаточно ли умен балансировщик нагрузки, чтобы отслеживать сеансы? Или, по крайней мере, достаточно умен, чтобы последовательно отправлять запросы конкретного пользователя в один и тот же экземпляр? Или мне нужно самому искать и решать эту проблему?
Нужна дополнительная информация, это зависит от того, как вы проводите свои сеансы. Хотя некоторые балансировщики нагрузки достаточно «умны» для перенаправления на основе сеансов, полагаться на это на самом деле просто означает, что ваша архитектура в первую очередь сломана.
В идеале вам нужно централизованное или распределенное хранилище сеансов. Хорошие варианты - централизованная база данных, такая как MySQL, или что-то распределенное, например memcached. Вы, вероятно, захотите начать с базы данных и перейти к memcached, если действительно начнете получать трафик.
Какой фреймворк или язык использует ваше приложение?
Нет, ELB не является балансировщиком нагрузки на основе липких сеансов. Это балансировщик нагрузки с нестрогим циклическим перебором, который не принимает во внимание схему вашего сеанса. Некоторые детали исследуются здесь: http://clouddevelopertips.blogspot.com/2009/07/elastic-in-elastic-load-balancing-elb.html
Если вы хотите использовать elb, вам необходимо убедиться, что ваша схема сеанса может обрабатывать запросы, маршрутизируемые на любой из серверов в пуле elb по любому запросу.
У вас есть два варианта.
Ваш лучший вариант - сделать так, как сказал anveo. Использование централизованного хранилища сеансов означает, что они могут попасть на любой из ваших серверов и по-прежнему иметь свой сеанс. Вы можете запускать и останавливать экземпляры, не беспокоясь о последствиях для пользователей.
Другой вариант - использовать параметр липкости ELB. Вы можете создать файлы cookie сеанса, и балансировщик нагрузки будет каждый раз направлять cookie сеанса в один и тот же экземпляр. Проблема в том, что вы не можете свободно уничтожать экземпляры, потому что люди теряют свои сеансы (если это имеет значение). Единственный плюс этого метода в том, что его очень просто реализовать. И проигрыш сессий обычно не так уж и плох. Пользователь просто снова войдет в систему.