{"id":4787,"date":"2022-08-12T15:21:06","date_gmt":"2022-08-12T13:21:06","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=4787"},"modified":"2022-08-19T11:05:18","modified_gmt":"2022-08-19T09:05:18","slug":"load-balancing-like-a-pro-configurazioni-avanzate-di-aws-elastic-load-balancer-elb","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/load-balancing-like-a-pro-configurazioni-avanzate-di-aws-elastic-load-balancer-elb\/","title":{"rendered":"Load Balancing like a pro: configurazioni avanzate di AWS Elastic Load Balancer (ELB)"},"content":{"rendered":"\n

Una vecchia pubblicit\u00e0 recitava: “Two is megl che one”.<\/p>\n\n\n\n

Soprattutto quando, come diciamo sempre, “Tutto pu\u00f2 fallire, in qualsiasi momento”. Per rendere il business resiliente ai fallimenti, \u00e8 necessario fare in modo che applicazioni ed infrastrutture siano fault tolerant, ad esempio utilizzando pi\u00f9 istanze applicative.<\/p>\n\n\n\n

Il Load balancing<\/strong> \u00e8 un componente fondamentale che pu\u00f2 permetterci di avere migliori uptime e rendere le applicazioni sempre disponibili: ridistribuire il traffico su istanze differenti in auto scaling (e controllandone il funzionamento corretto) non \u00e8 cos\u00ec semplice come sembra. <\/p>\n\n\n\n

Nel mio passato da system administrator ho sempre avuto difficolt\u00e0 nel trovare una soluzione ridondante, resiliente e scalabile. Solo dopo tanto lavoro ed automazioni sono riuscito a passare  notti di sonno tranquille ! <\/p>\n\n\n\n

Usando i servizi gestiti, come sempre, ci aiuta a ridurre la quantit\u00e0 di lavoro necessaria per raggiungere i nostri scopi. <\/p>\n\n\n\n

Quando si parla di load balaincing, AWS mette a disposizione servizi molto flessibili. Sotto al cappello “Elastic Load Balancing (ELB)” ci sono molte opzioni disponibili. <\/p>\n\n\n\n

In questo articolo vedremo in breve i concetti fondamentali legati ai load balancer e andremo ad analizzare alcuni casi d’uso non molto comuni.<\/p>\n\n\n\n

Concetti Base<\/h2>\n\n\n\n

AWS mette a disposizione tre differenti tipologie di load balancer: Application, Network<\/strong> e Gateway. <\/strong><\/p>\n\n\n\n

In questo articolo ci focalizzeremo su Application Load Balancer <\/strong>e Network Load Balancer<\/strong>.  Non descriveremo invece il Classic Load balancer perch\u00e9 si tratta di un mix di application e network con qualche feature mancante (potete trovare qui la tabella comparativa<\/a>). Al Gateway load balancer, invece, dedicheremo prestoun articolo dedicato. <\/p>\n\n\n\n

Ogni tipo di ELB pu\u00f2 estendersi in pi\u00f9 Availability Zones e le sue componenti fondamentali sono tre: listener<\/strong>, target group<\/strong> ed health checks<\/strong>.<\/p>\n\n\n\n

Gli ELB possono essere pubblici (internet facing) o privati (accessibilisolo dalle risorse interne private).<\/p>\n\n\n\n

Un listener<\/strong> \u00e8 una piccola porzione della configurazione dell’ELB che definisce il punto di ingresso del traffico. Se la nostra applicazione deve essere disponibile usando il protocollo HTTP sulla porta 8080 allora la configurazione del listener sar\u00e0 sulla stessa porta e protocollo. <\/p>\n\n\n\n

Un target group<\/strong> \u00e8 l’insieme delle risorse computazionali che possono ricevere il traffico distribuito dal load balancer. <\/p>\n\n\n\n

Pu\u00f2 essere composto da istanze EC2, container ECS, indirizzi IP, funzioni lambda ed anche un altro application load balancer.<\/p>\n\n\n\n

N.B:  non tutti i tipi di ELB possono usare tutti i target group. Ad esempio, solo un Application Load Balancer pu\u00f2 avere funzioni lambda come target. 
Un health check<\/strong> \u00e8 il test eseguito dal target group per determinare lo stato di salute dell’istanza. Quelle non funzionanti sono automaticamente escluse e non ricevono traffico Ad esempio se la nostra applicazione riceve traffico TCP sulla porta 31337, l’health check verifica che il servizio sia disponibile su quella porta.<\/p>\n\n\n\n

Application Load Balancer<\/h2>\n\n\n\n

L’application Load Balancer (ALB) opera al livello 7 ISO\/OSI, da qui il nome. <\/p>\n\n\n\n

\u00c8 il tipo di load balancer pi\u00f9 utilizzato perch\u00e9 \u00e8 in grado di bilanciare traffico HTTP ed HTTPS, ed \u00e8 in grado di fare redirezioni<\/strong>, autenticazione<\/strong> e offloading SSL <\/strong>utilizzati certificati rilasciati da Amazon Certificate Manager (ACM). <\/p>\n\n\n\n

Network Load Balancer<\/h2>\n\n\n\n

Il Network Load Balancer (NLB) opera al livello 4 dello stack ISO\/OSI (network). Pu\u00f2 gestire tutto il traffico basato su TCP o UDP senza una specializzazione specifica per alcun protocollo. Supporta anche l’offload TLS e offre IP statici (sia per load balancer interni che esterni). <\/p>\n\n\n\n

Gateway Load Balancer<\/h2>\n\n\n\n

Il Gateway Load Balancer \u00e8 l’ultimo aggiunto alla famiglia di servizi ELB. \u00c8 in grado di gestire il traffico a livello 3 usando il protocollo GENEVE per incapsulare il i pacchetti. Questo rende possibile l’utilizzo di appliance per la sicurezza ed il networking custom o fornite da terze parti. <\/p>\n\n\n\n

Per implementare una soluzione IDS custom in alta affidabilit\u00e0 (quindi usando diverse Availability Zones) \u00e8 necessario usare un Gateway Load Balancer, che si occuper\u00e0 proprio di distribuire il traffico IP, senza dover specificare porta o protocollo<\/p>\n\n\n\n

Dopo questo breve cappello introduttivo non ci resta che tuffarci nell’argomento analizzando qualche configurazione non proprio comune per il setup avanzato dei load balancer su AWS.<\/p>\n\n\n\n

Usare un ALB per mettere in sicurezza WordPress<\/h2>\n\n\n\n

Portare le applicazioni in Cloud facendone il refactoring o adattandole non \u00e8 sempre una strada percorribile quando il tempo stringe. <\/p>\n\n\n\n

WordPress \u00e8 un esempio comune di applicazione che non \u00e8 semplice migrare (se il tempo non \u00e8 un problema tenete presente la possibilit\u00e0 di usare container<\/a>.<\/p>\n\n\n\n

Per migrare un sito WordPress \u00e8 necessario mantenere lo stesso nome DNS e la connessione in HTTPS. Una soluzione \u201cquick and dirty\u201d potrebbe essere usare una istanza Amazon EC2 pubblica; esporre per\u00f2 una installazione WordPress senza usare un WAF pu\u00f2 essere un rischio per la sicurezza. <\/p>\n\n\n\n

Mettere un Application Load Balancer di fronte all’istanza WordPress aiuta ad aumentare la sicurezza e ridurre il lavoro necessario alla manutenzione, anche se non si tratta di un bilanciamento di traffico vero e proprio. Infatti: <\/p>\n\n\n\n