Strategien und bewährte Verfahren für API-Caching

Was ist API-Caching?

API-Caching ist ein Prozess, bei dem häufig angeforderte Objekte in einem sekundären Datenspeicher abgelegt werden, um kontinuierliche Aufrufe einer primären Datenbank oder eines anderen Datenspeichertyps zu vermeiden. Der Hauptvorteil eines Caches ist die Verarbeitungsgeschwindigkeit, da er es einer Anwendung ermöglicht, häufig angeforderte Objekte aus Quellen abzurufen, auf die sie effizient zugreifen kann.

Die Wahl zwischen einem primären Datenspeicher und Cache hängt von der Geschwindigkeit im Vergleich zur Größe ab. Daten in einer primären Datenbank sind möglicherweise besser strukturiert und durchsuchbar, aber der Zugriff darauf kann dennoch schwieriger sein als auf Daten in einem dedizierten Cache.

Warum API-Caching wichtig ist

API-Caching ist oft eine kostengünstige Möglichkeit, die Leistung zu verbessern. Durch den Einsatz von Tools, die die am häufigsten angeforderten Daten einer Anwendung speichern, können Entwickler die Belastung der Anwendung reduzieren und die Anfragen für die meisten Benutzer beschleunigen.

Caching kann auch eine rudimentäre Notlösung zur Bewältigung von Skalierungsproblemen sein, da die meisten Anfragen idealerweise vom Cache beantwortet werden und ein großer Teil des Datenverkehrs von den Anwendungsservern entlastet wird. Im Falle eines Ausfalls der zugrunde liegenden Anwendung kann ein gut implementierter Cache auch dazu beitragen, Ausfallzeiten zu vermeiden, indem er zumindest veraltete Daten bereitstellt, anstatt gar nichts zu liefern.

Arten von API-Caching-Strategien

Es gibt mehrere bekannte API-Caching-Strategien, darunter Cache-Aside, Read-Through, Write-Through, Write-Back und Write-Around.

Cache-Aside

Die gängigste Caching-Strategie, Cache-Aside, nutzt die Anwendung selbst zur Verwaltung des Caches. Bei einem Cache-Fehler ruft die Anwendung den Wert aus der Datenbank ab und fügt ihn in den Cache ein. Beim Schreiben neuer Daten speichert die Anwendung die Daten in der Datenbank und macht einfach alle Cache-Einträge für diese Daten ungültig. Diese Strategie wird auch als Lazy Loading bezeichnet, da nichts im Cache gespeichert wird, bis es von der Anwendung angefordert wird. Lazy Loading stellt sicher, dass der Cache die am häufigsten angeforderten Daten enthält.

Read-Through

Bei einer Read-Through-Cache-Konfiguration befindet sich der Cache zwischen der Anwendung und der Datenbank. Wenn Daten von der Anwendung angefordert werden, sendet die Anwendung eine Anfrage an den Cache. Wenn kein Eintrag für die Daten vorhanden ist, ruft der Cache den Wert aus der Datenbank ab, gibt ihn an die Anwendung zurück und speichert ihn dabei im Cache.

Write-Through

Die Write-Through-Strategie ähnelt dem Read-Through. Wenn Daten in die Anwendung geschrieben werden, übernimmt der Cache das Schreiben der Daten in die Datenbank und speichert den in die Datenbank geschriebenen Wert im Cache.

Write-Back

Bei der Write-Back-Strategie schreibt die Anwendung Daten in den Cache, und der Cache schreibt sie dann asynchron in die Datenbank. Die Idee hinter dieser Caching-Strategie besteht darin, die Schreibleistung durch das Zwischenspeichern von Schreibvorgängen zu priorisieren, da der Cache für das Schreiben neuer Daten in die Datenbank verantwortlich ist. Die Daten werden von der Anwendung über den Cache gelesen, sodass die Daten garantiert auf dem neuesten Stand sind, auch wenn der Cache die Datenbank noch nicht aktualisiert hat.

Write-Around

Write-Around-Caching bezieht sich darauf, dass die Anwendung direkt in die Datenbank schreibt, anstatt über den Cache. Die Idee hinter der Write-Around-Strategie ist, dass Daten, die beim Schreiben in einen Cache geschrieben werden, möglicherweise einfach ungenutzt bleiben. Je nach Kontext der Daten und der Funktionsweise der Anwendung kann es wesentlich effizienter sein, nur beim Lesen von Daten in den Cache zu schreiben.

Wichtige Best Practices für API-Caching

Entwicklungsteams sollten diese Best Practices bei der Implementierung von API-Caching berücksichtigen.

1. Festlegen einer Time To Live (TTL)

Time To Live (TTL) ist eine äußerst wichtige Einstellung für Caching-Tools. Bei der Definition einer TTL wird einfach eine Zeitspanne festgelegt, wie lange ein Cache-Eintrag gültig ist, bevor er abläuft und erneut aus der Datenbank gelesen werden muss. Die Dauer der TTL hängt von der Anwendung und den betreffenden Daten ab. Für Produktbestände wäre beispielsweise eine kürzere TTL besser, die häufiger abläuft und sicherstellt, dass der Cache aktualisiert wird. Für Daten, die nicht oft aktualisiert werden, wie Preise oder Benutzerprofilinformationen, kann eine längere TTL verwendet werden.

2. Bestimmen Sie die Basisleistung

Bei der Integration von API-Caching in eine Anwendung sollten Entwickler die Performance Benchmarks verstehen, insbesondere um die Leistung einer Anwendung mit Caching mit ihrer Leistung ohne Caching zu vergleichen.

Zu Beginn können Entwickler mit Tools wie Apache JMeter oder Locust Lasttests für API-Anfragen erstellen. Mit diesen beiden Open-Source-Tools können Entwickler die Anzahl der API-Anfragen skalieren, um verschiedene Anfragenlasten von unterschiedlichen Benutzertypen zu simulieren. Die Ergebnisse dieser frühen Lasttests können einen ersten Benchmark für die Leistung der Anwendung liefern.

Die Netzwerkbandbreite, Latenz und Rechenleistung eines Computers können einen erheblichen Einfluss auf die Menge der generierten Anforderungslasten haben. Entwickler müssen dies beim Vergleich der Lasttest-Ergebnisse berücksichtigen, da die Ergebnisse verschiedener Durchläufe möglicherweise keinen gültigen Vergleich darstellen. Um diese Diskrepanzen zu vermeiden, sollten Sie ein Cloud-Lasttest-Tool hinzufügen, das stabile, isolierte Server mit konsistenter Netzwerkbandbreite und Latenz verwendet. BlazeMeter oder CloudTest sind einige Beispiele für Tools, die dies leisten können.

3. Testszenarien für Anfragen ausführen

Nachdem sie einen Basis-Benchmark erhalten haben, können Entwickler Caching implementieren und die Leistung der Anwendung neu bewerten. Im Idealfall sollte sich die Fähigkeit der Anwendung, Lasten unter Stress zu bewältigen, verbessern – und hoffentlich auch ihre Gesamtleistung. Unabhängig von der Leistung sollten Teams jedoch auch die Antworten validieren, die Anfragen zurückgeben, um sicherzustellen, dass der Cache ordnungsgemäß funktioniert.

Eine Möglichkeit, dies zu überprüfen, besteht darin, Testszenarien zu erstellen, die nach aktualisierten Werten suchen und von Entwicklern in wenigen Schritten ausgeführt werden können. Beispiel:

1. Konfigurieren Sie eine Gruppe von Anfragen so, dass sie ausschließlich den Cache der Anwendung verwenden.
2. Nehmen Sie eine Aktualisierung eines Werts vor, der sich in der primären Datenbank der Anwendung befindet.
3. Senden Sie nach Ablauf der erwarteten Cache-Gültigkeitsdauer eine Anfrage an die Anwendung, um zu überprüfen, ob der aktualisierte Wert zurückgegeben wurde.

Je nach Cache-Implementierung können Entwickler auch Testszenarien ausführen, um bestimmte Funktionen zu überprüfen.

4. Verwenden Sie Schlüssel-Wert-Speicher

Viele Open-Source-Caching-Tools – wie Memcached – verwenden einen Schlüssel-Wert-Ansatz, um den Cache im Speicher zu füllen, wenn Anfragen eingehen. Bevor ein Wert im Cache vorhanden ist, überprüft eine Anwendung den Cache auf den angegebenen Schlüssel, der die Objekte identifiziert, die als Teil der Antwort zurückgegeben werden sollen.

Wenn kein Schlüssel im Cache vorhanden ist, fragt das Tool eine Datenbank ab und liefert eine Antwort zusammen mit dem erwarteten Schlüssel, den der Cache verwenden soll. Nachfolgende Anfragen für denselben Schlüssel erfordern keine Abfrage der Datenbank mehr, da sie nun im Cache gespeichert sind.

5. Vermeiden Sie das Thundering-Herd-Problem

Stellen Sie sich vor, es gibt zehn Server, die jeweils dieselbe Webseitenanwendung bedienen. Die Webseite wird in einem Cache gespeichert, der alle fünf Minuten abläuft, um sicherzustellen, dass Benutzer immer die aktuellste Version der Seite sehen. Der Cache kann ablaufen, während diese zehn Server stark ausgelastet sind, was dazu führt, dass jeder Server gleichzeitig den Cache abfragt, keine Webseite findet und versucht, direkt auf die primäre Datenbank zuzugreifen.

Caching unter einer solchen hohen Last – insbesondere in einem verteilten System – kann zum sogenannten Thundering-Herd-Problem führen. Wenn zehn Server gleichzeitig die Datenbank abfragen, entsteht eine hohe Auslastung, und eine rechenintensive Abfrage kann leicht zu einer Kaskade von Zeitüberschreitungen führen, da die Datenbank weiterhin überlastet ist. Wenn diese fehlgeschlagenen Anfragen erneut versucht werden, belasten sie die Datenbank zusätzlich und machen die Anwendung möglicherweise unbrauchbar.

Glücklicherweise gibt es einige Möglichkeiten, ein Thundering-Herd-Szenario zu vermeiden. Zum einen kann der Cache gesperrt werden, um sicherzustellen, dass jeweils nur ein Prozess den Cache aktualisieren kann. Mit dieser Sperre können Anwendungen, die versuchen, den Cache zu aktualisieren, zuvor gespeicherte Werte verwenden, bis die Aktualisierung abgeschlossen ist. Entwickler können auch einen externen Prozess zur Aktualisierung des Caches verwenden, anstatt sich auf die Anwendung selbst zu verlassen.

Eine weitere nützliche Möglichkeit, ein Thundering-Herd-Szenario zu vermeiden, besteht darin, das Ablaufdatum des Caches auf einen vorhergesagten Wert zu aktualisieren, wenn sich das Ablaufdatum des Caches nähert. In einem solchen Fall können Anwendungen, die auf den Cache angewiesen sind, auch die voraussichtlichen Ablaufzeiten berechnen und so besser sicherstellen, dass sie nicht alle gleichzeitig ablaufen.

6. Sicherheit bei der Entwicklung berücksichtigen

Da beim Caching Daten gespeichert werden, ist es wichtig, bei der Verwendung von Caching-Tools die Auswirkungen auf die Sicherheit zu berücksichtigen. Generell sollten keine personenbezogenen Daten im Cache gespeichert werden. Der Zugriff auf den Cache sollte ebenfalls eingeschränkt werden, da er eine Schwachstelle für mögliche Angriffe darstellt.

Wenn ein Angreifer auf den Cache zugreifen kann, kann er bösartige Daten einfügen, die dann zum Kompromittieren von Benutzerkonten oder anderen sensiblen Daten verwendet werden können. Es sollten spezifische Kontrollen vorhanden sein, um alle in den Cache eingefügten Daten zu validieren und solche Angriffe zu verhindern. Der Cache sollte nur für die Anwendung oder Datenbank zugänglich sein, die für seine Funktion erforderlich ist.