Instant Domain Search is snel omdat het een index van meerdere domeinzonebestanden in het geheugen houdt en op snelle servers draait. Elke zonevraag wordt binnen microseconden beantwoord. Het langzaamste onderdeel van het zoeken naar domeinen is de verbinding tussen de client en de server. Dat geldt vooral voor mobiele netwerken. We zijn geobsedeerd door snelheid en zoeken altijd naar manieren om deze website nog sneller te maken.
Wil je leren hoe je met AWS je eigen CDN bouwt? Lees dan verder om te zien hoe we er een voor Instant Domain Search hebben ingericht. Een CDN vanaf nul bouwen was tot voor kort moeilijk, maar nieuwe technologieën hebben het voor iedereen eenvoudig gemaakt.
Zo maak je een CDN
Een paar jaar geleden begonnen we JavaScript te gebruiken om te bepalen welke server het dichtst bij je stond. Die techniek verbeterde de zoekprestaties sterk, maar maakte de eerste paginalading niet sneller. Onlangs zijn we alle pagina’s standaard via HTTPS gaan aanbieden. Dat vertraagt de eerste paginalading nog meer, omdat we een HTTPS-verbinding moeten opzetten voordat de browser weet waar hij statische bestanden zoals CSS en JavaScript kan downloaden.
Een content delivery network (CDN) gebruiken om de website te hosten kan het lastig maken om wijzigingen door te voeren en eigen omleidingsregels te gebruiken. Hosting met je eigen beveiligingscertificaat kan bovendien duur zijn. We wilden ook HTTP/2 uitrollen, voorheen SPDY. Het HTTP/2-protocol is veel efficiënter dan traditionele HTTPS, omdat het met minder netwerkuitwisselingen een beveiligde verbinding kan opzetten. Google heeft aangetoond dat HTTP/2 op mobiele netwerken 23% sneller is dan HTTPS.
De voordelen van een CDN
Een CDN slaat kopieën van je bestanden op in caches in datacenters over de hele wereld. Dat zijn de edgeservers. Die cachen inhoud meestal op aanvraag. Het CDN haalt dus pas gegevens van jouw server, de originserver, op om ze op een edgeserver op te slaan wanneer een client in de buurt erom vraagt. Als je website relatief weinig verkeer heeft, zoals deze, worden je gegevens waarschijnlijk vaak uit de cache verwijderd. Dat kan extra vertraging veroorzaken wanneer de edgeserver van het CDN nieuwe gegevens van je originserver ophaalt.
Amazon voegde in maart 2012 routering op basis van latentie toe aan Route 53. Daardoor kun je servers in meerdere Amazon-datacenters hosten en gebruikt Route 53 DNS om gebruikers met de dichtstbijzijnde server te verbinden. CloudFront doet iets vergelijkbaars om gebruikers met het dichtstbijzijnde edgeknooppunt te verbinden. Geweldig, toch? Daarom is het zo logisch om je eigen CDN te hosten.
Snelheidsvergelijking
Gedurende 30 dagen gebruikten we Pingdom om de latentie te meten naar een CloudFront-URL die een met gzip gecomprimeerde versie van onze homepage via HTTPS aanbood. Pingdom gebruikt servers over de hele wereld om de beschikbaarheid te bewaken en latentierapporten te maken. In dezelfde periode boden we de identieke pagina via HTTPS aan. De latentiegestuurde routering van Route 53 stuurde het verkeer naar een van onze servers in Virginia, Californië, Singapore of Ierland. Over het geheel is ons eigen CDN ongeveer even snel als CloudFront:
| CloudFront | Eigen CDN | |
|---|---|---|
| Gemiddeld | 195ms | 193ms |
| Snelste | 166ms | 175ms |
| Langzaamste | 241ms | 234ms |
Hoewel er veel meer CloudFront-edgeknooppunten zijn dan Instant Domain Search-servers, kunnen we onze servers toch relatief dicht bij de meeste gebruikers plaatsen. Route 53 stuurt alleen verkeer naar servers die online zijn. Sinds we dit systeem gebruiken, rapporteert Pingdom een beschikbaarheid van 100,00% voor onze homepage, statische inhoud en zoekinterface.
Wanneer je je eigen CDN-netwerk bouwt, neem dan de tijd om je cijfers te vergelijken zoals wij hier hebben gedaan. Meet ze op verschillende momenten en dagen. Zo krijg je een duidelijk beeld van hoe goed je CDN-servers werken.
Minder complexiteit = snellere resultaten
Door alles vanaf één domein aan te bieden, kunnen we de DNS-vraag, TCP-verbinding en TLS/SSL-handshake met het CDN weglaten. Dat netwerkverkeer voegt vertraging toe aan een cruciaal onderdeel van de gebruikerservaring: de eerste paginalading. Wanneer een gebruiker begint te zoeken, communiceert die nog steeds met de dichtstbijzijnde server. De JavaScript-truc die we eerder gebruikten, is daardoor niet meer nodig. We optimaliseerden ons verbindingsbeheer verder met JSON-streamingtechnieken om het aantal HTTPS-verbindingen per zoekopdracht te verminderen.
Het is bijzonder dat een relatief kleine website zoals de onze toegang heeft tot de wereldwijde infrastructuur van AWS. We konden via de opdrachtregel een eigen CDN bouwen. Toen deze website in 2005 werd gelanceerd, was dat alleen tegen hoge kosten voor de grootste aanbieders beschikbaar.
Zoals je ziet, zijn er niet veel stappen nodig om je eigen CDN-server te maken. Hopelijk maakt dit artikel het minder spannend om eraan te beginnen als je het nog nooit hebt geprobeerd. Zodra je CDN-domein eenmaal draait, zul je blij zijn dat je het hebt gedaan.