Det här är ett gästinlägg av Diego Benavides och Luis Bendezú, Senior Data Architects, Data Architecture Direction på Belcorp.
Belcorp är ett av de största företagen för konsumentförpackade varor (CPG) som tillhandahåller kosmetikaprodukter i regionen i mer än 50 år, fördelat på cirka 13 länder i Nord-, Central- och Sydamerika (AMER). Född i Peru och med en egen produktfabrik i Colombia, höll Belcorp alltid före kurvan och anpassade sin affärsmodell efter kundernas behov och stärkte sin strategi med tekniska trender, vilket varje gång gav en bättre kundupplevelse. Med fokus på detta började Belcorp implementera sin egen datastrategi som uppmuntrade användningen av data för beslutsfattande. Baserat på denna strategi designade och implementerade Belcorps dataarkitekturteam ett dataekosystem som gör det möjligt för affärs- och analysteam att konsumera funktionell data som de använder för att generera hypoteser och insikter som materialiseras i bättre marknadsföringsstrategier eller nya produkter. Detta inlägg syftar till att detaljera en serie kontinuerliga förbättringar som genomfördes under 2021 för att minska antalet plattformsincidenter som rapporterades i slutet av 2020, optimera SLA:er som krävs av verksamheten och vara mer kostnadseffektiv när du använder Amazon EMR, vilket resulterar i upp till 30 % besparingar för företaget.
För att ligga före kurvan har starkare företag byggt en datastrategi som gör det möjligt för dem att förbättra de viktigaste affärsstrategierna, eller till och med skapa nya, med hjälp av data som huvuddrivkraft. Som ett av de största företagen för konsumentförpackade varor (CPG) i regionen är Belcorp inget undantag – de senaste åren har vi arbetat med att implementera datadrivet beslutsfattande.
Vi vet att all bra datastrategi är anpassad till affärsmål och baserad på huvudsakliga affärsanvändningsfall. För närvarande är alla våra teaminsatser fokuserade på slutkonsumenten, och nästan alla affärsinitiativ är relaterade till hyperpersonalisering, prissättning och kundengagemang.
För att stödja dessa initiativ tillhandahåller dataarkitekturavdelningen datatjänster som dataintegration, endast en källa till sanning, datastyrning och ramverk för datakvalitet, datatillgänglighet, datatillgänglighet och optimerad time to market, enligt affärskrav som andra stora företag. För att tillhandahålla minimal kapacitet för att stödja alla dessa tjänster behövde vi ett skalbart, flexibelt och kostnadseffektivt dataekosystem. Belcorp startade detta äventyr för ett par år sedan med hjälp av AWS-tjänster som Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda, AWS Fargate, Amazon EMR, Amazon DynamoDBoch Amazon RedShift, som för närvarande matar våra huvudsakliga analytiska lösningar med data.
När vi växte var vi tvungna att kontinuerligt förbättra vår arkitekturdesign och bearbetningsramverk med avseende på datavolym och mer komplexa krav på datalösningar. Vi var också tvungna att anta ramverk för kvalitet och övervakning för att garantera dataintegritet, datakvalitet och servicenivåavtal (SLA). Som du kan förvänta dig är det ingen lätt uppgift och kräver sin egen strategi. I början av 2021 och på grund av kritiska incidenter vi hittade, påverkades operativ stabilitet, vilket direkt påverkade affärsresultaten. Faktureringen påverkades också på grund av att fler nya komplexa arbetsbelastningar inkluderades, vilket orsakade en oväntad ökning av plattformskostnaderna. Som svar beslutade vi att fokusera på tre utmaningar:
- Driftstabilitet
- Kostnadseffektivitet
- Service Level Agreements
Det här inlägget beskriver några åtgärder som vi genomförde under 2021 över Belcorps ramverk för databehandling baserat på Amazon EMR. Vi diskuterar också hur dessa åtgärder hjälpte oss att möta de utmaningar som nämnts tidigare, och ger också ekonomiska besparingar till Belcorp, som var dataarkitekturteamets huvudsakliga bidrag till företaget.
Översikt över lösningen
Belcorps dataekosystem består av sju nyckelpelare (som visas i följande diagram) som definierar vår arkitektoniska design och ger oss mer eller mindre tekniskt flexibla alternativ. Vår dataplattform kan klassificeras som en del av den andra generationens dataplattformar, som nämndes av Zhamak Dehghani i Hur man flyttar bortom en monolitisk datasjö till ett distribuerat datanät. Faktum är att det har alla begränsningar och restriktioner för ett Lakehouse-tillvägagångssätt som nämns i tidningen Lakehouse: En ny generation av öppna plattformar som förenar datalagring och avancerad analys .
Belcorps dataplattform stöder två huvudsakliga användningsfall. Å ena sidan tillhandahåller den data som ska konsumeras med hjälp av visualiseringsverktyg, vilket uppmuntrar självbetjäning. Å andra sidan tillhandahåller den funktionell data till slutanvändare, som datavetare eller dataanalytiker, genom distribuerade datalager och objektlagring som är mer lämpade för avancerade analytiska metoder.
Följande referensdesign förklarar de två huvudsakliga skikten som ansvarar för att tillhandahålla funktionella data för dessa användningsfall. Databehandlingsskiktet är sammansatt av två underskikt. Den första är Belcorps Data Lake Integrator, som är en inbyggd, intern Python-lösning med en uppsättning API REST-tjänster som ansvarar för att organisera alla dataarbetsbelastningar och datastadier i analysförråden. Det fungerar också som en kontrollpunkt för att distribuera resurser som ska tilldelas för varje Amazon EMR Spark-jobb. Bearbetningsunderlagret består huvudsakligen av EMR-klustret, som ansvarar för orkestrering, spårning och underhåll av alla Spark-jobb som utvecklats med hjälp av ett Scala-ramverk.
För det beständiga förvarslagret använder vi Amazon enkel lagringstjänst (Amazon S3) objektlagring som ett datalager för analytiska arbetsbelastningar, där vi har designat en uppsättning datasteg som har operativa och funktionella syften baserat på referensarkitekturdesignen. Att diskutera förvarsdesignen mer på djupet är utanför räckvidden för detta inlägg, men vi måste notera att det täcker alla vanliga utmaningar relaterade till datatillgänglighet, datatillgänglighet, datakonsistens och datakvalitet. Dessutom uppnår den alla Belcorps behov som dess affärsmodell kräver, trots alla begränsningar och restriktioner som vi ärver av designen som nämnts tidigare.
Vi kan nu rikta vår uppmärksamhet mot huvudsyftet med detta inlägg.
Som vi nämnde upplevde vi kritiska incidenter (av vilka några funnits tidigare) och oväntade kostnadsökningar i början av 2021, vilket motiverade oss att vidta åtgärder. Följande tabell listar några av de viktigaste frågorna som väckte vår uppmärksamhet.
| Rapporterade incidenter | Inverkan |
| Försening i Spark-jobb på Amazon EMR | Grundläggande arbetsbelastningar tar lång tid |
| Fördröjning i automatisk skalning av Amazon EMR-noder | Arbetsbelastningen tar lång tid |
| Ökning av Amazon EMR-beräkningsanvändning per nod | Oväntad kostnadsökning |
| Förlorade resursbehållare | Arbetsbelastningar bearbetar en enorm datakrasch |
| Överskattat minne och CPU:er | Oväntad kostnadsökning |
För att möta dessa problem bestämde vi oss för att ändra strategier och började analysera varje problem för att identifiera orsaken. Vi definierade två handlingslinjer utifrån tre utmaningar som ledarna ville att vi skulle arbeta med. Följande figur sammanfattar dessa linjer och utmaningar.
Handlingslinjen för datasjöarkitektur hänvisar till alla arkitektoniska luckor och föråldrade funktioner som vi fastställde som en del av huvudproblemen som orsakade incidenterna. Handlingslinjen för bästa praxis för Spark-utveckling är relaterad till den utvecklade Spark-datalösningen som hade orsakat instabilitet på grund av dålig praxis under utvecklingens livscykel. Med fokus på dessa handlingslinjer definierade våra ledare tre utmaningar för att minska antalet incidenter och garantera kvaliteten på den tjänst vi tillhandahåller: operativ stabilitet, kostnadseffektivitet och SLA.
Utifrån dessa utmaningar definierade vi tre nyckeltal för att mäta projektets framgång. Jira-incidenter tillåter oss att validera att våra förändringar har en positiv inverkan; fakturering per vecka visar ledarna att en del av ändringarna vi tillämpade gradvis kommer att optimera kostnaden; och runtime ger affärsanvändarna en bättre tid till marknaden.
Därefter definierade vi nästa steg och hur man mäter framsteg. Baserat på vårt övervakningsramverk fastställde vi att nästan alla incidenter som uppstod var relaterade till databearbetning och beständiga förvarslager. Sedan fick vi bestämma hur vi skulle lösa dem. Vi kan göra reaktiva korrigeringar för att uppnå driftsstabilitet och inte påverka verksamheten, eller så kan vi ändra vårt vanliga sätt att arbeta, analysera varje problem och tillhandahålla en slutlig lösning för att optimera vårt ramverk. Som ni kan gissa bestämde vi oss för att ändra vårt sätt att arbeta.
Vi gjorde en preliminär analys för att fastställa de viktigaste effekterna och utmaningarna. Vi föreslog sedan följande åtgärder och förbättringar baserat på våra handlingslinjer:
- Data lake arkitektur – Vi gjorde om EMR-klustret; vi använder nu kärn- och uppgiftsnoder
- Bästa praxis för Spark Development – Vi optimerade Spark-parametrar (RAM-minne, kärnor, CPU:er och executornummer)
I nästa avsnitt förklarar vi i detalj de åtgärder och förbättringar som föreslås för att uppnå våra mål.
Åtgärder och förbättringar
Som vi nämnde i föregående avsnitt resulterade analysen som gjordes av arkitekturteamet i en lista med åtgärder och förbättringar som skulle hjälpa oss att möta tre utmaningar: driftsstabilitet, ett kostnadseffektivt dataekosystem och SLA.
Innan du går vidare är det en bra tid att ge mer information om Belcorps ramverk för databehandling. Vi byggde det baserat på Apache Spark med hjälp av programmeringsspråket Scala. Vårt ramverk för databehandling är en uppsättning skalbara, parametrerbara och återanvändbara Scala-artefakter som förser utvecklingsteam med ett kraftfullt verktyg för att implementera komplexa datapipelines, för att uppnå de mest komplexa affärskraven med Apache Spark-teknologi. Genom Belcorp DevOps-ramverket distribuerar vi varje artefakt till flera icke-produktionsmiljöer. Sedan marknadsför vi till produktion, där EMR-klustret lanserar alla rutiner med hjälp av Scala-artefakter som refererar till varje konceptuellt område i den analytiska plattformen. Denna del av cykeln ger teamen en viss grad av flexibilitet och smidighet. Men vi glömde för ett ögonblick kvaliteten på programvaran vi utvecklade med Apache Spark-teknik.
I det här avsnittet dyker vi ner i de åtgärder och förbättringar vi tillämpade för att optimera Belcorps databehandlingsramverk och förbättra arkitekturen.
Omdesign av EMR-klustret
Den nuvarande designen och implementeringen av Belcorps datasjö är inte den första versionen. Vi är för närvarande i version 2.0, och från början av den första implementeringen tills nu har vi provat olika EMR-klusterdesigner för att implementera databehandlingslagret. Till en början använde vi ett fast kluster med fyra noder (som visas i följande figur), men när den automatiska skalningskapaciteten lanserades och Belcorps databelastning ökade, bestämde vi oss för att flytta det dit för att optimera resursanvändning och kostnader. Men ett automatiskt skalat EMR-kluster har också olika alternativ. Du kan välja mellan kärn- och uppgiftsnoder med ett minimalt och maximalt antal av varje. Dessutom kan du välja On-Demand eller Spot Instances. Du kan också implementera en optimerad allokeringsstrategi med hjälp av EMR-instansflottor för att minska sannolikheten för Spot Instance-förlust. För mer information om Amazon EMR-resursallokeringsstrategier, se Gnistförbättringar för elasticitet och spänst på Amazon EMR och Optimera Amazon EMR för motståndskraft och kostnad med kapacitetsoptimerade Spot Instances.
Vi testade alla dessa funktioner, men vi hittade några problem.
För det första, även om AWS erbjuder många möjligheter och funktioner kring Amazon EMR, om du inte har någon grad av kunskap om tekniken du vill använda, kan du stöta på många problem när användningsfallen uppstår. Som vi nämnde bestämde vi oss för att använda Apache Sparks databehandlingsmotor genom Amazon EMR som en del av Belcorps dataekosystem, men vi stod inför många problem. Närhelst en incident inträffade motiverade det det ansvariga dataarkitektteamet att fixa det, som en del av drift- och supportuppgifterna. Nästan alla dessa reaktiva korrigeringar var relaterade till att ändra Amazon EMR-konfiguration för att prova olika alternativ för att effektivt lösa dessa incidenter.
Vi kom på att nästan alla incidenter var relaterade till resursallokering, så vi testade många konfigurationsalternativ som instanstyper, ökning av antalet noder, anpassade regler för automatisk skalning och flottastrategier. Det sista alternativet användes för att minska nodförlusten. I slutet av 2020 validerade vi att ett EMR-kluster med automatisk skalning aktiverad med en minimikapacitet på tre On-Demand kärnnoder 24/7 och möjligheten att skala upp till 25 On-Demand kärnnoder gav oss en stabil databehandling plattform. I början av 2021 distribuerades mer komplexa Spark-jobb som en del av databearbetningsrutinerna inom EMR-klustret, vilket igen orsakade operationell instabilitet. Dessutom ökade faktureringen oväntat, vilket varnade ledare vars team behövde omdesigna EMR-klustret för att bibehålla sund driftsstabilitet och optimera kostnaderna.
Vi insåg snart att det var möjligt att minska upp till 40 % av den nuvarande faktureringen med hjälp av Spot-instanser, istället för att behålla alla kärnnoder i On-Demand-konsumtion. En annan infrastrukturoptimering som vi ville tillämpa var att ersätta ett antal kärnnoder med uppgiftsnoder, eftersom nästan alla Belcorps dataarbetsbelastningar är minneskrävande och använder Amazon S3 för att läsa källdata och skriva resultatdataset. Frågan här var hur man gör det utan att förlora fördelarna med den nuvarande designen. För att svara på denna fråga fick vi vägledning från AWS Account Team och vår AWS Analytics och Big Data Specialist SA, för att klargöra frågor om följande:
- Apache Spark-implementering i Amazon EMR
- Bästa metoder för kärna och uppgiftsnoder för produktionsmiljöer
- Spot Instance beteende i Amazon EMR
Vi rekommenderar definitivt att du tar itu med dessa tre huvudpunkter innan du tillämpar några ändringar eftersom, enligt vår tidigare erfarenhet, att göra ändringar i mörker kan leda till kostsam och underpresterande Amazon EMR-implementering. Med det i åtanke gjorde vi om EMR-klustret för att kunna använda det EMR hanterade skalning, som automatiskt ändrar storleken på ditt kluster för bästa prestanda till lägsta möjliga kostnad. Vi definierade maximalt 28 kapacitetsenheter med tre On-Demand kärnnoder alltid på (24/7) för att stödja dataarbetsbelastningar under dagen. Vi satte sedan en automatisk skalningsgräns på sex On-Demand-kärnor för att ge minimal HDFS-kapacitet för att stödja de återstående 22 uppgiftsnoderna som består av Spot Instances. Denna slutliga konfiguration är baserad på råd från AWS-experter att vi har minst en kärnnod för att stödja sex uppgiftsnoder, med ett förhållande på 1:6. Följande tabell sammanfattar vår klusterdesign.
| Cluster Scaling Policy | Amazon EMR Managed Scaling aktiverad |
Minsta nodenheter (MinimumCapacityUnits) |
3 |
Maximalt antal nodenheter (a) |
28 |
På begäran gräns (MaximumOnDemandCapacityUnits) |
6 |
Maximalt antal kärnnoder (MaximumCoreCapacityUnits) |
6 |
| Instans typ | m4.10xstor |
| Antal primära noder | 1 |
| Typ av primär nodinstans | m4.4xstor |
Följande figur illustrerar vår uppdaterade och nuvarande klusterdesign.
Tuning Spark-parametrar
Som vilken bra bok som helst om Apache Spark kan säga dig att Spark-parameterjustering är det huvudsakliga ämnet du behöver titta på innan du distribuerar en Spark-applikation i produktion.
Att justera Spark-parametrar är uppgiften att ställa in resurserna (CPU:er, minne och antalet executorer) för varje Spark-applikation. I det här inlägget fokuserar vi inte på förarinstansresurser; vi fokuserar på utförarna eftersom det är huvudproblemet vi hittade i Belcorps implementering.
Efter att vi tillämpat förbättringar kring join-drift och cache-strategier i Spark-applikationsutveckling, insåg vi att vissa av dessa applikationer tilldelades överskattade resurser i EMR-klustret. Det betyder att Spark-applikationer tilldelade resurser, men endast 30 % av resurserna användes. Följande Ganglia-rapport illustrerar överskattningen av resursallokering för ett Spark-applikationsjobb, som vi fångade under ett av våra tester.
En stor konsekvens av detta beteende var den massiva utbyggnaden av EMR-noder som inte användes korrekt. Det betyder att många noder tillhandahålls på grund av den automatiska skalningsfunktionen som krävs av en Spark-ansökan, men mycket av resurserna för dessa noder hölls lediga. Vi visar ett grundläggande exempel på detta längre fram i detta avsnitt.
Med detta bevis började vi misstänka att vi behövde justera Spark-parametrarna för några av våra Spark-applikationer.
Som vi nämnde i tidigare avsnitt, som en del av Belcorps dataekosystem, byggde vi en Data Pipelines Integrator, som har huvudansvaret för att upprätthålla centraliserad kontroll över körningarna av varje Spark-applikation. För att göra det använder den en JSON-fil som innehåller Spark-parameterkonfigurationen och utför var och en spark-submit använder Livy-tjänsten, som visas i följande exempelkod:
Den här JSON-filen innehåller Spark-parameterkonfigurationen för varje Spark-applikation som är relaterad till ett internt system och land som vi skickar till EMR-klustret. I följande exempel, CM är namnet på systemet och PE är landskoden som data kommer från:
Problemet med detta tillvägagångssätt är att när vi lägger till fler applikationer blir hanteringen av dessa konfigurationsfiler mer komplex. Dessutom hade vi många Spark-applikationer konfigurerade med en standardkonfiguration som definierades för länge sedan när arbetsbelastningen var billigare. Så det förväntades att vissa saker skulle förändras. Ett exempel på en Spark-applikation med okalibrerade parametrar visas i följande figur (vi använder endast fyra exekveringsinstanser för exemplet). I det här exemplet insåg vi att vi tilldelade utförare med mycket resurser utan att följa någon av Sparks bästa praxis. Detta orsakade tillhandahållandet av feta exekutorer (med hjälp av Spark-slang) allokerar var och en av dessa i minst en nod. Det betyder att om vi definierar en Spark-applikation som ska skickas med 10 executorer, kräver vi minst 10 noder i klustret och använder 10 noder för endast en körning, vilket var väldigt dyrt för oss.
När du hanterar utmaningar med Spark-parameterjustering är det alltid en bra idé att följa expertråd. Ett av de viktigaste råden är kanske relaterat till antalet executor-kärnor du bör använda i en Spark-applikation. Experter föreslår att en exekutor ska ha upp till fyra eller fem kärnor. Vi kände till den här begränsningen eftersom vi tidigare utvecklade Spark-applikationer i Hadoop-ekosystemet på grund av Hadoop File Systems I/O-begränsningar. Det vill säga, om vi har fler kärnor konfigurerade för en executor, utför vi fler I/O-operationer i en enda HDFS-datanod, och det är välkänt att HDFS försämras på grund av hög samtidighet. Denna begränsning är inte ett problem om vi använder Amazon S3 som lagring, men förslaget kvarstår på grund av överbelastningen av JVM. Kom ihåg att medan du har fler operativa uppgifter, som I/O-operationer, har JVM för varje executor mer att göra, så JVM försämras.
Med dessa fakta och tidigare upptäckter insåg vi att för vissa av våra Spark-applikationer använde vi bara 30 % av de tilldelade resurserna. Vi behövde omkalibrera Spark-jobbparametrarna för att bara tilldela de bäst lämpade resurserna och avsevärt minska överanvändningen av EMR-noder. Följande figur ger ett exempel på fördelarna med denna förbättring, där vi kan observera en 50 % av nodreduktionen baserat på vår tidigare konfiguration.
Vi använde följande optimerade parametrar för att optimera Spark-applikationen relaterad till CM-systemet:
Resultat
I det här inlägget ville vi dela med oss av framgångssagan för vårt projekt för att förbättra Belcorps dataekosystem, baserat på två handlingslinjer och tre utmaningar definierade av ledare som använder AWS-datateknik och interna plattformar.
Vi var tydliga med våra mål från början baserat på de definierade KPI:erna, så vi har kunnat validera att antalet JIRA-incidenter som rapporterades i slutet av maj 2021 hade en märkbar minskning. Följande siffror visar en minskning med upp till 75 % jämfört med tidigare månader, vilket framhäver mars som en kritisk topp.
Baserat på denna incidentreduktion kom vi fram till att nästan alla Spark-jobbrutiner som kördes i EMR-klustret gynnades av en körtidsoptimering, inklusive de två mest komplexa Spark-jobben, med en minskning på upp till 60 %, som visas i följande figur.
Det kanske viktigaste bidraget av de förbättringar som gjorts av teamet är direkt relaterat till faktureringen per vecka. Till exempel Amazon EMR-omdesign, förbättringar av join-operationen, applicerade bästa praxis för cache och Spark-parameterjustering – allt detta gav en märkbar minskning av användningen av klusterresurser. Som vi vet beräknar Amazon EMR fakturering baserat på den tid som klusternoderna har varit på, oavsett om de gör något arbete. Så när vi optimerade EMR-klusteranvändningen optimerade vi också de kostnader vi genererade. Som visas i följande figur, bara på två månader, mellan mars och maj, uppnådde vi en faktureringsminskning på upp till 2 %. Vi uppskattar att vi kommer att spara upp till 40 % av den årliga fakturering som skulle ha genererats utan förbättringarna.
Slutsats och nästa steg
Dataarkitekturteamet ansvarar för Belcorps dataekosystems kontinuerliga förbättringar, och vi utmanas ständigt att uppnå en klassens bästa arkitektur, skapa bättre arkitektoniska lösningar, optimera kostnaden och skapa den mest automatiserade, flexibla och skalbara ramverk.
Samtidigt funderar vi på framtiden för detta dataekosystem – hur vi kan anpassa oss till nya affärsbehov, skapa nya affärsmodeller och ta itu med nuvarande arkitektoniska luckor. Vi arbetar nu med nästa generation av Belcorps dataplattform, baserad på nya tillvägagångssätt som dataprodukter, datanät och sjöhus. Vi tror att dessa nya tillvägagångssätt och koncept kommer att hjälpa oss att täcka våra nuvarande arkitektoniska luckor i den andra generationen av vår dataplattformsdesign. Dessutom kommer det att hjälpa oss att bättre organisera affärs- och utvecklingsteamen för att uppnå större smidighet under utvecklingscykeln. Vi tänker på datalösningar som en dataprodukt och förse team med en uppsättning tekniska komponenter och automatiserade ramverk som de kan använda som byggstenar.
Erkännanden
Vi vill tacka våra ledare, särskilt Jose Israel Rico, Corporate Data Architecture Director, och Venkat Gopalan, Chief Technology, Data and Digital Officer, som inspirerar oss att vara kundcentrerade, insistera på högsta standard och stödja varje tekniskt beslut baserat på en starkare kunskap om den senaste tekniken.
Om författarna
Diego Benavides är Belcorps Senior Data Architect med ansvar för utformningen, implementeringen och den kontinuerliga förbättringen av Global and Corporate Data Ecosystem Architecture. Han har erfarenhet av att arbeta med big data och avancerad analysteknik inom många branschområden som telekommunikation, bank och detaljhandel.
Luis Bendezú arbetar som Senior Data Engineer på Belcorp. Han är ansvarig för ständiga förbättringar och implementering av nya datasjöfunktioner med hjälp av ett antal AWS-tjänster. Han har också erfarenhet som mjukvaruingenjör, designande av API:er, integration av många plattformar, frikoppling av applikationer och automatisering av manuella jobb.
Mar Ortiz är en bioingenjör som arbetar som Solutions Architect Associate på AWS. Hon har erfarenhet av att arbeta med cloud compute och olika teknologier som media, databaser, datoranvändning och distribuerad arkitekturdesign.
Raúl Hugo är en AWS Sr. Solutions Architect med mer än 12 års erfarenhet från LATAM finansiella företag och globala telekomföretag som SysAdmin, DevOps ingenjör och molnspecialist.
