Ciao a tutti e bentornati.
Nel video di oggi parleremo dell'architettura del ridimensionamento basato sulle SKU di Amazon con una panoramica
di alto livello.
Ora, in molte organizzazioni, il numero di istanze EC due in esecuzione nell'ambiente di produzione
è direttamente correlato al numero di messaggi che fanno parte del salvataggio.
Ad esempio, supponiamo che ci siano dieci messaggi nella coda US e che ci siano due istanze
EC due in esecuzione. Ogni istanza EC due si occuperà di elaborare cinque messaggi e dopo l'elaborazione
caricherà gli artefatti sul bucket S3.
Supponiamo che domani ci sia una grande svendita e che negli Stati Uniti, invece di dieci messaggi,
ce ne siano 10.000.
Ora, dato che nella coda c'è un numero elevato di messaggi, ci sono due opzioni.
Il primo è che si hanno solo due istanze facili da gestire e l'elaborazione di 10.000 messaggi richiede molto
tempo.
Questa è la prima opzione.
La seconda opzione consiste nell'aumentare il numero di istanze di EC due in esecuzione nell'ambiente
di produzione, ad esempio da 2 a 20.
Quindi ora 20 è due istanze sono in esecuzione, 10.000 messaggi saranno elaborati in modo molto più rapido.
Tuttavia, aumentando il numero di istanze EC due aumenterà anche il costo.
Ora, al termine della vendita, il numero di messaggi in coda si è ridotto da 10.000 a
dieci.
Quindi, ora è necessario terminare l'EC extra.
Due istanze che stiamo eseguendo per ridurre il costo complessivo.
Ora, in un ambiente di produzione, si vuole implementare un'architettura di questo tipo, in cui le due
istanze EC vengono lanciate e terminate in base al numero di messaggi in coda.
E in effetti in molte organizzazioni si assiste all'implementazione di questo tipo di architettura.
Quindi, in una panoramica di alto livello, analizziamo rapidamente quali sono le cose da fare per ottenere
questo tipo di architettura.
Ora, se si utilizza un gruppo a scalare automatico, in questi casi è possibile configurare l'avvio o la chiusura
delle due istanze semplici in base al numero di messaggi che fanno parte del salvataggio.
Ora, questo può essere spiegato con questo diagramma in cui si ha un'applicazione che legge il
numero di messaggi che fanno parte della coda e memorizza i dati in cloud watch.
Ora, a seconda dei dati presenti nel cloud watch, l'autoscaling lancia un nuovo set di istanze oppure
termina il set aggiuntivo di istanze in esecuzione.
La domanda che sorge spontanea è: come fa questa specifica applicazione a sapere quanti messaggi ci sono nel salvataggio?
La risposta è una delle sei colonne di attributi, il numero approssimativo di messaggi.
Quindi andiamo avanti e analizziamo rapidamente la questione.
Ora, per la dimostrazione di oggi, ho un salvataggio e ci sono due messaggi disponibili.
Quindi, se apriamo il salvataggio, otteniamo l'URL della coda.
In base a questo URL, è possibile verificare il numero di messaggi presenti.
Quindi andiamo avanti e analizziamo rapidamente la questione.
Quindi ho un comando CLI che si chiama eight us get attributes, in cui si specifica l'URL della coda e si specifica il nome
dell'attributo e il nome dell'attributo è il numero approssimativo di messaggi.
Questo è molto simile a quello di cui stavamo discutendo e la regione è quella del Sud-Est.
Ora, se premo rapidamente invio, vedrete che il numero di messaggi visualizzati è due e questa è la stessa
cosa che l'applicazione può fare e può pubblicarla a un servizio centrale da cui l'autoscaling
avvierà e terminerà le istanze secondo le necessità.
Questo è uno dei progetti di architettura che possono essere implementati nel caso in cui si abbia un caso d'uso in cui
si voglia lanciare e terminare le istanze in base al numero di messaggi.
Con questo si conclude il video di oggi.