Avantages et inconvénients de la stratégie d'équilibrage de charge Sticky Session / Session Affinity?
Une approche de l'évolutivité élevée consiste à utiliser l'équilibrage de la charge réseau pour répartir la charge de traitement entre plusieurs serveurs.
Un défi que cette approche présente est celui où les serveurs sont conscients de l'état - stockant l'état de l'utilisateur dans une "session".
Une solution à ce problème est la "session persistante" (alias "affinité de session") où chaque utilisateur est affecté à un seul serveur et ses données d'état sont contenues sur ce serveur exclusivement pendant toute la durée de la session.
Quels sont les avantages et les inconvénients de l'approche "session collante"? L'utilisez-vous et si oui, en êtes-vous satisfait?
Avantages:
- c'est facile - aucun changement d'application requis.
- utilise mieux les caches locaux RAM (par exemple, recherchez le profil utilisateur une fois, mettez-le en cache et pouvez le réutiliser lors de visites ultérieures du même utilisateur)
Inconvénients:
- si le serveur tombe en panne, la session est perdue. (notez qu'il s'agit d'un inconvénient de stocker des informations de session localement sur le serveur Web - pas de sessions persistantes en soi). si le contenu de la session est vraiment important pour l'utilisateur (par exemple, un brouillon d'e-mail) ou pour le site (par exemple, un panier), la perte d'un de vos serveurs peut être très douloureuse.
- en fonction de l'implémentation "collante" dans votre équilibreur de charge, peut diriger une charge inégale vers certains serveurs par rapport à d'autres
- mettre un nouveau serveur en ligne ne donne pas immédiatement beaucoup de charge au nouveau serveur - si vous avez un système d'équilibrage de charge dynamique pour faire face aux pointes, l'adhérence peut ralentir votre capacité à répondre rapidement à une pointe. Cela dit, il s'agit en quelque sorte d'un cas d'angle et ne s'applique vraiment qu'aux sites très grands et sophistiqués.
- si vous avez relativement peu d'utilisateurs mais que le trafic d'un seul utilisateur peut submerger un serveur (par exemple, des pages complexes avec SSL, AJAX, des images générées dynamiquement, une compression dynamique, etc.), alors les stickines peuvent réduire le temps de réponse de l'utilisateur final car vous n'êtes pas répartir uniformément la charge d'un seul utilisateur sur les serveurs. Si vous avez beaucoup d'utilisateurs simultanés, ce n'est pas un problème car tous vos serveurs seront submergés!
Mais si vous devez utiliser l'état de session local du serveur, les sessions persistantes sont certainement la voie à suivre - et même si vous n'utilisez pas l'état de session local du serveur, l'adhérence présente des avantages en ce qui concerne l'utilisation du cache (voir ci-dessus). Votre équilibreur de charge devrait être en mesure d'examiner les cookies HTTP (pas seulement l'adresse IP) pour déterminer l'adhérence, car les adresses IP peuvent changer au cours d'une seule session (par exemple, ancrer un ordinateur portable entre un réseau câblé et sans fil).
Encore mieux, n'utilisez pas du tout l'état de la session sur le serveur Web! Si l'état de la session est très douloureux à perdre (par exemple, des paniers d'achat), stockez-le dans une base de données centrale et supprimez régulièrement les anciennes sessions. Si l'état de la session n'est pas critique (par exemple, le nom d'utilisateur/l'URL de l'avatar), collez-le dans un cookie - assurez-vous simplement de ne pas insérer trop de données dans le cookie.
Les versions modernes de Rails, par défaut, stockent les variables de session dans un cookie pour les raisons ci-dessus. D'autres frameworks Web peuvent avoir une option "stocker dans les cookies" et/ou "stocker dans la base de données".