Een Laravel-applicatie kan op één server staan en op tien. Welke setup je nodig hebt, volgt uit twee vragen. Hoe erg is het als je applicatie een uur niet bereikbaar is, en hoeveel mensen werken er tegelijk in?
Hieronder staan de setups die we in de praktijk neerzetten, van de eenvoudigste tot de meest robuuste. Per setup lees je wat er staat en waar het in de praktijk misgaat. Elke stap voegt zekerheid en snelheid toe, en kost meer geld en meer beheer.
Waarom de serverkeuze iets voor jou uitmaakt
Een server is een computer in een datacenter die jouw applicatie draait. We hosten op eigen servers en beheren die zelf, zodat we bij een probleem direct kunnen ingrijpen.
Zo'n machine kan uitvallen, vol raken of te druk worden. Wat er dan met jouw applicatie gebeurt, bepaalt de setup. Staat alles op één server, dan is de applicatie offline tot iemand het heeft opgelost. Bij een setup met een load balancer merkt geen bezoeker er iets van.
Setup 1: alles op één server
De webserver, de applicatie en de database draaien op dezelfde machine. Dit is de setup waar de meeste websites en interne applicaties op staan, en voor die groep is het ook de juiste keuze. Eén machine om te beheren, één plek waar je moet kijken als iets niet werkt, en de laagste maandprijs.
Het werkt goed zolang stilstand geen geld kost. Een brochuresite, een interne tool voor tien collega's, een applicatie die 's nachts niemand gebruikt. Met dagelijkse backups en updates die op tijd worden gedaan, gaat zo'n server jaren mee.
Waar het misgaat, zit in het woord "één". Bij een storing, een herstart of een grotere update ligt de applicatie plat, want er is niets dat het werk overneemt. Daarnaast delen de onderdelen dezelfde processor en hetzelfde geheugen. Een zware rapportage in de database maakt op zo'n moment ook de website traag voor iedereen die er niets mee te maken heeft. En een schijf die volloopt met logbestanden legt in één keer alles stil.
Setup 2: applicatie en database apart
De database verhuist naar een eigen machine. De applicatieserver handelt de verzoeken van bezoekers af en vraagt de gegevens op bij de databaseserver ernaast.
De winst zit in de zwaarte van de twee machines. Een database wil vooral geheugen en snelle schijven, een applicatieserver vooral processorkracht. Staan ze los, dan kun je ze afzonderlijk vergroten en trekt een zware query de website niet meer mee omlaag. Voor een applicatie met veel data of veel rapportages is dit de eerste stap die echt iets oplevert.
Voor de beschikbaarheid verandert er weinig. Er is nog steeds één applicatieserver, dus onderhoud aan die machine betekent nog steeds stilstand. Er komt ook een netwerkverbinding tussen de twee, en dat merk je zodra een pagina honderden losse queries afvuurt in plaats van een paar. Die pagina's moet je dan eerst opruimen, anders levert de scheiding vertraging op in plaats van snelheid.
Setup 3: twee applicatieservers achter een load balancer
Vooraan staat een load balancer die elk verzoek naar een van de twee applicatieservers stuurt. Beide servers draaien dezelfde code en praten met dezelfde database. Dit is de stap waarop downtime uit je onderhoud verdwijnt. We halen één server uit de rotatie, werken hem bij, zetten hem terug en doen daarna de andere. Wie op dat moment in de applicatie werkt, merkt er niets van.
Dezelfde winst geldt bij een storing. Valt een van de twee machines weg, dan ziet de load balancer dat de server niet meer antwoordt en gaat al het verkeer naar de ander. Je zit dan tijdelijk op de halve capaciteit, en verder gaat het gewoon door.
Wat deze stap vraagt, zit in de applicatie en niet in de servers. Sessies mogen niet meer op de schijf van één machine staan, want dan is een gebruiker uitgelogd zodra hij op de andere server terechtkomt; die gaan naar Redis of de database. Uploads horen op een gedeelde opslag, anders staat een net geüpload bestand op de ene server en niet op de andere. Cronjobs en achtergrondtaken draaien op één machine of nemen een lock, zodat een factuur niet twee keer verstuurd wordt. En de deploy moet beide machines raken. Dat is precies wat we nakijken bij het applicatiebeheer uitbesteden, want een applicatie die hier niet op voorbereid is, gaat achter een load balancer rare dingen doen.
De database is in deze setup het onderdeel dat nog geen achtervang heeft.
Setup 4: meerdere applicatieservers met een database-replica
Achter de load balancer staan nu drie of meer applicatieservers, en de database heeft een replica gekregen. De hoofddatabase verwerkt alles wat er wordt weggeschreven, de replica houdt daar een actuele kopie van bij en levert het leeswerk.
Dat leeswerk is meestal het grootste deel. Overzichten, rapportages en exports gaan naar de replica en houden de hoofddatabase vrij voor orders en mutaties. Bij een storing op de hoofddatabase heb je bovendien een kopie van een paar seconden oud in plaats van een backup van vannacht. Applicatieservers bijzetten kan in deze opzet binnen een dag, wat handig is als je een piek ziet aankomen.
De valkuil zit in de vertraging van de replicatie. Een wijziging staat een fractie later op de replica dan op de hoofddatabase, en wie meteen na het opslaan een overzicht opvraagt, kan zijn eigen wijziging missen. Daarom bepalen we per query welke kant hij op gaat, en lezen we direct na een mutatie uit de hoofddatabase. Het omschakelen naar de replica bij een storing is ook een handeling die je geoefend moet hebben, anders sta je die te bedenken op het moment dat het misgaat.
Wat voegt een cache toe?
Een cache bewaart antwoorden die de applicatie net heeft berekend, zodat het bij het volgende verzoek niet opnieuw hoeft. Denk aan een prijslijst, een menu of een dashboard dat honderden keren per uur wordt opgevraagd terwijl de inhoud maar één keer per dag verandert.
In Laravel-applicaties gebruiken we hiervoor Redis. Het is meestal de goedkoopste snelheidswinst die er is. Er komt geen zwaardere machine bij en de database krijgt minder werk te doen.
En wat doet een CDN?
Een CDN is een netwerk van servers over de hele wereld dat kopieën van je afbeeldingen, stylesheets en documenten bewaart. Een bezoeker krijgt die bestanden van een locatie dicht bij hem in plaats van uit het datacenter waar je server staat. Dat maakt de site merkbaar sneller en haalt een groot deel van het verkeer van je eigen servers af.
Het gaat dan om de statische bestanden. De pagina's zelf, de berekeningen en alles wat achter een login zit komen nog steeds van je eigen server. Een CDN neemt dus het makkelijke verkeer over en komt niet in de plaats van een extra server. Voor een webshop met veel afbeeldingen is het bijna altijd de moeite waard.
Alles erin: de complete setup
Bij de grootste platforms komen alle onderdelen samen. Een CDN vooraan, daarachter een load balancer met meerdere applicatieservers, en die praten met een cache, een zoekserver en een database met replica. Elk onderdeel neemt een deel van het werk over, zodat geen enkele machine alles hoeft te doen.
De zoekserver komt van al deze onderdelen het minst vaak langs. Zoeken en filteren door honderdduizenden regels is werk waar een database traag van wordt. Elasticsearch houdt daar een eigen index van bij en geeft antwoord in milliseconden, ook op een zoekopdracht met een typefout erin.
De opties naast elkaar
Een relatieve vergelijking. Wat het in jouw geval kost, hangt af van de zwaarte van de machines en het aantal gebruikers.
Setup | Kosten | Beschikbaarheid | Schaalbaarheid | Snelheid |
|---|---|---|---|---|
Eén server | Laagst | Downtime bij storing en update | Machine zwaarder maken | Genoeg bij rustig gebruik |
Applicatie en database apart | Laag | Downtime bij een storing | Beide delen los te vergroten | Beter bij veel data |
Load balancer, twee app-servers | Midden | Blijft in de lucht bij uitval | Server bijzetten kan | Verkeer over twee machines |
Meerdere servers en een replica | Hoogst | Database heeft achtervang | Meegroeien met de piek | Hoogste capaciteit |
Cache (Redis) | Klein | Geen effect | Stelt zwaardere servers uit | Winst op herhaald werk |
CDN ervoor | Klein | Geen effect | Neemt beeldverkeer over | Sneller, ook buiten Nederland |
Welke setup adviseren wij?
Voor de meeste websites en interne applicaties is één goed onderhouden server met dagelijkse backups precies genoeg. Zodra mensen er dagelijks in werken of er omzet door loopt, adviseren we de stap naar een load balancer met twee applicatieservers. De snelheid is daarbij de kleinste winst. Het gaat erom dat we kunnen onderhouden en herstellen zonder dat iemand het merkt, en dat valt onder website en applicatie onderhoud met een vaste maandprijs.
Cache en CDN zetten we vaak eerder in dan extra servers. Ze kosten weinig en leveren doorgaans meer snelheid op dan een zwaardere machine. Servers bijzetten heeft alleen zin als de applicatie erop is voorbereid, en dat is het eerste wat we nakijken bij iets wat al draait.
Gaan we een webapplicatie laten maken die vanaf dag één op meerdere servers moet kunnen staan, dan bouwen we die eisen meteen in. Sessies, uploads en achtergrondtaken zijn dan van het begin af aan losgekoppeld van de machine waar ze op draaien, en onze Laravel specialist richt de omgeving daarop in.
Veelgestelde vragen
Wat is een load balancer eigenlijk?
Een kleine server die vooraan staat en elk verzoek doorstuurt naar een van je applicatieservers. Hij controleert of die servers nog antwoorden en slaat een server over die stil ligt. Bezoekers merken er niets van, want zij zien alleen jouw domeinnaam.
Kan ik later overstappen naar een zwaardere setup?
Ja, en dat is ook de gebruikelijke route. Van één server naar een gescheiden database is een verhuizing van een paar uur. De stap naar meerdere applicatieservers vraagt meer voorbereiding, omdat sessies, uploads en achtergrondtaken dan niet meer op één machine mogen staan.
Is twee servers dan altijd veiliger?
Voor uitval wel, voor beveiliging niet automatisch. Meer machines betekent meer onderdelen om bij te houden. Zonder monitoring en updates is een setup met vier servers kwetsbaarder dan één server die goed wordt onderhouden.
Wat gebeurt er met mijn data bij een storing?
Backups staan altijd los van de server zelf, welke setup je ook hebt. Bij een replica is er daarnaast een actuele kopie van de database, waardoor je bij een storing minder werk verliest dan bij een backup van vannacht.
Twijfel je welke setup je nodig hebt?
Vertel ons hoeveel mensen er met de applicatie werken en wat er gebeurt als hij een uur niet bereikbaar is. Daar volgt de setup meestal vanzelf uit. We kijken vrijblijvend mee.