Je applicatie opzetten: Hoe kies je de beste serverconfiguratie?

Inleiding

Technologie en internet zijn een centrale rol gaan spelen in ons dagelijks, academisch en professioneel leven. Daarom is het enorme aantal websites en applicaties dat tegelijkertijd bestaat geen verrassing. Als bedrijf wil je graag een bijbehorend webplatform hebben. Een applicatie stelt je in staat om je diensten met gemak te vermarkten en te leveren aan je doelgroep.

Ongeacht de reden waarom je een webapplicatie maakt, moet je bepalen hoe je deze gaat bouwen. Er zijn veel opties tot je beschikking als het gaat om het kiezen van de beste serverconfiguratie. De serverarchitectuur die je kiest, bepaalt hoe je alles in je omgeving uitvoert en beheert. Daarom moet deze beslissing na zorgvuldige overweging worden genomen.

Hoe kies je de juiste serverconfiguratie

Dus hoe beslis je welke architectuur 'juist' is voor jouw applicatie? Om dat te doen, moet je eerst nadenken over wat de vereisten voor je webapplicatie zijn. Er moeten bepaalde functies zijn die je moet integreren om het efficiënt te laten werken voor jouw specifieke use-case. Misschien streef je bijvoorbeeld naar een applicatie die eenvoudig te schalen is. Of misschien moet je applicatie soepel werken op zowel browsers als mobiele apparaten. Tegelijkertijd kan je budget ook je grootste zorg zijn.

Ongeacht wat je vereisten zijn, moet je weten dat je een aangepaste oplossing voor je applicatie kunt maken. In deze handleiding verkennen we de verschillende soorten servers die veel mensen doorgaans gebruiken voor hun webapplicaties. We zullen de verschillende use-cases bespreken en wanneer een bepaalde configuratie het beste kan worden gebruikt. Om je te helpen beslissen of het geschikt is voor jou, geven we je ook enkele voor- en nadelen van elke serverarchitectuur.

1. Alles op één server

Zoals de naam al doet vermoeden, laad je de hele omgeving op één enkele server. De omgeving omvat je webserver, je applicatieserver en de databaseserver. Het werkt bijvoorbeeld op de Linux, Apache, MySQL, en PHP (LAMP) stack-configuratie. Je kunt onze handleidingen volgen over hoe je de LAMP-stack installeert op een Ubuntu-server en hoe je de LAMP-stack installeert op CentOS.

Wanneer te gebruiken:

Dit type opstelling werkt het beste als je weinig tijd hebt. Het is eenvoudig en snel op te zetten. Daarom werkt het goed voor simplistische webapplicaties.

Voordelen:

• Eenvoudig en gemakkelijk te begrijpen en te implementeren.
• Kost weinig tijd om in zijn geheel op te zetten.

Nadelen:

• Maakt horizontale schaalbaarheid niet mogelijk.
• Biedt zeer weinig op het gebied van isolatie van componenten.
• De applicatie en database concurreren in feite om dezelfde resources omdat ze zich op één enkele server bevinden.
• Als gevolg hiervan kun je slechte prestaties ervaren.

2. Aparte databaseserver

Het grootste probleem bij het gebruik van een enkele server is de concurrentie om beperkte resources. Deze configuratie is bedoeld om dat probleem op te lossen. Hier wordt het databasemanagementsysteem, of het DBMS, gescheiden gehouden van de applicatieserver. De databaseserver bevindt zich in een privénetwerk en heeft zijn eigen resources. Dit resulteert in betere prestaties en verhoogde beveiliging.

Wanneer te gebruiken:

Nogmaals, als je snel een configuratie wilt implementeren, is dit vrij eenvoudig te configureren. Het is de ideale oplossing als je je zorgen maakt dat de database en de applicatie om dezelfde resources concurreren.

Voordelen:

• Afzonderlijke, toegewijde systeemresources voor zowel de applicatie als de database, inclusief CPU, geheugen, I/O, enz.
• Meer potentieel voor schaalbaarheid in zowel de applicatie- als de databaselaag.
• Je kunt resources toevoegen en verwijderen naargelang je behoeften.
• Als je de database van het openbare internet haalt, kun je ook je beveiliging opschroeven.

Nadelen:

• Iets complexer dan een configuratie met één server.
• Een netwerkverbinding met lage bandbreedte of hoge latentie tussen de twee servers kan prestatieproblemen veroorzaken.

3. Reverse proxy of load balancer

Dit is waar load balancers in beeld komen. Load balancers worden doorgaans gebruikt in serveromgevingen om de prestaties en betrouwbaarheid te verbeteren. Ze doen dit door de belasting te verdelen ('balancing the load'); d.w.z. het verdelen van de werklast over een reeks servers.

Wanneer te gebruiken:

Load balancers zijn uiterst nuttig wanneer u horizontaal schalen moet uitvoeren. Horizontaal schalen betekent in feite het toevoegen van meer servers aan de omgeving. U kunt ook een reverse proxy op applicatielaagniveau gebruiken om meerdere applicaties tegelijk te bedienen via één domein en poort. HAProxy, Nginx, en Varnish zijn voorbeelden van software die reverse proxy load balancing mogelijk maken.

Voordelen:

• Mocht één server in de rij uitvallen, dan compenseren de andere servers de functie door de werklast te verdelen.
• Stelt u in staat om horizontaal te schalen om de capaciteit van de omgeving te vergroten of te verkleinen.
• Het beperkt ook clientverbindingen, wat bescherming biedt tegen DDOS-aanvallen.

Nadelen:

• Als de systeembronnen onvoldoende zijn, kan de load balancer de prestaties van uw applicatie beperken.
• Een juiste configuratie is vereist om goede prestaties te garanderen.
• Aanzienlijk complexer dan opstellingen met een enkele server of afzonderlijke servers.
• U moet rekening houden met factoren zoals SSL-terminatie en applicaties die sticky sessions nodig hebben.
• Het belangrijkste punt van zorg bij het gebruik van load balancers is dat het een single point of failure is. Dit betekent dat als de load balancer niet werkt, uw hele dienst uitvalt.

4. HTTP-accelerator of Caching Reverse Proxy

Dit is een opstelling die u kunt gebruiken om de snelheid te verhogen waarmee u inhoud levert aan een gebruiker van uw applicatie. Het maakt gebruik van verschillende technieken om deze tijd te verkorten. De belangrijkste is het cachen van het antwoord van de applicatieserver. De accelerator slaat de inhoud op in het geheugen wanneer een gebruiker deze voor de eerste keer opvraagt. Wanneer er in de toekomst soortgelijke verzoeken binnenkomen, levert het de inhoud snel zonder interactie met de applicatieserver. Zowel Nginx, Varnish als Squid zijn in staat tot HTTP-acceleratie.

Wanneer te gebruiken:

Begrijpelijkerwijs is deze opstelling het meest geschikt voor bestanden en inhoud die gebruikers zeer vaak opvragen. Het werkt ook erg goed voor dynamische webapplicaties met veel inhoud.

Voordelen:

• Caching en compressie verhogen de snelheid van de applicatie en de verwerking van verzoeken aanzienlijk.
• Het verminderen van de belasting van de CPU verbetert ook de prestaties van de site.
• U kunt dit ook gebruiken als een reverse proxy load balancer.

Nadelen:

• U moet het goed afstemmen om de beste prestaties eruit te halen.
• U kunt slechte prestaties ervaren als de cache-hit ratio laag is.

5. Primary-Replica Database-replicatie

Een primary-replica database-replicatieopstelling is doorgaans erg nuttig voor systemen die meer lees- dan schrijfbewerkingen uitvoeren. Contentmanagementsystemen kunnen bijvoorbeeld echt profiteren van een dergelijke architectuur. U hebt één primaire node en één of meer replicatienodes nodig voor replicatie. Het verdeelt de leesbewerkingen over alle nodes. De updates gaan alleen naar de primaire node.

Wanneer te gebruiken:

Zoals we al zeiden, helpt een op replicatie gebaseerde database-opstelling de leesprestaties van een systeem te verbeteren. U kunt het gebruiken voor applicaties zoals een CMS.

Voordelen:

• Het verbetert de leesprestaties van de database omdat het deze over de replica's verspreidt.
• Als u de primaire node alleen voor updates gebruikt, kunt u ook de schrijfprestaties verbeteren.

Nadelen:

• Elke applicatie die toegang probeert te krijgen tot de database, moet kunnen beslissen naar welke node updates en leesverzoeken moeten worden verzonden.
• Als de primaire replica uitvalt, stoppen de updates. U moet het probleem oplossen om updates weer mogelijk te maken.
• Er is geen failover-mechanisme om een eventuele uitval van de primaire node op te vangen.

Serveropstellingen in combinatie gebruiken

Gelukkig is het ook mogelijk om verschillende technieken te combineren om het gewenste resultaat te bereiken. Dit betekent dat u de applicatieservers kunt load balancen met de cachingservers in een enkele omgeving en de database kunt repliceren. Hierdoor kunt u profiteren van de functionaliteit van beide servers. Het maakt de installatie echter niet ingewikkelder of problematischer.

Voorbeeld:

We zullen proberen een dergelijke omgeving te begrijpen aan de hand van een voorbeeld:

In een dergelijke omgeving stuurt de load balancer statische verzoeken naar de cachingservers. Statische content omvat onder andere CSS, afbeeldingen en Javascript. In plaats daarvan stuurt het alle andere soorten contentverzoeken door naar de applicatieservers.

Stel dat een gebruiker statische content opvraagt uit de omgeving. Dit is wat er zou gebeuren:

• De load balancer bepaalt eerst of de content een cache-hit of cache-miss is. Cache-hit content is aanwezig in de cache, terwijl cache-miss content er niet is. Dit gebeurt door dit te controleren bij de cache-backend.
• In het geval van een cache-hit stuurt de load balancer de content naar de gebruiker.
• In het geval van een cache-miss stuurt de cacheserver het verzoek door naar de backend van de applicatie.
• De app-backend zoekt en verzendt de content uit de database.
• De cache-backend ontvangt de content van de load balancer. Het cachet deze content ook voordat het deze terugstuurt naar de load balancer.
• Deze laatste stuurt het antwoord vervolgens door naar de gebruiker.

Aan de andere kant is dit wat er gebeurt als de gebruiker dynamische content opvraagt:

• Het verzoek komt van de gebruiker binnen bij de load balancer.
• Dit verzoek komt binnen bij de app-backend.
• De app-backend zoekt de opgevraagde content en stuurt deze terug naar de load balancer.
• De gebruiker ontvangt de content.

Een van de belangrijkste voordelen van een dergelijke gecombineerde omgeving is dat deze betrouwbaarder is. Niet alleen dat, maar het heeft ook superieure prestaties. Er zijn echter nog steeds twee single points of failure: de load balancer en de primaire databaseserver.

Conclusie

U kunt elke serverconfiguratie afzonderlijk in uw omgeving gebruiken. Aan de andere kant kunt u er ook een paar met elkaar combineren om een gepersonaliseerde oplossing te creëren. Er is geen 'juist' antwoord. Het hangt allemaal af van de functionaliteit die u uit de architectuur wilt halen.

Het hebben van basiskennis over hoe elke serverconfiguratie werkt, helpt u bij het nemen van de beslissing voor uw eigen applicatie. Het beste is om klein en eenvoudig te beginnen. U kunt de complexiteit van uw configuratie blijven verhogen naarmate u meer ervaring opdoet.

Veel computerplezier!