レプリカセットメンバーとシャーディングノードのリソース割り当て比較

MongoDBのリソース計画は、単一のレプリカセットからシャーディングクラスターに移行する際に大きく変化します。これらの目標を達成するための主要なアーキテクチャとして、レプリカセットとシャーディングクラスターの2つがあります。どちらも本番環境のMongoDBデプロイメントに不可欠ですが、その基盤となるリソース割り当て戦略は大きく異なり、インフラ設計とコストに直接影響を与えます。

レプリカセットは、完全なデータセットとほとんどの書き込み負荷を1つのプライマリに集中させます。シャーディングクラスターはデータをシャードレプリカセット全体に分散しますが、容量と監視も必要となるmongosルーターとコンフィグサーバーが追加されます。

MongoDBデプロイメント戦略の理解

リソース割り当ての詳細に入る前に、レプリカセットとシャーディングクラスターにおける各コンポーネントの役割を簡単に振り返りましょう。

レプリカセット：高可用性とデータ冗長性

MongoDBレプリカセットは、同じデータセットを維持するmongodインスタンスのグループです。これにより、高可用性とデータ冗長性が提供されます。レプリカセットは通常、以下の要素で構成されます。

• プライマリノード： すべての書き込み操作を受信する唯一のノードです。すべての変更をその操作ログ（oplog）に記録します。レプリカセット内には、常に1つのプライマリのみが存在できます。
• セカンダリノード： プライマリのoplogを複製し、これらの変更を自身のデータセットに適用して、データの一貫性を確保します。セカンダリノードは、読み取り設定に応じて読み取り操作を処理でき、現在のプライマリが利用できなくなった場合にプライマリに選出される可能性があります。
• アービタノード： プライマリを決定するための選挙に参加しますが、データは保存しません。アービタは最小限のリソースを消費し、別のデータ保持メンバーをデプロイできない場合に投票を追加するために使用されることがあります。すべての選挙問題を防ぐわけではなく、控えめに使用する必要があります。

シャーディングクラスター：水平スケーラビリティ

シャーディングは、複数のマシンにデータを分散するためのMongoDBの方法です。これにより、単一のレプリカセットでは処理できない大規模なデータセットと高スループットの操作を処理するための水平スケーリングが可能になります。シャーディングクラスターは、いくつかの主要なコンポーネントで構成されます。

• Mongos（クエリルーター）： クライアントアプリケーションとシャーディングクラスター間のインターフェースとして機能します。クエリを適切なシャードにルーティングし、結果を集約し、接続を管理します。
• コンフィグサーバー（CSRS）： どのデータ範囲がどのシャードにあるか（「シャードマップ」）を含む、クラスターのメタデータを保存します。コンフィグサーバーは、高可用性のためにレプリカセット（Config Server Replica Set - CSRS）としてデプロイされます。
• シャード： 各シャードはそれ自体がレプリカセットであり、クラスターのデータのサブセットを保持します。データはシャードキーに基づいてこれらのシャード全体に分散されます。

レプリカセットメンバーのリソース割り当て

レプリカセットメンバーのリソース要件は、その役割と全体的なワークロードによって大きく異なります。

プライマリノード

プライマリノードは、すべての書き込み操作と通常ほとんどの読み取り操作を処理するため、レプリカセットの中で最も重要でリソースを大量に消費するメンバーです。

• CPU： 高。 書き込み負荷の高いワークロード、複雑な集約パイプライン、インデックス操作、多数の同時接続の処理には、かなりのCPUパワーが必要です。アプリケーションが頻繁にドキュメントを更新したり、集中的なクエリを実行したりする場合、プライマリのCPUはすぐにボトルネックになる可能性があります。
• RAM： 重要。 MongoDBのWiredTigerストレージエンジンは、キャッシュにRAMを大きく依存しています。プライマリは、ディスクI/Oを最小限に抑えるために、頻繁にアクセスされるデータとインデックスをメモリに保持するのに十分なRAMを必要とします。一般的な推奨事項は、ワーキングセット（アプリケーションでアクティブに使用されるデータとインデックス）に加えて、ある程度のバッファを保持するのに十分なRAMを割り当てることです。
• ストレージ： 高いIOPSとスループット。 すべての書き込み操作は、ジャーナリングを含めてプライマリのディスクにヒットします。書き込みレイテンシがボトルネックになるのを防ぐには、高いIOPS（1秒あたりの入出力操作数）を備えた高速ストレージ（SSD/NVMe）が不可欠です。容量は、完全なデータセットとその成長、およびoplogスペースに十分である必要があります。

セカンダリノード

セカンダリノードはプライマリからデータを複製し、読み取り要求を処理してプライマリをオフロードできます。特に読み取りを処理する場合、そのリソース要件はプライマリと同様であることがよくあります。

• CPU： 中程度から高。 CPU使用率は、レプリケーションレートと読み取りワークロードによって異なります。セカンダリが読み取りのかなりの部分を処理する場合、そのCPU要件はプライマリのそれに近づく可能性があります。主にレプリケーションとフェイルオーバー用の場合、CPU使用率は低くなりますが、oplogエントリを効率的に適用するためには依然として重要です。
• RAM： 重要。 プライマリと同様に、セカンダリはWiredTigerキャッシュを維持し、過剰なディスクI/Oなしでoplogエントリを効率的に適用し、読み取りを処理するために、ワーキングセットを保持するのに十分なRAMを必要とします。フェイルオーバー時に一貫したパフォーマンスを実現するには、セカンダリのキャッシュは理想的にはプライマリのキャッシュをミラーリングする必要があります。
• ストレージ： 高いIOPSとスループット。 セカンダリは、oplogエントリを適用することにより、プライマリの書き込みに追従する必要があります。これも高いI/Oパフォーマンスを要求します。データの完全なコピーを保存するため、容量はプライマリと同一である必要があります。

ヒント： セカンダリノードがプライマリと同様にプロビジョニングされていることを確認してください。これにより、スムーズなフェイルオーバーと、セカンダリがプライマリになったときの一貫したパフォーマンスが保証されます。

アービタノード

アービタは、選挙に参加するためだけの軽量ノードです。データを保存したり、読み取り/書き込み操作を処理したりしません。

• CPU： 非常に低い。 アービタは、選挙プロトコルに関連する最小限の計算を実行します。
• RAM： 非常に低い。 基本的なmongodプロセスのオーバーヘッドと選挙状態に十分なメモリのみが必要です。
• ストレージ： 非常に低い。 最小限の設定ファイルとログファイルのみを保存し、データファイルは保存しません。

警告： アービタノードでアプリケーションや他のデータベースプロセスを実行しないでください。選挙の可用性を確保し、リソースの競合を防ぐために、専用の最小限のインスタンスである必要があります。

シャーディングコンポーネントのリソース割り当て

シャーディングクラスターは追加のコンポーネントを導入し、それぞれが独自のリソースプロファイルを持つため、より分散的で複雑なリソース割り当て戦略につながります。

Mongos（クエリルーター）

mongosインスタンスはステートレスなルーティングプロセスです。データを保存しませんが、シャード全体の操作を調整します。

• CPU： 中程度から高。 CPU使用率は、クライアント接続数、クエリルーティング作業、mongosが調整する必要があるスキャッターギャザークエリ、および集約マージ作業に応じて拡大します。より多くのmongosインスタンスを追加して、より高い負荷を処理できます。
• RAM： 中程度。 主に接続管理、コンフィグサーバーからのメタデータ（シャードマップ）のキャッシュ、および一時的な集約バッファに使用されます。データ保持ノードほど重要ではありませんが、十分なRAMによりスワッピングを防ぎ、応答時間を短縮できます。
• ストレージ： 非常に低い。 ログのみが保存されます。通常、ローカルSSDで十分以上です。

ヒント： 最適なパフォーマンスを得るには、ネットワークレイテンシを最小限に抑えるために、アプリケーションサーバーの近くにmongosインスタンスをデプロイします。

コンフィグサーバー（Config Server Replica Set - CSRS）

コンフィグサーバーは、クラスターの状態に関するメタデータを保存するため、シャーディングクラスターの運用にとって重要です。これらは常にレプリカセット（CSRS）としてデプロイされます。

• CPU： 中程度。 チャンクの移行、シャードのリバランシング、または頻繁なメタデータ更新中にCPU使用率が急上昇する可能性があります。データ保持プライマリほど高くはありませんが、一貫したパフォーマンスが不可欠です。
• RAM： 中程度から高。 重要なクラスターメタデータをメモリに保持するのに十分なRAMが必要です。メタデータのサイズは、シャード数、チャンク数、データベース数によって異なります。RAMが不十分だと、クラスターのパフォーマンスと安定性が著しく低下する可能性があります。
• ストレージ： 中程度のIOPSと容量。 メタデータのサイズは通常ユーザーデータよりも小さいですが、シャードマップやその他のクラスター状態情報の更新は頻繁に行われる可能性があり、適切なI/Oパフォーマンスが必要です。容量は、増大するメタデータとoplogに対応する必要があります。

警告： コンフィグサーバーのパフォーマンスと可用性は最も重要です。パフォーマンスが低下すると、シャーディングクラスター全体が機能しなくなる可能性があります。信頼性とパフォーマンスの高いインフラストラクチャでプロビジョニングしてください。

シャードメンバー（データ保持レプリカセット）

各シャードは自己完結型のレプリカセットであり、クラスターの全データのサブセットを保存します。したがって、各シャード内のプライマリ、セカンダリ、アービタノードのリソース要件は、性質的にはスタンドアロンのレプリカセットと似ていますが、保持するデータの部分に合わせてスケーリングされます。

• CPU： プライマリは高、セカンダリは中程度から高。 各シャードのプライマリは、そのデータサブセットに対するすべての書き込みと、場合によっては読み取りを処理します。要件は、その特定のシャードにルーティングされるワークロードに比例します。
• RAM： プライマリとセカンダリにとって重要。 各シャードのmongodは、保存するデータのワーキングセットに比例した、WiredTigerキャッシュに十分なRAMを必要とします。これは、データのセグメント内のパフォーマンスにとって重要です。
• ストレージ： プライマリとセカンダリにとって高いIOPSとスループット。 スタンドアロンのレプリカセットと同様に、シャードのデータサブセットに対する書き込み、読み取り、レプリケーションを処理するには、高速ストレージが必要です。容量は、シャードのデータ部分とその成長に十分である必要があります。

主な違い： 個々のシャードレプリカセットはスタンドアロンのレプリカセットと同様の要件を持ちますが、シャーディングクラスター全体は、総データとワークロードを複数のそのようなレプリカセットに分散します。つまり、すべてのシャードにわたるリソースの合計は、単一の垂直スケーリングされたレプリカセットよりも大幅に大きくなります。

リソース割り当ての比較：レプリカセット vs. シャーディングクラスター

特徴	レプリカセット（スタンドアロン）	シャーディングクラスター
目的	高可用性、データ冗長性、中程度のスケーリング	水平スケーリング、非常に大規模なデータセット、高スループット
総ノード数	一般的に3つのデータ保持メンバー。アービタは必要な場合のみ	3つのコンフィグサーバー + N個のシャードレプリカセット（通常各3メンバー以上） + M個のMongosインスタンス
CPU	プライマリがすべての書き込みCPUを処理。セカンダリが読み取りCPUを処理。アービタは最小限。	mongos、コンフィグサーバー、複数のシャードプライマリ全体に分散。全体的に総CPUは高い。
RAM	プライマリとセカンダリはワーキングセット全体に対してRAMが必要。	各シャードのプライマリ/セカンダリは、ワーキングセットのサブセットに対してRAMが必要。コンフィグサーバーはメタデータにRAMが必要。全体的に総RAMは高い。
ストレージ	プライマリとセカンダリはデータセット全体に対して容量とIOPSが必要。	各シャードのプライマリ/セカンダリは、データセットのサブセットに対して容量とIOPSが必要。コンフィグサーバーは中程度のIOPS/容量が必要。全体的に総ストレージは高い。
ボトルネック	書き込みのプライマリノード。単一マシンのリソース制限。	どのコンポーネント（mongos、コンフィグサーバー、個々のシャード）も、プロビジョニングが不十分な場合にボトルネックになる可能性がある。
複雑さ	セットアップと管理が比較的簡単。	計画、デプロイ、管理が大幅に複雑。
コスト	中程度のスケールではインフラコストが低い。	インスタンス数が多く分散型であるため、インフラコストが高い。

実践的な考慮事項とベストプラクティス

• ワークロード分析： アプリケーションの読み取り/書き込みパターン、データ成長予測、クエリの複雑さを徹底的に理解します。これはリソース計画において最も重要な要素です。
• 監視が鍵： すべてのMongoDBコンポーネント（CPU、RAM、ディスクI/O、ネットワーク、WiredTigerキャッシュ使用率、oplogラグ、クエリ時間などのデータベースメトリクス）の包括的な監視を実装します。これにより、ボトルネックを特定し、プロアクティブなスケーリングが可能になります。
• ネットワークパフォーマンス： シャーディングクラスターの場合、mongos、コンフィグサーバー、シャード間のネットワークレイテンシと帯域幅が重要です。シャード間通信とデータバランシング操作は、ネットワークパフォーマンスの低下によって大きな影響を受ける可能性があります。
• 専用リソース： 各mongodプロセス（プライマリ、セカンダリ、シャードメンバーを問わず）は、専用のハードウェアまたは専用の仮想マシンで実行する必要があります。リソースの競合を防ぐために、アプリケーションサーバーや他のデータベースインスタンスと同じ場所に配置しないでください。
• クラウド vs. オンプレミス： クラウドプロバイダーは、リソースを簡単にスケーリングできる柔軟性を提供します。ただし、特にストレージ集約型の操作では、選択したインスタンスタイプがIOPSとスループットの要件を満たしていることを確認してください。
• テストとベンチマーキング： 本番環境に移行する前に、計画したインフラストラクチャを現実的なワークロードで常にテストしてください。これにより、リソース割り当ての前提を検証できます。

まとめ

ワーキングセット、書き込みレート、ストレージが1つのデータ保持ノードクラスに快適に収まる場合は、レプリカセットを使用します。水平スケーリングが必要な場合はシャーディングに移行しますが、シャードレプリカセット、コンフィグサーバー、ルーター、ネットワーク容量、およびより多くの運用テストといった追加の可動部分に予算を計上してください。