Upgrade auf HAProxy in einer Load-Balancer-as-a-Service-Plattform mit Booking.com
Mehr als 28 Millionen Inserate.
Verfügbar in 43 Sprachen.
Milliarden von Anfragen pro Tag.
Über Booking.com
Booking.com ist seit mehr als 25 Jahren führend in der digitalen Reisebranche und ist mit dem Internet aufgewachsen. Von einem kleinen niederländischen Startup, das 1996 gegründet wurde, hat sich Booking.com zu einem Online-Giganten entwickelt, der jedes Jahr Millionen von Reisenden nahtlos mit Unterkünften, Flügen und Mietobjekten zusammenbringt. Als einer der größten Online-Reisemarktplätze der Welt verbindet Booking.com sowohl etablierte Marken als auch Kleinunternehmer mit einem globalen Publikum und bietet gleichzeitig Kundenservice rund um die Uhr.
Die Herausforderung
Wie alle Vertreter des digitalen Zeitalters litt auch die Netzwerkorganisation von Booking.com lange Zeit unter einer veralteten Konfiguration, die noch aus den Anfängen des Onlinebetriebs stammte. Als Marcin Deranek 2008 die Leitung übernahm, bestand die Infrastruktur für das Load Balancing aus zwei Linux-Servern mit IP Virtual Server, die in einer Aktiv/Standby-Konfiguration für die Ausfallsicherung betrieben wurden. Es traten jedoch Probleme mit dem ARP-Caching auf, die das Failover-Setup vereitelten, sowie andere Probleme mit der Anpassbarkeit, die typischerweise mit dem Load Balancing auf dieser Ebene verbunden sind.
Dies ermutigte Marcin schon früh, eine F5-basierte Layer-7-Load-Balancing-Lösung auszuprobieren. Das anfängliche System bestand aus zwei lokalen F5 BIG-IP-Traffic-Managern, die Optionen zum Ändern von Nutzlasten oder zum Einfügen oder Entfernen von Headern boten, die zuvor nicht möglich waren. Die F5-Load-Balancer, bei denen es sich um physische Server handelte, die sich nicht automatisiert konfigurieren ließen, erforderten jedoch manuelle Schritte zum Aktualisieren und Anpassen der Einstellungen, was selbst nach der Entwicklung einer Reihe von Skripten für diese Aufgabe und der Implementierung von Puppet zur Erleichterung der Arbeit seinen Tribut zu fordern begann. Dieses System war außerdem nur vertikal skalierbar, und als der Kundenstamm von Booking.com wuchs, entstand eine unübersichtliche Struktur aus verschiedenen Generationen von F5-Hardware. So begann die Reise zu einem softwarebasierten Ansatz für das Load Balancing.
Marcin auf der HAProxyConf 2019
Die Ziele
Die ursprünglichen Ziele des Booking.com-Teams waren die Beseitigung dieser Redundanz im Zusammenhang mit der zyklischen Hardware sowie die Überschreitung der Begrenzung für die Sitzungsanzahl, die mit ihrem F5-Setup verbunden waren. Dies führte dazu, die F5-BIG-IP-Server durch ein internes Load-Balancer-as-a-Service-System zu ersetzen, das softwarebasierte HAProxy Enterprise-Load-Balancer und Equal-Cost-Multi-Path-Routing nutzt. Diese Strategie ermöglichte das Routing von Netzwerkpaketen über mehrere Pfade mit gleichen Kosten, die durch eine erste Schicht von Fabric-Layer-Switches und Top-of-Rack-Switches auf Layer 3 ermöglicht wurden, die Pakete an eine Schicht von HAProxy Enterprise-Load-Balancern weiterleiteten, die den Traffic schließlich an die Anwendungsserver verteilten – eine Strategie, die wiederum ein Per-Flow Load Balancing bedeutete, das sicherstellte, dass ein einzelner Paketfluss aufgrund der auf der ersten Schicht gerundeten Hash-Algorithmen während seiner gesamten Lebensdauer auf demselben Pfad blieb, der diesen dann an die darunter liegenden HAProxy-Load-Balancer-Paare weiterleitete.
Das Team wollte außerdem sicherstellen, dass der Netzwerk-Traffic auf der Grundlage von Standort- und Latenzmetriken an die richtigen Ziele weitergeleitet wird. Dies bedeutete, dass das neue softwarebasierte HAProxy Enterprise-Load-Balancing-System in Kombination mit Anycast implementiert wurde, einem Verfahren, bei dem der Absender-Traffic auf der Grundlage der idealen Netzwerktopologie weitergeleitet wird. Die Anycast-Theorie bedeutete die Zuweisung von Pfaden auf der Grundlage der niedrigsten Kosten, der Entfernung, der Hops oder der gemessenen Latenzzeit, wobei der Standort bevorzugt wurde.
Um dieses neue System so zu verwalten, dass es die Milliarden von Anfragen, die Booking.com pro Tag erhielt, bewältigen konnte, leitete Marcin auch die Entwicklung einer eigenen API, die treffend „Balancer“ genannt wurde.
Die Lösung
Diese maßgeschneiderte Software sollte zur Verwaltung der gesamten Load-Balancing-Plattform verwendet werden. Die Balancer-API basiert auf verschiedenen Clustern für unterschiedliche Umgebungen und bildet das Zentrum des Verteilungsnetzes. Sie speichert die Konfiguration als Objekte mit Attributen sowie die Beziehungen zwischen ihnen. Dies bedeutete, dass eine kontextbezogene Geschäftslogik die API nutzen konnte, um Server automatisch Backend-Pools zuzuweisen und ein intelligentes Traffic-Routing zu nutzen, um Pakete auf der Grundlage der festgelegten Anforderungen an eine gleichmäßige Verteilung des Traffic und die Einhaltung von Sitzungszonen weiterzuleiten.
Darüber hinaus automatisierte die API die Bereitstellung von Servern anhand von Attributen, die für jeden vorhandenen Pool erstellt wurden. Außerdem konnte jede Instanz von HAProxy Enterprise mit einem Balancer-Agenten genauer konfiguriert werden, was einen Dialog zwischen der API, dem Top-of-Rack-Switch und den BIRD Routing Daemons ermöglichte, die von einem Anycast Healthchecker konfiguriert wurden.
Die Systemadministratoren nutzten auch die unübertroffene Beobachtbarkeit von HAProxy, indem sie Daemons an den Balancer anschlossen, die ihrerseits die erfassten Daten verarbeiteten. Der Daemon überträgt diese Statistiken regelmäßig über den Stats-Socket an Graphite, wobei die Zugriffs- und Fehlerprotokolle von Rsyslog erfasst und an einen Elasticsearch-Cluster weitergeleitet werden, sodass eine Fülle von Informationen für die benutzerdefinierte Benutzeroberfläche zur Verfügung steht.
Die Resultate
Die Vorteile dieses softwarebasierten Ansatzes für das Load Balancing bedeuteten für das Team eine noch nie dagewesene Transparenz über die Benutzeroberfläche der Balancer-API. Es wurde eine Reihe von grafischen Anzeigen erstellt, die die von HAProxy Enterprise bereitgestellten Daten aufbereiteten, sodass auch Mitarbeiter, die mit dem Load Balancing vielleicht weniger vertraut waren, den Dienst nutzen konnten, indem sie die Metriken sowie die Verbindung zwischen den einzelnen Objekten im System visualisierten.
Die Flexibilität von HAProxy Enterprise, das in einem Load-Balancer-as-a-Service-Netzwerk eingesetzt werden kann, bedeutete, dass das Team in einer Weise skalieren, visualisieren und routen konnte, wie es zuvor nicht möglich war. Das intelligente Routing bietet auch Schutz gegen mehrere Ausfallszenarien, die alle mit der Leitungsrate angegangen werden können, anstatt wie bei den früheren F5- oder Linux-IPVS-Systemen die Kabel und Schrauben herauszuziehen.
Booking.com hat auch den Dialog zwischen HAProxy Technologies und seiner Community genutzt, als die verschiedenen Iterationen von HAProxy Enterprise verfügbar wurden, und den Wunsch des Unternehmens nach TCP Fast Open im Backend und seine Entwicklung in Richtung HTTP/3 kommuniziert.
Das bietet Ihnen HAProxy Enterprise
Während Booking.com eine benutzerdefinierte Lösung auf der Basis von HAProxy Enterprise implementiert hat, können Sie viele der gleichen Vorteile mit der HAProxy Fusion Control Plane nutzen. Die HAProxy Fusion Control Plane wird mit einer voll funktionsfähigen API, Unterstützung für intelligentes Routing auf der Grundlage des Serverzustands, einer umfangreichen Benutzeroberfläche und vielem mehr geliefert. Nehmen Sie Kontakt zu uns auf, um mehr zu erfahren.
Möchten Sie mehr über die Anwendungsfälle von HAProxy erfahren? Lesen Sie unsere Erfolgsgeschichten.