Tech Talk-serie: Arkitektur til skalering i din multitenant-sky

Hos Jitterbit er det vores mission at forenkle selv de mest komplekse udfordringer inden for konnektivitet og gøre det muligt for alle at oprette forbindelse i dagens digitale verden. Selvom vi understreger, at man ikke behøver at være udvikler for at bruge Jitterbits produkter, står der bag enhver fremragende softwareløsning et team af fantastiske udviklere.   I serien Jitterbit Tech Talk blog giver medlemmer af Jitterbits udviklerteam os indblik i opbygningen af en cloudplatform i enterprise-klassen og de udfordringer, de måtte løse i forbindelse med multi-tenancy, skalerbarhed og sikkerhed.

Denne uge ser Pankaj Arora, vores Sr. Director of Technology, nærmere på, hvordan man designer og opbygger en yderst skalerbar cloud-platform i virksomhedsklasse.

Skyen tilbyder virksomheder en kraftfuld måde at levere deres produkter og tjenester på, som er nemme at tilgå hvor som helst og på enhver enhed. Den giver også enorme fordele for leverandøren, herunder indsigt i, hvordan deres løsning bruges, hurtig udvikling og udrulning samt generelle reduktioner i IT- og vedligeholdelsesomkostninger. Som et resultat heraf ønsker næsten enhver virksomhed i dag at gøre deres løsninger tilgængelige i skyen.

Men der er meget mere i at blive en rigtig sky-virksomhed end bare at installere software på en hostet server og klistre “Cloud” på dine marketingmaterialer.

Jeg talte for nylig med en teknologistrateg, som bemærkede, at omkring 75% af virksomhederne gerne vil flytte deres ældre virksomhedsløsninger over i skyen. Overraskende nok udarbejder 90% af dem en indledende plan, der bygger på en arkitektur, hvor deres eksisterende applikationer blot skal implementeres på en offentligt tilgængelig cloud-server. Denne tilgang ophæver alle de fordele, som cloud-løsninger har at byde på.

Opbygning af en ægte multitenant-skyplatform kræver løsning af en række forskellige udfordringer såsom sikkerhed, pålidelighed, skalerbarhed, høj tilgængelighed, fejltolerance, logning, overvågning, adviseringstjeneste, kapacitet til kontinuerlig udrulning og mere.

I dagens indlæg vil vi se nærmere på, hvordan vi håndterede ‘skalerbarheids’-udfordringen under udviklingen af vores multi-tenant cloud-integrationsplatform.

Omfanget af en applikations skalerbarheid er knyttet til dens evne til at skalere vertikalt og horisontalt. I et sky-miljø betyder dette at designe tjenester, der betjener eksterne forespørgsler, som kan skalere, så de kan udnytte interne backendsystemer såsom databaser, cacher, mellemlag, batchprocesser (analytisk motor, anbefalingsmotor) osv. til at håndtere praktisk talt uendelige forespørgsler på rimelig kort tid. Det er ikke altid muligt at forudsige antallet af brugere, der tilgår din platform. At designe en arkitektur, der tager højde for dette i multi-tenancy-modellen, er med til at gøre denne usikkerhed til et generelt skalerbarhedsproblem.

Vertikal skalering

Vertikal skalerbarhed indebærer at tilføje ressourcer som yderligere CPU'er eller hukommelse til en enkelt node i et system, og dette bør være det første, du tænker på, når du skal skalere dine tjenester. Det er meget vigtigt at designe dine applikationer, så de udnytter disse ressourcer optimalt. Tag det almindelige use case for vores hybride integrationsskyplatform, hvor integrationshandlinger betjenes af en on-premise- eller sky-servernode. Her bør tjenesterne modtage en anmodning om at køre integrationer, sende anmodningen videre til servernoder og fortsætte med at betjene flere anmodninger. Tjenestelaget bør ikke være afhængigt af eller blokeret af de processer, der foregår på systemets forskellige lag. Som sådan er det meget vigtigt at have en asynkron, hændelsesstyret arkitektur.

En simpel måde at forstå asynkron arkitektur på er at tænke på din arkitektur som en restaurant. En tjener tager imod bestillinger fra et bord og giver dem videre til kokken. Mens kokken, madbringeren og oprydderen tager sig af aktiviteter som madlavning, servering og rengøring, fortsætter tjeneren med at betjene nye kunder og foretage afregninger ved slutningen af serveringen.

Det er meget vigtigt at opretholde asynkronitet, mens systemet arbejder med alle komponenterne såsom database, cache og mediatorlag. Ved at overføre belastningen til klyngedannede, højtilgængelige servernoter, der kører integrationer, frigøres ressourcer, så servicelaget kan modtage flere forespørgsler og svare, når processerne er fuldført.

Horisontal skalering

Den næste centrale overvejelse bør være, at tjenesterne er skrevet på en sådan måde, at det ikke bør spille nogen rolle, hvor mange instanser af disse tjenester der kører, og hvilket delt system der udfører transaktioner på et givet tidspunkt. Dette giver vores cloud-platform fleksibilitet til automatisk at skalere tjenestelaget. Hver del af backenden er højt tilgængelig og kan skaleres automatisk for at følge med efterspørgslen fra voksende tjenestecontainere.

Vi kan dog ikke have uendeligt mange containere, der kører servicelag, som bruger delte komponenter. Det er ikke det optimale design. Lad os vende tilbage til vores restauranteksempel. Med vertikal skalering kunne en enkelt restaurant blive meget skalerbar ved at tilføje mere personale, men på et vist tidspunkt vil antallet af ressourcer (kokke, løbere, opryddere) nå et mætningspunkt. For at skalere yderligere ville denne virksomhed være nødt til at åbne yderligere lokationer, som kan hjælpe med at fordele kunderne og balancere belastningen.

Det er bedre at opdele hele platformen i flere zoner, hvor hver zone fungerer som en replika af den oprindelige zone. Dette gør det muligt for os at bruge flere zoner til at balancere fremtidige belastninger.

Denne model har flere fordele:

1. Mulig uendelig horisontal skalering, da vi kan tilføje et vilkårligt antal zoner

2. Fejltolerance, hvis hele zonen svigter på grund af en naturkatastrofe

3. Dataseparation i tilfælde af en SaaS-platform, der kræver endog lokationsbaseret metadatasegregation, såsom for US-, EMEA-zoner osv.

Det ønskede resultat her er, at en brugers oplevelse skal være den samme uanset hvor de er, og hvilken zone de rammer. Ingen manuel indgriben bør være påkrævet fra en bruger for at få arbejdet gjort.

I vores hybrid integrationscloud blog, diskuterte vi, hvordan vi stødte på udfordringen ved at bruge et mellemmands-lag på en måde, der understøttede begrænset vertikal skalering. Ved at skrive vores eget tilpassede ikke-blokerende forbindelseslag baseret på sikker HTTPS-transport var vi i stand til at udvide arkitekturen til at have 50x vertikal skalering. Den er naturligvis også horisontalt skalerbar. Denne kombination af vertikal og horisontal skalering gav os et mindre dyrt og let udvideligt lag til at imødekomme vores voksende behov.

Optimering af brugen af delte komponenter:

Delte komponenter bør i sig selv være skalerbare og have høj tilgængelighed for at understøtte cloud-platformen. Men delte komponenter er netop delte og er derfor ikke lige så skalerbare som tjenestelaget. Det er meget vigtigt at være opmærksom på visse komponenter, der kan være følsomme over for stor belastning, for eksempel databaser. En model kan være at prioritere og sætte usage for delte komponenter i kø, hvor flere samtidige forespørgsler med høj volumen kan forårsage problemer. Prioritering kan reducere belastningen og mindske fejl på alle missionskritiske anmodninger.   Tilbage i vores restaurant er køkkenet en delt komponent, og selvom tjeneren tager imod en gæsts bestilling af forret, hovedret og dessert, vil køkkenet prioritere tilberedningen af disse retter og afbalancere belastningen.

En anden måde at håndtere belastningen på kan være at gemme data, der sjældent ændres, i cachen for at undgå en høj usage for disse komponenter. Hvis pommes frites er en populær ret på menuen, kan restauranten vælge at “gemme” et kontinuerligt parti i cachen i stedet for at stege dem efter bestilling.

Overvågning af komponenter:

Endelig er det meget vigtigt at overvåge hver enkelt komponent og kende dens begrænsninger. Systemet bør være i stand til at øge båndbredden automatisk og på det rigtige tidspunkt for at holde systemerne kørende i overensstemmelse med Cloud-platformens behov. Overvågning kan være ekstern eller applikationsinitieret, men i begge tilfælde er det endelige mål at lade systemet auto-skalere baseret på belastningen.

I det næste indlæg om blog vil vi tale om overvågning, logning og andre elementer i arkitekturen.