Стійкість сесії (Липкі сесії)

Стійкість сесії, також відома як "липкі" сесії (sticky sessions), — це техніка балансування навантаження, що використовується проксі-серверами для забезпечення того, щоб усі запити від певного клієнта послідовно маршрутизувалися до одного й того ж бекенд-сервера протягом усієї тривалості його сесії.

Цей механізм вирішує проблему, що виникає зі stateful-застосунками в середовищі з балансуванням навантаження. Багато веб-застосунків зберігають дані, специфічні для сесії (наприклад, вміст кошика покупок, статус автентифікації користувача, персоналізовані налаштування), на сервері. Без стійкості сесії наступний запит клієнта може бути спрямований балансувальником навантаження до іншого бекенд-сервера. Якщо цей сервер не містить даних сесії клієнта, стан сесії буде втрачено, що призведе до помилок, необхідності повторної автентифікації або змусить клієнта перезапустити взаємодію. "Липкі" сесії запобігають цьому, "прив'язуючи" клієнта до певного сервера після встановлення початкового з'єднання.

Як працює стійкість сесії

Проксі-сервери реалізують стійкість сесії за допомогою різних методів, насамперед шляхом ідентифікації клієнта, а потім зіставлення цього клієнта з певним бекенд-сервером.

Методи ідентифікації клієнта

Хеш IP (хешування вихідного IP)

Цей метод використовує IP-адресу клієнта як ключ для визначення бекенд-сервера. Проксі хешує IP-адресу клієнта та використовує отримане значення для вибору сервера з доступного пулу. Це гарантує, що всі запити, що надходять з однієї IP-адреси, спрямовуються на той самий сервер.

• Механізм: hash(client_ip) % number_of_servers
• Переваги: Простий у реалізації, не вимагає файлів cookie на стороні клієнта або модифікації застосунку.
• Недоліки:
  • Дисбаланс навантаження: Якщо багато клієнтів використовують одну й ту ж публічну IP-адресу (наприклад, за NAT-шлюзом, корпоративною мережею), цей єдиний сервер може бути перевантажений.
  • Збій сервера: Якщо призначений сервер виходить з ладу, сесія клієнта втрачається, і наступні запити будуть маршрутизовані до нового сервера (потенційно втрачаючи "липкість", якщо розрахунок хешу вказує на інший сервер або проксі переоцінює).
  • Динамічні IP: Клієнти з динамічними IP-адресами можуть втратити свою сесію, якщо їхня IP-адреса змінюється під час сесії.

Стійкість на основі файлів cookie

Це широко використовуваний і більш гнучкий метод. Проксі або застосунок вставляє файл cookie в браузер клієнта. Цей файл cookie містить інформацію, яка використовується проксі для маршрутизації наступних запитів до правильного бекенд-сервера.

Файли cookie, згенеровані проксі

Сам проксі вставляє файл cookie у відповідь HTTP перед відправленням його клієнту. Цей файл cookie зазвичай містить ідентифікатор бекенд-сервера, який обробив початковий запит. При наступних запитах проксі читає цей файл cookie і спрямовує клієнта на ідентифікований сервер.

• Механізм: Проксі перехоплює відповідь, додає заголовок Set-Cookie: PROXY_SESSION_ID=server_id. При наступних запитах проксі читає Cookie: PROXY_SESSION_ID=server_id і пересилає на server_id.
• Переваги: Не вимагає модифікації застосунку, прозорий для застосунку.
• Недоліки:
  • Збій сервера: Якщо ідентифікований сервер виходить з ладу, сесія клієнта втрачається. Проксі має потім маршрутизувати запит до нового сервера та оновити файл cookie, або клієнт отримує помилку.
  • Керування файлами cookie: Вимагає, щоб клієнтські браузери приймали та надсилали файли cookie.

Файли cookie, згенеровані застосунком

Сам бекенд-застосунок створює та керує файлом cookie сесії (наприклад, JSESSIONID для застосунків Java, PHPSESSID для PHP). Проксі налаштовується на перевірку цього конкретного файлу cookie застосунку та використання його значення (або його частини) для визначення цільового бекенд-сервера. Проксі може хешувати значення файлу cookie або витягувати вбудований у нього ідентифікатор сервера.

• Механізм: Застосунок встановлює Set-Cookie: APP_SESSION_ID=unique_session_id. Проксі читає Cookie: APP_SESSION_ID=unique_session_id і використовує це значення для зіставлення з сервером.
• Переваги: Використовує існуюче керування сесіями застосунку, потенційно більш надійне для ідентифікації унікальних сесій.
• Недоліки: Вимагає конфігурації проксі для розуміння форматів файлів cookie, специфічних для застосунків. Збій сервера призводить до втрати сесії.

Стійкість на основі заголовків

Менш поширений, ніж методи на основі хешу IP або файлів cookie, цей підхід використовує спеціальний HTTP-заголовок для передачі інформації про сесію або ідентифікацію сервера. Клієнт або проміжний проксі може вставити цей заголовок.

• Механізм: Проксі читає X-Server-ID: server_123 або X-Client-Session: abcdef і маршрутизує відповідно.
• Переваги: Може бути корисним у специфічних архітектурах API-шлюзів або мікросервісів.
• Недоліки: Вимагає специфічної співпраці клієнта або вихідного проксі для вставки заголовків. Не підходить для стандартних веб-браузерів без клієнтського скриптингу.

Порівняння методів "липких" сесій

Чому стійкість сесії важлива

• Підтримка stateful-застосунків: Необхідна для застосунків, які зберігають дані сесії локально на сервері (наприклад, кошики електронної комерції, сесії входу, багатоетапні форми).
• Досвід користувача: Запобігає втраті сесії, повторним входам або втраті прогресу, що забезпечує більш плавний досвід користувача.
• Простота дизайну застосунку: Зменшує потребу в складних рішеннях для розподіленого керування сесіями (наприклад, зовнішні сховища сесій, такі як Redis або Memcached), дозволяючи застосункам залишатися простішими.

Недоліки та міркування

• Дисбаланс навантаження: Основний недолік. Якщо один сервер обробляє непропорційно велику кількість "липких" клієнтів, він може бути перевантажений, тоді як інші сервери залишаються недовантаженими. Це може нівелювати переваги балансування навантаження.
• Вплив збою сервера: Якщо сервер з активними "липкими" сесіями виходить з ладу, всі клієнти, які "прив'язані" до цього сервера, втратять свої дані сесії. Це може призвести до погіршення досвіду користувача або переривання обслуговування для цих клієнтів.
• Проблеми масштабованості: Може ускладнити горизонтальне масштабування. Додавання або видалення бекенд-серверів може порушити існуючі "липкі" сесії, вимагаючи ретельного керування під час операцій масштабування.
• Споживання ресурсів: Підтримка зіставлення "липкості" (наприклад, у таблиці пошуку) споживає ресурси на проксі.
• Накладні витрати на керування файлами cookie: Для методів на основі файлів cookie існують невеликі накладні витрати на встановлення та читання файлів cookie для кожного запиту.

Приклади конфігурації

Nginx (з відкритим кодом)

Nginx може реалізувати "липкі" сесії за допомогою директиви ip_hash або більш розширених методів на основі файлів cookie з комерційними модулями або сторонніми модулями, такими як nginx-sticky-module-ng.

Хеш IP

http {
    upstream backend {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

У цьому прикладі ip_hash; гарантує, що запити з однієї IP-адреси клієнта послідовно маршрутизуються до того самого сервера в групі backend апстріму.

На основі файлів cookie (використання модуля sticky – зазвичай Nginx Plus або сторонній)

Якщо використовується Nginx Plus або сумісний сторонній модуль:

http {
    upstream backend {
        # Використання файлу cookie, згенерованого проксі, з назвою "route"
        # Значення є ідентифікатором маршруту, призначеним Nginx серверу.
        sticky route $cookie_route;
        server backend1.example.com route=A;
        server backend2.example.com route=B;
        server backend3.example.com route=C;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

Тут sticky route $cookie_route; налаштовує Nginx на використання файлу cookie з назвою route для стійкості сесії. Nginx встановить цей файл cookie зі значенням (A, B або C), що відповідає початково обраному бекенд-серверу.

Крім того, sticky learn можна використовувати для вивчення файлів cookie, згенерованих застосунком:

http {
    upstream backend {
        # Навчання з файлу cookie JSESSIONID застосунку
        sticky learn
               create=$upstream_cookie_JSESSIONID
               lookup=$cookie_JSESSIONID
               zone=client_sessions:1m; # Зона спільної пам'яті для даних сесії
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

Ця конфігурація намагається вивчити файл cookie JSESSIONID, встановлений бекенд-застосунком. Якщо файл cookie присутній, Nginx використовує його значення для маршрутизації наступних запитів до сервера, який його спочатку встановив.

HAProxy

HAProxy пропонує надійні можливості "липких" сесій, підтримуючи як IP-орієнтовані, так і cookie-орієнтовані методи.

Хеш IP (хешування вихідного IP)

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance source  # Використовує IP-адресу клієнта
    server backend1 192.168.1.10:80 check
    server backend2 192.168.1.11:80 check
    server backend3 192.168.1.12:80 check

Директива balance source вказує HAProxy використовувати вихідну IP-адресу клієнта для балансування навантаження, ефективно забезпечуючи "липкі" сесії.

Файл cookie, згенерований проксі

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    cookie SERVERID insert indirect nocache  # Вставити файл cookie з назвою SERVERID
    server backend1 192.168.1.10:80 cookie S1 check
    server backend2 192.168.1.11:80 cookie S2 check
    server backend3 192.168.1.12:80 cookie S3 check

Тут cookie SERVERID insert indirect nocache вказує HAProxy вставити файл cookie з назвою SERVERID у відповідь клієнта. cookie S1, cookie S2 тощо в кожному рядку сервера вказують значення, яке HAProxy має використовувати для цього сервера. Потім HAProxy використовуватиме цей файл cookie для маршрутизації наступних запитів. indirect означає, що файл cookie встановлюється лише якщо клієнт ще не має його, а nocache запобігає кешуванню проксі-серверами відповідей із заголовком Set-Cookie.

Файл cookie, згенерований застосунком

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    appsession JSESSIONID len 52 timeout 3h # Використовувати файл cookie JSESSIONID
    server backend1 192.168.1.10:80 check
    server backend2 192.168.1.11:80 check
    server backend3 192.168.1.12:80 check

Директива appsession JSESSIONID len 52 timeout 3h налаштовує HAProxy на пошук файлу cookie з назвою JSESSIONID (поширений для застосунків Java). len 52 вказує довжину ідентифікатора сесії, яку слід враховувати, а timeout 3h встановлює, як довго HAProxy пам'ятатиме зіставлення сесії з сервером, якщо файл cookie відсутній у запиті. Цей метод вимагає, щоб застосунок встановлював файл cookie JSESSIONID.