PALVELUNTARJOAJAN JA
PILVIPALVELUMALLIN VAIKUTUS PILVIPOHJAISEN
MITTAUSJ ¨ ARJESTELM ¨ AN TOTEUTUKSEEN
- case Q-Health
Jesse Tolvanen
Kandidaatinty¨o
LUT School of Energy Systems S¨ahk¨otekniikka
4.9.2019
Lappeenrannan teknillinen yliopisto LUT School of Energy Systems S¨ahk¨otekniikka
Jesse Tolvanen
Palveluntarjoajan ja pilvipalvelumallin vaikutus pilvipohjaisen mittausj¨arjestelm¨an toteutukseen- case Q-Health
2018
Kandidaatinty¨o.
20 s.
Tarkastaja: Kuisma, Mikko
Kandidaatintutkimuksessa kuvataan LUT-yliopiston ja Jyv¨askyl¨an yliopiston Q-Health tut- kimusprojektissa kehitetty datanker¨aysj¨arjestelm¨a, sen arkkitehtuuri ja palvelutoteutus Amazon AWS pilvipalvelualustalla. Tutkimus on toteutettu deskriptiivisen¨a tutkimuksena, jossa tavoit- teena on selvitt¨a¨a miten pilvipalvelumallin ja palveluntarjoajan valinta vaikuttaa Q-Health da- tanker¨aysj¨arjestelm¨a¨an. Tutkimuksessa selvitet¨a¨an, mitk¨a tekij¨at ovat merkitsevi¨a palveluntar- joajan valinnassa ja miten tehdyt valinnat tulevat n¨akyviin loppuk¨aytt¨aj¨alle.
Q-Health-projekti toteutettiin Amazon AWS-pilvipalvelualustalle k¨aytt¨aen Function as a Ser- vice palvelumallia. Pilvipalvelu sis¨alt¨a¨a verkkok¨aytt¨oliittym¨an sek¨a backendin, joka huolehtii tiedon tallentamisesta ja k¨asittelemisest¨a. Palveluntarjoajista tutkittiin Amazon AWS:¨a¨a, IBM Cloudia sek¨a Microsoft Azurea.
Tutkimuksessa selvisi, ett¨a pilvipalvelumallin valinnalla suurin vaikutus on palvelun skaalau- tuvuuteen, hinnoitteluun sek¨a kehitysty¨oh¨on. Skaalautuvuuden ja kehitysty¨on nopeuden osalta Function as a Service palvelutoteutuksena todettiin edullisimmaksi vaihtoehdoksi.
Tutkimuksessa keskityttiin Q-Health:n pilvipalvelualustan arkkitehtuuria vastaavien palve- luresurssien vertailuun. Vertailun tuloksena selvisi, ettei palveluntarjoajan valinnalla ole mer- kitt¨av¨a¨a vaikutusta Q-Health:n pilvipalvelun toteutukseen, sill¨a palveluntarjoajien palveluvali- koimat ovat kesken¨a¨an hyvin samanlaiset. Palveluntarjoajan valinnan voi tehd¨a vapaasti, jos palveluntarjoajalle ei ole erityisvaatimuksia.
Q-Health:n pilvipalvelun loppuk¨aytt¨aj¨alle ei tule n¨akyville, mill¨a tavalla backendin palvelu- toteutus on rakennettu.
ABSTRACT
LUT University
LUT School of Energy Systems Electrical engineering
Jesse Tolvanen
Effect of cloud service provider and service model for cloud-based measuring system - case Q-Health
2018
Bachelor’s Thesis.
20 p.
Examiner: Kuisma, Mikko
This study describes a data collection system, its architecture and service model developed in research project Q-Health between LUT-University and Jyv¨askyl¨a University. The research is done as descriptive study, in which the aim is to define how the choise of service model and service provider affect the Q-Health system. Study researches what factors are the most important in choosing the service providers and how this affects the user experience.
Q-Health-project was built using Amazon AWS platform and Function as a Service as the service model. The cloud service contains frontend and backend, which stores and process the data.The outcome of study was that cloud service model affects the most to scaling, pricing and development work. Function as a Service was the best in terms of scaling and speed of development.
Amazon AWS, IBM Cloud and Microsoft Azure were studied of cloud service providers. Study focused mainly on services that were similar what Q-Health used in it’s service architecture. The comparison between these service providers revealed the choise of cloud service provider was not major contributor to Q-Health’s service architecture. Providers had similar offerings of cloud services, so one can choose service provider freely if there is not special requirements. The end user does not see the effects of backend architecture.
K ¨AYTETYT MERKINN ¨AT JA LYHENTEET . . . 4
1. Johdanto . . . 5
2. Pilvipalvelu . . . 7
2.1 Pilvipalvelumallit . . . 7
2.1.1 IaaS . . . 7
2.1.2 PaaS . . . 7
2.1.3 SaaS . . . 7
2.2 Serverless . . . 7
3. Q-Health . . . 9
3.1 AWS Lambda . . . 10
3.2 AWS API Gateway . . . 10
3.3 AWS S3 . . . 11
3.4 DynamoDB . . . 11
3.5 Cloudwatch . . . 11
3.6 Route53 ja Cloudfront . . . 11
3.7 Verkkok¨aytt¨oliittym¨a . . . 11
3.8 Datanker¨ain . . . 12
3.9 Testaus ja kokemukset . . . 13
4. Alustojen ja palveluiden vertailu . . . 15
4.1 Pilvipalvelumallin valinta . . . 15
4.2 Palveluntarjoajien tarjonnan vertailu . . . 16
4.3 Palveluntarjoajan valinta . . . 18
5. Yhteenveto . . . 19
K ¨AYTETYT MERKINN ¨AT JA LYHENTEET
API Application programming interface CDN Content Delivery Network
FaaS Function as a service IaaS Infrastructure as a service LAMP Linux, Apache, MySQL, ja PHP NoSQL non SQL
PaaS Platform as a service
REST Representational State Transfer SaaS Software as a service
SQL Structured Query Language
1. Johdanto
Viimeisen vuosikymmenen aikana internetiin liitettyjen laitteiden m¨a¨ar¨a on kasvanut r¨aj¨ahdysm¨aisesti, eik¨a kasvulle ole n¨akyviss¨a laskua. Erilaiset anturit ja mittausj¨arjestelm¨at muodostavat uudenlaisia haasteita sek¨a mahdollisuuksia tietoyhteiskunnassa.
Yleisesti mittausj¨arjestelm¨an voidaan ajatella koostuvan datanl¨ahteest¨a, da- tank¨asittelyj¨arjestelm¨ast¨a, sek¨a k¨aytt¨oliittym¨ast¨a. Datanl¨ahde voi olla esimerkiksi l¨amp¨otila- anturi, valvontakamera tai vaikkapa ¨alypakastin. Data voidaan siirt¨a¨a esimerkiksi internetin yli pilvipalveluun, jossa sit¨a voidaan prosessoida ja jalostaa datasta merkityksellist¨a tietoa. Tieto esitet¨a¨an k¨aytt¨aj¨alle jonkin k¨aytt¨oliittym¨an, esimerkiksi puhelinsovelluksen tai internetsivuston kautta.
Mittausj¨arjestelm¨an toteutukselle ei ole olemassa yht¨a ainutta oikeaa tapaa. Valmiita j¨arjestelmi¨a on saatavilla niin kaupallisina, kuin avoimen l¨ahdekoodin ratkaisuina. Jos valmiit ratkaisut eiv¨at sovi jonkin mittausj¨arjestelm¨an alustaksi, voi pilvipalveluratkaisun rakentaa my¨os itse k¨aytt¨aen julkisia pilvipalvelualustoja.
T¨am¨a kandidaatinty¨o liittyy LUT-yliopiston ja Jyv¨askyl¨an yliopiston Q-Health tutkimusprojek- tiin. Projektissa tutkittiin ihmisen energiakulutuksen mittausta uudenlaisella l¨amp¨ovuoanturilla.
Anturin mittaustiedon ker¨a¨amiseksi t¨aytyi kehitt¨a¨a j¨arjestelm¨a (kuva 1), joka siirt¨a¨a mittaustie- dot puettavasta laitteesta pilvipalveluun, josta se tarjotaan k¨aytt¨aj¨alle. Projektin toteutusvai- heessa ei ollut tietoa, miten mittausj¨arjestelm¨an pilvipalveluosan palveluntarjoajan, tai palvelu- mallin valinta vaikuttaa toteutettuun j¨arjestelm¨a¨an.
Kuva 1: Q-Health-tutkimusprojektin mittausj¨arjestelm¨a, johon kuuluu puettava mittalaite, Blue- toothin yli kommunikoiva datanker¨ain sek¨a pilvess¨a sijaitseva datan tallennus- ja analysointipal- velu.
T¨am¨a kandidaatintutkimus toteutetaan deskriptiivisen¨a tutkimuksena, jossa kuvataan projektin j¨arjestelm¨atoteutus yleisell¨a tasolla. Tavoitteena on selvitt¨a¨a, miten vaikuttaako pilvipohjaisen
6
mittausj¨arjestelm¨an palveluntarjoajan ja palvelutoteutuksen valinnat Q-Health j¨arjestelm¨a¨an.
Tavoitetta tukevat tutkimuskysymykset ovat:
- Mihin tekij¨oihin datanker¨aysj¨arjestelm¨an palvelumallin valinta vaikuttaa
- Miten Q-Health datanker¨aysj¨arjestelm¨an voi toteuttaa eri palveluntarjoajilla k¨aytt¨aen valittua palvelumallia
- Mitk¨a ovat merkitt¨avimm¨at tekij¨at palveluntarjoajan valinnassa - Miten palvelumallin valinta n¨akyy loppuk¨aytt¨aj¨alle
2. Pilvipalvelu
Pilvipalvelulle on olemassa monia m¨a¨aritelmi¨a, mutta de facto -standardiksi on muodostunut yhdysvaltalaisen National Institute of Standards and Technology (NIST) j¨arjest¨on m¨a¨a¨aritelm¨a, jonka mukaan pilvipalvelu on malli, joka mahdollistaa helpon p¨a¨asyn skaalattaviin ja konfigu- roitaviin resursseihin, kuten verkkoihin, palvelimiin, tallennusresursseihin ja palveluihin. (Mell (2010))
Pilvipalvelut voidaan jakaa eri luokkiin palveluntarjoajan perusteella: yksityinen pilvi (Private cloud) on k¨aytt¨aj¨an tai organisaation itsens¨a yll¨apit¨am¨a pilvi, joko omassa tai kolmannen osa- puolen palvelinsalissa. Julkinen pilvipalvelu (Public cloud) on pilvipalveluntarjoajan yll¨apit¨am¨a pilvi, josta k¨aytt¨aj¨a voi vuokrata palveluja ja resursseja k¨aytt¨o¨ons¨a. Hybridipilvi on kahden edell¨amainitun yhdistelm¨a, jossa osa resursseista sijaitsee julkisessa ja osa yksityisess¨a pilvess¨a tai konesalissa.
2.1 Pilvipalvelumallit
Pilvipalvelu on k¨asite, joka pit¨a¨a sis¨all¨a¨an eritasoisia palvelumalleja. NIST tunnistaa julkaisus- saan kolme palvelumallia tasoa: SaaS, PaaS ja IaaS.
Pilvipalveluiden yhteydess¨a k¨aytett¨av¨at *aaS-lyhenteet kuvaavat pilvipalveluiden tarjoamaa ab- straktiotasoa, eli mink¨atasoista hallintaa k¨aytt¨aj¨alle tarjotaan pilvipalvelussa.
2.1.1 IaaS
Pilvipalvelumalleista matalimman tason abstraktion tarjoaa Infrastructure as a Service (IaaS), jossa k¨aytt¨aj¨alle tarjotaan mahdollisuus provisioida laskenta- tallennus- verkko- tai muita resurs- seja palvelualustalle. K¨aytt¨aj¨all¨a on l¨ahes t¨aysi k¨aytt¨oj¨arjestelm¨atason hallinta provisiotuihin resursseihin. K¨aytt¨aj¨a voi suorittaa resursseilla omia sovelluksiaan rajoituksetta. (Mell (2010);
K¨achele et al. (2013); Serrano (2015)) 2.1.2 PaaS
Platform as a Service (PaaS) on abstraktiotasoltaan IaaS:ia korkeammalla. PaaS:ssa pilvi- palveluntarjoaja huolehtii palvelun allaolevista laitteisto- ja j¨arjestelm¨aresursseista tarjoten k¨aytt¨aj¨alleen sovellusten suoritukseen kykenev¨an alustan, joka tukee tiettyj¨a ohjelmointikieli¨a kirjastoineen ja ty¨okaluineen. (Mell (2010); Srinivasan (2014))
2.1.3 SaaS
Software as a Service (SaaS) on pilvipalvelumalleista kauimmaksi laitteistosta abstraktoitu taso.
SaaS:ssa pilvipalveluntarjoaja tarjoaa k¨aytt¨aj¨alleen vain sovelluksen, joita k¨aytt¨aj¨a voi k¨aytt¨a¨a selaimella tai ohjelmarajapinnan (API) kautta. K¨aytt¨aj¨alle ei paljasteta sovelluksen alla olevia resursseja. (Mell (2010); Srinivasan (2014))
2.2 Serverless
Serverless, eli ”palveliton”suorittaminen on kasvava trendi pilvipalveluissa. Serverless eroaa ns.
perinteisest¨a pilvest¨a poistamalla k¨aytt¨aj¨alt¨a tarpeen resursoida laitteistoresursseja, kuten vir-
8
tuaalikoneita.
Er¨as serverless:n muoto on my¨os Function as a Service (FaaS), jossa suoritettava teht¨av¨a muotoil- laan usein melko pieniksi ja yksinkertaisiksi funktioiksi, jotka suoritetaan vain tarvittaessa. FaaS ja PaaS ovat l¨aheisi¨a k¨asitteit¨a, ja usein PaaS-palveluntarjoajat tarjoavatkin FaaS-palveluita.
(Sewak and Singh (2018))
Serverless-palvelumallissa k¨aytt¨aj¨a ei maksa etuk¨ateen allokoiduista resursseista. Maksu perus- tuu vain suoritettujen funktioiden m¨a¨ar¨a¨an ja niiden kuluttamiin resursseihin.
3. Q-Health
LUT-yliopiston Q-Health-tutkimusprojektissa toteutettiin j¨arjestelm¨a, jossa mitataan ihmisen kokonaisenergiankulutusta puettavalla mittalaitteella. Mittalaite l¨ahett¨a¨a mittausdatan pilvi- palveluun, josta k¨aytt¨aj¨a voi tarkastella ja ladata mittausdataa j¨alkik¨ateen. Projektin vaati- musm¨a¨arittelyss¨a pilvipalvelulle oli asetettu seuraavia vaatimuksia:
1. K¨aytt¨aj¨a tunnistautuu k¨aytt¨aj¨atunnuksella (esimerkiksi s¨ahk¨opostiosoitteella) ja salasanalla
2. K¨aytt¨aj¨alle n¨aytet¨a¨an vain omien laitteiden tuottama data 3. K¨aytt¨aj¨a voi valita ladattavan datan aikajakson
4. K¨aytt¨aj¨a voi ladata datan .csv -tiedostona 5. Selke¨at ohjetekstit ja k¨aytt¨oliittym¨a k¨aytt¨aj¨alle
Vaatimusm¨a¨arittelyss¨a listataan toiminnallisia vaatimuksia, joka j¨att¨a¨a teknisen toteutustavan sek¨a palveluntarjoajan valinnan vapaaksi.
Q-Health:ssa toteutettiin kes¨an 2017 aikana kuvan 2 mukainen mittausj¨arjestelm¨a Amazon AWS-pilvipalvelualustalle. Palveluntarjoajan valinta tapahtui projektiryhm¨an aiemman koke- muksen perusteella kyseisest¨a palvelualustasta. J¨arjestelm¨a toteutettiin k¨aytt¨aen serverless- palvelumallia, johon Amazonilla olisi ollut my¨os valmiita esimerkkiratkaisuja. Niit¨a ei kuiten- kaan p¨a¨adytty k¨aytt¨am¨a¨an, sill¨a j¨arjestelm¨an ollessa melko yksinkertainen, ei palveluresurssien automatisoitu luominen olisi kehitysty¨ot¨a nopeuttanut.
Kuvassa 2 esitet¨a¨an Q-Healthin j¨arjestelm¨an osat ja k¨aytetyt palvelut. Kuvassa punaisella nuolel- la merkataan k¨aytt¨aj¨an web-selaimen tekem¨an kutsun kulku eri palveluiden kautta. Q-Health:n verkkosivua haettaessa HTTP-kutsu ohjataan sis¨all¨onjakeluverkolle, mutta API:a kutsuttaessa kutsu ohjataan autentikaation kautta API-rajapinnalle. Kuvassa vihre¨all¨a merkatun mittalait- teen kutsut ohjataan oman autentikaation kautta API-rajapinnalle.
Kuva 2: Amazon AWS pilvipalvelualustalle toteutetussa j¨arjestelm¨ass¨a k¨aytetyt palvelut jaotel- tuna j¨arjestelm¨an arkkitehtuurin mukaan, sek¨a HTTP-kutsun reitti j¨arjestelm¨an l¨api
10
Pilvipalvelun arkkitehtuuri koostuu nimipalvelusta, k¨aytt¨aj¨aautentikaatiosta, API-rajapinnasta, tietokannasta sek¨a palveluohjelmasta.
3.1 AWS Lambda
AWS Lambda on Amazonin serverless-funktioita suorittava palvelu. Pilvipalvelun keskeinen osa, eli backendin toiminnallisuus toteutetaan serverless-funktioiden avulla Lambdassa. Backendin toiminnallisuus kirjoitettiin Node.js:ll¨a, sek¨a Pythonilla yksinkertaisten funktioiden muotoon, jotka jokainen suorittavat tietyn, tarkasti rajatun teht¨av¨an funktiota kutsuttaessa.
Funktioilla suoritetaan useita teht¨avi¨a: palautetaan frontendiin, eli k¨aytt¨aj¨an selaimeen halut- tuja tietoja, kuten mittauksen tila ja reaaliaikadata, selainpohjaisen mittausp¨ayt¨akirjan par- siminen ja tietokantaan tallentaminen, sek¨a reaaliaikadatan lukeminen datanker¨aimelt¨a. Lamb- dan funktiota kutsuttaessa REST sovellusrajapinnan (API) kautta funktiolle annetaan paramet- rein¨a HTTP-kutsun sis¨alt¨o, esimerkiksi POST-kutsun header ja body. Frontendist¨a funktioita kutsuttaessa n¨aihin liitet¨a¨an tarvittaessa data, joka halutaan l¨ahett¨a¨a backendiin, esimerkiksi mittausp¨oyt¨akirjan sis¨alt¨o tai selaimessa esitett¨av¨an mittausdatan aikav¨ali.
3.2 AWS API Gateway
Backendin kanssa kommunikoidaan REST API:n kautta. Amazon AWS-alustalla REST sovel- lusrajapinnat voidaan toteuttaa AWS API Gateway:ll¨a, joka integroituu tiukasti AWS Lambdan kanssa.
Lambda-proxyna Gateway ohjaa tulevat HTTP-kutsut Lambda-funktiolle. HTTP-kutsun vas- taus luodaan Lambdassa, esimerkiksi sen mukaan, onnistuiko kutsun k¨aynnist¨am¨an funktion suoritus vai tuliko suorituksessa jokin virhe tai jokin muu ei-odotettu tapahtuma.
AWS-Lambdan funktioille luodaan jokaiselle oma API-polku, jota kutsumalla funktion saa suo- ritettua. Sovellusrajapinta on t¨arke¨a¨a suojata, jotteivat ei-autentikoituneet k¨aytt¨aj¨at voi kutsua API-resursseja. API:n suojauksen voi API Gatewayssa toteuttaa useilla tavoilla riippuen API:n k¨aytt¨otarkoituksesta. Q-Healthissa API-rajapintaa kutsutaan k¨aytt¨aj¨an selaimessa suoritetta- valla javascript-ohjelmalla.
API:n autentikoinnissa k¨aytet¨a¨an AWS Cognitoa, joka suorittaa k¨aytt¨aj¨atunnuksien ja salasa- nojen tallentamisen, sek¨a onnistuneen autentikoinnin tapauksessa tokenin luomisen, jolla tun- nistaudutaan API:n resursseihin. Cognitoa kutsutaan selaimen javascriptist¨a suoraan AWS:n javascript SDK:n kautta. K¨aytt¨aj¨an sy¨ott¨aess¨a oikea k¨aytt¨aj¨atunnus-salasanayhdistelm¨an, Cog- nito palauttaa m¨a¨ar¨aajan voimassaolevan tokenin, jolla voidaan tunnistautua API Gatewayn resursseihin.
Toinen mahdollinen tapa tunnistautua API:lle on k¨aytt¨a¨a API-avainta, eli ennalta m¨a¨ar¨atty¨a salaista avainta, jonka tuntemalla APIa voi k¨aytt¨a¨a. Datanker¨ain k¨aytt¨a¨a API-avainta API Ga- tewayn kanssa kommunikoidessa. Jokaisella datanker¨aimell¨a on uniikki API-avain, joka voidaan vaihtaa tarvittaessa.
3.3 AWS S3
Datanker¨aimen tallentamat csv-datatiedostot s¨ail¨ot¨a¨an AWS S3-tiedostopalvelussa, jossa tiedos- tot tallennetaan nimettyihin kansioihin (engl. bucket). Kansioille m¨a¨aritell¨a¨an luontivaiheessa nimi, sijainti (engl. region), saatavuusluokka sek¨a p¨a¨asynhallinta. Jos Q-Healthille tulisi huo- mattava k¨aytt¨aj¨am¨a¨ar¨an lis¨ays, tulisi kannattavaksi siirt¨a¨a vanhat, ei usein k¨aytetyt mittausda- tatiedostot edullisempiin saatavuusluokkiin.
Q-Health-projektissa tallennettavien tiedostojen tulee olla suojattu siten, ett¨a niihin p¨a¨asee k¨asiksi vain palveluun kirjautuneet k¨aytt¨aj¨at, joten p¨a¨asynhallinnalla estet¨a¨an tiedostoihin p¨a¨asy ulkopuolisilta. Verkkok¨aytt¨oliittym¨a¨an kirjautuneelle k¨aytt¨aj¨alle muodostetaan ladattaviin tie- dostoihin kertak¨aytt¨oiset ja m¨a¨ar¨aaikaiset latauslinkit Lambda-funktion avulla. Linkin ollessa voimassa vain minuutin, voidaan olettaa ettei kukaan ulkopuolinen taho saa sit¨a k¨asiins¨a ja n¨ain saa p¨a¨asy¨a k¨aytt¨aj¨an dataan.
3.4 DynamoDB
DynamoDB on Amazonin NoSQL-tietokantapalvelu. Q-Healthissa DynamoDB:t¨a k¨aytet¨a¨an re- aaliaikadatan ja mittauksen tilan laitekohtaiseen tallentamiseen, mittausp¨oyt¨akirjojen tallen- tamiseen sek¨a k¨aytt¨ajien oikeuksien hallintaan. Tietokantaa luetaan ja kirjoitetaan ainoastaan p¨a¨asyhallitun REST-rajapinnan takana sijaitsevien Lambda-funktioiden kautta, jolloin tietokan- taan ei avata suoraa p¨a¨asy¨a julkisesta internetist¨a.
DynamoDB on t¨aysin hallittu (eng. fully managed) tietokanta tarkoittaen sit¨a, ettei tietokantaa tarvitse itse asentaa tai yll¨apit¨a¨a.
3.5 Cloudwatch
Koska Q-Healthin palvelu on avoinna julkiseen internetiin, on t¨arke¨a¨a pysty¨a tarkkailemaan pal- veluiden k¨aytt¨o¨a ja my¨os j¨alkik¨ateen analysoimaan mahdollisia h¨airi¨oit¨a palvelun toiminnassa.
Q-Healthissa lokitietoja ker¨at¨a¨an jokaisesta HTTP-kutsusta, jotka kutsuvat API:a sek¨a jokai- sesta vierailusta Q-Healthin verkkosivuilla. Lokitiedostoista voidaan selvitt¨a¨a my¨os mahdollisia vikatilanteita, joita sattuu backendin suorituksessa.
3.6 Route53 ja Cloudfront
Route53 on Amazonin verkkotunnusten hallintaty¨okalu, jolla Q-Healthin verkkotunnus on rekis- ter¨oity. Verkkotunnuksen tietueista voi asettaa tietueet osoittamaan suoraan AWS:n palveluihin, kuten Cloudfrontiin tai S3:een, jossa Q-Healthin staattiset HTML sivut sijaitsevat. Koska verk- kosivulla on kuvia ja muuta staattista sis¨alt¨o¨a, voidaan niiden latausta nopeuttaa k¨aytt¨am¨all¨a Cloudfront sis¨all¨onjakeluverkkoa (CDN), josta mediatiedostot latautuvat nopeasti.
3.7 Verkkok¨ aytt¨ oliittym¨ a
Toteutin verkkok¨aytt¨oliittym¨an verkkosivuna, johon k¨aytt¨aj¨a voi rekister¨oity¨a s¨ahk¨opostiosoitteellaan. Rekister¨oityneelle k¨aytt¨aj¨alle voidaan lis¨at¨a oikeuksia n¨ahd¨a eri mittalaitteiden data. Kuvassa 3 k¨aytt¨aj¨all¨a on oikeus laitteeseen QH-2. Koska projektilla
12
on kirjoitushetkell¨a vain kaksi mittalaitetta, en toteuttanut verkkok¨aytt¨oliittym¨a¨an admin- toiminnallisuuksia, jossa p¨a¨ak¨aytt¨aj¨a voisi laitteita lis¨at¨a, vaan ne t¨aytyy lis¨at¨a tietokantaan k¨asin.
Verkkok¨aytt¨oliittym¨ass¨a kirjautuneelle k¨aytt¨aj¨alle esitet¨a¨an omien mittalaitteiden status, joka kertoo, onko mittaus p¨a¨all¨a vai ei. Lis¨aksi laitteen pariston j¨annite annetaan millivoltteina.
Mittauksen aikana k¨aytt¨oliittym¨ast¨a voi tarkastella l¨ahes reaaliajassa mittalaitteen mittasignaa- leja. Signaalit esitet¨a¨an muutaman sekunnin v¨alein p¨aivittyv¨all¨a kuvaajalla.
Verkkok¨aytt¨oliittym¨an kautta voi tarkastella tehtyj¨a mittauksia kalenterin avulla. Kalenterin p¨aiv¨an kohdalla n¨akyy jokainen p¨aiv¨an aikana suoritettu mittaus omana tiedostonaan. P¨aiv¨a¨a tai tiedostoa klikkaamalla saa avattua ikkunan, josta halutut tiedostot voi ladata koneellensa.
Q-Health-tutkimusprojektin ihmismittausten mittausp¨oyt¨akirjat voi sy¨ott¨a¨a suoraan tietokan- taan verkkok¨aytt¨oliittym¨an avulla. K¨aytt¨aj¨alle esitet¨a¨an lomake, johon sy¨otet¨a¨an testihenkil¨on tietoja sek¨a mittausj¨arjestelyn tiedot.
Kuva 3: Q-Health-verkkok¨aytt¨oliittym¨a, jossa esitet¨a¨an saatavilla olevat mittaustiedostot kalen- terin¨akym¨ass¨a, sek¨a reaaliajassa mittalaitteelta tuleva mittausdata
3.8 Datanker¨ ain
Q-Healthin datanker¨aimen vaatimusm¨a¨arittely antaa paljon vapauksia tekniselle toteutukselle.
Vaatimusm¨a¨arittely asettaa laitteelle seuraavat reunaehdot: siin¨a on oltava Bluetooth, tallen- nustilaa, itsen¨ainen verkkoyhteys sek¨a jonkinlainen k¨aytt¨oliittym¨a.
Tutkimme mahdollisuutta k¨aytt¨a¨a Android-¨alypuhelinta datanker¨aimen¨a, sill¨a sellainen voidaan olettaa l¨ahes jokaiselta ihmiselt¨a l¨oytyv¨an. ¨Alypuhelimessa on oltava Bluetooth sek¨a datansiir- toon kykenev¨a matkapuhelinliittym¨a tai WiFi. Kyseiset ominaisuudet l¨oytyv¨at jokaisesta mo- dernista ¨alypuhelimesta.
Huomasimme kuitenkin ensimm¨aisell¨a testisovelluksella toteutetun testin yhteydess¨a Androidin olevan kykenem¨at¨on vastaanottamaan dataa Bluetooth beaconina toimivalta mittalaitteelta, sill¨a Androidin virranhallinta sulki dataa tallentavan sovelluksen puhelimen n¨ayt¨on sammuessa. Kos- ka rannekkeen ja datanker¨aimen¨a toimivan ¨alypuhelimen v¨alill¨a oli vain yksisuuntainen tiedon- siirtoyhteys, ei ranneke havainnut vastaanottavan laitteen sammumista, joten mittausdataa j¨ai tallentamatta.
Q-Healthin datanker¨ain p¨a¨adyttiin toteuttamaan Raspberry Pi-korttitietokoneella, joka k¨aytt¨a¨a GPRS-lis¨akorttia datayhteyden muodostamiseen. Raspberry Pi:hin p¨a¨adyimme sen ollessa en- nest¨a¨an tuttu tietokonealusta, jossa on my¨os sis¨a¨anrakennettu Bluetooth. Kehitysty¨o alustalla oli helppoa my¨os siit¨a syyst¨a, ett¨a rannekelaitteen valmistaja oli julkaissut avoimen l¨ahdekoodin esimerkkisovelluksen Python-ohjelmointikielell¨a, jonka p¨a¨alle pystyimme rakentamaan datan- ker¨aimen toiminnallisuuden.
Datanker¨ain saa virtansa 10000 mAh USB-varavirtal¨ahteest¨a, jonka avulla se kykenee tallenta- maan dataa itsen¨aisesti ilman ulkoista virtaa noin 18 tuntia. Varavirtal¨ahteen valintakriteerin¨a oli sen kykenevyys l¨apilataukseen, eli sen on kyett¨av¨a sy¨ott¨am¨a¨an virtaa samaan aikaan, kun sit¨a ladataan. T¨am¨a mahdollistaa datanker¨aimen k¨ayt¨on pidempi¨a ajanjaksoja kerrallaan.
K¨aytt¨oliittym¨a datanker¨aimelle toteutettiin kahdella LED:ll¨a, jotka indikoivat laitteen tilaa sek¨a kytkimell¨a, joka kytkee tallennuksen p¨a¨alle. Laitteen ensimm¨ainen LED n¨aytt¨a¨a onko laite p¨a¨all¨a ja onko se saanut haettua NTP-protokollaa hy¨odynt¨aen internetist¨a oikean ajan. Toinen LED indikoi Bluetooth-yhteytt¨a rannekkeeseen.
3.9 Testaus ja kokemukset
Testasin Q-Healthin verkkosivua Chromium-selaimen kehitt¨aj¨aty¨okalulla. Mittasin sivuston suo- rituskyky¨a ’Performance’-ty¨okalun avulla kirjautumalla sivustolle sis¨a¨an. Sivu latautui 733 milli- sekunnissa. Sis¨a¨ankirjautuessa sivuston latautuminen kesti noin 1600 millisekuntia, mist¨a suurin osa ajasta kului API:n vastausta odottaessa. Hitaimmat API-kutsut ovat tietokantaoperaatioita suorittavia, kuten mittauksen tilaa ja reaaliaikadataa lukevat funktiot.
Q-Healthin verkkosivusto on kirjoitushetkell¨a ollut k¨ayt¨oss¨a noin vuoden. K¨ayt¨on mukaan hin- noiteltuja palveluita hy¨odynt¨am¨all¨a kuukausittaiset toteutuneet kustannukset ovat j¨a¨aneet jopa alle euroon niilt¨a kuukausilta, kun palvelua ei juuri ole k¨aytetty. Muina kuukausina laskua pal- veluista on tullut joitakin euroja. Suurin kustannus on ollut .fi domain.
Datanker¨ain on osoittautunut k¨ayt¨oss¨a luotettavaksi. Suurin ongelma on ollut Raspberry Pi:n ohjelmistojen ja koodin p¨aivitys matkapuhelinverkon yli. Yhteyden ollessa hidas, j¨arjestelm¨an et¨ak¨aytt¨o on suoritettava vain silloin, kun laitteella ei tallenneta ja l¨ahetet¨a dataa. T¨am¨a vaatii yhteydenpitoa kehitt¨aj¨an ja k¨aytt¨aj¨an v¨alill¨a, joka on osoittautunut haasteelliseksi, joten ohjel- mistop¨aivitykset on jouduttu suorittamaan y¨oaikaan, kun laitetta ei ole k¨aytetty.
J¨arjestelm¨a¨an on k¨aytt¨o¨onoton j¨alkeen k¨aytt¨ajien toiveesta lis¨atty joitakin uusia ominaisuuksia, mutta arkkitehtuurillisesti mik¨a¨an ei ole muuttunut. J¨arjestelm¨a on osoittautunut toimivan hy- vin ja melko luotettavasti. Yksitt¨aisi¨a ongelmia on kuitenkin ilmennyt backendin python-kielell¨a kirjoitettujen funktioiden sek¨a frontendin javascript-kirjastojen p¨aivitysten my¨ot¨a.
14
Verkkosivun hitaimmat osiot, eli tietokantaa lukevat API-kutsut tulisi toteuttaa nopeammin.
Tulisi tutkia, onko mahdollista s¨ail¨o¨a API:n vastauksia v¨alimuistiin, jotta hitaita tietokantao- peraatioita ei tarvitsisi suorittaa joka sivunlatauksella. Toteutus vaatisi kuitenkin tarkistuksen, onko tietokannan sis¨alt¨o muuttunut suorituskertojen v¨aliss¨a, mik¨a voi olla haasteellista.
Toinen vaihtoehto hitaalle tietokantakutsulle olisi k¨aytt¨a¨a DynamoDB:n DAX muistikiihdytetty¨a v¨alimuistipalvelua. Palvelu k¨aytt¨a¨a AWS EC2-virtuaalikoneita, jotka ovat kuukausihinnoiteltuja, joten pilvipalvelun kuukausittainen hinta jopa moninkertaistuisi.
4. Alustojen ja palveluiden vertailu
Suurimmat julkisia pilvipalveluita tuottavat yritykset ja niiden pilvipalvelualustat ovat Amazon Web Services (AWS), Google Cloud, IBM Cloud ja Microsoft Azure. ( Srinivasan (2014); Sadaqat et al. (2018); BusinessWire (2015))
Gartnerin helmikuussa 2019 julkaisemassa raportissa lasketaan hyperskaalan palveluntarjoajiksi edell¨amainittujen lis¨aksi Alibaba Cloud sek¨a Oracle Cloud. (Lowery et al. (2019)) L¨ansimaissa Alibaban pilvipalvelu kuitenkaan ei ole saavuttanut suurta suosiota, joten en k¨asittele sit¨a t¨ass¨a kandidaatinty¨oss¨a. Lukemassani kirjallisuudessa Oracle Cloudia ei ole juuri mainittu, joten j¨at¨an my¨os sen k¨asittelyn ulkopuolelle.
J¨arjestelm¨a toteutettiin Amazon AWS pilvipalvelualustalle projektiryhm¨an aiemman kokemuk- sen perusteella. Amazonin lis¨aksi harkinnassa oli my¨os IBM Bluemix ja Microsoft Azure. Mui- takin palveluntarjoajia sek¨a valmiita palveluita tarkasteltiin, mutta ne todettiin jo varhaisessa vaiheessa sopimattomaksi projektin toteuttamiseen.
4.1 Pilvipalvelumallin valinta
Q-Health-tutkimusprojektin mittausj¨arjestelm¨all¨a vain muutamia samanaikaisia k¨aytt¨aji¨a, joten ne eiv¨at aiheuta suuria kuormia pilvipohjaiselle j¨arjestelm¨alle. J¨arjestelm¨an tulee kuitenkin olla tulevaisuutta ajatellen skaalautuvissa yl¨osp¨ain, jos k¨aytt¨aj¨am¨a¨ar¨a lis¨a¨antyisi runsaasti.
Pilvipalvelumalleista skaalauksen ja kuormantasauksen kannalta hyvi¨a vaihtoehtoja ovat PaaS, SaaS ja FaaS, sill¨a niiss¨a pilvipalveluntarjoaja huolehtii resurssien skaalauksesta kuorman vaihte- lun mukaan. IaaS:ssa kuormantasaus on toteutettava itse parhaaksi katsomallaan tavalla. (Mall and Sharma (2018)) Jos j¨arjestelm¨an kuormitus vaihtelee ajan my¨ot¨a, joutuu j¨arjestelm¨an mi- toittamaan huippukuorman mukaan vaikka sit¨a olisi vain pieni osa ajasta. Jos palveluresursseja - esimerkiksi virtuaalikoneita - ei vapauta tai sammuta vajaakuorman aikana, joutuu maksa- maan t¨aytt¨a hintaa my¨os hiljaiselta ajalta. Jos j¨arjestelm¨a¨a kuormitetaan tasaisesti, voi olla laskentateho olla edullisinta IaaS:lla.
Infrastructure as a Service voi olla FaaS:ia edullisempi my¨os j¨arjestelm¨ass¨a, jossa j¨arjestelm¨an palveluita kutsutaan hyvin tihe¨asti, sill¨a FaaS:n hinnoittelu perustuu suoritusten lukum¨a¨ar¨a¨an.
(Eivy (2017))
Q-Healthin pilvisovelluksen kehitt¨amiseen oli vain rajattu m¨a¨ar¨a aikaa, joten valitsin pilvipalve- lumalliksi FaaS:n sen skaalautuvuuden sek¨a kehitysty¨on nopeuden vuoksi. FaaS:n etu on my¨os sen yll¨apidon helppous, sill¨a ohjelmistop¨aivityksist¨a ei v¨altt¨am¨att¨a tarvitse huolehtia itse. FaaS- palvelut usein integroituvat hyvin pilvipalveluntarjoajan muihin palveluihin niiden API:en kaut- ta, eik¨a palveluntarjoajan omia resursseja kutsuessa tarvitse erikseen autentikaatiota. Q-Health:n pilvipalvelun olisi voinut toteuttaa my¨os IaaS tai PaaS palvelumallia. IaaS:lla j¨arjestelm¨a oli- si toteutettu k¨aytt¨aen Linux, Apache, MySQL ja PHP (LAMP)-ohjelmistokokonaisuutta (eng.
LAMP stack).
Palvelumallin valinta vaikuttaa eniten toteutettavan j¨arjestelm¨an kehitysty¨oh¨on. Jos totetutetta- va j¨arjestelm¨a voi hy¨odynt¨a¨a Software as a Service-tasoista palvelua, on kehitysty¨o huomattavasti nopeampaa verrattuna esimerkiksi Infrastructure as a Service-palvelumalliin, jossa esimerkiksi
16
ohjelmistot ja tietokannat on asennettava tai kehitett¨av¨a itse. IaaS antaa kuitenkin enemm¨an vapautta kehitt¨aj¨alle k¨aytt¨a¨a haluamiaan ty¨okaluja ohjelmistokehityksess¨a. IaaS helpottaa my¨os palveluntarjoajan vaihtamista toiseen, jos ohjelmakoodi ei ole riippuvaista palveluntarjoajan pal- veluista, vaan niit¨a suoritetaan jonkin k¨aytt¨oj¨arjestelm¨an p¨a¨all¨a.
Puhuttaessa backendin arkkitehtuurista tai palveluntarjoajasta, loppuk¨aytt¨aj¨alle ei tule n¨akyviin mill¨a tavalla backend on toteutettu.
4.2 Palveluntarjoajien tarjonnan vertailu
Vertailen Amazon AWS:n, Microsoft Azuren ja IBM Cloudin palvelutarjontaa ja niiden soveltu- vuutta Q-Healthin mittausj¨arjestelm¨a¨an.
Tietokannat
Backendiss¨a tarvitaan tietokantoja tiedon tallentamiseen ja k¨asittelyyn. Tietokantojen p¨a¨atyypit ovat SQL ja NoSQL, eli relationaalinen ja ei-relationaalinen tietokanta.
Palveluntarjoajilla on tietokannan k¨aytt¨otarkoituksesta riippuen useita vaihtoehtoja tietokan- noille. Azuressa ja AWS:ss¨a vaihtoehtoja on noin kymmenen, IBM:ll¨a jopa yli kaksikymment¨a.
Jos palveluntarjoajalla ei ole sopivaa tietokantaa, oman tietokannan voi asentaa esimerkiksi pil- vialustalla suoritettavalle virtuaalikoneelle tai Docker-konttiin.
Q-Healthissa tietokantoja tarvitaan reaaliaikaisen mittausdatan tallentamiseen sek¨a k¨aytt¨ajien tietojen tallentamiseen. K¨aytt¨o¨on soveltuu molemmat tietokantatyypit, joten tietokannan valin- nan voi tehd¨a vapaasti saatavilla olevista tietokannoista.
Tiedostos¨ail¨ot
Samoin kuin tietokannoissa, palveluntarjoajilla on tiedon tallentamiseen useita vaihtoehtoja k¨aytt¨okohteesta riippuen: nopeista ja suorituskykyisist¨a pitk¨aaikaiseen tiedon arkistointiin. Tie- donsiirron nopeus ja latenssi ovat suoraan verrannollisia palvelun hintaan. Pitk¨aaikaiseen tiedon s¨ailytt¨amiseen suunnatut palvelut, kuten AWS Glacier tai IBM Cloud Object Storagen Cold Vault, ovat tallennuskapasiteetin hinnaltaan huomattavia m¨a¨ari¨a edullisempia, mutta hitaam- pia verrattuna AWS S3:een tai IBM Cloud Object Storagen standard-luokkaan.
Palvelu Tier Hinta,
dollaria per GB Sijainti
AWS AWS S3 Standard 0.0245 Frankfurt
IBM IBM Cloud Object Storage Standard 0.0242 -
Microsoft Azure Storage Blobs Cool 0.01 Noth Europe
Taulukko 1: Pilvipalveluntarjoajien tiedontallennuspalveluiden hinta (tilanne 23.4.2019) Q-Healthissa tiedostos¨ail¨o¨on tallennetaan mittauksissa ker¨att¨av¨a data csv-tiedostojen muodos- sa. Tiedostoihin on kyett¨av¨a tarjoamaan turvallinen p¨a¨asy Q-Healthin verkkok¨aytt¨oliittym¨an kautta kirjautuneille k¨aytt¨ajille. Tallennettavan tiedon m¨a¨ar¨a laitetta kohti on joitakin kymme- ni¨a megatavuja vuorokaudessa, joten tallennustilan hinta ei muodostu ratkaisevaksi tekij¨aksi.
Kuten taulukosta 1 n¨ahd¨a¨an, on Azuressa edullisin tallennustila AWS:n ja IBM:n ollessa l¨ahes kaksikertaa kalliimpia siihen n¨ahden.
AWS S3:n API on muodostunut de-facto standardiksi pilvipalveluissa. S3 API:a tukee my¨os IBM:n Cloud Object Storage sek¨a Azuren Blob Storage. (IBM (2018); Zhang (2016))
Serverless funktiot
Serverless-funktiot tarjoavat FaaS-palvelumallin mukaisesti keinon suorittaa koodia pilvess¨a.
Serverless funktioita on mahdollista k¨aytt¨a¨a tarkasteltavilla palveluntarjoajilla. Amazon AWS- palvelussa funktioita voi suorittaa AWS Lambdassa, Microsoft Azuressa palvelu on Azure func- tions ja IBM:ll¨a IBM Cloud functions. Kaikki palveluntarjoajat eiv¨at paljasta allaolevaa arkkiteh- tuuria. IBM kuitenkin kertoo palvelun pohjautuvan Apachen avoimen l¨ahdekoodin OpenWhisk- alustaan. (IBM (2019))
Serverless-funktioita voi kutsua palveluissa ulkopuolelta API-rajapinnan kautta tai niille voi asettaa palveluntarjoajan pilvipalveluiden sis¨alt¨a k¨aynnistimi¨a (eng. trigger), jotka suorittavat funktioita esimerkiksi tietokannan tietueen p¨aivittyess¨a.
Q-Healthin backendin funktiot ovat toteutettu sek¨a Pythonilla, ett¨a Node.js:ll¨a, joten taulukon 2 mukaan funktiot voisi toteuttaa kaikilla kolmella palveluntarjoajan alustalla valituilla ohjelmoin- tikielill¨a. IBM Cloud tukee taulukossa 2 mainittujen lis¨aksi my¨os muita ohjelmointikieli¨a, jos nii- den suoritusymp¨arist¨ot asentaa Docker-konttiin (eng. container). My¨os AWS:¨a¨an ja Azureen voi asentaa Docker-kontteja, mutta serverless-funktioiden dokumentaatioissa t¨at¨a mahdollisuutta ei tuoda esiin.
Azure AWS IBM Cloud
Javascript / Node.js K K K
Java K K K
Python K K K
Go E K K
PHP E E K
Ruby E K K
C# K K K*
Powershell K K K*
*vaatii erillisen asennuksen
Taulukko 2: Pilvipalveluntarjoajien FaaS-palveluiden tukemat ohjelmointikielet
Hinnoittelu ja free-tier
Tarkasteltavat palveluntarjoajat ovat hinnoitelleet tuotteensa hieman eri tavoin. Osa palveluista tarjotaan kokonaan ilmaiseksi, ja muista voidaan tarjota kuukausittain pieni m¨a¨ar¨a resursse- ja ilmaiseksi. Ilmaisen osuuden ylitt¨av¨ast¨a k¨ayt¨ost¨a maksetaan hinnaston mukaan: joko aika-, resurssin k¨aytt¨o- tai vakiohinnalla.
Palveluntarjoajilla on sivustoillaan laskureita, joiden avulla voidaan arvioida palvelun k¨ayt¨on hintaa sy¨ott¨am¨all¨a tarvittavat tiedot, kuten montako virtuaalista suoritinta tarvitaan tai kuinka suuri m¨a¨ar¨a liikennett¨a palvelun kautta kulkee kuukaudessa. Laskurit voivat ottaa huomioon free-tierin, jolloin ilmaiset resurssit pienent¨av¨at kuukausihintaa.
Jokaisella kolmesta k¨asitelt¨av¨ast¨a palveluntarjoasta on tarjolla FaaS-palvelu, joihin kukin tarjoaa joka kuukausi 400000 GB-s (Gigatavu-sekuntia) suoritusta ilmaiseksi. T¨am¨a tarkoittaa esimer-
18
kiksi 100 ms suoritusajalla ja 256 MB RAM m¨a¨ar¨all¨a 15625000 ilmaista suorituskertaa kuukau- dessa. Q-Health-projektissa backendin ja frontendin vaatimat suorituskerrat tulevat j¨a¨am¨a¨an kaikilla palveluntarjoajilla free-tierin rajojen alle, jos palvelulla on vain yksitt¨aisi¨a k¨aytt¨aji¨a, kuten kirjoitushetkell¨a.
Q-Health:n pilvipalvelutoteutuksen FaaS-toteutuksen ja pienen k¨aytt¨aj¨am¨a¨ar¨an johdosta pil- vipalveluntarjoajasta riippumatta kuukausittainen kustannus j¨a¨a pieneksi. Koska voidaan hy¨odynt¨a¨a free-tierin ilmaisia suorituksia ja muita resursseja, ei palvelusta tarvitse aikana, jol- loin kukaan ei sit¨a k¨ayt¨a, maksaa ollenkaan. IaaS-palvelumallin pienin kuukausittainen hinta muodostuisi siit¨a, mink¨atehoista, tai montako virtuaalikonetta palvelussa k¨aytett¨aisiin.
4.3 Palveluntarjoajan valinta
Vertailluilla palveluntarjoajilla on jokaisella laaja palvelukattaus joista valita k¨aytett¨av¨at palve- lut. Koska ohjelmistokehityksess¨a on harvoin yht¨a ainutta oikeaa tapaa tehd¨a asioita, voi samaan lopputulokseen p¨a¨aty¨a k¨aytt¨am¨all¨a toisiinsa n¨ahden t¨aysin erilaisia palvelualustoja ja palvelun- tarjoajia.
Palveluntarjoajan valinta perustui Q-Health:ssa kehitystiimin aikaisempaan kokemukseen Amazon AWS alustasta. T¨am¨an tutkimuksen tuloksena n¨ahd¨a¨an, ett¨a valinnalla ei v¨altt¨am¨att¨a ollut suurtakaan merkityst¨a totetutuneen lopputuloksen kannalta. IBM:ll¨a sek¨a Microsoftilla olisi ollut opiskelijalisenssill¨a mahdollista toteuttaa j¨arjestelm¨a joksikin aikaa ilmaisesti, mutta olisi mahdollisesti lisenssiehtojen vastaista k¨aytt¨a¨a palveluita tutkimukseen, josta on mahdollisesti tarkoitus tehd¨a liiketoimintaa.
Palveluntarjoajien ollessa palveluiden saatavuudeltaan l¨ahes yhdenvertaiset, voi alustan valinnan tehd¨a pienempien yksityiskohtien ja asioiden perusteella. Jos valintakriteeri on esimerkiksi hinta, kannattaa k¨aytt¨a¨a palveluntarjoajien tarjoamia laskureita, joilla hinnasta saa tarkan arvion. Jos puolestaan on tarve jonkin tietyn ohjelmointikielen tai esimerkiksi tietokannan k¨ayt¨olle, voi valinnan tehd¨a niiden tarpeiden mukaan.
5. Yhteenveto
Q-Health-projektille toteutettiin pilvipohjainen mittausj¨arjestelm¨a. Palvelumalliksi valittiin Function as a Service (FaaS), ja palveluntarjoajaksi Amazon AWS. Tutkimuksen tuloksena saa- tiin selville, ett¨a Q-Health:n kaltaisessa datanker¨aysj¨arjestelm¨ass¨a FaaS on j¨arjestelm¨an suori- tuskyvyn skaalautumisen, hinnoittelun sek¨a kehitysty¨on nopeuden kannalta edullinen vaihtoehto IaaS:een ja PaaS:een verrattuna.
Palveluntarjoajista vertailtiin Amazon AWS:¨a¨a, IBM Cloudia sek¨a Microsoft Azurea. Palvelun- tarjoajien palvelukattauksesta vertailtiin vain Q-Health:n FaaS-arkkitehtuuria vastaavia palve- luita, eroavaisuuksia, sek¨a niiden soveltuvuutta toteutettuun j¨arjestelm¨a¨an. Palveluntarjoajilla selvisi olevan hyvin samankaltainen paletti palveluita, joten j¨arjestelm¨an olisi voinut toteuttaa tutkituista palveluntarjoajista mill¨a tahansa.
Palvelumallin olisi voinut valita Q-Health:ssa kolmesta tutkitusta sen mukaan, mik¨a ohjelmisto- kehitt¨aj¨ast¨a vaikuttaa kokonaisuudessaan sopivimmalta. Vaikutusta loppuk¨aytt¨aj¨alle n¨akyv¨a¨an lopputulokseen ei v¨altt¨am¨att¨a valinnasta tule, vaan palvelumallin ja palveluntarjoajan valinta vaikuttaa l¨ahinn¨a ohjelmistokehitysty¨oh¨on ja ty¨okaluihin.
Pienen k¨aytt¨aj¨akunnan pilvipohjaisessa mittausj¨arjestelm¨ass¨a, kuten Q-Healthissa palvelu on j¨arkev¨a¨a toteuttaa FaaS:lla. Jos kehitet¨a¨an palvelua, jolla on tuhansia k¨aytt¨aji¨a tai samanaikai- sesti dataa l¨ahett¨avi¨a laitteita, ei FaaS toteutettuna t¨ass¨a tutkimuksessa k¨asitellyill¨a palveluilla olisi en¨a¨a kustannusten puolesta j¨arkev¨a, vaan kannattaa siirty¨a k¨aytt¨am¨a¨an IaaS-palvelumallia, jossa yksitt¨aisist¨a suorituksista ei tarvitse maksaa. T¨all¨oin voitaisiin k¨aytt¨a¨a esimerkiksi Docker- kontteja tai virtuaalikoneita, joissa ohjelman suoritus tapahtuisi.
Tulevissa projekteissa, joissa toteutetaan pilvipohjaisia j¨arjestelmi¨a, voin t¨ast¨a tutkimuksesta ja Q-Health-projektista oppineena todeta, ett¨a j¨arjestelm¨akokonaisuus kannattaa suunnitella ja dokumentoida hyvin jo etuk¨ateen, ettei tule odottamattomia yll¨atyksi¨a en¨a¨a tekovaiheessa. Q- Health-projektissa palveluntarjoajan ja palvelumallin valinnat tehtiin hyvin kevyin perustein.
Jos projekti toteutettaisiin uudestaan, dokumentoisin ja automatisoisin l¨ahes kaikki ty¨ovaiheet, jotta niit¨a pystyisi hy¨odynt¨am¨a¨an tulevissa projekteissa.
20
L ¨ AHTEET
BusinessWire (2015).Research and Markets: IT Market in ANZ 2015-2019: Key Vendors are AWS, Google, HP & IBM.
Eivy, A. (2017). Be Wary of the Economics of ”Serverless”Cloud Computing.IEEE Cloud Computing, 4(2), pp. 6–12.
IBM (2018).Object Storage in the IBM Cloud. url: https:
//cloud.ibm.com/docs/services/ibm-cos?topic=ibm-cos-object-storage-in-the-ibm-cloud.
IBM (2019).IBM Cloud Functions documentation. url:
https://cloud.ibm.com/docs/openwhisk.
K¨achele, S., Spann, C., Hauck, F.J., and Domaschka, J. (2013).Beyond IaaS and PaaS: An extended cloud taxonomy for computation, storage and networking.
Lowery, C., et al. (2019).Magic Quadrant for Public Cloud Infrastructure Professional and Managed Services, Worldwide. url:
https://www.gartner.com/doc/reprints?id=1-67RUNRP&ct=190211&st=sb.
Mall, S. and Sharma, A. (2018).Analyzing Load on Cloud: A Review.
Mell, P. (2010). The NIST Definition of Cloud Computing.Association for Computing Machinery.Communications of the ACM, 53(6), p. 50.
Sadaqat, M., Colomo-Palacios, R., and Knudsen, L.E.S. (2018). Serverless computing: a multivocal literature review.
Serrano, N. (2015). Infrastructure as a Service and Cloud Technologies.IEEE Software, 32(2), pp. 30–36.
Sewak, M. and Singh, S. (2018).Winning in the Era of Serverless Computing and Function as a Service.
Srinivasan, S. (2014).Cloud computing basics. Springer. ISBN 9781-461476993.
Zhang, R. (2016).Access Azure Blob Storage from Your Apps using S3 Java API. url:
https://www.microsoft.com/developerblog/2016/05/22/
access-azure-blob-storage-from-your-apps-using-s3-api/.
