移行されたMongoDBワークロードのOracle Autonomous Transaction Processing Serverless@Azureへのデプロイ

ドキュメント・データベース(この場合はMongoDB)を使用する既存のワークロードを、AzureにデプロイされたMicrosoft AzureおよびOracle Autonomous Transaction Processingサーバーレスに移行します。これは、JSON中心のアプリケーション開発を他のマルチモデル・ワークロードとともに簡単に最新化できるクラウド・ドキュメント・データベース・サービスです。

ドキュメントやドキュメント・データベースを使用してデータ・スキーマやアプリケーションを進化させるワークロードやアプリケーションは、開発者に提供される柔軟性のために人気があります。スキーマの柔軟性、迅速な開発およびスケーラビリティにより、アプリケーション機能のプロトタイピングの高速化、アプリケーションの進化の容易化、および開発者が大規模なユーザー・ベースに対応するように拡張できる反復的に小さいアプリケーションや機能の構築が可能になります。ただし、このようなタイプのワークロードには、トランザクションの保証の低下、データ問合せの汎用性、分析や機械学習などのドキュメントで他のワークロードをサポートできないという課題があります。

これらのワークロードが従来のドキュメント・データベースのメリットを享受し、リレーショナル・データベースのメリットを活用できるとしたら?たとえば、データを別のデータベースやシステムにレプリケートする必要なく、トランザクション上の保証を強化し、分析や機械学習などの機能を追加することができます。

Autonomous Transaction Processing (ATP)サーバーレスは、トランザクション・ワークロード、分析ワークロードおよびバッチ・ワークロードを同時に実行するように最適化された、完全に自動化されたデータベース・サービスです。パフォーマンスを加速するために、拡張性、可用性、透過的なセキュリティ、リアルタイムの運用分析を提供しながら、行形式、索引、データ・キャッシュ用に事前構成されています。アプリケーション開発者とDBAは、機能性や原子性、一貫性、分離および耐久性(ACID)プロパティを犠牲にすることなく、迅速かつコスト効率よくアプリケーションを開発およびデプロイできます。

機能アーキテクチャ

このアーキテクチャでは、開始点として、アプリケーションとMongoDBデータベースを含むワークロードが存在し、オンプレミスまたはクラウド・デプロイメントのいずれかが存在し、AzureおよびOracle Database@Azureに移行されることを前提としています。将来の状態アーキテクチャ、その利点、デプロイ方法、および既存のワークロードを拡張するために使用できる追加機能について説明します。

このアーキテクチャで使用される主な機能の1つは、Oracle Database API for MongoDBです。このAPIを使用すると、アプリケーションは、MongoDBドライバ、ツールおよびSDKを使用してOracle Database内のJSONドキュメントのコレクションと対話できます。既存のアプリケーション・コードは、コードをリファクタすることなく、Oracle Autonomous Transaction Processingサーバーレスに格納されたデータを操作できます。

次の図は、データベース層、バックエンド層およびフロントエンド層で構成される一般的なアプリケーションを示しています。



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

MEANスタックは、このパターンの実装に使用される一般的なスタックです。

  • MongoDB: ドキュメント・データベース
  • Express: バックエンド・フレームワーク
  • Angular: フロントエンドフレームワーク
  • Node.js: バックエンド・サーバー

このドキュメントでは、AzureおよびATPサーバーレスに移行される既存のデプロイメントの例としてMEANスタックを使用します。

このワークロードのAzureおよびATP Serverlessへの移行は簡単で、次のステップの概要で構成されます。

  1. ATPサーバーレス・インスタンスをデプロイし、作成時にOracle Database MongoDB APIを有効にします。
  2. MongoDBからATPサーバーレスにメタデータおよびデータを移行します。
  3. Azure App Service、VM、コンテナまたはKubernetesのいずれかを使用してNode.jsおよびExpressを実行するアプリケーション・サーバーを、ATP Serverlessと同じリージョンおよび可用性ドメインにデプロイします。
  4. バックエンド・アプリケーション・コードをアプリケーション・サーバーにデプロイします。
  5. 現在のアプリケーションで使用されているものと同じMongoDBツールおよびドライバを使用して、バックエンド・アプリケーションをATPサーバーレスに接続します。
  6. ユーザーを新しいアプリケーションURIに接続します。

このリファレンス・アーキテクチャは、移行プロセス自体ではなく、移行されたワークロードのデプロイメントに重点を置いています。移行プロセスの詳細は、「詳細」の項を参照してください。

ワークロードをATP Serverlessに移行した後、既存の機能を拡張するためにいくつかの機能を使用できます。1)スケーラビリティ、回復性、高可用性の向上など、追加の非機能要件をサポートするか、2)運用レポート、分析、機械学習などの追加の機能機能を備えているかに関係なく、データベースからデータをコピーする必要はありません。

スケーラビリティと高可用性を向上させるには、Autonomous Transaction Processingサーバーレス自動スケーリング機能を使用します。1回のクリックまたはAPIコールで、ワークロードはダウンタイムなしでベースライン容量の3倍まで使用できます。Autonomous Transaction Processingサーバーレスは、高可用性のためにOracle Real Application Clusters (Oracle RAC)テクノロジを使用します。バックエンド層の場合は、Azure VMスケール・セットと自動スケール設定を使用するか、アプリケーションの高可用性およびスケーラビリティを有効にするアプリケーション・サービス(自動スケーリング設定を含むアプリケーション・サービスなど)のPaaSサービスを使用します。

ATP Serverlessはマルチモデルのマルチワークロード・データベース・テクノロジの上に構築されているため、既存のアプリケーションと連携して動作するリレーショナル、空間、グラフまたはベクトル・データ型に依存する機能を追加できます。

物理アーキテクチャ

物理アーキテクチャには、高可用性をサポートするために、2つのAzureリージョンで委任サブネットを使用してデプロイされたAutonomous Transaction Processingサーバーレスが含まれます。OCIサービスは、Oracle Cloud Infrastructure Object Storageへの自動バックアップをサポートしています。

このアーキテクチャでは、次のものがサポートされています。

  • フロントエンド層
    • アプリケーション・ユーザーは、インターネットまたは企業ネットワークから接続できます。
    • ユーザー接続は、Azure Front Doorを使用して、アプリケーションを実行しているアクティブ・リージョンにルーティングされます。
    • ユーザー接続は、Azure Web Application Firewallを使用して保護されます。
    • アプリケーションへのユーザー接続は、アプリケーション・サービスを使用してロード・バランシングされます。
  • バックエンド層
    • アプリケーションは、Azureアプリケーション・サービスを使用して高可用性方式でデプロイされます。
    • Azureアプリケーション・サービスAutoScaleは、水平方向のスケーラビリティを実現するために使用されます。
  • データベース階層
    • ATPサーバーレスは、Oracle Real Application Clusters (Oracle RAC)およびサービス・インスタンスを支える複数のデータベース・ノードとして、高可用性を提供します。したがって、デフォルトでは、データベース層は高可用性で自己回復性があります。
    • ATPサーバーレスで有効になっているOracle Database API for MongoDBを使用すると、既存のアプリケーション・コードを変更できます。
    • Oracle Database API for MongoDBは高い耐障害性を持ち、ATPサーバーレスによって内部的に耐障害性が保証されます。
    • ATP Serverlessでは、自動スケーリングを使用して、システム負荷の増減を調整できます。
    • ATPサーバーレス・ビジネス継続性は、リージョン間のAutonomous Data Guardによって実現されます。
  • ディザスタ・リカバリ
    • 2つ目のリージョンは、同様のトポロジでデプロイされ、全体的なリカバリ時間の目標が短縮されます。
    • ウォームDR戦略を使用して、RTO全体を削減します。ウォームDR戦略では、バックエンド層のクラウド・リソースは、ATPサーバーレス・スタンバイ・データベースとともにすでにプロビジョニングされています。
    • あるいは、障害が発生した場合にバックエンド層リソースをプロビジョニングして、DRリソースの実行コストを削減し、RTO全体を増やすこともできます。
  • ネットワーキング
    • オンプレミスおよびインターネットからのすべてのアプリケーション受信トラフィックは、Azure Front Doorによってルーティングされます。
    • ATP Serverlessは、セキュリティ体制を強化するためにプライベート・エンドポイントとともにデプロイされます。
    • Azure App Service Webアプリケーションは、統合サブネットおよびVNetを使用してデプロイされ、ATPサーバーレス・インスタンスにアクセスします。
    • アプリケーションVNetはデータベースVNetとピアリングされ、トラフィックはWebアプリケーションとATPサーバーレス間のフローが許可されます。
  • セキュリティ
    • すべてのデータは、転送中および保存中に安全です。

次の潜在的な設計改善は、このデプロイメントでは簡略化のために示されていません。

  • Azure Automationランブックを使用してアプリケーションのディザスタ・リカバリを自動化し、フロント・ドア・エンドポイントを切り替え、フェイルオーバー後のアプリケーションの健全性を検証します。
  • ハブ・トポロジとスポーク・トポロジを活用して、一元化されたネットワーク・セキュリティを強化します。
  • ハブVNetにデプロイされたネットワーク・ファイアウォールを利用して、すべてのトラフィックを検査し、ポリシーを適用することで、全体的なセキュリティ状態を改善します。


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

このアーキテクチャには、次のMicrosoftコンポーネントがあります。

  • Azureファイアウォール・マネージャ

    Azure Firewall Managerは、複数のリージョンおよびサブスクリプションでのAzure Firewallのデプロイと構成を簡素化する、一元化されたセキュリティ管理サービスです。これにより、階層的なポリシー管理が可能になり、グローバルおよびローカルのファイアウォール・ポリシーを一貫して適用できます。Azure Virtual WAN (vWAN)およびセキュア ハブと統合されている場合、Azure Firewall Managerは、ユーザー定義のルートを必要とせずにトラフィックのルーティングとフィルタリングを自動化することで、セキュリティを強化します。この統合により、仮想ネットワーク、支店、インターネット間のトラフィックが安全に管理および監視され、堅牢で合理化されたネットワーク・セキュリティ・ソリューションが提供されます。

  • Azureフロント・ドア

    Azure Front Doorは、Webアプリケーションのグローバル・エントリー・ポイントとして機能するクラウドベースのサービスで、高パフォーマンスのコンテンツ配信、インテリジェントなレイヤー7ロード・バランシング、およびWeb Application Firewall (WAF)やDDoS保護などの統合セキュリティ機能を提供して、高速で信頼性が高く安全なユーザー・エクスペリエンスを実現します。

  • Azureリージョン

    Azureリージョンは、可用性ゾーンと呼ばれる1つ以上の物理Azureデータ・センターが存在する地理的領域です。リージョンは他のリージョンから独立しており、長距離の場合は複数の国または大陸にまたがる領域を分離できます。

    AzureおよびOCIリージョンは、ローカライズされた地理的領域です。Oracle Database@Azureの場合、AzureリージョンはOCIリージョンに接続され、Azureの可用性ゾーン(AZ)はOCIの可用性ドメイン(AD)に接続されます。距離とレイテンシを最小限に抑えるために、AzureとOCIリージョンのペアが選択されています。

  • Azure可用性ゾーン

    Azureアベイラビリティ ゾーンは、Azureリージョン内の物理的に別の場所であり、独立した電力、冷却、およびネットワークを提供することで、高可用性と回復性を確保するように設計されています。

  • Azure仮想ネットワーク(VNet)

    Azure Virtual Network(VNet)は、Azureのプライベート・ネットワークの基本的なビルディング・ブロックです。VNetを使用すると、Azure仮想マシン(VM)などの多くのタイプのAzureリソースで、相互、インターネットおよびオンプレミス・ネットワークと安全に通信できます。

  • Microsoft Azure App Service

    Microsoft Azure App Serviceでは、基盤となるインフラストラクチャを管理することなく、Webアプリケーション、APIおよびモバイル・バックエンドを構築、ホストおよびスケーリングできます。

  • Azure App Service統合サブネット

    Azure Virtual Network内の専用サブネットで、アプリケーション・サービス・プランで使用するために特別に委任され、Webアプリケーションは仮想ネットワークまたはそのピアリングされたネットワーク内のプライベート・リソースへのアウトバウンド接続を行うが、VNetからのインバウンド・トラフィックを受信することはできないようにします。

  • Azure委任サブネット

    委任サブネットを使用すると、マネージド・サービス(特にPlatform-as-a-Service (PaaS)サービスをリソースとして仮想ネットワークに直接挿入できます。仮想ネットワーク内の外部PaaSサービスの完全な統合管理が可能です。

このアーキテクチャには、次のOracleコンポーネントがあります。

  • OCIのリージョン

    OCIリージョンとは、可用性ドメインをホストする1つ以上のデータ・センターを含む、ローカライズされた地理的領域のことです。リージョンは他のリージョンから独立しており、長距離の場合は複数の国または大陸にまたがる領域を分離できます。

  • Oracle Autonomous Database

    Oracle Autonomous Databaseは、トランザクション処理およびデータ・ウェアハウス・ワークロードに使用できる、完全に管理された事前構成済のデータベース環境です。ハードウエアの構成や管理、ソフトウェアのインストールを行う必要はありません。OCIは、データベースの作成、バックアップ、パッチ適用、アップグレードおよびチューニングを処理します。

  • Oracle Autonomous Data Guard

    Oracle Autonomous Data Guardを使用すると、スタンバイ(ピア)データベースは、Autonomous Databaseインスタンスのデータ保護およびディザスタ・リカバリを提供できます。1つ以上のスタンバイ・データベースを作成、維持、管理、監視して、本番のOracleデータベースが障害やデータ破損に耐えられるようにするための包括的なサービス・セットが用意されています。Oracle Data Guardは、本番データベースのコピーとしてこれらのスタンバイ・データベースを維持します。そうすることによって、計画停止または計画外停止のため本番データベースが使用できなくなったときに、スタンバイ・データベースを本番ロールに切り替えて、そうした停止に関連する停止時間を最小化できます。

  • OCIオブジェクト・ストレージ

    OCIオブジェクト・ストレージでは、データベースのバックアップ、分析データ、イメージおよびビデオなどのリッチ・コンテンツなど、あらゆるコンテンツ・タイプの構造化データおよび非構造化データの大量へのアクセスを提供します。アプリケーションから直接、またはクラウド・プラットフォーム内から、安全かつ安全にデータを格納できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージを拡張することができます。

    迅速、即時、頻繁にアクセスする必要のあるホット・ストレージに標準ストレージを使用します。長期間保存し、ほとんどまたはめったにアクセスしないコールド・ストレージにアーカイブ・ストレージを使用します。

  • OCIプライベート・エンドポイント

    OCIプライベート・エンドポイントは、仮想クラウド・ネットワーク(VCN)またはオンプレミス・ネットワーク内から、多数のOCIサービスの1つへのコストのかからないプライベートなセキュアなアクセスを提供します。

アーキテクチャ・バリアント

提案された物理アーキテクチャのこのバリアントは、各アプリケーション・サーバーで実行されている顧客管理Oracle REST Data Servicesデプロイメントを使用します。ただし、ATP Serverlessによって提供されるフルマネージドMongoDB APIは、管理が容易であるため、ほとんどのワークロードに最適なソリューションです。

Oracle REST Data Servicesの構成および管理を手動で制御する要件がある場合は、顧客管理Oracle REST Data Servicesを使用することがオプションです。たとえば、アプリケーションがより大きな接続プールを使用できるようにします。

ノート:

特定のワークロード要件がある場合は、このアーキテクチャ・バリアントを使用します。上級ユーザーのみがこのアーキテクチャ・バリアントをデプロイする必要があります。

このセクションでは、前述した物理アーキテクチャーとの違いについてのみ説明するため、特に明記しないかぎり、すべての物理アーキテクチャー設計原則が有効です。

次のアーキテクチャ図は、バリアントのデプロイ方法を示しています。JSONワークロードVCNにデプロイされたクラウド・リソースのみがわかりやすくなります。これは、デプロイメントの残りの部分は前述の物理アーキテクチャと同じであるためです。



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

次に、バリアントのフロントエンド層について説明します。
  • 受信ユーザー・リクエストはアプリケーション・サービス・ロード・バランサによって分散されるため、フロントエンド層は水平方向にスケーラブルで、単一障害点がありません。
  • バックエンド・アプリケーションは、アプリケーション・サービス・スケール・ユニットのワーカーにデプロイされます。
  • アプリケーションは、公開方法としてコンテナを使用してデプロイされます。
  • アプリケーションとOracle REST Data Servicesを使用してコンテナを作成、インストールおよび構成します。これにより、両方を同じコンテナで実行できます。
  • 各ワーカーは、同じランタイム環境でアプリケーションとOracle REST Data Servicesをコロケーションするコンテナ・イメージを実行します。
  • 顧客管理のOracle REST Data Servicesワーカーは、MongoDB APIを有効にするように構成されているため、アプリケーションはMongoDBツールおよびドライバを使用してデータベースに接続できます。
  • 顧客管理のOracle REST Data Servicesは、たとえば、より大きな接続プールを構成するか、別のデータベース・サービスを使用して、ワークロード非機能要件に合せて構成されます。
  • バックエンド・コードと顧客管理Oracle REST Data Servicesの両方が、ワーカーで使用されるコンテナ・イメージにプリインストールおよび事前構成されています。アプリケーション・サービスが水平方向にスケーリングされると、新しいワーカーはバックエンド・アプリケーションを実行し、プロビジョニング後にデータベースに接続できます。

レコメンデーション

ワークロードをさらに改善および進化させるための出発点として、次の推奨事項を使用してください。 実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • アプリケーションのデプロイ
    • アプリケーション・サービスで使用できない可能性のある高度なオーケストレーション、ネットワーキングおよびセキュリティ機能が必要な場合は、Azure Kubernetes Service (AKS)を使用したコンテナ・ベースのデプロイメントの使用を検討してください。
  • セキュリティ
    • Oracle Data Safeを使用して、ワークロードのセキュリティ体制をさらに高め、データベース監査を実行することを検討してください。
  • 観測性
    • Azure Monitorを使用して、他のすべてのAzureサービス監視データとともにATPサーバーレス・メトリックを監視することを検討してください。
  • ディザスタ・リカバリ
    • Azure Site Recoveryまたは障害を検出し、フェイルオーバー・プロセスを開始するカスタム・スクリプトを使用して、スタックのすべてのレイヤーの障害およびリカバリを自動化および調整することを検討してください。
  • 業務効率
    • ATPサーバーレス・ワークロードがより広範なデータベース・フリートの一部である場合は、コスト効率を高めるためにエラスティック・プールを使用することを検討してください。
    • ATPサーバーレス・インスタンスの管理を合理化するために、データベース・パフォーマンスの監視および管理機能の包括的なセットを提供するOCIサービスであるOracle Cloud Infrastructure Database Managementを有効にすることを検討してください。
  • アプリケーションの進化
    • 信頼できるリアルタイムのデータ分析のために、データベースからデータを移動することなく、SQLやAPEXやPowerBIなどのフロントエンドを使用して、ATP Serverlessに運用分析とリアルタイム・レポートをデプロイすることを検討してください。
    • Oracle Machine Learning (OML)を使用した機械学習にATP Serverlessを使用することを検討し、データ移動を必要とせずにJSONデータを使用してモデルを構築およびトレーニングし、効率的な推論のためにモデルを既存のワークロードとともにデプロイすることを検討します。
    • アプリケーション・コア以外のユースケースについては、ATPサーバーレス選択AIおよびデータベース・ビューを使用してJSONを問い合せ、メタデータを保持し、ユーザーが自然言語を使用してJSONデータを問い合せることができるようにすることを検討してください。
    • ワークロードの機能と柔軟性を高めるために、ATP Serverlessを使用して追加のデータ型(リレーショナル、ベクトル、空間またはグラフ)を格納することを検討してください。

確認

  • 作成者: José Cruz
  • コントリビュータ: Massimo Castelli, Simon Griffith, Hermann Baer, Matt DeMarco, Julian Dontcheff