Migrierte MongoDB-Workload in Oracle Autonomous JSON Database@Azure bereitstellen

Migrieren Sie eine vorhandene Workload, die eine Dokumentendatenbank, in diesem Fall MongoDB, verwendet, zu Azure und Oracle Autonomous JSON Database, die in Azure bereitgestellt sind, einem Cloud-Dokumentendatenbankservice, der es einfach macht, die Entwicklung Ihrer JSON-zentrierten Anwendungen 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, sehr beliebt. Schemaflexibilität, schnelle Entwicklung und Skalierbarkeit ermöglichen ein schnelles Prototyping von Anwendungsfunktionen, eine einfachere Anwendungsentwicklung und die Sicherheit, 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 wäre, wenn diese Workloads von allen Vorteilen herkömmlicher Dokumentendatenbanken profitieren könnten, aber gleichzeitig die Vorteile relationaler Datenbanken nutzen könnten? Verfügen Sie beispielsweise über stärkere Transaktionsgarantien und nutzen Sie zusätzliche Funktionen wie Analysen und maschinelles Lernen, ohne dass Daten in eine andere Datenbank oder ein anderes System repliziert werden müssen.

Autonomous JSON Database bietet Dokument-APIs im NoSQL-Stil (Oracle Simple Oracle Document Access (SODA) und Oracle Database API for MongoDB), serverlose Skalierung, leistungsstarke ACID-Transaktionen, umfassende Sicherheit und niedrige Pay-per-Use-Preise. Autonome JSON-Datenbank automatisiert Provisioning, Konfiguration, Optimierung, Skalierung, Patching, Verschlüsselung und Reparatur von Datenbanken, eliminiert das Datenbankmanagement und bietet eine Verfügbarkeit von 99,95%.

Funktionale Architektur

Diese Architektur setzt als Ausgangspunkt voraus, dass eine Workload mit einer Anwendung und einer MongoDB-Datenbank vorhanden ist, entweder ein On-Premise- oder ein Cloud-Deployment, und dass sie zu Azure und Oracle Database@Azure migriert wird. Es beschreibt die zukünftige Statusarchitektur, ihre Vorteile, wie sie bereitgestellt werden kann und welche zusätzlichen Funktionen Sie verwenden können, um die vorhandene Workload zu erweitern.

Eines der wichtigsten Features in dieser Architektur 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. Vorhandener Anwendungscode kann mit in Oracle Autonomous JSON Database gespeicherten Daten verwendet werden, ohne dass ein Refactoring erforderlich ist.

Das folgende Diagramm zeigt eine typische Anwendung, die sich aus einer Datenbank-, Backend- und Frontend-Ebene zusammensetzt.

Beschreibung der Abbildung mongodb-ajd-azure-logical-arch.png

mongodb-ajd-azure-logical-arch-oracle.zip

Ein beliebter Stack, der zur Implementierung dieses Musters verwendet wird, ist der MEAN-Stack, der MongoDB als Dokumentdatenbank, Express als Backend-Framework, Angular als Frontend-Framework und Node.js als Backend-Server verwendet. In diesem Dokument wird ein MEAN-Stack als Beispiel für ein vorhandenes Deployment verwendet, das zu Azure und Autonomous JSON Database migriert wird.

Die Migration dieser Workload zu Azure und Autonomous JSON Database ist einfach und umfasst auf hoher Ebene die folgenden Schritte:

1. Stellen Sie eine autonome JSON-Datenbankinstanz bereit, um die MongoDB-API von Oracle Database beim Erstellen zu aktivieren.
2. Migrieren Sie Metadaten und Daten aus MongoDB in Autonomous JSON Database.
3. Stellen Sie Anwendungsserver bereit, um Node.js und Express mit Azure App Service, VMs, Containern oder Kubernetes in derselben Region und Availability-Domain wie Autonomous JSON Database auszuführen.
4. Stellen Sie den Backend-Anwendungscode auf den Anwendungsservern bereit.
5. Verbinden Sie die Backend-Anwendung mit autonomen JSON-Datenbank mit denselben MongoDB-Tools und -Treibern, die in der aktuellen Anwendung verwendet werden.
6. Benutzer müssen sich bei der neuen Anwendungs-URI anmelden.

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.

Nachdem die Workload in eine autonome JSON-Datenbank migriert wurde, können Sie mehrere Features verwenden, um die vorhandene Funktionalität zu erweitern, unabhängig davon, ob diese auf 1) zusätzliche nicht funktionale Anforderungen unterstützt, wie z. B. einfache Verbesserung der Skalierbarkeit, Resilienz oder Hochverfügbarkeit oder 2) zusätzliche Funktionsfunktionen wie Betriebsberichte, Analysen und maschinelles Lernen vorhanden sind, ohne dass Daten aus der Datenbank kopiert werden müssen.

Um die Skalierbarkeit und High Availability zu verbessern, verwenden Sie das Autoscaling-Feature Autonomous JSON Database. Mit einem einzigen Klick oder API-Aufruf kann die Workload bis zum 3-fachen der Basiskapazität ohne Ausfallzeiten nutzen. Beachten Sie, dass Autonomous JSON Database die 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 die autonome JSON-Datenbank auf einer Multimodell-Datenbanktechnologie mit mehreren Workloads basiert, können Sie Funktionen hinzufügen, die auf relationalen, räumlichen, Diagramm- oder Vektordatentypen basieren, die neben der vorhandenen Anwendung funktionieren. In der Regel möchten Benutzer zusätzlich zu JSON-Daten Analysen durchführen. Die Verwendung von SQL in Autonomous JSON Database vereinfacht die Erstellung betrieblicher und analytischer Berichte mit derselben Engine und denselben Daten.

Autonome JSON-Datenbank ist auf 20 GB Nicht-JSON-Daten begrenzt. Wenn sich Ihre Datenvolumenanforderungen ändern, können Sie ganz einfach in Oracle Autonomous Database Serverless konvertieren, das dieselben Features unterstützt. Views and Materialized Views storage doesn't count towards the Autonomous JSON Database 20 Gb non-JSON data limit, so those can be easily created and used, for instance, to support operational analytics using SQL on top of JSON documents.

Physische Architektur

Die physische Architektur umfasst eine autonome JSON-Datenbank, die mit delegierten Subnetzen in zwei Microsoft Azure-Regionen bereitgestellt wird, um High Availability zu unterstützen. OCI-Services unterstützen automatisches Backup in Oracle Cloud Infrastructure Object Storage.

Die Architektur unterstützt Folgendes:

• Frontend-Tier
  • Anwendungsbenutzer können über das Internet oder das Unternehmensnetzwerk eine Verbindung herstellen.
  • Die Benutzerverbindung wird mit Microsoft Azure Front Door an die aktive Region weitergeleitet, in der die Anwendung ausgeführt wird.
  • Die Benutzerverbindung wird mit der Azure Web Application Firewall gesichert.
  • Die Benutzerverbindung zur Anwendung wird mit dem App-Service ausgeglichen.
• Backend-Tier
  • Die Anwendung wird mit Azure App Service hochverfügbar bereitgestellt.
  • Azure App Service AutoScale wird verwendet, um horizontale Skalierbarkeit zu erreichen.
• Datenbankebene
  • Autonomous JSON Database 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 Autonomous JSON Database aktiviert ist, können Sie vorhandenen Anwendungscode ohne Änderungen verwenden.
  • Die Oracle Database-API für MongoDB ist äußerst resilient und diese Resilienz wird intern von der Autonomous JSON Database garantiert.
  • Autonome JSON-Datenbank kann Autoscaling verwenden und sich an Erhöhungen und Verringerungen der Systemlast anpassen.
  • Die Geschäftskontinuität der autonomen JSON-Datenbank wird durch eine regionsübergreifende Notfallwiederherstellung auf Backupbasis erreicht. Alternativ können Sie aktualisierbare Klone verwenden.
• Disaster Recovery
  • Zwei Regionen unterstützen regionsübergreifendes Disaster Recovery für das gesamte Cloud-Deployment.
  • Die autonome JSON-Datenbank in der primären Region verfügt über einen backupbasierten regionsübergreifenden Peer in der sekundären Region.
  • Die zweite Region wird mit einer ähnlichen Topologie bereitgestellt, um das Gesamtziel für die Recovery-Zeit zu reduzieren.
  • Verwenden Sie eine warme DR-Strategie, um das gesamte RTO zu reduzieren. In einer Warm-DR-Strategie werden die Cloud-Ressourcen der Backend-Ebene bereits zusammen mit der Standbydatenbank der autonomen JSON-Datenbank bereitgestellt.
  • Alternativ können Sie die Backend-Tierressourcen im Falle eines Fehlers bereitstellen. Dadurch werden die Kosten für die Ausführung der DR-Ressourcen gesenkt, aber das RTO insgesamt erhöht.
• Networking
  • Der gesamte eingehende Datenverkehr der Anwendung von On-Premises und aus dem Internet wird von Azure Front Door geleitet.
  • Autonome JSON-Datenbank wird mit einem privaten Endpunkt bereitgestellt, um den Sicherheitsstatus zu erhöhen.
  • Azure App Service ist eine Webanwendung, die mit einem Integrationssubnetz und VNet bereitgestellt wird, um die Autonomous JSON Database-Instanz zu erreichen.
  • Die Anwendung VNet wird mit der Datenbank VNet per Peering verbunden, und Traffic kann zwischen der Webanwendung und der autonomen JSON-Datenbank fließen.
• Sicherheit
  • Sämtliche Daten sind während der Übertragung und bei rest sicher.
  • Die folgenden potenziellen Konstruktionsverbesserungen sind in diesem Deployment aus Gründen der Einfachheit nicht dargestellt:
    • Automatisieren Sie die Anwendungs-Disaster Recovery mit Azure Automation-Runbooks, um Front Door-Endpunkte zu wechseln und den Zustand der Post-Failover-App zu validieren.
    • Nutzen Sie eine Hub- und Spoke-Topologie, um eine zentrale Netzwerksicherheit durchzusetzen.
    • Nutzen Sie eine Netzwerkfirewall, die im Hub VNet bereitgestellt wird, um den allgemeinen Sicherheitsstatus zu verbessern, indem Sie den gesamten Traffic prüfen und Policys durchsetzen.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung der Abbildung mongodb-ajd-azure-physical-arch.png

mongodb-ajd-azure-physikalisch-arch.zip

Die Architektur enthält die folgenden Microsoft-Komponenten:

• Azure-Firewallmanager

  Azure Firewall Manager ist ein zentralisierter Sicherheitsverwaltungsservice, der die Bereitstellung und Konfiguration der Azure Firewall über mehrere Regionen und Abonnements hinweg vereinfacht. Es ermöglicht hierarchisches Policy-Management, sodass globale und lokale Firewall-Policys konsistent angewendet werden können. Wenn Azure Virtual WAN (vWAN) und ein sicherer Hub integriert sind, verbessert Azure Firewall Manager die Sicherheit, indem es das Traffic-Routing und die Filterung automatisiert, ohne dass benutzerdefinierte Routen erforderlich sind. Durch diese Integration wird sichergestellt, dass der Datenverkehr zwischen virtuellen Netzwerken, Niederlassungen und dem Internet sicher verwaltet und überwacht wird. Dies bietet eine robuste und optimierte Netzwerksicherheitslösung.

• Azure-Vordertür

  Azure Front Door ist ein cloudbasierter Service, der als globaler Einstiegspunkt für Webanwendungen fungiert und leistungsstarke Inhaltsbereitstellung, intelligentes Layer-7-Load Balancing sowie integrierte Sicherheitsfunktionen wie Web Application Firewall (WAF) und DDoS-Schutz bietet, um eine schnelle, zuverlässige und sichere Benutzererfahrung zu gewährleisten.

• Azure-Region

  Eine Azure-Region ist ein geografischer Bereich, in dem sich mindestens ein physisches Azure-Data Center, die sogenannten Availability Zones, befindet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  Azure- und OCI-Regionen sind lokalisierte geografische Gebiete. Bei Oracle Database@Azure ist eine Azure-Region mit einer OCI-Region verbunden, wobei Availability Zones (AZs) in Azure mit Availability-Domains (ADs) in OCI verbunden sind. Azure- und OCI-Regionspaare werden ausgewählt, um Entfernung und Latenz zu minimieren.

• Azure-Verfügbarkeitszone

  Azure-Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer Azure-Region, die durch unabhängige Stromversorgung, Kühlung und Vernetzung eine hohe Verfügbarkeit und Resilienz gewährleisten.

• Virtuelles Azure-Netzwerk (VNet)

  Azure Virtual Network (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNet können viele Arten von Azure-Ressourcen, wie z. B. virtuelle Azure-Maschinen (VMs), sicher miteinander, mit dem Internet und On-Premises-Netzwerken kommunizieren.

• Azure-Anwendungsservice

  Azure App Service ist eine vollständig verwaltete Platform-as-a-Service-Lösung (PaaS), mit der Webanwendungen, APIs und mobile Backends erstellt, gehostet und skaliert werden können, ohne die zugrunde liegende Infrastruktur zu verwalten.

• Azure App Service-Integrationssubnetz

  Ein dediziertes Subnetz in einem virtuellen Azure-Netzwerk, das speziell für die Verwendung durch App Service-Pläne delegiert wird. Dadurch können Webanwendungen ausgehende Verbindungen zu privaten Ressourcen innerhalb des virtuellen Netzwerks oder seiner Peer-Netzwerke herstellen, aber keinen eingehenden Traffic von der VNet empfangen.

• Delegiertes Azure-Subnetz

  Mit einem delegierten Subnetz können Sie einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt als Ressource in Ihr virtuelles Netzwerk einfügen. Sie haben die vollständige Integrationsverwaltung externer PaaS-Services in Ihren virtuellen Netzwerken.

Die Architektur umfasst die folgenden Oracle-Komponenten:

• OCI-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.

• OCI Object Storage

  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 Anwendungen oder 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.

• Privater OCI-Endpunkt

  OCI Private Endpoint bietet kostenlosen, privaten und sicheren Zugriff auf einen von vielen OCI-Services über ein virtuelles Cloud-Netzwerk (VCN) oder ein On-Premise-Netzwerk.

Architekturvariante

Diese Variante der vorgeschlagenen physischen Architektur verwendet ein vom Kunden verwaltetes Oracle REST Data Services-Deployment, das auf jedem Anwendungsserver ausgeführt wird. Die vollständig verwaltete MongoDB-API von Autonomous JSON Database ist jedoch die beste Lösung für die meisten Workloads, da sie einfacher zu verwalten ist.

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 der zuvor beschriebenen physischen Architektur identisch ist.

Beschreibung der Abbildung mongodb-ajd-azure-arch-variant.png

mongodb-ajd-azure-arch-variant-oracle.zip

Im Folgenden wird die Frontend-Ebene für die Variante beschrieben:

• Die eingehenden Benutzeranforderungen werden vom Load Balancer des App Service verteilt, sodass die Frontend-Tier horizontal skalierbar ist und keinen einzelnen Fehlerpunkt aufweist.
• Die Backend-Anwendung wird in den Workern der App Service Scale Unit bereitgestellt.
• Die Anwendung wird mit dem Container als Veröffentlichungsmethode bereitgestellt.
• Erstellen, installieren und konfigurieren Sie den Container mit der Anwendung und Oracle REST Data Services, sodass beide in demselben Container ausgeführt werden können.
• Jeder Worker führt das Containerimage aus, das die Anwendung und Oracle REST Data Services in derselben Laufzeitumgebung kolokalisiert.
• Vom Kunden verwaltete Oracle REST Data Services-Worker sind so konfiguriert, dass die MongoDB-API 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, z.B. durch die Konfiguration größerer Verbindungspools oder die Verwendung eines anderen Datenbankservice.
• Sowohl der Backend-Code als auch die vom Kunden verwalteten Oracle REST Data Services sind im Containerimage vorinstalliert und vorkonfiguriert, das für die Worker verwendet wird. Wenn App Service horizontal skaliert wird, können neue Worker die Backend-Anwendung ausführen und nach dem Provisioning eine Verbindung zur Datenbank herstellen.

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.

• Anwendungs-Deployment
  • Sie sollten ein containerbasiertes Deployment mit Azure Kubernetes Service (AKS) verwenden, wenn Sie erweiterte Orchestrierungs-, Netzwerk- und Sicherheitsfunktionen benötigen, die möglicherweise nicht in App Service verfügbar sind.
• Sicherheit
  • Verwenden Sie Oracle Data Safe, um den Sicherheitsstatus der Workload weiter zu erhöhen und Datenbankauditing auszuführen.
• Beobachtbarkeit
  • Verwenden Sie Azure Monitor, um Autonomous JSON Database-Metriken neben allen anderen Azure-Services zu überwachen, die Daten überwachen.
• Disaster Recovery
  • Erwägen Sie die Automatisierung und Orchestrierung der Disaster- und Recovery-Vorgänge für alle Ebenen des Stacks mit Azure Site Recovery oder benutzerdefinierten Skripten, die Fehler erkennen und Failover-Prozesse auslösen.
• Betriebliche Effizienz
  • Wenn die Workload der autonomen JSON-Datenbank Teil einer breiteren Datenbankflotte ist, sollten Sie Elastic Pools verwenden, um die Kosteneffizienz zu steigern.
  • Sie sollten Oracle Cloud Infrastructure Database Management aktivieren, einen OCI-Service, der umfassende Features zur Überwachung und Verwaltung der Datenbankperformance bereitstellt, um das Management der Autonomous JSON Database-Instanz zu optimieren.
• Anwendungsentwicklung
  • Erwägen Sie die Bereitstellung von Betriebsanalysen und Echtzeitberichten in einer autonomen JSON-Datenbank mit SQL und einem Frontend wie APEX oder PowerBI, ohne Daten aus der Datenbank zu verschieben, für eine vertrauenswürdige Datenanalyse in Echtzeit
  • Ziehen Sie in Betracht, Autonomous JSON Database für maschinelles Lernen mit Oracle Machine Learning (OML) zu verwenden, um Modelle mit JSON-Daten zu erstellen und zu trainieren, ohne dass Daten verschoben werden müssen, und die Modelle neben der vorhandenen Workload bereitzustellen, um eine effiziente Inferenzierung zu ermöglichen.
  • Für zusätzliche Anwendungsfälle, die über den Anwendungskern hinausgehen, sollten Sie Autonomous JSON Database verwenden. Wählen Sie KI- und Datenbankansichten aus, die JSON abfragen und Metadaten enthalten, damit Benutzer JSON-Daten in natürlicher Sprache abfragen können.
  • Verwenden Sie die autonome JSON-Datenbank, um zusätzliche Datentypen (relational, vektor, räumlich oder grafisch) bis zu 20 GB für zusätzliche Workload-Funktionalität und Flexibilität zu speichern.

Mehr erfahren

Weitere Informationen zu den Features dieser Architektur:

• Oracle Datenplattform
• Autonome JSON-Datenbank
• Autonomous Database-Services für Azure
• Oracle Database API für MongoDB
• Oracle Autonomous Database Serverless verwenden
• Migration einer MongoDB-Datenbank, die auf MongoDB Atlas oder On Premise ausgeführt wird, zu Oracle Autonomous JSON Database (Tutorial)

Prüfen Sie die folgenden zusätzlichen Ressourcen:

• Oracle Cloud Infrastructure-Dokumentation
• Gut durchdachte Framework-Architektur für Oracle Cloud Infrastructure
• Oracle Cloud-Kostenrechner
• Cloud Adoption Framework
• Moderne App-Entwicklung

Bestätigungen

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