Migrierte MongoDB-Workload für Oracle Autonomous Transaction Processing Serverless bereitstellen

Migrieren Sie eine vorhandene Workload, die eine Dokumentdatenbank, in diesem Fall MongoDB, verwendet, in die Oracle Autonomous Transaction Processing Serverless-(ATP Serverless-)Datenbank auf Oracle Cloud Infrastructure (OCI), um die Entwicklung Ihrer JSON-zentrierten Anwendungen neben anderen Workloads mit mehreren Modellen zu modernisieren.

Workloads und Anwendungen, die Dokumente und Dokumentdatenbanken verwenden, um Datenschemas und Anwendungen zu entwickeln, sind aufgrund der Flexibilität, die sie Entwicklern bieten, beliebt. Die Flexibilität des Schemas, die schnelle Entwicklung und die Skalierbarkeit ermöglichen ein beschleunigtes Prototyping von Anwendungsfunktionen, eine einfachere Anwendungsentwicklung und die Möglichkeit, iterativ kleinere Anwendungen und Funktionen zu erstellen, die Entwickler skalieren können, um eine große Benutzerbasis zu erreichen. Diese Arten von Workloads haben jedoch ihre Herausforderungen, darunter schwächere Transaktionsgarantien, Vielseitigkeit der Datenabfrage und die Unfähigkeit, andere Workloads in Dokumenten wie Analysen oder maschinelles Lernen zu unterstützen.

Was ist, wenn diese Workloads von den Vorteilen herkömmlicher Dokumentendatenbanken profitieren und die Vorteile relationaler Datenbanken nutzen können? Sie verfügen beispielsweise über stärkere Transaktionsgarantien und zusätzliche Funktionen wie Analysen und maschinelles Lernen, ohne dass Daten in eine andere Datenbank oder ein anderes System repliziert werden müssen.

Autonomous Transaction Processing Serverless ist ein vollständig automatisierter Datenbankservice, der für die gleichzeitige Ausführung von Transaktions-, Analyse- und Batch-Workloads optimiert ist. Um die Performance zu beschleunigen, ist es für Zeilenformat, Indizes und Daten-Caching vorkonfiguriert und bietet gleichzeitig Skalierbarkeit, Verfügbarkeit, transparente Sicherheit und Betriebsanalysen in Echtzeit. Anwendungsentwickler und DBAs können Anwendungen schnell und kostengünstig entwickeln und bereitstellen, ohne dabei auf Funktionalität oder Atomizität, Konsistenz, Isolation und Dauerhaftigkeit (ACID) verzichten zu müssen.

Funktionale Architektur

Diese Referenzarchitektur setzt voraus, dass Sie eine Workload mit einer Anwendung und einer MongoDB-Datenbank haben, entweder On-Premises oder in der Cloud, und zu OCI migrieren. Es beschreibt die zukünftige Statusarchitektur, ihre Vorteile, wie Sie sie bereitstellen können und welche zusätzlichen Funktionen Sie verwenden können, um die vorhandene Workload zu erweitern.

Diese Referenzarchitektur konzentriert sich auf das Deployment der migrierten Workload und nicht auf den Migrationsprozess selbst. Weitere Informationen zum Migrationsprozess finden Sie im Abschnitt Weitere Informationen.

Eines der wichtigsten Produkte, die in dieser Architektur verwendet werden, ist die Oracle Database-API für MongoDB, mit der Anwendungen mit Sammlungen von JSON-Dokumenten in Oracle Database mit MongoDB-Treibern, -Tools und -SDKs interagieren können. Dadurch kann vorhandener Anwendungscode mit Daten arbeiten, die in Autonomous Transaction Processing Serverless (ATP Serverless) gespeichert sind, ohne dass der Code neu berechnet werden muss.

Das folgende Diagramm zeigt eine typische Anwendung, die aus einer Datenbank-, Backend- und Frontend-Tier besteht.



mongodb-atp-s-logical-arch-migration-oracle.zip

Der MEAN-Stack ist ein beliebter Stack, mit dem dieses Muster implementiert wird:
  • MongoDB: Dokumentdatenbank
  • Express: Backend-Framework
  • Winkel: Frontend-Rahmen
  • Node.js: Backend-Server

In diesem Beispiel wird ein MEAN-Stack verwendet, um ein vorhandenes Deployment zu OCI und ATP Serverless zu migrieren.

Die Migration dieser Workload zu OCI und ATP Serverless ist unkompliziert und umfasst auf hoher Ebene die folgenden Schritte:

  1. Stellen Sie eine ATP Serverless-Instanz bereit, um die Oracle Database Mongo DB-API beim Erstellen zu aktivieren.
  2. Migrieren Sie Metadaten und Daten von MongoDB zu ATP Serverless.
  3. Stellen Sie Anwendungsserver bereit, um Node.js und Express mit VMs, Containern oder Kubernetes in derselben Region und Availability-Domain wie ATP Serverless auszuführen.
  4. Stellen Sie den Backend-Anwendungscode auf den Anwendungsservern bereit.
  5. Verbinden Sie die Backend-Anwendung mit ATP Serverless, indem Sie dieselben MongoDB-Tools und -Treiber verwenden, die in der aktuellen Anwendung verwendet werden.
  6. Verbinden Sie Benutzer mit der neuen Anwendungs-URI.

Nachdem die Workload zu ATP Serverless migriert wurde, stehen mehrere Funktionen zur Verfügung, um die vorhandene Funktionalität zu erweitern, unabhängig davon, ob dies auf 1) zusätzliche nicht funktionale Anforderungen wie einfache Verbesserung der Skalierbarkeit, Resilienz oder High Availability oder 2) zusätzliche funktionale Funktionen wie Betriebsberichte, Analysen und maschinelles Lernen unterstützen, ohne Daten aus der Datenbank kopieren zu müssen.

Um die Skalierbarkeit und High Availability zu verbessern, verwenden Sie das Autoscaling-Feature von Autonomous Transaction Processing Serverless. Mit einem einzigen Klick oder API-Aufruf kann die Workload bis zum 3-fachen der Basiskapazität ohne Ausfallzeiten nutzen. Beachten Sie, dass Autonomous Transaction Processing Serverless Oracle Real Application Clusters-(Oracle RAC-)Technologie für High Availability verwendet. Verwenden Sie für die Backend-Tier Compute-Instanzpools mit Autoscaling-Regeln, um High Availability und Skalierbarkeit für Anwendungen zu ermöglichen.

Da Autonomous Transaction Processing Serverless auf Multi-Modell-, Multi-Workload-Datenbanktechnologie basiert, können Sie Funktionen hinzufügen, die auf relationalen, räumlichen, Diagramm- oder Vektordatentypen basieren, die neben der vorhandenen Anwendung funktionieren.

Physische Architektur

Die physische Architektur umfasst öffentliche und private Subnetze in OCI mit einer sekundären Backupregion zur Unterstützung von High Availability.

Die Architektur unterstützt Folgendes:

  • Frontend-Tier
    • Anwendungsbenutzer können über das Internet oder das Unternehmensnetzwerk eine Verbindung herstellen.
    • Die Benutzerverbindung wird mit einer OCI Web Application Firewall gesichert.
    • Die Benutzerverbindung zur Anwendung wird für mehr Resilienz und Skalierbarkeit belastet.
    • Load Balancer wird mit High Availability bereitgestellt.
  • Backend-Tier
    • Anwendungsserver werden mit einem Instanzpool in High Availability bereitgestellt.
    • Instanzpool wird mit Autoscaling verwendet, um horizontale Skalierbarkeit zu erreichen.
    • Instanzpool ist so konfiguriert, dass Instanzen in derselben Availability-Domain wie ATP Serverless bereitgestellt werden, Anwendungs- und Datenbank-Colocation vorhanden ist und somit die Verbindungslatenz optimiert wird.
    • Der Instanzpool ist so konfiguriert, dass Instanzen über Faultdomains in derselben Availability-Domain verteilt werden, in der ATP Serverless gespeichert ist, um die Resilienz der Workload zu erhöhen.
  • Datenbankebene
    • ATP Serverless bietet High Availability, da Oracle Real Application Clusters (Oracle RAC) und mehrere Datenbankknoten die Serviceinstanz untermauern. Daher ist die Datenbankebene standardmäßig hochverfügbar und resilient.
    • Mit der Oracle Database API für MongoDB, die in ATP Serverless aktiviert ist, können Sie vorhandenen Anwendungscode ohne Änderungen verwenden.
    • Die Oracle Database API für MongoDB ist hoch belastbar und die Resilienz wird intern von ATP Serverless garantiert.
    • ATP Serverless kann die automatische Skalierung verwenden, um die Systemlast zu erhöhen und zu verringern.
    • Die Geschäftskontinuität von ATP Serverless wird mit Oracle Autonomous Data Guard-basiertem regionsübergreifendem Disaster Recovery erreicht.
    • Das regionsübergreifende Oracle Autonomous Data Guard Standby Recovery Time Objective (RTO) beträgt fünfzehn Minuten und das Recovery Point Objective (RPO) eine Minute.
  • Disaster Recovery
    • Zwei Regionen unterstützen regionsübergreifendes Disaster Recovery für das gesamte Cloud-Deployment.
    • Die Standby-Region unterstützt eine Warm Standby-Datenbank, in der Cloud-Instanzen vorab bereitgestellt werden, um das Gesamtziel für die Recovery-Zeit (RTO) zu senken.
    • ATP Serverless in der primären Region verfügt über einen regionsübergreifenden Oracle Autonomous Data Guard-Peer in der Standbyregion
    • Der Instanzpool der Backend-Tier ist mit einer Mindestanzahl von Instanzen im Pool vorkonfiguriert. Der DR-Plan für OCI Full Stack Disaster Recovery, der jeden Schritt des Failovers automatisiert, kann die Anzahl der Compute-Instanzen ändern, die nach dem Failover ausgeführt werden sollen. Die metrikbasierte Autoscaling-Konfiguration wird definiert, um die minimale und maximale Anzahl von Instanzen im Pool sowie die Metriken zu bestimmen, die zum horizontalen und vertikalen Skalieren verwendet werden.
    • Die Standby-Region wird mit einer ähnlichen Topologie bereitgestellt, um das Gesamtziel für die Recovery-Zeit zu reduzieren.
    • OCI Full Stack Disaster Recovery automatisiert das Failover für den gesamten Stack zur Standbyregion und Fallbacks zur primären Region.
  • Networking
    • Die in beiden Regionen bereitgestellten dynamischen Routinggateways werden per Peering verbunden.
    • On-Premise-Konnektivität nutzt sowohl Oracle Cloud Infrastructure FastConnect als auch Site-to-Site-VPN für Redundanz.
    • Der gesamte eingehende Traffic von On-Premise und vom Internet wird zuerst an das Hub-VCN und dann an das Workload-VCN weitergeleitet.
    • Verwendet ein Hub- und Spoke-Netzwerkdesign, um den Sicherheitsstatus zu erhöhen und andere Workload-VCNs aufzunehmen.
    • Services werden mit privaten Endpunkten bereitgestellt, um den Sicherheitsstatus zu erhöhen.
    • Das JSON-Workload-VCN ist in mehrere private Subnetze unterteilt, um den Sicherheitsstatus zu erhöhen.
  • Sicherheit
    • Alle Daten sind während der Übertragung und im Ruhezustand sicher.
    • Mögliche Designverbesserungen, die in diesem Deployment aus Gründen der Einfachheit nicht dargestellt werden, umfassen die Verwendung einer vollständigen CIS-konformen Landing Zone und die Nutzung einer Netzwerkfirewall, die im Hub-VCN bereitgestellt ist. Eine Netzwerkfirewall verbessert die allgemeine Sicherheitslage, indem der gesamte Datenverkehr geprüft und Richtlinien durchgesetzt werden.


mongodb-atp-s-physical-arch-oracle.zip

Die Architektur umfasst die folgenden Hauptkomponenten:

  • Region

    Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • FastConnect

    Oracle Cloud Infrastructure FastConnect erstellt eine dedizierte, private Verbindung zwischen Ihrem Data Center und OCI. FastConnect bietet Optionen Mit höherer Bandbreite sowie ein zuverlässigeres Netzwerk als bei internetbasierten Verbindungen.

  • Dynamisches Routinggateway (DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen OCI-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

  • Network Address Translation-(NAT-)Gateway

    Mit einem NAT-Gateway können private Ressourcen in einem VCN auf Hosts im Internet zugreifen, ohne diese Ressourcen für eingehende Internetverbindungen verfügbar zu machen.

  • Servicegateway

    Ein Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Datenverkehr vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.

  • Internetgateway

    Ein Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

  • Load Balancer

    Oracle Cloud Infrastructure Load Balancing bietet eine automatisierte Trafficverteilung von einem einzigen Einstiegspunkt auf mehrere Server.

  • Web Application Firewall

    Oracle Cloud Infrastructure Web Application Firewall (WAF) ist ein regionaler Edge-Enforcement Service, der an einen Enforcement Point angehängt ist, wie einen Load Balancer oder einen Domainnamen einer Webanwendung. WAF schützt Anwendungen vor schädlichem und unerwünschtem Internettraffic. Mit WAF können Sie jeden internetseitigen Endpunkt schützen und eine konsistente Regeldurchsetzung über Ihre Anwendungen hinweg ermöglichen.

  • Oracle Autonomous Transaction Processing Serverless

    Oracle Autonomous Transaction Processing Serverless ist ein vollständig automatisierter Datenbankservice, der für die gleichzeitige Ausführung von Transaktions-, Analyse- und Batch-Workloads optimiert ist. Um die Performance zu beschleunigen, ist es für Zeilenformat, Indizes und Daten-Caching vorkonfiguriert und bietet gleichzeitig Skalierbarkeit, Verfügbarkeit, transparente Sicherheit und Betriebsanalysen in Echtzeit. Anwendungsentwickler und DBAs können Anwendungen schnell, einfach und kostengünstig entwickeln und bereitstellen, ohne dabei auf Funktionalität oder Atomizität, Konsistenz, Isolation und Dauerhaftigkeit (ACID) verzichten zu müssen.

  • Full Stack Disaster Recovery

    Oracle Cloud Infrastructure Full Stack Disaster Recovery ist ein Orchestrierungs- und Management-Service, der umfassende Disaster-Recovery-Funktionen für alle Layer eines Anwendungsstacks bereitstellt, darunter Infrastruktur, Middleware, Datenbank und Anwendung.

  • Objektspeicher

    OCI Object Storage bietet Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und sicher direkt aus dem Internet bzw. aus der Cloud-Plattform speichern. Sie können den Storage skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.

    Verwenden Sie den Standardspeicher für "Hot Storage", auf die Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicherung für "Cold Storage", die Sie über lange Zeiträume beibehalten und nur selten darauf zugreifen.

  • Oracle Database API für MongoDB

    Mit der Oracle Database-API für MongoDB können Anwendungen mit Sammlungen von JSON-Dokumenten in Oracle Database mit MongoDB-Treibern, -Tools und -SDKs interagieren.

Physikalische Architektur - Variante

Die vollständig verwaltete MongoDB-API von ATP Serverless ist die beste Lösung für die meisten Workloads, da sie einfacher zu verwalten ist. Diese physische Architekturvariante verwendet ein vom Kunden verwaltetes Oracle REST Data Services-Deployment, das auf jedem Anwendungsserver ausgeführt wird.

Wenn die Konfiguration und Verwaltung von Oracle REST Data Services manuell gesteuert werden muss, ist die Verwendung von vom Kunden verwalteten Oracle REST Data Services eine Option. Beispiel: Damit die Anwendung größere Connection Pools verwenden kann.

Hinweis:

Verwenden Sie diese Architekturvariante, wenn dafür eine bestimmte Workload erforderlich ist. Nur fortgeschrittene Benutzer sollten diese Architekturvariante bereitstellen.

In diesem Abschnitt werden nur die Unterschiede zur zuvor beschriebenen physischen Architektur beschrieben. Daher sind alle Prinzipien des physischen Architekturdesigns gültig, sofern nicht anders angegeben.

Das folgende Architekturdiagramm zeigt, wie die Variante bereitgestellt wird. Der Einfachheit halber werden nur die im JSON-Workload-VCN bereitgestellten Cloud-Ressourcen dargestellt, da der Rest des Deployments mit dem zuvor beschriebenen identisch ist.



mongodb-atp-s-arch-variant-oracle.zip

Folgendes ist die Frontend-Ebene für die Variante:
  • Backend-Anwendungscode wird auf Anwendungsservern bereitgestellt, die Teil eines Instanzpools sind.
  • Die eingehenden Benutzeranforderungen werden vom Load Balancer verteilt, sodass die Frontend-Tier horizontal skalierbar ist und keinen einzelnen Fehlerpunkt aufweist.
  • Vom Kunden verwaltete Oracle REST Data Services wird auf jedem Anwendungsserver installiert und so konfiguriert, dass die API MongoDB aktiviert wird, sodass die Anwendung mit MongoDB-Tools und -Treibern eine Verbindung zur Datenbank herstellen kann.
  • Vom Kunden verwaltete Oracle REST Data Services sind so konfiguriert, dass sie an die nicht funktionalen Workload-Anforderungen angepasst werden. Beispiel: Sie konfigurieren größere Connection Pools oder verwenden einen anderen Datenbankservice.
  • Sowohl der Backend-Code als auch die vom Kunden verwalteten Oracle REST Data Services sind in der vom Pool verwendeten Instanzkonfiguration vorinstalliert und vorkonfiguriert. So kann eine Instanz nach dem Instanz-Provisioning immer dann das Backend ausführen und eine Verbindung zur Datenbank herstellen, wenn sie dem Pool hinzugefügt wird.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt, um die Workload weiter zu verbessern und weiterzuentwickeln. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

Beachten Sie Folgendes:

  • Anwendungs-Deployment

    Verwenden Sie ein containerbasiertes Deployment mit Oracle Cloud Infrastructure Kubernetes Engine (OKE), wenn die Anwendung in Containern ausgeführt werden kann.

  • Sicherheit
    • Mit Oracle Data Safe können Sie den Workload-Sicherheitsstatus weiter erhöhen und Datenbankauditing ausführen.
  • Beobachtbarkeit
    • Mit OCI Audit können Sie forensisches Auditing für alle OCI-Services außerhalb von Oracle Autonomous Database Serverless durchführen.
    • Mit OCI Monitoring, OCI Logging und OCI Logging Analytics können Sie den Betriebsstatus der Umgebung vollständig anzeigen.
  • Betriebliche Effizienz
    • Verwenden Sie Elastic Pools, wenn die ATP Serverless JSON-Workload zur Steigerung der Kosteneffizienz Teil einer breiteren Datenbankflotte ist.
    • Aktivieren Sie Oracle Cloud Infrastructure Database Management. Dieser Service bietet ein umfassendes Set an Funktionen zur Überwachung und Verwaltung der Datenbankperformance, um die ATP Serverless-Instanz zu optimieren.
  • Anwendungsentwicklung
    • Stellen Sie Betriebsanalysen und Echtzeitberichte in ATP Serverless mit SQL und einem Frontend wie APEX oder Oracle Analytics Cloud bereit, ohne Daten aus der Datenbank zu verschieben, um vertrauenswürdige und Echtzeitdatenanalysen zu ermöglichen.
    • Verwenden Sie ATP Serverless und Oracle Machine Learning, um Modelle mit JSON-Daten zu erstellen und zu trainieren, ohne Daten zu verschieben, und um die Modelle neben der vorhandenen Workload für eine effiziente Inferenz bereitzustellen.
    • Bei zusätzlichen Anwendungsfällen, die über den Anwendungskern hinausgehen, sollten Sie Oracle Autonomous Database Select AI und Datenbankansichten verwenden, um JSON abzufragen und Metadaten zu speichern. Auf diese Weise können Benutzer JSON-Daten in natürlicher Sprache abfragen.
    • Verwenden Sie ATP Serverless, um zusätzliche Datentypen (relational, vektor, räumlich oder grafisch) für zusätzliche Workload-Funktionalität und Flexibilität zu speichern.

Bestätigungen

  • Autoren: José Cruz
  • Mitwirkende: Massimo Castelli, Simon Griffith, Hermann Baer, Matt DeMarco, Julian Dontcheff