Wat is schaalbaarheid?

In de bedrijfswereld kan groei gunstig zijn. Wanneer de groei echter te snel plaatsvindt en als u er niet adequaat op voorbereid bent, kan groei problemen creëren. Een van deze problemen is het effect van groei op de betrouwbaarheid van toepassingen en services die niet zijn ontworpen om een grote toename van het verkeer af te handelen.

Voor uw klanten en gebruikers is een storing een storing. Ze weten niet of ze geen toegang hebben tot uw site vanwege buggycode of omdat te veel andere mensen uw perfect gecodeerde site tegelijkertijd proberen te gebruiken.

schaalbaarheid is de mogelijkheid om zich aan te passen aan hogere eisen of veranderende behoeften. Uw toepassingen en services moeten een grotere hoeveelheid workload kunnen verwerken om groei mogelijk te maken. Schaalbare toepassingen kunnen in de loop van de tijd een toenemend aantal aanvragen verwerken zonder een negatief effect op beschikbaarheid of prestaties.

In deze les leert u meer over de relatie tussen schaalbaarheid en betrouwbaarheid, het belang van capaciteitsplanning bij het bereiken van schaalbaarheid en bekijkt u kort enkele basisconcepten en termen met betrekking tot schalen.

Schaalbaarheids-/betrouwbaarheidsrelatie

Het goede nieuws is dat wanneer u uw app beter schaalbaar maakt, dit het ook betrouwbaarder kan maken. Als uw systeem bijvoorbeeld automatisch schaalt en er een onderdeelfout op één virtuele machine is opgetreden, richt de service voor automatisch schalen een ander exemplaar in om te voldoen aan de minimale vereisten voor het aantal virtuele machines (VM's). Uw systeem wordt betrouwbaarder. In een ander voorbeeld gebruikt u een service op hoger niveau, zoals Azure Storage die inherent schaalbaar is. Als u een opslagprobleem hebt, is de service gebouwd om betrouwbaar te zijn, zodat uw gegevens worden gerepliceerd.

Hier volgt een analogie: Denk aan de toegankelijkheidshellingen die u vaak buiten gebouwen ziet en die aanvankelijk zijn ontworpen om mensen in een rolstoel te kunnen voorzien. Ze dienen dat doel. Maar ze worden ook gebruikt door ouders met baby's in kinderwagens of wagentjes, of door kleine kinderen voor wie de traptreden te diep of hoog zijn. Dit gebruik is een secundair voordeel.

Betrouwbaarheid is vaak een secundair voordeel van schaalbaarheid. Als u uw systemen zo ontwerpt dat ze schaalbaar zijn, zijn ze waarschijnlijk ook betrouwbaarder.

Schaalbaarheid en capaciteitsplanning

capaciteitsplanning omvat het bepalen van de resources die u nodig hebt om zowel aan de huidige als toekomstige eisen te voldoen. U voert deze planning uit door uw huidige resourcegebruik te analyseren en vervolgens te projecteren op toekomstige groei.

Als u de capaciteitsbehoeften in de toekomst wilt schatten, moet u rekening houden met de volgende factoren:

• Verwachte bedrijfsgroei
• Periodieke schommelingen (seizoensgebonden, enzovoort)
• Toepassingsbeperkingen
• Identificatie van knelpunten en beperkingsfactoren

U moet ook serviceniveaudoelstellingen instellen, zodat u een capaciteitsbeheerplan kunt maken dat betrouwbaar aan deze doelstellingen voldoet of overschrijdt wanneer de workload en omgeving veranderen.

Capaciteitsplanning is een iteratief proces. Tijdens het doorlopen van deze module leert u hoe u resourcevereisten voor toepassingsonderdelen kunt toewijzen.

Concepten en terminologie

Voordat u de concepten en strategieën die u in deze module tegenkomt volledig begrijpt, hebt u enige vereiste kennis nodig van enkele basisconcepten en fundamentele termen met betrekking tot schalen.

• Omhoog schalen: een component groter maken zodat het een verhoogde werklast kan afhandelen. Ook wel verticaal schalen genoemd.
• Uitschalen: meer onderdelen of resources toevoegen om de belasting over een gedistribueerde architectuur te verdelen. Gebruik bijvoorbeeld een eenvoudige architectuur met meerdere back-ends achter een set front-ends. Naarmate de belasting toeneemt, voegen we meer back-endservers (en front-endservers) toe om deze te verwerken. Ook wel horizontaal schalen genoemd.
• Handmatig schalen: Menselijke actie is nodig om de hoeveelheid resources te verhogen.
• Automatisch schalen: Het systeem past automatisch de hoeveelheid resources aan op basis van de belasting. Om duidelijk te zijn, wordt de hoeveelheid zowel omhoog als omlaag aangepast op basis van een verhoogde of verminderde belasting.
• DIY-schaal: Zelf schalen waarbij u de automatische schaalaanpassing moet configureren.
• Inherente schaal: Services die zijn gebouwd om schaalbaar te zijn en de schaalvergroting voor u achter de schermen af te handelen zonder tussenkomst van uw kant. Vanuit uw perspectief zien ze er bijna oneindig schaalbaar uit, omdat u gewoon meer resources kunt gebruiken zonder ze handmatig in te richten.

Architectuur van Tailwind Traders

In deze module gebruiken we een voorbeeldarchitectuur van een fictief hardwarebedrijf met de naam Tailwind Traders. Hun e-commerceplatform ziet er als volgt uit:

Dit diagram is op het eerste gezicht redelijk complex, dus laten we het doorlopen. De website heeft een front-end. Dat is waar je mee praat als je naar tailwindtraders.com gaat.

De front-end communiceert met een set backendservices. Deze back-endservices omvatten de algemene items, zoals een couponservice, een winkelwagenservice, een voorraadservice, enzovoort. Ze worden allemaal uitgevoerd in Azure Kubernetes Service. Er zijn andere onderdelen en technologieën in het spel met deze toepassing. U hoeft zich alleen maar te richten op de front-end en de back-endservices die worden uitgevoerd op Kubernetes.

Enkele storingspunten

Nu u de hele architectuur hebt gezien, laten we even de tijd nemen om de enkele punten van falen te onderzoeken en de plaatsen waar we onze aandacht kunnen vestigen wanneer we nadenken over schaalvergroting.

Al deze services zijn een enkelvoudig foutpunt - ze zijn niet gebouwd voor veerkracht of om op te schalen. Als een van hen overbelast raakt, loopt het waarschijnlijk vast en is er geen eenvoudige manier om dat op dit moment op te lossen.

Verderop in deze module kijken we naar andere manieren om deze service te ontwerpen om schaalbaar en betrouwbaarder te zijn.

Vooraf ingerichte capaciteit

Laten we eens kijken naar een ander probleem dat lastig kan blijken. Dit zijn de services/onderdelen waarvoor we capaciteit vooraf moeten inrichten:

Met Cosmos DB richten we bijvoorbeeld de doorvoer vooraf in. Als we deze limieten overschrijden, gaan we beginnen met het retourneren van foutberichten aan onze klanten. Met Azure AI-services selecteren we de laag en die laag heeft een maximum aantal aanvragen per seconde. Nadat we een van de limieten hebben bereikt, wordt de snelheid van klanten beperkt.

Zal een aanzienlijke piek in het verkeer, zoals het lanceren van een nieuw product, ervoor zorgen dat we deze limieten bereiken? Op dit moment weten we het niet. Dit is een andere kwestie die we verderop in deze module bekijken.

Kosten

Zelfs als we het goed doen, moeten we nog steeds plannen voor groei. Dit zijn de services voor betalen per gebruik:

Hier gebruiken we Azure Logic Apps en Azure Functions. Dit zijn beide voorbeelden van serverloze technologie. Deze diensten worden automatisch geschaald en we betalen per verzoek. Uw factuur groeit naarmate uw klantenbestand dat doet. We moeten ons ten minste bewust zijn van de impact die toekomstige gebeurtenissen, zoals een productlancering, kunnen hebben op onze clouduitgaven. Verderop in deze module werken we aan het begrijpen en voorspellen van onze clouduitgaven.