AWS présente un nouveau mode Cluster pour Elastic Beanstalk, avec plusieurs applications sur une infrastructure partagée. Avant de répartir votre propre site entre plusieurs instances, vérifiez une dépendance souvent invisible : l'état conservé par chaque serveur. Une répétition ciblée permet de repérer un panier ou une connexion qui dépend du mauvais endroit.
1. Définir le parcours et les données à conserver
Dans votre environnement de test, décrivez un parcours complet : ouvrir une session, ajouter un produit fictif au panier, envoyer un fichier de démonstration puis consulter le résultat. Pour chaque étape, indiquez où l'application conserve l'information et comment une autre instance peut la retrouver.
Demandez à la personne qui maintient le site de distinguer sessions, fichiers persistants, cache et données en base. N'imposez pas un nouveau composant avant de comprendre le fonctionnement actuel. Vérifiez aussi si une tâche programmée serait lancée par chaque copie de l'application.
L'annonce AWS concerne une plateforme précise. Le contrôle proposé ici porte sur votre application et reste nécessaire quelle que soit la solution choisie pour distribuer les requêtes.
2. Faire passer le même visiteur par deux copies
Préparez deux instances avec la même version de l'application et une configuration de test cohérente. Utilisez des comptes fictifs, un paiement de démonstration et une destination mail isolée. Identifiez les instances dans leurs journaux pour savoir laquelle répond réellement.
Avec la personne responsable du répartiteur, dirigez les requêtes du même navigateur successivement vers les deux copies, tout en gardant le même nom de site et les mêmes cookies. Ne comparez pas deux domaines différents : cela pourrait tester les règles des cookies plutôt que le partage d'état recherché.
Vérifiez concrètement :
- La session reste ouverte après le changement d'instance.
- Le panier contient toujours les mêmes éléments.
- Le fichier envoyé reste consultable depuis l'autre copie.
- Une opération métier n'apparaît qu'une fois.
Gardez les heures et les identifiants des opérations fictives. Un résultat aléatoire doit être expliqué, même si une nouvelle tentative semble fonctionner.
3. Vérifier le remplacement d'une instance
Toujours en test, retirez une copie du trafic selon la procédure prévue et rejouez le parcours. Observez les requêtes en cours, les travaux différés et les résultats déjà enregistrés. Un simple affichage de la page d'accueil ne valide pas ce scénario.
Corrigez les dépendances locales identifiées, puis répétez exactement les mêmes contrôles. Documentez également le propriétaire des tâches planifiées et le mécanisme qui évite leur exécution multiple lorsque plusieurs instances existent.
Avant une mise en production, conservez le tableau des résultats et la procédure de retour. Vous disposez alors d'une preuve sur les sessions et les données, au lieu de déduire la compatibilité de l'application d'une option de déploiement.
Sources : AWS News Blog.