Kort om systemet
Quant Insight er en portefølje av tjenester for analyse og støtte til driften av distribusjonsnettet (altså strømnettet fra nettstasjoner og ut til sluttkunder). Data samles inn fra de nye smarte strømmålerne, fra multi-instrumenter i nettstasjoner, fra eksterne vær-tjenester, samt topologi og strukturdata fra nettselskapene. Quant Insight tilbyr visualisering og analyser gjennom web applikasjoner tilgjengeliggjort for nettselskapene. Porteføljen er bygget opp fra bunn som rene sky-tjenester i AWS.
Prosessering
Lambda kan benyttes i noen formål, men egner seg ikke for alt. Oppstartstiden for Lambda-funksjoner er utfordrende for visse prosesser, og kostnaden er for høy ved store og tunge volum. En god del av mikro-tjenestene våre kjører derfor på egne servere. I skrivende stund har vi drøye 20 slike mikro-tjenester, og ca 16 unike lambda. Hvert bygg av en enkelt mikro-tjeneste resulterer i et nytt docker-image som blir lastet opp til ECR. ECS brukes for å administrere og kjøre docker containerne. Alle tjenestene kjører på et spot-fleet cluster for å minimere kostnadene til servere. Denne holder seg stabilt på omtrent en tiendedel av normal kost. For å bøte på faren for manglende tilgjengelighet på spot instanser, konfigureres Spot-fleet’en bredt mtp ulike server-kategorier, modeller, pris, og lokasjon.
Vi har også noen få servere direkte på EC2 for spesielle formål. Eksempelvis Bastion-host, Dashboard-server, og ElasticSearch cluster.
Last-balanserere (ALB) kjører i forkant av mikro-tjenestene for ruting, fordeling av last, SSL-terminering, og håndtering av feilede instanser.
Lagring
Vi benytter flere lagringstjenester for ulike type data og formål. Til å begynne med ble de fleste data lagret i DynamoDB. Dessverre ble denne til vårt bruk uforholdsmessig dyr i drift. I den senere tid har vi derfor byttet ut DynamoDB til fordel for vår egen tidsseriedatabase, som er bygget på toppen av Aurora RDS. Denne håndterer nå flere hundre transaksjoner i sekundet. Strukturdata blir lagret i Neptune, med Apache Gremlin som spørre-språk. Neptune kunne med fordel vært rikere både på funksjonalitet og fleksibilitet enn det som tilbys i dag. Denne er en forholdsvis ny tjeneste, så dette vil antagelig bli bedre etterhvert. I tillegg cacher vi opp enkelte applikasjons-tilpassede datastrukturer i egne RDS PostgreSql databaser.
S3 blir brukt i flere sammenhenger: som temporær data storage, for historikk og backup, for media-filer, og for web applikasjonsdata. Redshift benyttes som datavarehus med kopi av alle master-data. CloudWatch inneholder alle applikasjonsloggene våre (i tillegg til logging av aws tjenester), mens EFS benyttes for lagring av loggdata i vår egen ElasticSearch/Kibana stack, og som file storage for byggserver. CloudTrail er aktivisert for audit-formål, eksempelvis all bruk av krypteringsnøkler.
Interaksjon
Tjenestene kommuniserer med hverandre asynkront der det er mulig, og synkront der man må. Alle nye data inn i systemet og alle oppdateringer legges på en Kinesis datastrøm. Flere av våre tjenester konsumerer så meldinger fra denne. Vi har vurdert å benytte Kinesis Analytics til noe av meldings-prosesseringen, men har foreløpig ikke funnet det egnet til våre behov.
SNS benyttes for å kommunisere nye hendelser fra den enkelte tjeneste, som andre tjenester trenger å bli informert om. Som en pub-sub mekanisme. Enkelte viktige hendelser fra selve strømmålere blir også publisert via SNS.
SQS benytter vi typisk for å separere tjenester, håndtering av retries, for å flate ut toppene i last-trafikken, og generell stabilisering. SQS i kombinasjon med Lambda fungerer bra for fan-out operasjoner som f.eks. prosessering av hundretusenvis av tidsserier.
Igangsetting av regelmessige oppgaver (les: crontab) konfigureres ved hjelp av CloudWatch event rules, og trigger enten Lambda funksjoner eller ECS scheduled tasks.
Sikkerhet
Sluttbrukere og systembrukere autentiserer og autoriserer seg vha Cognito. Tilgang fra tjenester til AWS ressurser er rolle-basert, og settes opp i IAM via CloudFormation. KMS benyttes for kryptering av meldinger. System Manager sin Parameter Store bruker vi for å håndtere passord og andre sensitive parametre. Vi vurderte også Secrets Manager for dette da den ble lansert, men den var priset for høyt og strengt tatt ikke nødvendig for våre behov.
Utviklere, testere, driftere, og andre interne ressurser konfigureres som brukere i IAM. Utvikling, test, og prod miljø inneholder derimot ikke egne brukere, og er kun tilgjengelig via bestemte roller.
Web-applikasjoner
Web applikasjoner blir deployet til CloudFront, og lagret i en S3 bucket. Route 53 håndterer DNS oppslag, sertifikater, og initiell ruting. API Gateway håndterer alle eksterne (internett) web kall til interne tjenester. Fungerer som en proxy som inkluderer bl.a. logging, monitorering, og autorisering.
Web applikasjonene vi lager tilbyr fritekst-søk. CloudSearch tjenesten til AWS hørtes i utgangspunktet ut som en veldig god match, men kom til kort da det viste seg at den ikke støttet tekstsøk på slutten av et ord. Dette er vesentlig i våre system der man ofte søker på nummerserier hvor første del er likt for hver kunde. Vi endte derfor med å bruke AWS sin ElasticSearch tjeneste.
Infrastruktur som en tjeneste (IAAS)
Utvikling, test- og produksjonsmiljø kjører på hver sin AWS konto. Konfigurasjon av disse skjer ved hjelp av CloudFormation. Grunnleggende nettverks-konfigurasjon inneholder elementer som VPC, Security Groups, Subnets, Internet and NAT Gateways, Elastic IPs, VPC Endpoints, IAM roles med mere.
Videre konfigureres den enkelte tjeneste vi lager, og alle ressursene denne behøver også i CloudFormation som yaml filer. F.eks. applikasjonsparametre, databaser, kryptering, logging, alarmer, tilganger osv.
For å automatisere deploying av endringer både i infrastrukturen og ved nye versjoner av tjenester/applikasjoner bruker vi CodeCommit som kode-repo for CloudFormation ressurser, og CodePipeline for å rulle ut endringene. Lambda-funksjoner kjøres for operasjoner som ikke er direkte støttet i CloudFormation.
AWS er ikke løsningen for alt
Monitorering og feilsøking:
QuickSite ble tidlig vurdert som et enkelt analyseverktøy mot dataene våre i Redshift, men ble forkastet da den viste seg å være litt for enkel og funksjonsfattig.
For å håndtere sentralisert logging av alle systemer og meldingene som blir behandlet, har vi bygget opp vårt eget ElasticSearch cluster (riktignok kjørende på EC2 instanser) med Kibana som front-end. Vi gjorde en initiell kalkulering av kostnadene ved å hoste dette selv, versus å benytte AWS sin egen ElasticSearch managed service. Det viste seg at å hoste dette selv ble billigere. En annen vesentlig fordel med dette var at vi kunne kjøre på siste versjon av ElasticSearch. AWS henger stadig etter på hvilken versjon den støtter.
Som kommunikasjonskanal for drift av systemene er Slack overlegent. Alle alarmer, feil, og advarsler, samt status-endringer, blir sendt til ulike Slack kanaler.
For øvrig monitorering, har brukergrensesnittet til CloudWatch flere svakheter. F.eks. ved kontinuerlig monitorering via eksterne skjermer. CloudWatch krever innlogging via AWS konsollet, og bruker-sesjoner har her en øvre timeout grense. Grafana fungerer derimot veldig bra, som en dashboard løsning som gjør spørringer direkte mot data i CloudWatch. Det kan forøvrig nevnes at en metrikk vi har hatt stor nytte av er en graf over daglige utgifter til AWS. Denne har gjort at vi raskt har kunnet håndtere uforutsette kostnadsøkninger i den daglige driften.
Kode og bygging:
De fleste git repo’ene våre hostes av Bitbucket. AWS sin CodeCommit manglet helt grunnleggende funksjonalitet til at denne ble vurdert da vi startet opp. Den hadde for eksempel ikke støtte for Pull requests. Vi ser foreløpig heller ingen grunn til bytte. Til bygging og test-kjøring benyttes Jenkins, som vi har god erfaring med fra tidligere. Bitbucket og Jenkins-bygg benyttes ikke bare på nye AWS komponenter, men også eldre moduler som ikke kjører på AWS. Disse siste har gjerne en mer kompleks struktur som lettere kan spesialtilpasses og scriptes vha Jenkins. Jenkins-clusteret kjører forøvrig på EC2 spot instanser.
Og verden går videre
Dette var en kjapp oversikt over dagens situasjon. I morgen kan det godt være noe annet. Vi jobber kontinuerlig med nye behov og utfordringer som må håndteres. For eksempel tester vi ut flere av IoT-tjenestene fra aws for innsamling og styring av data fra devices. Vi tester ut SageMaker for maskinlæring og statistiske beregninger, Recognition for bildegjenkjenning, Athena for big-data analyse, og Kinesis Analytics for enklere håndtering av innkommende data. Vi vurderer også å ta i bruk ElastiCache (redis) for enkelte in-memory cacher, og S3 som en data-lake for lagring av store datamengder til analyseformål (f.eks. i kombinasjon med Athena og SageMaker).
Som nevnt innledningsvis kommer AWS stadig med helt nye tjenester. Vi vil høyst sannsynlig ta i bruk Amazon Forecast så fort denne er allment tilgjengelig. I tillegg venter vi spent på den kommende tidsserie-databasen til Amazon; hvilke funksjoner den tilbyr, og hva kostnadsbildet for denne blir i praksis…