Tech Talk-reeks: Architectuur voor Schaalbaarheid in je Multi-tenant Cloud

Bij Jitterbit is het onze missie om zelfs de meest complexe connectiviteitsuitdagingen te vereenvoudigen en iedereen in staat te stellen verbinding te maken in de digitale wereld van vandaag. Hoewel we benadrukken dat je geen ontwikkelaar hoeft te zijn om de producten van Jitterbit te gebruiken, staat er achter elke geweldige softwareoplossing een team van fantastische ontwikkelaars.   In de Jitterbit Tech Talk blog-serie geven leden van het Jitterbit-ontwikkelingsteam ons inzicht in het bouwen van een cloudplatform van enterprise-klasse en de uitdagingen die ze moesten overwinnen op het gebied van multi-tenancy, schaalbaarheid en beveiliging.

Deze week kijkt Pankaj Arora, onze Sr. Director of Technology, naar hoe je een uiterst schaalbaar cloudplatform van enterprise-klasse ontwerpt en architectuurt.

De Cloud biedt bedrijven een krachtige manier om hun producten en diensten aan te bieden die gemakkelijk toegankelijk zijn vanaf elke locatie en op elk apparaat. Het biedt ook enorme voordelen voor de leverancier, waaronder inzicht in hoe hun aanbod wordt gebruikt, snelle ontwikkeling en implementatie en algehele verminderingen van IT- en onderhoudskosten. Als gevolg hiervan wil bijna elk bedrijf tegenwoordig zijn oplossingen in de Cloud beschikbaar maken.

Maar er komt veel meer kijken bij het worden van een echt cloudbedrijf dan het installeren van software op een gehoste server en het plakken van “Cloud” op je marketingmateriaal.

Ik sprak onlangs met een technologiestrateeg en die merkte op dat ongeveer 75% van de bedrijven hun verouderde bedrijfsapplicaties graag naar de cloud zouden willen migreren. Verrassend genoeg stelt 90% van hen een eerste plan op dat gebaseerd is op een architectuur waarbij hun verouderde applicaties gewoon op een openbaar toegankelijke cloudserver worden geïmplementeerd. Deze aanpak doet afbreuk aan alle voordelen die de cloud te bieden heeft.

Het bouwen van een echt multi-tenant cloudplatform vereist het oplossen van verschillende soorten uitdagingen, zoals beveiliging, betrouwbaarheid, schaalbaarheid, hoge beschikbaarheid, fouttolerantie, logging, monitoring, een notificatiesysteem, mogelijkheden voor continue implementatie en meer.

In de post van vandaag zullen we dieper ingaan op hoe we de ‘schaalbaarheid’-uitdaging hebben aangepakt bij het ontwikkelen van ons multi-tenant cloudintegratieplatform.

De mate van schaalbaarheid van een applicatie is gekoppeld aan het vermogen om zowel verticaal als horizontaal te schalen. In een cloudomgeving betekent dit dat services moeten worden ontworpen die externe verzoeken afhandelen en zo kunnen schalen dat ze gebruikmaken van interne backend-systemen, zoals databases, caches, mediatorlagen, batchprocessen (analytische engine, aanbevelingsengine) enzovoort, om praktisch oneindige verzoeken in een redelijk korte tijd te verwerken. Het is niet altijd mogelijk om het aantal gebruikers dat uw platform bereikt te voorspellen. Het ontwerpen van een architectuur die hier rekening mee houdt binnen het multi-tenancy model helpt om deze onzekerheid om te zetten in een generiek schaalbaarheidsprobleem.

Verticale schaling

Verticale schaalbaarheid omvat het toevoegen van resources zoals extra CPU's of geheugen aan een enkel knooppunt in een systeem, en dit zou het eerste moeten zijn waar u aan denkt bij het schalen van uw services. Het is erg belangrijk om uw applicaties zo te ontwerpen dat ze deze resources optimaal benutten. Neem de veelvoorkomende use-case voor ons hybride integratiecloudplatform, waar integratiebewerkingen worden afgehandeld door een on-premise of cloud-serverknooppunt. Hier moeten de services een verzoek om integraties uit te voeren aannemen, het verzoek doorgeven aan serverknooppunten en doorgaan met het bedienen van meer verzoeken. De servicelaag mag niet afhankelijk zijn van, of geblokkeerd worden door, de processen die plaatsvinden in verschillende lagen van het systeem. Als zodanig is het erg belangrijk om een asynchrone, event-driven architectuur te hebben.

Een eenvoudige manier om asynchrone architectuur te begrijpen, is door je architectuur te beschouwen als een restaurant. Een ober neemt bestellingen op aan een tafel en geeft deze door aan de chef-kok. Terwijl de chef-kok, de loper en de afruimer zorgen voor activiteiten als koken, uitserveren en opruimen, blijft de ober nieuwe klanten bedienen en voert hij betalingen uit aan het einde van de service.

Het handhaven van asynchroniteit terwijl het systeem werkt met alle componenten zoals database, cache en mediatorlaag is erg belangrijk. Het verdelen van de belasting over geclusterde, hoog beschikbare servernodes die integraties uitvoeren, maakt resources vrij voor de servicelaag om meer verzoeken aan te nemen en te reageren wanneer processen zijn voltooid.

Horizontaal schalen

Het volgende belangrijke aandachtspunt is dat de diensten zo moeten worden geschreven dat het niet uitmaakt hoeveel instanties van die diensten er actief zijn en welk gedeeld systeem op enig moment transacties uitvoert. Dit geeft ons cloudplatform de flexibiliteit om de servicelaag automatisch te schalen. Elk deel van de backend is hoog beschikbaar en automatisch schaalbaar om gelijke tred te houden met de vraag van groeiende servicecontainers.

We kunnen echter geen oneindige hoeveelheid containers laten draaien met servicelagen die gedeelde componenten gebruiken. Dat is niet het optimale ontwerp. Laten we teruggaan naar ons restaurantvoorbeeld. Met verticale schaling kan een enkel restaurant zeer schaalbaar worden door meer personeel toe te voegen, maar op een zeker moment bereikt het aantal resources (koks, lopers, afruimers) een verzadigingspunt. Om verder te schalen, zou deze onderneming extra vestigingen moeten openen die helpen om klanten te verspreiden en de belasting te verdelen.

Het is beter om het hele platform op te delen in meerdere zones, waarbij elke zone zich gedraagt als een replica van de initiële zone. Dit stelt ons in staat om meerdere zones te gebruiken om toekomstige behoeften te balanceren.

Dit model heeft verschillende voordelen:

1. Mogelijke oneindige horizontale schaalbaarheid, aangezien we een willekeurig aantal zones kunnen toevoegen

2. Fouttolerantie, voor het geval de gehele zone uitvalt als gevolg van een natuurramp

3. Gegevensscheiding, in het geval van een SaaS-platform dat zelfs locatiegebaseerde metadatasegregatie vereist, zoals voor VS-, EMEA-zones, enz.

Het gewenste resultaat hierbij is dat de ervaring van een gebruiker identiek moet zijn, ongeacht waar deze zich bevindt en welke zone wordt benaderd. Er is geen handmatige tussenkomst van een gebruiker vereist om het werk gedaan te krijgen.

In onze hybride integratiecloud blog, we bespraken hoe we tegen de uitdaging aanliepen dat het gebruik van een mediatorlaag zorgde voor een beperkte verticale schaalbaarheid. Door onze eigen aangepaste non-blocking verbindingslaag te schrijven op basis van een beveiligd HTTPS-transport, konden we de architectuur uitbreiden met een 50x grotere verticale schaal. Uiteraard is deze ook horizontaal schaalbaar. Deze combinatie van verticale en horizontale schaalbaarheid leverde ons een goedkopere en eenvoudig uitbreidbare laag op om aan onze groeiende behoeften te voldoen.

Het optimaliseren van het gebruik van gedeelde componenten:

Gedeelde componenten moeten zelf schaalbaar en hoog beschikbaar zijn om het cloudplatform te ondersteunen. Maar gedeelde componenten worden juist gedeeld en zijn daardoor niet zo schaalbaar als de servicelaag. Het is erg belangrijk om extra aandacht te besteden aan bepaalde componenten die gevoelig kunnen zijn voor een hoge belasting, zoals databases. Een mogelijke aanpak is het prioriteren en in de wachtrij plaatsen van de usage van gedeelde componenten wanneer meerdere, gelijktijdige verzoeken met een hoog volume problemen kunnen veroorzaken. Prioritering kan de belasting verlagen en fouten bij bedrijfskritische verzoeken beperken.   Terugkomend op ons restaurant: de keuken is een gedeelde component en hoewel de ober de bestelling van een gast voor een voorgerecht, hoofdgerecht en dessert kan opnemen, zal de keuken prioriteit toekennen aan het bereiden van deze gerechten en de belasting evenwichtig verdelen.

Een andere manier om de belasting aan te pakken, is het in de cache opslaan van gegevens die zelden veranderen, om zo te voorkomen dat de usage van die componenten te hoog wordt. Als frietjes een populair gerecht op het menu zijn, kan het restaurant besluiten om een doorlopende partij in de cache op te slaan in plaats van ze per bestelling te bakken.

Monitoring van componenten:

Ten slotte is het erg belangrijk om elk onderdeel te bewaken en de beperkingen ervan te kennen. Het systeem moet in staat zijn om de bandbreedte automatisch en op het juiste moment te vergroten om de systemen operationeel te houden volgens de behoeften van het cloudplatform. Monitoring kan extern of door de applicatie worden gestart, maar in beide gevallen is het uiteindelijke doel om het systeem automatisch te laten schalen op basis van de belasting.

In de volgende blog-blogpost zullen we het hebben over monitoring, logboekregistratie en andere onderdelen van de architectuur.