Wissensprüfung - Daten und Speicherung
Das Kundenportal von FinCorp bietet Ansichten für Kontozusammenfassungen und Transaktionsverläufe, die deutlich häufiger gelesen als geschrieben werden, und zwar alle von einem regulierten Managed PostgreSQL-Cluster auf der privaten Datenschicht. Ein Architekt schlägt vor, Read-Replikaten zu diesem Cluster hinzuzufügen und den Berichtsverkehr an einen Standby zu leiten. Warum ist dies der falsche Ausgangspunkt, und welches ist das native Muster?
Managed PostgreSQL-Standbys dienen der Hochverfügbarkeit, nicht der Verarbeitung von Leseverkehr. Es gibt weder Read-Replikaten noch einen verwalteten schreibgeschützten Endpunkt. Das native Muster ersetzt die fehlende Funktion durch eine In-Memory DB-Cacheschicht vor der relationalen Schicht (die Lesehälfte des Musters ohne Read-Replikaten) sowie durch den verwalteten pgbouncer-Pooler. Die Ablenkungsoptionen erfinden einen Modus, der Lese-Skalierung ermöglicht, missverstehen die Instanzanzahl und missbrauchen Snapshots, die kraschkonsistente Blockabbilder sind, keine datenbankkonsistente Quelle.
Ein Architekt plant die Datenkontinuität für das Portfolio von FinCorp, das migrierte VMs, Block Storage-Volumes, einen Managed PostgreSQL-Cluster und einen Managed MongoDB-Cluster umfasst. Ein Teammitglied schlägt einen einheitlichen Plan vor: den auf Acronis basierenden Backup Service-Agenten überall installieren, auch auf den Datenbank-Hosts, damit eine einzige Konsole das gesamte Portfolio abdeckt. Was ist der entscheidende Mangel?
Die wichtigste Grenze im Modul ist, dass der Backup Service verwaltete Datenbanken nicht sichert; die Datenbankkontinuität wird innerhalb jedes Datenbank-Dienstes über PITR und logisches Dump/Restore bereitgestellt. Die Ablenkungsoptionen sind faktisch falsch: Die Variante mit externem Agenten schützt On-Premises- und andere Cloud-VMs, der Backup Service bietet keine unveränderlichen Sicherungen (Unveränderlichkeit ist eine Object-Lock-Eigenschaft von Object Storage), und die Speicherklasse macht eine Datenbank nicht durch den Agenten sicherbar.
FinCorp muss sein mehrjähriges Audit-Archiv in Object Storage als manipulationsresistente, einmalige Aufbewahrung (write-once retention) vorhalten, die nicht einmal von einem Vertragsadministrator vor Ablauf des Aufbewahrungsdatums gekürzt oder gelöscht werden kann. Der Architekt richtet einen vertraglich verwalteten Bucket in einer deutschen Region ein, lädt die ersten Exporte hoch und versucht anschließend, Object Lock im COMPLIANCE-Modus zu aktivieren. In der Konsole ist keine Option zum Aktivieren vorhanden. Was ist schiefgelaufen, und wie lautet das korrekte Design?
Object Lock kann nur beim Erstellen des Buckets aktiviert werden und kann später nie nachträglich hinzugefügt werden. Die Aktivierung schaltet auch Versionierung ein, wobei weder Schritt rückgängig gemacht werden kann. Der COMPLIANCE-Modus macht das Objekt bis zu seinem Aufbewahrungsdatum unveränderlich, wobei die Frist von niemandem gekürzt werden kann. Die Ablenkungsoptionen verkehren das Verhältnis zur Versionierung, erfinden einen nur über die API verfügbaren Pfad, der nachträgliches Hinzufügen immer noch erlaubt, und erfinden ein GOVERNANCE-then-COMPLIANCE-Upgrade, das nicht existiert.
Der Transaktionsfeed mit hoher Datenmenge von FinCorp wird über Event Streams for Apache Kafka verarbeitet. Die Anforderung lautet, dass alle Ereignisse für ein bestimmtes Konto in der Reihenfolge verarbeitet werden, in der sie aufgetreten sind, während verschiedene Konten parallel verarbeitet werden und die Partitionen gleichmäßig auf die drei Broker des Clusters verteilt werden. Welches Topic-Design erfüllt alle drei Einschränkungen gleichzeitig?
Die Reihenfolge in Kafka gilt pro Partition. Wenn Sie die Kontenkennung als Schlüssel verwenden, werden die Ereignisse jedes Kontos auf einer Partition abgelegt, was eine strenge Reihenfolge pro Schlüssel bei gleichzeitiger Parallelität über Schlüssel hinweg gewährleistet. Die Partitionszahl ist auch die harte Obergrenze für die Consumer-Parallelität, und die Verwendung eines Vielfachen der drei Broker (3, 6, 9) hält die Verteilung gleichmäßig. Eine einzelne Partition serialisiert alle Konten und begrenzt die Parallelität auf einen Consumer. 5 ist kein Vielfaches von drei und verzichtet auf die Reihenfolge pro Konto. Die spekulative Aufblähung der Partitionen vervielfacht Datei-Handles, Replikationsverkehr und Rebalance-Zeit.
Die verwalteten Datenbanken von FinCorp stellen keinen Change-Data-Capture-Stream bereit, auf den nachgelagerte Systeme zugreifen können. Dennoch müssen das Analytik-Data-Warehouse, das Betrugserkennungsmodell und ein Suchindex auf jede Änderung reagieren. Die Architektur muss es zudem der KI-Ebene ermöglichen, die Änderungschronik ab einer festgelegten Position erneut zu lesen, wenn ein Modell neu trainiert wird. Welcher Ansatz ist das native Äquivalent auf IONOS CLOUD?
Da die verwalteten Datenbanken von IONOS CLOUD keinen abonnierbaren Change-Data-Capture-Stream bereitstellen, kehrt das native Muster die Abhängigkeit um: Die Application veröffentlicht ein Domänenereignis in Kafka, während sie die Änderung vornimmt, und jedes nachgelagerte System konsumiert dieses Topic. Dabei verfolgen Consumer-Gruppen ihre eigenen Offsets, sodass die KI-Ebene von einer festgelegten Position aus neu abspielen kann. Das Ablesen des WAL ist kein unterstützter abonnierbarer Strom, das Vergleichen von Dumps ist langsam und verlustbehaftet, und MongoDB bietet keine verwaltete Change-Stream-Replikation zu einem zweiten Cluster.
FinCorp benötigt eine manipulationssichere, langfristig aufbewahrte Kopie seiner Managed PostgreSQL-Daten, die außerhalb des Clusters überdauert und über Jahre hinweg aufbewahrt werden kann, getrennt vom eigenen 7-Tage-Punkt-in-Zeit-Wiederherstellungsfenster des Clusters. Welche Konfiguration erfüllt dies, während die Grenzen der Plattform respektiert werden?
PITR ist an ein Zeitfenster gebunden und an den eigenen Sicherungsspeicher des Clusters gekoppelt. Die portierbare, langfristig aufbewahrte Kopie stammt daher aus einem logischen Dump (pg_dump), der in Object Storage ausgeliefert wird, wo Object Lock im COMPLIANCE-Modus die Manipulationssicherheit bereitstellt, die der Datenbankdienst selbst nicht bietet. Die Erweiterung von PITR hält die Kopie nicht portierbar und an das Cluster gebunden. Snapshots sind absturzkonsistente Blockabbilder und keine datenbankkonsistenten Sicherungen. Der Backup Service sichert verwaltete Datenbanken überhaupt nicht.