Skaalautuvuus ja joustavuus: Mitä tarvitset viedäksesi yrityksesi pilveen

Olemme innoissamme voidessamme tuoda Transform 2022:n takaisin henkilökohtaisesti 19. ja 20.–28. heinäkuuta. Liity tekoäly- ja datajohtajien joukkoon oivaltavaa keskustelua ja jännittäviä verkostoitumismahdollisuuksia varten. Rekisteröidy tänään!


Vuoteen 2025 mennessä 85 %:lla yrityksistä on pilvi-first-periaate, joka on tehokkaampi tapa isännöidä dataa kuin paikan päällä. COVID-19:n ja etätyön vahvistama siirtyminen pilvipalveluihin on merkinnyt yrityksille monia etuja: alhaisemmat IT-kustannukset, lisääntynyt tehokkuus ja luotettava tietoturva.

Tämän trendin jatkuessa nousujohteisena, myös palveluhäiriöiden ja katkosten uhka kasvaa. Pilvipalveluntarjoajat ovat erittäin luotettavia, mutta ne “eivät ole immuuneja epäonnistumiselle”. Joulukuussa 2021 Amazon ilmoitti nähneensä useiden Amazon Web Services (AWS) -sovellusliittymien vaikutuksen, ja muutamassa minuutissa monet laajalti käytetyt verkkosivustot katosivat.

Miten yritykset voivat siis lieventää pilviriskiä, ​​valmistautua seuraavaan AWS-pulaan ja mukautua äkillisiin kysynnän huippeihin?

Vastaus on skaalautuvuus ja joustavuus – kaksi pilvipalvelun olennaista näkökohtaa, jotka hyödyttävät yrityksiä suuresti. Puhutaan skaalautuvuuden ja joustavuuden eroista ja katsotaan kuinka niitä voidaan rakentaa pilviinfrastruktuurin, sovellus- ja tietokantatasoilla.

Ymmärrä ero skaalautuvuuden ja elastisuuden välillä

Sekä skaalautuvuus että joustavuus liittyvät pyyntöjen määrään, jotka voidaan tehdä samanaikaisesti pilvijärjestelmässä – ne eivät sulje toisiaan pois; molempia on ehkä tuettava erikseen.

Skaalautuvuus on järjestelmän kykyä pysyä reagoivana, kun käyttäjien määrä ja liikenne kasvavat vähitellen ajan myötä. Siksi pitkän aikavälin kasvu on strategisesti suunniteltu. Useimmat B2B- ja B2C-sovellukset, jotka saavat käyttöönsä, vaativat tätä luotettavuuden, korkean suorituskyvyn ja käytettävyyden varmistamiseksi.

Muutamalla pienellä konfiguraatiomuutoksella ja napsautuksella yritys voi muutamassa minuutissa skaalata pilvijärjestelmää ylös tai alas helposti. Monissa tapauksissa tämä voidaan automatisoida pilvialustoilla palvelin-, klusteri- ja verkkotasolla sovellettavien mittakaavatekijöiden avulla, mikä vähentää suunnittelutyökustannuksia.

Elastisuus on järjestelmän kykyä pysyä reagoivana lyhytaikaisten purskeiden tai korkeiden hetkellisten kuormituspiikkien aikana. Joitakin esimerkkejä järjestelmistä, jotka kohtaavat säännöllisesti joustoongelmia, ovat NFL-lippusovellukset, huutokauppajärjestelmät ja vakuutusyhtiöt luonnonkatastrofien aikana. Vuonna 2020 NFL pystyi tukeutumaan AWS:ään suoratoistamaan virtuaalista luonnostaan, kun se tarvitsi paljon enemmän pilvikapasiteettia.

Yritys, jolla on arvaamattomia työkuormia, mutta joka ei halua ennalta suunniteltua skaalausstrategiaa, saattaa etsiä joustavaa ratkaisua julkisesta pilvestä pienemmillä ylläpitokustannuksilla. Tätä hallinnoisi kolmannen osapuolen palveluntarjoaja, ja se jaetaan useiden julkista Internetiä käyttävien organisaatioiden kanssa.

Onko yritykselläsi siis ennakoitavissa olevia, erittäin vaihtelevia työkuormia vai molempia?

Harkitse skaalausvaihtoehtoja pilviinfrastruktuurin avulla

Mitä tulee skaalautumiseen, yritysten on varottava yli- tai alitarjontaa. Näin tapahtuu, kun teknologiatiimit eivät tarjoa kvantitatiivisia mittareita sovellusten resurssivaatimuksista tai skaalauksen taustaidea ei ole linjassa liiketoiminnan tavoitteiden kanssa. Oikean kokoisen ratkaisun määrittämiseksi jatkuva suorituskyvyn testaus on välttämätöntä.

Tätä lukevien yritysjohtajien on puhuttava teknologiatiimilleen saadakseen selville, kuinka he löytävät pilvipalveluiden kaaviot. IT-tiimien tulisi jatkuvasti mitata vasteaikaa, pyyntöjen määrää, suorittimen kuormitusta ja muistin käyttöä seuratakseen pilvikuluihin liittyviä tavarakustannuksia (COG).

Organisaatioiden käytettävissä on erilaisia ​​skaalaustekniikoita, jotka perustuvat liiketoiminnan tarpeisiin ja teknisiin rajoituksiin. Joten, suurennatko vai vähennätkö?

Pystysuuntainen skaalaus sisältää skaalauksen ylös- tai alaspäin, ja sitä käytetään sovelluksissa, jotka ovat monoliittisia, usein rakennettu ennen vuotta 2017 ja joita voi olla vaikea muuttaa uudelleen. Se edellyttää resurssien, kuten RAM-muistin tai prosessointitehon (CPU) lisäämistä olemassa olevaan palvelimeesi, kun työmääräsi lisääntyy, mutta tämä tarkoittaa, että skaalauksella on raja, joka perustuu palvelimen kapasiteettiin. Se ei vaadi sovellusarkkitehtuurin muutoksia, koska siirrät saman sovelluksen, tiedostot ja tietokannan suurempaan koneeseen.

Vaakasuora skaalaus sisältää skaalaamisen tai vähentämisen ja palvelimien lisäämisen alkuperäiseen pilviinfrastruktuuriin toimimaan yhtenä järjestelmänä. Jokaisen palvelimen on oltava itsenäinen, jotta palvelimia voidaan lisätä tai poistaa erikseen. Se sisältää monia arkkitehtonisia ja suunnittelunäkökohtia, jotka liittyvät kuormituksen tasapainottamiseen, istunnonhallintaan, välimuistiin ja viestintään. Siirrettävät vanhat (tai vanhentuneet) sovellukset, joita ei ole suunniteltu hajautettuun tietojenkäsittelyyn, on muokattava huolellisesti uudelleen. Vaakasuuntainen skaalaus on erityisen tärkeää yrityksille, joilla on korkean käytettävyyden palvelut, jotka vaativat mahdollisimman vähän seisokkeja ja korkeaa suorituskykyä, tallennustilaa ja muistia.

Jos olet varma, mikä skaalaustekniikka sopii paremmin yrityksellesi, sinun on ehkä harkittava kolmannen osapuolen pilvisuunnittelun automaatioalustaa, joka auttaa hallitsemaan skaalaustarpeitasi, tavoitteitasi ja toteutustasi.

Mieti, kuinka sovellusarkkitehtuurit vaikuttavat skaalautumiseen ja joustavuuteen

Otetaanpa yksinkertainen terveydenhuollon sovellus – joka koskee myös monia muita toimialoja – nähdäksemme, kuinka sitä voidaan kehittää eri arkkitehtuurien välillä ja miten se vaikuttaa skaalautumiseen ja joustavuuteen. Terveydenhuoltopalveluihin kohdistui kovia paineita, ja niiden oli laajennettava rajusti COVID-19-pandemian aikana, ja ne olisivat voineet hyötyä pilvipohjaisista ratkaisuista.

Korkealla tasolla on olemassa kahdenlaisia ​​arkkitehtuureja: monoliittisia ja hajautettuja. Monoliittinen (tai kerroksellinen, modulaarinen monoliitti, putkisto ja mikroydin) arkkitehtoninen niitä ei ole rakennettu natiivisti tehokkaan skaalautuvuuden ja joustavuuden takaamiseksi – kaikki moduulit sisältyvät sovelluksen pääosaan, ja tämän seurauksena koko sovellus otetaan käyttöön yhtenä kokonaisuutena. Hajautettuja arkkitehtuureja on kolmenlaisia: tapahtumapohjaisia, mikropalveluita ja avaruuspohjaisia.

Yksinkertaisessa terveydenhuollon sovelluksessa on:

  • Potilasportaali – potilaiden rekisteröintiä ja ajanvarausta varten.
  • Lääkäriportaali – lääkintähenkilöstö voi tarkastella terveystietoja, suorittaa lääkärintarkastuksia ja määrätä lääkkeitä.
  • Toimistoportaali – kirjanpito- ja tukihenkilöstölle maksujen keräämiseen ja osoitekyselyihin.

Sairaalan palveluilla on kova kysyntä ja kasvun tukemiseksi niiden tulee skaalata potilasilmoittautumis- ja ajanvarausmoduuleja. Tämä tarkoittaa, että heidän tarvitsee vain skaalata potilasportaalia, ei lääkärin tai toimiston portaaleja. Selvitetään, kuinka tämä sovellus voidaan rakentaa jokaiselle arkkitehtuurille.

monoliittinen arkkitehtuuri

Tekniset startup-yritykset, myös terveydenhuollon alalla, käyttävät usein tätä perinteistä, yhtenäistä ohjelmistosuunnittelumallia nopeuden markkinoille saattamisen edun vuoksi. Mutta se ei ole optimaalinen ratkaisu yrityksille, jotka vaativat skaalautuvuutta ja joustavuutta. Tämä johtuu siitä, että sovelluksessa on yksi integroitu esiintymä ja keskitetty yksittäinen tietokanta.

Sovelluksen skaalausta varten lisäämällä useampia sovelluksen esiintymiä kuormituksen tasapainotuksella skaalataan kaksi muuta portaalia sekä potilasportaali, vaikka yritys ei sitä tarvitsekaan.

Useimmat monoliittiset sovellukset käyttävät monoliittista tietokantaa, joka on yksi kalleimmista pilviresursseista. Pilvikustannukset kasvavat eksponentiaalisesti mittakaavan myötä, ja tämä järjestely on kallis varsinkin kehitys- ja käyttöinsinöörien ylläpitoajan suhteen.

Toinen näkökohta, joka tekee monoliittisista arkkitehtuureista sopimattomia tukemaan joustavuutta ja skaalautuvuutta, on keskimääräinen käynnistysaika (MTTS) – aika, joka kuluu sovelluksen uuden esiintymän käynnistymiseen. Se vie yleensä useita minuutteja sovelluksen ja tietokannan suuren laajuuden vuoksi: Insinöörien on luotava tukitoiminnot, riippuvuudet, objektit ja yhteyspoolit sekä varmistettava turvallisuus ja liitettävyys muihin palveluihin.

Tapahtumalähtöinen arkkitehtuuri

Tapahtumalähtöinen arkkitehtuuri soveltuu monoliittista arkkitehtuuria paremmin skaalautumiseen ja joustavuuteen. Se esimerkiksi julkaisee tapahtuman, kun jotain havaittavaa tapahtuu. Se voi näyttää siltä, ​​että ostaisit verkkokauppasivustolla kiireisenä aikana, tilaat tuotteen, mutta sitten vastaanotat sähköpostin, jossa sanotaan, että tuote on loppunut. Asynkroninen viestintä ja jonot tarjoavat vastapainetta, kun etupää skaalataan ilman, että takapäätä skaalataan jonotuspyyntöjen avulla.

Tässä terveydenhuollon sovellusten tapaustutkimuksessa tämä hajautettu arkkitehtuuri tarkoittaisi, että jokainen moduuli on oma tapahtumaprosessori. on joustavuutta jakaa tai jakaa tietoja yhden tai useamman moduulin välillä. Sovellus- ja tietokantatasolla on jonkin verran joustavuutta mittakaavan suhteen, koska palveluita ei enää yhdistetä.

mikropalveluarkkitehtuuri

Tämä arkkitehtuuri näkee jokaisen palvelun yhden tarkoituksen palveluna, mikä antaa yrityksille mahdollisuuden skaalata jokainen palvelu itsenäisesti ja välttää arvokkaiden resurssien tarpeettoman kulutuksen. Tietokannan skaalausta varten pysyvyyskerros voidaan suunnitella ja määrittää yksinomaan kullekin palvelulle yksittäistä skaalausta varten.

Tapahtumalähtöisen arkkitehtuurin ohella nämä arkkitehtuurit maksavat pilviresurssien suhteen enemmän kuin monoliittiset arkkitehtuurit alhaisella käyttötasolla. Kuitenkin lisääntyvien kuormien, useiden vuokralaisten toteutusten ja liikennepurskeiden vuoksi ne ovat taloudellisempia. MTTS on myös erittäin tehokas ja se voidaan mitata sekunneissa hienorakeisten palveluiden ansiosta.

Palveluiden suuren määrän ja hajautetun luonteen vuoksi virheenkorjaus voi kuitenkin olla vaikeampaa ja ylläpitokustannukset voivat olla korkeammat, jos palveluita ei ole täysin automatisoitu.

Avaruuteen perustuva arkkitehtuuri

Tämä arkkitehtuuri perustuu periaatteeseen, jota kutsutaan tuple-spaced-käsittelyksi – useisiin rinnakkaisiin prosessoreihin jaetulla muistilla. Tämä arkkitehtuuri maksimoi sekä skaalautuvuuden että joustavuuden sovellus- ja tietokantatasolla.

Kaikki sovellusten vuorovaikutukset tapahtuvat muistissa olevan dataruudukon kanssa. Kutsut verkkoon ovat asynkronisia, ja tapahtumaprosessorit voivat skaalata itsenäisesti. Tietokannan skaalauksessa on taustatietojen kirjoittaja, joka lukee ja päivittää tietokannan. Vastaava palvelu lähettää kaikki lisäys-, päivitys- tai poistotoiminnot tietojen kirjoittajalle ja asettaa ne jonoon noudettavaksi.

MTTS on erittäin nopea ja kestää yleensä muutaman millisekunnin, koska kaikki datavuorovaikutus tapahtuu muistissa olevien tietojen kanssa. Kaikkien palveluiden on kuitenkin yhdistettävä välittäjään ja välimuistin alkulataus on luotava tiedonlukijalla.

Tällä digitaalisella aikakaudella yritykset haluavat lisätä tai vähentää IT-resursseja tarpeen mukaan vastatakseen muuttuviin vaatimuksiin. Ensimmäinen askel on siirtyminen suurista monoliittisista järjestelmistä hajautettuun arkkitehtuuriin kilpailuedun saamiseksi – tämän ovat tehneet Netflix, Lyft, Uber ja Google. Arkkitehtuurin valinta on kuitenkin subjektiivinen, ja päätökset on tehtävä kehittäjien kykyjen, keskimääräisen kuormituksen, huippukuormituksen, budjettirajoitusten ja liiketoiminnan kasvutavoitteiden perusteella.

Sashank on sarjayrittäjä, joka on kiinnostunut innovaatioista.

DataDecisionMakers

Tervetuloa VentureBeat-yhteisöön!

DataDecisionMakers on paikka, jossa asiantuntijat, mukaan lukien datatyötä tekevät tekniset ihmiset, voivat jakaa dataan liittyviä oivalluksia ja innovaatioita.

Jos haluat lukea uusimmista ideoista ja ajankohtaisista tiedoista, parhaista käytännöistä sekä datan ja datatekniikan tulevaisuudesta, liity mukaan DataDecisionMakersiin.

Saatat jopa harkita oman artikkelisi kirjoittamista!

Lue lisää DataDecisionMakersilta

Leave a Comment