Target group e health check

Un target group è una raccolta logica di destinazioni verso cui il load balancer instrada le richieste. Ogni target group ha un tipo di destinazione, un protocollo/porta e una configurazione dei controlli dello stato. Il load balancer distribuisce le richieste alle destinazioni registrate nel target group che superano i controlli dello stato.

I target group sono associati ai listener del load balancer tramite regole del listener. Un listener può instradare il traffico verso più target group in base agli attributi della richiesta. Questo è il meccanismo alla base del routing basato sul percorso e sull'host in ALB.

I target group supportano tre tipi di destinazione:

• instance: esegue il routing verso istanze EC2 tramite l'ID dell'istanza; il load balancer invia il traffico all'interfaccia di rete primaria dell'istanza sulla porta specificata
• ip: esegue il routing verso indirizzi IP privati, utile per destinazioni in container (ECS/EKS), server on-premises raggiungibili tramite VPN/Direct Connect o IP secondari di istanze EC2
• lambda: esegue il routing verso una singola funzione Lambda (solo ALB); ALB converte la richiesta HTTP in un evento JSON e richiama la funzione in modo sincrono

Il tipo di destinazione IP è obbligatorio per i task ECS con la modalità di rete awsvpc (ogni task riceve il proprio IP), per i pod EKS e per le architetture ibride con destinazioni on-premises.

È possibile registrare i target in un target group manualmente (nella console o tramite CLI) oppure automaticamente (tramite l'associazione a un Auto Scaling Group o la configurazione di un servizio ECS). I target registrati manualmente rimangono nel gruppo finché non vengono deregistrati esplicitamente.

Per gli ASG, si associa l'ASG a un target group e l'ASG registra automaticamente le istanze appena avviate e deregistra quelle terminate. Questa stretta integrazione con l'ASG è il pattern standard per i livelli di elaborazione elastici: le nuove istanze diventano operative e iniziano a ricevere traffico non appena superano il controllo dello stato.

Ogni target group è associato a un controllo dello stato che il load balancer utilizza per determinare se un target è integro e idoneo a ricevere traffico. Il controllo dello stato invia richieste periodiche a ogni target e ne valuta la risposta:

• Protocollo: HTTP, HTTPS o TCP (per NLB)
• Percorso: il percorso URL da richiedere (ad esempio /health o /ping)
• Porta: la porta da controllare (per impostazione predefinita, la porta del target group)
• Soglia di stato integro: numero di successi consecutivi prima di considerare il target integro
• Soglia di stato non integro: numero di errori consecutivi prima di considerare il target non integro
• Intervallo: secondi tra un controllo dello stato e l'altro (5–300)
• Timeout: secondi di attesa per una risposta

Per i controlli dello stato HTTP/HTTPS, si specificano i codici di risposta HTTP che indicano che un target è integro. Il valore predefinito è 200, ma è possibile configurare intervalli come 200-299 o valori separati da virgole come 200,301,302.

Best practice: creare nell'applicazione un endpoint /health dedicato che restituisca 200 solo quando tutte le dipendenze critiche sono disponibili (connettività al database, cache e servizio downstream). Non utilizzare l'URL root (/) come percorso del controllo dello stato se esegue operazioni costose o richiede l'autenticazione.

Dopo la registrazione, un target attraversa i seguenti stati:

• initial: ELB sta eseguendo i primi controlli dello stato
• healthy: ha superato il numero richiesto di controlli dello stato consecutivi; riceve traffico
• unhealthy: non ha superato il numero richiesto di controlli dello stato consecutivi; viene rimosso dalla rotazione
• draining: la deregistrazione è in corso; le connessioni esistenti possono terminare, ma non vengono inviate nuove connessioni
• unused: è registrato nel gruppo, ma nessuna regola del listener instrada attualmente il traffico verso questo gruppo

Monitorare le metriche CloudWatch UnHealthyHostCount e HealthyHostCount per rilevare problemi nel parco di target.

Il ritardo di deregistrazione (precedentemente chiamato connection draining) è il tempo che ELB attende affinché le connessioni esistenti vengano completate prima di deregistrare definitivamente un target. Il valore predefinito è di 300 secondi (5 minuti). Durante questo periodo, al target in fase di deregistrazione non vengono inviate nuove richieste, ma le richieste in corso possono terminare.

Per deployment rapidi e terminazioni dovute all'auto scaling, può essere opportuno ridurre questo valore a 30–60 secondi se l'applicazione gestisce rapidamente le richieste. Per operazioni di lunga durata (caricamento di file, elaborazione video), è consigliabile mantenerlo abbastanza elevato da consentire il completamento di tali operazioni senza interruzioni.

I target group supportano diversi algoritmi di load balancing:

• Round robin (predefinito per ALB): distribuisce le richieste uniformemente a rotazione; è la scelta migliore quando tutti i target sono equivalenti
• Least outstanding requests (ALB): invia ogni nuova richiesta al target con il minor numero di richieste in corso; è più adatto ai carichi di lavoro di durata variabile, in cui alcune richieste richiedono più tempo di altre
• Flow hash (NLB): distribuisce in base a protocollo, IP di origine/destinazione, porta di origine/destinazione e numero di sequenza TCP; garantisce che tutti i pacchetti di un flusso TCP/UDP vengano inviati allo stesso target

Per le applicazioni basate su sessione, in cui tutte le richieste di un utente devono raggiungere lo stesso target, abilitare le sticky session invece di affidarsi alla distribuzione round robin.

Una singola regola del listener ALB può distribuire il traffico tra più target group utilizzando target group ponderati. Ad esempio, è possibile instradare il 90% del traffico verso un target group stabile e il 10% verso un target group canary per deployment blue-green, senza utilizzare il routing ponderato di Route 53.

I target group ponderati vengono configurati a livello di regola del listener. I pesi sono relativi: un rapporto 90/10 invia il 90% al primo gruppo e il 10% al secondo. Questo è diverso dal routing ponderato tra più ALB: in questo caso il routing avviene all'interno di una singola regola del listener ALB.

Quando si esegue il deployment di servizi ECS dietro un ALB, ogni task ECS viene registrato nel target group dell'ALB utilizzando il tipo di target ip (per la modalità di rete awsvpc). Il servizio ECS gestisce automaticamente la registrazione e la deregistrazione: i nuovi task vengono registrati dopo aver superato i controlli dello stato, mentre per i task in arresto viene atteso il ritardo di deregistrazione prima della terminazione.

Ogni servizio ECS può essere registrato con un override della porta specifico, consentendo a più servizi ECS di condividere un singolo ALB tramite regole del listener diverse (basate sul percorso o sull'host) con target group differenti: un pattern comune nelle architetture a microservizi.

Il comportamento dei controlli dello stato NLB differisce da quello di ALB:

• NLB supporta i protocolli di controllo dello stato TCP, HTTP e HTTPS, indipendentemente dal protocollo del listener
• I controlli dello stato NLB vengono inviati dagli indirizzi IP dell'NLB in ogni AZ: assicurarsi che i security group consentano il traffico dagli IP delle subnet dell'NLB oppure utilizzare il security group dell'NLB stesso
• Per i controlli dello stato TCP, NLB considera integro un target se questo accetta una connessione TCP sulla porta specificata
• I target NLB che non superano i controlli dello stato vengono rimossi per AZ; se tutti i target di un'AZ non sono integri, NLB può distribuire il traffico tra zone verso target integri in altre AZ (se il load balancing tra zone è abilitato)

Verificate la vostra comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione avete appreso che i target group contengono target registrati e integri di tipo istanza, IP o Lambda, che i controlli dello stato verificano periodicamente i target per rimuovere dalla rotazione quelli non integri e che il ritardo di deregistrazione garantisce il completamento ordinato delle richieste in corso prima della rimozione del target. Nella prossima lezione esploreremo le regole dei listener e il routing basato sul percorso nell'ALB.