Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Documento di pianificazione dell'esperimento
Stato stazionario
| Process name (Nome del processo) | Sito di adozione di animali domestici |
|---|---|
Architettura fisica |
(Collegamento al diagramma dell'architettura.) |
Architettura logica |
(Collegamento al diagramma logico.) |
Definire lo stato stazionario |
Il tempo medio di caricamento della pagina, misurato utilizzando Largest Contentful Paint (LCP), per il sito di adozione di animali domestici è pari o inferiore a 2,5 secondi con una latenza del 99 percentile (P99) di 4,0 secondi o inferiore con una linea di base di 5000 utenti simultanei. |
Metriche dello stato stazionario |
Metrica LCP acquisita sulla base di utenti e metriche preferenziali (latenza, velocità effettiva, tassi di errore, saturazione). |
Osservabilità in stato stazionario |
L'LCP verrà acquisito dal browser dell'utente, inviato ad Amazon CloudWatch e ispezionato con CloudWatch RUM. In un periodo di 60 secondi, la media e il tempo LCP P99 verranno aggregati per tutte le richieste in quel periodo. Le metriche auree di primo livello vengono acquisite utilizzando. CloudWatch |
Processo per raggiungere lo stato stazionario |
Grafana K6 verrà utilizzato per creare un carico che simula i normali livelli di traffico di produzione di circa 5.000 utenti simultanei. |
Requisiti di osservabilità
I team dovrebbero essere in grado di visualizzare quanto segue:
-
Stato stazionario: cosa verrà osservato per verificare che l'applicazione sia in condizioni normali?
-
Condizione di guasto: come verrà visualizzata la condizione di guasto nella dashboard? Ad esempio:
-
Allarmi che devono essere attivati
-
Registri che dovrebbero essere generati
-
-
Impatto sul guasto: cosa occorre osservare per visualizzare i componenti che si prevede subiranno un impatto (ambito dell'impatto)?
-
Recupero: come verrà visualizzato e misurato il ripristino per acquisire l'MTTR?
-
Debug: risoluzione dei problemi relativi agli errori degli esperimenti.
La tabella seguente fornisce suggerimenti ed esempi per una tabella dei requisiti di osservabilità. È necessario definire cosa osservare in base al proprio esperimento specifico.
| Cosa deve essere osservato | Link allo strumento di osservabilità | Cosa viene osservato |
|---|---|---|
Fonte di input |
Cruscotto Grafana K6 |
|
Stato generale delle applicazioni |
|
|
Stato del flusso di lavoro |
CloudWatch Pannello sull'adozione di animali domestici |
Tempo LCP, metriche privilegiate |
Tracce |
Dashboard X-Ray per l'adozione di animali domestici |
|
Logs |
CloudWatch Registri di adozione di animali domestici |
Eventuali errori riscontrati dai pod verranno inviati a CloudWatch Logs. |
Definizione dell'esperimento
| Nome dell'esperimento | Stress della CPU del PetSite pod Amazon EKS |
|---|---|
Codice sorgente dell'esperimento |
(Link al repository dei sorgenti dell'esperimento.) |
Descrizione dell'esperimento |
Questo esperimento analizza come un aumento dell'utilizzo della CPU dell' PetSite application pod influirebbe sull'esperienza complessiva del cliente. Iniettando lo stress della CPU in ogni PetSite pod funzionante, saremo in grado di capire se c'è un impatto sui clienti e l'entità di tale impatto. |
Requisiti o parametri dell'esperimento |
Carico dell'applicazione: media di produzione Selettore di etichette per pod: |
Durata esperimento |
10 minuti |
Ambiente |
Ambiente di test Alpha |
Risorse mirate agli esperimenti |
PetSite contenitori per applicazioni |
Linea di base dell'esperimento introdotta tramite lo strumento di generazione del carico |
|
Condizione di backoff |
Nessuno |
Ipotesi
| Cosa succede se | Impatto | Ripristino |
|---|---|---|
Cosa accadrebbe allo stato stazionario se i pod delle PetSite applicazioni registrassero o causassero un utilizzo della CPU superiore al 60% per 10 minuti in condizioni di traffico normale a livello di produzione?
|
I tempi LCP rimarranno inferiori a 2,5 secondi per il 50% degli utenti, con P99 pari o inferiore a 4,0 secondi. Il consumatore dovrebbe essere in grado di caricare la PetSite pagina di destinazione. |
Rilevamento:
Autoriparazione:
Recupero: Quando l'utilizzo della CPU torna alla normalità, l'LCP dovrebbe ripristinarsi automaticamente. |
Processo sperimentale
Adatta il seguente step-by-step processo di esempio al tuo esperimento specifico:
-
Convalida l'accesso e la funzionalità di tutti gli Amazon CloudWatch, CloudWatch RUM e i AWS X-Ray dashboard.
-
Convalida lo stato dell'ambiente applicativo:
-
Verifica che il cluster EKS sia integro utilizzando la CloudWatch dashboard.
-
Visita l'implementazione dell'applicazione Test Pet Adoption Site all'URL di esempio.
-
-
Avvia un carico per raggiungere lo stato stazionario:
-
Verificate che il generatore di carico sia in funzione e invii 5000 richieste al secondo.
-
Attendi 5 minuti affinché l'applicazione raggiunga lo stato stazionario.
-
Conferma lo stato stazionario dell'applicazione utilizzando la dashboard CloudWatch RUM.
-
-
Avvia un guasto (esperimento):
-
Apri la AWS FIS console.
-
Esegui l' pet-adoption-pod-stressesperimento.
-
Conferma che l'esperimento sia in esecuzione nella console.
-
-
Osserva l'impatto dell'errore sulla tua applicazione:
-
Acquisisci schermate dal CloudWatch RUM e dai CloudWatch dashboard e annota eventuali punti dati anomali.
-
Una volta completato l'esperimento AWS FIS, acquisisci schermate aggiuntive per registrare se l'applicazione torna allo stato stazionario in assenza di stress e annota eventuali anomalie nei punti dati.
-
Se lo stato stazionario non riprende, procedi per ripristinare l'applicazione e registra i passaggi eseguiti.
-
-
Verifica che l'ambiente sia tornato alla normalità:
-
Esamina tutte le metriche aziendali, relative all'esperienza utente, alle applicazioni e all'infrastruttura per verificare che il sistema sia tornato a uno stato noto. Se utile, acquisisci schermate della dashboard.
-
Cronologia dell'esperimento
Assicurati di registrare la sequenza temporale dell' end-to-endesperimento, iniziando con la generazione del carico, l'iniezione del guasto, l'osservazione dell'impatto e il ripristino dell'applicazione, e terminando quando interrompi la generazione del carico. Questo è illustrato nell'esempio seguente.
Risultati dell'esperimento
| ID di esecuzione dell'esperimento | Risultati dell'esperimento |
|---|---|
|
(Link ai risultati dell'esperimento.) |
Difetti identificati
-
Il cluster Kubernetes non ha rilevato danni alla CPU dei PetSite pod, quindi non ha pianificato implementazioni aggiuntive.
-
Non vi è stato alcun aumento dei tassi di errore 4XX o 5XX come risultato di questo esperimento.
-
Dobbiamo modificare il controllo dello stato del pod per tenere conto dell'impatto sull'LCP in caso di limitazioni di risorse.
