Einheit 5.6: Event Streaming (Gemanagtes Kafka)

Einführung

Die tragende Entscheidung im Event-Streaming besteht nicht im Bereitstellen des Clusters, sondern in der Struktur des Topics. Die Anzahl der Partitionen bestimmt sowohl die Reihenfolgegarantie als auch die Obergrenze für die Parallelität der Consumer für die gesamte Lebensdauer dieses Topics. Der Replikationsfaktor und die Aufbewahrungsdauer entscheiden gemeinsam darüber, wie viel Sie für die sichere Aufbewahrung von Daten zahlen und wie lange diese aufbewahrt werden. Wenn die Topic-Struktur korrekt gewählt wird, ist der Cluster fast nebensächlich. Wird sie falsch gewählt, wird die Grenze in der Produktion deutlich, wo Partitionen nicht reduziert werden können und eine Umstrukturierung ein neues Topic und eine Migration erfordert.

Diese Einheit behandelt Event Streams for Apache Kafka als Streaming-Backbone für FinCorp, das deutsche Finanzdienstleistungsunternehmen, das während seiner Migration und mit seiner neuen KI-Fähigkeit DSGVO- und BSI-Pflichten erfüllt. Wir beginnen mit der Entscheidung zur Topic-Entwicklung, erklären, wie Partitionen, Consumer-Gruppen, Replikation und Aufbewahrungsdauer zusammenwirken, zeigen, wo der Stream in der Gesamtarchitektur positioniert ist, und erstellen anschließend einen Cluster und ein korrekt strukturiertes Topic im Data Center Designer.

1. Das Topic ist die Architektur: Partitionen, Reihenfolge und Parallelität

Eine Partition ist die Einheit für sowohl Reihenfolge als auch Parallelität, und diese beiden Eigenschaften wirken in die gleiche Richtung. Genau deshalb ist die Partitionszahl die wichtigste Entscheidung. Kafka hält die Reihenfolge von Nachrichten innerhalb einer Partition aufrecht; über Partitionen hinweg gibt es keine Reihenfolgegarantie. Wenn FinCorp also alle Ereignisse für ein bestimmtes Konto in der Reihenfolge verarbeiten muss, in der sie eingetreten sind, müssen alle Ereignisse für dieses Konto in derselben Partition landen. Der Standardweg, dies sicherzustellen, besteht darin, einen Partitionsschlüssel (die Kontokennung) zu setzen, sodass der Producer ihn auf eine feste Partition hashet. Die Reihenfolge ist daher eine Eigenschaft pro Schlüssel, nicht pro Topic: Man erhält eine strenge Reihenfolge innerhalb jedes Schlüssels und Parallelität über Schlüssel hinweg, was genau das ist, was ein Transaktionsfeed mit hohem Volumen benötigt.

Parallelität ist die andere Seite derselben Medaille. Innerhalb einer Consumer Group wird eine Partition zu einem Zeitpunkt von höchstens einem Mitglied konsumiert. Die Partitionszahl ist daher die harte Obergrenze dafür, wie viele Consumer dieses Topic parallel bearbeiten können. Drei Partitionen bedeuten höchstens drei aktive Consumer; ein vierter bleibt untätig. Mehr Partitionen ermöglichen eine bessere Lastverteilung über die Consumer hinweg und verbessern die Durchsatzrate, aber sie vermehren auch offene Datei-Handles, Replikationsverkehr und Rebalance-Zeit. Daher wird die Anzahl auf den tatsächlich erwarteten Durchsatz dimensioniert und nicht spekulativ aufgebläht. Die Asymmetrie, die man verinnerlichen sollte, ist, dass man Partitionen in der Regel später hinzufügen kann, aber das Hinzufügen die Zuordnung von Schlüsseln zu Partitionen neu hashet und die Reihenfolgegarantie pro Schlüssel für in-flight-Schlüssel aufbricht. Für einen geordneten Feed dimensioniert man die Partitionen daher von vornherein und lässt sie dann in Ruhe.

IONOS CLOUD gibt eine konkrete Dimensionierungsregel, die die Partitionszahl an die Broker-Topologie des Clusters bindet. Jedes Event Streams for Apache Kafka-Cluster läuft mit drei Brokern, unabhängig von der Größenvorlage. Die Empfehlung lautet, dass die Anzahl der Partitionen gleich oder größer als die Anzahl der Broker sein sollte und dass man nur Vielfache der Broker-Anzahl (3, 6, 9, 12 und so weiter) verwenden sollte, um eine ungleichmäßige Verteilung der Partitionen über die Broker hinweg zu vermeiden. Eine ungleichmäßige Verteilung lässt einen Broker heißer laufen als die anderen und verschenkt die Kapazität, für die man bezahlt hat. Wenn hoher Durchsatz eine Priorität hat, empfiehlt die Dokumentation 2x oder 3x die Broker-Anzahl oder mehr. Für das Konto-Ereignis-Topic von FinCorp bedeutet das, mit 3 Partitionen zu starten und nur dann auf 6 oder 9 hochzustufen, wenn der gemessene Durchsatz es rechtfertigt, wobei man immer bei einem Vielfachen von drei bleibt.

Consumer Groups und Offsets sind der Mechanismus, mit dem dieses Design Neustarts übersteht und skaliert. Eine Consumer Group ist eine Menge von Consumern, die die Partitionen eines Topics kooperativ unter sich aufteilen. Kafka verfolgt pro Gruppe und pro Partition den Offset der letzten verarbeiteten Nachricht. Da der Offset an das Cluster zurückgemeldet wird, setzt ein Consumer, der abstürzt und neu startet, dort fort, wo die Gruppe aufgehört hat, und nicht von vorne. Das Hinzufügen eines Consumers zur Gruppe löst ein Rebalance aus, das die Partitionen neu verteilt. Deshalb kann FinCorp eine Consumer Group für die Echtzeit-Betrugserkennung und eine zweite, unabhängige Gruppe für das Analytics-Warehouse gegen dasselbe Topic betreiben: Jede Gruppe verwaltet ihre eigenen Offsets und liest den gesamten Stream in ihrem eigenen Tempo, ohne die andere zu blockieren.

2. Replikation und Aufbewahrung als Hebel für Kosten und Zuverlässigkeit

Zwei einstellbare Parameter auf Topic-Ebene wirken sich direkt auf Ihre Speicherrechnung und Ihre Ausfallsicherheit aus. Beide sind bewusste Entscheidungen und keine Standardwerte, die man blind akzeptieren sollte.

Der Replikationsfaktor gibt an, wie viele Kopien jeder Nachricht auf verschiedenen Brokern gespeichert werden. IONOS CLOUD empfiehlt einen Replikationsfaktor von 3. In einem Cluster mit drei Brokern bedeutet dies, dass jede Partition vollständig auf jedem Broker vorhanden ist. Dadurch übersteht das Topic den Ausfall von Brokern ohne Datenverlust, und die automatische Failover- und Replikationslogik des Clusters hält die Datenpipeline am Laufen. Die Kosten skalieren dabei multiplikativ: Bei einem Replikationsfaktor von 3 verbraucht ein Topic dreimal so viel Speicher wie das reine Nachrichtenvolumen. Die Dimensionierungsrichtlinie von IONOS CLOUD macht dies ausdrücklich deutlich und warnt, dass der tatsächliche Speicherverbrauch je nach konfiguriertem Replikationsfaktor das eingehende Datenvolumen um ein Vielfaches übersteigen kann. Ein niedrigerer Faktor spart Speicher, reduziert aber die Fehlertoleranz. Für die regulierten Transaktionsdaten von FinCorp ist 3 der angemessene Mindestwert.

Die Aufbewahrungszeit bestimmt, wie lange Nachrichten gespeichert werden, bevor sie gelöscht werden, und ist der zweite große Speicherhebel. Die Aufbewahrungszeit wird in Millisekunden festgelegt, standardmäßig 604800000 (7 Tage). Der Wert -1 bedeutet, dass keine zeitliche Begrenzung gilt. Ergänzend gibt es eine Aufbewahrungsgröße pro Segment in Bytes (die Größe, bei der ein Log-Segment neu aufgerollt wird; Standardwert 1073741824, also 1 GB, mit einem dokumentierten Mindestwert von 14 Bytes) sowie eine Obergrenze für die Gesamtgröße, die die ältesten Nachrichten löscht, sobald die Gesamtgröße des Topics erreicht ist. Die Dimensionierung des Clusters ist daher im Wesentlichen eine Berechnung der Aufbewahrungszeit. Die Dokumentation enthält ein konkretes Rechenbeispiel: Drei Topics, die jeweils sieben Tage lang 500 KB pro Sekunde aufbewahren, benötigen vor Berücksichtigung der Replikation mindestens rund 866 GB Gesamtspeicher. Die Clustervorlagen legen den verfügbaren Speicher fest:

Betrachten Sie diese Tabelle als Budget und nicht als Auswahl von Geschwindigkeitsstufen: Sie wählen die Größe anhand der Durchsatz- und Aufbewaltungsanforderungen Ihrer Topics und prüfen anschließend, ob der Gesamtspeicher des Clusters den Wert aus Rohdatenvolumen mal Replikationsfaktor über den gesamten Aufbewahrungszeitraum mit ausreichend Puffer übersteigt. Der Transaktionsdatenstrom von FinCorp mit sieben Tagen Aufbewahrung und Replikationsfaktor 3 überschreitet bereits bei moderaten Eingaberaten die Kapazität der S-Vorlage. M ist daher der realistische Ausgangspunkt mit ausreichend Spielraum für ein zweites Topic.

Ein Feinkostpunkt bei der Aufbewahrung, der sich der Erwähnung lohnt, da die Plattform ihn unterstützt: Kafka-Log-Kompaktierung behält nur den jeweils letzten Wert für einen bestimmten Schlüssel, anstatt Nachrichten nach Alter zu löschen. Dies eignet sich für Topics, die den aktuellen Zustand abbilden (zum Beispiel das jeweils aktuelle Kontoguthaben), nicht aber für eine Ereignishistorie. Es handelt sich um einen anderen Aufbewahrungsmodus als das Löschverfahren nach Zeit oder Größe. Greifen Sie nur dann darauf zurück, wenn das Topic tatsächlich einen schlüsselbasierten Zustand modelliert, und gehen Sie nicht davon aus, dass dieser Modus standardmäßig aktiviert ist.

3. Der Stream als Ersatz und Rückgrat

Hier zeigt sich, warum Event Streaming im nativen Substitutionsmodell der Plattform seinen Platz verdient. Die verwalteten Datenbanken von IONOS CLOUD bieten keinen Change-Data-Capture-Stream, auf den Sie sich abonnieren können, sodass Sie das Transaktionsprotokoll der Datenbank nicht nachverfolgen können, um nachgelagerte Verbraucher anzutreiben. Das native Muster besteht darin, die Abhängigkeit umzukehren: Statt die Datenbank nachträglich auf Änderungen zu durchsuchen, veröffentlicht die Anwendung im Moment der Änderung ein Domänenereignis in einem Kafka-Topic, und jedes nachgelagerte System (das Analyse-Datenwarehouse, das Betrugserkennungsmodell, ein Suchindex, ein Audit-Archiv) konsumiert dieses Topic. Der Stream wird zur Vertrauensquelle für die Änderungsausbreitung, die Datenbank wird zu einer weiteren projizierten Ansicht auf der Konsumentenseite, und FinCorp erhält den Fan-out, den ein CDC-Stream bereitgestellt hätte, ohne eine Funktion, die die Plattform nicht anbietet. Die Disziplin, die dies erfordert, besteht darin, das Schreiben in die Datenbank und die Veröffentlichung im Topic in der Anwendung als eine logische Operation zu behandeln, da die Plattform keine automatische Brücke zwischen beiden bietet.

Derselbe Stream bildet das Ingestions-Rückgrat in die KI-Ebene. Die Modelle von FinCorp rufen die transaktionale Datenbank nicht direkt ab; sie konsumieren die Ereignis-Topics, was den KI-Workloads einen entkoppelten, wiedergabefähigen Feed liefert, den sie bei jedem erneuten Training eines Modells ab einem festgelegten Offset erneut lesen können. Zwei Endpunkte schließen den Kreislauf ab, und beide stützen sich auf Object Storage. Erstens: Archivierung. Der Bulk-Export von Daten ist verfügbar, aber kein Self-Service-Verfahren; es handelt sich um einen Support-Ticket-Prozess (Vertragsnummer, Support-PIN und ein PGP-Schlüssel, woraufhin IONOS CLOUD ein verschlüsseltes Archiv in Ihren Object Storage-Bucket liefert). Daher wird der lange Schwanz von Ereignissen, der das aktive Aufbewahrungsfenster überschritten hat, erst nach dieser Anfrage in Object Storage exportiert. Eine kurze Cluster-Aufbewahrungsdauer ist nur dann ein tragfähiges Design, wenn der Archivierungszyklus diese manuelle Vorlaufzeit berücksichtigt. Zweitens: Der Dead-Letter-Schwanz. Nachrichten, die ein Verbraucher nicht verarbeiten kann, werden in ein separates Dead-Letter-Topic geroutet und, für eine dauerhafte forensische Aufbewahrung, in Object Storage geleert, wo Object Lock sie vor Manipulationen schützt. Die Broker bleiben für den Live-Verkehr schlank; der langsame, kostengünstige und unveränderliche Speicher nimmt das Archiv und die Fehlerfälle auf.

Die Sicherheit auf der Datenebene basiert auf mutual TLS, und das Modell ist streng. Die Kommunikation mit dem Cluster ist TLS-gesichert, wobei sich beide Seiten gegenseitig authentifizieren: Der Client validiert das Zertifikat des Clusters, und das Cluster validiert das Zertifikat des Clients. Da das Cluster keine öffentlich signierten Zertifikate verwendet, validieren Clients den Server anhand der eigenen Zertifizierungsstelle des Clusters, und das Cluster unterhält eine Client-CA, die das Zertifikat jedes authentifizierten Benutzers signiert. Jedes Zertifikat ist 365 Tage gültig, und ein erneuertes Zertifikat ist 30 Tage vor Ablauf über die API für Benutzerzertifikate zum Abruf verfügbar, was das Zeitfenster ist, auf das Ihr Rotations-Runbook abzielt. Die Management-API wird im Gegensatz dazu mit einem Bearer-Token authentifiziert und ist öffentlich über einen regionsspezifischen Endpunkt erreichbar (kafka.<region>.ionos.com). Nur das Kafka-Datenebenen-Protokoll auf den Brokern ist ausschließlich auf dem privaten LAN verfügbar, ohne öffentlichen Endpunkt. Daher ist die Sicherheitsgrenze für die Datenebene das private Netzwerk plus der mTLS-Handshake, während die Sicherheitsgrenze der Management-API die Bearer-Token-Kontrolle ist (IAM-Rechte mit begrenztem Geltungsbereich, Token-Handling und Rotation).

DCD-Implementierungsanleitung

Sie provisionieren einen Event Streams for Apache Kafka-Cluster mit drei Brokern im privaten Data-Tier-LAN von FinCorp und erstellen ein korrekt strukturiertes Topic für den account-event-Feed. Das Architekturziel ist das Ingestion-Backbone aus Abschnitt 3: ein privater, mTLS-gesicherter Stream, dimensioniert für ein Sieben-Tage-Retentionsfenster mit Replikationsfaktor 3, wobei die Partitionszahl sowohl die Reihenfolge als auch die Broker-Topologie berücksichtigt. Der Cluster hat keinen öffentlichen Endpunkt, daher erfolgt die gesamte Arbeit innerhalb des VDC, den Sie zuvor im Kurs erstellt haben.

Bauziel: Erstellen Sie einen Cluster und ein gut strukturiertes Topic.

Voraussetzungen: Ein provisioniertes virtuelles Rechenzentrum, das mindestens eine VM in einem privaten LAN enthält; diese VM greift über das private LAN auf den Cluster zu und zählt gegen Ihre Vertragsquote. Bestimmen Sie die IP-Adressen der Broker im Voraus: Sie müssen zum selben Subnetz gehören wie das ausgewählte LAN.

Schritte (im Data Center Designer):

1. Öffnen Sie den Bereich Event Streams for Apache Kafka und klicken Sie auf Cluster erstellen.
2. Setzen Sie Cluster Name auf einen eindeutigen, identifizierbaren Namen und wählen Sie die Kafka Version (Version 4.0.0 ist die unterstützte Version; 3.9.0 und 3.9.1 sind veraltet, und bestehende Cluster mit diesen Versionen laufen weiter).
3. Wählen Sie die Cluster Größe (XS bis XL) entsprechend Ihren Durchsatz- und Retentionsanforderungen. Für den Sieben-Tage-Feed von FinCorp mit Replikationsfaktor 3 dimensionieren Sie anhand der Speichertabelle in Abschnitt 2, statt zu raten; M ist der realistische Mindestwert.
4. Wählen Sie den Standort (Region) für den Cluster. Die Region bestimmt die geografische Platzierung, die Latenz und die regulatorische Datenhaltung, daher wählen Sie das deutsche Rechenzentrum für die regulierten Daten von FinCorp.
5. Wählen Sie das Rechenzentrum und das Rechenzentrum-LAN. Wählen Sie das private Data-Tier-LAN; der Cluster ist nur über dieses Netzwerk erreichbar.
6. Konfigurieren Sie die Broker-Adressen, die Clients zur Verbindung verwenden. Die IP-Adressen müssen zum selben Subnetz gehören wie das in der vorherigen Schritt ausgewählte LAN, damit die Routing innerhalb des Clusters funktioniert. Verwenden Sie den Subnetz-Hinweis im DCD-Bildschirm, um den Bereich zu bestätigen.
7. Prüfen Sie die für die Eingabe angezeigten geschätzten Kosten (eine Schätzung, die Variablen wie Traffic ausschließt) und klicken Sie dann auf Speichern, um zu deployen. Überwachen Sie den Fortschritt, bis der Cluster den Status Verfügbar erreicht.
8. Wenn der Cluster verfügbar ist, öffnen Sie ihn, wählen Sie den Tab Topics und klicken Sie auf Topic erstellen.
9. Setzen Sie im Dialogfeld Topic erstellen: Name; Replikationsfaktor (3 verwenden); Anzahl der Partitionen (ein Vielfaches der drei Broker: 3 zum Start, 6 oder 9, wenn der Durchsatz es erfordert); Retentionszeit (ms) (604800000 für sieben Tage, oder -1 für keine zeitliche Begrenzung); und Retentionssegmentgröße (B) (Standard 1073741824, mit einem Minimum von 14 Bytes). Klicken Sie auf Erstellen.

Um den Cluster anschließend zu verwenden, rufen Sie das benutzerbezogene Client-Zertifikat aus der API für Zugangsdaten ab und validieren Sie den Broker gegen die Cluster-CA; die API gibt das Zertifikat als PEM zurück, beispielsweise:

curl --location https://kafka.<region>.ionos.com/clusters/${clusterId}/users/${userId}/access \
  --header "Authorization: Bearer ${personalToken}" | yq -r '.metadata.certificate' > client-cert.pem

Dieser einzelne Aufruf veranschaulicht die architektonische Grenze, nicht ein Konfigurationslabor: Die Daten-Ebene verwendet mTLS, sodass ein Client ohne ein von einer CA signiertes Zertifikat keinerlei Verbindung herstellen kann. Der Zertifikatslebenszyklus (Gültigkeit von 365 Tagen, Erneuerung 30 Tage vor Ablauf möglich) ist eine operative Aufgabe, für die das Team verantwortlich ist.

Häufige Fehler:

• Festlegung einer Partitionanzahl, die kein Vielfaches der Brokeranzahl ist. Verwenden Sie Vielfache von drei (3, 6, 9, 12), damit die Partitionen gleichmäßig verteilt werden; eine ungleichmäßige Verteilung überlastet einen Broker und verschwendet bezahlte Kapazität.
• Die Annahme, dass die Partitionanzahl später angepasst werden kann. Das Hinzufügen von Partitionen führt zu einem erneuten Hashing der Schlüssel und bricht die Schlüsselreihenfolge für Schlüssel, die gerade verarbeitet werden. Dimensionieren Sie die Partitionen eines geordneten Feeds daher von Anfang an entsprechend.
• Unterschätzung der Clustergröße im Hinblick auf die Aufbewahrungsdauer. Multiplizieren Sie die Rohdateneingabe mit dem Aufbewahrungsfenster und anschließend mit dem Replikationsfaktor; der Fall mit 7 Tagen und Replikationsfaktor 3 kann das Rohvolumen um ein Vielfaches übersteigen, und wenn das Speicherlimit erreicht wird, werden die ältesten Nachrichten gelöscht.
• Auswahl der Broker-IP-Adressen außerhalb des Subnets des gewählten LANs. Diese müssen sich im selben Subnetz befinden, da die Broker sonst keine Route zu den Clients aufbauen können.
• Vergessen der Voraussetzung für ein privates LAN: Ein VDC mit einer VM auf einem privaten LAN muss zuvor existieren, und es gibt keinen öffentlichen Endpunkt. Daher sind Konnektivität und der mTLS-Zertifikatspfad der einzige Zugangsweg.
• Das Auslaufen von Client-Zertifikaten. Jedes ist 365 Tage gültig, wobei eine Erneuerung 30 Tage vor Ablauf möglich ist. Integrieren Sie die Abruf- und Rotationsprozesse in das Runbook.

Zusammenfassung

Die Architektur bestimmt die Form des Themas: Die Partitionszahl fixiert die Reihenfolge pro Schlüssel und begrenzt die Parallelität der Consumer-Gruppen. Auf IONOS CLOUD sollte sie ein Vielfaches der drei Broker sein. Der Replikationsfaktor (empfohlen: 3) und die Aufbewahrungsdauer (Standard: 7 Tage, -1 für unbegrenzt) sind die Hebel für Kosten und Zuverlässigkeit, die die Clustergröße bestimmen. Der Stream ist auch die native Antwort der Plattform auf zwei Lücken: Er ersetzt den fehlenden Datenbank-Change-Data-Capture-Stream durch ereignisbasierte Veröffentlichung auf Anwendungsebene und dient als wiederspielbare Ingestionsschiene in die KI-Ebene. Object Storage übernimmt das gealterte Archiv und den Dead-Letter-Endabschnitt. Der Aufbau besteht aus einem privaten, mit mTLS gesicherten Cluster im LAN der Daten-Ebene sowie einem einzelnen, gut geformten Thema, dessen Größe anhand der Speichertabelle und nicht durch Schätzungen bestimmt wird.

Wichtige Punkte:

• Eine Partition ist die Einheit sowohl der Reihenfolge (pro Schlüssel) als auch der Consumer-Parallelität (ein Consumer pro Partition pro Gruppe). Partitionen sollten als Vielfaches der drei Broker dimensioniert werden, insbesondere für geordnete Datenfeeds.
• Der Replikationsfaktor 3 ist der empfohlene Mindestwert für Dauerhaftigkeit und vervielfacht den Speicherbedarf ungefähr dreifach. Die Aufbewahrungszeit (Standard: 604800000 ms / 7 Tage, -1 für keine Begrenzung) und die Segmentgröße bestimmen den restlichen Speicherbedarf.
• Consumer-Gruppen verfolgen die bestätigten Offsets pro Partition. Unabhängige Gruppen lesen dasselbe Thema in ihrem eigenen Tempo und überstehen Neustarts, ohne Daten erneut verarbeiten zu müssen.
• Ereignisbasierte Veröffentlichung auf Anwendungsebene ist der native Ersatz für den fehlenden Datenbank-Change-Data-Capture-Stream. Dieselben Themen dienen als wiederspielbarer Datenfeed in die KI-Ebene.
• Object Storage dient als Archiv (über den Bulk-Data-Export) und als dauerhafter Dead-Letter-Endabschnitt. Die Broker bleiben für den Live-Verkehr schlank.
• Die Daten-Ebene nutzt gegenseitiges TLS (mTLS) mit der eigenen Zertifizierungsstelle des Clusters und Zertifikaten mit einer Gültigkeit von 365 Tagen (Erneuerung 30 Tage vor Ablauf). Die Management-API verwendet ein Bearer-Token. Das Cluster ist nur über das private LAN erreichbar.

Wichtige Begriffe:

• Partition: Die Einheit der Reihenfolge und Parallelität innerhalb eines Themas. Die Reihenfolge ist nur innerhalb einer Partition garantiert. Eine Consumer-Gruppe weist jede Partition höchstens einem Mitglied zu.
• Consumer-Gruppe: Eine Gruppe kooperierender Consumer, die die Partitionen eines Themas aufteilen und die bestätigten Offsets teilen. Dies ermöglicht paralleles, fortsetzbares und unabhängiges Konsumieren.
• Replikationsfaktor: Die Anzahl der auf den Brokern gespeicherten Kopien jeder Nachricht. Empfohlen wird 3. Dieser Faktor ist ein direkter Multiplikator für den Speicherbedarf.
• Aufbewahrungsdauer: Die Richtlinie (Zeit, Größe oder Log-Kompaktierung), die festlegt, wie lange Nachrichten gespeichert werden, bevor sie gelöscht oder kompaktiert werden.
• mTLS: Gegenseitiges TLS, bei dem Client und Cluster sich gegenseitig gegenüber der Zertifizierungsstelle des Clusters authentifizieren. Dies ist der einzige Zugangsweg zur privaten Daten-Ebene.

Weitere Lektüre

• Einheit 5.2: Object Storage (das Ziel für Archiv, Dead-Letter und Trainingskorpus)
• Einheit 5.3: Relationale Datenbanken (die Schreibseite, die Domänenereignisse veröffentlicht)
• Einheit 6.5: AI Inference - Managed Model Hub (der Verbraucher am Ende des Ingestion-Backbones)
• IONOS CLOUD Architecture Center