Distribuzioni canary di Amazon ECS

Spostamento del traffico: il processo utilizzato da Amazon ECS per spostare il traffico di produzione. Per le implementazioni di Amazon ECS Canary, il traffico viene spostato in due fasi: prima verso la percentuale canaria, quindi verso il completamento della distribuzione.

Percentuale canaria: la percentuale di traffico indirizzato alla nuova versione durante il periodo di valutazione.

Tempo di cottura di Canary: la durata del monitoraggio della versione Canary prima di procedere con la distribuzione completa.

Tempo di attesa dell'implementazione: il tempo, in minuti, che Amazon ECS attende dopo aver spostato tutto il traffico di produzione alla nuova revisione del servizio, prima di terminare la vecchia revisione del servizio. Si tratta del periodo in cui le revisioni blu e verde del servizio vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.

Fasi del ciclo di vita: una serie di eventi nell'operazione di implementazione, ad esempio “dopo lo spostamento del traffico di produzione”.

Lifecycle hook: una funzione Lambda che viene eseguita in una fase specifica del ciclo di vita. È possibile creare una funzione che verifichi la distribuzione.

Gruppo target: una risorsa ELB utilizzata per indirizzare le richieste verso uno o più obiettivi registrati (ad esempio, EC2 istanze). Quando si crea un listener, si specifica un gruppo di destinazione per l'operazione predefinita. Il traffico viene inoltrato al gruppo di destinazione specificato nella regola del listener.

Listener: una risorsa ELB che verifica le richieste di connessione utilizzando il protocollo e la porta configurati. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.

Regola: una risorsa ELB associata a un listener. Una regola definisce il modo in cui le richieste vengono instradate e consiste in un'azione, una condizione e una priorità.

Utilizzo delle risorse: le implementazioni Canary eseguono contemporaneamente sia i set di attività originali che quelli di Canary durante il periodo di valutazione, aumentando l'utilizzo delle risorse.

Volume di traffico: assicurati che la percentuale di Canary generi traffico sufficiente per una convalida significativa della nuova versione.

Complessità del monitoraggio: le implementazioni di Canary richiedono il monitoraggio e il confronto delle metriche tra due versioni diverse contemporaneamente.

Velocità di rollback: le implementazioni Canary consentono un ripristino rapido riportando il traffico al set di attività originale.

Mitigazione del rischio: le implementazioni Canary offrono un'eccellente mitigazione del rischio limitando l'esposizione a una piccola percentuale di utenti.

Durata dell'implementazione: le implementazioni di Canary includono periodi di valutazione che prolungano il tempo complessivo di implementazione ma offrono opportunità di convalida.

Iniziale: l'implementazione inizia con il 100% del traffico indirizzato alla revisione blu (attuale) del servizio. La (nuova) revisione del servizio verde riceve traffico di prova ma inizialmente nessun traffico di produzione.

Spostamento del traffico nelle Canarie - Questa è una strategia di spostamento del traffico in due fasi.

Tempo di cottura per Canary Traffic - Attende una durata configurabile (Canary Bake Time) dopo il cambio di marcia per consentire il monitoraggio e la convalida delle prestazioni della nuova revisione con l'aumento del traffico.

Lifecycle Hook: le funzioni Lambda opzionali possono essere eseguite in varie fasi del ciclo di vita durante l'implementazione per eseguire convalida, monitoraggio o logica personalizzata automatizzati. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION_TRAFFIC_SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.

Percentuale delle Canarie: la percentuale di traffico da indirizzare verso la nuova revisione del servizio durante la fase canaria. Ciò consente di eseguire test con un sottoinsieme controllato del traffico di produzione.

Tempo di cottura delle Canarie: la durata di attesa durante la fase canaria prima di spostare il traffico rimanente verso la nuova revisione del servizio. Ciò fornisce il tempo necessario per monitorare e convalidare la nuova versione.

Gruppo target originale: contiene le attività dell'attuale versione stabile e riceve la maggior parte del traffico.

Gruppo target Canary: contiene le attività della nuova versione e riceve una piccola percentuale di traffico per i test.

Routing ponderato: il load balancer utilizza regole di routing ponderate per distribuire il traffico tra i gruppi target in base alla percentuale di canarie configurata.

Controlli sanitari: entrambi i set di attività devono superare i controlli di integrità prima di ricevere traffico.

Confronto delle metriche: confronta gli indicatori chiave delle prestazioni tra la versione originale e quella di Canary, come il tempo di risposta, il tasso di errore e la velocità effettiva.

Rollback automatico: configura gli CloudWatch allarmi per attivare automaticamente il rollback se la versione Canary mostra prestazioni inferiori.

Convalida manuale: utilizza il periodo di valutazione per esaminare manualmente i registri, le metriche e il feedback degli utenti prima di procedere.

Inizia in piccolo: inizia con il 5-10% del traffico per ridurre al minimo l'impatto in caso di problemi.

Considerate la criticità delle applicazioni: utilizzate percentuali più basse per le applicazioni mission critical e percentuali più alte per i servizi meno critici.

Tieni conto del volume di traffico: assicurati che la percentuale canaria generi traffico sufficiente per una convalida significativa.

Concedi un tempo sufficiente: imposta periodi di valutazione sufficientemente lunghi da acquisire dati significativi sulle prestazioni, in genere 10-30 minuti.

Considerate i modelli di traffico: tenete conto dei modelli di traffico dell'applicazione e dei periodi di picco di utilizzo.

Equilibra velocità e sicurezza: periodi di valutazione più lunghi forniscono più dati ma rallentano la velocità di implementazione.

Metriche chiave: monitora il tempo di risposta, il tasso di errore, la velocità effettiva e l'utilizzo delle risorse per entrambi i set di attività.

Rollback basato sugli allarmi: configura gli CloudWatch allarmi per attivare automaticamente il rollback quando le metriche superano le soglie.

Analisi comparativa: configura dashboard per confrontare le metriche tra la versione originale e quella di Canary. side-by-side

Metriche aziendali: oltre alle metriche tecniche, includi metriche specifiche aziendali come i tassi di conversione o il coinvolgimento degli utenti.

Rollback automatizzato: configura i trigger di rollback automatici in base ai controlli di integrità e alle metriche delle prestazioni.

Procedure di rollback manuali: documenta procedure chiare per il rollback manuale quando i trigger automatici non rilevano tutti i problemi.

Test di rollback: verifica regolarmente le procedure di rollback per assicurarti che funzionino correttamente quando necessario.

Test pre-implementazione: verifica accuratamente le modifiche negli ambienti di staging prima dell'implementazione di Canary.

Configurazione del controllo dello stato: assicurati che i controlli dello stato riflettano accuratamente la disponibilità e la funzionalità delle applicazioni.

Convalida delle dipendenze: verifica che le nuove versioni siano compatibili con i servizi downstream e upstream.

Coerenza dei dati: assicurati che le modifiche allo schema del database e le migrazioni dei dati siano compatibili con le versioni precedenti.

Finestre di implementazione: pianifica le implementazioni di Canary durante l'orario lavorativo, quando i team sono disponibili per il monitoraggio e la risposta.

Canali di comunicazione: stabilisci canali di comunicazione chiari per lo stato dell'implementazione e la risoluzione dei problemi.

Assegnazione dei ruoli: definisci ruoli e responsabilità per il monitoraggio, il processo decisionale e l'esecuzione del rollback.