Sessions persistantes avec cookies basés sur les applications - AWS Conseils prescriptifs
Cas d’utilisation courantsChangements de code depuis basic.ymlÉtapesRésultats attendusComment ça marche

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 persistantes avec cookies basés sur les applications

Lorsque vous utilisez un Application Load Balancer avec un cookie basé sur une application :

  • L'Application Load Balancer utilise le poids du groupe cible pour déterminer comment équilibrer le trafic entrant entre les groupes cibles.

  • Par défaut, l'Application Load Balancer utilise la méthode round robin pour acheminer les demandes vers les EC2 instances du groupe cible de destination.

  • Une fois que le trafic a été initialement acheminé vers une EC2 instance, la réponse de l'application de l' EC2 instance doit contenir un cookie d'application personnalisé, qui est renvoyé au client avec un cookie Application Load Balancer automatisé.

  • Le trafic suivant restera concentré sur l' EC2 instance si le client renvoie le cookie d'application et le cookie Application Load Balancer.

  • Le cookie basé sur l'application expire après non-utilisation pendant la durée configurée.

Modèle : utilisez le AWS CloudFormation modèle stickysessionsapp.yml (inclus dans le fichier .zip de code d'exemple) pour essayer des sessions persistantes avec des cookies basés sur des applications.

Cas d’utilisation courants

Utilisez des sessions persistantes avec des cookies générés par l'application lorsque vous souhaitez un contrôle supplémentaire dans les scénarios suivants :

  • Serveurs Web PHP

  • Serveurs qui conservent des données de session temporaires telles que les journaux, les paniers d'achat ou les conversations par chat

Changements de code depuis basic.yml

Le seul changement de code concerne la configuration du groupe cible. Nous avons ajouté une configuration d'adhérence aux attributs de l'Application Load Balancer et du groupe cible. La durée du cookie d'application est spécifiée et le groupe cible a activé le caractère persistant des cookies d'application.

basic.yml stickysessionsapp.yml 
TG1:
   Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
   Properties:
     Name: TG1
     Protocol: HTTP
     Port: 80
     TargetType: instance
     Targets:
       - Id: !Ref Instance1
       - Id: !Ref Instance2
VpcId: !Ref CustomVPC
 
TG1:
  Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
  Properties:
    Name: TG1
    Protocol: HTTP
    Port: 80
    TargetType: instance
    Targets:
      - Id: !Ref Instance1
      - Id: !Ref Instance2
    VpcId: !Ref CustomVPC
    TargetGroupAttributes:
      - Key: stickiness.enabled
        Value: true
      - Key: stickiness.type
        Value: app_cookie
      - Key: stickiness.app_cookie.duration_seconds
        Value: 10
      - Key: stickiness.app_cookie.cookie_name
        Value: TESTCOOKIE

Étapes

Remarques

  • Les passerelles NAT sont peu coûteuses.

  • Plusieurs EC2 instances utiliseront vos heures de niveau gratuit plus rapidement qu'une seule EC2 instance.

  1. Déployez le CloudFormation modèle stickysessionslb.yml dans un environnement de laboratoire.

  2. Attendez que l'état de santé des instances de votre groupe cible passe d'un état initial à un état sain.

  3. Accédez à l'URL de l'Application Load Balancer dans un navigateur Web à l'aide du protocole HTTP (TCP/80).

    Par exemple : http://alb-123456789.us-east-1.elb.amazonaws.com/

    La page Web affiche l'un des éléments suivants : Instance 1 - TG1, Instance 2 - TG1, Instance 3 - TG2 ou Instance 4 - TG2.

  4. Actualisez la page plusieurs fois.

Résultats attendus

Note

Le CloudFormation modèle de cet exemple a configuré l'adhérence pour qu'elle dure 10 secondes. La configuration valide de la durée d'adhérence est comprise entre 1 seconde et 1 semaine.

L'instance qui charge la page Web doit rester la même, comme indiqué par le texte de la page.

La durée de conservation n'est pas actualisée, mais est basée sur l'expiration configurée dans l'Application Load Balancer pour le cookie d'application généré par l'instance. EC2

Exemple 1 : attendez 5 secondes pour actualiser la page. La même instance se chargera et le caractère collant sera actualisé pendant 10 secondes supplémentaires.

Exemple 2 : attendez plus de 10 secondes pour recharger la page. Le cookie d'application expire et vous êtes redirigé vers une autre EC2 instance. Cette nouvelle instance génère un autre cookie d'application d'une durée de 10 secondes.

Comment ça marche

  • Dans cet exemple, un serveur Web Apache (httpd) est installé sur les EC2 instances. Le httpd.conf fichier est configuré pour renvoyer une Set-Cookie valeur statique au client (votre navigateur Web). La Set-Cookie valeur est codée en dur pour être. TESTCOOKIE=<somevalue>

  • Ouvrez l'option Inspect Element de votre navigateur, choisissez l'onglet Réseau, puis choisissez la méthode Get, qui charge la page. Vous verrez un onglet Cookies.

  • Le navigateur est une application cliente qui est automatiquement configurée pour renvoyer toutes les mises à jour ultérieures au serveur avec les cookies qu'il reçoit dans la Set-Cookie réponse du serveur.

  • Lorsque vous rechargez la page, les cookies reçus lors du chargement initial de la page sont automatiquement renvoyés à l'Application Load Balancer.

    • Si le cookie a expiré (c'est-à-dire que 10 secondes se sont écoulées depuis le dernier appel), l'Application Load Balancer utilise une nouvelle logique pour déterminer l'instance vers EC2 laquelle acheminer le trafic.

    • Si le cookie n'a pas expiré, l'Application Load Balancer achemine le trafic vers la même EC2 instance.