Tech Talk-serien: Arkitektur för skalbarhet i ditt flertenanta moln

Hos Jitterbit är vårt uppdrag att förenkla även de mest komplexa utmaningarna när det gäller anslutning och att göra det möjligt för vem som helst att ansluta sig till dagens digitala värld. Även om vi betonar att man inte behöver vara utvecklare för att använda Jitterbits produkter – så finns det bakom varje bra mjukvarulösning ett team av fantastiska utvecklare.   I serien Jitterbit Tech Talk blog ger medlemmar i Jitterbits utvecklingsteam en inblick i hur man bygger en molnplattform i företagsklass och vilka utmaningar de har fått lösa när det gäller multitenancy, skalbarhet och säkerhet.

Den här veckan tittar Pankaj Arora, vår Sr. Director of Technology, på hur man designar och arkitekterar en mycket skalbar molnplattform av företagsklass.

Molnet erbjuder företag ett kraftfullt sätt att erbjuda sina produkter och tjänster som är lättillgängliga var som helst och på vilken enhet som helst. Det ger också enorma fördelar för leverantören, inklusive insyn i hur deras utbud används, snabb utveckling och driftsättning samt övergripande minskningar av IT- och underhållskostnader. Som ett resultat vill nästan varje företag idag göra sina lösningar tillgängliga i molnet.

Men det krävs mycket mer för att bli ett sant molnföretag än att installera programvara på en värdbaserad server och klistra “Moln” på ditt marknadsföringsmaterial.

Jag pratade nyligen med en teknikstrateg som påpekade att omkring 75% av företagen skulle vilja migrera sina äldre företagslösningar till molnet. Överraskande nog utarbetar 90% av dem en inledande plan som bygger på en arkitektur där deras äldre applikationer helt enkelt skulle driftsättas på en allmänt tillgänglig molnserver. Denna strategi motverkar alla fördelar som molnet har att erbjuda.

Att bygga en äkta flertenarbaserad molnplattform kräver att man löser ett antal olika typer av utmaningar som säkerhet, tillförlitlighet, skalbarhet, hög tillgänglighet, felaktighetstålighet, loggning, övervakning, aviseringssystem, kapacitet för kontinuerlig distribution med mera.

I dagens inlägg tar vi en närmare titt på hur vi hanterade ‘skalbarhetsutmaningen’ när vi utvecklade vår multitenant-molnintegrationsplattform.

Skalbarheten hos en applikation är knuten till dess förmåga att skalas uppåt (vertikalt) och utåt (horisontellt). I en molnmiljö innebär detta att man utformar tjänster som hanterar externa anrop och som kan skalas för att utnyttja interna bakgrundssystem som databaser, cachar, mäklarlager, batchprocesser (analysmotorer, rekommendationsmotorer) etc. för att hantera i praktiken oändliga förfrågningar på rimligt kort tid. Det är inte alltid möjligt att förutsäga antalet användare som kommer till din plattform. Att utforma en arkitektur som tar hänsyn till detta i en modell för fleranvändarmiljö (multi-tenancy) bidrar till att göra denna osäkerhet till ett generellt skalbarhetsproblem.

Vertikal skalning

Vertikal skalbarhet innebär att man lägger till resurser som ytterligare processorer eller minne till en enskild nod i ett system, och detta bör vara det första du tänker på när du skalar dina tjänster. Det är mycket viktigt att utforma dina applikationer så att de utnyttjar dessa resurser optimalt. Tänk på det vanliga användningsfallet för vår hybrida integrationsmolnplattform, där integrationstjänster hanteras av en lokal eller molnbaserad servernod. Här bör tjänsterna ta emot en begäran om att köra integrationer, skicka begäran vidare till servernoder och fortsätta att hantera fler förfrågningar. Tjänstelagret bör inte vara beroende av, eller blockeras av, de processer som sker i systemets olika lager. Därför är det mycket viktigt att ha en asynkron, händelsedriven arkitektur.

Ett enkelt sätt att förstå asynkron arkitektur är att tänka på din arkitektur som en restaurang. En servitör tar emot beställningar från ett bord och skickar dem vidare till kocken. Medan kocken, matutköraren och plockaren tar hand om aktiviteter som matlagning, servering och städning, fortsätter servitören att betjäna nya kunder och göra notan i slutet av sittningen.

Att upprätthålla asynkroncitet medan systemet arbetar med alla komponenter som databas, cache och mediatorlager är mycket viktigt. Att skicka vidare belastning till klustrade, hötillgängliga servernoder som kör integrationer frigör resurser för tjänstelagret att ta emot fler förfrågningar och svara när processerna är slutförda.

Horisontell skalning

Nästa viktiga övervägande bör vara att tjänsterna är utformade på ett sådant sätt att det inte spelar någon roll hur många instanser av dessa tjänster som körs, och vilket delat system som utför transaktioner vid en given tidpunkt. Detta ger vår molnplattform flexibilitet att skalautomatiskt för tjänstlagret. Varje del av the backend är högavailable och skalbar automtiskt för att hänga med efterfrågan av växande tjänstcontainrar.

Vi kan dock inte ha oändligt många containrar som kör tjänstelager som använder delade komponenter. Det är inte en optimal design. Låt oss återgå till vårt restaurangexempel. Med vertikal skalning kan en enskild restaurang bli mycket skalbar genom att lägga till mer personal, men vid en viss tidpunkt kommer antalet resurser (kockar, springpojkar, avplockare) att nå en mättnadspunkt. För att skala ytterligare skulle den här verksamheten behöva öppna ytterligare enheter som hjälper till att fördela gästerna och balansera lasten.

Det är bättre att dela upp hela plattformen i flera zoner, där varje zon fungerar som en replik av den ursprungliga zonen. Detta gör att vi kan använda flera zoner för att lastbalansera framtida behov.

Den här modellen har flera fördelar:

1. Möjlig oändlig horisontell skalning, eftersom vi kan lägga till valfritt antal zoner

2. Felaktighetstolerans, om hela zonen skulle slås ut på grund av en naturkatastrof

3. Dataseparation, när det gäller en SaaS-plattform som kräver även platsbaserad metadatasegregering, till exempel för US-, EMEA-zoner etc.

Det önskade resultatet här är att en användares upplevelse ska vara densamma oavsett var de befinner sig och vilken zon de ansluter till. Ingen manuell insats ska krävas av en användare för att få arbetet utfört.

I vår hybridintegration i molnet blog, diskuterade vi hur vi stötte på utmaningen att använda ett medlarskikt på ett sådant sätt att det stödde begränsad vertikal skalning. Genom att skriva vårt eget anpassade icke-blockerande anslutningslager baserat på säker HTTPS-transport kunde vi utöka arkitekturen till att få 50 gånger vertikal skalning. Den är naturligtvis även horisontellt skalbar. Denna kombination av vertikal och horisontell skalning gav oss ett billigare och lätt utbyggbart skikt för att möta våra växande behov.

Optimering av användningen av delade komponenter:

Delade komponenter bör i sig vara skalbara och ha hög tillgänglighet för att stödja molnplattformen. Men eftersom delade komponenter just är delade är de inte lika skalbara som tjänstelagret. Det är mycket viktigt att ta hänsyn till vissa komponenter som kan vara känsliga för hög belastning, till exempel databaser. En modell kan vara att prioritera och köa usage för delade komponenter där flera samtidiga högvolymsbelastningar kan orsaka problem. Prioritering kan minska belastningen och mildra fel på alla affärskritiska förfrågningar.   Om vi återvänder till vår restaurang är köket en delad komponent, och även om servitören tar emot en gästs beställning av förrätt, huvudrätt och efterrätt, kommer köket att prioritera tillagningen av dessa rätter och balansera belastningen mellan dem.

Ett annat sätt att hantera belastningen kan vara att lagra data som sällan ändras i cacheminnet för att undvika ett högt usage-värde för dessa komponenter. Om pommes frites är en populär rätt på menyn kan restaurangen välja att “lagra” en kontinuerlig sats i cacheminnet istället för att steka dem efter beställning.

Övervakning av komponenter:

Slutligen är det mycket viktigt att övervaka varje komponent och känna till dess begränsningar. Systemet bör kunna öka bandbredden automatiskt och vid rätt tidpunkt för att hålla systemen igång i enlighet med molnplattformens behov. Övervakningen kan vara extern eller applikationsinitierad, men i båda fallen är det slutliga målet att låta systemet skalas automatiskt baserat på belastningen.

I nästa inlägg om blog kommer vi att ta upp övervakning, loggning och andra delar av arkitekturen.