Agoda, einer der größten Online-Reiseanbieter Asiens, hat einen eigenen Reverse Proxy in Rust entwickelt – und zeigt damit, wie moderne Infrastrukturteams das Tail-Latency-Problem in hochfrequentierten Microservice-Umgebungen systematisch angehen können.
Agoda entwickelt Rust-basierten Reverse Proxy für latenzoptimiertes Load Balancing
Ausgangsproblem: Bestehende Lösungen stoßen an Grenzen
Agoda betreibt eine Plattform, die täglich Millionen von Suchanfragen und Buchungstransaktionen verarbeitet. Herkömmliche Reverse-Proxy-Lösungen wie NGINX oder HAProxy bieten zwar ausgereifte Feature-Sets, stoßen jedoch bei sehr granularer Latenzkontrolle und individuellen Routing-Anforderungen an Grenzen.
Das Tail-Latency-Problem – überdurchschnittlich lange Antwortzeiten im 99. oder 99,9. Perzentil – stellte die Engineering-Teams vor Herausforderungen, die mit Standardkonfigurationen kaum lösbar waren.
Rust als technische Grundlage
Die Entscheidung für Rust als Implementierungssprache folgt einer Abwägung, die in der Backend-Infrastruktur zunehmend anzutreffen ist:
- C-ähnliche Performance ohne Garbage Collector sorgt für vorhersehbares Latenzverhalten
- GC-Pausen, wie sie in JVM-basierten Systemen oder Go unter Last auftreten können, entfallen konstruktionsbedingt
- Das Ownership-Modell verhindert ganze Klassen von Speicherfehlern, die in C oder C++ zu Sicherheitslücken führen
Das Agoda-Team setzte auf das asynchrone Rust-Ökosystem – konkret die Tokio-Runtime – um nicht-blockierende I/O-Operationen effizient abzuwickeln. Dieser Ansatz erlaubt es, eine hohe Anzahl gleichzeitiger Verbindungen mit vergleichsweise geringem Ressourcenverbrauch zu verwalten.
Architektur und Load-Balancing-Strategien
Der entwickelte Proxy unterstützt verschiedene Load-Balancing-Algorithmen, die dynamisch an den Zustand der Backend-Dienste angepasst werden können. Besonderes Gewicht wurde auf zwei Kernmechanismen gelegt:
- Health Checking: Fehlerhafte oder überlastete Backend-Instanzen werden frühzeitig aus der Rotation genommen
- Circuit Breaker: Anfragen werden nicht auf bereits degradierte Services weitergeleitet – was direkt zur Reduktion von Tail Latencies beiträgt
Ein weiterer zentraler Aspekt ist die Observability: Der Proxy exponiert detaillierte Metriken, die eine feingranulare Analyse des Routing-Verhaltens und der Latenzverteilung erlauben – eine Voraussetzung für den produktiven Einsatz in komplexen Microservice-Umgebungen.
Eigenentwicklung versus Standardlösung
Die Entscheidung, einen Proxy selbst zu entwickeln anstatt auf Envoy oder ähnliche Cloud-native Lösungen zu setzen, ist nicht trivial.
Agoda begründet den Schritt mit dem Bedarf an spezifischen Routing-Logiken und der direkten Kontrolle über den gesamten Request-Lifecycle.
Envoy bietet zwar ein umfangreiches Erweiterungsmodell über WebAssembly-Filter, jedoch bringt jede Abstraktionsschicht eigene Latenzbeiträge mit sich – ein Kompromiss, den Agoda bei seinen strengen SLAs nicht eingehen wollte.
Einordnung für deutsche Unternehmen
Für Technologieunternehmen und Infrastrukturverantwortliche in Deutschland liefert das Agoda-Projekt mehrere relevante Hinweise:
- Rust ist produktionsreif – das Ökosystem hat inzwischen die nötige Reife für netzwerkkritische Infrastrukturkomponenten erreicht
- Eigenentwicklungen sind kein Selbstzweck – sie lohnen sich nur bei sehr spezifischen Anforderungen, die Standardlösungen strukturell nicht erfüllen können
- Für die meisten Mittelständler bleiben verwaltete Lösungen wie AWS ALB, Cloudflare oder Envoy die pragmatischere Wahl
Wer jedoch intern skalierbare Plattformen mit strengen Latenz-SLAs betreibt, sollte Rust als ernstzunehmende Option in der Infrastruktur-Toolchain evaluieren.
Quelle: InfoQ
