Recent was de nieuwe app van een groot wandelevenement in Nederland in het nieuws met hun app, die vrij snel na de start van het evenement niet meer functioneerde doordat de server overbelast was. Dit kwam door de enorme hoeveelheid aanvragen vanuit de mobiele app. Enorm teleurstellend voor de lopers en volgers, maar natuurlijk ook voor de organisatie.
Dit soort teleurstellingen zijn vandaag de dag niet meer nodig, maar dan moet je bij de realisatie van de hele oplossing wel de juiste keuzes maken. Hieronder geef ik een toelichting op een aantal van onze principes en regels die jij kan gebruiken om een platform te bouwen dat schaalbaar is en dat tegen een stootje kan. Want dat er iets fout zal gaan is geen vraag, maar een gegeven.
De principes
Ontwerp voor veiligheid
Misbruik van je platform kan jouw reputatie en ook de beschikbaarheid van je API beïnvloeden. Daarnaast moet iedereen voldoen aan de AVG (GDPR) wetgeving. Daarom staat veiligheid bij ons op nummer één.
1. Zorg voor authenticatie en autorisatie
Om te voorkomen dat onbevoegden gegevens kunnen inzien, is het van belang dat het platform de gebruiker identificeert die van de app gebruik maakt. Dit wordt authenticatie genoemd. Als de identiteit van de gebruiker is vastgesteld, dan moet je ervoor zorgen dat de gebruiker alleen toegang heeft tot alleen die gegevens die de desbetreffende gebruiker nodig heeft. Dat wordt autorisatie genoemd.
2. Versleutel alle gegevens
Het is belangrijk dat gegevens altijd versleuteld zijn. Bij de meeste is al bekend dat je voor het netwerkverkeer tussen de verschillende onderdelen van je oplossing altijd een versleutelde verbinding moet gebruiken (denk aan HTTPS).
Wat te vaak nog wordt vergeten is dat gegevens ergens worden opgeslagen op een server en dat als die server wordt gehackt onbevoegden toegang hebben tot die gegevens. Dus zorg ervoor dat opgeslagen gegevens - gegevens in rust - ook standaard worden versleuteld.
3. Valideer alle ontvangen gegevens
Controleer in elk component van je platform of de gegevens die het ontvangt valide zijn. Alleen de invoer van een gebruiker controleren in de mobiele app is niet voldoende. Er zijn namelijk altijd mensen die in staat zijn rechtstreeks jouw API aan te roepen en proberen om ongeldige data te injecteren. Andersom moet de mobiele app ook gegevens valideren die het ontvangt van de server. Denk bijvoorbeeld aan man-in-the-middle-attacks waarbij een hacker het verkeer omleidt en ongeldige gegevens injecteert.
Ontwerp voor schaalbaarheid
Je kunt vrijwel nooit goed inschatten hoe jouw systeem in de dagelijkse praktijk gebruikt gaat worden. Je zal altijd te maken hebben met piekbelastingen. Om de beschikbaarheid van het systeem - ook bij piekbelastingen - te kunnen garanderen moet je je platform ontwerpen voor schaalbaarheid. Daarnaast levert een goed ontworpen systeem kostenbesparingen op, omdat je gemiddeld minder capaciteit hoeft te reserveren dan de te verwachten piekbelasting. Waarbij het een utopie is om te denken dat de te verwachten piekbelasting correct voorspeld kan worden.
4. Kies voor serverless
De term serverless klinkt als een hype, maar het is de manier om te voorkomen dat je zelf servers moet gaan beheren en bij moet gaan schakelen als het verkeer toeneemt. Daarnaast zorgt het gebruik van functionele serverless componenten ervoor dat je niet één hele grote logge foutgevoelige oplossing bouwt waar alle functionaliteit in zit, maar dat je allemaal kleine beheersbare functionele componenten bouwt. Omdat het allemaal kleine losse functionele componenten zijn, kunnen deze ook eenvoudig los van elkaar vervangen en opgeschaald worden.
5. Kies de juiste opslag voor je gegevens
Niet alle gegevens hoeven in een database te worden vastgelegd. Foto’s en andere grotere bestanden kun je bijvoorbeeld meestal beter opslaan in een object of blob opslagdienst. Ook hier geldt, ga niet zelf een server opzetten, maar gebruik een bestaande dienst.
Voor gegevens die wel in een database thuishoren is over het algemeen de traditionele relationele database niet de oplossing vanwege de beperkte schaalbaarheid (daarnaast is het prijstechnisch ook vaak niet interessant). Meestal - maar zeker niet altijd - is een NoSQL database een betere keuze. Het uitgangspunt voor je data is meestal wel een relationeel datamodel, maar dat model moet je op een slimme manier vertalen naar een datamodel voor een NoSQL database. Waar je bij een relationele database vaak meerdere tabellen hebt, heb je in een NoSQL database vaak maar één tabel nodig waarin alles op een slimme manier wordt vastgelegd, rekeninghoudend met de wijze waarin de data gebruikt wordt. Dat laatste maakt het ontwerpen van een datamodel voor NoSQL een vak apart.
6. Kies de juiste manier van gegevens verwerken
Niet alle gegevens zijn gelijk, dus hier mogen we discrimineren. Sommige gegevens moeten direct door de server verwerkt worden, maar dat geldt zeker niet voor alle gegevens. Als een gebruiker zich aanmeldt, dan wil je dat die gegevens meteen worden verwerkt, omdat een gebruiker meteen het resultaat wil zien. Maar dat geldt bijvoorbeeld niet voor de huidige posities van lopers. De app verstuurt de positie via het mobiele netwerk naar de server en wacht op een antwoord van de server dat de positie is opgenomen.Om de kans op falen te verkleinen moet je het ontvangen van de positie en het verwerken van de positie scheiden in je serveromgeving. Een oplossing is het gebruiken van een wachtrij (queue) voor posities
Ontwerp voor falen
Een platform bestaat uit zeer veel verschillende componenten die allemaal van elkaar afhankelijk zijn. Iedere component kan en zal in de praktijk een keer falen. Daarnaast zijn er onverwachte gebeurtenissen van buitenaf. Dus per definitie heb je nooit de volledige controle over alle componenten.
7. Het mobiele netwerk faalt
Eén van de schakels in de keten is het mobiele netwerk dat wordt gebruikt voor het versturen van gegevens (data) tussen de app en de server. Zeker bij grote evenementen waarbij zeer veel mobiele telefoons binnen een klein gebied worden gebruikt zullen de zendmasten van de telecomproviders overbelast kunnen raken. Met als gevolg dat de data niet wordt verstuurd. De meeste ontwikkelaars houden hier wel rekening mee door automatisch data opnieuw te versturen. En daar gaat het dan ook vaak fout. Als iedere app de data meteen opnieuw gaat versturen, dan belast je het mobiele netwerk nog meer, waardoor herstel bijna onmogelijk wordt. Dus het automatisch opnieuw versturen moet op een slimme manier gebeuren, zodat de kans dat meerdere telefoons tegelijkertijd iets doen kleiner is. Maar ook als het meerdere keren achter elkaar fout gaat, dan moet de app het automatisch minder vaak gaan proberen. Op die manier wordt het mobiele netwerk automatisch ontlast. Een technische oplossing hiervoor heet exponential backoff.
8. De server is tijdelijk overbelast of niet beschikbaar
Het kan ook voorkomen dat de server omgeving tijdelijk overbelast is en aanvragen niet meer kan verwerken. Hier geldt hetzelfde als voor het mobiele netwerk. Meestal ontdekt de app dit vanzelf en heeft de ontwikkelaar er meestal al voor gezorgd dat de data opnieuw wordt verstuurd of aangevraagd. Alleen niet op een slimme manier. De oplossing hiervoor is identiek aan de oplossing voor een falend mobiel netwerk.