Web applicaties of mobiele apps met veel gebruikers, of die kritisch zijn voor het bedrijfsproces moeten hoog beschikbaar zijn. Om dat te bereiken moeten veel stappen worden ondernomen. Het begint met het bug vrij krijgen van de applicatie code, maar voor veel applicaties met een lang track record is dat vaak grotendeels in orde.
Dit blog beschrijft in grote lijnen de mogelijkheden die je met Amazon cloud services kunt bereiken.
Om een app hoog beschikbaar (HA) te maken moeten alles zogenaamde Singe Points of Failure (SPOF) worden uitgesloten. Dat zijn in volgorde DNS, Webserver/Applicatie Server, Database en filesysteem.
De meeste DNS servers zijn al HA en zo niet is het relatief eenvoudig een secundaire DNS server op te zetten die een read replica is van de primaire.
Amazon biedt via een dienst elastic load balancing (ELB) een hoog beschikbare en in DNS opgenomen URL die je kunt gebruiken om je webserver beschikbaar te maken aan de wereld.
Die ELB verwijst verkeer door naar de web/applicatie servers die hier achter zijn geconfigureerd. Dit kunnen gewone virtuele machines (EC2) zijn of een auto scaling group. Zo'n auto scaling group bestaat ook uit virtuele machines, maar die automatisch worden bijgeschakeld als er meer capaciteit nodig is. Je kunt de minimale, gewenste en maximale capaciteit instellen als harde waardes.
Iedere node in het cluster wordt begouwd op basis van een image dat je kunt maken van de eerste node. Deze node moet dus helemaal up to date zijn en mechanismes voor software update of in het image hebben of er moet een ander mechanisme worden gebruikt om software en change mgmt toe te passen.
Het filesysteem. Veel web applicaties hebben bestands structuren waar ze bepaalde data wegschrijven die niet in de database terecht komt. Dat kunnen log bestanden zijn, configuratie wijzigingen maar vaak ook andere bestanden als plaatjes e.d.
Die moeten natuurlijk voor iedere applicatie server hetzelfde zijn. Een shared filesysteem zoals NFS (in Amazon termen EFS) biedt hier uitkomst. Nadeel is echter dat NFS niet zo lekker schaalt en vrij snel performance problemen geeft. Een oplossing daarvoor die wij toepassen is cacheFS waarmee je feitelijk weer lokaal op de clustered nodes de data gaat cachen.
De database hoog beschikbaar maken kan je standaard met Amazon RDS Door de optie multi-az aan te zetten wordt deze in meerdere availability zones opgezet en automatisch redundant gemaakt door Amazon. Mocht de primaire site of database uitvallen blijft de DNS instance gelijk maar wordt de database opgestart op de andere site zonder herconfiguratie van de applicatie servers vinden deze hun weg daarna opnieuw. Dat gaat dus niet zonder down tijd maar die is beperkt tot enkele minuten.
Nu is er feitelijk nog 1 ding om over na te denken en dat is session management. Veel (php) applicaties controleren of ze de sessie herkennen adhv een unieke key die is afgegeven door de applicatie server. Om te voorkomen dat een andere webserver dit niet herkend zijn twee strategieen mogelijk. Een is de ELB zo configureren dat hij de state van de clients bijhoud (stickyness) en het verkeer altijd routeert naar de applicatie server waar deze gebruiker op thuis hoort. Dat heeft als grote nadeel dat de load niet netjes wordt verdeeld en dat als een applicatie server wegvalt (waar je niks over hebt te zeggen met autoclustering) dat deze user wordt uitgelogd. Netter is door de sessie op te slaan of in via EFS op een shared filesysteem. Wij gebruiken hier memcached voor. Dat is sowieso aan te bevelen om te gaan gebruiken omdat memcached ook SQL queries kan cachen en hergebruiken. Memcached is prima hoog beschikbaar op te zetten en Amazon heeft hier ook standaard opties voor.
Ik hoop dat dit een nuttige maar rundimentaire beschrijving is. Uiteraard helpen we (nieuwe) klanten graag om dit voor jullie te doen. Schroom niet om dit vrijblijvend te vragen.