Användning

Lambda och GCF används på liknande vis, men har vissa skillnader när det kommer till krav på koden som ska köras.

Tabell B.1: Körtidsmiljöer som stöds

AWS Lambda Google Cloud Functions

Körtidsmiljö Versioner Körtidsmiljö Versioner

Node.js 4.3, 6.10, 8.10 Node.js 6.11.5

C# .NET Core 1.0, .NET

Core 2.0

Go 1.x

Java 8

Python 2.7, 3.6

I tabell B.1 visas vilka körtidsmiljöer som stöds av de båda plattformarna. Lambda har stöd för ett antal olika programspråk och versioner. Google har valt att endast använda en körtidsmiljö i GCF.

Förutom programspråk ställer även användningen av serverlös teknik i dessa två fall ytterli- gare krav på koden. Det är enkelt att se vad som krävs i de båda fallen genom att undersöka exempel i dokumentationen för respektive tjänst. Nedan visas exempel för en Lambdafunk- tion samt två typer av GCF. Alla exemplen använder sig av körtidsmiljön Node.js och pro- gramspråket Javascript.

AWS Lambda

Exempel på Lambdafunktion [46]:

1 exports.myHandler = function(event, context) {

2 ...

3 }

I ovanstående kodexempel syns en så kallad ”lambda handler”, det vill säga den funktion som kallas på när Lambdafunktionen invokeras. Som parametrar till funktionen kommer in- formation om eventet som invokerade funktionen (som metadata och nyttolast). Utvecklare får även via parametrarna tillgång till minimal information om funktionens körtidsmiljö, ex- empelvis information om loggström, maximal återstående körtid etc.

Google Cloud Functions

GCF finns i två varianter, ”HTTP” och ”Background”. På samma sätt som vid användning av Lambda krävs en funktion med en specifik signatur som körs när GCF invokeras.

B.5. Resultat

1 /**

2 * HTTP Cloud Function.

3 *

4 * @param {Object} req Cloud Function request context.

5 * @param {Object} res Cloud Function response context.

6 */

7 exports.helloHttp = (req, res) => {

8 res.send(`Hello ${req.body.name || 'World'}!`); 9 };

En HTTP Function använder protokollet HTTP för invokation och svar och tar in två parametrar: ett objekt som motsvarar en HTTP-förfrågan och ett objekt som motsvarar ett HTTP-svar.

En GCF av typen Background är tänkt att köra i bakgrunden och kommunicera direkt med andra molntjänster som Google tillhandahåller. Denna typ av GCF är relativt lik ovanstående kodexempel. Exempel [47]:

1 /**

2 * Background Cloud Function.

3 *

4 * @param {object} event The Cloud Functions event.

5 * @param {function} callback The callback function.

6 */

7 exports.helloBackground = (event, callback) => {

8 callback(null, `Hello ${event.data.name || 'World'}!`); 9 };

För att skapa en Lambdafunktion eller GCF kan ett grafiskt webbgränssnitt användas där ut- vecklare specificerar körtidsmiljö (för Lambda), invokationstyper (se sektion B.5.3) och funk- tion att anropa vid invokation. I detta gränssnitt kan även vissa begränsningar anpassas (se sektion B.5.4).

B.5.3

Invokation

Lambda kan invokeras direkt av ett urval av de andra tjänsterna Amazon tillhandahåller, exempelvis API-gateway, Internet-of-Things-plattform, röststyrningstjänst, monitorering, kodhantering, databas, livestreaming, lagring och meddelande-/notifieringssystem. Det är även möjligt att invokera en Lambdafunktion programmatiskt eller via ett kommandorads- program. För varje av tidigare nämnda tjänster finns det flera olika alternativ. Ett exempel kan vara att invokera en Lambdafunktion varje gång en fil läggs till på ett visst lagringsmedia. GCF kan också invokeras direkt genom vissa av Googles molntjänster. Bredden på dessa är dock mindre omfattande jämfört med Lambda. De molntjänster som kan invokera GCF är i dagsläget ett notifierings- och meddelandesystem (”Cloud Pub/Sub”) och lagringstjänst (”Cloud Storage”). Utöver detta kan utvecklare invokera GCF direkt med protokollet HTTP samt via ett kommandoradsprogram.

I båda fallen ovan kan de flesta av leverantörens övriga tjänster användas genom ett medde- landesystem för att invokera en serverlös funktion.

B.5.4

Begränsningar

I tabell B.2 listas de explicita begränsningar som finns vid användande av Lambda och GCF.

B.5. Resultat

Begränsning Utökningsmöjlighet

Attribut Lambda GCF Lambda GCF

Källkod 250 MB 500MB Nej Nej

Minnesallokering 3008 MB 2048 MB Nej Nej

Nyttolast1_{vid invokering 6 MB 10 MB Nej Nej}

Temp. lagring2 512 MB 0 MB Nej Nej

Körtid 300 sekun-

der

540 sekun- der

Nej Nej

Samtidiga körningar 1000 st3 1000 st4 Ja Nej

För GCFs ”HTTP functions” finns även en mjuk gräns på en miljon invokation per 100 se- kunder.

Ur tabell B.2 framgår det att riktigt stora applikationer ej går att driftsätta på enskilda in- stanser av varken Lambda eller GCF. Dels på grund av begränsningen gällande storleken på källkod och dels på grund av den maximala exekveringstiden. Det är inte heller möjligt att skicka med stora mänger data vid invokation.

Utvecklare kan vid skapande eller ändring av en Lambda eller GCF specificera minnesalloke- ring och körtidsgräns. För Lambda kan minnesallokeringen väljas i 64 MB-inkrementeringar från 128 MB upp till 3008 MB. För GCF kan minnesallokeringen väljas utifrån nivåerna 128 MB, 256 MB, 512 MB, 1024 MB och 2048 MB.

Prismodell

Båda leverantörerna tar betalt för någon form av körtid, minnesanvändning och antal invo- kationer. Både vid användning av Lambda och GCF finns ett antal steg att välja mellan när det kommer till minnesallokering, de anpassas alltså inte dynamiskt vid körtid utan bestäms i förhand. Varje nivå av valbar minnesallokering i GCF har en tillhörande processorkapacitet [48, 49]. Det sistnämnda gäller även för Lambda, men det uttalas inte exakt vilken proces- sorkapacitet som tillhandahålls vid de olika nivåerna av minnesallokering [50].

Den lägsta minnesanvändningen som debiteras är 128 MB och körtiden debiteras per 100 millisekunder, avrundat uppåt.

Prismodellen för Lambda presenteras i tabell B.3 nedan. Prismodellen för GCF kan även hit- tas i tabell B.4, priserna för GCF kommer ej användas i jämförelsen mellan Lambda och EC2, men det går att se att prismodellerna för Lambda och GCF har den gemensamma aspekten att endast användning debiteras.

Tabell B.3: Prismodell för Lambda (per månad)

Antal USD/invokation USD/GB-sekund

< 1 miljon invokationer 0

> 1 miljon invokationer 0,0000002

< 400000 GB-sekunder 0

> 400000 GB-sekunder 0,00001667

I tabell B.3 visas att innehavare av ett AWS-konto får invokera Lambdafunktioner en miljon gånger i månaden och får även köra dessa i 400 000 GB-sekunder kostnadsfritt. Efter detta kostar en miljon invokationer 0,2 USD och en miljon GB-sekunder 16,67 USD.

1_{Engelska: ”Payload”} 2_{Utöver minnesallokering} 3_{Per AWS region}

B.5. Resultat

Tabell B.4: Prismodell för GCF (per månad)

Antal USD/invokation USD/GB-sekund USD/GHz-sekund

< 2 miljoner invokationer 0 > 2 miljoner invokationer 0,0000004 < 400000 GB-sekunder 0 > 400000 GB-sekunder 0,0000025 < 200000 GHz-sekunder 0 > 200000 GHz-sekunder 0,0000100

Kostnadsjämförelse - FaaS och IaaS

För att jämföra kostnaden av att använda serverlös teknik jämfört med IaaS används två exempel: ett exempel från [51] där prestandan hos en Node.js-baserad server analyserats och ett eget exempel som efterliknar det tidigare, fast för serverlös miljö. Båda exemplen tar in ett anrop och returnerar en sträng direkt.

1 var http = require('http');

2 http.createServer(function(req, res){

3 res.writeHead(200, {'Content-Type': 'text/plain'}); 4 res.end('Hellow World\\n');}).listen(8080, '127.0.0.1'); 5 console.log('Server localhost 8080');

Figur B.2: IaaS-applikation: Exempel som använts i studie kring prestanda med Node.js Källa: [51]

1 exports.handler = (event, context, callback) => { 2 console.log('Serverless handler');

3 callback(null, 'Hello World!'); 4 };

Figur B.3: FaaS-applikation: Exempel som skapats för denna undersökning

I experiment med Node.js på en fysisk maskin med en processorkärna och 2 GB minne visas att IaaS-applikationen klarar av att behandla 100 samtidiga anrop med 1000000 st i följd och då haft en medelsvarstid på 17 ms [51]. Detta innebär att denna konfiguration klarar av att behandla _17ms/anrop1000ms « 59 anrop per sekund och 100 samtidiga anslutningar, det vill säga 5900 anrop per sekund.

Vid körning av FaaS-applikationen med AWS SAM Local visade det sig att körtiden var mellan 7 och 20 millisekunder. Den maximala minnesanvändningen var 28 MB. Det betyder att en Lambdafunktion som motsvarar IaaS-applikationen kan konfigureras att allokera 128 MB (d.v.s. den lägsta möjliga nivån) samt att den debiterbara körtiden beräknas till 100 ms i detta fall. Det betyder att en körning av applikationen kostar 0,000000208 USD plus kostnaden för invokation. Detta ger en total kostnad för en körning på 0,000000408 USD exklusive rabatter.

IaaS tjänsten som valts till denna jämförelse är Amazon EC2 t2.small då även den har en processorkärna samt 2 GB minne [37]. EC2 har några olika typer av avtal med olika priser. I avtalet som kallas ”On-demand” kostar en EC2 t2.small 0,025 USD per timme (18 USD för 30 dagar).

B.6. Diskussion 0.5 1 1.5 2 2.5 ¨106 10 20 30

Antal invokationer per 30 dagar

Kostnad (USD) _{AWS Lambda}

Amazon EC2 t2.small

Figur B.4: Kostnad för invokationer vid 128 MB minnesallokering och 100 samtidiga körningar

I figur B.4 syns den konstanta kostnaden för IaaS-applikationen (EC2-instansen) i blått samt kostnaden för olika antal körningar av FaaS-applikationen (Lambdafunktionen) i orange. I detta exempel används de en miljon kostnadsfria invokationerna av Lambda. Dessutom nås aldrig ett sådant antal GB-sekunder att gränsen för kostnadsfria sådana överskrids. Det leder till att endast invokationer debiteras.

Från figuren kan det tydas att kostnaden för att använda serverlös teknik överstiger kostna- den för användning av IaaS när antalet invokationer börjar närma sig 2000000 stycken.

B.6

Diskussion

Detta avsnitt syftar till att diskutera metoden i sektion B.4 samt resultatdelen av denna bilaga. Först framläggs eventuella felorsaker och risker med metoden och sedan diskuteras olika aspekter ur resultatet utifrån frågeställningarna i B.1.2

B.6.1

Metod

Eftersom Lambda användes i projektet VATG har författaren av denna bilaga sedan tidigare en del erfarenhet av just Lambda, detsamma kan ej sägas om GCF. Det skulle kunna färga återgivningen av skillnaderna mellan de två tjänsterna.

För att ta fram för- och nackdelar med serverlös teknik har endast två leverantörer under- sökts. För att få en komplett bild av vilka möjligheter och begränsningar som finns kan fler tjänster utvärderas.

För att få en mer komplett bild av faktiska prisskillnader mellan att använda IaaS och FaaS bör verkliga applikationer testas och analyseras i respektive miljö. Att simulera med AWS SAM ger en bild av hur resultatet kan se ut vid driftsättning men många faktorer, exempelvis nätverksbelastning, tid sedan senaste invokation, specifik hårdvara och liknande kan påverka i verklig drift. Dessutom bör olika komplexitet av applikationer tas i beaktning. I denna bilaga har endast ytterst små applikationer analyserats för kostnadsjämförelse.

B.7. Slutsatser

B.6.2

Resultat

Ur resultatet av denna bilaga finns det mycket som tyder på olika för- och nackdelar med serverlös teknik. Att det är enkelt och går fort att driftsätta kod kan nog de flesta hålla med om, men av naturliga skäl medför det även många begränsningar och krav på hur denna kod ska vara utformad. I och med att konfigurationsmöjligheterna är begränsade krävs att det finns en funktion i koden med en viss signatur. Detta gäller dock även i vissa andra fall, se exempelvis ”public static void main(String[] args) ... ” i Java, som är ett annat standardiserat sätt att invokera en applikation. Det är kanske snarare begränsningarna kring körtid, minnesallokering samt kodstorlek som kan vara av intresse vid design och utveckling av nya applikationer. Stora monolitiska applikationer kan vara svåra att driftsätta med de serverlösa tekniker som undersökts i denna bilaga och kan istället behöva delas upp i flera mindre applikationer. De mindre applikationerna skulle eventuellt behöva ett gemensamt gränssnitt för att kommunicera med varandra. En sådan typ av lösning börjar likna något som kallas för mikrotjänster, något som leverantörer av serverlös teknik uppger vara användningsområdet för just sådan teknik. Mikrotjänster passar inte alla typer av applikationer, så det bör överses vid design av ny mjukvara.

En ytterligare aspekt som kan diskuteras är huruvida ägare av applikationer driftsatta i en serverlös miljö blir uppbundna till den nuvarande leverantören. Sköts hela driftmiljön av ägaren till applikationen kan denna miljö anpassas utan involvering av andra parter så som molntjänstleverantörer. Dessutom gör de smidiga integrationsmöjligheterna med leverantörens andra produkter att utvecklare eventuellt hellre väljer att använda dessa över andra leverantörers produkter.

Det går i resultatet att se en jämförelse som undersöker kostnader för användande av FaaS och IaaS. Beroende på vilken typ och mängd av trafik en applikation har kan olika typer av miljöer vara olika gynnsamma att använda. Det är också värt att notera att det är svårare att ha kontroll över och prediktera kostnaderna som kan uppstå vid användande av FaaS jämfört med IaaS eftersom IaaS oftast har en fast prismodell där kostnaden för en specifik tidsperiod är förbestämd. Sedan finns det nackdelar med en fast prismodell, kunder betalar samma kostnad oavsett kapacitetsutnyttjande. Både Google och Amazon tillhandahåller en viss mängd resurser utan kostnad, vilket kan vara till fördel vid liten användning.

B.7

Slutsatser

I denna bilaga har serverlös teknik undersökts och presenterats med avseende på för- och nackdelar, begränsningar samt kostnader. Slutsatser för respektive frågeställning i avsnitt B.1.2 presenteras nedan.

1. Finns det någon arkitektur som lämpar sig mer väl än andra för en serverlös produk-

tionsmiljö?

Det visar sig att applikationer som är uppbyggda i form av mikrotjänster lämpar sig för användning i en serverlös produktionsmiljö mer väl än monolitiska applikationer, till stor del på grund av de resursrelaterade begränsningar som är bestämda för de serverlösa tjänsterna.

2. Vilka designrelaterade begränsningar finns vid användning av serverlös produk-

tionsmiljö?

Det är tydligt att en serverlös miljö inför betydligt fler och striktare designrelaterade begränsningar än exempelvis att använda IaaS. Detta medförs av idéen att serverlös utveckling ska vara så enkel som möjligt, utan konfiguration och installation.

B.7. Slutsatser

3. Hur skiljer sig kostnaden för användning av Lambda jämfört med Amazon EC2? När det kommer till de ekonomiska aspekterna kring serverlös teknik är det svårt att dra några berikande generella slutsatser. Huruvida det lönar sig att använda serverlös teknik eller ej beror på många faktorer, både interna faktorer hos leverantören och även vilken typ av applikation och trafik som analyseras. Det som kan konstateras är att en- dast faktiskt användning debiteras, vilket kan vara fördelaktigt för applikationer med tillfällig eller skurvis användning. Det visar sig även vara betydligt svårare att predik- tera och kontrollera kostnaderna som kan uppstå vid användning av serverlös teknik.

C

Oliver Haberler: Amazon

Rekognition eller Google Vision

C.1

Inledning

Användningsområdena för bildbehandling och bland annat objektigenkänning är många, det kan vara allt från att detektera vad ett filmklipp handlar om till fordonsdetektion. Det finns en mängd företag som erbjuder olika typer av bildbehandling, men denna bilaga kommer fokusera på Amazon och Google och deras tjänster Rekognition respektive Vision. Rapporten kommer att undersöka vilka likheter och skillnader Rekognition och Vision har, samt vilken tjänst som hade varit bäst utifrån vårt projekt. Eftersom projektgruppens kund, Flowplayer, idag använder sig av AWS ville de att Rekognition skulle användas istället för Vision, för att underlätta hantering av data. Inom ramarna för projektet hade projektgruppen således inget behov av att undersöka Vision närmare, men att en undersökning ändå kunde göras för att se huruvida Vision var bättre. Rekognition och Vision är två molntjänster från Amazon Web Services, AWS, respektive Google Cloud Platform, GCP. Tjänsterna tillhandahåller analys av bilder och videor för att bland annat ta fram objekt, logotyper, kända personer med mera i bilder och filmklipp.

C.1.1

Syfte och mål

Syftet med rapporten är att undersöka vilka skillnader som finns mellan Rekognition och Vision, utifrån utdata, vilka tjänster de tillhandahåller och ur ett hållbarhetsperspektiv. Tan- ken med resultatet är att ställa dessa mot varandra och se hur vårt projekt eventuellt hade gynnats av Vision istället för Rekognition.

C.1.2

Frågeställningar

Från kapitlet ovan, Syfte och mål, kan vi se att följande frågeställningar ska besvaras:

1. Vilka egenskaper hos Google Vision skulle projektet kunna nyttja?

2. Vilken tjänst får ut bäst taggar, där bäst avser konfidensnivå på taggarna och om tag- garna generellt sett är bra utifrån vad en människa hade taggat?

C.2. Bakgrund

3. Vilken av tjänsterna, Amazon Rekognition eller Google Vision, är bäst ur ett hållbart perspektiv?

C.1.3

Avgränsningar

Undersökningen kommer att begränsa sig till att i första hand undersöka bilder och hur väl detektionen av objekt fungerar. Således kommer inte övriga tjänster av Vision eller Rekognition att undersökas i denna rapport. Olika bildkvalitetér kommer inte att jämföras. För att besvara frågeställning tre kommer rapporten endast att fokusera på aspekten förnybar energi.

C.2

Bakgrund

Att automatiskt kunna bedöma vad ett filmklipp eller bild handlar om är något som kan vara användbart för tjänster som till exempel rekommenderings- eller sökmotorer. Det ställer dock ett högt krav på de tjänster som används och framförallt att det som genererats från filmen eller bilden är korrekt. Eftersom Flowplayer redan använde AWS föreslog de att projektet skulle använda Rekognition, men att projektgruppen kunde undersöka om Vision var bättre. Projektgruppen gjorde då en mindre undersökning under projektets undersökningsfas som fokuserade kring de tjänster som Vision och Rekognition erbjuder. Det kändes således re- levant att undersöka djupare huruvida Rekognition och Vision stod sig mot varandra och om projektet hade kunnat gynnats av att använda Vision istället. Undersökningen som finns beskriven i rapporten gjordes under projektets utvecklings- och avslutningsfas, det vill säga mot slutet av projektet och bygger delvis på det arbete som gjorts under projektets tidigare faser.

C.3

Teori

I detta kapitel tas relevant information och teori upp. Som nämnts tidigare är både Rekognition och Vision en samling av olika funktioner, där rapporten kommer fokusera på objektigenkänningsfunktionaliteten. Kapitlet kommer därmed översiktligt beskriva vad ob- jektigenkänning är och innebär samt hur det generellt sett fungerar. Teorin som tas upp be- hövs för att få en bättre förståelse för resultatet, diskussionen och slutsatsen.

AWS och GCP är två plattformar för molntjänster som tillhandahåller en mängd olika smarta lösningar, som till exempel servrar, databaser, virtuella datorer, maskininlärning med me- ra [52, 53]. Företag som använder dessa tjänster är bland annat Spotify och airbnb [54]. Rekognition och Vision är samlingsnamn för en mängd olika funktioner. Tjänsterna inne- håller flera olika typer av detektion, som till exempel detektion av objekt, kända personer, texter med mera.

Gemensamt för Rekognition och Vision är att de är API:er, det vill säga applikationsprogram- meringsgränssnitt. Det innebär att allt användaren behöver göra är att anropa en viss funk- tion och ge rätt inparametrar och så sköter programmeringsgränsnittet resten. Information om vilken funktion och vilka parametrar funktionen tar finns ofta väl dokumenterad. Detta medför att det blir enkelt att använda deras tjänster, samt att det inte behövs någon tidigare kunskap inom området. Tillsammans med detta erbjuder både Amazon och Google via deras plattformar helhetslösningar och inte enbart tjänster som Rekognition och Vision.

C.3.1

Objektigenkänning

Objektigenkänning handlar om att analysera bilder eller videoklipp och försöka identifiera de objekt som finns i den aktuella bilden. För att göra detta måste först objektet lokaliseras i

C.3. Teori

bilden för att därefter klassificeras. Detta kan i sin tur tillämpas på diverse sätt, till exempel detektera fordon i trafiken, eller som i vårt projekt detektera vad ett filmklipp handlar om. När Rekogntion och Vision har analyserat ett filmklipp får vi ut resultatet i form av ett JSON- objekt. JSON är en datastruktur som är enkel att tolka för både människor och datorer [55]. JSON-objektet innehåller alla taggar i form av en lista, där varje tagg i sin tur innehåller information som namn och konfidensnivå. Denna data kan skilja sig beroende på typ av tjänst som körs samt om det är ett filmklipp eller bild som analyseras. Ett exempel på en tagg som genererats från en bild kan ses i figur C.1.

1 "Labels": [ 2 { 3 "Confidence": 98.4629, 4 "Name": "Person" 5 }, 6 ... 7 ] 8 }

Figur C.1: Ett exempel på hur en tagg kan se ut

In document Automatisk taggning av video (Page 65-74)