Hos Jitterbit er vår oppgave å forenkle selv de mest komplekse tilkoblingsutfordringene og å la hvem som helst få kontakt i dagens digitale verden. Selv om vi understreker at du ikke trenger å være en utvikler for å bruke Jitterbits produkter – bak enhver flott programvareløsning står et team av fantastiske utviklere. I Jitterbit Tech Talk blog serien gir medlemmer av Jitterbits utviklingsteam oss innsikt i å bygge en skyplattform i bedriftsklassen og utfordringene de måtte løse rundt multi-tenancy, skalerbarhet og sikkerhet.
Denne uken ser Pankaj Arora, vår seniordirektør for teknologi på hvordan du designer og arkitekterer en svært skalerbar skyplattform i bedriftsklassen.
Skyen tilbyr bedrifter en kraftig måte å tilby sine produkter og tjenester som er enkle å få tilgang til fra hvor som helst og på hvilken som helst enhet. Det gir også enorme fordeler for leverandøren, inkludert innsyn i hvordan tilbudet deres brukes, rask utvikling og distribusjon og generelle reduksjoner i IT- og vedlikeholdskostnader. Som et resultat, nesten hver company i dag er ute etter å gjøre sine løsninger tilgjengelige i skyen.
Men det er mye mer å bli en ekte sky company enn å installere programvare på en vertsserver og slå "Cloud" på markedsføringsmateriellet ditt.
Jeg pratet nylig med en teknologistrateg, og de la merke til at rundt 75 % av bedriftene ønsker å migrere sine eldre bedriftstilbud til skyen. Overraskende nok lager 90 % av dem en innledende plan som vil bygges på en arkitektur der deres eldre applikasjoner bare vil bli distribuert på en offentlig tilgjengelig skyserver. Denne tilnærmingen negerer alle fordelene skyen har å tilby.
Å bygge en ekte multi-tenant Cloud-plattform krever å løse en rekke forskjellige typer utfordringer som sikkerhet, pålitelighet, skalerbarhet, høy tilgjengelighet, feiltoleranse, logging, overvåking, varslingssystem, evne til kontinuerlig distribusjon og mer.
I dagens innlegg vil vi ta en dypere titt på hvordan vi håndterte «skalerbarhets»-utfordringen da vi utviklet vår skyintegrasjonsplattform for flere leietakere.
Omfanget av skalerbarheten til en applikasjon er knyttet til dens evne til å skalere vertikalt og horisontalt. I et skymiljø betyr dette å designe tjenester som betjener eksterne forespørsler som skaleres slik at de kan utnytte interne backend-systemer som databaser, cacher, mediatorlag, batchprosesser (analytisk motor, anbefalingsmotor) osv. for å håndtere praktisk talt uendelige forespørsler på en rimelig måte kort tid. Det er ikke alltid mulig å forutsi antall brukere som treffer plattformen din. Å designe en arkitektur som tar høyde for dette i multi-tenancy-modellen, bidrar til å gjøre denne usikkerheten til et generisk skalerbarhetsproblem.
Vertikal skalering
Vertikal skalerbarhet innebærer å legge til ressurser som ekstra CPUer eller minne til en enkelt node i et system, og dette bør være det første du tenker på når du skalerer tjenestene dine. Det er svært viktig å designe applikasjonene dine slik at de utnytter disse ressursene optimalt. Ta den vanlige brukssaken for vår hybride skyplattform for integrering, der integrasjonsoperasjoner betjenes av lokal eller skyservernode. Her bør tjenestene ta en forespørsel om å kjøre integrasjoner, sende forespørselen til servernoder og fortsette å betjene flere forespørsler. Tjenestelaget skal ikke være avhengig av eller blokkert av prosessene som skjer på ulike lag av 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 kelner tar imot bestillinger fra et bord og gir det til kokken. Mens kokken, matløperen og bussgutten tar seg av aktiviteter som matlaging, servering og rydding, fortsetter servitøren å betjene nye kunder og kjører sjekker på slutten av tjenesten.
Å opprettholde asynkronitet mens systemet fungerer med alle komponentene som database, cache og mediatorlag er veldig viktig. Ved å overføre belastning til grupperte, svært tilgjengelige servernoder som kjører integrasjoner, frigjøres ressursene for tjenestelaget til å ta flere forespørsler og svare når prosessene er fullført.
Horisontal skalering
Den neste viktige vurderingen bør være at tjenestene er skrevet på en måte at det ikke bør ha noen betydning hvor mange forekomster av disse tjenestene som kjører, og hvilket delt system som utfører transaksjoner til enhver tid. Dette gir vår skyplattform fleksibilitet til å automatisk skalere tjenestelaget. Hver del av backend er svært tilgjengelig og automatisk skalerbar for å holde tritt med etterspørselen etter voksende tjenestecontainere.
Vi kan imidlertid ikke ha uendelige beholdere som kjører tjenestelag som bruker delte komponenter. Det er ikke det optimale designet. La oss gå tilbake til restauranteksemplet vårt. Med vertikal skalering kan en enkelt restaurant bli svært skalerbar ved å legge til flere ansatte, men på et visst tidspunkt vil antall ressurser (kokker, løpere, bussgutter) nå et metningspunkt. For å skalere videre, må denne virksomheten åpne flere lokasjoner som vil hjelpe distribuere kunder og balansere belastningen.
Det er bedre å dele hele plattformen i flere soner, der hver sone oppfører seg som en kopi av den opprinnelige sonen. Dette lar oss bruke flere soner for å balansere fremtidige behov.
Denne modellen har flere fordeler:
1. Mulig uendelig horisontal skalering, da vi kan få inn et hvilket som helst antall soner
2. Feiltoleranse, i tilfelle hele sonen svikter på grunn av en naturkatastrofe
3. Dataseparasjon, i tilfelle av en SaaS-plattform som krever til og med stedsbasert metadatasegregering som for USA, EMEA-soner, etc.
Det ønskede resultatet her er at en brukers opplevelse skal være den samme uansett hvor de er og hvilken sone de treffer. Ingen manuell inngripen bør kreves fra en bruker for å få arbeidet gjort.
I vår hybrid integrasjonssky blog, diskuterte vi hvordan vi møtte utfordringen med å bruke et mediatorlag på en måte som støttet begrenset vertikal skala. Ved å skrive vårt eget tilpassede ikke-blokkerende tilkoblingslag basert på sikker HTTPS-transport kunne vi utvide arkitekturen til å ha 50x vertikal skala. Selvfølgelig er det horisontalt skalerbart også. Denne kombinasjonen av vertikal og horisontal skalering ga oss et rimeligere og lett utvidbart lag for å møte våre økende behov.
Optimalisering av bruken av delte komponenter:
Delte komponenter bør i seg selv være skalerbare og svært tilgjengelige for å støtte Cloud-plattformen. Men delte komponenter deles, og er som et resultat ikke like skalerbare som tjenestelaget. Det er svært viktig å ta vare på noen komponenter som kan være følsomme for høy belastning, for eksempel databaser. En modell kan være å prioritere og sette i kø bruken av delte komponenter der flere, samtidige høyvolumsbelastninger kan forårsake problemer. Prioritering kan redusere belastningen og redusere feil på alle oppdragskritiske forespørsler. Tilbake i restauranten vår er kjøkkenet en delt komponent, og mens servitøren kan ta imot en middagsbestilling på en forrett, hovedrett og dessert, vil kjøkkenet prioritere matlagingen av disse tingene og balansere belastningen.
En annen måte å adressere belastning på kan være caching av data som sjelden endres for å forhindre høy bruk av disse komponentene. Hvis pommes frites er et populært element på menyen, kan restauranten bestemme seg for å "cache" en kontinuerlig batch i stedet for å steke dem på bestilling.
Overvåking av komponenter:
Til slutt er det veldig viktig å overvåke hver komponent og kjenne dens begrensninger. Systemet skal kunne øke båndbredden automatisk og til rett tid for å holde systemene oppe og kjøre i henhold til behovene til Cloud-plattformen. Overvåking kan være eksternt eller applikasjonsinitiert, men i begge tilfeller er det endelige målet å la systemet autoskalere basert på belastningen.
I neste blog innlegg, vil vi snakke om overvåking, logging og andre elementer i arkitekturen.
