Skaalautuvuus on olennainen osa yrityksen ohjelmistoja. Sen priorisointi alusta alkaen johtaa pienempiin ylläpitokustannuksiin, parempaan käyttökokemukseen ja suurempaan ketteryyteen.

Ohjelmistosuunnittelu on tasapainoilua, jossa kehittäjät työskentelevät luodakseen parhaan tuotteen asiakkaan aika- ja budjettirajoitusten puitteissa.

Kompromissien välttämättömyydeltä ei voi välttyä. Kompromisseja on tehtävä, jotta projektin vaatimukset voidaan täyttää, olivatpa ne sitten teknisiä tai taloudellisia.

Yli liian usein yritykset kuitenkin asettavat kustannukset skaalautuvuuden edelle tai jopa sivuuttavat sen merkityksen kokonaan. Tämä on valitettavan yleistä big data -aloitteissa, joissa skaalautuvuusongelmat voivat upottaa lupaavan hankkeen.

Skaalautuvuus ei ole ”bonusominaisuus”. Se on laatu, joka määrittää ohjelmiston elinkaariarvon, ja skaalautuvuus huomioiden rakentaminen säästää sekä aikaa että rahaa pitkällä aikavälillä.

Mitä on skaalautuvuus?

Järjestelmää pidetään skaalautuvana, kun sitä ei tarvitse suunnitella uudelleen, jotta se säilyttäisi tehokkaan suorituskykynsä työmäärän jyrkän kasvun aikana tai sen jälkeen.

”Työkuorma” voi viitata samanaikaisiin käyttäjiin, tallennuskapasiteettiin, käsiteltävien transaktioiden enimmäismäärään tai mihin tahansa muuhun, joka vie järjestelmän alkuperäisen kapasiteetin yli.

Skaalautuvuus ei ole ohjelman perusvaatimus sikäli, että skaalautumattomat ohjelmistot voivat toimia hyvin rajallisella kapasiteetilla.

Skaalautuvuus kuvastaa kuitenkin ohjelmiston kykyä kasvaa tai muuttua käyttäjän vaatimusten mukaan.

Jokainen ohjelmisto, joka voi laajentua perustoimintojaan pidemmälle – varsinkin jos liiketoimintamalli on riippuvainen sen kasvusta – tulisi konfiguroida skaalautuvaksi.

Skaalautuvien ohjelmistojen edut

Skaalautuvuudella on sekä pitkän että lyhyen aikavälin etuja.

Alussa se antaa yritykselle mahdollisuuden hankkia vain sen, mitä se tarvitsee välittömästi, eikä kaikkia ominaisuuksia, jotka saattavat olla hyödyllisiä myöhemmin.

Tietotiedonkeruun pilottiohjelman aloittava yritys voi esimerkiksi valita massiivisen yritysanalytiikkapaketin, tai se voi aloittaa ratkaisulla, joka käsittelee vain aluksi tarvitsemansa toiminnot.

Suosittu valinta on kojelauta, joka vetää tuloksia ensisijaisista tietolähteistä ja olemassa olevista yritysohjelmistoista.

Kun yritys kasvaa tarpeeksi suureksi käyttääkseen useampia analyysiohjelmia, nämä tietovirrat voidaan lisätä kojelautaan sen sijaan, että yritys joutuisi jongleeraamaan useiden visualisointiohjelmien kanssa tai rakentamaan kokonaan uuden järjestelmän.

Tällä tavalla rakentamalla valmistaudutaan tulevaan kasvuun ja luodaan samalla kevyempi tuote, joka vastaa nykyisiä tarpeita ilman ylimääräistä monimutkaisuutta.

Se vaatii myös pienemmän alkuvaiheen rahallisen panostuksen, mikä on tärkeä näkökohta suurten datainvestointien suuruudesta huolestuneille johtajille.

Skaalautuvuus jättää myös tilaa muuttuville painopisteille. Valmis analytiikkapaketti voi menettää merkityksensä, kun yritys siirtyy vastaamaan kehittyvien markkinoiden vaatimuksia.

Skaalautuvien ratkaisujen valitseminen suojaa alkuperäistä teknologiainvestointia. Yritykset voivat jatkaa saman ohjelmiston käyttöä pidempään, koska se on suunniteltu kasvamaan yrityksen mukana.

Kun on aika tehdä muutoksia, vankan, skaalautuvan ohjelmiston varaan rakentaminen on huomattavasti edullisempaa kuin yrittää mukauttaa vähemmän ketteriä ohjelmia.

Uudet ominaisuudet saadaan käyttöön nopeammin kuin kokonaan uuden ohjelmiston käyttöönotto.

Sivuhyötynä voidaan todeta, että henkilöstöä ei tarvitse juurikaan kouluttaa tai suostutella omaksumaan päivitettyä järjestelmää. Käyttöliittymä on heille jo tuttu, joten lisäominaisuuksien kanssa työskentelyä pidetään pikemminkin bonuksena kuin vaivalloisuutena.

Skaalausvirheiden seuraukset

Mitä sitten tapahtuu, kun ohjelmisto ei ole skaalautuva?

Aluksi heikkoutta on vaikea havaita. Sovelluksen alkuvaiheessa työmäärä on kevyt. Kun samanaikaisia käyttäjiä on suhteellisen vähän, arkkitehtuurille ei ole paljon vaatimuksia.

Kun työmäärä kasvaa, syntyy ongelmia. Mitä enemmän tallennettuja tietoja tai yhtäaikaisia käyttäjiä ohjelmisto kerää, sitä enemmän ohjelmiston arkkitehtuuriin kohdistuu rasitusta.

Rajoituksista, jotka eivät alussa tuntuneet tärkeiltä, tulee tuottavuuden este. Korjaukset saattavat lievittää joitakin alkuvaiheen ongelmia, mutta korjaukset lisäävät monimutkaisuutta.

Kompleksisuus tekee ongelmien jatkuvasta diagnosoinnista työläämpää (käännös: kalliimpaa ja tehottomampaa).

Suorituskyky laskee, kun työkuorma kasvaa niin suureksi, että ohjelmisto ei enää kykene skaalautumaan.

Käyttäjät kokevat, että latausajat ovat hitaita, koska palvelimella kestää liian kauan vastata pyyntöihin. Muita mahdollisia ongelmia ovat heikentynyt käytettävyys tai jopa tietojen katoaminen.

Kaikki tämä lannistaa tulevaa käyttöä. Työntekijät löytävät kiertoteitä epäluotettaville ohjelmistoille saadakseen omat työnsä tehtyä.

Tämä asettaa yrityksen tietomurron tai pahemman riskin.

Kun ohjelmisto on asiakaskohtainen, epäluotettavuus lisää potentiaalista vaihtuvuutta.

Google havaitsi, että 61 prosenttia käyttäjistä ei anna sovellukselle toista tilaisuutta, jos heillä oli huono ensimmäinen kokemus. 40 prosenttia siirtyy sen sijaan suoraan kilpailijan tuotteeseen.

Skaalautuvuusongelmat eivät ole myöskään vain pienten yritysten tekemä aloittelijan virhe. Jopa Disney törmäsi ongelmiin Applause-sovelluksensa alkuperäisessä lanseerauksessa, jonka oli tarkoitus antaa katsojille ylimääräinen tapa olla vuorovaikutuksessa Disneyn suosikkiohjelmien kanssa. Sovellus ei kyennyt käsittelemään samanaikaisten suoratoistovideokäyttäjien tulvaa.

Tyytymättömät fanit jättivät negatiivisia arvosteluja, kunnes sovellus sai yhden tähden Google Play -kaupassa. Disneyn virkamiehet joutuivat poistamaan sovelluksen käytöstä vahingon korjaamiseksi, ja negatiivinen julkisuus oli niin voimakasta, ettei se koskaan palannut verkkoon.

Prioriteettien asettaminen

Jotkut yritykset eivät aseta skaalautuvuutta etusijalle, koska ne eivät näe siitä välitöntä hyötyä.

Skaalautuvuus työnnetään syrjään nopeuden, lyhyempien kehityssyklien tai alhaisempien kustannusten eduksi.

On itse asiassa joitain tapauksia, joissa skaalautuvuus ei ole ensisijainen prioriteetti.

Ohjelmisto, joka on tarkoitettu prototyypiksi tai pienen volyymin konseptin todisteeksi, ei kasva niin suureksi, että se aiheuttaisi ongelmia.

Kuten myös pienten yritysten sisäiset ohjelmistot, joiden potentiaalisten käyttäjien kiinteä raja on pieni, voivat asettaa muita prioriteetteja.

Loppujen lopuksi, kun ACID-yhteensopivuus on ehdottoman pakollista, skaalautuvuus menee luotettavuuden edelle.

Yleissääntönä kuitenkin skaalautuvuus on helpompaa ja vähemmän resursseja vievää, kun se otetaan huomioon alusta alkaen.

Yksi asia on se, että tietokannan valinnalla on suuri vaikutus skaalautuvuuteen. Uuteen tietokantaan siirtyminen on kallista ja aikaa vievää. Sitä ei voi tehdä helposti jälkikäteen.

Skaalautuvuuden periaatteet

Ohjelmiston yleiseen skaalautuvuuteen vaikuttavat useat tekijät:

Käyttö

Käyttö mittaa mahdollisten samanaikaisten käyttäjien tai yhteyksien määrää. Käytöllä ei pitäisi olla mitään keinotekoisia rajoituksia.

Käytön lisäämisen pitäisi olla yhtä yksinkertaista kuin lisätä resursseja ohjelmiston käyttöön.

Maksimaalinen tallennettu data

Tämä on erityisen tärkeää sivustoille, joilla on paljon strukturoimatonta dataa: käyttäjien lataamaa sisältöä, sivustoraportteja ja tietyntyyppistä markkinointidataa.

Tietotekniset projektit kuuluvat myös tähän luokkaan. Tällaiseen sisältöön tallennetun datan määrä voi kasvaa dramaattisesti ja odottamattomasti.

Voidaanko tallennetun datan enimmäismäärä skaalata nopeasti, riippuu suuresti tietokantatyylistä (SQL- vs. NoSQL-palvelimet), mutta on myös ratkaisevan tärkeää kiinnittää huomiota asianmukaiseen indeksointiin.

Koodi

Kokemattomat kehittäjät jättävät yleensä huomiotta koodiin liittyvät näkökohdat skaalautuvuutta suunniteltaessa.

Koodi tulisi kirjoittaa niin, että sitä voidaan lisätä tai muuttaa ilman vanhan koodin refaktorointia. Hyvät kehittäjät pyrkivät välttämään päällekkäistä työtä ja vähentämään koodikannan kokonaiskokoa ja monimutkaisuutta.

Sovellusten koko kasvaa niiden kehittyessä, mutta koodin pitäminen puhtaana minimoi vaikutuksen ja estää ”spagettikoodin” muodostumisen.

Skaalautuminen ulospäin vs. skaalautuminen ylöspäin

Skaalautumisessa ylöspäin (tai ”pystysuuntaisessa skaalautumisessa”) on kyse siitä, että kasvaminen tapahtuu käyttämällä kehittyneempiä tai vahvempia laitteita. Lisääntyneen työmäärän käsittelyyn käytetään levytilaa tai nopeampaa keskusyksikköä (CPU).

Skaalautuminen ylöspäin tarjoaa paremman suorituskyvyn kuin skaalautuminen ulospäin. Kaikki on samassa paikassa, mikä mahdollistaa nopeamman tuoton ja pienemmän haavoittuvuuden.

Skaalautumisen ongelmana on, että tilaa kasvaa on vain rajallisesti. Laitteisto kallistuu, kun se kehittyy. Jossain vaiheessa yritykset törmäävät kehittyneiden järjestelmien ostamisen vähenevän tuoton lakiin.

Uuden laitteiston käyttöönotto vie myös aikaa.

Tämän rajoituksen vuoksi vertikaalinen skaalautuminen ei ole paras ratkaisu ohjelmistoille, joiden on kasvettava nopeasti ja vähällä varoitusajalla.

Ulospäin skaalautuminen (tai ”horisontaalinen skaalautuminen”) on paljon laajemmin käytössä yritystarkoituksiin.

Skaalautumisessa ulospäin ohjelmisto kasvaa käyttämällä enemmän – ei kehittyneempää – laitteistoa ja jakamalla lisääntynyt työmäärä uuteen infrastruktuuriin.

Kustannukset ovat alhaisemmat, koska ylimääräiset palvelimet tai suorittimet voivat olla samantyyppisiä kuin tällä hetkellä käytössä olevat (tai mitä tahansa yhteensopivaa tyyppiä).

Skaalautuminen tapahtuu myös nopeammin, koska mitään ei jouduta tuomaan maahan tai rakentamaan uudelleen.

Nopeus kuitenkin kärsii hieman. Horisontaalisesti skaalautuvia ohjelmistoja rajoittaa nopeus, jolla palvelimet voivat kommunikoida.

Ero ei kuitenkaan ole niin suuri, että useimmat käyttäjät huomaisivat sen, ja on olemassa työkaluja, jotka auttavat kehittäjiä minimoimaan vaikutuksen. Tämän seurauksena skaalautumista ulospäin pidetään parempana ratkaisuna, kun rakennetaan skaalautuvia sovelluksia.

Guidelines for Building Highly Scalable Systems

Skaalautuvuuden huomioiminen suunnitteluvaiheessa on sekä halvempaa että helpompaa. Seuraavassa on joitakin parhaita käytäntöjä skaalautuvuuden sisällyttämiseksi alusta alkaen:

Käytä kuormanjako-ohjelmistoa

Kuormanjako-ohjelmisto on kriittisen tärkeä järjestelmissä, joissa on hajautettu infrastruktuuri (kuten horisontaalisesti skaalautuvissa sovelluksissa).

Tämä ohjelmisto käyttää algoritmia, jolla se jakaa työkuorman palvelimille varmistaakseen, ettei yksikään yksittäinen palvelin joudu ylikuormitetuksi. Se on ehdoton välttämättömyys suorituskykyongelmien välttämiseksi.

Sijoituksella on väliä

Skaalautuva ohjelmisto tekee mahdollisimman paljon lähellä asiakasta (sovelluskerroksessa). Kun vähennetään sitä, kuinka monta kertaa sovellusten on navigoitava raskaampaa liikennettä lähellä ydinresursseja, se johtaa nopeampiin nopeuksiin ja pienempään rasitukseen palvelimille.

Edge computing on jotain muuta huomioitavaa. Kun yhä useammat sovellukset vaativat resurssi-intensiivisiä sovelluksia, mahdollisimman suuren osan työn pitäminen laitteessa vähentää heikon signaalin alueiden ja verkon viiveiden vaikutusta.

Välimuisti missä mahdollista

Ole tietoinen tietoturvaongelmista, mutta välimuistiin tallentaminen on hyvä tapa välttää saman tehtävän suorittaminen yhä uudelleen ja uudelleen.

Johtaminen API:lla

Käyttäjät ottavat yhteyttä useiden eri asiakastyyppien kautta, joten johtaminen API:lla, joka ei oleta tiettyä asiakastyyppiä, voi palvella kaikkia.

Asynkroninen käsittely

Se viittaa prosesseihin, jotka on jaettu erillisiin vaiheisiin, joiden ei tarvitse odottaa edellisen valmistumista ennen käsittelyä.

Käyttäjälle voidaan esimerkiksi näyttää ”lähetetty!”.” -ilmoituksen, kun sähköpostin tekninen käsittely on vielä kesken.

Asynkroninen käsittely poistaa joitakin pullonkauloja, jotka vaikuttavat suorituskykyyn laajamittaisissa ohjelmistoissa.

Limitoi rajallisten resurssien samanaikaista käyttöä

Ei päällekkäistä työtä. Jos useampi kuin yksi pyyntö pyytää samaa laskutoimitusta samasta resurssista, anna ensimmäisen lopettaa ja käytä vain sitä tulosta. Tämä lisää nopeutta ja vähentää samalla järjestelmän rasitusta.

Käytä skaalautuvaa tietokantaa

NoSQL-tietokannat ovat yleensä skaalautuvampia kuin SQL. SQL skaalautuu lukuoperaatioiden osalta riittävän hyvin, mutta kirjoitusoperaatioiden osalta se on ristiriidassa rajoitusten kanssa, joiden tarkoituksena on valvoa ACID-periaatteiden noudattamista.

NoSQL-tietokannan skaalautuminen vaatii näiden periaatteiden vähemmän tiukkaa noudattamista, joten jos ACID-vaatimusten noudattaminen ei ole huolenaihe, NoSQL-tietokanta voi olla oikea valinta.

Harkitse PaaS-ratkaisuja

Platform-as-a-service-palvelun tarjoama alusta vapauttaa paljon skaalautuvuusongelmista, sillä paas-palveluntarjoaja hallinnoi skaalausta. Skaalautuminen voi olla yhtä helppoa kuin tilaustason päivittäminen.

Katso FaaS

Function-as-a-service on kehittynyt PaaS:stä ja liittyy siihen hyvin läheisesti. Palvelimeton tietojenkäsittely tarjoaa tavan käyttää vain niitä toimintoja, joita kulloinkin tarvitaan, mikä vähentää tarpeettomia vaatimuksia back-end-infrastruktuurille.

FaaS on vielä kypsymässä, mutta se voi olla tutkimisen arvoinen tapa leikata käyttökustannuksia ja parantaa samalla skaalautuvuutta.

Älkää unohtako ylläpitoa

Säädä ohjelmisto automatisoitua testausta ja ylläpitoa varten, jotta sen kasvaessa ylläpidon työ ei riistäydy käsistä.

Rakenna tulevaisuutta silmällä pitäen

Skaalautuvuuden asettaminen etusijalle valmistaa yrityksesi menestykseen. Harkitse sitä ajoissa, niin saat ketteryyden hyödyt silloin, kun sitä eniten tarvitaan.

Etsitkö ohjelmistoa, joka voi kasvaa yrityksesi mukana? Sovi ilmainen tapaaminen yhden kehittäjämme kanssa, jotta voimme keskustella siitä, mihin sinun on mentävä ja miten voimme auttaa sinua pääsemään sinne!