balancer - Pros y contras de la estrategia Sticky Session/Session Affinity?

sticky session f5 (1)

Un enfoque de alta escalabilidad es utilizar el equilibrio de carga de red para dividir la carga de procesamiento entre varios servidores.

Uno de los desafíos que presenta este enfoque es que los servidores sean conscientes del estado, almacenando el estado del usuario en una "sesión".

Una solución a este problema es la "sesión adhesiva" (también conocida como "afinidad de sesión") en la que cada usuario está asignado a un solo servidor y sus datos de estado están contenidos en ese servidor exclusivamente durante toda la sesión.

¿Cuáles son los pros y los contras del enfoque de "sesión adhesiva"? ¿Lo usas y de ser así estás satisfecho con él?

Pros:

es fácil, no se requieren cambios en la aplicación.
utiliza mejor los cachés de RAM locales (por ejemplo, busca el perfil del usuario una vez, lo almacena en caché y puede volver a usarlo en visitas posteriores del mismo usuario)

Contras:

si el servidor se cae, la sesión se pierde. (Tenga en cuenta que esto es una estafa de almacenar información de sesión localmente en el servidor web, no de sesiones fijas per se). si lo que hay en la sesión es realmente importante para el usuario (por ejemplo, un borrador de correo electrónico) o para el sitio (por ejemplo, un carrito de compras), perder uno de sus servidores puede ser muy doloroso.
dependiendo de la implementación "adhesiva" en su equilibrador de carga, puede dirigir la carga desigual a algunos servidores frente a otros
traer un nuevo servidor en línea no le da mucha carga al nuevo servidor. Si tiene un sistema dinámico de equilibrio de carga para lidiar con los picos, la adherencia puede ralentizar su capacidad de responder rápidamente a un pico. Dicho esto, este es un caso de esquina y realmente solo se aplica a sitios muy grandes y sofisticados.
si tiene relativamente pocos usuarios pero el tráfico de un solo usuario puede saturar un servidor (p. ej., páginas complejas con SSL, AJAX, imágenes generadas dinámicamente, compresión dinámica, etc.), los correos no deseados pueden dañar el tiempo de respuesta del usuario final ya que no repartir la carga de un solo usuario de manera uniforme entre los servidores. Si tienes muchos usuarios concurrentes, esto no es un problema ya que todos tus servidores se inundarán.

Pero si debe usar el estado de sesión local del servidor, las sesiones adhesivas son definitivamente el camino a seguir, e incluso si no usa el estado de sesión local del servidor, la compatibilidad tiene beneficios cuando se trata de la utilización de la memoria caché (consulte más arriba). Su equilibrador de carga debería poder mirar las cookies HTTP (no solo la dirección IP) para determinar la adherencia, ya que las direcciones IP pueden cambiar durante una sola sesión (por ejemplo, conectar una computadora portátil entre una red cableada e inalámbrica).

Aún mejor, ¡no use el estado de la sesión en el servidor web en absoluto! Si el estado de la sesión es muy doloroso de perder (por ejemplo, los carritos de compra), guárdelo en una base de datos central y elimine periódicamente las sesiones anteriores. Si el estado de la sesión no es crítico (p. Ej., Nombre de usuario / avatar URL), pégalo en una cookie; solo asegúrate de no introducir demasiados datos en la cookie.

Las versiones modernas de Rails, de forma predeterminada, almacenan variables de sesión en una cookie por los motivos anteriores. Otros marcos web pueden tener una opción de "almacenar en la cookie" y / o "almacenar en la base de datos".