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à. # Best practice di dimensionamento automatico e gestione della capacità di Amazon ECS Su Amazon ECS puoi eseguire carichi di lavoro di applicazioni containerizzate di tutte le dimensioni. Ciò include ambienti di test minimi e ambienti di produzione di grandi dimensioni che operano su scala globale. Con Amazon ECS, come tutti i AWS servizi, paghi solo per ciò che usi. Quando progetti l'applicazione in modo adeguato puoi risparmiare sui costi consumando solo le risorse di cui hai bisogno, quando ne hai bisogno. I consigli riportati di seguito mostrano come eseguire i carichi di lavoro Amazon ECS per soddisfare i tuoi obiettivi di livello di servizio operando a costi contenuti. **Topics** + [ # Determinazione delle dimensioni delle attività per Amazon ECS ](capacity-tasksize-best-practice.md) + [ # Ottimizzazione del dimensionamento automatico del servizio Amazon ECS ](capacity-autoscaling-best-practice.md) + [ # Capacità e disponibilità di Amazon ECS ](capacity-availability-best-practice.md) + [ # Capacità dei cluster Amazon ECS ](capacity-cluster-best-practice.md) + [ # Scelta delle dimensioni delle attività Fargate per Amazon ECS ](fargate-task-size-best-practice.md) + [ # Accelerazione del provisioning della capacità dei cluster Amazon ECS con i provider di capacità su Amazon EC2 ](capacity-cluster-speed-up-ec2-best-practice.md) # Determinazione delle dimensioni delle attività per Amazon ECS Una delle scelte più importanti quando implementi container su Amazon ECS è la dimensione dei container e delle attività. Le dimensioni dei container e delle attività sono essenziali per la scalabilità e la pianificazione della capacità. Amazon ECS utilizza due parametri di risorse per la capacità: CPU e memoria. Amazon ECS misura la CPU in unità di 1/1024 di una vCPU completa (dove 1024 unità equivalgono a 1 vCPU intera). Amazon ECS misura la memoria in megabyte. Nella definizione dell'attività, puoi dichiarare prenotazioni e limiti di risorse. Quando dichiari una prenotazione, dichiari la quantità minima di risorse richiesta da un'attività. L'attività riceve almeno la quantità di risorse da te richiesta. L'applicazione potrebbe essere in grado di utilizzare più CPU o memoria rispetto alla prenotazione dichiarata. Tuttavia, ciò è soggetto ai limiti che hai dichiarato. L'utilizzo di una quantità superiore alla quantità della prenotazione è noto come bursting. Il bursting significa che l'applicazione utilizza più risorse di quelle prenotate, ma rimane entro i limiti dichiarati. Amazon ECS garantisce le prenotazioni. Ad esempio, se utilizzi istanze Amazon EC2 per fornire capacità, Amazon ECS non inserisce un'attività su un'istanza in cui non può soddisfare la prenotazione. Un limite è la quantità massima di unità CPU o memoria che il container o l'attività può utilizzare. Se il container tenta di utilizzare più CPU rispetto a questo limite, Amazon ECS lo limita. Se il container tenta di utilizzare più memoria oltre questo limite, Amazon ECS lo arresta. La scelta di questi valori può essere complessa. I valori che funzionano meglio per l'applicazione dipendono molto dai requisiti di risorse dell'applicazione. Il test di carico dell'applicazione è la chiave per una corretta pianificazione del fabbisogno di risorse. Il test di carico consente di comprendere meglio i requisiti dell'applicazione. ## Applicazioni stateless Per le applicazioni stateless con scalabilità orizzontale, ad esempio un'applicazione con bilanciatore del carico, consigliamo innanzitutto di determinare la quantità di memoria utilizzata dall'applicazione per soddisfare le richieste. A tale scopo, puoi utilizzare strumenti tradizionali come `ps` o `top`. Puoi anche utilizzare soluzioni di monitoraggio come CloudWatch Container Insights. Quando stabilisci una prenotazione della CPU, considera come vuoi scalare l'applicazione per soddisfare i requisiti aziendali. Puoi utilizzare prenotazioni di CPU minori, ad esempio 256 unità CPU (o 1/4 vCPU), per aumentare orizzontalmente in modo da ridurre al minimo i costi. Tuttavia, potrebbero non scalare abbastanza velocemente per soddisfare i picchi significativi della domanda. Puoi utilizzare prenotazioni di CPU maggiori per ridurre e aumentare orizzontalmente più in fretta. Ciò ti aiuta a soddisfare più rapidamente i picchi di domanda. Tuttavia, le prenotazioni di CPU maggiori costano di più. ## Altre applicazioni Per le applicazioni che non sono scalabili orizzontalmente, come worker singleton o server di database, le considerazioni più importanti sono la capacità e i costi disponibili. Scegli la quantità di memoria e di CPU in base ai risultati dei test di carico necessari per gestire il traffico e raggiungere il tuo obiettivo di livello di servizio. Amazon ECS garantisce che l'applicazione sia collocata su un host con una capacità adeguata. # Ottimizzazione del dimensionamento automatico del servizio Amazon ECS Un servizio Amazon ECS è una raccolta gestita di attività. Ogni servizio ha una definizione di attività associata, un numero di attività desiderato e una strategia di posizionamento opzionale. Il dimensionamento automatico del servizio Amazon ECS funziona tramite il servizio Application Auto Scaling. Application Auto Scaling utilizza le CloudWatch metriche come fonte per le metriche di scalabilità. Utilizza inoltre gli CloudWatch allarmi per impostare soglie su quando ampliare o disattivare il servizio. Sei tu a fornire le soglie per la scalabilità. Puoi impostare un parametro di destinazione, denominato *dimensionamento con monitoraggio della destinazione*. Puoi anche specificare delle soglie, operazione denominata *scalabilità a fasi*. Dopo aver configurato Application Auto Scaling, questo calcola continuamente il numero di attività desiderato appropriato per il servizio. Inoltre, notifica ad Amazon ECS quando il numero di attività desiderato deve cambiare, ridimensionandolo orizzontalmente o verticalmente. Per utilizzare il service di dimensionamento automatico in modo efficace, devi scegliere un parametro di dimensionamento adeguato. Nelle sezioni seguenti viene descritto come scegliere un parametro. ## Caratterizzazione dell'applicazione Per scalare correttamente un'applicazione devi conoscere le condizioni in cui è necessario scalare l'applicazione e quando è necessario scalarla orizzontalmente. In sostanza, devi aumentare orizzontalmente l'applicazione se prevedi che la domanda superi la capacità. Al contrario, puoi ridurre orizzontalmente l'applicazione per ridurre i costi quando le risorse superano la domanda. ### Identificazione di un parametro di utilizzo Per una scalabilità efficace devi identificare un parametro che indichi l'utilizzo o la saturazione. Tale parametro deve presentare le seguenti proprietà per essere utile per la scalabilità. + Il parametro deve essere correlato alla domanda. Quando si mantengono stabili le risorse ma la domanda cambia, deve cambiare anche il valore del parametro. Il parametro deve aumentare o diminuire quando la domanda aumenta o diminuisce. + Il valore del parametro deve essere ridotto orizzontalmente in proporzione alla capacità. Quando la domanda rimane costante, l'aggiunta di più risorse deve comportare una modifica proporzionale del valore del parametro. Pertanto, il raddoppio del numero di attività dovrebbe far diminuire il parametro del 50%. Il modo migliore per identificare un parametro di utilizzo è eseguire test di carico in un ambiente di preproduzione come un ambiente di staging. Sono ampiamente disponibili soluzioni commerciali e open source per i test di carico. Queste soluzioni di solito possono generare carichi sintetici o simulare il traffico utente reale. Per avviare il processo di test di carico devi prima creare delle dashboard per i parametri di utilizzo dell'applicazione. Queste metriche includono l'utilizzo della CPU, l'utilizzo della memoria, I/O le operazioni, la profondità della I/O coda e il throughput di rete. Puoi raccogliere queste metriche con un servizio come Container Insights. CloudWatch Puoi inoltre rilevarli utilizzando Amazon Managed Service per Prometheus insieme a Grafana gestito da Amazon. Durante questo processo, assicurati di rilevare e monitorare i parametri relative ai tempi di risposta della tua applicazione o ai tassi di completamento del lavoro. Quando esegui il test di caricamento, inizia con un tasso ridotto di inserimento di richieste o processi. Mantieni questa frequenza costante per diversi minuti per consentire all'applicazione di prepararsi. Quindi, aumenta lentamente la velocità e mantienila costante per alcuni minuti. Ripeti questo ciclo, aumentando la frequenza ogni volta fino a quando i tempi di risposta o completamento dell'applicazione non sono troppo lenti per soddisfare gli obiettivi a livello di servizio (). SLOs Durante il test di caricamento esamina ciascun parametro di utilizzo. I parametri che aumentano insieme al carico sono quelli più adatti come migliori parametri di utilizzo. Successivamente, identifica la risorsa che raggiunge la saturazione. Allo stesso tempo, esamina anche i parametri di utilizzo per vedere quale si appiattisce per prima a un livello elevato. Oppure, esamina quale raggiunge per primo il picco massimo e poi blocca l'applicazione. Ad esempio, se l'utilizzo della CPU aumenta dallo 0% al 70-80% man mano che aggiungi carico e poi rimane a quel livello dopo aver aggiunto ancora più carico, allora si può tranquillamente affermare che la CPU è satura. A seconda dell'architettura della CPU, potrebbe non raggiungere mai il 100%. Ad esempio, supponiamo che l'utilizzo della memoria aumenti man mano che aggiungi carico e che l'applicazione si blocchi improvvisamente quando raggiunge il limite di memoria dell'attività o dell'istanza Amazon EC2. In questa situazione, è probabile che la memoria sia stata completamente consumata. L'applicazione potrebbe utilizzare più risorse. Pertanto, scegli il parametro che rappresenta la risorsa che si esaurisce per prima. Infine, riprova a testare il carico dopo aver raddoppiato il numero di attività o di istanze Amazon EC2. Supponiamo che il parametro chiave aumenti o diminuisca della metà rispetto a prima. In tal caso, il parametro è proporzionale alla capacità. Si tratta di un buon parametro di utilizzo per il dimensionamento automatico. Consideriamo ora questo scenario ipotetico. Supponiamo di testare un'applicazione e di scoprire che l'utilizzo della CPU alla fine raggiunge l'80% a 100 richieste al secondo. Quando aggiungi altro carico, l'utilizzo della CPU non aumenta più. Tuttavia, fa sì che l'applicazione risponda più lentamente. Poi esegui nuovamente il test di carico, raddoppiando il numero di attività ma mantenendo la frequenza al valore di picco precedente. Se noti che l'utilizzo medio della CPU scende a circa il 40%, l'utilizzo medio della CPU è un buon candidato come parametro di scalabilità. D'altra parte, se l'utilizzo della CPU rimane all'80% dopo l'aumento del numero di attività, l'utilizzo medio della CPU non è un buon parametro di scalabilità. In tal caso, sono necessarie ulteriori ricerche per trovare un parametro adeguato. ### Modelli di applicazione e proprietà di dimensionamento comuni Puoi eseguire software di ogni tipo su AWS. Molti carichi di lavoro sono creati internamente, mentre altri si basano su software open source comuni. Indipendentemente dalla loro origine, abbiamo osservato alcuni modelli di progettazione comuni per i servizi. Il modo in cui esegui una scalabilità efficace dipende in gran parte dal modello. #### Il server efficiente collegato alla CPU Il server efficiente legato alla CPU non utilizza quasi nessuna risorsa oltre alla CPU e al throughput di rete. Ogni richiesta può essere gestita dalla sola applicazione. Le richieste non dipendono da altri servizi come i database. L'applicazione è in grado di gestire centinaia di migliaia di richieste simultanee e a tale scopo può utilizzarne più CPUs di una in modo efficiente. Ogni richiesta è gestita da un thread dedicato con un basso sovraccarico di memoria, oppure esiste un ciclo di eventi asincrono che viene eseguito su ogni CPU che soddisfa le richieste. Ogni replica dell'applicazione è ugualmente in grado di gestire una richiesta. L'unica risorsa che potrebbe esaurirsi prima della CPU è la larghezza di banda della rete. Nei servizi legati alla CPU, l'utilizzo della memoria, anche al picco del throughput, è una frazione delle risorse disponibili. Per questo tipo di applicazione puoi utilizzare il dimensionamento automatico basato sulla CPU. L'applicazione gode della massima flessibilità in termini di dimensionamento. Puoi scalarlo verticalmente fornendo istanze Amazon EC2 più grandi o Fargate v. CPUs Puoi anche scalarla orizzontalmente aggiungendo più repliche. L'aggiunta di altre repliche o il raddoppio delle dimensioni dell'istanza dimezzano l'utilizzo medio della CPU rispetto alla capacità. Se utilizzi la capacità di Amazon EC2 per questa applicazione, valuta la possibilità di collocarla su istanze ottimizzate per il calcolo come la famiglia `c5` o `c6g`. #### Il server efficiente legato alla memoria Il server efficiente legato alla memoria alloca una quantità significativa di memoria per richiesta. In caso di massima concorrenza, ma non necessariamente throughput, la memoria si esaurisce prima che si esauriscano le risorse della CPU. La memoria associata a una richiesta viene liberata al termine della richiesta. Possono essere accettate richieste aggiuntive purché sia disponibile memoria. Per questo tipo di applicazione puoi utilizzare il dimensionamento automatico basato sulla memoria. L'applicazione gode della massima flessibilità in termini di dimensionamento. Puoi scalarla verticalmente fornendogli risorse di memoria Amazon EC2 o Fargate più grandi. Puoi anche scalarla orizzontalmente aggiungendo più repliche. L'aggiunta di altre repliche o il raddoppio delle dimensioni dell'istanza possono dimezzare l'utilizzo medio della memoria rispetto alla capacità. Se utilizzi la capacità di Amazon EC2 per questa applicazione, valuta la possibilità di collocarla su istanze ottimizzate per la memoria come la famiglia `r5` o `r6g`. Alcune applicazioni legate alla memoria non liberano la memoria associata a una richiesta al termine, quindi una riduzione della concorrenza non si traduce in una riduzione della memoria utilizzata. Per questo consigliamo di non utilizzare il dimensionamento basato sulla memoria. #### Il server basato sul lavoro Il server basato sul lavoro elabora una richiesta per ogni singolo thread di lavoro una dopo l'altra. I thread di lavoro possono essere thread leggeri, come i thread POSIX. Possono anche essere thread più pesanti, come i processi UNIX. Indipendentemente dal thread, c'è sempre una concorrenza massima che l'applicazione è in grado di supportare. Di solito il limite di concorrenza è impostato proporzionalmente alle risorse di memoria disponibili. Se viene raggiunto il limite di concorrenza, l'applicazione inserisce richieste aggiuntive in una coda di backlog. Se la coda di backlog si esaurisce, l'applicazione rifiuta immediatamente le richieste aggiuntive in entrata. Le applicazioni comuni che si adattano a questo modello includono il server web Apache e Gunicorn. La concorrenza delle richieste è in genere il parametro migliore per scalare questa applicazione. Poiché esiste un limite di concorrenza per ogni replica, è importante aumentare orizzontalmente prima che venga raggiunto il limite medio. Il modo migliore per ottenere i parametri relativi alla concorrenza delle richieste consiste nel farli riportare dall'applicazione. CloudWatch Ogni replica dell'applicazione può pubblicare il numero di richieste simultanee come parametro personalizzato ad alta frequenza. Consigliamo di impostare la frequenza su almeno una volta al minuto. Dopo aver raccolto diversi report, puoi utilizzare la concorrenza media come parametro di dimensionamento. Tale parametro si calcola prendendo la concorrenza totale e dividendola per il numero di repliche. Ad esempio, se la concorrenza totale è 1000 e il numero di repliche è 10, la concorrenza media è 100. Se la tua applicazione è alla base di un Application Load Balancer, puoi anche utilizzare il parametro `ActiveConnectionCount` per il bilanciatore del carico come fattore nel parametro di dimensionamento. Per ottenere un valore medio devi dividere il parametro `ActiveConnectionCount` per il numero di repliche. Devi utilizzare il valore medio per il dimensionamento, anziché il valore di conteggio non elaborato. Affinché questa progettazione funzioni al meglio, la deviazione standard della latenza di risposta deve essere minima a basse frequenze di richiesta. È bene che, durante i periodi di scarsa domanda, la maggior parte delle richieste riceva risposta in breve tempo e che non vi siano molte richieste che impiegano molto più tempo della media per rispondere. Il tempo di risposta medio dovrebbe essere vicino al tempo di risposta del 95° percentile. In caso contrario, potrebbero verificarsi sovraccarichi dalla coda. Ciò porta a errori. Consigliamo di fornire repliche aggiuntive laddove necessario per mitigare il rischio di overflow. #### Il server di attesa Il server di attesa esegue alcune elaborazioni per ogni richiesta, ma il funzionamento dipende molto da uno o più servizi a valle. Le applicazioni container fanno spesso un uso intensivo di servizi a valle come database e altri servizi API. La risposta di questi servizi può richiedere del tempo, in particolare in scenari ad alta capacità o ad alta concorrenza. Ciò accade perché tali applicazioni tendono a utilizzare poche risorse della CPU e a sfruttare la massima concorrenza in termini di memoria disponibile. Il servizio di attesa è adatto sia nel modello di server legato alla memoria che nel modello di server basato sul lavoro, a seconda di come è progettata l'applicazione. Se la concorrenza dell'applicazione è limitata solo dalla memoria, bisognerebbe utilizzare l'utilizzo medio della memoria come parametro di dimensionamento. Se la concorrenza dell'applicazione si basa su un limite di lavoratori, bisognerebbe utilizzare la concorrenza media come parametro di dimensionamento. #### Il server basato su Java Se il server basato su Java è legato alla CPU e si adatta proporzionalmente alle risorse della CPU, potrebbe essere adatto all'efficiente modello di server associato alla CPU. In tal caso, l'utilizzo medio della CPU potrebbe essere adatto come parametro di dimensionamento. Tuttavia, molte applicazioni Java non sono legate alla CPU, il che le rende difficili da scalare. Per prestazioni ottimali, consigliamo di allocare quanta più memoria possibile all'heap Java Virtual Machine (JVM). Le versioni recenti di JVM, tra cui l'aggiornamento 191 di Java 8 o le versioni successive, impostano automaticamente la dimensione dell'heap al massimo possibile per adattarla al container. Ciò significa che, in Java, l'utilizzo della memoria è raramente proporzionale all'utilizzo delle applicazioni. Con l'aumento della frequenza delle richieste e della concorrenza, l'utilizzo della memoria rimane costante. Per questo motivo, sconsigliamo di scalare i server basati su Java in base all'utilizzo della memoria. Al contrario, in genere consigliamo di ridimensionare l'utilizzo della CPU. In alcuni casi, i server basati su Java vanno incontro all'esaurimento dell'heap prima di esaurire la CPU. Se l'applicazione è soggetta all'esaurimento dell'heap in caso di elevata simultaneità, il parametro di dimensionamento migliore è rappresentato dalle connessioni medie. Se la tua applicazione è soggetta all'esaurimento dell'heap a un throughput elevato, il parametro di dimensionamento migliore è la frequenza media delle richieste. #### Server che utilizzano altri runtime raccolti tramite rimozione di oggetti inutili Molte applicazioni server si basano su runtime che effettuano la rimozione di oggetti inutili, ad esempio .NET e Ruby. Queste applicazioni server potrebbero rientrare in uno dei modelli descritti in precedenza. Tuttavia, come nel caso di Java, sconsigliamo di scalare tali applicazioni in base alla memoria, poiché il loro utilizzo medio della memoria osservato spesso non è correlato al throughput o alla concorrenza. Per tali applicazioni consigliamo di scalare l'utilizzo della CPU se l'applicazione è vincolata alla CPU. Altrimenti, consigliamo di scalare in base al throughput medio o alla concorrenza media, in base ai risultati dei test di carico. #### Elaboratori di processi Molti carichi di lavoro prevedono l'elaborazione asincrona dei processi. Questi includono applicazioni che non ricevono richieste in tempo reale, ma si iscrivono a una coda di lavoro per ricevere processi. Per questi tipi di applicazioni, il parametro di dimensionamento adatto è quasi sempre la profondità della coda. L'aumento della coda indica che il lavoro in sospeso supera la capacità di elaborazione, mentre una coda vuota indica che c'è più capacità del lavoro da fare. AWS i servizi di messaggistica, come Amazon SQS e Amazon Kinesis Data Streams, CloudWatch forniscono metriche che possono essere utilizzate per la scalabilità. Per Amazon SQS, `ApproximateNumberOfMessagesVisible` è il parametro migliore. Per Kinesis Data Streams, considera l'utilizzo del parametro `MillisBehindLatest`, pubblicato dalla Kinesis Client Library (KCL). È necessario calcolare la media di questo parametro tra tutti i consumatori prima di utilizzarlo per il dimensionamento. # 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: + Se puoi creare un file binario statico o usare Golang, crea la tua immagine `FROM` zero e includi solo la tua applicazione binaria nell'immagine risultante. + Usa immagini di base ridotte al minimo da fornitori di distribuzioni upstream, come Amazon Linux o Ubuntu. + Non includere artefatti di costruzione nell'immagine finale. L'utilizzo di build in più fasi può aiutarti in questo senso. + Compatta le fasi `RUN` laddove possibile. Ogni fase `RUN` crea un nuovo livello di immagine, che comporta un ulteriore percorso di andata e ritorno per scaricare il livello. Una singola fase `RUN` con più comandi uniti da `&&` ha meno livelli di una con più fasi `RUN`. + Se desideri includere dati, come i dati di inferenza ML, nell'immagine finale, includi solo i dati necessari per avviare e iniziare a generare traffico. Se recuperi dati su richiesta da Amazon S3 o da un altro spazio di archiviazione senza influire sul servizio, allora archivia i dati lì. **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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) nella *Guida per gli sviluppatori di Amazon Elastic Container Service*. Se utilizzi istanze Amazon EC2 per fornire capacità di cluster, prendi in considerazione i seguenti consigli: **Utilizza istanze Amazon EC2 più grandi e volumi Amazon EBS più veloci.** Puoi migliorare la velocità di download e preparazione delle immagini utilizzando un'istanza Amazon EC2 più grande e un volume Amazon EBS più veloce. All'interno di una determinata famiglia di istanze Amazon EC2, la rete e il throughput massimo di Amazon EBS aumentano all'aumentare delle dimensioni dell'istanza (ad esempio, da `m5.xlarge` a `m5.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 istanze Amazon EC2.** Le attività che utilizzano la modalità di rete `bridge` su Amazon EC2 vengono avviate più rapidamente delle attività che utilizzano la modalità di rete `awsvpc`. 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html) 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](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) 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. # Capacità dei cluster Amazon ECS Puoi fornire capacità a un cluster Amazon ECS in diversi modi. Ad esempio, puoi avviare istanze Amazon EC2 e registrarle nel cluster all'avvio utilizzando l'agente container Amazon ECS. Tuttavia, questo metodo può essere difficile perché devi gestire la scalabilità per conto tuo. Pertanto, consigliamo di utilizzare i provider di capacità di Amazon ECS. I provider di capacità gestiscono la scalabilità delle risorse per te. Esistono tre tipi di provider di capacità: Amazon EC2, Fargate e Fargate Spot. Per ulteriori informazioni sui provider di capacità Fargate, consulta [Cluster Amazon ECS per carichi di lavoro Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html) e, per i carichi di lavoro EC2, consulta [Cluster Amazon ECS per carichi di lavoro EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html). I provider di capacità Fargate e Fargate Spot gestiscono per conto tuo il ciclo di vita delle attività Fargate. Fargate fornisce capacità su richiesta e Fargate Spot fornisce capacità Spot. Quando avvii un'attività, Amazon ECS fornisce una risorsa Fargate per te. Questa risorsa Fargate include la memoria e le unità CPU che corrispondono direttamente ai limiti a livello di attività dichiarati nella definizione dell'attività. Ogni attività riceve la propria risorsa Fargate, che crea una relazione 1:1 tra l'attività e le risorse di elaborazione. Le attività eseguite su Fargate Spot sono soggette a interruzioni. Le interruzioni arrivano dopo un avviso di due minuti. Si verificano durante i periodi di forte domanda. Fargate Spot funziona al meglio per carichi di lavoro tolleranti alle interruzioni come lavori in batch, ambienti di sviluppo o staging. È adatto anche per qualsiasi altro scenario in cui l'alta disponibilità e la bassa latenza non siano un requisito. Puoi eseguire le attività Fargate Spot insieme alle attività Fargate on demand. Usandole insieme, ottieni una capacità “di espansione” di fornitura a un costo inferiore. Amazon ECS può anche gestire la capacità delle istanze Amazon EC2 per le tue attività. Ogni provider di capacità Amazon EC2 è associato a un gruppo Amazon EC2 Auto Scaling specificato da te. Quando utilizzi il provider di capacità Amazon EC2, il dimensionamento automatico del cluster mantiene le dimensioni del gruppo Amazon EC2 Auto Scaling per garantire che tutte le attività pianificate possano essere eseguite. # Scelta delle dimensioni delle attività Fargate per Amazon ECS Per le definizioni delle AWS Fargate attività, è necessario specificare CPU e memoria a livello di attività e non è necessario tenere conto di alcun sovraccarico. Per le attività Fargate, puoi anche specificare CPU e memoria a livello di container. Tuttavia non è obbligatorio farlo. I limiti delle risorse devono essere maggiori o uguali a qualsiasi prenotazione da te dichiarata. Nella maggior parte dei casi, puoi impostarli sulla somma delle prenotazioni di ogni container dichiarato nella definizione dell'attività. Dopodiché, arrotonda il numero alla dimensione Fargate più vicina. Per ulteriori informazioni sulle dimensioni disponibili, consulta [CPU e memoria delle attività](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size). # Accelerazione del provisioning della capacità dei cluster Amazon ECS con i provider di capacità su Amazon EC2 I clienti che eseguono Amazon ECS su Amazon EC2 possono sfruttare il [Dimensionamento automatico dei cluster Amazon ECS (CAS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) per gestire la scalabilità dei gruppi Amazon EC2 Auto Scaling (ASG). Con il CAS puoi configurare Amazon ECS per scalare automaticamente il tuo ASG e concentrarti solo sull'esecuzione delle tue attività. Amazon ECS garantirà la scalabilità interna e orizzontale dell'ASG in base alle necessità senza ulteriori interventi. I provider di capacità Amazon ECS vengono utilizzati per gestire l'infrastruttura nel cluster, garantendo che vi siano istanze di container sufficienti a soddisfare le esigenze dell'applicazione. Per maggiori informazioni su come funziona il CAS di Amazon ECS, consulta [Approfondimento sul dimensionamento automatico dei cluster Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). Poiché CAS si basa su un'integrazione CloudWatch basata su ASG per regolare la capacità del cluster, presenta una latenza intrinseca associata alla pubblicazione delle CloudWatch metriche, al tempo impiegato dalla metrica per `CapacityProviderReservation` violare gli CloudWatch allarmi (sia alto che basso) e al tempo impiegato da un'istanza Amazon EC2 appena lanciata per il riscaldamento. Puoi adottare le seguenti misure per rendere il CAS più reattivo per implementazioni più rapide: ## Scalabilità graduale delle dimensioni del provider di capacità I fornitori di capacità di Amazon ECS alla fine troveranno grow/shrink le istanze di container più adatte a soddisfare le esigenze della tua applicazione. Il numero minimo di istanze che Amazon ECS avvierà è impostato su 1 per impostazione predefinita. Ciò potrebbe comportare un aumento dei tempi di implementazione, qualora fossero necessarie diverse istanze per l'esecuzione delle attività in sospeso. Puoi aumentare la [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) utilizzando l'API Amazon ECS per aumentare il numero minimo di istanze scalabili da Amazon ECS per volta. Un valore [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) troppo basso può limitare il numero di istanze di container scalate in entrata o in uscita alla volta, rallentando le implementazioni. **Nota** Questa configurazione è attualmente disponibile solo utilizzando o. [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) APIs ## Periodo di preparazione dell'istanza Il periodo di riscaldamento dell'istanza è il periodo di tempo dopo il quale un'istanza Amazon EC2 appena lanciata può contribuire CloudWatch ai parametri per il gruppo Auto Scaling. Alla fine del periodo di riscaldamento specificato, l'istanza viene conteggiata ai fini delle metriche aggregate dell'ASG e il CAS procede con la successiva iterazione di calcoli per stimare il numero di istanze richieste. Il valore predefinito per [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)è 300 secondi, che puoi configurare su un valore inferiore utilizzando [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs per un ridimensionamento più reattivo. ## Capacità di riserva Se il tuo provider di capacità non dispone di istanze di container per l'inserimento delle attività, deve aumentare orizzontalmente la capacità del cluster avviando immediatamente le istanze Amazon EC2 e attendere che si avviino prima di poter avviare container su di esse. Questo può ridurre significativamente la velocità di avvio delle attività. Sono quindi disponibili due opzioni. In questo caso, disporre di capacità Amazon EC2 di riserva già avviata e pronta per l'esecuzione delle attività aumenterà la velocità effettiva di avvio delle attività. Puoi usare la configurazione `Target Capacity` per indicare che vuoi mantenere una capacità di riserva nei cluster. Ad esempio, impostando `Target Capacity` all'80%, indichi che il cluster necessita di una capacità di riserva del 20% in ogni momento. Questa capacità di riserva consente di avviare immediatamente qualsiasi attività autonoma, garantendo che l'avvio delle attività non sia limitato. Il compromesso, nel caso di questo approccio, è il potenziale aumento dei costi legati al mantenimento della capacità di riserva del cluster. Un approccio alternativo che si può prendere in considerazione è quello di aggiungere margine di manovra al tuo servizio, e non al provider di capacità. Ciò significa che invece di ridurre la configurazione della `Target Capacity` per avviare la capacità di riserva, puoi aumentare il numero di repliche nel servizio modificando la metrica di dimensionamento di monitoraggio delle destinazioni o le soglie di dimensionamento graduale del dimensionamento automatico. Tieni presente che questo approccio sarà utile solo per i carichi di lavoro soggetti a picchi, ma non avrà alcun effetto quando si implementano nuovi servizi e si passa da 0 a N attività per la prima volta. Per ulteriori informazioni sui criteri di dimensionamento correlati, consulta le [Policy di dimensionamento di monitoraggio delle destinazioni](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) o le [Policy di dimensionamento per fasi](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)