Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sessions permanentes pour votre Application Load Balancer

Par défaut, un Application Load Balancer achemine chaque demande de façon indépendante vers une cible enregistrée en fonction de l'algorithme de répartition de charge choisi. Toutefois, vous pouvez utiliser la fonctionnalité de session permanente (également appelée affinité de session) pour permettre à l'équilibreur de charge de lier la session d'un utilisateur à une cible spécifique. Il est ainsi possible de garantir que toutes les demandes de l'utilisateur pendant la session soient adressées à la même cible. Cette fonctionnalité est utile pour les serveurs qui conservent des informations d'état afin d'offrir une expérience continue aux clients. Pour utiliser les sessions permanentes, le client doit accepter les cookies.

Application Load Balancers prennent en charge à la fois les cookies basés sur la durée et les cookies basés sur les applications. Les sessions permanentes sont activées au niveau du groupe cible. Vous pouvez combiner une adhérence basée sur la durée, une permanence basée sur l'application et une absence de permanence entre vos groupes cibles.

La clé de la gestion des sessions permanentes consiste à déterminer la durée pendant laquelle votre équilibreur de charge doit acheminer la demande de l'utilisateur vers la même cible. Si votre application dispose de son propre cookie de session, vous pouvez utiliser une session permanente basée sur l'application et le cookie de session de l'équilibreur de charge suit la durée spécifiée par le cookie de session de l'application. Si votre application n'a pas son propre cookie de session, vous pouvez utiliser la permanence basée sur la durée pour générer un cookie de session d'équilibreur de charge d'une durée que vous spécifiez.

Le contenu des cookies générés par l'équilibreur de charge est chiffré à l'aide d'une clé tournante. Vous ne pouvez pas déchiffrer ni modifier les cookies générés par l'équilibreur de charge.

Pour les deux types de viscosité, l'Application Load Balancer réinitialise l'expiration des cookies qu'il génère après chaque demande. Si un cookie expire, la session n'est plus permanente et le client doit supprimer le cookie de son magasin de cookies.

Permanence basée sur la durée

La permanence basée sur la durée achemine les demandes vers la même cible dans un groupe cible à l'aide d'un cookie généré par un équilibreur de charge (AWSALB). Le cookie est utilisé pour mapper la session à la cible. Si votre application n'a pas son propre cookie de session, vous pouvez spécifier votre propre durée de permanence et gérer la durée pendant laquelle votre équilibreur de charge doit systématiquement acheminer la demande de l'utilisateur vers la même cible.

Lorsqu'un équilibreur de charge reçoit pour la première fois une demande d'un client, il achemine la demande vers une cible (en fonction de l'algorithme choisi) et génère un cookie nommé AWSALB. Il code les informations relatives à la cible sélectionnée, chiffre le cookie et inclut le cookie dans la réponse au client. Le cookie généré par l'équilibreur de charge a son propre délai d'expiration de 7 jours, ce qui n'est pas configurable.

Dans les demandes ultérieures, le client doit inclure le cookie AWSALB. Lorsque l'équilibreur de charge reçoit une demande d'un client contenant le cookie, il le détecte et achemine la demande vers la même cible. Si le cookie est présent mais ne peut pas être décodé, ou s'il fait référence à une cible dont l'enregistrement a été annulé ou n'est pas saine, l'équilibreur de charge sélectionne une nouvelle cible et met à jour le cookie avec des informations sur la nouvelle cible.

Pour les demandes de partage de ressources (CORS) provenant de plusieurs origines, certains navigateurs nécessitent d'SameSite=None; Secureactiver le caractère collant. Pour prendre en charge ces navigateurs, l'équilibreur de charge génère toujours un deuxième cookie de viscositéAWSALBCORS, qui inclut les mêmes informations que le cookie d'adhérence d'origine, ainsi que l'attribut. SameSite Les clients reçoivent les deux cookies, y compris les CORS non-demandes.

Pour activer l'adhérence basée sur la durée à l'aide du AWS CLI

Utilisez la modify-target-group-attributescommande avec les stickiness.lb_cookie.duration_seconds attributs stickiness.enabled et.

Exécutez la commande suivante pour activer la permanence en fonction de la durée.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

Votre sortie doit ressembler à l'exemple suivant.

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

Permanence basée sur les applications

La permanence basée sur les applications vous donne la flexibilité de définir vos propres critères de permanence par rapport au client cible. Lorsque vous activez la permanence basée sur les applications, l'équilibreur de charge achemine la première demande vers une cible au sein du groupe cible en fonction de l'algorithme choisi. La cible est censée définir un cookie d'application personnalisé correspondant au cookie configuré sur l'équilibreur de charge pour permettre la permanence. Ce cookie personnalisé peut inclure n'importe quel attribut de cookie requis par l'application.

Lorsque Application Load Balancer reçoit le cookie d'application personnalisé de la cible, il génère automatiquement un nouveau cookie d'application chiffré pour capturer les informations relatives à la permanence. Ce cookie d'application généré par l'équilibreur de charge capture les informations de permanence pour chaque groupe cible pour lequel la permanence basée sur les applications est activée.

Le cookie d'application généré par l'équilibreur de charge ne copie pas les attributs du cookie personnalisé défini par la cible. Il a son propre délai d'expiration de 7 jours, ce qui n'est pas configurable. Dans la réponse au client, Application Load Balancer valide uniquement le nom sous lequel le cookie personnalisé a été configuré au niveau du groupe cible et non la valeur ou l'attribut d'expiration du cookie personnalisé. Tant que le nom correspond, l'équilibreur de charge envoie les deux cookies, le cookie personnalisé défini par la cible et le cookie d'application généré par l'équilibreur de charge, en réponse au client.

Lors de demandes ultérieures, les clients doivent renvoyer les deux cookies pour conserver la permanence. L'équilibreur de charge déchiffre le cookie de l'application et vérifie si la durée de la permanence configurée est toujours valide. Il utilise ensuite les informations contenues dans le cookie pour envoyer la demande à la même cible au sein du groupe cible afin de maintenir la permanence. L'équilibreur de charge transmet également le cookie d'application personnalisé par proxy à la cible sans l'inspecter ni le modifier. Dans les réponses suivantes, l'expiration du cookie d'application généré par l'équilibreur de charge et la durée de la permanence configurée sur l'équilibreur de charge sont réinitialisées. Pour maintenir la permanence entre le client et la cible, l'expiration du cookie et la durée de la permanence ne doivent pas s'écouler.

Si une cible est défaillante ou devient défectueuse, l'équilibreur de charge cesse d'acheminer les demandes vers cette cible et choisit une nouvelle cible saine en fonction de l'algorithme de répartition de charge choisi. L'équilibreur de charge considère que la session est désormais « liée » à la nouvelle cible saine et continue d'acheminer les demandes vers cette dernière, même si la cible défaillante réapparaît.

Dans le cas des demandes de partage de ressources (CORS) d'origine croisée, pour permettre l'adhérence, l'équilibreur de charge ajoute les SameSite=None; Secure attributs au cookie d'application généré par l'équilibreur de charge uniquement si la version de l'agent utilisateur est Chromium80 ou supérieure.

Comme la plupart des navigateurs limitent la taille des cookies à 4 K, l'équilibreur de charge partitionne les cookies d'application supérieurs à 4 K en plusieurs cookies. Application Load Balancers prennent en charge les cookies d'une taille maximale de 16 K et peuvent donc créer jusqu'à 4 partitions qu'ils envoient au client. Le nom du cookie d'application que le client voit commence par « AWSALBAPP - » et inclut un numéro de fragment. Par exemple, si la taille du cookie est comprise entre 0 et 4 Ko, le client voit AWSALBAPP -0. Si la taille du cookie est comprise entre 4 et 8 ko, le client voit AWSALBAPP -0 et AWSALBAPP -1, et ainsi de suite.

Pour activer l'adhérence basée sur les applications à l'aide du AWS CLI

Utilisez la modify-target-group-attributescommande avec les attributs suivants :

Exécutez la commande suivante pour activer la permanence basée sur les applications.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

Votre sortie doit ressembler à l'exemple suivant.

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

Répartition manuelle

Lors de la mise à l'échelle, si le nombre de cibles augmente considérablement, il existe un risque de répartition inégale de la charge en raison de la permanence. Dans ce scénario, vous pouvez rééquilibrer la charge sur vos cibles à l'aide des deux options suivantes :