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.
Document de planification de l'expérience
État stable
| Nom du processus | Site d'adoption d'animaux |
|---|---|
Architecture physique |
(Lien vers le schéma d'architecture.) |
Architecture logique |
(Lien vers le diagramme logique.) |
Définir l'état d'équilibre |
Le temps de chargement moyen des pages, mesuré à l'aide de Largest Contentful Paint (LCP), pour le site d'adoption d'animaux de compagnie est de 2,5 secondes ou moins avec une latence de 99 percentiles (P99) de 4 secondes ou moins avec une base de référence de 5 000 utilisateurs simultanés. |
Indicateurs de l'état d'équilibre |
Métrique LCP capturée par l'ensemble de la base d'utilisateurs et métriques de référence (latence, débit, taux d'erreur, saturation). |
Observabilité en régime permanent |
Le LCP sera capturé par le navigateur de l'utilisateur, envoyé à Amazon CloudWatch et inspecté avec CloudWatch RUM. Sur une période de 60 secondes, le temps moyen et le temps LCP P99 seront agrégés pour toutes les demandes au cours de cette période. Les indicateurs de référence de haut niveau sont capturés à l'aide CloudWatch de. |
Procédé pour atteindre l'état d'équilibre |
Grafana K6 sera utilisé pour créer une charge qui simule les niveaux de trafic de production normaux d'environ 5 000 utilisateurs simultanés. |
Exigences en matière d'observabilité
Les équipes devraient être en mesure de consulter les informations suivantes :
-
État stable : qu'est-ce qui sera observé pour vérifier que l'application se déroule dans des conditions normales ?
-
Condition de défaillance : Comment la condition de défaillance apparaîtra-t-elle sur le tableau de bord ? Exemples :
-
Alarmes qui devraient être déclenchées
-
Journaux qui devraient être générés
-
-
Impact de la défaillance : que faut-il observer pour visualiser les composants susceptibles d'être affectés (étendue de l'impact) ?
-
Rétablissement : Comment le rétablissement sera-t-il visualisé et mesuré pour capturer le MTTR ?
-
Débogage : détails de résolution des problèmes liés aux échecs des expériences.
Le tableau suivant fournit des suggestions et des exemples pour un tableau des exigences d'observabilité. Vous devez définir ce qui doit être observé en fonction de votre expérience spécifique.
| Ce qui doit être observé | Lien vers l'outil d'observabilité | Ce qui est observé |
|---|---|---|
Source d'entrée |
Tableau de bord Grafana K6 |
|
État général de l'application |
|
|
État du flux de travail |
Tableau de CloudWatch bord d'adoption d'animaux |
Temps LCP, indicateurs de référence |
Suivis |
Tableau de bord X-Ray sur l'adoption d'animaux |
|
Journaux |
CloudWatch Journaux d'adoption d'animaux |
Toute erreur rencontrée par les pods sera transmise à CloudWatch Logs. |
Définition de l'expérience
| Nom de l'expérience | Stress du processeur Amazon EKS PetSite pod |
|---|---|
Code source de l'expérience |
(Lien vers le référentiel des sources d'expériences.) |
Description de l'expérience |
Cette expérience explore l'impact d'une augmentation de l'utilisation du processeur dans le module d' PetSite application sur l'expérience client globale. En injectant le stress du processeur dans chaque PetSite module en cours d'exécution, nous serons en mesure de comprendre s'il y a un impact sur les clients et l'ampleur de cet impact. |
Exigences ou paramètres de l'expérience |
Charge d'application : moyenne de production Sélecteur d'étiquettes pour capsules : |
Durée de l'expérience |
10 minutes |
Environnement |
Environnement de test alpha |
Expérimentez les ressources cibles |
PetSite modules d'application |
Base de référence d'expérimentation introduite via l'outil de génération de charge |
|
Condition de recul |
Aucune |
Hypothèse
| Et si | Impact | Récupération |
|---|---|---|
Qu'arriverait-il à l'état d'équilibre si les modules PetSite d'application utilisaient ou provoquaient une utilisation du processeur supérieure à 60 % pendant 10 minutes dans des conditions de trafic normales en production ?
|
Les temps LCP resteront inférieurs à 2,5 secondes pour les utilisateurs P50 avec un P99 de 4 secondes ou moins. Le consommateur doit être en mesure de charger la page de PetSite destination. |
Détection :
Auto-guérison :
Rétablissement : Lorsque l'utilisation du processeur revient à la normale, le LCP devrait se rétablir automatiquement. |
Processus d'expérimentation
Adaptez l'exemple de step-by-step processus suivant à votre expérience spécifique :
-
Validez l'accès et les fonctionnalités de tous les Amazon CloudWatch, CloudWatch RUM et AWS X-Ray tableaux de bord.
-
Validez l'état de l'environnement de l'application :
-
Vérifiez que le cluster EKS est sain à l'aide du CloudWatch tableau de bord.
-
Consultez le déploiement de l'application de test pour un site d'adoption d'animaux de compagnie à l'adresse URL d'exemple.
-
-
Initiez une charge pour atteindre un état stable :
-
Vérifiez que le générateur de charge est en cours d'exécution et envoie 5 000 demandes par seconde.
-
Attendez 5 minutes pour que l'application atteigne son état d'équilibre.
-
Vérifiez l'état d'équilibre de l'application à l'aide du tableau de bord CloudWatch RUM.
-
-
Initier une panne (expérience) :
-
Ouvrez la AWS FIS console.
-
Lancez l' pet-adoption-pod-stressexpérience.
-
Vérifiez que le test est en cours d'exécution dans la console.
-
-
Observez l'impact du défaut sur votre application :
-
Capturez des captures d'écran du CloudWatch RUM et CloudWatch des tableaux de bord, et notez les points de données anormaux.
-
Une fois l'expérience terminée AWS FIS, prenez des captures d'écran supplémentaires pour enregistrer si l'application revient à l'état d'équilibre en l'absence de stress, et notez toute anomalie dans les points de données.
-
Si l'état d'équilibre ne revient pas, prenez des mesures pour récupérer l'application et enregistrez les étapes effectuées.
-
-
Vérifiez que l'environnement est revenu à la normale :
-
Passez en revue tous les indicateurs relatifs à l'activité, à l'expérience utilisateur, aux applications et à l'infrastructure pour vérifier que le système est revenu à un état connu. Prenez des captures d'écran du tableau de bord si cela est utile
-
Chronologie de l'expérience
Assurez-vous d'enregistrer la chronologie de l' end-to-endexpérience, en commençant par la génération de la charge, l'injection du défaut, l'observation de l'impact et la restauration de l'application, jusqu'à l'arrêt de la génération de charge. Ceci est illustré dans l'exemple suivant.
Résultats de l'expérience
| ID d'exécution de l'expérience | Résultats de l'expérience |
|---|---|
|
(Lien vers les résultats de l'expérience.) |
Défauts identifiés
-
Le cluster Kubernetes n'a pas détecté l'altération du processeur des PetSite pods. Il n'a donc pas planifié de déploiements supplémentaires.
-
Aucune augmentation des taux d'erreur 4XX ou 5XX n'a été observée à la suite de cette expérience.
-
Nous devons ajuster le bilan de santé du pod pour tenir compte de l'impact sur le LCP en cas de contraintes de ressources.
