🥇Load balancing met AWS ELB

Hallo iedereen! Vandaag start de cursus «AWS voor ontwikkelaars», daarom hebben we een themawebinar georganiseerd over de ELB. We hebben de soorten load balancers besproken en verschillende EC2-instanties met een load balancer gemaakt. We hebben ook andere gebruiksvoorbeelden bestudeerd.

Na het beluisteren van het webinar, zult u:

begrijpen wat AWS Load Balancing is;
de types Elastic Load Balancer en zijn componenten kennen;
AWS ELB in uw praktijk gebruiken.

Waarom is dit belangrijk:

het is nuttig als u van plan bent om AWS-certificeringsexamens af te leggen;
het is een eenvoudige manier om de belasting over servers te verdelen;
het is een eenvoudige manier om Lambda aan uw service toe te voegen (ALB).

De open les werd gegeven door Rishat Teregulov, systeemingenieur bij een marketingbedrijf voor websiteontwikkeling en -ondersteuning.

Inleiding

Wat Elastic Load Balancer is, kunt u zien in het diagram hieronder, waar een eenvoudig voorbeeld wordt gepresenteerd:

De Load Balancer ontvangt verzoeken en verdeelt deze over de instanties. We hebben één afzonderlijke instantie, Lambda-functies en een AutoScaling-groep (groep servers).

Soorten AWS ELB

1. Laten we de belangrijkste types bekijken:

Classic Load Balancer. De allereerste load balancer van AWS, werkt op zowel level 4 als level 7 van het OSI-model, ondersteunt HTTP, HTTPS, TCP en SSL. Het biedt basis load balancing tussen meerdere Amazon EC2-instanties en werkt op zowel verzoeken- als verbindingniveau. Laten we het openen (gemarkeerd in grijs):

Deze balancer wordt als verouderd beschouwd, daarom wordt gebruik ervan slechts in bepaalde gevallen aanbevolen. Bijvoorbeeld voor applicaties die zijn gebouwd in het EC2-Classic netwerk. In feite staat niets ons in de weg om het te maken:

2. Network Load Balancer. Geschikt voor hoge belasting, werkt op level 4 van het OSI-model (kan worden gebruikt in EKS en ECS), ondersteunt TCP, UDP en TLS.

De Network Load Balancer leidt het verkeer naar doelobjecten in Amazon VPC en kan miljoenen verzoeken per seconde verwerken met extreem lage latentie. Bovendien is het geoptimaliseerd voor het verwerken van verkeerspatronen met onverwachte en veranderlijke belasting.

3. Application Load Balancer. Werkt op level 7, ondersteunt Lambda, ondersteunt regels op header- en padniveau, ondersteunt HTTP en HTTPS.
Biedt geavanceerde verzoekroutering voor applicaties, gebouwd op moderne architecturen, waaronder microservices en containers. Leidt verkeer naar doelobjecten in Amazon VPC, afhankelijk van de inhoud van het verzoek.

Voor veel gebruikers verving de Application Load Balancer in eerste instantie de Classic Load Balancer, aangezien TCP minder gebruikelijk is in vergelijking met HTTP.

Laten we er ook een maken, waardoor we al twee load balancers hebben:

Componenten van Load Balance

Algemene componenten van Load Balance (gemeenschappelijk voor alle load balancers):

Access Logging Policy

— uw toeganglogs voor ELB. Om instellingen te wijzigen, kunt u naar de Beschrijving gaan en de knop 'Attributen bewerken' selecteren:

Vervolgens geven we S3Bucket op — de objectopslag van Amazon:

Scheme

— interne of externe load balancer. Het idee is of uw LoadBalancer externe adressen moet ontvangen om van buitenaf toegankelijk te zijn, of dat het uw interne load balancer kan zijn;

Security Groups

— toegangsbeheer tot de load balancer. Dit is in wezen een high-level firewall.

Subnets

— subnets binnen uw VPC (en dus ook beschikbaarheidszones). Subnets worden opgegeven bij het aanmaken. Als VPC beperkt is tot een regio, zijn de subnets beperkt tot de beschikbaarheidszones. Wanneer u een Load Balancer maakt, is het beter om deze in ieder geval in twee subnets te maken (helpt bij problemen met een beschikbare zone);

Listeners

— uw load balancer-protocollen. Zoals eerder vermeld kan dat voor de Classic Load Balancer HTTP, HTTPS, TCP en SSL zijn, voor de Network Load Balancer — TCP, UDP en TLS, en voor de Application Load Balancer — HTTP en HTTPS.

Voorbeeld voor Classic Load Balancer:

Bij de Application Load Balancer zien we een iets andere interface en in het algemeen een andere logica:

Componenten van Load Balancer v2 (ALB en NLB)

Laten we nu dieper ingaan op de load balancers van versie 2, Application Load Balancer en Network Load Balancer. Deze load balancers hebben hun eigen componentkenmerken. Bijvoorbeeld, er is een concept als Target Groups — instanties (en functies). Dankzij deze component hebben we de mogelijkheid om aan te geven naar welke van de Target Groups we het verkeer willen sturen.

In eenvoudige bewoordingen geven we in Target Groups de instanties op waar het verkeer naartoe zal komen. In de Classic Load Balancer sluit u gewoon direct instanties aan op de load balancer, terwijl u in de Application Load Balancer eerst:

een Load Balancer maakt;
een Target-groep aanmaakt;
verkeer op de juiste poorten of regels van de Load Balancer naar de juiste Target Groups stuurt;
In de doelgroepen wijst u instanties toe.

Deze werklogica kan ingewikkelder lijken, maar in werkelijkheid is het handiger.

De volgende component is - Listener rules (regels voor routing). Dit betreft alleen de Application Load Balancer. Bij de Network Load Balancer creëert u eenvoudig een Listener, en deze verstuurt verkeer naar een specifieke doelgroep, maar bij de Application Load Balancer is het interessanter en gebruiksvriendelijker..

Laten we nu een paar woorden zeggen over de volgende component - Elastic IP (statische adressen voor NLB). Als de regels voor routing van Listener rules alleen betrekking hadden op de Application Load Balancer, dan heeft Elastic IP alleen betrekking op de Network Load Balancer.

Laten we een Network Load Balancer aanmaken:

En juist tijdens het maken zullen we zien dat we de mogelijkheid krijgen om een Elastic IP te kiezen:

Elastic IP biedt een enkele IP-adres dat in de tijd aan verschillende EC2-instanties kan worden gekoppeld. Als een EC2-instantie een Elastic IP-adres heeft en deze instantie is gestopt of beëindigd, kunt u onmiddellijk een nieuwe EC2-instantie met het Elastic IP-adres verbinden. Hierdoor stopt uw huidige applicatie niet met werken, aangezien de applicaties nog steeds hetzelfde IP-adres zien, zelfs als de echte EC2 is veranderd.

Hier is een andere use-case over waarom Elastic IP nodig is. Kijk, we zien 3 IP-adressen, maar deze zullen niet voor altijd hier blijven:

Amazon verandert ze na verloop van tijd, en kan dit elke 60 seconden doen (maar in de praktijk natuurlijk minder vaak). Dit betekent dat de IP-adressen kunnen veranderen. En in het geval van Network Load Balancer kunt u het ip-adres vastleggen en het gebruiken in uw regels, beleidslijnen, enz.

Laten we conclusies trekken.

ELB zorgt voor automatische distributie van binnenkomend verkeer over meerdere doelobjecten (containers, Amazon EC2-instanties, IP-adressen en Lambda-functies). ELB kan verkeer met een variabele belasting verdelen zowel binnen één beschikbaarheidszone als tussen meerdere beschikbaarheidszones. De gebruiker kan kiezen uit drie soorten balancers die hoge beschikbaarheid, autoscaling en een goede beveiliging bieden. Dit alles is belangrijk voor de veerkracht van uw applicaties.

Belangrijkste voordelen:

hoge beschikbaarheid. In de serviceovereenkomst wordt 99,99% beschikbaarheid voor de load balancer bedoeld. Bijvoorbeeld, meerdere beschikbaarheidszones garanderen dat het verkeer alleen wordt afgehandeld door functionerende objecten. In feite kan de belasting ook over de hele regio worden gebalanceerd, waarbij het verkeer wordt omgeleid naar functionerende doelobjecten in verschillende beschikbaarheidszones;
veiligheid. ELB werkt met Amazon VPC en biedt verschillende beveiligingsmogelijkheden, waaronder geïntegreerd certificaatbeheer, gebruikersauthenticatie en SSL/TLS-decryptie. Dit alles zorgt voor centraal en flexibel beheer van TLS-instellingen;
elasticiteit. ELB kan omgaan met plotselinge veranderingen in netwerkbelasting. De diepe integratie met Auto Scaling geeft de applicatie voldoende middelen als de belasting verandert, zonder dat handmatige tussenkomst nodig is;
flexibiliteit. IP-adressen kunnen worden gebruikt voor het routeren van verzoeken naar de doelobjecten van uw applicaties. Hierdoor wordt flexibiliteit gegarandeerd bij het virtualiseren van doelapplicaties, waardoor het mogelijk is om meerdere applicaties op één instance te hosten. Aangezien applicaties dezelfde netwerkpoort kunnen gebruiken en aparte beveiligingsgroepen hebben, wordt de interactie tussen applicaties vereenvoudigd, vooral wanneer we bijvoorbeeld een microservices-architectuur hebben;
monitoring en auditing. U kunt applicaties in real-time monitoren met behulp van Amazon CloudWatch-functies. Dit betreft metrics, logs en het volgen van verzoeken. Zeggend in eenvoudige taal, u kunt problemen identificeren en de knelpunten in de prestaties vrij nauwkeurig bepalen;
hybride belastingbalancing. De mogelijkheid om de belasting te balanceren tussen lokale middelen en AWS met gebruik van dezelfde load balancer vergemakkelijkt de migratie of uitbreiding van lokale applicaties naar de cloud. Ook wordt het omgaan met storingen in de cloud vergemakkelijkt.

Als u meer informatie wilt, vindt u hier nog een paar nuttige links van de officiële Amazon-website:

Bron: habr.com