Project casus: Standaardisatie en bouw maatwerk datalake platform

30 August 2023 | Cloud Server, DevOps, ICT Consultancy, NL

Key takeaways

In dit artikel leer je meer over de volgende aspecten:

  • Je krijgt uitleg over hoe je een server en applicatie platform inricht en waar je rekening mee moet houden
  • We behandelen diverse facetten zoals wetgeving en continuïteit
  • Er wordt een methodiek gevolgd over hoe dit aan te pakken zodat jij je goed kunt voorbereiden als je zelf een dergelijk traject in gaat.

 

Introductie

 

Voor Metric Angel (MA), een vooruitstrevend bedrijf in data & business analytics, hebben wij in nauwe samenwerking met hen een gestandaardiseerde applicatie stack ontwikkeld waarmee zij data management doen voor hun klanten.

De gestandaardiseerde applicatie stack en server uitrol maakt het mogelijk om vlot een robuuste operationele infrastructuur op te zetten. In dit geval betreft het tools voor analyse, transformatie en representatie van gegevens uit bedrijfsprocessen en platformen zodat de klant van Metric Angel goed geïnformeerd is over bedrijfsvoering en gebruik van hun software platformen door afnemers.

 

Voor wie

Dit soort gestandaardiseerde oplossingen zijn ideaal voor start-ups en scale-ups die hun online diensten willen uitbreiden of professionaliseren. Wanneer er voor het eerst een server wordt uitgerold, ontstaat al snel de behoefte aan een tweede systeem voor het testen van nieuwe applicatieversies. De genoemde standaardisatie vergemakkelijkt het uitrollen van meerdere, identieke servers met consistente en veilige configuraties. Dit minimaliseert afwijkingen en verlaagt daarmee toekomstige issues. Het op een dergelijk manier repliceren van systemen is ook uitermate geschikt voor het opzetten van een OTAP straat (link to Jargon page).

 

Klant reactie

Onze samenwerking met CAP5 heeft ons in staat gesteld om een aanzienlijk aantal cloud servers door CAP5 te laten configureren. Dankzij CAP5’s deskundigheid kunnen we onze klanten robuuste en veilige oplossingen bieden, op het gebied van Business Intelligence en Automatisering. Bovendien heeft Gerard’s consultancy in DevOps ons enorm geholpen bij het opzetten van onze toolstack. Van advies tot de daadwerkelijke installatie en deployment. Thierry @ Metric Angel

 

Situatieschets

In het geval van Metric Angel betreft het een maatwerk op te bouwen datalake systeem. Zij hebben zelf zicht op welke gereedschappen er samengesteld moeten worden. Het eindproduct is een datalake systeem om hun diensten te faciliteren voor hun afnemers. Metric Angel verzoek is om met behulp van onderstaande tools tot een totaaloplossing te komen.

 

Superset

https://superset.apache.org/

Superset verzamelt en verwerkt data voor analyse en grafische visualisaties

 

Airbyte

https://airbyte.com/

Airbyte is een data pipeline tool voor het samenbrengen en beheren van data bronnen

 

DBT

https://www.getdbt.com/

DBT is een SQL transformatie tool voor data analytics

 

Adminer

https://www.adminer.org/

Database management tool voor alle gangbare database types zoals postgres, mysql, elastic, Mongo en andere.

 

De genoemde componenten zorgen in de eindoplossing voor replicatie, transformatie, analyse en representatie van data. Daarnaast moet alles uiteraard  veilig, afgeschermd voor alleen intern gebruik en dusdanig samengesteld zodat alles werkbaar in één cloud server terecht komt. Hier kan toekomstig vanaf geweken worden, hoe, dat lees je zo.

info: Wat is het verschil tussen een data lake en een data warehouse?

Een datalake systeem is ingericht voor analyses en real-time verwerking van zowel gestructureerde als ongestructureerde data uit diverse bronnen. Een data warehouse daarentegen voorziet in het analyseren en rapporteren op basis van vooraf gestructureerde data.

 

Doelen en uitdagingen

Om tot de uiteindelijke opstelling te komen zoals hierboven beschreven, moeten er diversen aspecten beoordeeld worden. Op basis van overleg met Metric Angel zijn de volgende doelstellingen opgesteld.

  • Het moet een samenstelling worden waarbij de gekozen tools van de verschillende leveranciers tezamen opereren in een cloudserver.
  • De architectuur van de gehele omgeving moet opgezet worden
  • De service mag alleen toegankelijk zijn voor medewerkers en de betreffende klant.
  • Er moet een gestandaardiseerde installatie komen voor vlotte uitrol van nieuwe identieke systemen.
  • Installatie software opzetten voor inline software updates met minimale serviceonderbreking.
  • Het dient een opzet te zijn waarbij (data) continuïteit geborgd is.
  • Er moet voldaan worden aan de wettelijke vereisten v.w.b. data beveiliging en access management.

Bij bovengenoemde doelen zijn er aspecten die we nog niet weten. Daarbij kunnen we de volgende uitdagingen definiëren.

  • Hoe brengen we alle tools samen in een cloudserver?
  • Hoe groot moet de cloudserver worden?
  • Hoe kunnen we de tools van verschillende leveranciers laten samenwerken?
  • Hoe borgen we dat we aan alle wettelijke vereisten voldoen?
  • Welke methoden en tools zijn het beste voor data versleuteling en access management?
  • Wat zijn de risico’s van een dergelijke opstelling en hoe ondervangen we die?

 

Oplossing

Om voor dit project tot een gedegen oplossing te komen is er eerst onderzoek nodig. We moeten de scope vaststellen, d.w.z. wat komt er wel en niet in de eindoplossing. Vervolgens, als we weten hoe de genoemde tools werken, kunnen we naar een initiële conceptopstelling toewerken.

Tijdens het testen van de installatie op een testomgeving werken we direct toe naar een deployment methodiek en werken deze gaandeweg verder uit. De methodiek is een combinatie geworden bestaande uit Saltstack en Docker-compose. Hierover onder ‘Deployment’ meer. Tevens nemen we in de architectuur een (User) VPN oplossing mee. Daarnaast testen we alle tools op het gebied van identificatie en account management (IAM) voor maximale controle en veiligheid.

 

Aanloop en onderzoek

Om tot daadwerkelijke implementatie over te gaan moeten we eerst weten wat er geïmplementeerd moet worden. Na de gesprekken met Metric Angel hebben we de behoeften duidelijk. Er moet onderzocht worden wat de (installatie) specificaties van de applicaties zijn en hoe we deze op één systeem samen kunnen brengen. We hebben gezamenlijk deze tool opzet in een (tijdelijke) testomgeving uitgerold. 

Door dit te testen kan een generiek URL schema opgezet worden. Dit maakt eenduidige toegang voor de afnemers mogelijk. Hierdoor is ook duidelijk wat de proxy configuratie moet worden, zodat we hier herbruikbare templates voor op kunnen zetten. Door onze uitgebreide ervaring met Saltstack wordt een installatie niet met de hand uitgevoerd maar direct uitgeschreven in de vorm van een uitvoerbaar manifest. Met dat alle tools onderzocht en getest zijn, is e.e.a. gereed voor installatie. In overleg is besloten dat CAP5 server provisioning doet en Metric Angel applicatie upgrade deployments. We hebben Metric Angel geholpen met het opzetten van de installatiesoftware, te weten docker-compose, en de eerste deployments begeleid.

 

Server dimensionering

Nadat op de testomgeving een casco applicatie stack is uitgerold hebben we een indicatie van de basisbehoeften voor de omvang van de cloudserver. Dit kan uiteraard nog variëren afhankelijk van de dataset omvang, dat zal per geval beoordeeld moeten worden.

Naast een eerste indicatie van processoren, geheugen en opslagruimte moet gekeken worden naar de hoeveelheid data die opgehaald en verwerkt wordt. Voorts is een belangrijk aspect de te verwachten systeem load voor het transformeren van de data. Dit vergt met name rekenkracht, dus voldoende processoren, maar ook geheugen. 

Database instanties werken het beste als zij voldoende geheugen beschikbaar hebben. Daarbovenop komt de extra behoefte door de zwaarte van de query’s en de grootte van de tabellen die verwerkt moeten worden. Zet hier niet te klein in want te weinig geheugen kan leiden tot lange executie tijden en zelfs proces-uitval.

 

De onderdelen

De uiteindelijke opstelling die we herhaaldelijk kunnen uitrollen bevat de volgende aspecten.

 

Postgres

Een aantal van de tools hebben in hun standaard deployment Postgres in een container draaien. Dit is in beginsel prima. Echter als zaken groter worden en er meerdere postgres containers naast elkaar worden opgestart is het verstandiger de applicaties een OS gebaseerde postgres installatie te laten gebruiken. Hiermee is er meer controle op performance en configuratie en voorkom je onnodige geheugen consumptie. Onze deployment zorgt overigens voor installatie en automatische database aanmaak waar nodig.

 

Docker

Door de verschillende applicatie componenten middels Docker containers te virtualiseren is het gemakkelijk uitschalen. Aldus verplaatsen van individuele componenten naar een andere cloudserver. Tevens zorgt het voor eenvoudige en eenduidige installatieprocedures. 

 

Proxy

De applicaties worden achter een proxy service gezet voor betere controle en eenduidig gebruik door de afnemers, middels gestandaardiseerde URL schema’s. Bij verandering of verplaatsing van onderdelen aan de back-end, heeft dit geen impact op het gebruik en de levering aan de klant.

 

Deployment

Voor de samengestelde deployment is gekozen voor twee verschillende tools, te weten: Saltstack en Docker-compose. De combinatie van Saltstack en docker-compose zorgt voor een duidelijke ‘wie doet wat’ aanpak. Saltstack wordt gebruikt voor de algehele CAP5 infra en server provisioning. Daarmee realiseren we de opname van de nieuwe services in onder andere backups en monitoring. Vervolgens wordt Docker-compose ingezet, aangegeven als voorkeur door Metric Angel, voor de deployment van de applicatie stack zelf en haar en toekomstige upgrades.

 

Beveiliging

Firewalling

De firewall bestaat feitelijk uit een tweetal lagen:

  1. De cloud perimeter voor harde 1e-lijns afscherming
  2. In-host (zogenaamde ‘soft’) firewalling om verdere detectie en mitigatie te realiseren. Hierbij valt te denken aan het tegengaan van o.a. brute force login of andere aanvallen.

 

VPN-server

De VPN service zorgt voor een veilige toegang door enkel expliciet aangewezen medewerkers toegang te verlenen. Hierdoor zijn de services nooit openbaar toegankelijk. Dit draagt bij aan de algehele beveiliging alsook de wettelijke vereisten.

 

Identity en access management (IAM)

Voor wat betreft Identity en access management, kortweg IAM, zijn er een drietal toegangsniveaus ingericht.

  1. Zogenaamde persoonsgebonden VPN accounts om überhaupt bij de services te kunnen. Het gaat immers om belangrijke data die alleen door interne medewerkers toegankelijk moeten zijn.
  2. Daarnaast zijn er applicatie-accounts binnen de diverse tools zodat Metric Angel en/of haar afnemers zicht en controle hebben op wie er daadwerkelijk bij welke data kan.
  3. Dan is er directe SSH server toegang (tevens afgeschermd door firewall en VPN) voor het beheren van server specifieke tooling en data transformatie gereedschap.

 

Data beveiliging

De eerder genoemde firewalling, VPN en IAM combinatie zorgen voor adequate afscherming. Daarnaast is het wettelijk verplicht om te zorgen dat data die verzonden of opgehaald wordt (uit externe bronnen alsook de toegang door gebruikers) tijdens verzending niet leesbaar is door derden. De delen die hiervoor zorgen zijn VPN, dit is een vorm van identificatie maar ook encryptie. Voorts is alle data verkeer dat via de proxy gaat (waaronder gebruikers verkeer) voorzien van SSL, welke ook zorgt voor encryptie. Tevens wordt op de data replicatie kanalen, veelal verbinding met externe databases of API’s, ook SSL encryptie toegepast.

 

Continuïteit

Bij continuïteit geldt altijd: Een ketting is zo sterk als de zwakste schakel.

Met andere woorden, we dienen hiermee rekeningen te houden vanaf de data beschikbaarheid aan de ‘bovenkant’ tot aan de hardware waarop je VPS draait aan de ‘onderkant’. Dit geldt ook voor je end-to-end bedrijfsprocessen en SLA’s in je volledige supply chain, maar dat kenmerk ik voor nu out of scope. Omdat clustertechniek een volgende stap is in een toekomstig groei traject, wijd ik daar op een later tijdstip een artikel aan.

De enkelvoudige server opzet waarvoor gekozen is, met daarbij de mogelijkheid snel een (nieuwe) deployment te kunnen doen, plus een backup van de unieke data is voldoende voor herstel bij calamiteiten. Neem bijvoorbeeld een totale server crash of data center dat afbrandt. Je zou de volledige dienst binnen 1 etmaal elders compleet kunnen herbouwen.

 

Risico’s

Wat zijn de risico’s van een dergelijke opstelling en hoe ondervangen we die? Risico’s moeten ook bedrijfsmatig beoordeeld worden, maar we beperken ons nu tot de data en techniek. Enkele voorbeelden:

  • Server inbraak
  • data of software corruptie
  • account hijacking
  • laptop verlies
  • data lekken

Uitgaande van de vuistregel “Risico = Kans x Impact” beoordelen we deze aspecten als volgt.

 

Inbraak

Omdat de firewalls ervoor zorgen dat de services niet voor publiek toegankelijk zijn en we dit borgen middels cyclische penetratie tests, zit daar nagenoeg geen risico. Daarnaast zorgt de tweede (in-host) firewall voor mitigatie van onder andere brute-force aanvallen.

 

Data corruptie

Vervolgens is, zoals boven te lezen, server herstel afdoende ingericht in het geval van calamiteiten. Daarnaast wordt een groot deel van de data ge-repliceert, dus is er slechts een back-up nodig van data uniek voor dit systeem.

Lees meer over backups en (data) beschikbaarheid op: https://cap5.nl/dataverlies-versus-niet-beschikbaar-zijn-van-data/ 

 

Data lekken

Een groter risico is bijvoorbeeld als een medewerker een laptop verliest. Even los van een eventueel datalek en het melden hiervan bij de Autoriteit Persoonsgegevens, is het dichtzetten van een gecompromitteerd account een kwestie van de VPN toegang intrekken. Daarmee is alle toegang ontzegd en direct gevaar geweken.

 

Wet en regelgeving

Ik beperk me in dit artikel tot de technische vereisten omtrent het verantwoordelijk omgaan met bedrijfsdata. Uiteraard is het taak dat de verwerkersverantwoordelijke het verwerken van privacygevoelige gegevens dit doet conform de geldende wetgeving en dit ook opnemen in hun privacy statement, verwerkersovereenkomst dan wel contracten.

De wet dicteert niet ‘hoe’ maar wel ‘wat’ je geregeld moet hebben, namelijk dat je je gegevens beschermt met hedendaagse moderne technische middelen. Zoals onder kopjes ‘Identity en access management’ en ‘Data beveiliging’ te lezen is, adresseert deze implementatie alle gangbare beveiligingsaspecten.

Daarnaast is het sowieso aan te raden om bedrijfsbreed dan wel voor de nieuwe product tak een data protection impact assessment (DPIA) uit te laten voeren.

 

Resultaat

Er is een architectuur samengesteld die rekening houdt met toekomstige uitbreiding en verandering. De gekozen opzet bevat o.a. een proxy component wat een dergelijke complexe opstellingen modulair houdt. Zo kunnen tools, indien nodig, individueel worden verplaatst naar hun eigen cloudservers in het geval van schaalvergroting. Tevens kunnen onderdelen worden vervangen zonder dat de gebruikerservaring ernstig wordt beïnvloed. 

Hieronder de belangrijkste highlights op een rij.

  • Modulair: een proxy service, dedicated postgres en dockerization maken de oplossing geschikt voor uitschalen.
  • Beveiliging: Middels VPN, dubbele firewalling, access management en data versleuteling is de opzet maximaal beveiligd
  • Deployment: Door een combinatie in te zetten van Saltstack en Docker Compose passend bij de rolverdeling, kunnen CAP5 en Metric Angel samen zorgen voor geautomatiseerde deployments om updates en verbeteringen door te voeren.
  • Continuïteit: Door het opzetten van gemanagede backups, een -weliswaar- enkelvoudige server op redundante hardware is de continuïteit gewaarborgd.
  • Risico’s: Een backup plan, dataversleuteling en toegangsbeheer (IAM) zorgen voor veiligheid en betrouwbaarheid. 
  • Wetgeving: De opzet zal bij een data protection impact assessment (DPIA) ondersteunend zijn aan de geldende richtlijnen.

 

De behandelde oplossing is een geoptimaliseerde, goed beveiligde en schaalbare oplossing specifiek voor Metric Angel. Uiteraard kan een dergelijke standaardisatie voor een scala aan cloud opstellingen gerealiseerd worden.

Loop je zelf met cloud- en standaardisatie vraagstukken? Wij kunnen je helpen. Neem voor een oriënterend gesprek contact met ons op.

Over Gerard

Gerard Petersen is oprichter en eigenaar van CAP5. Hij heeft meer dan 35 jaar ICT ervaring en 10+ jaar ervaring in ondernemerslandschap. Gerard wordt gedreven door de optimale combinatie tussen mens en techniek en gaat voor het maken van maatschappelijke impact. Gerard is vanuit CAP5 actief als adviseur voor ICT operatie en management. 

Meer over Gerard

Open chat
1
Hulp nodig?
Scan the code
Hi 👋 ... kan ik je helpen?