Der Redis-Proxy wird zur Schlüsselkomponente für das Cache-Management bei steigender Last und Komplexität. Lassen Sie uns untersuchen, wie der architektonische Proxy Degradierungen beseitigt und Highload-Systeme stabilisiert.
Das Problem zeigt sich nicht sofort — bis zu dem Moment, in dem Redis nicht mehr als „transparente“ Komponente fungiert und beginnt, das Verhalten des Systems zu diktieren. Im beschriebenen Fall begann die Degradierung mit dem Anstieg der Verbindungen und dem Erreichen der I/O-Limits. Plötzliche Spitzen in der Kundenaktivität erzeugten den Effekt des thundering herd: Viele Dienste öffneten gleichzeitig Verbindungen und überlasteten den Cluster. Parallel dazu wuchs die Fragmentierung der Client-Bibliotheken. Dies beeinträchtigte die Beobachtbarkeit (observability) und erschwerte die Diagnose. Infolgedessen betrafen Vorfälle die Verfügbarkeit des gesamten Systems und nicht nur die Cache-Schicht.
Versuche lokaler Optimierungen, wie client-seitiges Pooling, hatten einen vorübergehenden Effekt. Sie isolierten die Ausfälle von Redis, beseitigten jedoch nicht die Wurzelursache. Architektonisch blieb das Problem bestehen: Zu viel Logik und Verantwortung lagen auf der Seite der Clients. Dies führte zu einer starken Kopplung und erschwerte die Evolution des Systems.
Die Lösung besteht darin, die Kontrolle in eine separate Schicht auszulagern: Redis-Proxy. Dieser Ansatz wurde bereits zuvor für Datenbanken über Proxys zur SQL-Routing verwendet. Hier wird dieselbe Idee auf den Cache übertragen. Der Proxy wird zum zentralen Punkt, an dem folgende Aspekte gebündelt werden:
- Verbindungsmanagement (connection management)
- Befehlsmultiplexierung
- Kontrolle des Kundenverhaltens
- Vereinheitlichung der Beobachtbarkeit
Dies ist eine Kompromisslösung. Sie fügt einen zusätzlichen Netzwerk-Hop hinzu und kompliziert die Infrastruktur. Im Gegenzug bietet sie Kontrolle über das System unter Highload-Bedingungen, in denen das Verhalten der Clients unvorhersehbar wird.
Die Implementierung ist als stateless-Service zwischen Anwendungen und Redis-Clustern aufgebaut. Die Architektur ist in zwei Schichten unterteilt:
- Frontend: akzeptiert Verbindungen, analysiert Redis-Befehle (RESP)
- Backend: multiplexiert Verbindungen und führt Befehle aus
Diese Trennung verringert die Kopplung und ermöglicht eine unabhängige Weiterentwicklung der Komponenten. Ein entscheidendes Detail ist die semantische Verarbeitung der Befehle. Im Gegensatz zu typischen Lösungen versteht der Proxy die Struktur der Anfragen und kann Runtime-Regeln anwenden: Filterung, Routing und benutzerdefinierte Befehle.
Die Konfiguration ist eine weitere wichtige Entscheidung. Anstelle statischer Dateien wird ein Starlark-Programm verwendet, das zur Laufzeit ausgeführt wird und die Konfiguration generiert. Dies ermöglicht es, das Verhalten des Systems ohne Deployment zu ändern. Im Kontext von SRE reduziert dies die MTTR, da Änderungen schneller und sicherer vorgenommen werden können.
Separat wurde das Problem des Redis Clusters mit CROSSSLOT-Fehlern gelöst. Normalerweise muss der Client das Sharding berücksichtigen. Hier fängt der Proxy solche Szenarien ab und führt Scatter-Gather durch: Er zerlegt die Pipeline in Teile, führt sie parallel aus und aggregiert das Ergebnis. Für den Client sieht dies wie eine einzige Operation aus. Dies verringert die Anforderungen an die Client-Logik und vereinfacht Migrationen.
Die Migration zum Proxy wurde umkehrbar gestaltet. Die Dienste wurden über die Konfiguration umgeschaltet, ohne den Code zu ändern. Der Traffic wurde schrittweise umgeleitet, mit der Möglichkeit eines sofortigen Rollbacks über Feature-Flags. Für große Dienste wurde ein schrittweiser Rollout verwendet. Dies ist ein typisches Muster zur Risikominderung bei Änderungen an der Infrastruktur.
Vor dem Start durchlief das System regelmäßige Stresstests mit Lasten über den Spitzenwerten. Dies ist wichtig: Der Proxy wird zu einer kritischen Komponente, und sein Ausfall wirkt sich auf die gesamte Plattform aus.
Die Ergebnisse zeigen, dass der Hauptgewinn nicht in der Latenz oder dem Durchsatz als solchen liegt, sondern in der Handhabbarkeit:
- Der Effekt des thundering herd wurde beseitigt
- Operationen (Failover, Skalierung, Updates) wurden zu zero-downtime
- Die Beobachtbarkeit wurde vereinheitlicht: Metriken, Protokolle und Traces sind abgestimmt
- Die Zeit zur Diagnose von Vorfällen wurde von Stunden auf Minuten verkürzt
Zahlreiche Metriken der Verbesserungen, abgesehen von der angegebenen hohen Verfügbarkeit, sind nicht detailliert. Aber der architektonische Effekt ist offensichtlich: Das System wechselt von verteiltem Chaos der Clients zu zentralisierter Kontrolle.
Ein interessanter Nebeneffekt ist die Abstraktion über das Backend. Der Proxy arbeitet über RESP und kann zwischen verschiedenen Speichern wechseln, einschließlich Alternativen zu Redis. Dies verringert den Vendor Lock-in und bietet Flexibilität auf der Infrastrukturebene.
Im weiteren Kontext bestätigt dies den Trend: Bei Erreichen eines bestimmten Maßes hört die Infrastruktur auf, ein „Detail“ zu sein, und wird zu einem Produkt. In solchen Systemen ist die Wahl zwischen Cache-aside oder Write-through weniger kritisch als die Zuverlässigkeit und Handhabbarkeit der Datenebene selbst.
Der Redis-Proxy ist in diesem Fall nicht nur eine Optimierung, sondern ein Weg, die Kontrolle über ein System zurückzugewinnen, in dem die Last und die Vielfalt der Clients bereits über einfache Lösungen hinausgegangen sind.