Application-Caching-Strategien

Dieser Artikel gibt einen Überblick über das Caching, seinen Zweck und seine Anwendungsfälle und zeigt wie Unternehmen mit ihr verschiedene Caching-Strategien in Ihre Anwendungslandschaft integrieren können.

In der IT ist ein Cache eine Komponente zur Speicherung von Daten, die ansonsten zeitintensiv berechnet, verarbeitet oder von einem darunterliegenden Backend-System abgerufen werden müssten. Caching verhindert unnötige, zusätzliche Netzwerkzugriffe und Prozesse häufig verwendeter Daten In beiden Fällen lässt sich Caching zur Leistungssteigerung oder zur Minderung der Latenzzeiten von Anwendungen nutzen. Ein Cache-Hit tritt ein, wenn Daten bereits im Cache verfügbar sind und ohne weitere Vorgänge zurückgegeben werden können. Ansonsten reagiert der Cache auf eine Anfrage mit einem Cache-Miss oder kann, sofern verfügbar, die Daten von einem anderen darunterliegenden Backend-System transparent abrufen und, vor der Rückgabe, zwischenspeichern. Caches wurden entwickelt, um nahezu in Echtzeit auf Datenanfragen zu reagieren. Sie sind daher als einfache Key-Value-Datenbank implementiert. Ihre Datenstruktur kann dennoch unterschiedlich ausfallen und hängt vom Speicher-Backend ab. Außerdem können Caches häufig durch mehrere Frontend-Systeme wie Webanwendungen verwendet werden. Caches können mehrere Ebenen aufweisen, die als mehrstufige Speicher bezeichnet werden und nach ihrem jeweiligen Geschwindigkeitsfaktor angeordnet sind. Man spricht hier von Tiered-Storage Systemen. Häufig oder vor Kurzem verwendete Daten werden üblicherweise im Arbeitsspeicher vorgehalten, während andere Daten (abhängig von den Implementierungen der mehrstufigen Speicher) auf SSD oderlangsamere Festplattensysteme geschrieben. Denkbar ist auch die vollständige Entfernung, wenn sie reproduzierbar sind.

Typische Szenarien sind In-Memory Caches für Datenbanken, mit hoher Latenzzeit wiederherstellbare Daten von Festplattenspeichern, remote gespeicherte Daten hinter langsamen Netzwerkverbindungen oder Ergebnisse aus vorherigen Berechnungen.

Bild 1: In-memory Caching für Datenbanken ist ein Paradebeispiel für den Einsatz des Cachings.

Warum Caching?

Caching kommt als Lösung oft dann ins Spiel, wenn die Antwortzeiten der Webserver, Datenbanken oder sonstiger Backend-Ressourcen exponentiell ansteigen. Die erste Optimierungsmaßnahme besteht oft darin, schnell einen Cache in die Anwendungslandschaft zu integrieren. Auf eine Caching-Strategie im Vorfeld wird meist verzichtet. Dieser Ansatz ist problematisch, denn so entsteht ein zentrales System, das zugleich Schwachstelle und limitierender Faktor ist.

Das ist beispielsweise der Fall, wenn alle Daten in einer relationalen Datenbank gespeichert werden. Jeder Seitenabruf initiiert nicht nur eine Abfrage der Datenbank, sondern möglicherweise multiple und mitunter auch komplexe Verknüpfungen. Zu Spitzenzeiten leiden Anwender dann unter langen Ladezeiten sowie hohen Latenzen, je nachdem, wie viele Roundtrips die Daten zwischen ihrem Standort und dem Rechenzentrum zurücklegen müssen. Mit Caching First ist ein Begriff entstanden, der verdeutlicht, dass Caching selbst eines der wichtigen Bestandteile einer Applikation ist – ebenso wie Datenbanken, Anwendungsserver, Hardwarespezifikationen oder das Benutzererlebnis. Heutzutage müssen Systeme eine kritische Masse erreichen, um erfolgreich sein zu können.

Es ist unwahrscheinlich, dass diese kritische Masse mit einer einzelnen Datenbank oder einem einzigen Webserver erreicht werden kann. Systeme müssen bestimmte Caches integrieren. Dieses Whitepaper liefert alle notwendigen Informationen, die Sie zum Aufbau Ihrer eigenen Caching-Strategie benötigen. Die Auswahl ist letztlich vergleichbar mit der Entscheidung für eine bestimmte Datenbank oder einer Programmiersprache.

---

Lesen Sie auch den anderen Beitrag der Serie „Big Data“:

Teil 1: Application-Caching-Strategien
Teil 2: Caching-Topologien und Bereinigungsstrategien

---

Vorteile

Wie bereits angesprochen, beschleunigt Caching bestimmte Anfragen oder Teile von Anfragen. Webseiten, die dynamisch generiert werden, sich allerdings mangels Änderungen wie statische Inhalte verhalten, können umfassend zwischengespeichert werden. Dasselbe gilt für Seitenfragmente, die vorgerendert und vor dem Versand nur mit anwenderspezifischen Daten angereichert werden. Ebenso können Anfragen, die nicht zu dynamischen Datensätzen (aufgrund von Berechnungen während Anfragen) führen, ganz einfach zwischengespeichert werden, was zu viel höheren Anforderungsgeschwindigkeiten führt.

Gutes Caching unterstützt Nutzer und Anbieter von Inhalten. Eine gute Caching-Strategie bietet viele Vorteile und senkt die Hardwareausgaben bei vergleichbar, guten Ergebnissen.

• Besseres Antwortverhalten: Ein Cache beschleunigt den Abruf von Inhalten und vermeidet zusätzliche Netzwerk-zugriffe. Gute Caching-Strategien (beispielsweise für Webseiten) lagern statische Inhalte sofort in den Webbrowser-Cache des Benutzers aus.
   
• Geringere Netzwerkkosten: Je nach Caching-Strategie stehen Inhalte in mehreren, geografisch verteilten Orten oder Netzwerk-Lokationen zur Verfügung. Inhalte rücken damit näher an den Benutzer heran und die Netzwerkaktivitäten werden reduziert.
   
• Höhere Leistung bei gleicher Hardware: Ein Cache speichert bereits abgerufene Inhalte und stellt diese bereit, solange sie gültig sind. Kostspielige Berechnungen, Seitenaufbauten oder andere relativ langwierige Operationen werden reduziert oder eliminiert, was die Hardware frei macht für die Abarbeitung anderer Anfragen.
   
• Verfügbarkeit von Inhalten bei Unterbrechung von Netzwerk- oder Backend-Ressourcen: Ein Cache kann zwischengespeicherte Daten auch dann bereitstellen, wenn Backend-Systeme nicht verfügbar sind oder wenn die Netzwerkverbindung Probleme macht.

Der Einsatz

Immer dann, wenn bestimmte Anfragen oft und regelmäßig getätigt werden, sollte man über die Zwischenspeicherung dieser Elemente nachdenken. Das können Datenbankabfragen, HTMLFragmente, vollständige Websites oder die Ausgabe einer großen, langwierigen Berechnung sein. Ebenso ist es sinnvoll, jegliche Art sprachspezifischer Daten geografisch lokal für den Content Consumer abzuspeichern, beispielsweise Übersetzungen (Anwenderdaten für Personen in einer bestimmten Region). Es gilt nur eine Regel: Daten dürfen sich nicht zu häufig oder schnell ändern, sollten jedoch recht oft abgerufen werden, als Formel: Lesen > Schreiben.

Was nicht in den Cache gehört!

Es ist ein Irrglaube, dass man automatisch davon profitiert, wenn man alles zwischenspeichert. Was häufig zunächst funktioniert, bereitet bei hohen Datenspitzen aber andere Schwierigkeiten.

Sich häufig ändernde Daten sind generell nicht sehr gut für Caches. Immer dann, wenn sich Daten ändern, muss der Cache annulliert werden; und je nach ausgewählter Caching-Strategie kann das äußerst aufwändig sein. Stellen Sie sich ein globales Caching-System vor und eine Änderungsstrategie von über 100 Änderungen pro Sekunde. Der Vorteil des Zwischenspeicherns, nämlich Daten schnell wiederherzustellen, wird durch den Umstand zunichtegemacht, dass alle Caches gelöscht und die Datensätze für jede einzelne Änderung neu abgerufen werden müssen.

Auch schnell wiederherstellbare Daten gehören nicht in den Cache. Rasch abrufbare Daten beanspruchen den Arbeitsspeicher zusätzlich und unnötig. Darüber hinaus ist der Vorteil, solche Daten zwischen zu speichern gering oder nicht vorhanden, und rechtfertigt keine umfangreiche, teure Architektur.

Cachetypen

Je nach Art der gespeicherten Daten werden Caches meist in drei unterschiedliche Kategorien unterteilt. Nachfolgend ein Kurzüberblick über diese Kategorien sowie Beispiele für ihren Einsatz.

• HTTP-Cache

  Ein HTTP-Cache wird meist in Browsern eingesetzt. Diese Art von Cache enthält Informationen über den letzten Änderungszeitpunkt einer Ressource oder einen Content Hash zur Identifizierung von Änderungen an diesem Inhalt. Webserver müssen dafür nützliche Informationen über den Status eines Elements bereithalten, damit ein bereits im Cache vorhandenes Element nicht erneut vom Server abgerufen wird. Der Cache dient dazu, den Netzwerkdatenverkehr zu reduzieren, Kosten zu minimieren und die Geschwindigkeit für den Benutzer bei mehrfachen Besuchen zu steigern.

• Fragement Cache

  Ein Fragment Cache speichert Teile einer Antwort oder eines Ergebnisses. Dies könnte das Ergebnis einer Datenbankabfrage oder ein Teil einer HTML-Seite sein. Ganz gleich, was es ist, es sollte sich nicht häufig ändern.

  Ein Fragment Cache kommt häufig bei Webseiten zum Einsatz, die oftmals eine Kombination aus benutzerspezifischen und nicht benutzerspezifischen Inhalte enthalten. Der benutzerunabhängige Inhalt kann als Fragment vorgehalten und bei Abruf mit benutzerspezifischen Inhalten erweitert werden. Diesen Prozess bezeichnet man als Content Enrichment. Diese Art von Caching dient dazu, Betriebs- und Hardwarekosten zu reduzieren, indem man den gleichen Durchsatz mit weniger Computeraufwand bereitstellt.

• Object Cache

  Ein Object Cache speichert alle Arten von Objekten, die ansonsten aus anderen Datentypen ausgelesen werden müssten. Ein solcher Cache lässt sich vor einer Datenbank nutzen, um Abfragen zu beschleunigen und die resultierenden Objekte (etwa Object Relational Mapping, ORM) zu speichern. Er speichert außerdem nicht umgewandelte Ergebnisse von beispielsweise XML- oder JSON-Daten. Diese Caches dienen oft als Proxy zwischen externen Ressourcen, wie einer Datenbank oder Webservices, und sie beschleunigen die Transformationsprozesse oder vermeiden zusätzliche Netzwerkzugriffe zwischen Anwender- und Produktionssystemen.

Caching Strategien

Nun zu den unterschiedlichen Typen der gängigen Caching-Strategien.

Das Cooperative/Distributed Caching

Beim Cooperative Caching, auch als Distributed Caching bezeichnet, bilden mehrere Einzelsysteme (üblicherweise als Cluster-Knoten) einen großen, gemeinsamen Cache. Anfragen an Cooperative Caches werden entweder an alle Knoten gerichtet. Oder es existiert ein intelligentes Partitionierungssystem: dieses beruht normalerweise auf konsistenten Hash-Algorithmen und leitet Anfrage zu dem Knoten mit dem entsprechenden Schlüssel weiter. Cooperative Caching ist heute das übliche Verfahren bei größeren Systemen, das große Datenmengen vorhalten muss.

Bild 2: Szenario des Cooperative Cachings mit Hilfe von Hazelcast.

Partielles Caching

Beim partiellen Caching werden nicht alle Daten im Cache abgelegt. Abhängig von bestimmten Kriterien sind die Antworten entweder nicht für den Cache geeignet oder es wird nicht erwartet, dass sie gespeichert werden sollen (beispielsweise temporäre Ausfälle). Webseiten sind ein typisches Beispiel dafür Einige Seiten sind „statisch“ und ändern sich nur bei manuellen oder routinemäßigen Eingriffen. Diese Seiten lassen sich leicht cachen und wieder auffrischen, wenn Änderungen vorgenommen worden sind. Andere Seiten bestehen vorwiegend aus dynamischen oder häufig aktualisierten Inhalten (etwa Aktienkurse) und sollten daher gar nicht gecachet werden.

Bild 3: Nicht alle Daten werden hier gecachet.

Geografisches Caching

Geografische Caches berücksichtigen, woher die Anfrage kommt und verkürzen, da strategisch günstig gelegen, die Antwortzeiten. Diese Art von Cache wird daher meist für Websiten-Content verwendet und ist bekannt unter dem Begriff Content Delivery Network, kurz CDN. Ein geografischer Cache greift transparent auf einen zentralen Cache zu, der als Hauptquelle für Inhalte und lokal abgerufene Daten dient.

Dieses Konzept eignet sich gut für statische Inhalte oder solche, die sich seltener ändern. Die regionalen Caches können normalerweise kleiner als der zentrale Cache sein, da bestimmte Caches auf Regionen mit unterschiedlichen Sprachen oder kulturellen Unterschieden spezialisiert sind. Geografisches Caching wird zudem häufig in Verbindung mit partiellem Caching verwendet, um statische Inhalte (etwa Bilder, Ton, Videos usw.) so nah wie möglich am Ort der Abfrage zwischen zu speichern. Dynamische Inhalte dagegen werden mithilfe unterschiedlicher Routen oder Regelmechanismen (Forwardern) erstellt. Der geografisch nächstgelegene Cache wird häufig durch Georouting anhand von IP-Adressen (DNS-Routing) oder mithilfe von Proxies ermittelt, die die Anfragen mithilfe des HTTP-Statuscodes 302 an bestimmte IP-Adressen weiterleiten.

Bild 4: Für geografisches Caching gibt es spezielle Anwendungsgebiete.

Präventives Caching

Präventive Caches sind streng genommen nicht Teil einer eigenständigen Caching-Strategie. Meistens werden sie in Verbindung mit geografischen Caches genutzt. Ein präventiver Cache wird beim “Warm-up” mit Daten befüllt. Ab jetzt versucht der Cache, sich selbst zu aktualisieren, basierend auf Regeln oder Ereignissen. Dem liegt die Idee zugrunde, Daten aus einem Backend-Service oder einem zentralen Cluster zu laden, bevor sie tatsächlich benötigt werden. So bleiben die Zugriffszeiten für die vorgehaltenen Elemente konstant. Außerdem werden unzumutbar lange Wartezeiten beim Zugriff auf einzelne Elemente vermieden. Der Aufbau eines präventiven Cache erfordert gute Kenntnisse der betreffenden Domain und deren Update-Zyklen.

Bild 5: Nichts für Anfänger – der Aufbau eines präventiven Cache.

Latenz SLA Caching

Service-Level-Agreements (SLA) gibt es auch bei den Ladezeiten. Um die Latenz-SLAs einhalten zu können, selbst dann, wenn der Cache langsam oder überlastet ist, gibt es zwei Möglichkeiten: Im ersten Fall muss ein Timeout überschritten werden, bevor das System entweder das potenziell vorgehaltene Element aus der ursprünglichen Quelle abruft (parallel zur bereits laufenden Cache-Abfrage) oder eine einfache Standardantwort gibt. Verwendet wird dann jenes Ergebnis, welches zuerst vorliegt.

Bild 6: Caching für Fortgeschrittene- Fall 1.

Im zweiten Fall werden beide Abfragen parallel abgesetzt. Die zuerst vorliegende Antwort wird verwendet. Dies ist allerdings nicht die bevorzugte Implementierungsform, da sie der Idee des Cache eigentlich zuwiderläuft und das Backend-System nicht entlastet. Sie lässt sich allerdings sinnvoll einsetzen, wenn mehrere Caching-Ebenen vorhanden sind, also wenn beispielsweise immer versucht wird, den ersten und zweiten nächstgelegenen Cache parallel zu verwenden.

Bild 7: Caching für Fortgeschrittene- Fall 2.

Weitere Informationen:

Teil 2 der Serie “Big Data” widmet sich dem Thema Caching-Topologien und Bereinigungsstrategien.

Christoph Engelbert, Technical Evangelist Senior Solutions Architect bei Hazelcast

https://hazelcast.com/