Прилипания HTTP-запросов в контексте прокси-сервера

Сегодня пользователи ожидают от веб-приложений мгновенного отклика. Оптимизация производительности становится критически важной задачей для разработчиков. Один из способов повысить эффективность работы серверов и уменьшить время отклика – прилипание http-запросов.

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

Меня зовут Ринат Фатхуллин, я владелец продукта Platform V SynGX – веб- и обратного прокси-сервера на базе Nginx. Наш продукт полностью заместил Nginx Plus в Сбере, в том числе благодаря расширенной поддержке «липких» сессий. 

В этой статье подробно рассмотрим сценарии использования и особенности этого подхода. Материал будет особенно интересен специалистам, которые занимаются обеспечением бесперебойной работы высоконагруженных сервисов. 

Зачем нужны «липкие» сессии

В контексте прокси-сервера прилипание, или «липкие» сессии, – это механизм, позволяющий сохранять связь между первым и последующими HTTP-запросами клиента и узлом в группе балансировки, который обрабатывает эти запросы. Наличие связи означает, что все запросы клиента с определенными свойствами прокси-сервер будет перенаправлять на один и тот же узел в группе балансировки. 

Преимущество этого подхода лежит на поверхности. Когда приходит первый запрос от клиента на экземпляр сервиса, сервис начинает запрашивать данные по клиенту у других сервисов и сохранять у себя в кеше. Сбор данных занимает время. И если запросы клиента каждый раз будут попадать на разные экземпляры сервиса, собирать данные придется многократно, а это нецелесообразно. Если данные уже есть в кеше, сервис сможет быстрее ответить на клиентский запрос.

Механизм прилипания решает еще одну важную задачу – распределение клиентских запросов на основании определенных характеристик. Например, зная IP клиентского запроса, мы можем определить страну или город клиента с помощью базы MaxMindDB и перенаправить запрос на узел, который обслуживает все клиентские запросы из этой страны или города. 

Как правило, разработчики веб-сервисов сами определяют, необходимо ли им прилипание клиентских запросов, чтобы улучшить клиентский опыт и пользовательские характеристики сервиса. Обычно прилипание запросов требуется в рамках сеанса пользователя по работе с сервисом. Пример такого сеанса – 15 минут, которые человек потратил на посещение интернет-магазина, поиск и отбор товаров, оформление заказа.

Прилипание дает ряд преимуществ для сервисов, которые поддерживают создание сеанса:

• Согласованность: все запросы в рамках сеанса обрабатываются одним и тем же узлом, поэтому данные пользователя остаются согласованными. Это особенно важно для приложений, которые хранят данные сеанса локально на сервере.
• Производительность: данные пользователя в рамках сеанса не нужно синхронизировать между узлами сервиса, поэтому производительность сервиса может быть выше за счет сокращения накладных расходов.
• Простота: прилипание запросов может упростить архитектуру сервиса, поскольку разработчикам не нужно внедрять распределенные кэши или распределенные базы данных, в которых данные должны быть одинаковыми и согласованными.

Но несмотря на очевидные преимущества у прилипания запросов есть и ряд недостатков: 

• Влияние на масштабируемость: прилипание может приводить к неравномерному распределению нагрузки. Определенные узлы могут быть перегружены, в то время как другие недостаточно загружены. Этот дисбаланс может повлиять на общую производительность и масштабируемость сервиса.
• Недостаточная надежность: в случае сбоя узла сервиса все сеансы, связанные с этим узлом, прерываются, а данные теряются. Это приводит к ошибкам сервиса. Реализовать отработку отказа в этих случаях может быть сложно.
• Влияние на управление состоянием: сервисы с прилипанием запросов должны управлять состоянием сеанса пользователя на стороне сервера. Это может усложнить развертывание и масштабирование, особенно в распределенных средах.

Все эти моменты стоит учитывать, если вы планируете воспользоваться возможностями «липких» сессий.

Полный текст статьи на Хабре