Skaalautuva palveluarkkitehtuuri joka keittiöstä löytyvillä aineksilla

Hei, sinä joka rakennat juuri verkkopalvelua! Kyllä, juuri sinä.

Teetkö suunnitelmia siitä lähtökohdasta, että tulet onnistumaan työssäsi, vai oletatko epäonnistuvasi?



Jos verkkopalvelusi onnistuu, kuinka paljon sillä tulee olemaan käyttäjiä? Kuinka monta pyyntöä sekunnissa se saa palvella?

Juuri nyt, ennenkuin palvelullasi on vielä sitä ensimmäistäkään käyttäjää, on paras aika istua alas ja ajatella mitä onnistuminen tarkoittaa.

Jos rakennat verkkopalvelua, suunnittelet varmaankin käyttäväsi työkaluina PHP:ta, Pythonia, Javaa tai dotnettiä, ja tallettavasi palvelun tiedot MySQL:n, Postgresiin tai MSSQL:n.

Olet tottunut toimimaan niin, että ensin suunnittelet relaatiokannan, sitten rakennat sitä käyttävän saitin, ja iteroit asiakastarpeiden ja uusien ajatusten pohjalta. Jos sinulla on jo jonkin verran kokemusta, suunnittelet rakentavasi kolmitasoarkkitehtuurin ja käyttäväsi MVC-kehystä, sen sijaan että kaikki koodi on samoissa PHP-tiedostoissa.

Nämä suunnitelmat auttavat sinua onnistumaan. Se on hienoa!

Ne eivät auta sinua kohtaamaan onnistumisen aiheuttamia ongelmia. Se on huonoa!

Onnistuminen ja epäonnistuminen ovat luonteeltaan erilaisia. Jos onnistut, peli ei lopukaan, vaan sinulta odotetaan vielä lisää onnistumisia. On paljon katkerampaa väsyä toisessa mäessä, kun ensimmäinen on jo ylitetty.

Kehitys ei pysähdy koskaan, mutta verkkopalveluiden kohdalla voit ottaa suurten toimijoiden onnistumisista ja epäonnistumisista mallia, ja suunnitella järjestelmäarkkitehtuurisi sekä ensimmäistä että toista mäkeä varten. Kolmatta mäkeä ei sitten teknologialla valloitetakaan, vaan siitä huolehtivat humanistit.

Ensimmäinen mäki on palvelun saaminen markkinoille. Toinen on suurten käyttäjämäärien palveleminen palvelunlaadun kärsimättä. Kolmas on oman organisaation kasvukivut tämän seurauksena.

Toisessa mäessä moni verkkopalvelu uupuu siihen, että kehitystiimin sydänverelläkään ei pysytä käyttäjämäärän kasvun perässä, vaan palvelu alkaa hidastumaan ja saattaa hajota kokonaankin, josta viime aikojen kuuluisimpana esimerkkinä Twitter. Hidastelu ja hajoileminen on tuhonnut monta lupaavaa palvelua ajamalla niiden käyttäjät luotettavampien saittien huomaan. Mitä sosiaalisempi on palvelukonsepti, sitä herkemmin näin käy.

Näin ei tarvitse käydä sinulle. Toisen mäen hanskaamista kutsutaan palvelun skaalautumiseksi, ja se tarkoittaa sitä, että tuotat palvelun monella pienellä tavalla yhden suuren askeleen sijaan.

Yhdellä suurella askeleella tarkoitan järjestelmäarkkitehtuuria, jossa kaikki tieto on yhdessä tietokannassa. Kyllä, vaikka suunnittelisit antavasi kannalle lukuorjia.

Monella pienellä tavalla tarkoitan sitä, että teet jokaisesta palvelusi osa-alueesta oman taustapalvelunsa, ja jaat jokaisen taustapalvelun edelleen pienempiin paloihin.

Käyttäjätilien hallinta voi olla oma taustapalvelunsa. Kun koostat verkkosivun, jossa haluat sanoa käyttäjän koko nimen, sivua rakentava kontrolleri tekee HTTP-haun "http://tilipalvelu/users/gumi" ja saa XML/JSON-vastauksen.

Tilipalvelu puolestaan koostuu jatkuvasti kasvavasta määrästä yhden edustakoneen ja kahden HA-klusteroidun MySQL-palvelimen kokonaisuuksia, joissa jokaisessa on vain niin monen käyttäjän tiedot kuin mitä tälläinen toiminnallinen kokonaisuus voi palvella hyvällä palvelunlaadulla.

Ennen tilipalvelun toiminnallisia klustereita on hakemistopalvelu, jonka ainoa tehtävä on kertoa, mistä löytyvät käyttäjän "gumi" tiedot. Koko hakemisto pidetään palvelun muistissa, joten vastaukset missä-kyselyihin tulevat pahimmillaan mikrosekunneissa.

Voilà. Meillä on tilipalvelu, joka ei väsy toisessa mäessä.

Haastavampaa on suunnitella ryhmäpalvelu. Jos ryhmät ja käyttäjätunnukset ovat eri koneilla, tietokanta ei voi pitää huolta tiedon eheydestä sillä tavalla johon olet jo tottunut.

Se, että tiedon eheyttä ei voida 100% taata taustapalveluiden rajojen yli on se hinta joka joudutaan maksamaan toisen mäen ylittämisestä. Siitä ei pääse yli eikä ympäri. Tämä johtuu siitä, että etäisyydet tietokoneiden välillä verkossa ovat niin erilaisia kuin etäisyydet yhden tietokoneen prosessorin ja muistin välillä.

Sovellussuunnittelijoiden ja sivuja koostavien kontrollereiden pitää varautua siihen, että yhden ryhmän jäsenen tietoja ei enää löydykään, ja jättää nimi tulostamatta. Suunnittelijoiden pitää priorisoida sivun tavoitteet, ja päättää mistä voidaan tarvittaessa tilapäisesti luopua.

Olet ohjelmistoja rakentaessasi oppinut saman läksyn kuin minäkin: muutoskustannukset kasvavat logaritmisesti ajan myötä.

Sinun tehtäväsi on suunnitella onnistuvasi. Kyllä, juuri sinun!

Keskustele tiimisi kanssa ensimmäisestä ja toisesta mäestä, hahmottele palvelusi taustapalveluina ja toiminnallisina klustereina, ja tee prototyyppi hakemistopalvelusta jo tänään!

Ja ole ylpeä itsestäsi!