Einheit 5.6: Ereignis-Streaming (Verwaltetes Kafka)

Einführung

Die tragende Entscheidung beim Event-Streaming ist nicht die Bereitstellung des Cluster, sondern die Form des Themas. Die Partitionierungsanzahl legt sowohl die Reihenfolgegarantie als auch die Obergrenze für die parallele Verarbeitung durch den Verbraucher für die Lebensdauer dieses Themas fest, und der Replikationsfaktor und die Aufbewahrungsfrist entscheiden gemeinsam, wie viel Sie zahlen, um Daten sicher zu halten und für wie lange. Wenn Sie die Form des Themas richtig gestalten, ist das Cluster fast nebensächlich. Wenn Sie es falsch machen, entdecken Sie die Grenze in der Produktion, wo Partitionen nicht reduziert werden können und eine Neugestaltung ein neues Thema und eine Migration bedeutet.

Diese Einheit behandelt Event Streams for Apache Kafka als das Streaming-Backbone für FinCorp, das deutsche Finanzdienstleistungsunternehmen, das GDPR und BSI-Verpflichtungen durch seine Migration und seine neue KI-Fähigkeit trägt. Wir beginnen bei der Themen-Design-Entscheidung, erklären, wie Partitionen, Verbrauchergruppen, Replikation und Aufbewahrungsfrist interagieren, zeigen, wo der Stream in der breiteren Architektur sitzt, und bauen dann ein Cluster und ein korrekt geformtes Thema in dem Data Center Designer.

1. Das Thema ist die Architektur: Partitionen, Reihenfolge und Parallelismus

Eine Partition ist die Einheit sowohl der Reihenfolge als auch des Parallelismus, und diese beiden Eigenschaften ziehen in die gleiche Richtung, was die Partitionenzahl zur wichtigsten Entscheidung macht. Kafka hält die Reihenfolge der Nachrichten innerhalb einer Partition auf; es macht keine Reihenfolgeversprechen über Partitionen hinweg. Wenn also FinCorp alle Ereignisse für ein bestimmtes Konto in der Reihenfolge verarbeiten muss, in der sie aufgetreten sind, muss jedes Ereignis für dieses Konto auf der gleichen Partition landen. Die Standardmethode, um dies zu gewährleisten, besteht darin, einen Partitionsschlüssel (den Kontoidentifikator) festzulegen, sodass der Producer ihn zu einer festen Partition hashen kann. Die Reihenfolge ist daher eine Eigenschaft pro Schlüssel und nicht pro Thema: Sie erhalten eine strikte Reihenfolge innerhalb jedes Schlüssels und Konkurrenz zwischen Schlüsseln, was genau das ist, was ein Hoch-Volume-Transaktionsfeed möchte.

Parallelismus ist die andere Seite der gleichen Medaille. Innerhalb einer Consumer-Gruppe wird eine Partition von höchstens einem Mitglied gleichzeitig verbraucht, sodass die Partitionenzahl die harte Obergrenze dafür ist, wie viele Consumer dieses Thema parallel bearbeiten können. Drei Partitionen bedeuten höchstens drei aktive Consumer; ein vierter bleibt inaktiv. Mehr Partitionen ermöglichen eine bessere Lastverteilung zwischen den Consumern und verbessern die Durchsatzrate, aber sie multiplizieren auch offene Dateihandler, Replikationsverkehr und Umbilanzierungszeit, sodass die Anzahl an Partitionen auf den tatsächlich erwarteten Durchsatz und nicht spekulativ aufgebläht wird. Die Asymmetrie, die man internalisieren muss, ist, dass man normalerweise Partitionen später hinzufügen kann, aber das Hinzufügen von Partitionen die Schlüssel-zu-Partition-Zuordnung neu hashen und die pro-Schlüssel-Reihenfolgegarantie für in Flug befindliche Schlüssel brechen würde, sodass man für einen geordneten Feed die Partitionen von vorneherein dimensioniert und sie unverändert lässt.

IONOS gibt eine konkrete Größenschätzung, die die Partitionenzahl an die Broker-Topologie des Cluster bindet. Jeder Event Streams for Apache Kafka Cluster läuft drei Broker unabhängig vom Größenvorlagewert. Die Richtlinie besagt, dass die Anzahl der Partitionen gleich oder größer als die Anzahl der Broker sein sollte und dass man nur Vielfache der Brokeranzahl (3, 6, 9, 12 und so weiter) verwenden sollte, um eine ungleichmäßige Verteilung von Partitionen über die Broker zu vermeiden. Eine ungleichmäßige Verteilung lässt einen Broker heißer als die anderen werden und verschwendet die Kapazität, die man bezahlt hat. Wenn ein hoher Durchsatz Priorität hat, schlägt die Dokumentation vor, 2x oder 3x die Brokeranzahl oder mehr zu verwenden. Für das account-event-Thema von FinCorp bedeutet das, bei 3 Partitionen zu beginnen und nur dann auf 6 oder 9 zu steigern, wenn der gemessene Durchsatz dies rechtfertigt, und immer auf einem Vielfachen von drei zu bleiben.

Consumer-Gruppen und Offsets sind es, die dieses Design über Neustarts hinweg überleben und skaliert werden. Eine Consumer-Gruppe ist eine Menge von Consumern, die kooperativ die Partitionen eines Themas unter sich aufteilen; Kafka verfolgt pro Gruppe und pro Partition den Offset der zuletzt verarbeiteten Nachricht. Da der Offset an den Cluster zurückgemeldet wird, kann ein Consumer, der abstürzt und neu startet, von dem Punkt aus weitermachen, an dem die Gruppe aufgehört hat, anstatt von Anfang an, und das Hinzufügen eines Consumers zur Gruppe löst eine Umbilanzierung aus, die die Partitionen neu verteilt. Deshalb kann FinCorp eine Consumer-Gruppe für die Echtzeit-Betrugsbewertung und eine zweite, unabhängige Gruppe für das Analyse-Warehouse gegen das gleiche Thema durchführen: Jede Gruppe behält ihre eigenen Offsets und liest den gesamten Datenstrom in ihrem eigenen Tempo, und keine blockiert die andere.

2. Replikation und Aufbewahrung als Kosten- und Zuverlässigkeitshebel

Zwei themenbezogene Einstellungen wirken sich direkt auf Ihre Speicherrechnung und Ihre Ausfallsicherheit aus, und beide sind Entscheidungen, die nicht blindlings akzeptiert werden sollten.

Der Replikationsfaktor ist die Anzahl der Kopien jeder Nachricht, die auf verschiedenen Brokern gespeichert werden. IONOS empfiehlt einen Replikationsfaktor von 3, was bei einem drei-Broker-Cluster bedeutet, dass eine vollständige Kopie der Partition auf jedem Broker gespeichert wird, sodass das Thema auch nach dem Verlust von Brokern ohne Datenverlust überlebt und die automatische Failover- und Replikationsfunktion des Cluster den Datenfluss aufrechterhält. Die Kosten sind multiplikativ: Bei einem Replikationsfaktor von 3 beträgt der Speicherplatz, den ein Thema verbraucht, das Dreifache seines rohen NachrichtenVolume. Der IONOS-Größenschätzberechnung macht dies explizit, indem sie warnt, dass der endgültige Speicherplatzverbrauch je nach konfiguriertem Replikationsfaktor mehrmals so groß sein kann wie der eingehende DatenVolume. Ein niedrigerer Faktor spart Speicherplatz, aber opfert die Fehlertoleranz; für FinCorps regulierte Transaktionsdaten ist 3 der richtige Mindestwert.

Die Aufbewahrungsfrist legt fest, wie lange Nachrichten vor ihrer Löschung aufbewahrt werden, und ist der andere große Speicherhebel. Die Aufbewahrungsfrist wird in Millisekunden angegeben, beträgt standardmäßig 604800000 (7 Tage) und ein Wert von -1 bedeutet, dass keine Zeitbegrenzung besteht. Es gibt eine Begleitaufbewahrungssegmentgröße in Bytes (die Größe, bei der ein Log-Segment gerollt wird, standardmäßig 1073741824, was 1 GB entspricht, mit einem dokumentierten Mindestwert von 14 Bytes) und eine Aufbewahrungsgrenze, die die ältesten Nachrichten löscht, sobald die Gesamtgröße des Themas erreicht ist. Die Größenschätzung des Cluster ist daher ein Aufbewahrungsrechenproblem. Die Dokumentation enthält ein Beispiel: Drei Themen, die jeweils sieben Tage bei 500 KB pro Sekunde aufbewahren, benötigen mindestens etwa 866 GB Speicherplatz, bevor die Replikation überhaupt berücksichtigt wird. Die Cluster-Vorlagen legen den Speicherplatz fest, den Sie erhalten:

Lesen Sie diese Tabelle als Budget und nicht als Menü von Geschwindigkeitsstufen: Sie wählen die Größe basierend auf dem Durchsatz und der Aufbewahrungsfrist, die Ihre Themen erfordern, und überprüfen dann, ob der Gesamtspeicher des Cluster den rohen Volume-Wert komfortabel übertrifft, multipliziert mit dem Replikationsfaktor über die Aufbewahrungsfrist. FinCorps siebentägige, replikationsfaktor-3-Transaktionsfeed bringt es über die S-Vorlage hinaus, selbst bei moderaten Ingest-Raten, sodass M der realistische Ausgangspunkt mit Spielraum für ein zweites Thema ist.

Eine Aufbewahrungsnuance, die erwähnenswert ist, weil die Plattform sie unterstützt: Die Kafka-Log-Kompaktion behält nur den neuesten Wert für einen bestimmten Schlüssel und löscht nicht nach Alter, was für ein Thema geeignet ist, das den aktuellen Zustand (den neuesten Kontostand, sagen wir) und nicht die Ereignisgeschichte darstellt. Es handelt sich um einen anderen Aufbewahrungsmodus als die zeit- oder größenbasierte Löschung; verwenden Sie ihn nur, wenn das Thema tatsächlich den Zustand mit Schlüssel modelliert, und nehmen Sie nicht an, dass es standardmäßig aktiviert ist.

3. Der Stream als Ersatz und Rückgrat

Hier verdient das Event-Streaming seinen Platz im nativen Substitutionsmodell der Plattform. Die von IONOS gemanagten Datenbanken bieten keinen Change-Data-Capture-Stream, den Sie abonnieren können, sodass Sie den Datenbanktransaktionslog nicht für die Antriebskraft von Downstream-Verbrauchern verwenden können. Das native Muster ist, die Abhängigkeit umzukehren: Anstatt die Datenbank nachträglich auf Änderungen zu untersuchen, veröffentlicht die Anwendung ein Domänenereignis in einem Kafka-Thema im Moment, in dem sie die Änderung vornimmt, und jedes Downstream-System (das Analyse-Warenhaus, das Betrugsmodell, ein Suchindex, ein Prüfarchiv) verbraucht dieses Thema. Der Stream wird zur Quelle der Wahrheit für die Änderungsverbreitung, die Datenbank wird zu einer weiteren Verbraucher-Seitenprojektion, und FinCorp erhält die Fan-out, die ein CDC-Stream ihr gegeben hätte, ohne eine Funktion, die die Plattform nicht anbietet. Die Disziplin, die dies erfordert, besteht darin, dass der Schreibvorgang in die Datenbank und die Veröffentlichung in das Thema als eine logische Operation in der Anwendung behandelt werden, da die Plattform keine automatische Brücke zwischen ihnen bietet.

Der gleiche Stream ist das Einlass-Rückgrat in die KI-Ebene. Die Modelle von FinCorp rufen die transaktionale Datenbank nicht direkt auf; sie verbrauchen die Ereignisthemen, was den KI-Workloads eine entkoppelte, wiederaufnehmbare Zufuhr gibt, die sie von einem festgelegten Offset aus neu lesen können, wenn ein Modell neu trainiert wird. Zwei Endpunkte schließen den Kreis und beide stützen sich auf Object Storage. Erstens, Archiv: Eine Bulk-Datenausfuhr ist verfügbar, aber nicht selbstbedienend, es ist ein Support-Ticket-Prozess (Vertragsnummer, Support-PIN und ein PGP-Schlüssel, nach dem IONOS ein verschlüsseltes Archiv in Ihren Object Storage-Bucket liefert), sodass der lange Schwanz von Ereignissen, der über das heiße Aufbewahrungsfenster hinausgegangen ist, nur nach dieser Anfrage in Object Storage exportiert wird, und eine kurze Cluster-Aufbewahrungsfrist ist nur dann ein tragbares Design, wenn die Archiv-Periodik die manuelle Vorlaufzeit berücksichtigt. Zweitens, der Dead-Letter-Schwanz: Nachrichten, die ein Verbraucher nicht verarbeiten kann, werden an ein separates Dead-Letter-Thema weitergeleitet und für eine dauerhafte forensische Aufbewahrung in Object Storage entleert, wo Object Lock sie manipulationsfest macht. Die Broker bleiben für den Live-Verkehr schlank; der langsame, billige, unveränderliche Speicher absorbiert das Archiv und die Fehler.

Die Sicherheit auf der Daten-Ebene ist eine gegenseitige TLS, und das Modell ist streng. Die Kommunikation mit dem Cluster ist TLS-gesichert, wobei beide Seiten authentifizieren: Der Client überprüft das Zertifikat des Cluster, und das Cluster überprüft das Zertifikat des Clients. Da das Cluster keine öffentlich signierten Zertifikate verwendet, überprüfen die Clients den Server gegen die eigene Zertifizierungsstelle des Cluster, 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 wird 30 Tage vor Ablauf für die Abholung aus dem Benutzer-Anmeldeinformationen-API verfügbar, was das Ziel Ihrer Rotations-Runbook ist. Die Verwaltungs-API hingegen wird mit einem Bearer-Token authentifiziert und ist öffentlich über einen pro-Region-Endpunkt (Kafka.<Region>.ionos.com) erreichbar; nur das Kafka-Daten-Flug-Protokoll auf den Brokern ist privat-LAN-nur mit keinem öffentlichen Endpunkt, sodass die Sicherheitsperimeter für die Daten-Ebene das private Netzwerk plus die mTLS-Handshake sind, während die Verwaltungs-API-Perimeter die Bearer-Token-Kontrolle (eingeschränktes IAM-Privileg, Token-Handling und Rotation) ist.

DCD Implementierung Schritt-für-Schritt

Sie werden einen drei-Broker-Event Streams for Apache Kafka Cluster auf FinCorps privatem Daten-Tier-LAN bereitstellen und ein korrekt geformtes Thema für die Account-Event-Feed erstellen. Das Architekturziel ist die Ingestion-Spine aus Abschnitt 3: ein privater, mTLS-gesicherter Stream, der für ein siebentägiges, Replikationsfaktor-3-Retentionsfenster dimensioniert ist, mit einer Partition-Anzahl, die sowohl die Reihenfolge als auch die Broker-Topologie berücksichtigt. Der Cluster hat keinen öffentlichen Endpunkt, daher findet die Arbeit vollständig innerhalb des virtuellen Rechenzentrums statt, das Sie zuvor im Kurs erstellt haben.

Ziel: Erstellen Sie einen Cluster und ein gut geformtes Thema.

Voraussetzungen: Ein bereitgestelltes virtuelles Rechenzentrum, das mindestens einen VM in einem privaten LAN enthält; dieser VM greift auf den Cluster über den privaten LAN zu und wird auf Ihr Vertragskontingent angerechnet. Legen Sie die Broker-IP-Adressen im Voraus fest: Sie müssen zur gleichen Subnetz wie der LAN gehören, den Sie auswählen.

Schritte (im Data Center Designer):

1. Öffnen Sie den Event Streams for Apache Kafka-Abschnitt und klicken Sie auf Cluster erstellen.
2. Setzen Sie Cluster-Name auf einen eindeutigen, identifizierbaren Namen, und wählen Sie Kafka-Version (Version 4.0.0 ist die unterstützte Version; 3.9.0 und 3.9.1 sind veraltet, und bestehende Cluster auf diesen Versionen bleiben weiterhin aktiv).
3. Wählen Sie die Cluster-Größe (XS bis XL) basierend auf Ihren Durchsatz- und Retentionsanforderungen. Für FinCorps siebentägigen, Replikationsfaktor-3-Feed sollten Sie die Größe aus der Speichertabelle in Abschnitt 2 ableiten, anstatt zu raten; M ist der realistische Boden.
4. Wählen Sie den Standort (Region) für den Cluster. Die Region legt die geografische Platzierung, Latenz und regulatorische Residenz fest, also wählen Sie das deutsche Rechenzentrum für FinCorps regulierte Daten.
5. Wählen Sie das Rechenzentrum und das Rechenzentrum-LAN. Wählen Sie das private Daten-Tier-LAN; der Cluster ist nur über dieses Netzwerk erreichbar.
6. Konfigurieren Sie die Broker-Adressen, die Clients verwenden, um eine Verbindung herzustellen. Die IP-Adressen müssen zur gleichen Subnetz wie der LAN gehören, den Sie im vorherigen Schritt ausgewählt haben, damit die Routing innerhalb des Cluster funktioniert. Verwenden Sie den DCD-Bildschirm-Hinweis, um den Bereich zu bestätigen.
7. Überprüfen Sie die geschätzten Kosten, die für die Eingabe angezeigt werden (eine Schätzung, die Variablen wie Datenverkehr ausschließt), und klicken Sie dann auf Speichern, um den Cluster bereitzustellen. Überwachen Sie den Fortschritt, bis der Cluster den Verfügbar-Zustand erreicht.
8. Wenn der Cluster verfügbar ist, öffnen Sie ihn, wählen Sie die Themen-Registerkarte und klicken Sie auf Thema erstellen.
9. Im Erstellen-Thema-Dialog setzen Sie: Name; Replikationsfaktor (verwenden Sie 3); Anzahl der Partitionen (ein Vielfaches der drei Broker: 3 zum Starten, 6 oder 9, wenn der Durchsatz es erfordert); Aufbewahrungszeit (ms) (604800000 für sieben Tage oder -1 für keine Zeitbegrenzung); und Aufbewahrungssegmentgröße (B) (Standard 1073741824, mit einem Minimum von 14 Bytes). Klicken Sie auf Erstellen.

Um den Cluster später zu verwenden, rufen Sie das pro-Benutzer-Client-Zertifikat aus den Anmeldeinformationen API ab und validieren den Broker gegen das Cluster-CA; das API gibt das Zertifikat als PEM zurück, zum Beispiel:

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 ist mTLS, sodass ein Client ohne ein CA-signiertes Zertifikat überhaupt nicht verbinden kann, und der Zertifikatslebenszyklus (365-Tage-Gültigkeit, Verlängerung verfügbar 30 Tage im Voraus) ist eine operative Aufgabe, die das Team besitzt.

Häufige Fehler:

• Festlegung einer Partition-Anzahl, die kein Vielfaches der Broker-Anzahl 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.
• Behandlung der Partition-Anzahl als später anpassbar. Das Hinzufügen von Partitionen neu hashet Schlüssel und bricht die pro-Schlüssel-Reihenfolge für Schlüssel in der Luft, sodass eine geordnete Feed-Partition von vornherein dimensioniert werden muss.
• Unterschätzung des Cluster gegenüber der Aufbewahrung. Multiplizieren Sie die rohe Eingabe mit dem Aufbewahrungszeitfenster und dann mit dem Replikationsfaktor; der Fall mit 7 Tagen und Replikationsfaktor 3 kann mehrmals so groß sein wie die rohe Volume, und sobald die Speicherbegrenzung erreicht ist, werden die ältesten Nachrichten gelöscht.
• Auswahl der Broker-IP-Adressen außerhalb des ausgewählten LAN-Subnetzes. Sie müssen im gleichen Subnetz sein, oder die Broker können nicht zu den Clients routen.
• Vergessen der privaten-LAN-Voraussetzung: Ein VDC mit einem VM auf einem privaten LAN muss bereits existieren, und es gibt keinen öffentlichen Endpunkt, sodass die Konnektivität und der mTLS-Zertifikatspfad die einzigen Möglichkeiten sind, um Zugriff zu erhalten.
• Lassen Sie die Client-Zertifikate ablaufen. Jedes ist 365 Tage gültig, mit einer Verlängerung, die 30 Tage vor Ablauf verfügbar ist; integrieren Sie die Abrufung und Rotation in das Runbook.

Zusammenfassung

Die Form des Themas ist die Architektur: Die Anzahl der Partitionen legt die Reihenfolge pro Schlüssel fest und begrenzt die Parallelität der Consumer-Gruppen, und bei IONOS sollte sie ein Vielfaches der drei Broker sein; der Replikationsfaktor (empfohlen 3) und die Aufbewahrungsfrist (Standard 7 Tage, -1 für unbegrenzt) sind die Kosten- und Zuverlässigkeitshebel, die die Größe des Cluster bestimmen. Der Stream ist auch die native Antwort der Plattform auf zwei Lücken, indem er als Datenbank-Änderungsdaten-Erfassungs-Stream durch Anwendungsebene-Event-Veröffentlichung dient und als wiedergabefähige Aufnahme in die AI-Ebene fungiert, wobei Object Storage das archivierte Alter und den toten Brief trägt. Der Build ist ein privater, mTLS-gesicherter Cluster auf der Daten-Ebene LAN plus ein einzelnes gut geformtes Thema, das aus der Speichertabelle und nicht durch Ratenwerk bestimmt wird.

Wichtige Punkte:

• Eine Partition ist die Einheit der Reihenfolge (pro Schlüssel) und der Consumer-Parallelität (ein Consumer pro Partition pro Gruppe); Partitionen sollten als Vielfaches der drei Broker und im Voraus für geordnete Feeds dimensioniert werden.
• Der Replikationsfaktor 3 ist die empfohlene Dauerhaftigkeitsuntergrenze und multipliziert den Speicherplatz ungefähr dreifach; die Aufbewahrungszeit (Standard 604800000 ms / 7 Tage, -1 für keine Begrenzung) und die Segmentgröße bestimmen die REST der Speicherrechnung.
• Consumer-Gruppen verfolgen die committeten Offsets pro Partition, so dass unabhängige Gruppen das gleiche Thema in ihrem eigenen Tempo lesen und Neustarts ohne erneute Verarbeitung überstehen.
• Anwendungsebene-Event-Veröffentlichung ist die native Substitute für den fehlenden Datenbank-Änderungsdaten-Erfassungs-Stream, und die gleichen Themen sind die wiedergabefähige Aufnahme in die AI-Ebene.
• Object Storage ist das Archiv (über Massendatenexport) und der dauerhafte tote Brief; die Broker bleiben für den Live-Datenverkehr schlank.
• Die Daten-Ebene ist mutual TLS gegen die Cluster-eigene Zertifizierungsstelle mit 365-Tages-Zertifikaten (Erneuerung 30 Tage im Voraus); die Verwaltungs-API verwendet ein Bearer-Token; die Cluster ist privat-LAN nur.

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 jedem Partition höchstens ein Mitglied zu.
• Consumer-Gruppe: Eine Menge kooperierender Consumer, die die Partitionen eines Themas aufteilen und committete Offsets teilen, um parallele, wiederholbare, unabhängige Konsumation zu ermöglichen.
• Replikationsfaktor: Die Anzahl der broker-residenten Kopien jeder Nachricht; empfohlen 3, und ein direkter Multiplikator auf den Speicherbedarf.
• Aufbewahrungsfrist: Die Richtlinie (Zeit, Größe oder Log-Kompaktion) zur Regelung, wie lange Nachrichten vor dem Löschen oder Kompaktieren aufbewahrt werden.
• mTLS: Mutual TLS, bei dem Client und Cluster sich gegenseitig gegen die Cluster-Zertifizierungsstelle authentifizieren; der einzige Pfad auf die private Daten-Ebene.

Weitere Lektüre

• Einheit 5.2: Object Storage (das Archiv, der Dead-Letter- und der Training-Corpus-Zielort)
• Einheit 5.3: Relationale Datenbanken (die Schreibseite, die Domänenereignisse veröffentlicht)
• Einheit 6.5: KI-Schlussfolgerung - Gemanagtes Modell-Hub (der Verbraucher am Ende des Ingestions-Rückgrats)
• IONOS Cloud Architekturzentrum