Wat is schaalbaarheid voor systemen en services?

Een schaalbaar systeem is een systeem dat snelle veranderingen in werklast en vraag kan verwerken. De schaalbaarheid geeft aan hoe goed dat systeem reageert op veranderingen door resources toe te voegen of te verwijderen om aan de vraag te voldoen. De architectuur is het geheel van hardware, software, technologie en best practices waarop de netwerken, toepassingen, processen en services in je hele systeem steunen.

Schaalbaarheid betekenis

Je systeem, bestaande uit de architectuur, de services, de producten en alles wat jouw merk definieert, is schaalbaar als:

• Het resources kan toevoegen en kan opschalen om een toegenomen vraag van klanten en een grotere werklast naadloos te verwerken.
• Het resources gemakkelijk en naadloos kan verwijderen als de vraag en de werklast afnemen.

Het uitgangspunt is een systeem dat de capaciteit kan aanpassen om aan een continu veranderende vraag te voldoen. Het systeem moet uiterst toegankelijk zijn en altijd en overal beschikbaar zijn voor al je klanten. 

Zo zal een goed ontworpen, schaalbare website met een enkele bezoeker even goed functioneren als met duizenden gelijktijdige bezoekers. De functionaliteit mag niet merkbaar afnemen als er meer gebruikers inloggen.

Wat is schaalbaarheid?

Heb jij ooit met LEGO®-blokjes gespeeld? Misschien heb je ooit iets gebouwd zonder de instructies te volgen en bleek je constructie niet echt stevig. Wie daarentegen de geïllustreerde instructies nauwgezet opvolgt, krijgt altijd een solide structuur die alleen uiteenvalt als je de blokjes opzettelijk weer uit elkaar haalt. De bouwtechnieken in de instructies zijn uitvoerig getest als goede oplossingen voor de gebruikelijke, structurele problemen waar bouwers mee geconfronteerd worden.

In de computerwereld zijn architectuurpatronen vergelijkbaar met de LEGO®-bouwtechnieken in de instructies. Ze vormen een geheel van beproefde ontwikkelings- en programmeertechnieken om gebruikelijke problemen bij computersysteemontwikkeling op te lossen. Deze patronen hebben een solide ontwerpstructuur, goed gedefinieerde eigenschappen en wisten in het verleden al problemen met succes op te lossen. 

Maar dat betekent niet dat alle schaalbaarheidspatronen voor jou geschikt zijn. Het is jouw uitdaging de meest geschikte patronen te selecteren en aan te passen om de unieke problemen van jouw systeem op te lossen. Scalability patterns besparen je tijd doordat veel van het werk al voor je gedaan is.

Welke scalability patterns worden veel gebruikt?

Je kunt kiezen uit verschillende schaalbare architectuurpatronen. Hier bespreken we enkele gangbare patronen om architecturale schaalbaarheidsproblemen op te lossen. 

De AKF Scale Cube

Dit driedimensionale model definieert drie benaderingen van schaalbaarheid langs de x-, y- en z-as.

Schalen via de x-as

De horizontale x-as beschrijft het schalen via meerdere instanties van dezelfde component. Dat doe je door een service, applicatie of dataset achter een loadbalancer te klonen of te kopiëren. Dus als er N klonen van een applicatie draaien, verwerkt elke kloon 1/N deel van de werklast.

Schaalbaarheidspatronen op de x-as zijn gemakkelijk te implementeren en vergroten de transactieschaalbaarheid. Maar het onderhoud kan duur zijn doordat volledige datasets naar meerdere servers gekopieerd worden en datacaches exponentieel toenemen.

Schalen via de y-as

Schalen op de y-as wordt gedefinieerd als het opsplitsen of segmenteren van ongelijke componenten in meerdere macro- of microservices, afgebakend als werkwoord of zelfstandig naamwoord. Een werkwoordsegment kan bijvoorbeeld een service definiëren, zoals 'afrekenen'. Een 'winkelmandje' is een voorbeeld van een zelfstandignaamwoordsegment.

Elke service is afzonderlijk schaalbaar, waardoor je meer resources kunt toewijzen aan alleen die services die ze op dit moment nodig hebben. Om een hoge beschikbaarheid te garanderen, moet elke service beschikken over een eigen dataset die niet wordt gedeeld. 

Aangezien de datasets niet gedeeld worden, kunnen fouten geïsoleerd worden. Daardoor kunnen problemen snel geïdentificeerd en verholpen worden zonder het hele systeem te hoeven scannen. Maar de y-as vergt veel tijd om in te stellen is niet gemakkelijk te implementeren.

Schalen via de z-as

Terwijl de y-as ongelijke componenten opsplitst, wordt de z-as gebruikt voor de segmentatie van gelijke componenten in je systeem. Elke server voert een identieke kopie van de code uit, maar alleen voor een subset (of 'shard') van die data.

De z-as wordt bijvoorbeeld vaak gebruikt om klanten in te delen volgens hun locatie of type. Zo kan een betalende klant op een nieuwswebsite 24/7 onbeperkt toegang krijgen tot de volledige inhoud van de site. Een niet-betalende klant op die zelfde website heeft toegang tot dezelfde data, maar kan bijvoorbeeld slechts drie of vier artikelen per maand openen en lezen. 

Zo'n setup kan de operationele kosten verlagen doordat de datasegmenten kleiner zijn en minder opslagruimte vereisen. Maar het ontwerpen en implementeren van de z-as kost veel tijd en vergt veel automatisering om de systeemoverhead te reduceren. 

Horizontale en verticale schaalbaarheidspatronen

Je kunt opschalen (verticaal) of uitschalen (horizontaal). 

Verticaal schalen

Je schaalt verticaal als je de capaciteit van een component, zoals een server, vergroot om de prestaties te verbeteren. De prestaties van je server zullen immers afnemen naarmate het verkeer toeneemt. De toevoeging van meer RAM en opslagstations zal de prestaties van de server verbeteren, zodat die het toegenomen verkeer gemakkelijker kan verwerken.

Verticaal schalen is eenvoudig te implementeren, bespaart geld doordat je geen nieuwe resources hoeft aan te schaffen en is gemakkelijk te onderhouden. Maar ze kunnen een enkel storingspunt vormen dat tot veel downtime kan leiden.

Een pas beginnend bedrijf kan verticaal schalen om de kosten laag te houden. Maar de verticale benadering bereikt uiteindelijk zijn RAM- en opslaglimieten, waarna je meer resources moet toevoegen om de vraag bij te houden. 

Horizontaal schalen

Je schaalt horizontaal als je de prestatiecapaciteit vergroot door meer van hetzelfde soort resources aan je systeem toe te voegen. In plaats van bijvoorbeeld de capaciteit van een server te vergroten, voeg je meer servers aan het systeem toe. Een loadbalancer verdeelt vervolgens de werklast over de verschillende servers naargelang hun beschikbaarheid. Hierdoor nemen de totale prestaties van het systeem toe.

Meer computerresources betekenen ook meer foutentolerantie en minder risico op downtime. Maar het toevoegen van servers en loadbalancers kan kostbaar zijn. Overweeg daarom een combinatie van resources in eigen beheer en in de cloud om toegenomen verkeer te verwerken.

Loadbalancing

Loadbalancers verdelen de verzoeken van gebruikers en de werklast op efficiënte wijze over een groep back-endservers. Het idee is om het werk zodanig over de beschikbare servers te verdelen dat geen enkele resource overbelast raakt. Loadbalancers helpen je IT-afdeling om de beschikbaarheid en de schaalbaarheid van je services te waarborgen.

De taken van een loadbalancer zijn onder meer:

• Achterhalen welke resources beschikbaar zijn in het systeem.
• De gezondheid van resources controleren om te bepalen welke resources beschikbaar zijn en zodanig functioneren dat ze de werklast kunnen afhandelen. Als een beschikbare server niet naar behoren functioneert, moet de loadbalancer het pad daar naartoe afsluiten en omschakelen naar een andere server zonder dat de gebruiker enige vertraging of downtime opmerkt.
• Bepalen welk algoritme gebruikt moet worden om de werklast te verdelen over de verschillende gezonde back-endservers.

Gangbare methodes (algoritmes) voor loadbalancing zijn:

• Minste verbindingen: het verkeer wordt gerouteerd naar de server met het minste aantal actieve verbindingen.
• Snelste reactietijd: de loadbalancer meet hoe snel de server reageert op een gezondheidscontroleverzoek. Het verkeer wordt naar de gezondste server met de snelste reactietijd gestuurd. Sommige loadbalancers houden bij dit algoritme ook rekening met het aantal actieve verbindingen. 
• Round robin : het verkeer wordt naar de eerst beschikbare server gestuurd, ongeacht de huidige werklast en het aantal actieve verbindingen daarvan. Zodra de server een verzoek ontvangt en verwerkt, plaatst de loadbalancer die server achteraan in de wachtrij. Het risico bestaat dat een server die processorintensieve verzoeken ontvangt nog bezig is met het verwerken van eerdere verzoeken als hij weer vooraan in de wachtrij komt te staan.
• Hash: een hash van gegevens van het inkomende pakket bepaalt welke server het verzoek ontvangt. Die gegevens kunnen onder andere het IP-adres, het poortnummer of de domeinnaam bevatten.

Caching - Content Delivery Networks (CDN)

Een CDN is een wereldwijd netwerk van servers dat wordt gebruikt om de toegang tot en de verdeling van statische webcontent te optimaliseren en te versnellen. Statische webcontent bestaat uit elementen zoals Javascript, CSS, afbeeldingen en andere mediabestanden die niet vaak veranderen.

Tot wel 80 % van een website kan uit statische content bestaan. De video's op een streamingdienst worden bijvoorbeeld niet vaak gewijzigd. Een aantal van die video's wordt heel populair en kan dagelijks miljoenen keren bekeken worden. Dankzij de beschikbaarheid van statische content op een CDN wordt de oorspronkelijke server ontlast en wordt de content wereldwijd en dus dichter bij de gebruikers aangeboden, met een grotere toegankelijkheid en beschikbaarheid als resultaat.

Microservices

Microservices zijn verschillende kleine toepassingen die allemaal kunnen samenwerken. Elke microservice heeft een eigen doel en taak. Ze kunnen ontwikkeld worden door verschillende teams, los van andere microservices. Hoewel microservices volledig onafhankelijk van elkaar kunnen werken, moeten ze wel met elkaar kunnen communiceren. 

Microservices zijn gemakkelijk te schalen omdat je alleen de services hoeft te schalen die dat op dit moment nodig hebben. Ze kunnen afzonderlijk geïmplementeerd worden, zonder overleg tussen verschillende ontwikkelingsteams. Microservices zijn uiterst geschikt voor webtoepassingen, voor snelle ontwikkeling en implementatie en voor teams die over de hele wereld verspreid zijn.

Microservices kunnen transacties of grote datasets efficiënt schalen en helpen je om fouten te isoleren zodat je systemen zeer beschikbaar blijven. Bovendien kunnen grote functies zonder samenhang opgedeeld worden in kleinere services, waardoor de codebase minder complex wordt.

Sharding

Dit is in feite het opsplitsen van een grote database in kleinere, beter beheerbare en schaalbare componenten. Hoe groter een database wordt, hoe meer verzoeken en transacties erop plaatsvinden. Dat vertraagt de responstijd bij databasequery's. Bovendien kan het onderhoud van een enorme database erg duur zijn.

Een shard is een individuele databasepartitie. Om de werklast beter te verdelen, kunnen deze partities opgeslagen en verspreid worden over meerdere gedistribueerde databaseservers. 

Als je database te groot wordt, kun je sharding gebruiken om de volgende redenen:

• Kleinere databases zijn gemakkelijker te beheren.
• Kleinere databases werken sneller en elke individuele shard presteert beter dan een grote database.
• Kleinere databases zijn gemakkelijker te schalen doordat nieuwe datashards aangemaakt en over verschillende servers verdeeld kunnen worden.
• Sharding kan de kosten verlagen doordat je geen enorme, dure servers nodig hebt om ze te hosten.

Door schaalbare architectuurpatronen in je systeem te implementeren, kan je systeem zijn prestatieniveau behouden en wordt een toename van de input mogelijk.