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.
# niveau Web sans état
Pour tirer parti de plusieurs serveurs Web dans une configuration de dimensionnement automatique, votre niveau Web doit être apatride. Une application sans état est une application qui n'a pas besoin de connaître les interactions précédentes et qui ne stocke aucune information de session. Dans le cas de WordPress, cela signifie que tous les utilisateurs finaux reçoivent la même réponse, quel que soit le serveur Web qui a traité leur demande. Une application sans état peut évoluer horizontalement car toute demande peut être traitée par l'une des ressources informatiques disponibles (c'est-à-dire les instances de serveur Web). Lorsque cette capacité n'est plus requise, toute ressource individuelle peut être interrompue en toute sécurité (une fois que les tâches en cours ont été épuisées). Ces ressources n'ont pas besoin d'être conscientes de la présence de leurs pairs ; il leur suffit de trouver un moyen de leur répartir la charge de travail.
En ce qui concerne le stockage des données de session utilisateur, le WordPress noyau est totalement apatride car il repose sur des cookies stockés dans le navigateur Web du client. Le stockage de session n'est pas un problème, sauf si vous avez installé un code personnalisé (par exemple, un WordPress plugin) qui repose plutôt sur PHP des sessions natives.
Cependant, WordPress il a été initialement conçu pour fonctionner sur un seul serveur. Par conséquent, il stocke certaines données dans le système de fichiers local du serveur. Lors de WordPress l'exécution dans une configuration multiserveur, cela crée un problème car il existe des incohérences entre les serveurs Web. Par exemple, si un utilisateur télécharge une nouvelle image, celle-ci n'est stockée que sur l'un des serveurs.
Cela montre pourquoi nous devons améliorer la configuration d' WordPressexécution par défaut pour déplacer les données importantes vers le stockage partagé. L'architecture des meilleures pratiques comporte une base de données en tant que couche séparée en dehors du serveur Web et utilise le stockage partagé pour stocker les téléchargements, les thèmes et les plugins des utilisateurs.
# Stockage partagé (Amazon S3 et AmazonEFS)
Par défaut, WordPress stocke les téléchargements des utilisateurs sur le système de fichiers local et n'est donc pas apatride. Par conséquent, nous devons déplacer l' WordPress installation et toutes les personnalisations utilisateur (telles que la configuration, les plugins, les thèmes et les téléchargements générés par les utilisateurs) vers une plate-forme de données partagée afin de réduire la charge sur les serveurs Web et de rendre le niveau Web apatride.
[Amazon Elastic File System](https://aws.amazon.com/efs/details/) (AmazonEFS) fournit des systèmes de fichiers réseau évolutifs à utiliser avec des EC2 instances. Les systèmes de EFS fichiers Amazon sont répartis sur un nombre illimité de serveurs de stockage, ce qui permet aux systèmes de fichiers de croître de manière élastique et permet un accès massivement parallèle depuis les instances. EC2 La conception distribuée d'Amazon EFS permet d'éviter les goulots d'étranglement et les contraintes inhérents aux serveurs de fichiers traditionnels.
En déplaçant l'intégralité du répertoire WordPress d'installation sur un système de EFS fichiers et en le montant dans chacune de vos EC2 instances au démarrage, votre WordPress site et toutes ses données sont automatiquement stockés sur un système de fichiers distribué qui ne dépend d'aucune EC2 instance, ce qui rend votre niveau Web complètement apatride. L'avantage de cette architecture est que vous n'avez pas besoin d'installer de plugins et de thèmes à chaque lancement d'une nouvelle instance, et vous pouvez accélérer considérablement l'installation et la restauration des WordPress instances. Il est également plus facile de déployer les modifications apportées aux plugins et aux thèmes dans WordPress, comme indiqué dans la section [Considérations relatives au déploiement](appendix-a-cloudfront-configuration.md) de ce document.
Pour garantir des performances optimales de votre site Web lorsqu'il est exécuté à partir d'un système de EFS fichiers, vérifiez les paramètres de configuration recommandés pour Amazon EFS et OPcache sur l'[architecture de AWS référence pour WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache).
Vous avez également la possibilité de décharger toutes les ressources statiques, telles que les images et JavaScript les fichiersCSS, dans un compartiment S3 avec CloudFront mise en cache à l'avant. Le mécanisme permettant de le faire dans une architecture multiserveur est exactement le même que pour une architecture à serveur unique, comme indiqué dans la section [Contenu statique](accelerating-content-delivery.md) de ce livre blanc. Les avantages sont les mêmes que ceux de l'architecture à serveur unique : vous pouvez déléguer le travail associé à la diffusion de vos actifs statiques sur Amazon S3 CloudFront, permettant ainsi à vos serveurs Web de se concentrer uniquement sur la génération de contenu dynamique et de répondre à un plus grand nombre de demandes d'utilisateurs par serveur Web.
# Niveau de données (Amazon Aurora et Amazon ElastiCache)
L' WordPress installation étant stockée sur un système de fichiers réseau partagé, évolutif et distribué, et les ressources statiques étant fournies par Amazon S3, vous pouvez concentrer votre attention sur le composant dynamique restant : la base de données. Comme pour le niveau de stockage, la base de données ne doit pas dépendre d'un seul serveur, elle ne peut donc pas être hébergée sur l'un des serveurs Web. Hébergez plutôt la WordPress base de données sur Amazon Aurora.
[Amazon Aurora](https://aws.amazon.com/rds/aurora) est une base de données relationnelle SQL compatible avec My SQL et Postgre conçue pour le cloud, qui associe les performances et la disponibilité des bases de données commerciales haut de gamme à la simplicité et à la rentabilité des bases de données open source. Aurora My SQL améliore mes SQL performances et ma disponibilité en intégrant au moteur de base de données un système de stockage distribué spécialement conçu, soutenu par. SSD Il est tolérant aux pannes et autoréparant, réplique six copies de vos données dans trois zones de disponibilité, est conçu pour une disponibilité supérieure à 99,99 % et sauvegarde en permanence vos données dans Amazon S3. Amazon Aurora est conçu pour détecter automatiquement les incidents de base de données et redémarrer sans effectuer de récupération sur incident et sans regénérer le cache de la base de données.
Amazon Aurora propose un certain nombre de [types d'instances](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) adaptés à différents profils d'applications, notamment des instances optimisées pour la mémoire et des instances évolutives. Pour améliorer les performances de votre base de données, vous pouvez sélectionner un type d'instance de grande taille afin de fournir davantage de ressources CPU et de mémoire.
Amazon Aurora gère automatiquement le basculement entre l'instance principale et [Aurora Replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) afin que vos applications puissent reprendre les opérations de base de données aussi rapidement que possible sans intervention administrative manuelle. Le basculement dure généralement moins de 30 secondes.
Après avoir créé au moins une réplique Aurora, connectez-vous à votre instance principale à l'aide du point de terminaison du cluster pour permettre à votre application de basculer automatiquement en cas de défaillance de l'instance principale. Vous pouvez créer jusqu'à 15 réplicas en lecture à faible latence dans trois zones de disponibilité.
Au fur et à mesure que votre base de données évolue, votre cache de base de données devra également évoluer. Comme indiqué précédemment dans la section Mise en [cache de base](database-caching.md) de données, ElastiCache possède des fonctionnalités permettant de dimensionner le cache sur plusieurs nœuds d'un ElastiCache cluster et sur plusieurs zones de disponibilité d'une région pour une meilleure disponibilité. Lorsque vous dimensionnez votre ElastiCache cluster, assurez-vous de configurer votre plug-in de mise en cache pour qu'il se connecte à l'aide du point de terminaison de configuration afin qu'il WordPress puisse utiliser les nouveaux nœuds de cluster lorsqu'ils sont ajoutés et arrêter d'utiliser les anciens nœuds de cluster lorsqu'ils sont supprimés. Vous devez également configurer vos serveurs Web pour utiliser le [client de ElastiCache cluster PHP et les mettre à jour AMI pour](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html) enregistrer cette modification.