Criteos Service Mesh mit Consul und HAProxy Enterprise

Die Challenge

Wenn es um Technologie geht, ist Criteo einen Schritt voraus. Seine Ingenieure und Architekten nutzen ihr Know-How, um erstklassige Software auszuwählen, ihre Infrastruktur zu automatisieren, Containerplattformen aufzunehmen und eigennützige, benutzerfreundliche Systeme zu hosten. Die praktischen Gründe für diese Initiativen sind der Aufbau einer Infrastruktur, die den Datenverkehr von Criteo unterstützen kann (Millionen von Anfragen pro Sekunde), und die Kapazitätssteigerung der R&D-Abteilung, sodass sie schnell und mit möglichst wenig Reibung neue Ideen ausprobieren kann.

Dank einer auf Microservices basierten Architektur, haben Criteos Softwareentwickler enorme Skalierbarkeit erreicht. Durch die Steigerung der Node-Anzahl für jeden Service unabhängig, ermöglichten sie Optimierungen auf einer granularer Ebene. Sie hatten jedoch Probleme ihre Frontend-Web-Apps mit ihren Backend-Microservices zu verbinden. Anfangs verwendeten sie benutzerdefinierte Libraries, um Messages zwischen den Layers zu vermitteln, aber die Verwaltung einer solcher Architektur wurde immer schwieriger.

Schließlich entshieden sie sich HAProxy Enterprise Load Balancers zwischen ihren Apps und Backend-Services einzufügen, aber das steigerte die Latenzzeit. Criteos Werbeplattform hängt kritisch von der Geschwindigkeit ab – jede Millisekunde zählt. Also, mussten sie einen neuen Weg finden, um die Latenzzeit auf ein Minimum zu beschränken. Sie suchten nach einer Möglichkeit, ihre Apps und Services nahtloser miteinander zu verbinden.

Die Ziele

Criteos Ingenieure kammen zum Entschluss, dass die Implementierung eines Service Meshes die bestmögliche Lösung ist. Ein Service Mesh platziert einen Proxy neben jeden Microservice. Bei Criteo bedeutete das, dass diese Proxies ihre vorhandenen Client-Side Libraries ersetzen werden. Anstatt den Datenverkehr zu einem extra Layer von Load Balancers zu routen, was einen zusätzlichen Netwzwerk-Hop bedeutet, können die Apps direkt mit einem Microservice kommunizieren. Somit werden die Messages durch einen lokalen, sidecar Proxy weitergeleitet.

Sie wurden HashiCorp Consul benuzten, um diese Konfiguration von Proxies zu verwalten. Consul wurde alle Routing-Regeln beinhalten und diese zu jedem einzigen Node übertragen. Wann immer ein neues Microservice hinzugefügt wird, benachrichtigt Consul die ganze Proxy-Flotte. Die Proxies synchronisieren sich dann mit den neuen Informationen. Der Problem lag aber in dem von Consul benutzten Proxy – Envoy Proxy. Er war nicht genug für Criteos Anforderungen.

Die Lösung

Criteo hat schon früher seine F5 Load Balancers mit HAProxy Enterprise ersetzt. HAProxy Enterprise kann Millionen von Anfragen pro Sekunde bearbeiten, bietet erstklassige Logs und Metriken, unterstüzt TLS-Offloading, Durchsatzbegrenzung und viele andere Features. Alle diese Features machen HAProxy zu einem perfekten Sidecar Proxy-Kandidat, aber leider war er zu dieser Zeit nich als Option mit Consul verfügbar. So haben sich Consuls Ingenieure darauf entschieden die Integrierung zwischen Consul und HAProxy Enterprise selbst aufzubauen.

Criteos Ingenieure wählten HAProxy Enterprise aus mehreren Grunden aus: es basiert sich auf der Open-Source-Version von HAProxy und kommt mit technischen Support von HAProxy Experten. Benutzerdefinierter Code, geschrieben vom Consul Team, ermöglichte HAProxy Enterprise im Consul zuvor erfassende Routing-Informationen automatisch einzusetzen. HAProxys flexible Konfigurationssprache erleichtere Alles, aber es war die HAProxy Data Plane API die dies noch mehr vereinfachte. Die HAProxy Data Plane API ermöglicht Ihnen HAProxy Enterprise durch HTTP-Commands programmatisch zu konfigurieren.

Eine weitere Schwierigkeit wurde überwunden: wenn einer der Microservices einen anderen Microservice kontaktiert, müssen die Load Balancers die sich zwischen den Microservices befinden entscheiden, ob sie diese Kommunikation erlauben. Schließlich sollten einige der Microservices nicht in der Lage sein sich mit einigen der anderen Microsevices zu verbinden, hauptsächlich aus Sicherheitsgründen. Criteo benutzte das einzigartige Stream Processing Offload Protocol (SPOP) von HAProxy Enterprise, um dieses Problem zu lösen. Das SPOP führt einen Programm neben HAProxy Enterprise aus und checkt ob diese Verbindung erlaubt werden soll. Das SPOP ermöglicht live Datenverkehr zu einen externen Programm weiterzuleiten, wo der Datenverkehr in Echtzeit untersucht und prozessiert wird, während er durch den Load Balancer fließt.

Nach Abschluss des Projekts wurde HAProxy Enterprise zur zentralen Komponente des von Consul betriebenen Service-Meshes von Criteo. HAProxy Enterprise routet den Datenverkehr für rund 270.000 Service Nodes. Diese Vereinheitlichung gab ihnen die Features, die sie benötigten, einschließlich TLS-Encryption zwischen Services und Durchsatzbegrenzung, während die Latenzzeit extrem niedrig blieb. Criteo hat seitdem die Implementierung als Open-Source-Lösung bereitgestellt. Mit Zustimmung von Criteo ist nun HAProxy Technologies für die Verwaltung dieser Integrierung verantwortlich.

Die Resultate

Dank seinem Service Mesh, der HAProxy Enterprise als Client-Side Load Balancer benutzt. hat Criteo die Leistung und Sicherheit zwischen seinen Mircoservices gesteigert. Sein ganzer Datenverkehr hat nun TLS-Encryption, Hochleistungsfähigkeit und andere HAProxy Features, wie Durchsatzbegrenzung und ausführliche Observability. Heute fließen bei Criteo Millionen von Anfragen pro Sekunde über HAProxy Enterprise, sodass sie ihren Weg zu einer einfachen eigennützigen Infrastruktur fortsetzen können.

Wollen Sie mehr HAProxy Use-Cases entdecken? Besuchen Sie unseren Success Story Page?