🥇 Bilanciamento del carico con AWS ELB

Ciao a tutti! Il corso inizia già oggi «AWS per sviluppatori», pertanto abbiamo tenuto un webinar tematico dedicato alla panoramica di ELB. Abbiamo esaminato i vari tipi di bilanciatori e creato alcune istanze EC2 con il bilanciatore. Abbiamo anche studiato altri esempi di utilizzo.

Ascoltando il webinar, sarete in grado di:

comprendere cos'è l'AWS Load Balancing;
conoscere i tipi di Elastic Load Balancer e i suoi componenti;
utilizzare AWS ELB nella vostra pratica.

Perché è importante saperlo:

è utile se prevedete di sostenere 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 Rishat Teregulov, ingegnere di sistema in una società di marketing per lo sviluppo e la manutenzione di siti web.

Introduzione

Cosa sia Elastic Load Balancer, è possibile vederlo nel diagramma sottostante, dove è presentato il più semplice esempio:

Il Load Balancer riceve le richieste e le distribuisce tra le istanze. Abbiamo un'istanza separata, ci sono funzioni Lambda e c'è un gruppo di AutoScaling (un gruppo di server).

Tipi di AWS ELB

1. Consideriamo i principali tipi:

Classic Load Balancer. Il primo bilanciatore di AWS, funziona sia al livello 4 che al livello 7 dell'OSI, supporta HTTP, HTTPS, TCP e SSL. Fornisce una bilanciatura di carico di base tra più istanze Amazon EC2 e opera sia a livello di richiesta che a livello di connessione. Apriamolo (evidenziato in grigio):

Questo bilanciatore è considerato obsoleto, quindi è raccomandato per un uso solo in casi specifici. Ad esempio, per applicazioni che sono state 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, opera al livello 4 dell'OSI (può essere utilizzato in EKS e ECS), supporta TCP, UDP e TLS.

Il Network Load Balancer instrada il traffico verso le risorse target 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. Opera al livello 7, supporta Lambda, gestisce regole a livello di intestazione e percorso, supporta HTTP e HTTPS.
Fornisce un routing avanzato delle richieste, orientato alla consegna di applicazioni basate su architetture moderne, inclusi microservizi e container. Dirige il traffico verso gli obiettivi in Amazon VPC, basandosi sul contenuto della richiesta.

Per molti utenti, l'Application Load Balancer ha prima di tutto sostituito il Classic Load Balancer, poiché l'TCP non è così diffuso rispetto all'HTTP.

Creiamone uno anche noi, così da avere già due bilanciatori di carico:

Componenti del Load Balance

Componenti generali del Load Balance (caratteristici di tutti i bilanciatori):

Access Logging Policy

— i vostri registri di accesso all'ELB. Per configurare le impostazioni, potete andare su Description e selezionare il pulsante «Edit attributes»:

Poi specifichiamo S3Bucket — il servizio di storage di oggetti di Amazon:

Scheme

— bilanciatore interno o esterno. Il significato è se il vostro LoadBalancer deve ricevere indirizzi esterni per essere accessibile dall'esterno, o se può essere il vostro bilanciatore interno;

Gruppi di Sicurezza

— controllo accessi al bilanciatore. Essenzialmente, è un firewall di alto livello.

Sottoreti

— sottoreti all'interno della vostra VPC (di conseguenza, le zone di disponibilità). Le sottoreti sono specificate durante la creazione. Se la VPC è limitata alla regione, le sottoreti sono limitate dalle zone di disponibilità. Quando create un Load Balancer, è meglio crearne uno in almeno due sottoreti (aiuta nel caso insorgano problemi con una zona di disponibilità);

Listeners

— i vostri protocolli del bilanciatore. 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 Classic Load Balancer:

In Application Load Balancer vediamo un'interfaccia un po' diversa e, in generale, una logica distinta:

Componenti del Load Balancer v2 (ALB e NLB)

Ora esaminiamo più nel dettaglio i bilanciatori di seconda versione Application Load Balancer e Network Load Balancer. Questi bilanciatori presentano le proprie caratteristiche componentali. Ad esempio, è emerso il concetto di Target Groups — istanze (e funzioni). Grazie a questo componente, abbiamo ora la possibilità di specificare a quale delle Target Groups vogliamo dirigere il traffico.

In termini semplici, nei Target Groups indichiamo le istanze dove arriverà il traffico. Se nel Classic Load Balancer collegate semplicemente le istanze al bilanciatore, nell'Application Load Balancer prima:

create un Load Balancer;
create un gruppo Target;
dirigi verso i gruppi Target necessari tramite le porte o le regole del Load Balancer;
nella group Target assegni le istanze.

Questa logica di funzionamento può sembrare più complessa, ma in realtà è più comoda.

Il componente successivo — Regole del listener (regole per la routazione). Questo riguarda solo l'Application Load Balancer. Se nel Network Load Balancer crei semplicemente un Listener e Questo invia il traffico a un gruppo Target specifico, nel Application Load Balancer tutto è più divertente e comodo..

Ora diciamo qualche parola sul componente successivo — Elastic IP (indirizzi statici per NLB). Se le regole per la routazione delle listener riguardano 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 la possibilità di scegliere un Elastic IP:

L'Elastic IP fornisce un singolo indirizzo IP che può essere associato a diverse istanze EC2 nel tempo. Se un'istanza EC2 ha un indirizzo Elastic IP e quest'istanza viene terminata o fermata, è possibile immediatamente associare una nuova istanza EC2 a quell'indirizzo Elastic IP. In questo modo, l'applicazione attuale non smetterà di funzionare, poiché le applicazioni vedono sempre lo stesso indirizzo IP, anche se la vera EC2 è cambiata.

Ecco un altro caso d'uso su perché è necessario l'Elastic IP. Guardate, vediamo 3 indirizzi IP, ma non rimarranno qui per sempre:

Amazon li cambia nel tempo, può farlo ogni 60 secondi (ma in pratica, ovviamente, meno frequentemente). Questo significa che gli indirizzi IP potrebbero cambiare. E nel caso del Network Load Balancer puoi proprio associare l'indirizzo IP e indicarlo nelle tue regole, politiche, ecc.

Tiriamo delle conclusioni

ELB garantisce la distribuzione automatica del traffico in ingresso su più obiettivi (contenitori, istanze Amazon EC2, indirizzi IP e funzioni Lambda). ELB è in grado di distribuire il traffico con carico variabile 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à, scalabilità automatica e una buona protezione. Tutto ciò è importante per garantire la resilienza delle tue applicazioni.

Principali vantaggi:

alta disponibilità. Nel contratto di assistenza si prevede una disponibilità del 99,99% per il bilanciatore di carico. Ad esempio, più zone di disponibilità garantiscono che il traffico venga trattato solo da oggetti funzionanti. In effetti, è possibile bilanciare il carico su tutta la regione, deviando il traffico verso obiettivi funzionanti in diverse zone di disponibilità;
sicurezza. ELB funziona con Amazon VPC, offrendo diverse possibilità per garantire la sicurezza: si tratta di gestione centralizzata dei certificati, autenticazione degli utenti e decrittazione SSL/TLS. Tutto ciò insieme offre una gestione centralizzata e flessibile delle impostazioni TLS;
elasticità. ELB può gestire variazioni improvvise nel traffico di rete. E la profonda integrazione con Auto Scaling fornisce all'applicazione le risorse necessarie quando il carico cambia, senza richiedere intervento manuale;
flessibilità. È possibile utilizzare indirizzi IP per instradare le richieste agli obiettivi delle vostre applicazioni. Ciò garantisce flessibilità nella virtualizzazione delle applicazioni target, consentendo così l'hosting di più applicazioni su un'unica istanza. Poiché le applicazioni possono utilizzare una sola porta di rete e hanno gruppi di sicurezza separati, si semplifica l'interazione tra le applicazioni, specialmente in un'architettura basata su microservizi;
monitoraggio e audit. È possibile monitorare le applicazioni in tempo reale utilizzando le funzionalità di Amazon CloudWatch. Si tratta di metriche, registri, tracciamento delle richieste. In parole semplici, sarete in grado di identificare problemi e di determinare con precisione i colli di bottiglia delle 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 con l'uso del cloud diventa più semplice.

Se sei interessato ai dettagli, ecco un paio di link utili dal sito ufficiale di Amazon:

Fonte: habr.com