🥇Lastbalancering med AWS ELB

Hej alle! I dag starter kurset «AWS for udviklere», hvorfor vi afholdt et relevant webinar, der var dedikeret til en oversigt over ELB. Vi gennemgik typerne af belastningsbalancere og oprettede flere EC2-instanser med en belastningsbalancer. Vi undersøgte også andre anvendelseseksempler.

Når du har lyttet til webinaret, vil du:

forstå, hvad AWS Load Balancing er;
kende typerne af Elastic Load Balancer og dens komponenter;
bruge AWS ELB i din praksis.

Hvorfor overhovedet kunne det:

nyttigt, hvis du planlægger at tage AWS-certificeringseksamener;
det er en enkel måde at fordele belastningen mellem servere;
det er en enkel måde at tilføje Lambda til din service (ALB).

Den åbne lektion blev ledet af Rishat Teregulov, systemingeniør i et marketingfirma til udvikling og support af websites.

Introduktion

Hvad Elastic Load Balancer er, kan ses på diagrammet nedenfor, hvor der præsenteres et enkelt eksempel:

Belastningsbalanceren modtager anmodninger og fordeler dem mellem instanserne. Vi har en separat instans, Lambda-funktioner og en AutoScaling-gruppe (servergruppe).

Typer af AWS ELB

1. Lad os se på de vigtigste typer:

Classic Load Balancer. Den første belastningsbalancer fra AWS, fungerer både på niveau 4 og 7 i OSI-modellen, understøtter HTTP, HTTPS, TCP og SSL. Den sikrer grundlæggende belastningsbalancering mellem flere Amazon EC2-instanser og fungerer både på anmodningsniveau og forbindelsesniveau. Lad os åbne den (markeret med grå):

Denne balancer anses for at være forældet, så den anbefales kun til brug i særlige tilfælde. For eksempel for applikationer, der blev bygget i EC2‑Classic-netværket. Generelt er der ikke noget til hinder for, at vi kan oprette den:

2. Network Load Balancer. Velegnet til høj belastning, fungerer på niveau 4 i OSI (kan bruges i EKS og ECS), understøtter TCP, UDP og TLS.

Network Load Balancer dirigerer trafikken til målobjekterne i Amazon VPC og kan håndtere millioner af anmodninger per sekund ved ekstremt lave ventetider. Desuden er den optimeret til at håndtere trafikmønstre med pludselige og skiftende belastninger.

3. Application Load Balancer. Fungerer på niveau 7, har støtte til Lambda, understøtter regler på hoved- og stiniveau, understøtter HTTP og HTTPS.
Giver avanceret ruteanmodning, der fokuserer på leveringen af applikationer bygget på moderne arkitekturer, herunder mikroservices og containere. Dirigerer trafik til målobjekter i Amazon VPC baseret på indholdet af anmodningen.

For mange brugere erstattede Application Load Balancer først Classic Load Balancer, da TCP ikke er så udbredt i modsætning til HTTP.

Lad os også oprette den, hvormed vi allerede har to belastningsbalancere:

Komponenter til Lastbalance

Generelle komponenter til Lastbalance (tilstedeværende i alle belastningsbalancere):

Adgangslogningspolitik

— dine adgangslogger til ELB. For at konfigurere det, kan du gå til Beskrivelse og vælge knappen 'Rediger attributter':

Derefter angiver vi S3Bucket — objektslageret i Amazon:

Scheme

— intern eller ekstern balancer. Pointen er, om din LoadBalancer skal modtage eksterne adresser for at være tilgængelig udefra, eller om det kan være din interne balancer;

Sikkerhedsgrupper

— kontrol af adgangen til balancer. I bund og grund er dette en avanceret firewall.

Undernet

— undernet inde i dit VPC (og dermed tilgængelighedszoner). Undernet angives ved oprettelse. Hvis VPC er begrænset til regionen, er Undernet begrænset af tilgængelighedszoner. Når du opretter Load Balancer, er det bedst at oprette den i mindst to undernet (hjælper, hvis der opstår problemer med en tilgængelighedszone);

Lyttere

— dine protokoller for balancer. Som nævnt tidligere kan dette for Classic Load Balancer være HTTP, HTTPS, TCP og SSL, for Network Load Balancer — TCP, UDP og TLS, for Application Load Balancer — HTTP og HTTPS.

Eksempel for Classic Load Balancer:

Her i Application Load Balancer ser vi en lidt anden brugerflade og generelt en anden logik:

Komponenter til Load Balancer v2 (ALB og NLB)

Lad os nu se nærmere på anden version af Application Load Balancer og Network Load Balancer. Disse balancere har deres egne komponentfunktioner. For eksempel er der nu et begreb som Target Groups — instanser (og funktioner). Takket være denne komponent, har vi mulighed for at angive, hvilken af Target Groups vi vil dirigere trafik til.

For at sige det enkelt, angiver vi i Target Groups, hvilke instanser trafik vil komme til. Mens du i Classic Load Balancer blot tilslutter instanser direkte til balancer, så gør du i Application Load Balancer det først ved at:

oprette en Load Balancer;
oprette en Target-gruppe;
dirigerer til de nødvendige porte eller Load Balancer-regler til de relevante Target Groups;
i Target-grupperne tildeler du instanser.

Sådan en arbejdslogik kan virke mere kompleks, men i virkeligheden er den mere praktisk.

Den næste komponent — Listener-regler (regler for routing). Dette vedrører kun Application Load Balancer. I Network Load Balancer opretter du blot en Listener, og den sender trafik til en bestemt Target-gruppe, men i Application Load Balancer er alt mere sjovt og praktisk.

Nu skal vi sige et par ord om den næste komponent — Elastic IP (statisk adresser til NLB). Hvis reglerne for routing Listener-reglerne kun vedrørte Application Load Balancer, så gælder Elastic IP kun Network Load Balancer.

Lad os oprette en Network Load Balancer:

Og netop i oprettelsesprocessen vil vi se, at vi får mulighed for at vælge Elastic IP:

Elastic IP giver en enkelt IP-adresse, som kan knyttes til forskellige EC2-instanser over tid. Hvis en EC2-instant har en Elastic IP-adresse, og denne instans stoppes eller afsluttes, kan en ny EC2-instant straks knyttes til Elastic IP-adressen. Dine nuværende applikationer stopper ikke, da de fortsat ser den samme IP-adresse, selvom den faktiske EC2 er ændret.

Her er endnu et use-case om hvorfor Elastic IP er nødvendigt. Se, vi ser 3 IP-adresser, men de vil ikke forblive her for evigt:

Amazon ændrer dem over tid, muligvis hver 60. sekund (men i praksis sjældnere). Det betyder, at IP-adresserne kan ændre sig. Og i tilfældet med Network Load Balancer kan du netop knytte IP-adressen og angive den i dine regler, politikker osv.

Lad os opsummere

ELB sikrer automatisk fordeling af indkommende trafik til flere mål (containere, Amazon EC2-instanser, IP-adresser og Lambda-funktioner). ELB kan fordele trafik med varierende belastning både inden for en tilgængelighedzone og på tværs af flere tilgængelighedszoner. Brugeren kan vælge mellem tre typer balancere, der sikrer både høj tilgængelighed, automatisk skalering og rimelig beskyttelse. Alt dette er vigtigt for at sikre robustheden af dine applikationer.

De primære fordele:

høj tilgængelighed. Aftalen om service indebærer 99,99 % tilgængelighed for lastbalancer. For eksempel sikrer flere tilgængelighedszoner, at trafikken kun behandles af funktionsdygtige objekter. Man kan faktisk balancere belastningen på tværs af regionen ved at omdirigere trafikken til funktionsdygtige målobjekter i forskellige tilgængelighedszoner;
sikkerhed. ELB fungerer med Amazon VPC og tilbyder forskellige sikkerhedsmuligheder — det inkluderer integreret certifikatstyring, brugergodkendelse og SSL/TLS-kryptering. Alt i alt giver dette centraliseret og fleksibel håndtering af TLS-indstillinger;
elasticitet. ELB kan håndtere pludselige ændringer i netværkstrafikken. Den tætte integration med Auto Scaling giver applikationen tilstrækkelige ressourcer, når belastningen ændrer sig, uden behov for manuel intervention;
fleksibilitet. IP-adresser kan bruges til at rute anmodninger til målobjekterne for dine applikationer. Dette sikrer fleksibilitet i virtualiseringen af målprogrammerne, hvilket gør det muligt at hoste flere applikationer på én instans. Da applikationerne kan bruge én netværksport og har separate sikkerhedsgrupper, forenkles interaktionen mellem applikationer, især i en mikroservices-arkitektur;
overvågning og revision. Du kan overvåge applikationer i realtid ved hjælp af Amazon CloudWatch-funktioner. Dette inkluderer målinger, logs og sporing af anmodninger. Med andre ord kan du identificere problemer og præcist bestemme flaskehalse i ydeevnen;
hybrid lastbalancering. Muligheden for at balancere belastningen mellem lokale ressourcer og AWS ved hjælp af den samme balancer gør det lettere at migrere eller udvide lokale applikationer til skyen. Det forenkler også håndteringen af fejlsituationer ved brug af skyen.

Hvis du er interesseret i flere detaljer, har vi et par nyttige links fra Amazon's officielle hjemmeside:

Kilde: habr.com