So hat SNCF Connect mit HAProxy ein eigenes CDN entwickelt
Über SNCF Connect
SNCF Connect ist der Online-Marktplatz der französischen Eisenbahn und bietet Fahrkarten für alle 15.000 Züge, die täglich verkehren. Nach 20 Jahren Wachstum ist SNCF Connect heute der größte Online-Anbieter des Landes. Mit bis zu 50 verkauften Fahrkarten pro Sekunde und etwa sechzig Millionen Besuchern pro Monat muss SNCF Connect Inhalte mit hoher Geschwindigkeit für eine enorme Vielfalt von Geräten bereitstellen.
Resultatsüberblick
Die Herausforderung
Vor mehr als einem Jahrzehnt, als die Website noch unter dem alten Namen Oui.sncf betrieben wurde, nutzte sie ein dreistufiges System mit einem Apache-Webserver, einem Weblogic-Anwendungsserver und Oracle-Datenbanken. Angesichts der mangelnden Beobachtbarkeit dieser Infrastruktur nutzte das Team die Community-Version von HAProxy, um die Fehlerstatistiken zu überwachen, bevor es einige Jahre später auf die unterstützte HAProxy Enterprise-Software für seine Webanwendungen umstieg.
Im Jahr 2014 begannen die Ingenieure Antonin Mellier und Nicolas Besin angesichts der steigenden Kosten ihres Standard-Content-Delivery-Network-Anbieters Akamai, ihre Optionen zu überdenken. Der wachsende Bandbreitenbedarf machte die Preise unerschwinglich, und sie erkannten, dass viele der optionalen Funktionen, für die sie bezahlten, wie Echtzeit-Protokollanalyse und SSL-Zertifikate, kostenlos in eine benutzerdefinierte CDN-Lösung implementiert werden könnten.
Das Team beschloss daher, ein eigenes Content Delivery Network aufzubauen, dessen Herzstück HAProxy Enterprise ist.
Die Ziele
Das Hauptziel von Nicolas und Antonin bei der Umstellung auf ein benutzerdefiniertes CDN bestand darin, die Latenzvorteile eines Systems von Cache-Servern in ihrem Netzwerk beizubehalten und gleichzeitig Dritte aus der Struktur zu eliminieren. Durch die Beantwortung von Endbenutzeranfragen am Ursprungsort minimieren Content Delivery Networks die Verzögerung beim Laden von Webseiteninhalten und bieten gleichzeitig Schutz vor hohen Traffic-Spitzen und DDoS-Angriffen. In Anbetracht der geringeren Bandbreitenkosten ist dies auch deutlich preiswerter als herkömmliches Hosting.
Das Team benötigte auch ein unkonventionelles DNS-Produkt für sein CDN. Nach der Wahl ihrer Bare-Metal-CDN-Hosts entschieden sich Nicolas und Antonin für GeoDNS, das ihnen die Möglichkeit bot, IPs auf der Grundlage des Standorts der Kunden zuzuweisen und zusätzlich eine gewichtete Umverteilung für unterschiedliche Lasten auf jedem der Edge-Server vorzunehmen. Sie fügten außerdem mit Dyn einen separaten, verwalteten DNS-Anbieter hinzu, um ihre globale Präsenz zu erhöhen. Diese Lösung mit mehreren DNS-Anbietern bot eine Ausfallsicherung für den Notfall und die Möglichkeit, den Traffic zwischen den beiden Lösungen zu verteilen.
Die Lösung
Nachdem die Infrastruktur nun vorhanden war, implementierte SNCF Connect ihre HAProxy Enterprise-Load Balancer am Rande ihres CDN mit Varnish als Caching-Lösung. Mit der HAProxy Enterprise-Instanz am Rande des CDN erhielten Nicolas und Antonin einen standardisierten Überblick über ihre Inputs und Outputs, während die Daten durch das CDN geroutet wurden, was die Bestimmung von Fehler- und Cache-Verhältnissen sowie die Lokalisierung des Ursprungs potenzieller Probleme innerhalb oder außerhalb ihres CDN-Netzwerks erleichterte.
Um die Konfigurationsdateien zu verwalten, entwickelte das Team eine eigene Anwendung, die als Konfigurationsmanagement-Datenbank (Configuration Management Database, CMDB) fungiert. Für jeden Standort oder jede Anwendung, die das Netzwerk nutzt, werden in der CMDB Parameter für Funktionen wie Caching-Regeln, zu verwendende IP-Adressen und Ports sowie die Aktivierung von HTTP/2 oder IPv6 gespeichert. Diese Dateien sollten in Ruby generiert und anschließend von Ansible bereitgestellt werden.
Das Backend des CDN von SNCF Connect wurde dann über die HAProxy Enterprise-Instanzen an eines der beiden Rechenzentren geroutet, die von den Load Balancern jeweils als Zielserver behandelt werden. Für jede Anwendung wird ein vorher festgelegter Prozentsatz des Traffic an einen der beiden Zielserver weitergeleitet, wobei Cookies für die Sitzungsaufrechterhaltung verwendet werden, wenn die Anwendung nicht zustandslos ist. In bestimmten Fällen werden auch Zugriffskontrolllisten verwendet, insbesondere beim Abrufen von Medien von einem dedizierten Server oder den Teilen der Website, die in der öffentlichen Cloud auf AWS gehostet werden.
Die Resultate
Das Team von SNCF Connect profitiert auch von der unübertroffenen Beobachtbarkeit ihrer HAProxy Enterprise-Load-Balancer. Durch den Einsatz von Prometheus zur Erfassung von Kennzahlen über die verschiedenen Komponenten hinweg können sie die Daten in ihren Promviz- und Grafana-Visualisierern anzeigen und analysieren. Eine weitere HAProxy-Innovation, die sie nutzen, sind Stick-Tabellen, mit denen sie das Vorhandensein von abnormalem IP-Verhalten in ihrem Netzwerk feststellen können.
Das Endergebnis von Nicolas und Antonins Umstellung auf ein selbst betriebenes CDN war eine Senkung ihrer Betriebskosten um zwei Drittel im Vergleich zu ihrem vorherigen kostenpflichtigen Modell. Und das trotz einer Steigerung der Bandbreite um 80 % in den Jahren seit der Einführung. Der Content-Cache bedeutet auch, dass nur 10 % der Anfragen ihre Ursprungsserver erreichen müssen, was für ihre Kunden ein besseres Website-Erlebnis und eine geringere Belastung des internen Netzwerks bedeutet.
Das bietet Ihnen HAProxy Enterprise
Ganz gleich, ob Sie eine hervorragende Beobachtbarkeit, Schutz vor webbasierten Bedrohungen oder einfach einen Load Balancer benötigen, der sich in eine benutzerdefinierte Plattform integrieren lässt – HAProxy Enterprise hat viel zu bieten. Während das Team von SNCF Connect sein eigenes CDN entwickelt hat, können Sie mit HAProxy Edge, dem CDN, das auf der HAProxy-Technologie basiert, Ihre eigenen Anwendungen in großem Maßstab bereitstellen.
Möchten Sie mehr über die Anwendungsfälle von HAProxy erfahren? Lesen Sie unsere Erfolgsgeschichten.