Tech Talk-serie: Arkitektur for skalering i din fleretters sky

Hos Jitterbit er vårt mål å forenkle selv de mest komplekse tilkoblingsutfordringene og å gjøre det mulig for alle å koble seg til i dagens digitale verden. Selv om vi understreker at man ikke trenger å være utvikler for å bruke Jitterbits produkter, står det et team av fantastiske utviklere bak hver eneste gode programvareløsning.   I serien «Jitterbit Tech Talk blog» gir medlemmer av Jitterbits utviklingsteam oss innblikk i hvordan man bygger en skyplattform i enterpriseklasse, samt utfordringene de måtte løse knyttet til flerbrukerfunksjonalitet, skalerbarhet og sikkerhet.

Denne uken ser Pankaj Arora, vår Sr. Director of Technology, på hvordan du designer og arkitekter en svært skalerbar skyplattform i bedriftsklasse.

Skyen tilbyr selskaper en kraftig måte å tilby sine produkter og tjenester på, som er enkle å få tilgang til fra hvor som helst og på hvilken som helst enhet. Den gir også enorme fordeler for leverandøren, inkludert innsikt i hvordan tilbudet deres brukes, rask utvikling og utrulling, og generelle reduksjoner i IT- og vedlikeholdskostnader. Som et resultat ønsker nesten alle bedrifter i dag å gjøre løsningene sine tilgjengelige i skyen.

Men det skal mer til for å bli et ekte nettskybedrift enn å installere programvare på en vertstjener og klistre “Sky” på markedsføringsmateriell.

Jeg snakket nylig med en teknologistrateg, og vedkommende påpekte at rundt 75% av bedriftene ønsker å migrere sine eldre bedriftsløsninger til skyen. Overraskende nok utarbeider 90% av dem en innledende plan basert på en arkitektur der de gamle applikasjonene bare skal distribueres på en offentlig tilgjengelig skyserver. Denne tilnærmingen undergraver alle fordelene som skyen har å tilby.

Bygging av en ekte flertjeners skyplattform krever løsning av en rekke ulike typer utfordringer som sikkerhet, pålitelighet, skalerbarhet, høy tilgjengelighet, feiltoleranse, loggførring, overvåking, varslingssystem, kapasitet for kontinuerlig utrulling og mer.

I dagens innlegg skal vi se nærmere på hvordan vi håndterte ‘skalerbarhet’-utfordringen da vi utviklet vår multileier skyintegrasjonsplattform.

Omfanget av skalerbarheten til en applikasjon er knyttet til dens evne til å skalere vertikalt og horisontalt. I et skybasert miljø betyr dette å designe tjenester som betjener eksterne forespørsler og som skalerer slik at de kan utnytte interne backend-systemer som databaser, mellomlagring (cachen), mellomalierende lag, batch-prosesser (analytisk motor, anbefalingsmotor) osv. for å håndtere praktisk talt uendelig mange forespørsler på en rimelig kort tid. Det er ikke alltid mulig å forutsi antall brukere som treffer plattformen din. Å designe en arkitektur som tar høyt for dette i flermodeller (multi-tenancy-modellen) bidrar til å gjøre denne usikkerheten til et generelt skalerbarhetsproblem.

Skalering oppover

Vertikal skalerbaarheid innebærer å legge til ressurser som ekstra CPU-er eller minne til en enkelt node i et system, og dette bør være det første du tenker på når du skal skalere tjenestene dine. Det er svært viktig å designe applikasjonene dine slik at de utnytter disse ressursene optimalt. Tenk på det vanlige brukstilfellet for vår hybride integrasjonsskyplattform, der integrasjonsoperasjoner betjenes av en lokal servernode eller en skybasert servernode. Her bør tjenestene motta en forespørsel om å kjøre integrasjoner, videresende forespørselen til servernoder og fortsette å betjene flere forespørsler. Tjenestelaget bør ikke være avhengig av, eller blokkert av, prosessene som foregår på ulike lag i systemet. Som sådan er det svært viktig å ha en asynkron, hendelsesdrevet arkitektur.

En enkel måte å forstå asynkron arkitektur på er å tenke på arkitekturen din som en restaurant. En servitør tar imot bestillinger fra et bord og gir dem videre til kokken. Mens kokken, matutbringeren og ryddehjelpen tar seg av oppgaver som matlaging, servering og rydding, fortsetter servitøren å betjene nye kunder og sjekker regningen ved slutten av servicen.

Det er svært viktig å opprettholde asynkronitet mens systemet arbeider med alle komponentene som database, mellomlager og mediatorlag. Å overføre last til klyngede, høyt tilgjengelige tjenerserverenheter som kjører integrasjoner, frigjør ressurser slik at tjenestelaget kan motta flere forespørsler og svare når prosessene er fullført.

Horisontal skalering

Den neste viktige hensikten bør være at tjenestene er skrevet på en slik måte at det ikke skal spille noen rolle hvor mange instanser av disse tjenestene som kjører, og hvilket delt system som utfører transaksjoner til en hver tid. Dette gir skyplattformen vår fleksibilitet til å skalere tjenestelaget automatisk. Hver del av backend-en er svært tilgjengelig og autoskalerbar for å holde tritt med etterspørselen fra voksende tjenestebeholdere.

Vi kan imidlertid ikke ha et uendelig antall containere som kjører tjenestelag som bruker delte komponenter. Det er ikke den optimale designen. La oss gå tilbake til restauranteksempelet vårt. Med vertikal skalering kan en enkelt restaurant bli svært skalerbar ved å legge til mer personale, men på et visst tidspunkt vil antall ressurser (kokker, servitører, ryddehjelpere) nå et metningspunkt. For å skalere ytterligere, må denne virksomheten åpne flere steder som vil bidra til å distribuere kundene og balansere lasten.

Det er bedre å dele hele plattformen inn i flere soner, der hver sone fungerer som en replika av den opprinnelige sonen. Dette gjør at vi kan bruke flere soner til å balansere fremtidige behov.

Denne modellen har flere fordeler:

1. Mulig uendelig horisontal skalering, siden vi kan ta inn et vilkårlig antall soner

2. Feiltoleranse, i tilfelle hele sonen svikter på grunn av en naturkatastrofe

3. Dataseparasjon, i tilfelle en SaaS-plattform som krever til og med lokasjonsbasert metadatasegregering, slik som for US-, EMEA-soner osv.

Det ønskede resultatet her er at en brukers opplevelse skal være den samme uavhengig av hvor de befinner seg og hvilken sone de treffer. Ingen manuell inngripen skal være nødvendig fra en bruker for å få arbeidet gjort.

I vår hybrid integrasjon i skyen blog, diskuterte vi hvordan vi støtte på utfordringen med å bruke et mellomalderlag (mediator layer) på en måte som støttet begrenset vertikal skalerbarhet. Ved å skrive vårt eget tilpassede ikke-blokkerende tilkoblingslag basert på sikker HTTPS-transport, klarte vi å utvide arkitekturen til å ha 50 ganger vertikal skala. Den er naturligvis også horisontalt skalerbar. Denne kombinasjon av vertikal og horisontal skalerbarhet ga oss et billigere og enkelt utvidbart lag for å møte våre voksende behov.

Optimalisering av bruken av delte komponenter:

Delt komponenter bør i seg selv være skalerbare og ha høy tilgjengelighet for å støtte skyplattformen. Men delte komponenter er nettopp delte, og er derfor ikke like skalerbare som tjenestelaget. Det er svært viktig å ta hensyn til enkelte komponenter som kan være følsomme for høy belastning, for eksempel databaser. En mulig modell kan være å prioritere og sette usage av delte komponenter i kø der flere samtidige forespørsler med høy belastning kan forårsake problemer. Prioritering kan redusere belastningen og minimere feil ved oppdragskritiske forespørsler.   Tilbake i restauranten vår er kjøkkenet en delt komponent, og mens servitøren kan ta imot en gjestes bestilling av forrett, hovedrett og dessert, vil kjøkkenet prioritere tilberedningen av disse rettene og balansere belastningen mellom dem.

En annen måte å håndtere belastningen på er å lagre data som sjelden endres i hurtigbufferen, for å unngå høy usage for disse komponentene. Hvis pommes frites er en populær rett på menyen, kan restauranten velge å “lagre” et kontinuerlig parti i hurtigbufferen i stedet for å steke dem etter bestilling.

Overvåking av komponenter:

Til slutt er det svært viktig å overvåke hver komponent og kjenne til dens begrensninger. Systemet bør være i stand til å øke båndbredden automatisk og til rett tid for å holde systemene i gang i henhold til behovene til skyplattformen. Overvåking kan være ekstern eller applikasjonsinitiert,但 i begge tilfeller er det endelige målet å la systemet skalerer automatisk basert på belastningen.

I neste blog-innlegg skal vi snakke om overvåking, loggføring og andre elementer i arkitekturen.