Oracle Autonomous Transaction Processing Serverless@Google Cloudへの移行されたMongoDBワークロードのデプロイ
ドキュメントやドキュメント・データベースを使用してデータ・スキーマやアプリケーションを進化させるワークロードやアプリケーションは、開発者に提供される柔軟性のために非常に人気があります。スキーマの柔軟性、迅速な開発およびスケーラビリティにより、アプリケーション機能の迅速なプロトタイピング、アプリケーションの進化の容易化、および開発者が大規模なユーザー・ベースに対応するために拡張できる反復的に小さいアプリケーションや機能の構築が保証されます。ただし、このようなタイプのワークロードには、トランザクションの保証の低下、データ問合せの汎用性、分析や機械学習などのドキュメントで他のワークロードをサポートできないという課題があります。
これらのワークロードが従来のドキュメント・データベースのメリットを享受し、リレーショナル・データベースのメリットを活用できるとしたら?たとえば、データを別のデータベースやシステムにレプリケートする必要なく、トランザクション上の保証を強化し、分析や機械学習などの機能を追加することができます。
Autonomous Transaction Processing (ATP)サーバーレスは、トランザクション・ワークロード、分析ワークロードおよびバッチ・ワークロードを同時に実行するように最適化された、完全に自動化されたデータベース・サービスです。パフォーマンスを加速するために、拡張性、可用性、透過的なセキュリティ、リアルタイムの運用分析を提供しながら、行形式、索引、データ・キャッシュ用に事前構成されています。アプリケーション開発者とDBAは、機能性や原子性、一貫性、分離および耐久性(ACID)プロパティを犠牲にすることなく、迅速かつコスト効率よくアプリケーションを開発およびデプロイできます。
機能アーキテクチャ
このアーキテクチャでは、開始点として、アプリケーションとMongoDBデータベースを含むワークロードが存在し、オンプレミスまたはクラウド・デプロイメントのいずれかが存在し、Google CloudおよびOracle Database@Google Cloudに移行することを前提としています。将来の状態アーキテクチャ、その利点、デプロイ方法、および既存のワークロードを拡張するために使用できる追加機能について説明します。
このアーキテクチャで使用される主な機能の1つは、Oracle Database API for MongoDBです。これにより、アプリケーションは、MongoDBドライバ、ツールおよびSDKを使用して、Oracle Database内のJSONドキュメントのコレクションと対話できます。既存のアプリケーション・コードは、コードをリファクタすることなく、Autonomous Transaction Processingサーバーレスに格納されたデータを操作できます。
次の図は、データベース層、バックエンド層およびフロントエンド層で構成される一般的なアプリケーションを示しています。
mongodb-atp-s-google-logical-arch-migration.zip
MEANスタックは、このパターンの実装に使用される一般的なスタックです。
- MongoDB: ドキュメント・データベース
- Express: バックエンド・フレームワーク
- Angular: フロントエンドフレームワーク
Node.js: バックエンド・サーバー
このドキュメントでは、Google CloudおよびATP Serverlessに移行される既存のデプロイメントの例としてMEANスタックを使用します。
このワークロードのGoogle CloudおよびATP Serverlessへの移行は簡単で、次のステップの概要で構成されます。
- ATPサーバーレス・インスタンスをデプロイし、作成時にOracle Database MongoDB APIを有効にします。
- MongoDBからATPサーバーレスにメタデータおよびデータを移行します。
- Google Cloud Run、VM、コンテナまたはKubernetesを使用して
Node.jsおよびExpressを実行するアプリケーション・サーバーを、ATP Serverlessと同じリージョンおよび可用性ドメインにデプロイします。 - バックエンド・アプリケーション・コードをアプリケーション・サーバーにデプロイします。
- 現在のアプリケーションで使用されているものと同じMongoDBツールおよびドライバを使用して、バックエンド・アプリケーションをATPサーバーレスに接続します。
- ユーザーを新しいアプリケーションURIに接続します。
このリファレンス・アーキテクチャは、移行プロセス自体ではなく、移行されたワークロードのデプロイメントに重点を置いています。移行プロセスの詳細は、「詳細」の項を参照してください。
ワークロードをATP Serverlessに移行した後、既存の機能を拡張するためにいくつかの機能を使用できます。1)スケーラビリティ、回復性、高可用性の向上など、追加の非機能要件をサポートするか、2)運用レポート、分析、機械学習などの追加の機能機能を備えているかに関係なく、データベースからデータをコピーする必要はありません。
スケーラビリティと高可用性を向上させるには、Autonomous Transaction Processingサーバーレス自動スケーリング機能を使用します。1回のクリックまたはAPIコールで、ワークロードはダウンタイムなしでベースライン容量の3倍まで使用できます。Autonomous Transaction Processingサーバーレスは、高可用性のためにOracle Real Application Clusters (Oracle RAC)テクノロジを使用します。バックエンド層の場合は、自動スケール設定でVMスケール・セットを使用するか、アプリケーションの高可用性およびスケーラビリティを有効にするために自動スケーリング設定でアプリケーション・サービスなどのPaaSサービスを使用します。
ATP Serverlessはマルチモデルのマルチワークロード・データベース・テクノロジの上に構築されているため、既存のアプリケーションと連携して動作するリレーショナル、空間、グラフまたはベクトル・データ型に依存する機能を追加できます。
物理アーキテクチャ
物理アーキテクチャには、高可用性をサポートするために、2つのGoogle Cloudリージョンで委任サブネットを使用してデプロイされたAutonomous Transaction Processingサーバーレスが含まれます。OCIサービスは、Oracle Cloud Infrastructure Object Storageへの自動バックアップをサポートしています。
このアーキテクチャでは、次のものがサポートされています。
- フロントエンド層
- アプリケーション・ユーザーはインターネットから接続できます。
- ユーザー接続は、グローバル・クラウド・ロード・バランサを使用して、アプリケーションを実行しているアクティブなリージョンにルーティングされます。
- ユーザー接続はCloud Armorを使用して保護されます。
- アプリケーションへのユーザー接続は、外部グローバル・アプリケーション・ロード・バランサを使用してロード・バランシングされます。
- バックエンド層
- アプリケーションは、クラウド実行を使用して高可用性でデプロイされます。
- クラウド実行の自動スケーリングは、水平方向のスケーラビリティを実現するために使用されます。
- データベース階層
- ATPサーバーレスは、Oracle Real Application Clusters (Oracle RAC)およびサービス・インスタンスを支える複数のデータベース・ノードとして、高可用性を提供します。したがって、デフォルトでは、データベース層は高可用性で自己回復性があります。
- ATPサーバーレスで有効になっているOracle Database API for MongoDBを使用すると、既存のアプリケーション・コードを変更できます。
- Oracle Database API for MongoDBは高い耐障害性を持ち、ATPサーバーレスによって内部的に耐障害性が保証されます。
- ATPサーバーレスでは、自動スケーリングを使用して、システムの負荷が増減したときに調整できます。
- ATPサーバーレス・ビジネス継続性は、リージョン間のAutonomous Data Guardによって実現されます。
- ディザスタ・リカバリ
- 2つ目のリージョンは、同様のトポロジでデプロイされ、全体的なリカバリ時間の目標が短縮されます。
- ウォームDR戦略を使用して、RTO全体を削減します。ウォームDR戦略では、バックエンド層のクラウド・リソースは、ATPサーバーレス・スタンバイ・データベースとともにすでにプロビジョニングされています。
- あるいは、障害が発生した場合にバックエンド層リソースをプロビジョニングして、DRリソースの実行コストを削減し、RTO全体を増やすこともできます。
- ネットワーキング
- オンプレミスおよびインターネットからのすべてのアプリケーションの受信トラフィックは、Cloud Load Balancerによってルーティングされます。
- ATP Serverlessは、セキュリティ体制を強化するためにプライベート・エンドポイントとともにデプロイされます。
- Cloud Runは、VPC内のアプリケーション・サブネットに配置されたサーバーレスVPCアクセス・コネクタを使用してデプロイされ、ATPサーバーレス・インスタンスにアクセスします。
- サーバーレスVPCアクセス・コネクタを使用すると、ATPサーバーレス・インスタンスへのプライベート接続を確立できます。
- セキュリティ
- すべてのデータは、転送中および保存中に安全です。
次の潜在的な設計改善は、このデプロイメントでは簡略化のために示されていません。
- Cloud Monitoringのアラート、Pub/Sub、Cloud Functionsを使用してアプリケーションのディザスタ・リカバリを自動化します。
- ハブ・トポロジとスポーク・トポロジを活用して、一元化されたネットワーク・セキュリティを強化します。
- ハブVPCにデプロイされたネットワーク・ファイアウォールを利用して、すべてのトラフィックを検査し、ポリシーを適用することで、全体的なセキュリティ状態を改善します。
mongodb-atp-s-google-physical-arch.zip
このアーキテクチャには、次のGoogleコンポーネントがあります。
- Google Cloudリージョン
Google Cloudリージョンは、リソースをホスティングするためのデータ・センターとインフラストラクチャを含む地理的な領域です。リージョンはゾーンで構成され、ゾーンはリージョン内で相互に分離されます。
- Google Cloudゾーン
Google Cloudのゾーンは、リージョン内のリソースのデプロイメント領域です。ゾーンはリージョン内で相互に分離され、単一の障害ドメインとして扱われます。
- Google Cloudプロジェクト
Google Cloudプロジェクトは、Google Workspace APIを使用し、Google Workspaceアドオンまたはアプリを構築するために必要です。クラウド・プロジェクトは、APIの管理、請求の有効化、コラボレータの追加と削除、権限の管理など、すべてのGoogle Cloudサービスの作成、有効化および使用の基礎となります。
- Google仮想プライベート・クラウド
Google Virtual Private Cloud(VPC)は、Compute Engine仮想マシン(VM)インスタンス、Google Kubernetes Engine(GKE)コンテナ、データベース・サービスおよびサーバーレス・ワークロードにネットワーキング機能を提供します。VPCは、クラウドベースのサービスに、グローバルでスケーラブル、かつ柔軟なネットワーキングを提供します。
- Googleサブネット
各Google Virtual Private Cloud(VPC)ネットワークは、サブネットと呼ばれる1つ以上のIPアドレス範囲で構成されます。サブネットは、IPアドレス範囲が関連付けられているリージョナル・リソースです。
- Googleロード・バランサ
Googleロード・バランサは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- Googleクラウドアーマー
Google Cloud Armorは、分散型サービス拒否(DDoS)攻撃およびWebアプリケーションの脅威(クロスサイト・スクリプティング(XSS)やSQLインジェクションなど)に対するエンタープライズ・グレードの保護を提供するネットワーク・セキュリティ・サービスであり、常時オンのDDoS防御、事前構成およびカスタマイズ可能なルールを備えたWebアプリケーション・ファイアウォール(WAF)、およびアプリケーションの適応性の高い機械学習ベースの脅威検出を組み合せます。
- Google Cloudの実行
Google Cloud Runは、完全に管理されたサーバーレス・コンピュート・プラットフォームで、コンテナ化されたアプリケーション、API、バッチ・ジョブをGoogleのスケーラブルなインフラストラクチャ上で直接実行でき、自動スケーリング、統合されたセキュリティを備えており、サーバーやクラスタを管理する必要はありません。
このアーキテクチャには、次の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オブジェクト・ストレージでは、データベースのバックアップ、分析データ、イメージおよびビデオなどのリッチ・コンテンツなど、あらゆるコンテンツ・タイプの構造化データおよび非構造化データの大量へのアクセスを提供します。アプリケーションから直接、またはクラウド・プラットフォーム内から、安全かつ安全にデータを格納できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージを拡張することができます。
迅速、即時、頻繁にアクセスする必要のあるホット・ストレージに標準ストレージを使用します。長期間保存し、ほとんどまたはめったにアクセスしないコールド・ストレージにアーカイブ・ストレージを使用します。
アーキテクチャ・バリアント
提案された物理アーキテクチャのこのバリアントは、各アプリケーション・サーバーで実行されている顧客管理Oracle REST Data Servicesデプロイメントを使用します。ただし、ATP Serverlessによって提供されるフルマネージドMongoDB APIは、管理が容易であるため、ほとんどのワークロードに最適なソリューションです。
Oracle REST Data Servicesの構成および管理を手動で制御する要件がある場合は、顧客管理Oracle REST Data Servicesを使用することがオプションです。たとえば、アプリケーションがより大きな接続プールを使用できるようにします。
ノート:
特定のワークロード要件がある場合は、このアーキテクチャ・バリアントを使用します。上級ユーザーのみがこのアーキテクチャ・バリアントをデプロイする必要があります。このセクションでは、前述した物理アーキテクチャーとの違いについてのみ説明するため、特に明記しないかぎり、すべての物理アーキテクチャー設計原則が有効です。
次のアーキテクチャ図は、バリアントのデプロイ方法を示しています。JSONワークロードVCNにデプロイされたクラウド・リソースのみがわかりやすくなります。これは、デプロイメントの残りの部分は前述の物理アーキテクチャと同じであるためです。
mongodb-atp-s-google-arch-variant.zip
- 受信ユーザー・リクエストは、クラウド実行サーバーレス・ネットワーク・エンドポイント・グループ(NEG)をバックエンドとして使用するクラウド・ロード・バランサによって分散されます。この設定により、水平スケーリングが可能になり、単一障害点が排除されます。
- バックエンド・アプリケーションは、クラウド実行コンテナとしてデプロイされます。
- Cloud Runは、既存のコンテナの負荷に応じて、コンテナを横方向にスケーリングします。
- アプリケーションとOracle REST Data Servicesを使用してコンテナを作成、インストールおよび構成します。これにより、両方を同じコンテナで実行できます。
- 各ワーカーは、同じランタイム環境でアプリケーションとOracle REST Data Servicesをコロケーションするコンテナ・イメージを実行します。
- 顧客管理のOracle REST Data Servicesワーカーは、MongoDB APIを有効にするように構成されているため、アプリケーションはMongoDBツールおよびドライバを使用してデータベースに接続できます。
- 顧客管理のOracle REST Data Servicesは、たとえば、より大きな接続プールを構成するか、別のデータベース・サービスを使用して、ワークロード非機能要件に合せて構成されます。
- バックエンド・コードと顧客管理Oracle REST Data Servicesの両方が、ワーカーで使用されるコンテナ・イメージにプリインストールおよび事前構成されています。クラウド実行が水平にスケーリングされると、新しいワーカーはバックエンド・アプリケーションを実行し、プロビジョニング後にデータベースに接続できます。
レコメンデーション
- アプリケーションのデプロイ
- クラウド実行で使用できない可能性のある高度なオーケストレーション、ネットワーキングおよびセキュリティ機能が必要な場合は、Google Kubernetes Engine (GKE)を使用したコンテナ・ベースのデプロイメントの使用を検討してください。
- セキュリティ
- Oracle Data Safeを使用して、ワークロードのセキュリティ体制をさらに高め、データベース監査を実行することを検討してください。
- 観測性
- Google Cloud Monitoringを使用して、他のすべてのGoogle Cloudサービス監視データとともにATPサーバーレス・メトリックを監視することを検討してください。
- ディザスタ・リカバリ
- Googleパートナーソリューションまたは障害を検出し、フェイルオーバープロセスを開始するカスタムスクリプトを使用して、スタックのすべてのレイヤーの障害と回復を自動化および調整することを検討してください。
- 業務効率
- ATPサーバーレス・ワークロードがより広範なデータベース・フリートの一部である場合は、コスト効率を高めるためにエラスティック・プールを使用することを検討してください。
- ATPサーバーレス・インスタンスの管理を合理化するために、データベース・パフォーマンスの監視および管理機能の包括的なセットを提供するOCIサービスであるOracle Cloud Infrastructure Database Managementを有効にすることを検討してください。
- アプリケーションの進化
- 信頼できるリアルタイムのデータ分析のために、データベースからデータを移動することなく、SQLやOracle APEXやLookerなどのフロントエンドを使用して、ATP Serverlessに運用分析とリアルタイム・レポートをデプロイすることを検討してください。
- Oracle Machine Learning (OML)を使用した機械学習にATP Serverlessを使用することを検討し、データ移動を必要とせずにJSONデータを使用してモデルを構築およびトレーニングし、効率的な推論のためにモデルを既存のワークロードとともにデプロイすることを検討します。
- アプリケーション・コア以外のユースケースについては、ATPサーバーレス選択AIおよびデータベース・ビューを使用してJSONを問い合せ、メタデータを保持し、ユーザーが自然言語を使用してJSONデータを問い合せることができるようにすることを検討してください。
- ワークロードの機能と柔軟性を高めるために、ATP Serverlessを使用して追加のデータ型(リレーショナル、ベクトル、空間またはグラフ)を格納することを検討してください。
詳細の参照
このアーキテクチャの機能についてさらに学習します。
次の追加のリソースを確認します。
- Oracleデータ・プラットフォーム
- Oracle Autonomous Transaction Processing Serverlessのドキュメント
- Google向けAutonomous Databaseサービス
- Oracle Database API for MongoDB
- Oracle Autonomous Database Serverlessの使用
次の追加のリソースを確認します。