Déploiement1 / 5
Une entreprise migre vers le cloud une application web à trois niveaux. Le niveau applicatif repose sur des serveurs de session avec état qui conservent en mémoire les paniers d'achat des utilisateurs. Pour permettre une mise à l'échelle horizontale dans le cloud, quelle modification dois-tu faire EN PREMIER ?
Bonne réponseRéponse incorrecte
Alex
L'un des plus gros défis d'une migration vers le cloud est la gestion des niveaux applicatifs avec état. Quand les données de session vivent dans la mémoire du serveur, les utilisateurs doivent toujours atteindre le même serveur (affinité de session), ce qui limite la mise à l'échelle et crée des points uniques de défaillance. La solution cloud-native consiste à externaliser l'état vers un magasin partagé et distribué comme Redis ou Memcached. Une fois les sessions stockées dans un cache externe, les serveurs applicatifs deviennent sans état — n'importe quel serveur peut traiter n'importe quelle requête, et on peut ajouter ou retirer des serveurs librement. Les sticky sessions (affinité de session) sur le load balancer sont un contournement temporaire qui épingle les utilisateurs à des serveurs précis, mais cela crée une répartition de charge inégale, complique les déploiements et signifie que la panne d'un serveur fait perdre les sessions de tous les utilisateurs qui y étaient épinglés. Augmenter la mémoire relève de la mise à l'échelle verticale, pas d'un chemin vers la scalabilité horizontale. Le passage à WebSocket concerne le type de connexion, pas la gestion de l'état. Astuce d'examen : une migration « avec état vers sans état » signifie presque toujours qu'il faut externaliser l'état vers un cache distribué.
Sourcedocs.aws.amazon.com
Les réponses aux questions complémentaires sont disponibles dans l’app. Crée un compte gratuit, sans carte bancaire.
Question 1 sur 5
Créer un compte gratuit