Toepassingen schaalbaar maken

Nu u de basisprincipes van het voorbereiden op groei begrijpt en zich bewust bent van factoren die u in de capaciteitsplanning moet overwegen, kunt u de uitdaging in beslag nemen om uw toepassingen zo schaalbaar mogelijk te maken.

Architectuurbeoordelingen

Een belangrijk punt om te onthouden is dat u regelmatig architectuurbeoordelingen van uw systemen moet uitvoeren.

U weet dat u procedures zoals infrastructuur als code kunt toepassen om de implementatie van uw cloudresources te verbeteren. U werkt uw toepassingscode regelmatig bij en verbetert deze, en u moet hetzelfde doen met uw onderliggende platformbronnen.

Door een architectuurbeoordeling uit te voeren, kunt u de gebieden identificeren die moeten worden verbeterd.

Het Azure Architecture Center beschikt over een schat aan resources om u te helpen uw toepassingen in de cloud te ontwerpen en er zijn veel aanbevelingen voor schaalbaarheid die u kunt vinden in de handleiding voor toepassingsarchitectuur op de volgende koppeling:

Azure Architecture Center

Scenario: Tailwind Traders-architectuur

Een eerste stap is het uitvoeren van een evaluatie van de architectuur en toepassing, niet alleen om te bepalen waar de zwakke punten liggen, maar ook om de sterke punten te herkennen. Wat is er goed aan?

Bekijk nog eens het scenario dat u in de vorige les hebt gezien. Hier volgt een diagram van de architectuur van de organisatie.

Ze hebben de toepassing opgesplitst in kleinere microservices en sommige van deze services bevinden zich als containers in Azure Kubernetes Service of kunnen worden uitgevoerd op VM's of App Service. U gebruikt een aantal inherent schaalbare services, zoals Functions en Logic Apps.

Deze wijziging is goed, maar er zijn enkele verbeteringen die de toepassing schaalbaarder maken. Als voorbeeld richt u zich nu op de productenservice. In het diagram wordt de productservice uitgevoerd in Kubernetes, maar we gaan ervan uit dat deze wordt uitgevoerd op een virtuele machine in Azure. De schaalconcepten, mogelijk met een iets andere implementatie, kunnen worden toegepast op toepassingen, ongeacht of ze worden uitgevoerd op servers, App Service of in containers.

Het product wordt momenteel uitgevoerd op één VIRTUELE machine die is verbonden met één Azure SQL-database. U moet deze VM inschakelen om uit te schalen. U kunt dit doen met behulp van virtuele-machineschaalsets van Azure, waarmee u een groep identieke vm's met gelijke taakverdeling kunt maken en beheren. Omdat u nu meer dan één virtuele machine hebt, moet u een load balancer introduceren om verkeer over de VM's te verdelen.

Virtuele-machineschaalsets

Door virtuele-machineschaalsets toe te passen op meerdere virtuele machines, krijgt u enkele voordelen:

• U kunt automatisch schalen op basis van metrische gegevens van de host, metrische gegevens van gasten, application insights of volgens een schema.
• U kunt beschikbaarheidszones (AZ) gebruiken. Dit zijn onafhankelijke zelfstandige datacenters binnen een Azure-regio. Met AZ-ondersteuning kunt u uw VM's verspreiden over meerdere AZ's, waardoor uw toepassing betrouwbaarder wordt en deze kunt beschermen tegen datacenterfouten. Nieuwe exemplaren in een schaalset worden automatisch gelijkmatig verdeeld over AZ's.
• Het toevoegen van een load balancer wordt eenvoudiger. Virtuele machineschaalsets ondersteunen het gebruik van Azure Load Balancer voor de distributie van laag 4-verkeer. Ze ondersteunen ook Azure Application Gateway voor geavanceerdere distributie van L7-verkeer en SSL-beëindiging.

Er zijn enkele belangrijke factoren die u moet overwegen voordat u schaalsets implementeert. Specifiek:

• Vermijd kleefkracht van instanties, zodat er geen client vastzit aan een specifieke back-end.
• Verwijder permanente gegevens uit de virtuele machine en sla deze ergens anders op, zoals in Azure Storage of in een database.
• Ontwerpen voor schaalbaarheid. Het is ook belangrijk dat uw toepassing eenvoudig omlaag kan worden geschaald. Het moet niet alleen goed omgaan met het toevoegen van meer exemplaren aan de pool van servers die het verkeer verwerken, maar ook de abrupte beëindiging van exemplaren wanneer de belasting afneemt. Het verkleiningsaspect van schalen wordt vaak over het hoofd gezien.

Ontkoppeling

U hebt meer VM's met schaalsets toegevoegd. Uitschalen is het typische antwoord op 'we moeten schalen'. U kunt echter alleen schalen op één metriek en dit antwoord is mogelijk niet relevant voor alle taken die door uw productservice worden uitgevoerd.

In ons scenario heeft de service producten een taak. Er wordt een productafbeelding gemaakt en daarna geüpload. Het transcodeert die afbeelding en slaat deze op in verschillende grootten voor miniaturen, afbeeldingen in de catalogus, enzovoort. De verwerking van afbeeldingen is CPU-intensief, maar het algemene gebruik is geheugenintensief.

Afbeeldingsverwerking is een asynchrone taak die kan worden onderverdeeld in een achtergrondtaak. U kunt dit doen door uw service voor afbeeldingsverwerking los te koppelen met behulp van een wachtrij. Met ontkoppeling kunt u beide services onafhankelijk schalen: één op het geheugen (de productservice) en de andere (de service voor afbeeldingsverwerking) op CPU of zelfs wachtrijlengte, en een andere schaalset verbruikt deze berichten en verwerkt de afbeeldingen.

Schalen met wachtrijen

Azure heeft twee soorten wachtrijaanbiedingen:

• Azure Service Bus-wachtrijen Een geavanceerdere wachtrijaanbieding, die deel uitmaakt van het bredere Azure Service Bus-product, dat pub/sub-patronen en geavanceerdere integratiepatronen biedt.
• Azure Storage-wachtrijen Een eenvoudige, op REST gebaseerde wachtrijinterface die is gebouwd op Azure Storage. Het biedt betrouwbare, permanente berichten.

Uw vereisten in dit scenario zijn eenvoudig, zodat u Azure Storage-wachtrijen kunt gebruiken. Je productniveau hoeft niet te worden uitgebreid omdat je deze achtergrondtaak hebt gescheiden.

In-memory caching (geheugen caching)

Een andere manier om de prestaties van uw toepassing te verbeteren, is door een cache in het geheugen te implementeren.

Nu weet u dat prestaties niet exact gelijk zijn aan schaalbaarheid, maar door de prestaties van uw toepassing te verbeteren, kunt u de belasting van andere resources verminderen. Deze verbetering betekent dat u mogelijk niet zo snel hoeft te schalen.

Azure Cache voor Redis is een beheerde Redis-aanbieding. Redis kan worden gebruikt voor veel patronen en use cases. Voor uw productservice in dit scenario implementeert u waarschijnlijk het cache-aside-patroon. In dit patroon laadt u indien nodig items uit de database in de cache, waardoor uw toepassing beter presteert en de belasting van de database vermindert.

Redis kan ook worden gebruikt als een berichtenwachtrij voor het opslaan van webinhoud in de cache of voor het opslaan van gebruikerssessies. Dit type caching is mogelijk geschikter voor andere services in het systeem, zoals de winkelwagenservice, waar u winkelwagengegevens per sessie in Redis kunt opslaan in plaats van een cookie te gebruiken.

De database schalen

Nu u uw rekenresources schaalbaarder hebt gemaakt, bekijkt u de database. In dit scenario gebruikt u Azure SQL-database. Dit is een beheerde SQL Server-aanbieding van Azure.

Relationele databases zijn moeilijker uit te schalen dan niet-relationele databases. Het eerste wat u kunt doen om uw database te schalen, is door de grootte van de database omhoog te schalen. Het formaat wijzigen kan gemakkelijk worden gedaan met een gemiddelde downtime van minder dan vier seconden. Ofwel met behulp van een eenvoudige API-aanroep in Azure SQL of met behulp van een schuifregelaar in de portal.

Als deze grootte niet voldoet aan uw vereisten, afhankelijk van de verkeerskenmerken, is het mogelijk geschikt om de leesbewerkingen naar de database uit te schalen. Hiermee kunt u leesverkeer naar uw leesreplica routeren.

Deze wijziging moet worden geïmplementeerd in code. Dit doet u als volgt.

#Azure SQL Connection String

#Master Connection String
ApplicationIntent=ReadWrite

#Read Replica Connection String
ApplicationIntent=ReadOnly

#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Werk het kenmerk ApplicationIntent in de databaseverbindingsreeks bij om op te geven op welke server u verbinding wilt maken. Gebruik ReadOnly als u verbinding wilt maken met de replica of ReadWrite als u verbinding wilt maken met de hoofdserver.

Omdat deze opdracht in code moet worden geïmplementeerd, is deze mogelijk geen geschikte oplossing voor uw situatie. Wat gebeurt er als elke productservice de mogelijkheid nodig heeft om te lezen en schrijven?

In dat geval kunt u kijken naar het uitschalen van SQL DB met behulp van sharding.

Databasesharding

Als uw databaseresources na het opschalen of implementeren van Read Replicas nog steeds niet voldoen aan de behoeften van uw systeem, is de volgende optie sharding.

Sharding is een techniek voor het distribueren van grote hoeveelheden identiek gestructureerde gegevens over veel onafhankelijke databases. Sharding kan om verschillende redenen vereist zijn. Bijvoorbeeld:

• De totale hoeveelheid gegevens is te groot om binnen de beperkingen van een afzonderlijke database te passen.
• De transactiedoorvoer van de totale workload overschrijdt de mogelijkheden van een afzonderlijke database.
• Om nalevingsredenen moeten afzonderlijke tenants zich in verschillende fysieke databases bevinden (deze vereiste gaat minder over schalen, maar is een andere situatie waarin sharding wordt gebruikt).

Uw toepassing voegt de relevante gegevens toe aan de relevante shard en maakt uw systeem dus schaalbaar buiten de beperkingen van de afzonderlijke database.

Azure SQL biedt de Azure Elastic Database-hulpprogramma's. Deze hulpprogramma's helpen u bij het maken, onderhouden en opvragen van shard-SQL-databases in Azure op basis van uw toepassingslogica.