Instant Domain Search ist schnell, weil es einen Index mehrerer Domain-Zonendateien im Arbeitsspeicher hält und auf schnellen Servern läuft. Jede Zonenabfrage wird in Mikrosekunden beantwortet. Der langsamste Teil der Domainsuche ist die Verbindung zwischen Client und Server. Das gilt besonders für Mobilfunknetze. Geschwindigkeit ist uns äußerst wichtig, und wir suchen ständig nach Wegen, diese Website noch schneller zu machen.
Wenn Sie erfahren möchten, wie Sie mit AWS Ihr eigenes CDN aufbauen, lesen Sie weiter. Wir zeigen, wie wir eines für Instant Domain Search aufgebaut haben. Ein CDN von Grund auf zu entwickeln war bis vor Kurzem schwierig. Neue Technologien machen es inzwischen für jeden einfach.
So bauen Sie ein CDN
Vor einigen Jahren begannen wir, mit JavaScript zu ermitteln, welcher Server Ihnen am nächsten liegt. Das verbesserte die Suchleistung deutlich, beschleunigte aber nicht das erste Laden der Seite. Vor Kurzem haben wir damit begonnen, alle Seiten standardmäßig über HTTPS auszuliefern. Das erhöht die Latenz beim ersten Seitenaufruf zusätzlich, weil zunächst eine HTTPS-Verbindung ausgehandelt werden muss, bevor der Browser weiß, wo er statische Ressourcen wie CSS und JavaScript herunterladen soll.
Ein Content Delivery Network (CDN) zum Hosten der Website kann die Verteilung von Änderungen und eigene Weiterleitungsregeln erschweren. Der Betrieb mit einem eigenen Sicherheitszertifikat kann außerdem teuer sein. Wir wollten auch HTTP/2 (früher SPDY) einführen. Das HTTP/2-Protokoll ist deutlich effizienter als herkömmliches HTTPS, da es eine sichere Verbindung mit weniger Netzwerk-Rundreisen aushandeln kann. Google hat gezeigt, dass HTTP/2 in Mobilfunknetzen 23 % schneller als HTTPS ist.
Die Vorteile eines CDN
Ein CDN speichert Kopien Ihrer Ressourcen in Rechenzentren weltweit zwischen. Diese heißen Edge-Server. Edge-Server speichern Inhalte normalerweise bei Bedarf. Das bedeutet: Das CDN holt Daten erst dann von Ihrem Server, dem Ursprungsserver, in einen Edge-Server, wenn ein Client in der Nähe sie anfordert. Bei einer Website mit vergleichsweise wenig Traffic wie dieser werden Ihre Daten vermutlich häufig aus dem Cache entfernt. Das kann etwas zusätzliche Latenz verursachen, wenn der Edge-Server des CDN aktuelle Daten vom Ursprungsserver abruft.
Amazon ergänzte seinen Dienst Route 53 im März 2012 um latenzbasiertes Routing. Damit können Sie Server in mehreren Amazon-Rechenzentren betreiben. Route 53 verbindet Nutzer per DNS mit dem nächstgelegenen Server. CloudFront verwendet ein ähnliches Verfahren, um Nutzer mit dem nächsten Edge-Knoten zu verbinden. Erstaunlich, oder? Deshalb ist es so sinnvoll, ein eigenes CDN zu betreiben.
Geschwindigkeitsvergleich
Über einen Zeitraum von 30 Tagen überwachten wir mit Pingdom die Latenz einer CloudFront-URL, die eine mit gzip komprimierte Version unserer Startseite über HTTPS auslieferte. Pingdom verwendet weltweit verteilte Server, um Verfügbarkeit zu überwachen und Latenzberichte zu erstellen. Im selben Zeitraum lieferten wir dieselbe Seite über HTTPS aus und ließen das latenzbasierte Routing von Route 53 die Last auf einen unserer Server in Virginia, Kalifornien, Singapur oder Irland verteilen. Insgesamt ist unser eigenes CDN etwa so schnell wie CloudFront:
| CloudFront | Eigenes CDN | |
|---|---|---|
| Insgesamt | 195ms | 193ms |
| Schnellster | 166ms | 175ms |
| Langsamster | 241ms | 234ms |
Obwohl es viel mehr CloudFront-Edge-Knoten als Server von Instant Domain Search gibt, können wir Server dennoch relativ nah an der Mehrheit unserer Nutzer platzieren. Route 53 leitet Traffic nur an Server weiter, die online sind. Seit dem Wechsel auf dieses System meldet Pingdom für unsere Startseite, statischen Inhalte und Suchoberfläche eine Verfügbarkeit von 100,00 %.
Wenn Sie Ihr eigenes CDN aufbauen, nehmen Sie sich Zeit, Ihre Werte wie hier zu vergleichen und zu verschiedenen Uhrzeiten an unterschiedlichen Tagen zu überwachen. So erhalten Sie ein klares Bild davon, wie gut Ihre CDN-Server arbeiten.
Weniger Komplexität = schnellere Ergebnisse
Indem wir alles über eine Domain ausliefern, entfallen DNS-Abfrage, TCP-Verbindung und TLS/SSL-Handshake mit dem CDN. Diese Netzwerkkommunikation erhöht die Latenz an einer entscheidenden Stelle des Nutzererlebnisses: beim ersten Laden der Seite. Beginnt ein Nutzer zu suchen, kommuniziert er weiterhin mit dem nächstgelegenen Server. Dadurch entfällt der zuvor eingesetzte JavaScript-Trick. Mit JSON-Streaming-Techniken haben wir die Verbindungsverarbeitung weiter optimiert und die Zahl der HTTPS-Verbindungen pro Anfrage reduziert.
Es ist erstaunlich, dass eine relativ kleine Website wie unsere Zugriff auf die globale Infrastruktur von AWS hat. Wir konnten ein eigenes CDN über die Kommandozeile aufbauen. Als diese Website 2005 startete, war das nur den größten Anbietern und zu hohen Kosten möglich.
Wie Sie sehen, sind nicht allzu viele Schritte nötig, um einen eigenen CDN-Server einzurichten. Hoffentlich nimmt Ihnen dieser Beitrag etwas die Scheu davor, falls Sie es noch nie versucht haben. Wenn Ihre CDN-Domain erst eingerichtet ist und läuft, werden Sie froh sein, es getan zu haben.