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à.

Capacità e disponibilità di Amazon ECS

La disponibilità delle applicazioni è fondamentale per fornire un'esperienza priva di errori e ridurre al minimo la latenza delle applicazioni. La disponibilità dipende dalla disponibilità di risorse accessibili e con una capacità sufficiente per soddisfare la domanda. AWS fornisce diversi meccanismi per gestire la disponibilità. Per le applicazioni ospitate su Amazon ECS, queste includono la scalabilità automatica e le zone di disponibilità (). AZs La scalabilità automatica gestisce il numero di attività o istanze in base a parametri definiti dall'utente, mentre le zone di disponibilità consentono di ospitare l'applicazione in posizioni isolate ma geograficamente vicine.

Come per quanto riguarda le dimensioni delle attività, la capacità e la disponibilità presentano alcuni compromessi da considerare. Idealmente, la capacità sarebbe perfettamente allineata alla domanda. Ci sarebbe sempre la capacità sufficiente per soddisfare le richieste ed elaborare i lavori per soddisfare gli obiettivi del livello di servizio (SLOs), tra cui una bassa latenza e un tasso di errore. La capacità non sarebbe mai troppo elevata, con conseguenti costi eccessivi, né troppo bassa, con conseguenti alti tassi di latenza e di errore.

La scalabilità automatica è un processo latente. Innanzitutto, CloudWatch deve ricevere metriche in tempo reale. Quindi, CloudWatch deve aggregarle per l'analisi, che può richiedere fino a diversi minuti a seconda della granularità della metrica. CloudWatch confronta le metriche con le soglie di allarme per identificare una carenza o un eccesso di risorse. Per evitare l'instabilità, è necessario configurare gli allarmi in modo che la soglia impostata venga superata per alcuni minuti prima che l'allarme si spenga. Inoltre, è necessario del tempo per fornire nuove attività e terminare quelle che non sono più necessarie.

A causa di questi potenziali ritardi nel sistema, è consigliabile mantenere un certo margine di manovra effettuando un approvvigionamento eccessivo. L'over-provisioning può contribuire a far fronte ai picchi di domanda a breve termine. Ciò consente inoltre all'applicazione di soddisfare le richieste aggiuntive senza raggiungere la saturazione. È buona norma impostare l'obiettivo di scalabilità tra il 60 e l'80% dell'utilizzo. Questo aiuta l'applicazione a gestire meglio i picchi di domanda extra mentre la capacità aggiuntiva è ancora in fase di provisioning.

Un altro motivo per cui consigliamo di effettuare un eccesso di provisioning è quello di poter rispondere rapidamente ai guasti delle zone di disponibilità. AWS consiglia di gestire i carichi di lavoro di produzione da più zone di disponibilità. Questo perché, se si verifica un errore nella zona di disponibilità, le attività in esecuzione nelle zone di disponibilità rimanenti possono comunque soddisfare la domanda. Se l'applicazione viene eseguita in due zone di disponibilità, è necessario raddoppiare il normale numero di attività. In questo modo è possibile fornire una capacità immediata in caso di potenziale guasto. Se l'applicazione viene eseguita in tre zone di disponibilità, si consiglia di eseguire 1,5 volte il numero di attività normale. Cioè, esegui tre attività ogni due necessarie per il servizio ordinario.

Massimizzazione della velocità di scalabilità

La scalabilità automatica è un processo reattivo che richiede tempo per avere effetto. Tuttavia, esistono alcuni modi per ridurre al minimo il tempo necessario per la scalabilità orizzontale.

Ridurre al minimo le dimensioni dell'immagine. Le immagini più grandi richiedono più tempo per essere scaricate da un archivio di immagini e decomprimute. Pertanto, mantenere le dimensioni delle immagini più piccole riduce il tempo necessario per l'avvio di un contenitore. Per ridurre le dimensioni dell'immagine, puoi seguire questi consigli specifici:

Tieni le immagini vicine. Maggiore è la latenza di rete, maggiore è il tempo necessario per scaricare l'immagine. Ospita le tue immagini in un repository nella stessa AWS regione in cui si trova il tuo carico di lavoro. Amazon ECR è un repository di immagini ad alte prestazioni disponibile in tutte le regioni in cui è disponibile Amazon ECS. Evita di utilizzare Internet o un collegamento VPN per scaricare le immagini dei contenitori. L'hosting delle immagini nella stessa regione migliora l'affidabilità complessiva. Riduce il rischio di problemi di connettività di rete e problemi di disponibilità in una regione diversa. In alternativa, puoi anche implementare la replica interregionale di Amazon ECR per aiutarti in questo.

Riduci le soglie di controllo dello stato del sistema di bilanciamento del carico. I sistemi di bilanciamento del carico eseguono controlli di integrità prima di inviare traffico all'applicazione. La configurazione predefinita del controllo dello stato di salute per un gruppo target può richiedere 90 secondi o più. Durante questo periodo, il load balancer controlla lo stato di salute e riceve le richieste. La riduzione dell'intervallo dei controlli sanitari e del numero di soglie può far sì che l'applicazione accetti il traffico più rapidamente e riduca il carico su altre attività.

Considerate le prestazioni con avvio a freddo. Alcune applicazioni utilizzano runtime come la compilazione Java perform Just-In-Time (JIT). Il processo di compilazione, almeno all'avvio, può mostrare le prestazioni dell'applicazione. Una soluzione alternativa consiste nel riscrivere le parti critiche per la latenza del carico di lavoro in linguaggi che non impongano un calo delle prestazioni a freddo.

Utilizza la scalabilità graduale, non le politiche di scalabilità basate sul tracciamento degli obiettivi. Sono disponibili diverse opzioni di Application Auto Scaling per le attività di Amazon ECS. Il monitoraggio degli obiettivi è la modalità più semplice da utilizzare, in quanto è necessario soltanto impostare un valore target per un parametro, ad esempio l'utilizzo medio della CPU. L'autoscaler gestisce automaticamente il numero di attività necessarie per raggiungere tale valore. Il dimensionamento per fasi consente di reagire più rapidamente alle variazioni della domanda, poiché si definiscono le soglie specifiche per i parametri di dimensionamento e il numero di attività da aggiungere o rimuovere quando le soglie vengono superate. In particolare, consente di reagire molto rapidamente alle variazioni della domanda riducendo al minimo il tempo di superamento di una soglia di allarme. Per ulteriori informazioni, consulta Scalabilità automatica del servizio nella Guida per gli sviluppatori di Amazon Elastic Container Service.

Se utilizzi EC2 istanze Amazon per fornire capacità di cluster, prendi in considerazione i seguenti consigli:

Usa EC2 istanze Amazon più grandi e volumi Amazon EBS più veloci. Puoi migliorare la velocità di download e preparazione delle immagini utilizzando un' EC2 istanza Amazon più grande e un volume Amazon EBS più veloce. All'interno di una determinata famiglia di EC2 istanze Amazon, la velocità effettiva massima della rete e di Amazon EBS aumenta all'aumentare delle dimensioni dell'istanza (ad esempio, da m5.xlarge am5.2xlarge). Inoltre, puoi personalizzare i volumi Amazon EBS per aumentarne il throughput e gli IOPS. Ad esempio, se utilizzi volumi, utilizza gp2 volumi più grandi che offrono una maggiore velocità di base. Se utilizzi gp3 volumi, specifica la velocità effettiva e gli IOPS quando crei il volume.

Usa la modalità di rete bridge per le attività in esecuzione su EC2 istanze Amazon. Le attività che utilizzano la modalità di bridge rete su Amazon vengono EC2 avviate più rapidamente delle attività che utilizzano la modalità awsvpc di rete. Quando viene utilizzata la modalità di awsvpc rete, Amazon ECS collega un'elastic network interface (ENI) all'istanza prima di avviare l'attività. Ciò introduce una latenza aggiuntiva. Tuttavia, ci sono diversi compromessi per l'utilizzo del bridge networking. Queste attività non dispongono di un proprio gruppo di sicurezza e vi sono alcune implicazioni per il bilanciamento del carico. Per ulteriori informazioni, consulta Load Balancer target group nella Elastic Load Balancing User Guide.

Gestione degli shock legati alla domanda

Alcune applicazioni subiscono improvvisi forti shock della domanda. Ciò accade per una serie di motivi: un evento giornalistico, una grande vendita, un evento mediatico o qualche altro evento che diventa virale e causa un aumento rapido e significativo del traffico in un lasso di tempo molto breve. Se non pianificato, ciò può far sì che la domanda superi rapidamente le risorse disponibili.

Il modo migliore per gestire gli shock legati alla domanda è prevederli e pianificare di conseguenza. Poiché la scalabilità automatica può richiedere del tempo, consigliamo di ridimensionare l'applicazione prima che cominci lo shock della domanda. Per ottenere risultati ottimali, consigliamo di adottare un piano aziendale che preveda una stretta collaborazione tra i team che utilizzano un calendario condiviso. Il team che pianifica l'evento dovrebbe lavorare in anticipo a stretto contatto con il team responsabile della candidatura. Questo dà al team abbastanza tempo per avere un piano di pianificazione chiaro. Possono pianificare la scalabilità orizzontale prima dell'evento e ampliarla dopo l'evento. Per ulteriori informazioni, consulta Dimensionamento pianificato nella Guida per l'utente di Dimensionamento automatico delle applicazioni.

Se disponi di un piano Enterprise Support, assicurati di collaborare anche con il tuo Technical Account Manager (TAM). Il TAM può verificare le quote di servizio e garantire che le quote necessarie vengano aumentate prima dell'inizio dell'evento. In questo modo, non si raggiungono accidentalmente le quote di servizio. Inoltre, possono aiutarvi con servizi di preriscaldamento, come i sistemi di bilanciamento del carico, per assicurarvi che l'evento si svolga senza intoppi.

La gestione degli shock di domanda non programmati è un problema più difficile. Gli shock non programmati, se di ampiezza sufficientemente elevata, possono far sì che la domanda superi rapidamente la capacità. Può anche superare la capacità di reazione della scalabilità automatica. Il modo migliore per prepararsi agli shock non programmati è quello di fornire risorse in eccesso. È necessario disporre di risorse sufficienti per gestire la massima richiesta di traffico prevista in qualsiasi momento.

Mantenere la capacità massima in previsione di shock non programmati della domanda può essere costoso. Per mitigare l'impatto sui costi, individuate un indicatore, una metrica o un evento anticipatore che preveda l'imminenza di un forte shock della domanda. Se la metrica o l'evento forniscono in modo affidabile un preavviso significativo, avvia il processo di scalabilità orizzontale immediatamente quando si verifica l'evento o quando la metrica supera la soglia specifica che hai impostato.

Se la tua applicazione è soggetta a improvvisi shock di domanda non programmati, prendi in considerazione l'aggiunta di una modalità ad alte prestazioni all'applicazione che sacrifichi le funzionalità non critiche ma mantenga funzionalità cruciali per il cliente. Ad esempio, supponiamo che l'applicazione possa passare dalla generazione di costose risposte personalizzate alla pubblicazione di una pagina di risposta statica. In questo scenario, è possibile aumentare in modo significativo la velocità effettiva senza scalare affatto l'applicazione.

Infine, potete prendere in considerazione la possibilità di smontare i servizi monolitici per far fronte meglio agli shock della domanda. Se la tua applicazione è un servizio monolitico, costoso da eseguire e lento da scalare, potresti riuscire a estrarre o riscrivere parti essenziali per le prestazioni ed eseguirle come servizi separati. Questi nuovi servizi possono quindi essere scalati indipendentemente dai componenti meno critici. Avere la flessibilità necessaria per scalare le funzionalità essenziali in termini di prestazioni separatamente dalle altre parti dell'applicazione può ridurre il tempo necessario per aggiungere capacità e contribuire a ridurre i costi.