Ciao a tutti! Oggi inizia il corso , per cui abbiamo tenuto un webinar a tema dedicato alla panoramica di ELB. Abbiamo esaminato i vari tipi di bilanciatori e creato diverse istanze EC2 con un bilanciatore. Inoltre, abbiamo studiato altri casi d'uso.

, imparerete a:
- comprendere cosa sia il bilanciamento del carico AWS;
- conoscere i tipi di Elastic Load Balancer e i suoi componenti;
- utilizzare AWS ELB nella vostra pratica.
Perché è importante saperlo:
- è utile se intendete sostenere gli esami di certificazione AWS;
- è un modo semplice per distribuire il carico tra i server;
- è un modo semplice per aggiungere Lambda al vostro servizio (ALB).
La lezione aperta è stata condotta da , ingegnere di sistema in un'azienda di marketing per lo sviluppo e il supporto di siti web.
Introduzione
Cosa sia l'Elastic Load Balancer può essere visto nel diagramma qui sotto, che presenta un esempio base:

Il Load Balancer riceve le richieste e le distribuisce tra le istanze. Abbiamo un'istanza separata, funzioni Lambda e un gruppo di AutoScaling (gruppo di server).
Tipi di AWS ELB
1. Consideriamo i principali tipi:
Classic Load Balancer. Il primo bilanciatore di carico di AWS, funziona sia al livello 4 che al livello 7 del modello OSI, supporta HTTP, HTTPS, TCP e SSL. Garantisce un bilanciamento del carico di base tra più istanze di Amazon EC2 e opera sia a livello di richieste che a livello di connessione. Apriamolo (evidenziato in grigio):

Questo bilanciatore è considerato obsoleto, quindi è consigliato usarlo solo in casi specifici. Ad esempio, per applicazioni costruite nella rete EC2-Classic. In linea di principio, non c'è nulla che ci impedisca di crearlo:

2. Network Load Balancer. Adatto per carichi elevati, funziona al livello 4 del modello OSI (può essere utilizzato in EKS e ECS), supporta TCP, UDP e TLS.
Il Network Load Balancer indirizza il traffico agli oggetti di destinazione in Amazon VPC ed è in grado di gestire milioni di richieste al secondo con latenze ultra basse. Inoltre, è ottimizzato per gestire modelli di traffico con carichi improvvisi e variabili.
3. Application Load Balancer. Funziona al livello 7, ha supporto per Lambda, supporta regole a livello di intestazioni e percorsi, supporta HTTP e HTTPS.
Fornisce un routing avanzato delle richieste, orientato alla consegna di applicazioni costruite su architetture moderne, inclusi microservizi e container. Dirige il traffico verso le risorse target in Amazon VPC, basandosi sul contenuto della richiesta.
Per molti utenti, l'Application Load Balancer ha subito sostituito il Classic Load Balancer, poiché il TCP non è così comune rispetto all'HTTP.
Creiamo anche questo, ottenendo così due bilanciatori di carico:

Componenti del Load Balancer
Componenti generali del Load Balancer (comuni a tutti i bilanciatori di carico):
- Policy di Access Logging
— i tuoi log di accesso a ELB. Per configurare, puoi andare su Description e selezionare il pulsante «Modifica attributi»:

Poi indichiamo S3Bucket — lo storage object di Amazon:

- Schema
— bilanciatore interno o esterno. La questione è se il tuo Load Balancer debba ricevere indirizzi esterni per essere accessibile dall'esterno, oppure se possa essere un bilanciatore interno;
- Gruppi di Sicurezza
— controllo accessi al bilanciatore. Fondamentalmente è un firewall di alto livello.


- Sottoreti
— subnet all'interno della tua VPC (e, di conseguenza, anche zone di disponibilità). Le subnet vengono specificate al momento della creazione. Se la VPC è limitata a una regione, le subnet sono limitate alle zone di disponibilità. Quando crei un Load Balancer, è consigliabile crearlo in almeno due subnet (aiuta in caso di problemi con una delle zone di disponibilità);
- Listeners
— i vostri protocolli del bilanciatore di carico. Come già detto in precedenza, per il Classic Load Balancer possono essere HTTP, HTTPS, TCP e SSL, per il Network Load Balancer — TCP, UDP e TLS, per l'Application Load Balancer — HTTP e HTTPS.
Esempio per il Classic Load Balancer:

E qui nell'Application Load Balancer vediamo un'interfaccia leggermente diversa e, in generale, una logica differente:

Componenti del Load Balancer v2 (ALB e NLB)
Ora esaminiamo più da vicino i bilanciatori di carico di seconda generazione Application Load Balancer e Network Load Balancer. Questi bilanciatori hanno le loro peculiarità componenti. Ad esempio, è emerso il concetto di Target Groups — istanze (e funzioni). Grazie a questo componente, abbiamo la possibilità di specificare su quale delle Target Groups vogliamo dirigere il traffico.


Parlando in termini semplici, nei Target Groups indichiamo le istanze a cui verrà inviato il traffico. Se nel Classic Load Balancer colleghi direttamente le istanze al bilanciatore, nell'Application Load Balancer fai prima:
- crei il Load Balancer;
- crei il Target group;
- dirigi il traffico sui porti o secondo le regole del Load Balancer verso i Target Groups desiderati;
- nelle Target groups assegni le istanze.
Questa logica di lavoro può sembrare più complessa, ma in realtà è più comoda.
Il componente successivo è— Listener rules (regole per il routing). Questo riguarda solo l'Application Load Balancer. Se nel Network Load Balancer crei semplicemente un Listener, che invia il traffico a un Target group specifico, nell'Application Load Balancer tutto .

Ora diciamo un paio di parole sul componente successivo— Elastic IP (indirizzi statici per NLB). Se le regole per il routing delle Listener rules riguardavano solo l'Application Load Balancer, l'Elastic IP riguarda solo il Network Load Balancer.
Creiamo un Network Load Balancer:


E proprio durante il processo di creazione vedremo che ci viene data l'opportunità di scegliere l'Elastic IP:

L'IP elastico fornisce un unico indirizzo IP che può essere associato a diversi istanze EC2 nel tempo. Se un'istanza EC2 ha un indirizzo IP elastico e questa istanza viene terminata o fermata, è possibile associare immediatamente una nuova istanza EC2 all'indirizzo IP elastico. In questo modo, la tua attuale applicazione non smetterà di funzionare, poiché le applicazioni vedono sempre lo stesso indirizzo IP, anche se l'EC2 reale è cambiato.
Ecco relativo a perché sia necessario un IP elastico. Vedi, abbiamo 3 indirizzi IP, ma non rimarranno qui per sempre:

Amazon li cambia nel tempo, può farlo ogni 60 secondi (ma in pratica, ovviamente, più raramente). Ciò significa che gli indirizzi IP possono cambiare. E nel caso del Network Load Balancer, puoi proprio associare l'IP e specificarlo nelle tue regole, politiche, ecc.

Facciamo delle conclusioni
ELB offre un'assegnazione automatica del traffico in ingresso a più destinazioni (contenitori, istanze Amazon EC2, indirizzi IP e funzioni Lambda). ELB è in grado di distribuire il traffico con carichi variabili sia all'interno di una singola zona di disponibilità che tra più zone di disponibilità. L'utente può scegliere tra tre tipi di bilanciatori che garantiscono alta disponibilità, autoscaling e una protezione adeguata. Tutto questo è fondamentale per garantire la resilienza delle vostre applicazioni.
Principali vantaggi:
- alta disponibilità. L'accordo di servizio prevede una disponibilità del 99,99% per il bilanciatore di carico. Ad esempio, avere più zone di disponibilità garantisce che il traffico venga elaborato solo da oggetti funzionanti. Infatti, è possibile bilanciare il carico anche in tutto il regionale, reindirizzando il traffico verso oggetti di destinazione funzionanti in diverse zone di disponibilità;
- sicurezza. ELB funziona con Amazon VPC, offrendo diverse possibilità di sicurezza: gestione integrata dei certificati, autentificazione degli utenti e decrittazione SSL/TLS. Insieme, tutto ciò consente una gestione centralizzata e flessibile delle impostazioni TLS.
- elasticità. ELB può gestire cambiamenti improvvisi nel traffico di rete. La profonda integrazione con Auto Scaling fornisce sufficienti risorse all'app, qualora ci siano variazioni nel carico, senza richiedere intervento manuale.
- flessibilità. È possibile utilizzare indirizzi IP per instradare le richieste verso gli obiettivi delle vostre applicazioni. Questo garantisce flessibilità nella virtualizzazione delle applicazioni target, consentendo di ospitare più applicazioni su un solo istanza. Poiché le applicazioni possono utilizzare una sola porta di rete e dispongono di gruppi di sicurezza separati, si semplifica l'interazione tra le applicazioni in un'architettura basata, ad esempio, sui microservizi.
- monitoraggio e audit. È possibile monitorare le applicazioni in tempo reale utilizzando le funzionalità di Amazon CloudWatch. Questo include metriche, registri e monitoraggio delle richieste. In parole semplici, sarai in grado di identificare i problemi e determinare con precisione i colli di bottiglia nelle prestazioni;
- bilanciamento del carico ibrido. La possibilità di bilanciare il carico tra risorse locali e AWS utilizzando lo stesso bilanciatore semplifica la migrazione o l'espansione delle applicazioni locali nel cloud. Anche la gestione dei guasti diventa più facile con l'uso del cloud.
Se sei interessato a maggiori dettagli, ecco un paio di link utili dal sito ufficiale di Amazon:
- .
Fonte: habr.com
