Ron Rademaker
26.05.2021

AWS Aurora, waarom we deze database steeds vaker inzetten

WhatsApp Image 2021-05-26 at 10.38.22

De basis van een modern IT ecosysteem is de data hub. Connect Holland bouwt zo’n data hub met behulp van diverse AWS producten. De AWS Aurora database is een van de belangrijkste bouwstenen van deze data hub. We nemen je in dit artikel graag mee voor een deep dive in deze database.

AWS Aurora is een volledig gemanagede, relationele database in de cloud. Je kan AWS Aurora zien als een ‘gewone’ SQL database, maar dan zonder de overhead van het beheren van een server. Wat dat betreft is een Aurora database heel goed te vergelijken met bijvoorbeeld AWS RDS MySQL of AWS RDS PostgreSQL. Sterker nog, Aurora is compatible met zowel MySQL als PostgreSQL waardoor je deze databases dus eenvoudig door elkaar kan vervangen. Aurora biedt echter wel enkele grote voordelen ten opzichte van (RDS) MySQL of (RDS) PostgreSQL. Het enige nadeel van Aurora is dat je deze niet binnen een andere infrastructuur dan die van Amazon kan gebruiken. Als je Aurora gebruikt dan zal je je database ook binnen de AWS infrastructuur moeten gebruiken (je kan de data overigens wel weer prima vanuit een andere locatie gebruiken).

De belangrijkste voordelen van AWS Aurora

De Aurora database gebruikt een totaal andere manier van data opslag dan bijvoorbeeld MySQL of PostgreSQL. Zowel MySQL als PostgreSQL slaan hun data op de server waar ze op draaien op. Aurora gebruikt een redundante en gedistribueerde data opslag. 

Dit heeft een paar voordelen:

  • Redundante opslag: elk stukje data wordt op meerdere plekken opgeslagen. Indien data door een storing verloren gaat dan merk je hier als gebruiker niets van.
  • Gedistribueerde opslag: de data wordt niet alleen op meerdere plekken opgeslagen, deze plekken zijn ook echt op fysiek andere locaties, in andere datacentra dus. Hierdoor is de data dus ook bij het compleet uitvallen van een datacentrum nog steeds direct beschikbaar. 
  • Zero impact backups: er worden automatisch backups gemaakt van de database zonder impact op de database. De database wordt op het moment van het maken van een backup dus niet tijdelijk zwaarder belast. Gebruikers merken hierdoor niets van het maken van een backup. Behalve als deze teruggezet moet worden. Backups maken geen impact en daarom kunnen standaard veel backups gemaakt worden. Een Recovery Point Objective (RPO) van 5 minuten is standaard. Dat betekent dat er maximaal 5 minuten dataverlies zal zijn in geval van een calamiteit. Overigens is het bijna nooit nodig om de backup te gebruiken, omdat de data al redundant en gedistribueerd is opgeslagen.

Deze redundante en gedistribueerde opslag maakt het ook mogelijk om eenvoudig een of meerdere zogenaamde read replicas toe te voegen. Een read replica is een database server die alleen gebruikt kan worden om data uit de database te lezen, niet om data weg te schrijven. Een Aurora read replica heeft de volgende voordelen ten opzichte van een MySQL of PostgreSQL RDS read replica:

  • Geen overhead: omdat data gedistribueerd opgeslagen is, kan de read replica hier direct bij. Het is niet nodig om een kopie van de data te maken en die steeds bij te werken als er data in de database verandert. Hierdoor gaat geen CPU en geheugen verloren aan het ‘in-sync’ houden van de read replica en kunnen gebruikers van zowel de write database als de read replica de database zwaarder belasten zonder performance verlies.
  • Automatic failover: een Aurora read replica kan ook gebruikt worden voor automatic failover. Indien de write database niet meer werkt, kan een read replica automatisch gepromoveerd worden en die taken overnemen zonder dataverlies. Hierdoor is zonder handmatige actie de database weer volledig beschikbaar binnen 30 seconden.
  • Cross-region replication: een read replica hoeft niet per se in deze AWS region uitgerold te worden. Het is bijvoorbeeld mogelijk om een read replica van een database die in de eu-west-1 (Ierland) region draait uit te rollen in us-west-1 (California) en us-east-1 (North Virginia) en je applicatie zo te routeren dat gebruikers vanuit de Verenigde Staten uit die read replicas lezen. Hiermee ontlast je niet alleen de database in Europa, maar ervaren de gebruikers in de Verenigde Staten ook minder latency omdat het datacentrum dat zij gebruiken simpelweg dichterbij is. 

Schematisch kan een Aurora cluster met 3 read replicas in 3 availability zones (verschillende datacentra in dezelfde regio) er als volgt uit zien:

1621926214244

Aurora in actie

Case: Lamb Weston / Meijer customer portal

De customer portal van Lamb Weston / Meijer maakt het voor gebruikers onder andere mogelijk om orders te plaatsen, orders te tracken en informatie over de orders in te zien. Hiervoor maken we onder andere gebruik van een Aurora database. Het netwerk (subnet) waarbinnen we de Aurora database uitgerold hebben is via een Direct Connect verbinding rechtstreeks verbonden met het datacentrum waar Lamb Weston / Meijer hun servers heeft staan (dit is geen AWS datacentrum). Serverless functions synchroniseren de relevante data tussen het datacentrum en de Aurora database en maken deze beschikbaar in de customer portal. We gebruiken in dit project de RDS Proxy voor connection pooling en daarmee voorkomen we problemen met het maximaal aantal verbindingen met de database. Benchmark tests hebben laten zien dat de portal ook zeer grote aantallen requests, op een relatief kleine database instance, met slechts 2 virtuele CPU's en 2 GB geheugen, probleemloos aankunnen. Hiermee is de customer portal van Lamb Weston / Meijer klaar voor de toekomst en verwachten we de aankomende tijd veel nieuwe functionaliteiten toe te kunnen gaan voegen.

Case: Caru Containers data platform

We ontwikkelen met Caru Containers een data hub. Deze data hub vormt de basis van het toekomstige IT ecosysteem van Caru Containers waarop een diversiteit van verschillende applicaties aangesloten kunnen worden. De kern van de data laag van de data hub is een Aurora database. Alle cruciale data voor de dagelijkse operatie van Caru Containers wordt opgeslagen in deze Aurora database. Dit betekent informatie over miljoenen containers en bijbehorende informatie. Het is cruciaal om zeer snel informatie over deze containers te ontsluiten. We maken daarom gebruik van serverless functions en een RDS proxy. Hierdoor is de oplossing extreem schaalbaar en kunnen we vele concurrent requests verwerken. Dit heeft als voordeel dat de applicaties die op de data hub worden aangesloten parallel API requests kunnen doen om zo razendsnel de benodigde data te laden. Een read replica zal het mogelijk maken om via standaard BI tooling real time inzicht te krijgen in de de business van Caru Containers. 

Case: Nacht van de Vluchteling app

We ontwikkelden met Nacht van de Vluchteling de app waarmee tijdens de corona lockdown in 2020 mensen vanuit huis deel konden nemen aan het virtuele Nacht van de Vluchteling evenement. Het reguliere, jaarlijkse evenement waarbij deelnemers geld inzamelen door een hele nacht door te lopen, kon uiteraard geen doorgang vinden. We gebruiken voor Nacht van de Vluchteling de zogenaamde serverless uitvoering van de Aurora database in combinatie met de data API. Deze setup biedt enkele grote voordelen voor deze specifieke toepassing:

  • Schaalbaarheid: de serverless uitvoering van de Aurora database schaalt automatisch. Dit is met name interessant als je niet precies in kan schatten hoeveel verkeer er op je applicatie af komt of je grote pieken in dit verkeer verwacht. Apps voor evenementen zijn typisch applicaties waarbij gedurende korte tijd veel verkeer kan worden verwacht.
  • Data API: de serverless API waar de app gebruik van maakt schaalt net als de database automatisch mee. Dit kan problemen opleveren met het maximaal aantal verbindingen met de database. Dit voorkomen we in geval van de Nacht van de Vluchteling door gebruik te maken van de Data API.

Meer blogs

Sluiten