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 per 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 Il dimensionamento automatico 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 correlati costi eccessivi, né troppo bassa, con la conseguenza di latenza e tasso di errore elevati.

Il dimensionamento automatico è 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à devi configurare gli avvisi in modo che la soglia impostata venga superata per alcuni minuti prima che l'avviso cessi. Inoltre, occorre tempo per fornire nuove attività e terminare quelle che non sono più necessarie.

A causa di questi potenziali ritardi nel sistema, dovresti mantenere un certo margine di manovra effettuando un provisioning eccessivo. Il provisioning eccessivo 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. Come buona norma, dovresti impostare la destinazione di scalabilità tra il 60-80% dell'utilizzo. Ciò 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 un approvvigionamento eccessivo è 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. Ossia, esegui tre attività ogni due necessarie per il servizio ordinario.

Ottimizzazione 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 aumentare orizzontalmente.

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

Tieni vicine le tue immagini. 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 container. 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 agevolarti.

Riduci le soglie di controllo dell'integrità per il bilanciatore del carico. I bilanciatori del carico eseguono controlli dell'integrità prima di inviare traffico all'applicazione. La configurazione predefinita del controllo dell'integrità per un gruppo di destinazioni può richiedere 90 secondi o più. In questo lasso di tempo, il bilanciatore del carico controlla l'integrità e riceve le richieste. La riduzione dell'intervallo dei controlli dell'integrità e del numero di soglie può far sì che l'applicazione accetti il traffico più rapidamente e riduca il carico su altre attività.

Considera 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à mirate al monitoraggio delle destinazioni. 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 gp2, utilizza volumi più grandi che offrono un throughput maggiore. Se utilizzi volumi gp3, specifica throughput e IOPS al momento della creazione del 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 rete awsvpc, Amazon ECS collega un'interfaccia di rete elastica (ENI) all'istanza prima di avviare l'attività. Ciò introduce una latenza aggiuntiva. Tuttavia, ci sono diversi compromessi per l'utilizzo delle reti bridge. Queste attività non dispongono di un proprio gruppo di sicurezza e vi sono alcune implicazioni per il bilanciatore del carico. Per ulteriori informazioni, consulta Eliminazione del bilanciatore del carico nella Guida per l'utente dell'Elastic Load Balancing.

Gestione degli shock della domanda

Alcune applicazioni subiscono forti shock improvvisi 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é il dimensionamento automatico può richiedere del tempo, consigliamo di aumentare orizzontalmente 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 dell'applicazione. Questo dà al team abbastanza tempo per avere un progetto di pianificazione chiaro. Può pianificare di aumentare orizzontalmente la capacità prima dell'evento e ridurla orizzontalmente dopo l'evento. Per ulteriori informazioni, consulta Dimensionamento pianificato nella Guida per l'utente di Dimensionamento automatico delle applicazioni.

Se hai un piano Enterprise Support, assicurati di collaborare anche con il Technical Account Manager (TAM). Il TAM può verificare le tue quote di servizio e garantire che le quote necessarie vengano aumentate prima dell'inizio dell'evento. In questo modo non colpirai accidentalmente alcuna quota di servizio. Inoltre, può aiutarti con servizi di preriscaldamento, come i bilanciatori del carico, per assicurarsi 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 portata 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, individua 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, inizia ad aumentare orizzontalmente all'istante 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 il throughput senza scalare affatto l'applicazione.

Infine, puoi prendere in considerazione la possibilità di smontare i servizi monolitici per fronteggiare meglio gli 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 aumentare orizzontalmente 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.