Teknologiakeskustelusarja: Skaalautuvuuden suunnittelu monivuokralaisessa pilvessäsi

Jitterbitillä tehtävämme on yksinkertaistaa jopa kaikkein monimutkaisimpia yhteyshaasteita ja mahdollistaa kaikille yhteys nykypäivän digitaaliseen maailmaan. Vaikka korostammekin, ettei Jitterbitin tuotteiden käyttämiseen tarvitse olla kehittäjä – jokaisen loistavan ohjelmistoratkaisun takana on joukko upeita kehittäjiä.   Jitterbit Tech Talk blog -sarjassa Jitterbitin kehitystiimin jäsenet antavat meille näkemyksiä yritystason pilvialustan rakentamisesta sekä haasteista, joita heidän piti ratkaista monikäyttöisyyden, skaalautuvuuden ja tietoturvan suhteen.

Tällä vikolla teknologiajohtajamme (Sr. Director of Technology) Pankaj Arora tarkastelee, miten erittäin skaalautuva yritystason pilvialusta suunnitellaan ja arkkitehtoidaan.

Pilvipalvelut tarjoavat yrityksille tehokkaan tavan tarjota tuotteitaan ja palveluitaan, joita on helppo käyttää mistä tahansa ja millä tahansa laitteella. Se tarjoaa myös valtavia etuja myyjälle, mukaan lukien näkyvyyden tarjonnan käyttöön, nopean kehityksen ja käyttöönoton sekä IT- ja ylläpitokustannusten kokonaisvähennykset. Tämän seurauksena lähes jokainen yritys pyrkii nykyään tuomaan ratkaisunsa pilveen.

Mutta todelliseksi pilviyritykseksi tulemisessa on paljon enemmän kuin vain ohjelmiston asentaminen isännöidylle palvelimelle ja “Pilvi”-sanan lätkäiseminen markkinointimateriaaleihin.

Keskustelin äskettäin erään teknologiastrategin kanssa, ja hän totesi, että noin 75% yrityksistä haluaisi siirtää vanhat yrityssovelluksensa pilvipalveluun. Yllättäen 90% niistä laatii alustavan suunnitelman, joka perustuisi arkkitehtuuriin, jossa vanhat sovellukset vain asennettaisiin julkisesti saatavilla olevaan pilvipalvelimeen. Tämä lähestymistapa mitätöi kaikki pilvipalvelun tarjoamat edut.

Aidosti monen vuokralaisen (multi-tenant) pilvialustan rakentaminen vaatii monenlaisten haasteiden ratkaisua, kuten turvallisuuden, luotettavuuden, skaalautuvuuden, korkean käytettävyyden, vikasietoisuuden, lokituksen, seurannan, ilmoitusjärjestelmän, jatkuvan oheistuksen (deployment) valmiudet ja paljon muuta.

Tämän päivän julkaisussa tarkastelemme lähemmin, miten ratkaisimme skaalautuvuushaasteen kehittäessämme moniasiakaspohjaista pilvi-integraatioalustaamme.

Sovelluksen skaalautuvuuden laajuus on sidoksissa sen kykyyn skaalautua pysty- ja vaakasuunnassa. Pilviympäristössä tämä tarkoittaa sellaisten ulkoisia pyyntöjä palvelevien palveluiden suunnittelua, jotka skaalautuvat niin, että ne voivat hyödyntää sisäisiä taustajärjestelmiä, kuten tietokantoja, välimuisteja, välittäjäkerroksia, eräajoja (analyyttinen moottori, suositusmoottori) jne., käsitelläkseen käytännössä rajattoman määrän pyyntöjä kohtuullisen lyhyessä ajassa. Alustallesi saapuvien käyttäjien määrää ei ole aina mahdollista ennustaa. Sellaisen arkkitehtuurin suunnittelu, jossa tämä otetaan huomioon monen vuokralaisen (multi-tenancy) mallissa, auttaa tekemään tästä epävarmuudesta yleisen skaalautuvuusongelman.

PystySKAALAUS

Vertikaalinen skaalautuvuus tarkoittaa resurssien, kuten lisäsuorittimien tai muistin, lisäämistä järjestelmän yhteen solmuun, ja tämän tulisi olla ensimmäinen asia, jota ajattelet skaalatessasi palveluitasi. On erittäin tärkeää suunnitella sovellukset niin, että ne hyödyntävät näitä resursseja optimaalisesti. Otetaan hybridintegraatiopilvialustamme yleinen käyttötapaus, jossa integraatiotoiminnoista vastaa paikallinen tai pilvipalvelinsolmu. Tässä palveluiden tulisi ottaa vastaan pyyntö integraatioiden suorittamisesta, välittää pyyntö palvelinsolmuille ja jatkaa uusien pyyntöjen palvelemista. Palvelukerros ei saa olla riippuvainen järjestelmän eri kerroksissa tapahtuvista prosesseista eikä se saa estyä niiden vuoksi. Sellaisenaan on erittäin tärkeää käyttää asynkronista, tapahtumapohjaista arkkitehtuuria.

Yksinkertainen tapa ymmärtää asynkroninen arkkitehtuuri on ajatella arkkitehtuuriasi ravintolana. Tarjoilija ottaa vastaan tilaukset pöydästä ja välittää ne kokille. Samaan aikaan kun kokki, ruokajuoksija ja tarjoilija-apulainen huolehtivat toiminnoista, kuten ruoanlaitosta, tarjoilusta ja siivouksesta, tarjoilija jatkaa uusien asiakkaiden palvelemista ja hoitaa laskutuksen vuoron lopussa.

Epäsynkronisuuden ylläpitäminen järjestelmän työskennellessä kaikkien komponenttien, kuten tietokannan, välimuistin ja mediaattorikerroksen, kanssa on erittäin tärkeää. Kuorman siirtäminen klusteroiduille, erittäin käytettävissä oleville palvelinsolmuille, jotka suorittavat integraatioita, vapauttaa resursseja palvelukerrokselle ottamaan vastaan enemmän pyyntöjä ja vastaamaan prosessien valmistuttua.

Vaakasuuntainen skaalaus

Seuraava keskeinen huomioitava asia on, että palvelut on kirjoitettava siten, että sillä ei pitäisi olla väliä, kuinka monta kyseisten palveluiden ilmentymää on käynnissä ja mikä jaettu järjestelmä suorittaa tapahtumia milläkin hetkellä. Tämä antaa pilvialustallemme joustavuutta palvelukerroksen skaalaamiseen automaattisesti. Taustajärjestelmän jokainen osa on erittäin käytettävissä ja automaattisesti skaalautuva pysyäkseen kasvavien palvelukonttien kysynnän tahdissa.

Meillä ei kuitenkaan voi olla rajattomasti säiliöitä käynnissä pyörittämässä palvelukerroksia, jotka käyttävät yhteisiä komponentteja. Se ei ole optimaalinen ratkaisu. Palataan ravintolaesimerkkeihimme. Pystyskaalauksessa yhdestä ravintolasta voisi tulla erittäin skaalautuva lisäämällä henkilökuntaa, mutta tietyssä pisteessä resurssien (kokkien, tarjoilijoiden, bussipoikien) määrä saavuttaa kyllästyneen pisteen. Skaalatakseen edelleen tämän yrityksen täytyisi avata uusia toimipisteitä, jotka auttaisivat jakamaan asiakkaita ja tasapainottamaan kuormaa.

On parempi jakaa koko alusta useaan vyöhykkeeseen, joista jokainen toimii alkuperäisen vyöhykkeen kopiona. Tämä mahdollistaa usean vyöhykkeen käytömme tulevien tarpeiden kuormituksen tasapainottamiseen.

Tällä mallilla on useita etuja:

1. Mahdollinen Ääretön vaakasuora skaalaus, koska voimme tuoda minkä tahansa määrän vyöhykkeitä

2. Vikasietoisuus siltä varalta, että koko vyöhyke tuhoutuu luonnonkatastrofin seurauksena

3. Datan eriyttäminen, jos kyseessä on SaaS-alusta, joka edellyttää jopa sijaintipohjaista metadatan eriyttämistä esimerkiksi USA:n ja EMEA-alueiden välillä.

Haluttu lopputulos tässä on, että käyttäjän kokemuksen tulee olla samanlainen riippumatta siitä, missä hän on ja mitä aluetta hän käyttää. Työn tekemiseen ei saa tarvita käyttäjän manuaalista puuttumista asiaan.

Meidän hybridi-integraatiopilvi blog, keskustelimme siitä, kuinka törmäsimme haasteeseen käyttää välittäjäkerrosta tavalla, joka tuki rajoitettua pystysuuntaista skaalautuvuutta. Kirjoittamalla oman räätälöidyn ei-blokkaavan yhteyskerroksen, joka perustuu suojattuun HTTPS-siirtoon, pystyimme laajentamaan arkkitehtuuria saavuttamaan 50-kertaisen pystysuuntaisen skaalautuvuuden. Se on tietysti skaalautuva myös vaakasuunnassa. Tämä pysty- ja vaakasuuntaisen skaalautuvuuden yhdistelmä antoi meille edullisemman ja helposti laajennettavan kerroksen kasvaviin tarpeisiimme.

Jaettujen komponenttien käytön optimointi:

Jaettujen komponenttien tulisi itsessään olla skaalautuvia ja erittäin käytettävissä olevia pilvialustan tukemiseksi. Jaetut komponentit ovat kuitenkin jaettuja, minkä vuoksi ne eivät ole yhtä skaalautuvia kuin palvelutaso. On erittäin tärkeää kiinnittää huomiota tiettyihin komponentteihin, jotka voivat olla herkkiä suurelle kuormitukselle, kuten esimerkiksi tietokantoihin. Yksi malli voi olla jaettujen komponenttien usage:n priorisointi ja jonotus tilanteissa, joissa useat samanaikaiset suuret kuormitukset voivat aiheuttaa ongelmia. Priorisointi voi vähentää kuormitusta ja lieventää virheitä liiketoiminnalle kriittisissä pyynnöissä.   Palataksemme ravintolaesimerkkiin: keittiö on jaettu komponentti, ja vaikka tarjoilija ottaa asiakkaalta tilauksen alkupalasta, pääruoasta ja jälkiruoasta, keittiö priorisoi näiden ruokien valmistuksen ja tasapainottaa niiden kuormitusta.

Toinen tapa hallita kuormitusta on tallentaa välimuistiin harvoin muuttuvat tiedot, jotta kyseisten komponenttien usage-arvo ei nouse liian korkeaksi. Jos ranskalaiset perunat ovat suosittu ruokalistalla, ravintola voi päättää “tallentaa välimuistiin” jatkuvan erän sen sijaan, että ne paistettaisiin tilauksesta.

Komponenttien valvonta:

Lopuksi on erittäin tärkeää seurata jokaista komponenttia ja tuntea sen rajoitukset. Järjestelmän tulisi pystyä lisäämään kaistanleveyttä automatisoidusti ja oikeaan aikaan, jotta järjestelmät pysyvät toiminnassa pilvialustan tarpeiden mukaisesti. Valvonta voi olla ulkoista tai sovelluksen käynnistämää, mutta kummassakin tapauksessa lopullisena tavoitteena on antaa järjestelmän skaalautua automaattisesti kuormituksen mukaan.

Seuraavassa blog-julkaisussa käsittelemme valvontaa, lokitietojen keräämistä ja muita arkkitehtuurin osia.