Utnyttelse av AWS i Geodata AS. Hvordan Geodata benytter muligheter i AWS-plattformen til effektiv drift av tjenester, apps og dataprosessering.

1. AWS PÅ
KARTET
Pål Kristensen
Teamleder Systemdrift / DevOps

3. OM GEODATA
• Etablert i 1988
• Samtlige eiere har fortsatt tilknytning til selskapet
• Solid selskap med jevn vekst
• Distributør av Esri i Norge
• Ca 117 ansatte (122 m Geocap)
• Omsetning 2014: ca 218 MNOK, Resultat 34,1
• Omsetning 2015: ca 219 MNOK, Resultat 27,9*
• Mål 2016: ca 230 MNOK
Steinkjer
Oslo
Stavanger
*) Endring av regnskapsføringsprinsipper i 2015

4. ØKONOMISK UTVIKLING
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
40000000
-
50,000,000
100,000,000
150,000,000
200,000,000
250,000,000
2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015B
Utvikling i omsetning og resultat
Omsetning Resultat

5. GEODATA ER EN «GIS-INTEGRATOR»
• Leverer tjenester på tvers av
hele verdikjeden til kundene
• Programvare
• Prosjektleveranser
• Rådgivning
• Support
• Opplæring
• Innholdstjenester
• Datatilrettelegging
• Drift av løsninger
• Erfaring fra noen av de største
og tyngste
forvaltningsprosjektene

6. KUNDER PÅ TVERS AV ALLE SEGMENTER

8. • Innholdstjenester
• Offline innhold
• Hosting av apps
• Hosting av tjenester

12. VÅR REISE I AWS
• 2008: Sped begynnelse, eksperimentering
• 2009: Noen få tjenester kjørende på en single EC2 boks
• 2010: Gradvis flere tjenester settes opp i AWS. Fremdeles helt manuell
workflow for oppsette og drift av infrastrukturen. Hver EC2 boks var en silo
• 2011: Gradvis en mer lagdelt infrastruktur
• Fillagring, Databaser, Tjenester/Apps
• 2012-2015: Gradvis mer automatisering av infrastruktur. Utvikling av egen
dataflyt og prosesseringsplattform
• 2015-2016: «All in» på VPC og CloudFormation, med cfn-init og
bootstrapping. Implementering av rutiner for continuous delivery for
tjenester og apps.
Alle tjenester, apps og selve infrastrukturen er underlagt versjonskontroll.
• 2016: Fullstendig automatisert deploy av tjenester og apps, inkludert
tilbakerulling til tidligere versjoner. Hele infrastrukturen satt opp som
CloudFormation stacks
• 2016: Implementerer Spot. Lambda og API gateway for micro services

13. TEKNOLOGI - HOVEDKOMPONENTER

14. AWS-BYGGEKLOSSER

15. • AWS SDK for Python (Boto)
• AWS SDK for .Net
• AWS SDK for Java
• AWS SDK for PHP
• AWS SDK for Ruby

17. • Continuous integration
• Integrering eller «merge» av kode i nærsanntid, og samtidig sikre at funksjonalitet og
egenskaper ikke brytes. «Build» server som kontinuerlig lytter på endringer i
kildekodesystem og gjør forsøk på å bygge kode og kjøre tester
• Continuous delivery
• All kode som «leveres» skal være produksjonsklar og produksjonstestet. I prinsippet
skal koden kunne deployes om kunder og organisasjonen for øvrig er klar
• Continuous deplyment
• Er å ta det enda et steg. All kode som leveres blir også regelmessig (om ikke
automatisk) kjør ut i produksjon.
• Hvorfor? For å korte ned tiden fra ideer og behov oppstår til
funksjonalitet kan rulles ut til kunder. Mindre sårbar som
organisasjon og mindre avhengig av enkeltpersoner.
• Amazon har flere mekanismer som muliggjør konseptene
rent praktisk

18. THE AMAZON WAY

19. • Hvordan får vi til Continuous Delivery for
ArcGIS for Server?
• Innhold (data)
• Tjenester

20. AMI
RDS
snapshot
gdvh-master gdvh-prodRoute53 private hosted zone
• Hvordan får vi til Continuous Delivery for
ArcGIS for Server?
• Innhold (data)
• Tjenester

21. S3
«site»-staging.geodataonline.no «site».geodataonline.no
CF OK signal
Elastic
• Hvordan får vi til Continuous Delivery for
ArcGIS for Server?
• Innhold (data)
• Tjenester

22. DEPLOYMENTSTEG
1. Ny Windows Server 2012 R2 instans booter, eget AMI (ca 1-2
minutter)
2. EC2 Windows Servicen starter
3. Bootstrapping kjører (cfn-init)
1. Deploymentpakke lastes ned fra S3
2. Komponentene pakkes ut
3. Deploymentscript kjører (ca 22 minutter)
4. Kontrollscript kjører
Hvis alle tjenester er OK aktiveres helsesjekk URLen
4. cfn-init sender OK til stacken

23. CLOUDFORMATION - «SECRET SAUCE»
• Infrastruktur som kode

24. Spot
- AutoScaling group Spot
- Launch Configuration Spot
On-Demand
- AutoScaling group
- Launch Configuration
Elastic

25. DEPLOYE OPPDATERINGER
• Prinsipielt to ulike metoder å deploye oppdatert kode/config
• Oppdatere kode (pushe) til kjørende EC2 instanser som er «in service»,
instansen konfigurerer seg selv. (cfn-init, cfn-hup og custom deploy-kode)
• Bytte ut kjørende instanser med nye, som da enten har koden bakt inn i AMI,
eller som konfigurerer seg ved oppstart via såkalt bootstrapping (cfn-init og
custom deploykode)
• NB, enkelte endringer krever utskifting av instanser!
• Nytt AMI
• Ny maskintype
• Endringer i user-data
• Hva som er best egnet kommer an på din app/tjeneste

26. ROLLING UPDATE POLICY VS
REPLACE UPDATE POLICY
Rolling Update Replace Update
Deployment tid Lang i noen tilfeller Kort
Tid for eventuell rollback Lang Kort
Oppdateringsmetode Batch Alle på en gang
Krever utskifting av instanser for å deploye kode Nei Ja
Garantert konsistent kode i prod på alle noder Nei Ja
Tar hensyn til AutoScaling actions / ScaleOut Ja Nei (workaround med Lambda og
CloudFormation custom actions)
Fungerer greit med spot (ved utskifting av
instanser)
Nei (ingen workaround) Nei (workaround med Lambda og
CloudFormation custom actions)
Redusert kapasitet ved deploy (On Demand) Kan skje ved rollback Nei (Ja, hvis scaling actions er aktive)
Redusert kapasitet ved deploy (Spot) Ja Ja (workaround med Lambda og CloudFormation
custom actions)
Replace Update Policy har en mer robust og vesentlig raskere rollback ved eventuelle deployment feil

27. DEPLOYE OPPDATERINGER

28. DEPLOYE OPPDATERINGER

29. DEPLOYE OPPDATERINGER

30. CASE - ROLLING UPDATE - SPOT
SpotOnDemand
Booting
In Service

31. ROLLING UPDATE – SPOT!!!!!
NB! MinInstancesInService må være 0

32. CASE - REPLACE UPDATE - SPOT
SpotOnDemand
Booting
In Service

33. CASE - REPLACE UPDATE – SPOT (WORKAROUND)
SpotOnDemand
Booting
In Service

34. WORKAROUND

36. HVORDAN LAGRE STORE DATAMENGDER I EN
FILSTRUKTUR PÅ AWS?
• Vi har tjenester som er avhengig av å nå data på en
filstruktur, altså ikke bare jobbe mot S3
• Hvordan bygger du fillagring på +80TB?
• Som ikke koster skjorta
• Som gir bra ytelse
• Som har god nok oppetid
• Som kan benyttes som SMB v3.0 i Microsoft noder
• Som ikke er overkomplisert

37. HVORDAN LAGRE STORE DATAMENGDER I EN
FILSTRUKTUR PÅ AWS?
• Linux
• NFS and CIFS Options for AWS (STG401) | AWS re:Invent 2013
• GlusterFS
• SoftNAS
• Zadara Storage
• Windows
• Scale-Out File Server for Application Data Overview
• Storage Spaces Overview
• EFS
• Kostbart
• Relativt lav IO og throughput
• Kun NFSv4

38. https://aws.amazon.com/ebs/details/
VOLUMTYPER
• Max 27 EBS
volumer pr
Windows Server,
inkludert
/dev/sda1
• Det «gamle»
standard HDD
EBS volumet er
begrenset til max
1TB pr volum

39. VI VALGTE
• Windows Server 2012 R2
• Storage Spaces
• EBS Cold HDD for lagring
• EBS GP SSD for Write Back Cache

43. TAKK FOR
OPPMERKSOMHETEN!
pal.kristensen@geodata.no