REL05-BP06 Rendre les systèmes sans état dans la mesure du possible - AWS Well-Architected Framework
Directives d’implémentationRessources

REL05-BP06 Rendre les systèmes sans état dans la mesure du possible

Les systèmes ne doivent pas exiger d’état ou doivent décharger un état de telle sorte qu’entre les différentes demandes client, il n’y ait pas de dépendance vis-à-vis des données stockées localement sur disque et en mémoire. Cela permet le remplacement à volonté des serveurs sans impact sur la disponibilité.

Lorsque des utilisateurs ou des services interagissent avec une application, ils exécutent souvent une série d’interactions qui forment une session. Une session correspond aux données uniques des utilisateurs qui persistent entre les requêtes pendant l’utilisation de l’application. Une application sans état n’a pas besoin de connaître les interactions précédentes et ne stocke pas d’informations de session.

Lorsqu’une application est conçue pour être sans état, vous pouvez utiliser des services de calcul sans serveur, comme AWS Lambda ou AWS Fargate.

Outre le remplacement du serveur, les applications sans état ont également pour avantage de pouvoir être mises à l’échelle horizontalement, car toutes les ressources de calcul disponibles (telles que les instances EC2 et les fonctions AWS Lambda) peuvent répondre à n’importe quelle requête.

Avantages de la mise en place de cette bonne pratique : les systèmes conçus pour être sans état sont plus adaptables à une mise à l’échelle horizontale, ce qui permet d’ajouter ou de supprimer de la capacité en fonction des fluctuations du trafic et de la demande. Ils sont également intrinsèquement résilients aux défaillances et offrent flexibilité et agilité dans le cadre du développement d’applications.

Niveau de risque exposé si cette bonne pratique n’est pas établie: moyen

Directives d’implémentation

Rendre vos applications sans état. Les applications sans état permettent une mise à l’échelle horizontale et tolèrent la défaillance d’un nœud individuel. Analysez et comprenez les composants de votre application qui conservent leur état au sein de l’architecture. Cela vous permet d’évaluer l’impact potentiel de la transition vers une conception sans état. Une architecture sans état découple les données utilisateur et décharge les données de session. Cela permet de mettre à l’échelle chaque composant indépendamment pour répondre à des demandes variables de charge de travail et optimiser l’utilisation des ressources.

Étapes d’implémentation

  • Identifiez et comprenez les composants avec état dans votre application.

  • Découplez les données en séparant et en gérant les données utilisateur de la logique principale de l’application.

    • Amazon Cognito peut découpler les données utilisateur du code de l’application à l’aide de fonctionnalités telles que les groupes d’identités, les groupes d’utilisateurs et Amazon Cognito Sync.

    • Vous pouvez utiliser AWS Secrets Manager pour découpler les données des utilisateurs en stockant les secrets dans un emplacement sécurisé et centralisé. Cela signifie que le code de l’application n’a pas besoin de stocker de secrets, ce qui le rend plus sécurisé.

    • Envisagez d’utiliser Amazon S3 pour stocker des données volumineuses non structurées, telles que des images ou des documents. Votre application peut récupérer ces données en cas de besoin, évitant ainsi d’avoir à les stocker en mémoire.

    • Utilisez Amazon DynamoDB pour stocker des informations telles que des profils utilisateurs. Votre application peut interroger ces données en temps quasi réel.

  • Déchargez les données de session dans une base de données, un cache ou des fichiers externes.

  • Concevez une architecture sans état après avoir identifié les données d’état et d’utilisateur qui doivent être conservées avec la solution de stockage de votre choix.

Ressources

Bonnes pratiques associées :

Documents connexes :