Der Forever-Log: Warum Tiered Storage die Rechnung (und die Risiken) verändert

Bryan: Das bringt uns zu Tiered Storage. Davor war es zwar technisch möglich, Daten für immer in Kafka zu halten, aber sehr teuer.

Anatoly: Exakt. Vor Tiered Storage war Kafka einfach nur eine sehr teure, schnelle Festplatte. Weil Speicher und Rechenleistung (Compute) gekoppelt waren, musstest du, wenn du 100 TB Historie speichern wolltest, auch die Server kaufen, um diesen Speicher zu unterstützen – selbst wenn du die CPU-Leistung gar nicht benötigt hast.

Tiered Storage ändert diese Rechnung grundlegend. Es entkoppelt Compute von Storage. Du behältst deine heißen Daten (die letzten paar Stunden oder Tage) auf teuren SSDs auf dem Broker. Alles andere, Monate oder Jahre an Historie, wird auf S3 oder einen anderen Object Store ausgelagert.

Bryan: Aber ich höre oft Leute fragen: "Warum soll ich alles in Kafka behalten? Ich kann es doch einfach in meine Datenplattform laden und von dort nutzen."

Anatoly: Das ist das übliche Gegenargument. Aber Kafka kann als System of Record sowohl für operationale als auch für analytische Daten fungieren. Das ermöglicht dir einen zentralen Zugriffspunkt für alte und neue Daten.

Das macht den Forever-Log möglich. Plötzlich ist Kafka nicht mehr nur eine Pipe. Es wird zum System of Record. Aber genau hier beginnen die neuen Herausforderungen.

Bryan: Wenn Kafka zum System of Record wird, ändern sich die Anforderungen an die Zuverlässigkeit. Aber viele Teams arbeiten immer noch unter der Annahme: "Kafka braucht keine Backups, weil es Replikation hat."

Anatoly: Das ist ein gefährlicher Irrtum. Zu sagen "Ich habe einen Replikationsfaktor von 3, also brauche ich keine Backups", ist wie zu sagen "Ich habe RAID 5, also brauche ich keine Backups". Wir haben spätestens in den 90ern gelernt, dass RAID kein Backup ist.

Replikation bietet Hochverfügbarkeit. Sie schützt dich, wenn ein Server abstürzt. Sie schützt dich nicht vor menschlichem Versagen.

Wenn jemand ein Skript ausführt, das ein Topic in der Produktion statt in der Entwicklungsumgebung löscht, sorgt die Replikation nur dafür, dass die Daten sofort von allen drei Brokern gelöscht werden.

Mit Tiered Storage wird deine Backup-Strategie tatsächlich etwas handhabbarer, aber du musst gezielt vorgehen. Es ist auch wichtig zu beachten, dass diese rohen Backups unflexibel sein können:

Bryan: Lass uns über die Metadaten sprechen. Du hast erwähnt, dass man selbst mit Backups der Logs die Daten möglicherweise nicht mehr lesen kann – wegen der Schema Registry.

Anatoly: Das ist der spezielle Albtraum, der mich nachts wach hält. Die Schema Registry weist jedem Schema eine ID zu. Diese ID ist in die Kafka-Nachricht eingebettet. Das Problem ist: Die ID hat keine semantische Bedeutung. Sie ist nur ein Zähler.

Bryan: Und was passiert, wenn diese Zuordnung verloren geht?

Anatoly: Ich kann dir ein echtes Beispiel geben. Ich hatte einen Kunden, bei dem das _schemas Topic versehentlich gelöscht wurde.

Es war eine Katastrophe. Die Daten waren noch da. Terabytes davon lagen in den Topics. Aber weil das _schemas Topic weg war, verloren sie die Zuordnung. Sie hatten Nachrichten, die sagten "Ich bin Schema ID 5", aber sie hatten keine Ahnung mehr, wie ID 5 aussah.

Bryan: Das ist beängstigend.

Anatoly: Ist es. Du musst dein _schemas Topic als ein extrem kritisches Datenstück behandeln. Wenn du Disaster Recovery betreibst, kannst du nicht einfach eine neue Registry hochfahren und erwarten, dass es funktioniert. Die IDs werden nicht übereinstimmen (ID 5 im alten Cluster könnte ID 1 im neuen sein).

Wenn du dieses spezifische Topic nicht Byte-für-Byte sicherst und wiederherstellst, könnten deine Terabytes an Daten zu binärem Müll werden.

Bryan: Tiered Storage öffnet also die Tür zum Forever-Log, aber die operationale Reife muss erst noch aufholen?

Anatoly: Genau. Wir bewegen uns von Daten bewegen zu Daten behalten.

Bryan: Danke für diesen Realitätscheck, Anatoly.

Anatoly: Jederzeit. Wir sehen uns auf dem nächsten Kafka Summit. Oder auf LinkedIn (Bryan und Anatoly).