🥇 Lastbalansering med AWS ELB

Hej alla! Idag startar kursen «AWS för utvecklare», vilket innebär att vi har genomfört ett tematiskt webbinar, som handlar om en översikt av ELB. Vi gick igenom typerna av belastningsutjämnare och skapade flera EC2-instanser med en belastningsutjämnare. Vi studerade också andra exempel på användning.

Efter att ha lyssnat på webbinariet, kommer du att:

förstå vad AWS Load Balancing är;
känna till typer av Elastic Load Balancer och dess komponenter;
använda AWS ELB i din praktik.

Varför detta är viktigt:

det är användbart om du planerar att ta AWS certifieringsexaminer;
det är ett enkelt sätt att fördela belastningen mellan servrar;
det är ett enkelt sätt att lägga till Lambda i din tjänst (ALB).

Den öppna lektionen leddes av Rishat Teregulov, systemingenjör på ett marknadsföringsföretag som utvecklar och supportar webbplatser.

Introduktion

Vad är Elastic Load Balancer kan ses i diagrammet nedan, som visar ett enkelt exempel:

Belastningsutjämnaren tar emot begärningar och fördelar dem till instanser. Vi har en separat instans, Lambda-funktioner och en AutoScaling-grupp (en grupp servrar).

Typer av AWS ELB

1. Låt oss titta på de huvudsakliga typerna:

Classic Load Balancer. Den första belastningsutjämnaren från AWS, fungerar på både OSI lager 4 och 7, stöder HTTP, HTTPS, TCP och SSL. Den möjliggör grundläggande belastningsutjämning mellan flera Amazon EC2-instanser och fungerar både på begärnings- och anslutningsnivå. Låt oss öppna den (markerad i grått):

Denna balansutjämnare anses vara föråldrad, så det rekommenderas att använda den endast i särskilda fall. Till exempel för applikationer som byggts på nätverket EC2‑Classic. I princip finns det inget som hindrar oss från att skapa den:

2. Network Load Balancer. Lämplig för hög belastning, arbetar på OSI lager 4 (kan användas i EKS och ECS), stöder TCP, UDP och TLS.

Network Load Balancer dirigerar trafik till målobjekt i Amazon VPC och kan hantera miljontals begärningar per sekund med ultralåga fördröjningar. Dessutom är den optimerad för att hantera trafikmönster med plötslig och varierande belastning.

3. Application Load Balancer. Fungerar på lager 7, har stöd för Lambda, stöder regler på header- och sökvägnivå, stöder HTTP och HTTPS.
Ger tillgång till avancerad förfrågningsrouting som är inriktad på att leverera applikationer baserade på moderna arkitekturer, inklusive mikrotjänster och containrar. Styra trafik till målen i Amazon VPC baserat på innehållet i förfrågan.

För många användare har Application Load Balancer i första hand ersatt Classic Load Balancer, eftersom TCP inte är lika utbrett jämfört med HTTP.

Vi skapar också den, vilket ger oss två lastbalanserare:

Komponenter i Load Balance

Allmänna komponenter i Load Balance (gemensamma för alla lastbalanserare):

Access Logging Policy

— dina åtkomstloggar för ELB. För att utföra inställningarna kan du gå till Beskrivning och välja knappen "Redigera attribut":

Därefter anger vi S3Bucket — Amazon objektlagringslagring:

Scheme

— intern eller extern lastbalanserare. Det handlar om huruvida din LoadBalancer ska ta emot externa adresser för att vara tillgänglig utanför, eller om det kan vara din interna lastbalanserare;

Security Groups

— åtkomstkontroll till lastbalanseraren. I grund och botten är detta en brandvägg på hög nivå.

Subnets

— delnät inom din VPC (och därmed tillgänglighetszoner). Delnät anges vid skapandet. Om VPC är begränsad till regionen, är delnäten begränsade per tillgänglighetszon. När du skapar Load Balancer, är det bättre att skapa den i minst två delnät (hjälper om det skulle uppstå problem med en tillgänglighetszon);

Listeners

— dina protokoll för lastbalanseraren. Som nämnts tidigare kan det för Classic Load Balancer vara HTTP, HTTPS, TCP och SSL, för Network Load Balancer — TCP, UDP och TLS, för Application Load Balancer — HTTP och HTTPS.

Exempel för Classic Load Balancer:

Men i Application Load Balancer ser vi och en något annan gränssnitt och en helt annan logik:

Komponenter i Load Balancer v2 (ALB och NLB)

Nu ska vi titta närmare på lastbalanserare version 2, Application Load Balancer och Network Load Balancer. Dessa lastbalanserare har sina egna komponentfunktioner. Till exempel har det kommit ett begrepp som Target Groups — instanser (och funktioner). Tack vare denna komponent har vi nu möjlighet att ange vilken av Target Groups vi vill styra trafiken till.

Enkelt uttryckt anger vi i Target Groups instanserna som trafiken kommer att komma till. Medan du i Classic Load Balancer bara kopplar instanser direkt till lastbalanseraren, gör du i Application Load Balancer först:

skapar Load Balancer;
skapar Target-grupp;
styr efter nödvändiga portar eller regler Load Balancer till de nödvändiga Target Groups;
I Target-grupper tilldelar du instanser.

Denna arbetslogik kan verka mer komplex, men i själva verket är den mer bekväm.

Den nästa komponenten är Lyssnarrutiner (riktlinjer för routning). Det här gäller endast Application Load Balancer. Om du i Network Load Balancer bara skapar en lyssnare och den skickar trafik till en specifik Target-grupp, så är det i Application Load Balancer roligare och mer praktiskt.

Låt oss säga några ord om nästa komponent — Elastic IP (statisk adresser för NLB). Om riktlinjerna för lyssnarrutiner endast rörde sig om Application Load Balancer, så gäller Elastic IP endast Network Load Balancer.

Vi skapar en Network Load Balancer:

Och under skapandeprocessen kommer vi att se att vi får möjlighet att välja Elastic IP:

Elastic IP ger en enda IP-adress som kan kopplas till olika EC2-instanser över tid. Om en EC2-instans har en Elastic IP-adress och denna instans stoppas eller avslutas kan du omedelbart koppla en ny EC2-instans till Elastic IP-adressen. På så sätt avbryts inte din aktuella applikation, eftersom applikationerna ser samma IP-adress, även om den verkliga EC2-instansen har ändrats.

Här är en till användningsfall om varför Elastic IP behövs. Titta, vi ser 3 IP-adresser, men de kommer inte att stanna här för alltid:

Amazon ändrar dem över tid, kan göra det var 60:e sekund (men i praktiken är det förstås mer sällan). Det innebär att IP-adresserna kan ändras. I fallet med Network Load Balancer kan du just koppla IP-adressen och ange den i dina riktlinjer, policyer och så vidare.

Vi drar slutsatser

ELB erbjuder automatisk fördelning av inkommande trafik till flera målobjekt (containrar, Amazon EC2-instanser, IP-adresser och Lambda-funktioner). ELB kan fördela trafik med varierande belastning både inom en tillgänglighetszon och mellan flera tillgänglighetszoner. Användaren kan välja bland tre typer av belastningsbalanserare som erbjuder hög tillgänglighet, automatisk skalning och rimligt bra skydd. Allt detta är viktigt för att säkerställa motståndskraften hos dina applikationer.

Huvudsakliga fördelar:

hög tillgänglighet. I serviceavtalet garanteras 99,99 % tillgänglighet för lastbalanseraren. Till exempel garanterar flera tillgänglighetszoner att trafiken endast hanteras av fungerande objekt. I själva verket kan man balansera last över hela regionen och omdirigera trafiken till fungerande målobjekt i olika tillgänglighetszoner;
säkerhet. ELB fungerar med Amazon VPC och erbjuder olika säkerhetsfunktioner – inklusive integrerad certifikathantering, användarautentisering och SSL/TLS-dekryptering. Tillsammans ger detta centraliserad och flexibel hantering av TLS-inställningar;
elasticitet. ELB kan hantera plötsliga förändringar i nätverkstrafik. Den djupa integrationen med Auto Scaling ger applikationen tillräckligt med resurser när belastningen ändras, utan att man behöver ingripa manuellt;
flexibilitet. IP-adresser kan användas för att dirigera förfrågningar till målen för dina applikationer. Detta säkerställer flexibilitet vid virtualisering av målapplikationer, vilket möjliggör att köra flera applikationer på en och samma instans. Eftersom applikationerna kan använda samma nätverksport och har separata säkerhetsgrupper, förenklas interaktionen mellan applikationer i en mikroservicesarkitektur;
övervakning och granskning. Du kan övervaka applikationer i realtid med hjälp av funktionerna i Amazon CloudWatch. Detta omfattar metrik, loggar och spårning av förfrågningar. Enkelt uttryckt kan du identifiera problem och noggrant fastställa flaskhalsar i prestanda;
hybridlastbalansering. Möjligheten att balansera lasten mellan lokala resurser och AWS med samma lastbalanserare förenklar migrering eller utvidgning av lokala applikationer till molnet. Det underlättar också hantering av fel med hjälp av molnet.

Om du är intresserad av detaljer, här är ett par nyttiga länkar från Amazons officiella sida:

Källa: habr.com