移行されたMongoDBワークロードのOracle Autonomous JSON Databaseへのデプロイ@Azure
ドキュメント・データベース(この場合はMongoDB)を使用する既存のワークロードを、AzureにデプロイされたAzureおよびOracle Autonomous JSON Databaseに移行します。これは、JSON中心のアプリケーションの開発のモダナイズを容易にするクラウド・ドキュメント・データベース・サービスです。
ドキュメントやドキュメント・データベースを使用してデータ・スキーマやアプリケーションを進化させるワークロードやアプリケーションは、開発者に提供される柔軟性のために非常に人気があります。スキーマの柔軟性、迅速な開発およびスケーラビリティにより、アプリケーション機能の迅速なプロトタイピング、アプリケーションの進化の容易化、および開発者が大規模なユーザー・ベースに対応するために拡張できる反復的に小さいアプリケーションや機能の構築が保証されます。ただし、このようなタイプのワークロードには、トランザクションの保証の低下、データ問合せの汎用性、分析や機械学習などのドキュメントで他のワークロードをサポートできないという課題があります。
これらのワークロードが従来のドキュメント・データベースのすべてのメリットを享受できる一方で、リレーショナル・データベースのメリットを活用できるとしたらどうでしょうか。たとえば、トランザクション上の保証を強化し、別のデータベースやシステムにデータをレプリケートする必要なく、分析や機械学習などの追加機能を使用します。
Autonomous JSON Databaseは、NoSQL形式のドキュメントAPI (Oracle Simple Oracle Document Access (SODA)およびOracle Database API for MongoDB)、サーバーレス・スケーリング、high performance ACIDトランザクション、包括的なセキュリティ、および低従量制の価格設定を備えています。Autonomous JSON Databaseは、データベースのプロビジョニング、構成、チューニング、スケーリング、パッチ適用、暗号化および修復を自動化し、データベース管理を排除し、99.95%の可用性を実現します。
機能アーキテクチャ
このアーキテクチャで使用される主な機能の1つは、Oracle Database API for MongoDBです。これにより、アプリケーションは、MongoDBドライバ、ツールおよびSDKを使用してOracle Database内のJSONドキュメントのコレクションと対話できます。既存のアプリケーション・コードは、リファクタリングしなくても、Oracle Autonomous JSON Databaseに格納されているデータを操作できます。
次の図は、データベース層、バックエンド層およびフロントエンド層で構成される一般的なアプリケーションを示しています。
mongodb-ajd-azure-logical-arch oracle.zip
このパターンの実装に使用される一般的なスタックは、MEANスタックで、ドキュメント・データベースとしてMongoDB、バックエンド・フレームワークとしてExpress、フロントエンド・フレームワークとしてAngular、バックエンド・サーバーとしてNode.jsを使用します。このドキュメントでは、AzureおよびAutonomous JSON Databaseに移行される既存のデプロイメントの例としてMEANスタックを使用します。
AzureおよびAutonomous JSON Databaseへのこのワークロードの移行は簡単で、次のステップの概要で構成されます:
- Autonomous JSON Databaseインスタンスをデプロイし、作成時にOracle Database MongoDB APIを有効にします。
- MongoDBからAutonomous JSON Databaseにメタデータおよびデータを移行します。
- Azureアプリケーション・サービス、仮想マシン、コンテナまたはKubernetesのいずれかを使用して
Node.jsおよびExpressを実行するアプリケーション・サーバーを、Autonomous JSON Databaseと同じリージョンおよび可用性ドメインにデプロイします。 - バックエンド・アプリケーション・コードをアプリケーション・サーバーにデプロイします。
- 現在のアプリケーションで使用されているものと同じMongoDBツールおよびドライバを使用して、バックエンド・アプリケーションをAutonomous JSON Databaseに接続します。
- ユーザーが新しいアプリケーションURIに接続するようにします。
このリファレンス・アーキテクチャは、移行プロセス自体ではなく、移行されたワークロードのデプロイメントに重点を置いています。移行プロセスの詳細は、「詳細」の項を参照してください。
ワークロードをAutonomous JSON Databaseに移行した後、既存の機能を拡張するために複数の機能を使用できます(1)機能のない追加の要件(容易など)をサポートしているかどうかに関係なく)。スケーラビリティ、回復性、高可用性を向上させるか、または2)運用レポート、分析、機械学習などの追加の機能機能を備えているため、データベースからデータをコピーする必要はありません。
スケーラビリティと高可用性を向上させるには、Autonomous JSON Databaseの自動スケーリング機能を使用します。1回のクリックまたはAPIコールで、ワークロードはダウンタイムなしでベースライン容量の3倍まで使用できます。Autonomous JSON Databaseでは、高可用性のためにOracle Real Application Clusters (Oracle RAC)テクノロジが使用されることに注意してください。バックエンド層では、コンピュート・インスタンス・プールを自動スケーリング・ルールとともに使用して、アプリケーションの高可用性とスケーラビリティを実現します。
Autonomous JSON Databaseはマルチモデルのマルチワークロード・データベース・テクノロジ上に構築されているため、既存のアプリケーションと連携して動作するリレーショナル、空間、グラフまたはベクトル・データ型に依存する機能を追加できます。ユーザーは、JSONデータに対して分析を実行することが一般的です。Autonomous JSON DatabaseでSQLを使用すると、同じエンジンとデータを使用して、運用レポートと分析レポートを簡単に作成できます。
Autonomous JSON Databaseには、JSON以外のデータの20 Gbの制限があります。データ・ボリュームの要件が変更された場合は、同じ機能をサポートするOracle Autonomous Database Serverlessに簡単に変換できます。ビューおよびマテリアライズド・ビューのストレージは、Autonomous JSON Database 20 Gbの非JSONデータ制限にカウントされないため、たとえば、JSONドキュメント上でSQLを使用した運用分析をサポートするために、簡単に作成して使用できます。
物理アーキテクチャ
物理アーキテクチャには、高可用性をサポートするために2つのMicrosoft Azureリージョンで委任サブネットを使用してデプロイされたAutonomous JSON Databaseが含まれます。OCIサービスは、Oracle Cloud Infrastructure Object Storageへの自動バックアップをサポートしています。
このアーキテクチャでは、次のものがサポートされています。
- フロントエンド層
- アプリケーション・ユーザーは、インターネットまたは企業ネットワークから接続できます。
- ユーザー接続は、Microsoft Azure Front Doorを使用して、アプリケーションを実行しているアクティブなリージョンにルーティングされます。
- ユーザー接続は、Azure Web Application Firewallを使用して保護されます。
- アプリケーションへのユーザー接続は、アプリケーション・サービスを使用してロード・バランシングされます。
- バックエンド層
- アプリケーションは、Azure App Serviceを使用して高可用性方式でデプロイされます。
- Azure App Service AutoScaleは、水平方向のスケーラビリティを実現するために使用されます。
- データベース階層
- Autonomous JSON Databaseは、Oracle Real Application Clusters (Oracle RAC)として高可用性を提供し、サービス・インスタンスを支える複数のデータベース・ノードを提供します。したがって、デフォルトでは、データベース層は高可用性で自己回復性があります。
- Autonomous JSON Databaseで有効になっているMongoDB用のOracle Database APIを使用すると、変更せずに既存のアプリケーション・コードを使用できます。
- Oracle Database API for MongoDBは非常に自己回復性があり、その自己回復性はAutonomous JSON Databaseによって内部的に保証されます。
- Autonomous JSON Databaseでは、自動スケーリングを使用して、システム負荷の増加と減少に合わせて調整できます。
- Autonomous JSON Databaseのビジネス継続性は、バックアップベースのクロス・リージョン・ディザスタ・リカバリによって実現されます。または、リフレッシュ可能クローンを使用できます。
- ディザスタ・リカバリ
- 2つのリージョンが、クラウド・デプロイメント全体のリージョン間ディザスタ・リカバリをサポートしています。
- プライマリ・リージョンのAutonomous JSON Databaseには、セカンダリ・リージョンにバックアップベースのクロス・リージョン・ピアがあります。
- 2つ目のリージョンは、同様のトポロジでデプロイされ、全体的なリカバリ時間の目標が短縮されます。
- ウォームDR戦略を使用して、RTO全体を削減します。ウォームDR戦略では、バックエンド層クラウド・リソースはすでにAutonomous JSON Databaseスタンバイ・データベースとともにプロビジョニングされています。
- あるいは、障害が発生した場合にバックエンド層リソースをプロビジョニングして、DRリソースの実行コストを削減し、RTO全体を増やすこともできます。
- ネットワーキング
- オンプレミスおよびインターネットからのすべてのアプリケーション受信トラフィックは、Azure Front Doorによってルーティングされます。
- Autonomous JSON Databaseは、セキュリティ・ポスチャを増やすためにプライベート・エンドポイントとともにデプロイされます。
- Azure App Serviceは、統合サブネットを使用してWebアプリケーションをデプロイし、VNetを使用してAutonomous JSON Databaseインスタンスにアクセスします。
- アプリケーションVNetはデータベースVNetとピアリングされ、トラフィックはWebアプリケーションとAutonomous JSON Databaseの間のフローが許可されます。
- セキュリティ
- すべてのデータは、転送中およびrestで安全です。
- 次の潜在的な設計改善は、このデプロイメントでは簡略化のために示されていません。
- Azure Automationランブックを使用してアプリケーションのディザスタ・リカバリを自動化し、フロント・ドア・エンドポイントを切り替え、フェイルオーバー後のアプリケーションの健全性を検証します。
- ハブ・トポロジとスポーク・トポロジを活用して、一元化されたネットワーク・セキュリティを強化します。
- ハブVNetにデプロイされたネットワーク・ファイアウォールを利用して、すべてのトラフィックを検査し、ポリシーを適用することで、全体的なセキュリティ状態を改善します。
次の図は、このリファレンス・アーキテクチャを示しています。
mongodb-ajd-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リソースで、相互、インターネットおよびオンプレミス・ネットワークと安全に通信できます。
- Azureアプリケーション・サービス
Azure App Serviceは、基盤となるインフラストラクチャを管理することなく、Webアプリケーション、API、およびモバイル バックエンドを構築、ホスティング、およびスケーリングできる完全管理型のPlatform-as-a-Service (PaaS)です。
- Azure App Service統合サブネット
Azure Virtual Network内の専用サブネットで、アプリケーション・サービス・プランで使用するために特別に委任され、Webアプリケーションは仮想ネットワークまたはそのピアリングされたネットワーク内のプライベート・リソースへのアウトバウンド接続を行うが、VNetからのインバウンド・トラフィックを受信することはできないようにします。
- Azure委任サブネット
委任サブネットを使用すると、マネージド・サービス(特にPlatform-as-a-Service (PaaS)サービスをリソースとして仮想ネットワークに直接挿入できます。仮想ネットワーク内の外部PaaSサービスの完全な統合管理が可能です。
このアーキテクチャには、次のOracleコンポーネントがあります。
- OCIのリージョン
OCIリージョンとは、可用性ドメインをホストする1つ以上のデータ・センターを含む、ローカライズされた地理的領域のことです。リージョンは他のリージョンから独立しており、長距離の場合は複数の国または大陸にまたがる領域を分離できます。
- OCIオブジェクト・ストレージ
OCIオブジェクト・ストレージでは、データベースのバックアップ、分析データ、イメージおよびビデオなどのリッチ・コンテンツなど、あらゆるコンテンツ・タイプの構造化データおよび非構造化データの大量へのアクセスを提供します。アプリケーションから直接、またはクラウド・プラットフォーム内から、安全かつ安全にデータを格納できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージを拡張することができます。
迅速、即時、頻繁にアクセスする必要のあるホット・ストレージに標準ストレージを使用します。長期間保存し、ほとんどまたはめったにアクセスしないコールド・ストレージにアーカイブ・ストレージを使用します。
- OCIプライベート・エンドポイント
OCI Private Endpoint provides no-cost, private, secure access to one of many OCI services from within a virtual cloud network (VCN) or on-premises network.
アーキテクチャ・バリアント
Oracle REST Data Servicesの構成および管理を手動で制御する要件がある場合は、顧客管理Oracle REST Data Servicesを使用することがオプションです。たとえば、アプリケーションがより大きな接続プールを使用できるようにします。
ノート:
特定のワークロード要件がある場合は、このアーキテクチャ・バリアントを使用します。上級ユーザーのみがこのアーキテクチャ・バリアントをデプロイする必要があります。このセクションでは、前述した物理アーキテクチャーとの違いについてのみ説明するため、特に明記しないかぎり、すべての物理アーキテクチャー設計原則が有効です。
次のアーキテクチャ図は、バリアントのデプロイ方法を示しています。デプロイメントのrestは前述した物理アーキテクチャと同じであるため、わかりやすくするために、JSONワークロードVCNにデプロイされているクラウド・リソースのみが示されます。
mongodb-ajd-azure-arch-variant-oracle.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サービス監視データとともにAutonomous JSON Databaseメトリックを監視することを検討してください。
- ディザスタ・リカバリ
- Azure Site Recoveryまたは障害を検出し、フェイルオーバー・プロセスを開始するカスタム・スクリプトを使用して、スタックのすべてのレイヤーの障害およびリカバリを自動化および調整することを検討してください。
- 業務効率
- Autonomous JSON Databaseワークロードがより広範なデータベース・フリートの一部である場合は、コスト効率を高めるためにエラスティック・プールの使用を検討してください。
- Autonomous JSON Databaseインスタンスの管理を合理化するために、データベース・パフォーマンスの監視および管理機能の包括的なセットを提供するOCIサービスであるOracle Cloud Infrastructure Database Managementを有効にすることを検討してください。
- アプリケーションの進化
- 信頼できるリアルタイムのデータ分析のために、データベースからデータを移動することなく、SQLやAPEXやPowerBIなどのフロントエンドを使用して、Autonomous JSON Databaseに運用分析とリアルタイム・レポートをデプロイすることを検討します
- Oracle Machine Learning (OML)を使用した機械学習にAutonomous JSON Databaseを使用することを検討し、データ移動を必要とせずにJSONデータを使用してモデルを構築およびトレーニングし、効率的な推論のために既存のワークロードとともにモデルをデプロイすることを検討してください。
- アプリケーション・コア以外のその他のユースケースについては、Autonomous JSON Databaseの使用を検討してください。ユーザーが自然言語を使用してJSONデータを問い合せることができるように、JSONを問い合せてメタデータを保持するAIビューおよびデータベース・ビューを選択します。
- ワークロード機能と柔軟性を高めるために、Autonomous JSON Databaseを使用して、最大20 Gbまでの追加のデータ型(リレーショナル、ベクトル、空間またはグラフ)を格納することを検討してください。