{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Creazione di un'API scalabile su istanze spot AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti! Mi chiamo Kirill, sono il CTO di Adapty. Gran parte della nostra architettura si trova su AWS e oggi vi parler\u00f2 di come abbiamo ridotto i costi dei server di tre volte utilizzando istanze spot in ambiente di produzione, oltre a come configurare il loro autoscaling. Inizialmente ci sar\u00e0 una panoramica di come funziona, seguita da istruzioni dettagliate per l'avvio.<\/p>\n

<\/p>\n

Cosa sono le istanze spot?<\/h2>\n

<\/p>\n

Istanze spot<\/a><\/noindex> Gli istanze sono server di altri utenti AWS che in questo momento sono inattivi e li vendono a un grande sconto (Amazon afferma fino al 90%, ma dalla nostra esperienza \u00e8 circa 3 volte, variabile a seconda della regione, AZ e del tipo di istanza). La loro principale differenza rispetto agli ordinari \u00e8 che possono spegnersi in qualsiasi momento. Pertanto, per molto tempo abbiamo ritenuto che fosse opportuno utilizzarli per ambienti di sviluppo o per compiti di calcolo, salvando i risultati intermedi su S3 o in un database, ma non per la produzione. Esistono soluzioni di terze parti che consentono di utilizzare gli spot in produzione, ma nel nostro caso ci sono molte complicazioni, quindi non le abbiamo implementate. L'approccio descritto nell'articolo funziona completamente all'interno delle funzionalit\u00e0 standard di AWS, senza script aggiuntivi, cron o simili.<\/p>\n

<\/a><\/noindex><\/p>\n

Di seguito troverai alcuni screenshot che mostrano la cronologia dei prezzi per le istanze spot.<\/p>\n

<\/p>\n

m5.large nella regione eu-west-1 (Irlanda). Il prezzo \u00e8 prevalentemente stabile per 3 mesi, attualmente il risparmio \u00e8 di 2.9x.<\/p>\n

<\/p>\n

\"Creazione<\/p>\n

<\/p>\n

m5.large nella regione us-east-1 (Virginia del Nord). Il prezzo cambia continuamente da 3 mesi, al momento il risparmio va da 2,3x a 2,8x a seconda della zona di disponibilit\u00e0.<\/p>\n

<\/p>\n

\"Creazione<\/p>\n

<\/p>\n

t3.small nella regione us-east-1 (Virginia del Nord). Il prezzo \u00e8 stabile da 3 mesi, al momento il risparmio \u00e8 di 3,4x.<\/p>\n

<\/p>\n

\"Creazione<\/p>\n

<\/p>\n

Architettura del servizio<\/h2>\n

<\/p>\n

L'architettura di base del servizio di cui parleremo in questo articolo \u00e8 illustrata nel diagramma qui sotto.<\/p>\n

<\/p>\n

\"Creazione<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Come bilanciatore, viene utilizzato l'Application Load Balancer (ALB), che invia le richieste al EC2 Target Group (TG). TG \u00e8 responsabile dell'apertura delle porte sugli istanze per l'ALB e della loro connessione con le porte dei container Elastic Container Service (ECS). ECS \u00e8 l'equivalente di Kubernetes in AWS, che gestisce i container Docker.<\/p>\n

<\/p>\n

Su un'istanza possono esserci pi\u00f9 contenitori in esecuzione con le stesse porte, quindi non possiamo specificarle in modo fisso. ECS informa TG che sta avviando un nuovo task (nella terminologia di Kubernetes questo \u00e8 chiamato pod), essa verifica le porte disponibili sull'istanza e ne assegna una per il task in avvio. Inoltre, TG controlla regolarmente se l'istanza e l'API su di essa funzionano tramite health check, e se rileva problemi, smette di inviare richieste a quell'istanza.<\/p>\n

<\/p>\n

Gruppi di Auto Scaling EC2 + Fornitori di Capacit\u00e0 ECS<\/h3>\n

<\/p>\n

Nella diagramma sopra riportata non \u00e8 mostrato il servizio Gruppi di Auto Scaling EC2 (ASG). Dal nome si pu\u00f2 dedurre che \u00e8 responsabile della scalabilit\u00e0 delle istanze. Fino a tempi recenti, AWS non disponeva di un'opzione integrata per gestire il numero di macchine avviate da ECS. ECS permette di scalare il numero di task, ad esempio, in base all'utilizzo della CPU, della RAM o al numero di richieste. Tuttavia, se i task occupavano tutte le istanze disponibili, nuove macchine non venivano automaticamente attivate.<\/p>\n

<\/p>\n

Questo \u00e8 cambiato con l'introduzione degli ECS Capacity Providers (ECS CP). Ora ogni servizio in ECS pu\u00f2 essere collegato a un ASG, e se i task non si adattano alle istanze in esecuzione, ne verranno avviate di nuove (ma entro i limiti stabiliti dall'ASG). Funziona anche in direzione opposta: se ECS CP rileva istanze inattive senza task, ordiner\u00e0 all'ASG di spegnerle. ECS CP ha la possibilit\u00e0 di specificare una percentuale obiettivo di utilizzo delle istanze, in modo da mantenere un certo numero di macchine sempre disponibili per una rapida scalabilit\u00e0 dei task, ne parler\u00f2 pi\u00f9 avanti.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

L'ultimo servizio di cui parler\u00f2, prima di passare a una descrizione dettagliata della creazione di questa infrastruttura, \u00e8 EC2 Launch Templates. Consente di creare un modello in base al quale verranno avviate tutte le macchine, per evitare di dover ripetere questa operazione ogni volta da zero. Qui puoi scegliere il tipo di macchina da avviare, il gruppo di sicurezza, l'immagine del disco e molti altri parametri. \u00c8 anche possibile specificare dati utente, che saranno caricati su tutte le istanze avviate. Nei dati utente, puoi eseguire script; ad esempio, \u00e8 possibile modificare il contenuto di un file. configurazioni dell'agente ECS<\/a><\/noindex>.<\/p>\n

<\/p>\n

Uno dei parametri di configurazione pi\u00f9 importanti in questo articolo \u00e8 ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Se questo parametro \u00e8 attivato, non appena ECS riceve il segnale che un'istanza spot sta per essere prelevata, tutte le attivit\u00e0 in esecuzione su di essa vengono messe nello stato Draining. Nessuna nuova attivit\u00e0 sar\u00e0 assegnata a quest'istanza; se ci sono attivit\u00e0 che vogliono essere distribuite su di essa, verranno annullate. Anche le richieste dal bilanciatore smettono di arrivare. La notifica di rimozione dell'istanza arriva 2 minuti prima dell'evento reale. Pertanto, se il tuo servizio non esegue attivit\u00e0 per pi\u00f9 di 2 minuti e non salva nulla su disco, puoi utilizzare le istanze spot senza perdita di dati.<\/p>\n

<\/p>\n

Per quanto riguarda il disco, AWS recentemente ha fatto<\/a><\/noindex> \u00e8 possibile utilizzare Elastic File System (EFS) insieme a ECS; con questo schema, persino il disco non rappresenta un ostacolo, ma non lo abbiamo provato, poich\u00e9 in linea di principio non abbiamo bisogno del disco per memorizzare lo stato. Di default, dopo aver ricevuto SIGINT (inviato nel momento in cui il task passa allo stato Draining), tutte le attivit\u00e0 in esecuzione verranno interrotte dopo 30 secondi, anche se non sono state completate; questo tempo pu\u00f2 essere modificato tramite il parametro ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. \u00c8 importante non impostarlo su pi\u00f9 di 2 minuti per le istanze spot.<\/p>\n

<\/p>\n

Creazione del servizio<\/h2>\n

<\/p>\n

Ora passiamo direttamente alla creazione del servizio descritto. Durante il processo descriver\u00f2 anche alcuni punti utili che non sono stati menzionati sopra. In generale, si tratta di un'istruzione passo passo, ma non esaminer\u00f2 casi davvero molto basilari o molto specifici. Tutte le azioni vengono eseguite nella console visiva di AWS, ma possono essere replicate programmaticamente con CloudFormation o Terraform. In Adapty utilizziamo Terraform.<\/p>\n

<\/p>\n

EC2 Launch Template<\/strong><\/h3>\n

<\/p>\n

In questo servizio viene creata una configurazione delle macchine che verranno utilizzate. La gestione dei template avviene nella sezione EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Amazon machine image (AMI)<\/strong> \u2014 specifichiamo l'immagine del disco da cui partiranno tutte le istanze. Per ECS, nella maggior parte dei casi \u00e8 consigliabile utilizzare un'immagine ottimizzata di Amazon. Viene aggiornata regolarmente e contiene tutto il necessario per far funzionare ECS. Per conoscere l'ID attuale dell'immagine, accediamo alla pagina Amazon ECS-optimized AMIs<\/a><\/noindex>, selezioniamo la regione utilizzata e copiamo l'AMI ID corrispondente. Ad esempio, per la regione us-east-1, l'ID attuale al momento della scrittura \u00e8 ami-00c7c1cf5bdc913ed<\/em>. Questo ID deve essere inserito nel campo Specifica un valore personalizzato.<\/p>\n

<\/p>\n

Tipo di istanza<\/strong> \u2014 specifichiamo il tipo di istanza. Scegli quello che si adatta meglio alle tue esigenze.<\/p>\n

<\/p>\n

Coppia di chiavi (accesso)<\/strong> \u2014 specifichiamo il certificato con cui sar\u00e0 possibile connettersi all'istanza tramite SSH, se necessario.<\/p>\n

<\/p>\n

Impostazioni di rete<\/strong> \u2014 specifichiamo i parametri di rete. Piattaforma di rete<\/strong> nella maggior parte dei casi deve essere Virtual Private Cloud (VPC). Gruppi di sicurezza<\/strong> \u2014 gruppi di sicurezza per le tue istanze. Poich\u00e9 utilizzeremo un bilanciatore di carico davanti alle istanze, ti consiglio di specificare qui un gruppo che consenta connessioni in ingresso solo dal bilanciatore. Ci\u00f2 significa che avrai 2 gruppi di sicurezza: uno per il bilanciatore, che consente connessioni in ingresso (inbound) da ovunque sulle porte 80 (http) e 443 (https), e l'altro per le macchine, che consente connessioni in ingresso su qualsiasi porta dal gruppo del bilanciatore. Le connessioni in uscita (outbound) in entrambi i gruppi devono essere consentite tramite il protocollo TCP su tutte le porte verso tutti gli indirizzi. \u00c8 possibile limitare le porte e gli indirizzi per le connessioni in uscita, ma in tal caso \u00e8 necessario monitorare costantemente che non si stia cercando di accedere a una porta chiusa.<\/p>\n

<\/p>\n

Storage (volumes)<\/strong> \u2014 specifichiamo le impostazioni del disco per le macchine. La dimensione del disco non pu\u00f2 essere inferiore a quella definita nell'AMI, per ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

Dettagli avanzati<\/strong> \u2014 specifichiamo parametri aggiuntivi.<\/p>\n

<\/p>\n

Opzione di acquisto<\/strong> \u2014 vogliamo acquistare istanze spot. Vogliamo, ma qui non selezioneremo questa opzione, la configureremo nel Gruppo di Scaling Automatico, dove ci sono pi\u00f9 opzioni.<\/p>\n

<\/p>\n

Profilo istanza IAM<\/strong> \u2014 indichiamo il ruolo con cui verranno avviate le istanze. Affinch\u00e9 le istanze funzionino in ECS, hanno bisogno dei permessi che di solito sono associati al ruolo ecsInstanceRole<\/em>. In alcuni casi, questo pu\u00f2 essere creato; in caso contrario, qui una guida<\/a><\/noindex> \u00e8 spiegato come farlo. Dopo la creazione, lo indichiamo nel modello.
\nDopo ci sono molti parametri; in generale, si possono lasciare i valori predefiniti, ma ognuno di essi ha una descrizione chiara. Io attivo sempre i parametri EBS-optimized instance e T2\/T3 Unlimited, se si utilizzano burstable<\/a><\/noindex> istanze.<\/p>\n

<\/p>\n

User data<\/strong> \u2014 indichiamo i dati utente. Modificheremo il file \/etc\/ecs\/ecs.config<\/code>, in cui \u00e8 presente la configurazione dell'agente ECS.
\nEcco un esempio di come potrebbero apparire i dati utente:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 questo parametro indica che l'istanza appartiene a un cluster con il nome specificato, il quale potr\u00e0 quindi eseguire i propri task su questo server. Non abbiamo ancora creato un cluster, ma quando lo faremo utilizzeremo questo nome.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 questo parametro indica che, quando si riceve un segnale di spegnimento per un'istanza spot, tutti i task su di essa devono essere spostati nello stato Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 il parametro indica che, dopo aver ricevuto il segnale SIGINT, tutte le attivit\u00e0 hanno 1 minuto prima di essere terminate.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 il parametro indica che viene utilizzato lo schema docker come meccanismo di autorizzazione.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 i parametri di connessione per il registro privato dei container, dove sono memorizzate le tue immagini Docker. Se \u00e8 pubblico, non \u00e8 necessario specificare nulla.<\/p>\n
<\/p>\n
In questo articolo utilizzer\u00f2 un'immagine pubblica da Docker Hub, quindi non \u00e8 necessario specificare i parametri. ECS_ENGINE_AUTH_TYPE<\/code> e ECS_ENGINE_AUTH_DATA<\/code> non \u00e8 necessario.<\/p>\n
<\/p>\n
\u00c8 utile sapere<\/strong>: si raccomanda di aggiornare regolarmente l'AMI, poich\u00e9 nelle nuove versioni vengono aggiornati Docker, Linux, ECS agent e altro. Per non dimenticarlo, puoi configurare notifiche<\/a><\/noindex> sull'uscita di nuove versioni. Puoi ricevere notifiche via email e aggiornare manualmente, oppure puoi scrivere una funzione Lambda che creer\u00e0 automaticamente una nuova versione del Launch Template con AMI aggiornato.<\/p>\n
<\/p>\n
Gruppo di Auto Scaling EC2<\/strong><\/h3>\n
<\/p>\n
Il Gruppo di Auto Scaling gestisce l'avvio e la scalabilit\u00e0 delle istanze. La gestione dei gruppi avviene nella sezione EC2 -> Auto Scaling -> Gruppi di Auto Scaling.<\/p>\n
<\/p>\n
Template di avvio<\/strong> \u2014 selezioniamo il template creato nel passaggio precedente. Lasciamo la versione predefinita.<\/p>\n
<\/p>\n
Opzioni di acquisto e tipi di istanza<\/strong> \u2014 specifichiamo i tipi di istanze per il cluster. Adhere to launch template utilizza il tipo di istanza del Launch Template. Combine purchase options and instance types consente di configurare flessibilmente i tipi di istanze. Lo utilizzeremo.<\/p>\n
<\/p>\n
Base on-demand opzionale<\/strong> \u2014 il numero di istanze normali, non spot, che saranno sempre attive.<\/p>\n
<\/p>\n
Percentuale on-demand oltre la base<\/strong> \u2014 la proporzione tra istanze normali e istanze spot, 50-50 distribuir\u00e0 uniformemente, 20-80 comporter\u00e0 l'innalzamento di 4 istanze spot per ogni istanza normale. In questo esempio indicher\u00f2 50-50, ma nella realt\u00e0 facciamo spesso 20-80, in alcuni casi 0-100.<\/p>\n
<\/p>\n
Tipi di istanze<\/strong> \u2014 qui si possono indicare ulteriori tipi di istanze che saranno utilizzati nel cluster. Non li abbiamo mai usati, perch\u00e9 non capisco bene il senso di questa storia. Forse \u00e8 legato ai limiti su specifici tipi di istanze, ma si possono aumentare facilmente tramite il supporto. Se conoscete un'applicazione, sarei felice di leggerla nei commenti)<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Network\n   log \/dev\/log local0\n   log \/dev\/log local1 notice\n   chroot \/var\/lib\/haproxy\n   stats timeout 30s\n   user haproxy\n   group haproxy\n   daemon\n\ndefaults\n   log global\n   mode http\n   option httplog\n   option dontlognull\n   timeout connect 5000\n   timeout client 50000\n   timeout server 50000\n\nfrontend http_front\n   bind *:80\n   stats uri \/haproxy?stats\n   default_backend http_back\n\nbackend http_back\n   balance roundrobin\n   server server_name1 private_ip1:80 check\n   server server_name2 private_ip2:80 check<\/strong> \u2014 impostazioni di rete, si scelgono VPC e subnet per le macchine; nella maggior parte dei casi \u00e8 opportuno selezionare tutte le subnet disponibili.<\/p>\n
<\/p>\n
Bilanciamento del carico<\/strong> \u2014 impostazioni del bilanciatore, ma faremo questo separatamente; qui non tocchiamo nulla. Controlli di salute<\/strong> saranno configurati successivamente.<\/p>\n
<\/p>\n
Dimensione del gruppo<\/strong> \u2014 indichiamo i limiti sul numero di macchine nel cluster e il numero desiderato di macchine all'avvio. Il numero di macchine nel cluster non sar\u00e0 mai inferiore a quello minimo indicato e non superer\u00e0 quello massimo, anche se gli metriche suggeriscono un'espansione.<\/p>\n
<\/p>\n
Politiche di scaling<\/strong> \u2014 parametri di scaling, ma scaleremo basandoci sui task ECS in esecuzione, quindi configureremo lo scaling successivamente.<\/p>\n
<\/p>\n
Protezione della scala degli istanze<\/strong> \u2014 protezione delle istanze dalla rimozione durante il ridimensionamento. Attiviamo in modo che l'ASG non rimuova la macchina con task in esecuzione. Disattivare la protezione per le istanze senza task sar\u00e0 compito del Provider di Capacit\u00e0 ECS.<\/p>\n
<\/p>\n
Aggiungi tag<\/strong> \u2014 \u00e8 possibile specificare tag per le istanze (per questo deve essere selezionata l'opzione Tag new instances). Si consiglia di specificare il tag Nome, in modo che tutte le istanze avviate all'interno del gruppo abbiano lo stesso nome, facilitando la visualizzazione nella console.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Dopo aver creato il gruppo, aprilo e vai alla sezione Configurazioni avanzate, perch\u00e9 in fase di creazione non tutte le opzioni sono visibili nella console.<\/p>\n
<\/p>\n
Politiche di terminazione<\/strong> \u2014 le regole che vengono seguite durante la rimozione delle istanze. Vengono applicate in ordine. Di solito utilizziamo quelle nella figura sottostante. Prima si rimuovono le istanze con il Launch Template pi\u00f9 vecchio (ad esempio, se abbiamo aggiornato l'AMI, si \u00e8 creata una nuova versione, ma tutte le istanze sono riuscite a passare a questa). Poi si scelgono le istanze pi\u00f9 vicine al prossimo orario di fatturazione calcolato. E poi si selezionano le pi\u00f9 vecchie in base alla data di avvio.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
\u00c8 utile sapere<\/strong>: per aggiornare tutte le macchine nel cluster, \u00e8 comodo utilizzare Instance Refresh<\/a><\/noindex>. Se combinato con una funzione Lambda dal passo precedente, avrete un sistema di aggiornamento delle istanze completamente automatizzato. Prima di aggiornare tutte le macchine, \u00e8 necessario disattivare la protezione dal ridimensionamento delle istanze per tutte le istanze nel gruppo. Non la configurazione nel gruppo, ma proprio la protezione delle macchine, che pu\u00f2 essere disattivata nella scheda gestione delle istanze.<\/p>\n
<\/p>\n
Application Load Balancer e EC2 Target Group<\/h3>\n
<\/p>\n
Il bilanciatore viene creato nella sezione EC2 \u2192 Load Balancing \u2192 Load Balancers. Utilizzeremo l'Application Load Balancer, per un confronto tra i vari tipi di bilanciatori si pu\u00f2 leggere la pagina del servizio<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u00c8 consigliabile configurare le porte 80 e 443 e effettuare un reindirizzamento dalla 80 alla 443 tramite regole del bilanciatore.<\/p>\n
<\/p>\n
Zone di disponibilit\u00e0<\/strong> In molti casi, selezioniamo tutte le zone di disponibilit\u00e0.<\/p>\n
<\/p>\n
Configura le impostazioni di sicurezza<\/strong> Qui si specifica il certificato SSL per il bilanciatore; l'opzione pi\u00f9 comoda \u00e8 utilizzare un certificato<\/a><\/noindex> in ACM. Puoi leggere delle differenze Politica di Sicurezza<\/strong> nel documentazione<\/a><\/noindex>, puoi lasciare quella selezionata di default ELBSecurityPolicy-2016-08<\/code>. Dopo la creazione del bilanciatore, vedrai il suo nome DNS<\/strong>, per il quale dovrai configurare un CNAME per il tuo dominio. Ecco un esempio di come appare in Cloudflare.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Gruppo di Sicurezza<\/strong> Creiamo o selezioniamo un gruppo di sicurezza per il bilanciatore; ne ho parlato pi\u00f9 sopra nella sezione Template di Avvio EC2 \u2192 Impostazioni di rete.<\/p>\n
<\/p>\n
Gruppo di destinazione<\/strong> creiamo un gruppo responsabile del routing delle richieste dal bilanciatore alle macchine e ne verifica la disponibilit\u00e0 per sostituirle in caso di problemi. Tipo di destinazione<\/strong> deve essere Instance, Protocollo<\/strong> e Port<\/strong> qualsiasi, se utilizzi HTTPS per la comunicazione tra il bilanciatore e le istanze, allora devi caricare il certificato su di esse. Nel contesto di questo esempio, non lo faremo, semplicemente lasceremo la porta 80.<\/p>\n
<\/p>\n
Controlli di salute<\/strong> \u2014 parametri di verifica della funzionalit\u00e0 del servizio. In questo servizio, deve trattarsi di una richiesta separata che implementa parti cruciali della logica aziendale; per questo esempio, lascer\u00f2 le impostazioni predefinite. Successivamente, \u00e8 possibile scegliere l'intervallo delle richieste, il timeout, i codici di risposta di successo, e altro. Nel nostro esempio, indicheremo i codici di successo 200-399, perch\u00e9 l'immagine Docker utilizzata restituisce il codice 304.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Registrare obiettivi<\/strong> \u2014 qui si scelgono le macchine per il gruppo, ma nel nostro caso ci penser\u00e0 ECS, quindi saltiamo semplicemente questo passaggio.<\/p>\n
<\/p>\n
\u00c8 utile sapere<\/strong>: a livello del bilanciatore di carico, \u00e8 possibile attivare i log che verranno salvati in S3 in un certo formato<\/a><\/noindex>. Da l\u00ec, possono essere esportati in servizi esterni per analisi, oppure \u00e8 possibile eseguire query SQL direttamente sui dati in S3 con l'aiuto di Athena<\/a><\/noindex>. Questo \u00e8 comodo e funziona senza alcun codice aggiuntivo. Raccomando inoltre di impostare la cancellazione dei log dal bucket S3 dopo un periodo di tempo specifico.<\/p>\n
<\/p>\n
Definizione del compito ECS<\/h3>\n
<\/p>\n
Nei passaggi precedenti abbiamo creato tutto ci\u00f2 che riguarda l'infrastruttura del servizio, ora passiamo alla descrizione dei container che lanciamo. Questo viene fatto nella sezione ECS \u2192 Definizioni di Task.<\/p>\n
<\/p>\n
Tipologia di compatibilit\u00e0 del lancio<\/strong> \u2014 scegliamo EC2.<\/p>\n
<\/p>\n
Ruolo IAM di esecuzione del task<\/strong> \u2014 selezioniamo ecsTaskExecutionRole<\/code>. Con questo ruolo vengono registrati i log, viene fornito accesso a variabili segrete e altro.<\/p>\n
<\/p>\n
Nella sezione Definizioni di Container clicchiamo su Aggiungi Container.<\/p>\n
<\/p>\n
Image<\/strong> \u2014 link all'immagine con il codice del progetto, in questo esempio utilizzer\u00f2 un'immagine pubblica da Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Limiti di Memoria<\/strong> \u2014 limiti di memoria per il container. Limite Fisso<\/strong> \u2014 limite fisso, se il container supera il valore specificato, verr\u00e0 eseguita il comando docker kill, il container morir\u00e0 immediatamente. Limite Morbido<\/strong> \u2014 limite morbido, il contenitore pu\u00f2 superare il valore specificato, ma durante l'assegnazione dei task alle macchine verr\u00e0 considerato questo parametro. Ad esempio, se c'\u00e8 4 GiB di memoria RAM sulla macchina e il limite morbido del contenitore \u00e8 di 2048 MiB, allora su questa macchina possono essere eseguiti al massimo 2 task con questo contenitore. In realt\u00e0, 4 GiB di RAM sono leggermente inferiori a 4096 MiB, come si pu\u00f2 vedere nella scheda ECS Instances nel cluster. Il limite morbido non pu\u00f2 essere maggiore del limite rigido. \u00c8 importante comprendere che se in un task ci sono pi\u00f9 contenitori, i loro limiti si sommano.<\/p>\n
<\/p>\n
Mappature delle porte<\/strong> \u2014 in Porta host<\/strong> se specifichiamo 0, questo significa che la porta verr\u00e0 assegnata in modo dinamico, verr\u00e0 monitorata dal Target Group. Porta del contenitore<\/strong> \u2014 porta sulla quale funziona la tua applicazione, spesso impostata nel comando di esecuzione, o assegnata nel codice della tua applicazione, Dockerfile, ecc. Per il nostro esempio useremo 3000, poich\u00e9 \u00e8 specificato in Dockerfile<\/a><\/noindex> l'immagine utilizzata.<\/p>\n
<\/p>\n
Controllo dello stato<\/strong> \u2014 parametri di controllo della funzionalit\u00e0 del contenitore, non confondere con quello impostato nel Target Group.<\/p>\n
<\/p>\n
Ambiente<\/strong> \u2014 impostazioni ambientali. Unit\u00e0 CPU<\/strong> \u2014 simile ai limiti di memoria, ma riguarda il processore. Ogni core del processore corrisponde a 1024 unit\u00e0, quindi se il server ha un processore dual-core e il valore impostato per il container \u00e8 512, sar\u00e0 possibile eseguire 4 task con quel container su uno stesso server. Le unit\u00e0 CPU corrispondono sempre al numero di core, non possono essere leggermente inferiori come nel caso della memoria.<\/p>\n
<\/p>\n
Comando<\/strong> \u2014 comando per avviare il servizio all'interno del container, tutti i parametri devono essere separati da una virgola. Pu\u00f2 essere gunicorn, npm, ecc. Se non specificato, verr\u00e0 utilizzato il valore della direttiva CMD dal Dockerfile. Indichiamo npm,start<\/code>.<\/p>\n
<\/p>\n
Variabili ambientali<\/strong> \u2014 variabili d'ambiente del container. Queste possono essere dati testuali semplici, cos\u00ec come variabili segrete da Secrets Manager<\/a><\/noindex> o Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Storage e Logging<\/strong> \u2014 qui configureremo il logging in CloudWatch Logs (servizio di log di AWS). \u00c8 sufficiente attivare l'opzione Auto-configure CloudWatch Logs. Dopo la creazione della Task Definition, verr\u00e0 automaticamente creata un gruppo log in CloudWatch. Per impostazione predefinita, i log in esso vengono conservati indefinitamente; consiglio di modificare il periodo di retention da Never Expire al periodo richiesto. Questo pu\u00f2 essere fatto in CloudWatch Log groups, cliccando sul periodo attuale e selezionando uno nuovo.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
ECS Cluster e ECS Capacity Provider<\/h3>\n
<\/p>\n
Andiamo alla sezione ECS \u2192 Clusters per creare un cluster. Come modello scegliamo EC2 Linux + Networking.<\/p>\n
<\/p>\n
Nome del cluster<\/strong> \u2014 \u00e8 molto importante, utilizziamo qui lo stesso nome indicato nel Launch Template nel parametro ECS_CLUSTER<\/code>, nel nostro caso \u2014 DemoApiClusterProd<\/code>. Spuntiamo la casella Crea un cluster vuoto. Opzionalmente, puoi abilitare Container Insights per visualizzare le metriche dei servizi in CloudWatch. Se hai fatto tutto correttamente, nella sezione ECS Instances vedrai le macchine create nel gruppo di Auto Scaling.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Andiamo alla scheda Capacity Providers<\/strong> e creiamo uno nuovo. Ricordo che \u00e8 necessario per gestire la creazione e lo spegnimento delle macchine in base al numero di task ECS attivi. \u00c8 importante notare che il provider pu\u00f2 essere associato a un solo gruppo.<\/p>\n
<\/p>\n
Auto Scaling group<\/strong> \u2014 selezioniamo il gruppo creato in precedenza.<\/p>\n
<\/p>\n
Scaling gestito<\/strong> \u2014 abilitiamo per consentire al provider di scalare il servizio.<\/p>\n
<\/p>\n
Capacit\u00e0 target %<\/strong> \u2014 quale percentuale di carico delle macchine \u00e8 necessaria per i task. Se si specifica il 100%, tutte le macchine saranno sempre occupate con task in esecuzione. Se si specifica il 50%, met\u00e0 delle macchine saranno sempre libere. In questo caso, se si verifica un'improvvisa impennata del carico, i nuovi task andranno immediatamente sulle macchine disponibili, senza dover attendere il deploy di nuove istanze.<\/p>\n
<\/p>\n
Protezione dalle terminazioni gestita<\/strong> \u2014 se attivato, questo parametro consente al provider di rimuovere la protezione delle istanze dalla cancellazione. Questo accade quando non ci sono task attivi sulla macchina e consente la Target capacity %.<\/p>\n
<\/p>\n
Servizio ECS e configurazione della scalabilit\u00e0<\/h3>\n
<\/p>\n
Ultimo passo :) Per creare un servizio, \u00e8 necessario accedere al cluster creato in precedenza nella scheda Servizi.<\/p>\n
<\/p>\n
Tipo di avvio<\/strong> \u2014 bisogna cliccare su Switch to capacity provider strategy e selezionare il provider creato in precedenza.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Definizione del task<\/strong> \u2014 selezioniamo la Definizione del Task creata in precedenza e la sua revisione.<\/p>\n
<\/p>\n
Nome del servizio<\/strong> \u2014 per non confondersi, indichiamo sempre lo stesso nome della Definizione del Task.<\/p>\n
<\/p>\n
Tipo di servizio<\/strong> \u2014 sempre Replica.<\/p>\n
<\/p>\n
Numero di task<\/strong> \u2014 numero desiderato di task attivi nel servizio. Questo parametro \u00e8 gestito dalla scalabilit\u00e0, ma deve comunque essere specificato.<\/p>\n
<\/p>\n
Percentuale minima di salute<\/strong> e Percentuale massima<\/strong> \u2014 definiscono il comportamento delle attivit\u00e0 durante il deployment. I valori predefiniti 100 e 200 indicano che al momento del deployment il numero delle attivit\u00e0 aumenter\u00e0 di fattore, per poi tornare al valore desiderato. Se hai 1 attivit\u00e0 in esecuzione, min=0 e max=100, allora durante il deployment sar\u00e0 terminata e dopo verr\u00e0 avviata una nuova attivit\u00e0, il che comporter\u00e0 un'interruzione. Se hai 1 attivit\u00e0 in funzionamento, min=50 e max=150, il deployment non avverr\u00e0 affatto, perch\u00e9 non si pu\u00f2 dividere 1 attivit\u00e0 a met\u00e0 o aumentarla di un fattore e mezzo.<\/p>\n
<\/p>\n
Tipo di deployment<\/strong> \u2014 lasciamo Rolling update.<\/p>\n
<\/p>\n
Template di posizionamento<\/strong> \u2014 regole per il posizionamento delle attivit\u00e0 sulle macchine. Per impostazione predefinita, \u00e8 impostato su AZ Balanced Spread, il che significa che ogni nuova attivit\u00e0 verr\u00e0 collocata su una nuova istanza fino a quando non sono in funzione macchine in tutte le zone di disponibilit\u00e0. Di solito facciamo BinPack \u2014 CPU e Spread \u2014 AZ, con questa politica, le attivit\u00e0 vengono collocate il pi\u00f9 strettamente possibile su una macchina in base alla CPU. Se \u00e8 necessario creare una nuova macchina, viene creata in una nuova zona di disponibilit\u00e0.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Tipo di bilanciatore di carico<\/strong> \u2014 scegliamo Application Load Balancer.<\/p>\n
<\/p>\n
Ruolo IAM del servizio<\/strong> \u2014 selezioniamo ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Nome del bilanciatore di carico<\/strong> \u2014 selezioniamo il bilanciatore creato in precedenza.<\/p>\n
<\/p>\n
Periodo di tolleranza per il controllo dello stato<\/strong> \u2014 pausa prima di eseguire i controlli di disponibilit\u00e0 dopo il rilascio di un nuovo task, di solito impostiamo 60 secondi.<\/p>\n
<\/p>\n
Contenitore per il bilanciamento del carico<\/strong> \u2014 nel campo Nome del gruppo di destinazione scegliamo il gruppo precedentemente creato, e tutto si riempir\u00e0 automaticamente.<\/p>\n
<\/p>\n
\"Creazione<\/p>\n
<\/p>\n
Auto Scaling del Servizio<\/strong> \u2014 parametri di scaling del servizio. Scegliamo Configura l'Auto Scaling del servizio per regolare il numero desiderato del tuo servizio. Impostiamo il numero minimo e massimo di task durante il scaling.<\/p>\n
<\/p>\n
Ruolo IAM per l'Auto Scaling del Servizio<\/strong> \u2014 selezioniamo AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Politiche di scaling automatico dei task<\/strong> \u2014 regole per il scaling. Ci sono 2 tipi:<\/p>\n
<\/p>\n
    \n
  1. Tracciamento degli obiettivi<\/strong> \u2014 monitoraggio della metrica target (utilizzo di CPU\/RAM o numero di richieste per ogni task). Ad esempio, vogliamo che il carico medio della CPU sia dell'85%, quando superer\u00e0 tale valore, nuovi task verranno aggiunti fino a che non si torner\u00e0 al valore target. Se il carico \u00e8 inferiore, i task verranno rimossi, a meno che non sia attivata la protezione dallo scaling verso il basso (Disabilita scaling in<\/strong>).<\/li>\n
  2. Scaling a passi<\/strong> \u2014 reazione a qualsiasi evento. Qui puoi configurare la reazione a un evento qualsiasi (CloudWatch Alarm); quando si verifica, puoi aggiungere o rimuovere il numero specificato di task, oppure indicare esattamente il numero di task.<\/li>\n<\/ol>\n
    <\/p>\n
    Il servizio pu\u00f2 avere diverse regole di scalabilit\u00e0, il che pu\u00f2 essere utile; \u00e8 importante assicurarsi che non conflittino tra loro.<\/p>\n
    <\/p>\n
    Conclusione<\/h2>\n
    <\/p>\n
    Se hai seguito le istruzioni e hai usato la stessa immagine Docker, il tuo servizio dovrebbe restituire questa pagina.<\/p>\n
    <\/p>\n
    \"Creazione<\/p>\n
    <\/p>\n
      \n
    1. Abbiamo creato un modello secondo il quale vengono avviate tutte le macchine nel servizio. Abbiamo anche imparato a aggiornare le macchine quando il modello cambia.<\/li>\n
    2. Abbiamo configurato la gestione del segnale di arresto dell'istanza spot; quindi, entro un minuto dalla ricezione, tutti i task in esecuzione vengono rimossi dalla macchina, in modo che nulla venga perso o interrotto.<\/li>\n
    3. Abbiamo attivato un bilanciatore di carico per distribuire uniformemente il carico tra le macchine.<\/li>\n
    4. Abbiamo creato un servizio che funziona su istanze spot, il che riduce i costi delle macchine di circa tre volte.<\/li>\n
    5. Abbiamo impostato l'autoscaling in entrambe le direzioni per gestire l'aumento del carico, senza pagare per il tempo di inattivit\u00e0.<\/li>\n
    6. Utilizziamo il Capacity Provider affinch\u00e9 sia l'applicazione a gestire l'infrastruttura (le macchine), e non il contrario.<\/li>\n
    7. Siamo bravi.<\/li>\n<\/ol>\n
      <\/p>\n
      Se hai picchi di carico prevedibili, ad esempio a causa di una grande campagna email, puoi impostare lo scaling in base a un programma.<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Inoltre, puoi effettuare lo scaling basandoti su dati provenienti da diverse parti del tuo sistema. Ad esempio, abbiamo la funzionalit\u00e0 di invio di promozioni personalizzate<\/a><\/noindex> agli utenti dell'app mobile. A volte la campagna viene inviata a oltre 1 milione di persone. Dopo un invio del genere, si osserva sempre un grande aumento delle richieste all'API, poich\u00e9 molti utenti accedono all'app simultaneamente. Quindi, se vediamo che nella coda per l'invio delle notifiche promozionali ci sono significativamente pi\u00f9 richieste rispetto ai parametri standard, possiamo immediatamente attivare alcune macchine e task aggiuntivi per essere pronti al carico.<\/p>\n
      <\/p>\n
      Sarei felice se nei commenti condivideste casi interessanti d'uso delle istanze spot e ECS, oppure qualcosa riguardo allo scaling.<\/p>\n
      <\/p>\n
      Presto pubblicheremo articoli su come gestiamo migliaia di eventi analitici al secondo su un stack principalmente serverless (con budget) e su come realizziamo il deployment dei servizi utilizzando GitLab CI e Terraform Cloud.<\/p>\n
      <\/p>\n
      Iscrivetevi a noi, sar\u00e0 interessante!<\/p>\n
      Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n
      Usate le istanze spot in produzione?<\/h2>\n