MongoDB Search 配置オプション

ノード アーキテクチャ

テストおよびプロトタイプ作成環境には、 MongoDBプロセスとMongoDB Search プロセスが 同じノードで実行されるノードアーキテクチャを推奨します。この配置モデルの次の図では、 MongoDB Search mongot プロセスが Atlas クラスター内の各ノードで mongod と並行して実行され、これらは同じリソースを共有しています。

デフォルトでは 、Atlas は 最初のMongoDB Searchインデックスを作成するときに、mongod プロセスを実行するのと同じノードでMongoDB Search mongot プロセスを有効にします。

MongoDB Search がこのアーキテクチャでクエリをプロセシングする方法については、 クエリプロセシングを参照してください。

MongoDB Searchインデックスで 保存済みソース フィールド を定義すると、mongot プロセスは mongot の指定フィールドを保存できます。次に、 MongoDB Search クエリで returnStoredSource オプション を使用すると、データベースでドキュメント全体を検索する代わりに、mongot から一致するドキュメントの保存済みフィールドを直接検索できます。

メリット

MongoDB Search を有効にすると、データベースに自動的に同期する統合された完全管理検索エンジンを使用して、データ上に検索を簡単に構築できます。MongoDB Search は、全文検索用の $search や $searchMeta などのMongoDB Search集計パイプラインステージ、セマンティック検索用の $vectorSearch などの MongoDB Search 集計パイプライン ステージを、他のMongoDB集計パイプラインステージやスコアベースの結果ランキングと組み合わせて使用する豊富な問い合わせ言語を提供します。

クラスターにプロビジョニングされるリソースによっては、同じノードに両方の プロセスを配置した方が、別個の 専用ノードで検索プロセスを実行中よりもコスト効率が高くなる場合があります。

制限

データベースmongod と検索 mongot プロセス間でリソース競合が発生する可能性があります。これは、インデックスのパフォーマンスとクエリのレイテンシに影響可能性があります。本番環境に対応できるアプリケーションとその検索ワークロードをサポートするには、専用の検索ノードに移行します。

コスト

クラスターでMongoDB Search を有効にしても、追加料金や料金は発生しません。ただし、大規模なインデックス付きコレクションまたはインデックス定義では、クラスターのリソース使用率が増加する可能性があります。

Considerations

mongod プロセスと mongot プロセスの両方が 同じノードで実行されるため、特定の状況下で mongot が使用できなくなる可能性があります。 次の表では、潜在的な原因について説明しています。

ノード アーキテクチャ

本番環境では、 MongoDBプロセスとMongoDB Search プロセスが別々のノードで実行されるノードアーキテクチャを推奨します。個別の検索ノードを配置するには、専用検索ノードへの移行を参照してください。

この配置モデルの次の図では、 MongoDB Search mongot プロセスは専用の検索ノードで実行されます。このノードは、mongod プロセスが実行されるクラスター ノードとは別です。

Atlas は、各クラスターまたはクラスター上の各シャードに検索ノードを配置します。たとえば、3 つのシャードを持つクラスターに 2 つの検索ノードを配置すると、Atlas は 6 つの検索ノード（シャードあたり 2 つ）を配置します。また、検索ノードの数と、各検索ノードにプロビジョニングされるリソースの量を構成することもできます。

MongoDB Search がこのアーキテクチャでクエリをプロセシングする方法については、 クエリプロセシングを参照してください。

MongoDB Searchインデックスで 保存済みソース フィールド を定義すると、mongot プロセスは mongot の指定フィールドを保存できます。次に、 MongoDB Search クエリで returnStoredSource オプション を使用すると、データベースでドキュメント全体を検索する代わりに、mongot から一致するドキュメントの保存済みフィールドを直接検索できます。

メリット

別個の検索ノードを配置すると次のメリットが得られます。

高可用性

別個の検索ノードを配置すると、Atlas は少なくとも 2 つの検索ノードを強制して、障害や中断が発生した場合にワークロードが最小限のダウンタイムで機能し続けるようにします。

スケーラビリティ

検索ノードを個別に配置すると、MongoDB クラスターから独立してストレージと計算能力をスケールできます。これにより、MongoDB とは独立してクエリ負荷をスケールすることも可能です。

検索ノードを水平方向に増やすするには、検索ノードの数を増減します。最小 2 から最大 32 の検索ノードまでプロビジョニングできます。クエリの負荷を分散するために、 MongoDB Search は検索クエリを利用可能なすべての検索ノードに分散します。

検索ノードを垂直方向にスケールするには、フルテキストワークロードをサポートするさまざまな検索階層、CPU、RAM、およびストレージ構成を選択します。

パフォーマンス

専用の検索ノードを導入することで、mongodおよび mongotプロセスのパフォーマンスとリソース利用率が向上し、これらのプロセス間のリソース競合が解消されます。

専用検索ノードは同時セグメント検索をサポートしているため、 MongoDB Search は複数のインデックスセグメントを同時に検索できます。同時セグメント検索を使用すると、クエリの応答時間が改善される場合があります。

ワークロードの分離

専用の検索ノードを配置しても、メインのデータベースノードへのデータ転送には直接影響しません。検索ノードは検索クエリをデータベースのメイン操作とは別に処理するため、ワークロードを分離できますが、検索ノードとデータベースノード間のトラフィックに対してのみネットワーク料金が発生します。

検索ノードのサイズ設定とスケーリングに関するヒント

検索ノードのメモリ要件を決定するには、次の Atlas メトリクスを使用します。

• 検索インデックスのサイズ

• 検索ノード上の RAM の合計

検索インデックスが 10 GB で、検索ノードの合計 RAM が 4 GB のアプリケーションを考えてみましょう。この場合、1GBのRAMが他のプロセスで使用され、インデックスデータ用に3GBのみが使用可能な場合、残りの7GBのインデックスデータ（10GB - 3GB = 7GB）は、必要に応じてディスクからページインされます。ディスクからの頻繁なページングは、ページフォールト、ディスク I/O、CPU IOWait の増加を引き起こし、パフォーマンスの低下を招きます。

8GB 以上の RAM を持つ上位のクラスター階層を使用すると、Atlas は検索インデックスの大部分のデータをメモリから提供でき、ディスクの読み取りとページ フォールトを最小化され、パフォーマンスが向上します。

検索ノードのコスト

MongoDB は（M10 以上）の専有クラスターで個別の検索ノードをサポートします。検索ノードは、コンピュート集約型インスタンスに配置され、高性能なローカル ストレージを備えています。最低 2 つのノードを配置する必要があります。ノードごとのリソース使用量が時間単位で毎日請求されます。詳細については、「検索ノードのコスト」を参照してください。

保存時の暗号化の有効化

デフォルトでは、MongoDBプロセスと検索プロセスは同じノードで実行されます。このアーキテクチャでは、カスタマー マネージドの暗号化はデータベースデータに適用されますが、検索インデックスには適用されません。

専用の検索ノードを有効にすると、検索プロセスは別々のノードで実行されます。これにより、検索ノード データの暗号化が有効になり、データベースデータと検索インデックスの両方を同じカスタマー マネージド キーで暗号化して、包括的な暗号化をカバレッジすることができます。

詳細については、「検索ノードのカスタマーキー管理を有効にする」を参照してください。

専用検索ノードの追加

新しいクラスターに専用の検索ノードを追加すると、次のことが可能になります。

• 検索配置のサイズと増やすは、データベース配置とは独立して変更します。

• MongoDBデータベースと検索プロセスを同じノードで実行するクラスターで発生する可能性のあるリソース競合を解消します。

専用の検索ノードを配置するには、プロジェクトへの Project Owner アクセスが必要です。

専用の検索ノードを追加するには以下の手順に従います。

1. ノード分離をサポートするクラウドプロバイダーとリージョンで、M10 以上の階層としてクラスターを作成します。詳細については、「クラスターの作成」を参照してください。

   専用検索ノードは、M10 以上のクラスター階層と、ノード分離をサポートするクラウドプロバイダーリージョンでのみサポートされます。

2. Search Nodes for workload isolationと検索ノードを構成する を有効にします。

専用検索ノードへの移行

ステージングから本番環境に移行し、専用の検索ノードを追加するには、既存のステージングとプロトタイプ作成の配置に次の変更を加えます。

1. 配置でフレックス クラスターを使用している場合は、クラスター階層を上位の階層に変更します。専用検索ノードは、M10 以上のクラスター階層のみサポートされます。

2. 検索ノードも利用可能なリージョンにクラスターを配置します。専用の検索ノードは、Amazon Web Services および Azure の一部のリージョンと、サポートされているすべての Google Cloud Platform リージョンで利用できます。既存のクラスターが検索ノードを利用できないリージョンでホストされている場合は、検索ノードを利用できるリージョンにクラスターを移行してください。詳細については、「ノード分離をサポートするクラウドプロバイダーのリージョン」を参照してください。

3. Search Nodes for workload isolation を有効にして、検索ノードを構成します。詳しくは、「検索ノードを追加する」を参照してください。

   専用の検索ノードを配置すると、次の一連のアクションが実行されます。

   • Atlas は検索ノードに検索インデックスを構築し、クラスター ノードからインデックスを削除します。

   • Atlas は検索クエリを検索ノードにルーティングします。

   • MongoDB Search は、検索インデックスを使用してクラスターにクエリを処理します。

配置のトラブルシューティング