Durch die Integration von Datenkomprimierung in Redis haben wir die Speichernutzung um 70% reduziert, den Netzwerkverkehr verringert und Infrastrukturkosten erheblich eingespart — ohne die Datenstruktur zu verändern oder die Leistung zu beeinträchtigen.

In einem unserer Projekte standen wir vor einer kritischen Herausforderung: Der Speicher unserer Redis-Produktionsinstanz neigte sich dem Ende zu. Wir nutzen Redis als leistungsstarken Key-Value-Speicher für verschiedene Datentypen – von Produkten, Kategorien und Preisen bis hin zu Benutzersitzungen. Besonders die Sitzungsdaten erwiesen sich als Speicherfresser und beanspruchten etwa 80-90% des gesamten verfügbaren Speichers. Der Grund: Die Sitzungsobjekte in Redis enthalten sämtliche Details zum Warenkorb des Nutzers sowie dessen Wunschliste. In Extremfällen können diese Objekte pro Nutzer:in bis zu 4MB groß werden und bleiben bis zu 30 Tage im System.

Als Sofortmaßnahme entschieden wir uns für ein Upgrade unserer AWS Elasticache-Instanz von cache.r5.xlarge (26GB) auf cache.r5.2xlarge (52GB), wodurch wir unsere Speicherkapazität verdoppelten. Der entscheidende Nachteil: Die monatlichen Kosten für unseren Kunden verdoppelten sich ebenfalls.

Das akute Problem war zwar behoben. Wir benötigten dennoch eine nachhaltigere und kosteneffizientere Alternative. Zunächst zogen wir in Betracht, die in Redis gespeicherten Daten zu analysieren und neu zu strukturieren, um den Speicherverbrauch zu optimieren. Dann kam uns jedoch eine elegantere Lösung in den Sinn: Warum nicht die Daten vor der Speicherung in Redis komprimieren und beim Abrufen wieder dekomprimieren? Dieser Ansatz ermöglichte es uns, den Speicherbedarf drastisch zu senken, ohne die zugrundeliegende Datenstruktur verändern zu müssen.

Redis-Komprimierung for the win!

Die Einführung der Redis-Komprimierung erwies sich als Durchbruch für unser Speicherproblem. In unserem auf Spryker basierenden Projekt implementierten wir die Komprimierungstechnik für sämtliche in Redis gespeicherten Daten und erzielten beeindruckende Ergebnisse: Der Speicherverbrauch sank von ursprünglich 26GB auf lediglich 8GB – eine Reduktion um nahezu 70%! Je nach Objektgröße lag die Kompressionsrate zwischen 50% und 90%.

Da komprimierte Daten weniger Übertragungsvolumen benötigen, verringerte sich gleichzeitig der Netzwerkverkehr erheblich. Die Datenübertragung zu und von Redis wurde deutlich effizienter. Die Verbesserungen waren so substanziell, dass wir sogar unsere Redis-Instanz auf eine kleinere Variante zurückstufen konnten, was zu einer spürbaren Entlastung der Infrastrukturkosten führte.

Wer Redis-Komprimierung im eigenen Projekt implementieren möchten und Predis verwendet (was für Spryker-Projekte der Standard ist), kann wie folgt vorgehen.

Schritt 1: Predis Compression Package verwenden

Wir haben das b1rdex/predis-compressible Composer-Paket verwendet, das die Basis-Predis-Befehlsklassen um Komprimierungsfunktionen erweitert. Zum Beispiel bietet es erweiterte Befehle wie StringSet, die Komprimierung ziemlich reibunglos erledigen.

Schritt 2: Redis-Konfiguration aktualisieren

Um Komprimierung zu integrieren, ersetze die Standard Predis-Befehle durch die erweiterten Befehle. Wir haben es wie folgt in unserem Spryker-Projekt konfiguriert.

Füge dies zu deiner Konfiguration hinzu, also in config/Shared/config_default.php:

Schritt 3: Lege einen Grenzwert für die Kompression fest

Der ConditionalCompressorWrapper benötigt einen Schwellenwert (in Bytes), um zu bestimmen, wann Daten komprimiert werden sollen. Für unser Projekt haben wir einen Schwellenwert von 1024 Bytes (1kB) verwendet. Dies stellt sicher, dass kleinere Werte, bei denen der Kompressionsaufwand die Vorteile überwiegen würde, nicht komprimiert werden.

Basierend auf den eigenen Daten kann man kann durchaus mit verschiedenen Schwellenwerten experimentieren, um das optimale Gleichgewicht zwischen Speichereinsparung und Verarbeitungsaufwand zu finden.

Komprimierungs-Module

Es gibt mehrere Komprimierungs-Module für PHP. In unserem Fall haben wir ZLIB für die Komprimierung verwendet, das mehrere Ebenen (0-9) unterstützt. Das legt man fest, indem man den Parameter output-compression-level konfiguriert. 

Wir haben zügig die verschiedenen Ebenen verglichen, aber keine signifikanten Unterschiede in den Ergebnissen festgestellt. ZLIB lieferte ausgezeichnete Ergebnisse, ohne dass weitere Optimierungen erforderlich waren.

Auswirkungen auf Speicher und Traffic, nicht auf Leistung

Bevor wir die Änderung implementiert haben, lautete unsere wichtigste Frage: Wie wird sich das auf die Leistung der Anwendung auswirken? Die Komprimierung und Dekomprimierung führen zu einem gewissen Verarbeitungsaufwand beim Schreiben und Lesen von Daten. Dies wird jedoch durch die reduzierte Datenmenge, die übertragen wird, ausgeglichen.

Bei der Einführung einer solchen Änderung empfehlen wir immer, zumindest einen grundlegenden Performance-/Lasttest im eigenen Projekt durchzuführen, bevor man es im Produktionssystem aktiviert. In unserem Fall haben wir einen Lasttest in einer Testumgebung mit einer ähnlichen Konfiguration wie unserer Produktionsumgebung unter Verwendung von aktiver Komprimierung durchgeführt. Hier haben wir keine signifikante Veränderung in der Leistung festgestellt – sprich weder positiv noch negativ. Absoluter Best Case wäre natürlich ein leichter Performance-Gewinn gewesen. Führt man jedoch eine solche gravierende Änderung ein, ist es in der Tat ein großer Erfolg, wenn das aktuelle Leistungsniveau beibehalten wird!

Ein weiterer positiver Effekt neben der enormen Reduzierung des Speicherverbrauchs war die verringerte Netzwerklast aufgrund der geringeren Datenmengen, die jetzt zu/von Redis übertragen werden müssen. Dies kann auch Infrastrukturkosten sparen, wenn der Datenverkehr abgerechnet wird.

Kosteneinsparungen bei der Infrastruktur

Die Reduzierung des Speicherbedarfs und des Netzwerkverkehrs wirkt sich direkt auf die Infrastrukturkosten aus. Nach der Implementierung der Kompression konnten wir unsere AWS Elasticache-Instanz nicht nur auf ihre ursprüngliche Größe herabstufen, sondern sogar auf eine noch kleinere. Dies hat unserem Kunden fast $600 pro Monat an Redis-Kosten gespart.

Bei größeren Setups können die Einsparungen noch erheblicher sein. Zum Beispiel führen wir derzeit die Redis-Kompression für einen Auftraggeber mit Infrastruktur in 10 Ländern und mehreren Umgebungen pro Land ein. Die geschätzten Kosteneinsparungen für dieses Projekt belaufen sich auf rund € 100.000 pro Jahr.

Aufwand vs. Impact

Diese Verbesserung sticht als eine der wirkungsvollsten Optimierungen hervor, die wir umgesetzt haben, insbesondere im Vergleich zum erforderlichen Aufwand und den erzielten Ergebnissen. Unser kleines Team von zwei Entwicklern hat den gesamten Prozess in einem bemerkenswert effizienten zweitägigen Sprint bewältigt – von der Recherche über die Implementierung und das Testing.

Die eigentliche Implementierung selbst, dauert sogar nur etwa wie 30 Minuten – vorausgesetzt man weiß, wie man vorgeht. Wer mit wachsenden Datenmengen oder steigenden Infrastrukturkosten zu tun hat, für den ist Redis-Komprimierung eine einfache, aber leistungsstarke Optimierung. Wir hoffen, dass dieser Leitfaden hilft, die Redis-Komprimierung in eigenen Projekten umzusetzen – mit minimalem Aufwand zu enormen Einsparungen und neuer Effizienz.