Instant Domain Search est rapide parce qu’il conserve en mémoire un index de plusieurs fichiers de zone de noms de domaine et s’exécute sur des serveurs rapides. Chaque requête de zone reçoit une réponse en microsecondes. La partie la plus lente de la recherche de domaines est la liaison entre le client et le serveur, surtout sur les réseaux mobiles. Nous sommes obsédés par la vitesse et cherchons toujours des moyens de rendre ce site encore plus rapide.
Si vous voulez apprendre à créer votre propre CDN avec AWS, poursuivez votre lecture pour voir comment nous avons structuré celui d’Instant Domain Search. Construire un CDN à partir de zéro était difficile il y a peu, mais les nouvelles technologies ont simplifié cette tâche pour tous.
Comment créer un CDN
Il y a quelques années, nous avons commencé à utiliser JavaScript pour déterminer quel serveur se trouvait le plus près de vous. Cette technique a beaucoup amélioré les performances de recherche, mais elle n’accélère pas le chargement initial de la page. Nous avons récemment commencé à servir toutes les pages en HTTPS par défaut. Cela ajoute encore de la latence au chargement initial, car nous devons négocier une connexion HTTPS avant que le navigateur sache où télécharger des ressources statiques comme CSS et JavaScript.
Héberger le site sur un réseau de diffusion de contenu (CDN) peut compliquer la propagation des changements, l’utilisation de règles de redirection personnalisées et l’hébergement avec son propre certificat sécurisé, tout en coûtant cher. Nous voulions également déployer HTTP/2, anciennement SPDY. Le protocole HTTP/2 est beaucoup plus efficace que HTTPS traditionnel, car il peut négocier une connexion sécurisée avec moins d’allers-retours réseau. Google a montré que HTTP/2 est 23 % plus rapide sur les réseaux mobiles que HTTPS.
Les avantages d’un CDN
Un CDN met en cache des copies de vos ressources dans des centres de données du monde entier. Ce sont les serveurs périphériques. Ils mettent généralement le contenu en cache à la demande : le CDN récupère les données à stocker sur un serveur périphérique depuis votre serveur, le serveur d’origine, uniquement lorsqu’un client proche les demande. Si votre site reçoit relativement peu de trafic comme le nôtre, vos données risquent d’être souvent évincées du cache. Cela peut ajouter un peu de latence lorsque le serveur périphérique du CDN récupère des données récentes auprès de votre serveur d’origine.
Amazon Route 53 a ajouté le routage fondé sur la latence en mars 2012. Vous pouvez ainsi héberger des serveurs dans plusieurs centres de données Amazon, et Route 53 utilise DNS pour connecter les utilisateurs au serveur le plus proche. CloudFront fait de même pour connecter les utilisateurs au nœud périphérique le plus proche. C’est la raison pour laquelle héberger son propre CDN est si pertinent.
Comparaison de vitesse
Pendant 30 jours, nous avons utilisé Pingdom pour surveiller la latence d’une URL CloudFront qui servait une version gzipée de notre page d’accueil en HTTPS. Pingdom utilise des serveurs répartis dans le monde entier pour surveiller la disponibilité et produire des rapports de latence. Au cours de la même période, nous avons servi la page identique en HTTPS, en laissant le routage fondé sur la latence de Route 53 diriger la charge vers l’un de nos serveurs en Virginie, en Californie, à Singapour ou en Irlande. Globalement, notre CDN personnalisé est à peu près aussi rapide que CloudFront :
| CloudFront | CDN personnalisé | |
|---|---|---|
| Globalement | 195ms | 193ms |
| Le plus rapide | 166ms | 175ms |
| Le plus lent | 241ms | 234ms |
Même si CloudFront possède bien plus de nœuds périphériques que Instant Domain Search n’a de serveurs, nous pouvons tout de même placer des serveurs relativement près de la majorité de nos utilisateurs. Route 53 n’envoie le trafic que vers des serveurs en ligne. Depuis le passage à ce système, Pingdom indique une disponibilité de 100,00 % pour notre page d’accueil, notre contenu statique et notre interface de recherche.
Lorsque vous créez votre propre réseau CDN, prenez le temps de comparer vos chiffres comme nous l’avons fait ici et de les surveiller à différents moments, sur plusieurs jours. Vous verrez ainsi clairement comment vos serveurs CDN fonctionnent.
Moins de complexité = des résultats plus rapides
En servant tout depuis un seul domaine, nous éliminons la requête DNS, la connexion TCP et la négociation TLS/SSL réalisées avec le CDN. Ces échanges réseau ajoutent de la latence à une partie essentielle de l’expérience utilisateur : le premier chargement de la page. Lorsqu’un utilisateur commence une recherche, il communique encore avec le serveur le plus proche. Cela élimine le besoin du contournement JavaScript que nous utilisions auparavant. Nous avons encore optimisé la gestion des connexions avec des techniques de diffusion JSON afin de réduire le nombre de connexions HTTPS par requête.
Il est remarquable qu’un site relativement petit comme le nôtre ait accès à l’infrastructure mondiale fournie par AWS. Nous avons pu créer un CDN personnalisé depuis la ligne de commande, ce qui n’était accessible qu’aux plus grands fournisseurs et à grands frais lorsque ce site a été lancé en 2005.
Comme vous pouvez le voir, il ne faut pas beaucoup d’étapes pour créer votre propre serveur CDN. Nous espérons que cet article rendra le sujet un peu moins intimidant si vous ne l’avez jamais essayé. Une fois votre domaine CDN configuré et opérationnel, vous serez heureux de l’avoir fait.