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 bevat een schat aan resources om u te helpen bij het ontwerpen van uw toepassingen in de cloud 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 op Azure Kubernetes Service of ze kunnen worden uitgevoerd op VM's of App Service. Ze maken ook gebruik van 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 Azure virtuele-machineschaalsets, 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, die fysiek gescheiden locaties zijn binnen een Azure regio, elk uit een of meer datacenters. Met AZ-ondersteuning kunt u uw VM's verspreiden over meerdere AZ's, waardoor uw toepassing betrouwbaarder wordt en deze beschermt 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 de Azure Load Balancer voor basis laag 4-verkeersdistributie. 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: wanneer een productafbeelding wordt geüpload, wordt die afbeelding getranscodeerd en opgeslagen 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, waarin pub/sub- en geavanceerde integratiepatronen worden aangeboden.
• Azure Storage Queues Een eenvoudige, op REST gebaseerde wachtrijinterface die is gebouwd boven 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 Managed Redis (voorheen 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, een beheerd SQL Server-aanbod 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. Dit aanpassen van de grootte kan eenvoudig worden gedaan met slechts een kort verlies van connectiviteit, door een eenvoudige API-aanroep in Azure SQL te gebruiken of een schuifregelaar in de portal te hanteren.

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, zodat u leesverkeer naar uw leesreplica kunt routeren.

Deze wijziging moet worden geïmplementeerd in code. U geeft de routeringsintentie op door het kenmerk ApplicationIntent in uw database-verbindingstring in te stellen. Gebruik ReadOnly om verbinding te maken met de replica, of ReadWrite om verbinding te maken met de primaire.

De aanbevolen methode is om beheerde identiteiten te gebruiken voor verificatie, waarbij alle benodigde configuraties in Azure Key Vault worden opgeslagen:

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Omdat deze wijziging 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 Azure SQL Database door gebruik te maken van sharding.

Databasesharding

Als uw databaseresources na het omhoog schalen of implementeren van leesreplica's 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 hulpprogramma's voor Azure Elastic Database. Deze hulpprogramma's helpen u bij het maken, onderhouden en opvragen van shard-SQL-databases in Azure vanuit uw toepassingslogica.