MongoDB - アーキテクチャーのベスト・プラクティス

MongoDB 上のデプロイメントで IBM Cloud® を使用するために、以下のベスト・プラクティスを使用してください。エンジニアリング・サーバーを選択した場合、これらの推奨事項のいくつかはすでに実装されています。

デプロイメント・ストラテジー

MongoDB のデプロイメントを計画する際には、いくつかの重要な領域について考慮する必要があります。最も重要な領域は、データ・セットの現行サイズと予想されるサイズです。この 2 つの領域は、個々の物理ノード・リソースのニーズを選択するための主な要因であり、シャーディング・プランの指針となります。また、データの重要性も考慮する必要があり、どの程度のデータの損失や遅れの可能性を許容できるかを検討する必要があります (特に、複製シナリオの場合)。

メモリーのサイジング

MongoDB は (多くのデータ指向アプリケーションと同様)、データ・セットがメモリー内に存在している場合に最も効果的に機能します。ディスク入出力を必要としない MongoDB インスタンスほどパフォーマンスが優れているものはありません。可能な限り、作業データ・セットのサイズよりも使用可能な RAM の容量のほうが大きいプラットフォームを選択してください。データ・セットが単一ノードの使用可能な RAM を超える場合、シャーディングの利用を考えてください。シャーディングは、クラスター内の使用可能な RAM の量を増やし、より大きなデータ・セットを収容できるようにします。これにより、デプロイメントの全体的なパフォーマンスを最大化できます。ページ不在は、デプロイメントの使用可能な RAM を超えている可能性があることを示す場合があります。使用可能な RAM を増やすことを検討する必要があります。

ディスク・タイプ

速度は問題ではない場合、あるいは使用可能メモリー戦略でサポートできる大きさを超えるデータ・セットがある場合、デプロイメントに適切なディスク・タイプを使用することが重要です。 IOPS がディスク・タイプの選択の鍵になります。 IOPS が高いほど、MongoDB のパフォーマンスが優れています。ネットワーク・ストレージは、デプロイメントの長い待ち時間およびパフォーマンスの低下の原因になるため、可能であれば、ローカル・ディスクを使用する必要があります。ディスク・アレイには RAID 10 を使用することをお勧めします。

CPU

map-reduce を使用する場合、クロック速度と使用可能なプロセッサー数が検討対象となります。ただし、ほとんどのデータがメモリー内にある状態で MongoDB インスタンスを実行する場合は、クロック速度がパフォーマンスに影響する可能性があります。ご使用のシステムがそのような状況下で稼働するときに、1 秒当たりの処理を最大化させたい場合は、バスクロックが高速である CPU を組み込んだデプロイメント・ストラテジーを検討してください。

複製する

複製は、クラスター内のノードに障害が発生した場合に、データの高可用性を実現します。最良の結果を得るには、任意の MongoDB デプロイメントで、少なくとも 3 つのノードを使用して複製を行います。 3 つのノードを使用した複製の最も一般的な構成は、2x1 デプロイメントです。つまり、1 つのデータ・センターに 1 次ノードを 2 つ配置し、2 次データ・センターにバックアップ・サーバーを 1 つ配置します。

シャーディング

[: #dbtシャーディング]

大きなデータ・セットが予想される場合は、シャード MongoDB デプロイメントをデプロイすることをお勧めします。シャーディングを使用して、データ・セットを複数のノードにパーティション化することができます。MongoDB では、クラスター内の複数ノード間でデータを自動的に分散できます。あるいは、シャード・キーを定義し、そのキーに対して、範囲に基づいたシャーディングを作成できます。シャーディングは書き込みパフォーマンスに役立つため、データ・セットが小さい場合でも、多数の更新または挿入を必要とする場合は、シャードを行うことができます。シャード・セットをデプロイする場合、MongoDB では、3 つの構成サーバー・インスタンスのみ必要です。これらは、現行シャード構成のトラッキング専用の Mongo ランタイムです。これらのノードの1つを失うと、クラスタはコンフィギュレーションのみの読み取り専用モードになり、コンフィギュレーションを変更する前にすべてのノードをオンラインに戻す必要があります。

書き込み安全モード

MongoDB でのディスクに対するデータの永続性の対応方法を制御する書き込み安全モードには、複数のオプションがあります。データ保全性とパフォーマンスの両方にとって、どの戦略がニーズに最適かを検討することが重要です。使用可能な書き込み安全モードは、次のとおりです。

None- ノンブロッキングの遅延書き込みストラテジーを提供する。しかし、ノードの故障やデータの損失は、小さな可能性である。また、クラスター内の 1 つのノードに書き込まれたデータが、そのクラスターのすべてのノードでは、読み取りの整合性のために、即時に使用可能にならない場合もあります。「None」モードでは、ネットワーク障害に対するデータ保護は提供されません。このモードは信頼性が極めて低いため、その使用は、パフォーマンスが優先されてデータ保全性は問題ではない場合に限ってください。
Normal – MongoDB のデフォルトです。ノーマル・モードもノンブロッキング遅延書き込み戦略である。
Safe – MongoDB が書き込み要求を受け取ったことを認識するまでブロックしますが、書き込みが完了するまでブロックします。「Safe」モードは、より高度なレベルのデータ保全性とクラスター内の読み取り整合性を提供します。
Journal Safe – MongoDB のリカバリー・オプションを提供します。 Journal Safe モードでは、必ずデータが確認され、戻す前にジャーナルの更新が完了しているようになります。
Fsync – 最高レベルのデータ保全性が提供され、データの物理書き込みが実行されるまでブロックされます。「Fsync」の使用はパフォーマンスの低下を伴うため、アプリケーションのデータ保全性が主要な関心事である場合にのみ使用してください。

デプロイメントのテスト

10gen には、デプロイメントのロード・テストに役立ついくつかのツールが用意されています。コンソール・ツール benchRun は、JavaScript テスト・ハーネス内から操作を実行できます。benchRun は、各操作の操作情報と待ち時間の数値を返します。 MongoDB インスタンスについて詳細情報が必要な場合は、mongostat コマンドまたは MMS を実行して、テスト中にデプロイメントをモニターすることを検討してください。

インストール

MongoDB をインストールする際には、安定したパフォーマンス指向のソリューションの作成を支援する、いくつかの考慮事項があります。10gen では、可能であれば CentOS (64 ビット) を使用することをお勧めします。 32 ビット・オペレーティング・システムおよび Windows オペレーティング・システムにはデプロイしないようにしてください。これらのシステムで提供されるデプロイメント・プラットフォームは低品質です。32 ビット・オペレーティング・システムにはファイル・サイズ制限があり、それによって問題が生じます。また、デプロイメント内の RAM の不足を埋め合わせるために OS で仮想メモリーが使用されると、Windows でパフォーマンスの問題が発生する可能性があります。デフォルトでは、IBM Cloud は、すべてのエンジニアリング・サーバー・デプロイメントに対して、CentOS 64 ビット・オペレーティング・システムを提供しています。

また、パフォーマンスを最大化するために、基本 OS インストールに対して以下の変更を行ってください。

SSD 先読みのデフォルトを 16 ブロックに設定 – SSD ドライブはシーク時間が優れているため、先読みを 16 ブロックに縮小することが可能です。回転ディスクには多少のバッファリングが必要になることがあるため、これらのディスクは 32 ブロックに設定されます。
noatime – 「Noatime」を使用することで、システムは読み取り中のファイルをファイル・システムに書き込む必要がなくなります。つまり、ファイルアクセスが速くなり、ディスクの消耗が少なくなります。
BIOS で NUMA をオフにする Linux、NUMA、および MongoDB は、通常は連携しません。 NUMA ハードウェア上で MongoDB を実行している場合は、NUMA をオフにする (インターリーブ・メモリー・ポリシーを使用して稼働する) ことをお勧めします。そうしないと、大幅なスローダウンや高いシステム CPU 時間などの問題が現れる可能性があります。
ulimit の設定 – ulimit は、オープン・ファイルの場合は 64000、ユーザー・プロセスの場合は 32000 に設定されます。これらの ulimit により、使用可能なファイル・ハンドルやユーザー・プロセスの不足が原因での障害を防ぐことができます。
ext4 の使用 – ext3 は、ファイルの割り振り (または、ファイルの削除) が低速です。また、大きいファイル内のアクセスも、ext3 では低下します。

デフォルトでは、これらの変更はすべての IBM Cloud サーバーに設定されている。

ジャーナル・ボリュームとデータ・ボリュームを別々の物理ボリュームにすることもお勧めします。ジャーナル・ディレクトリーとデータ・ディレクトリーが同じ物理ボリュームに存在すると、ジャーナルへのフラッシュによりデータのアクセスが中断され、MongoDB デプロイメント内で長い待ち時間のスパイクが発生します。

操作

MongoDB デプロイメントが実動にプロモートされた後は、モニタリングとパフォーマンスの最適化に関する以下の推奨事項を考慮してください。

MongoDB のすべてのインスタンスで MMS エージェントが実行されているようにしてください。これは、デプロイメントの正常性とパフォーマンスをモニターするのに役立ちます。サポートの対話時に、MMS エージェントは有用なデバッグ・データを 10gen に提供します。
mongostat コマンドは、MongoDB ノードのパフォーマンスに関するランタイム情報も提供します。

これらのツールのいずれかでパフォーマンス問題が検出された場合、シャーディングまたは索引付けを使用すると、これらのパフォーマンス問題を修正できることがあります。

フィールドベースのクエリの動作が悪いことを監視ツールが示す場合、 MongoDB 配置のインデックスを作成する。パフォーマンスを向上させるために、個別のフィールドに基づくデータを照会する際には、常に索引を使用してください。
運用するデータ・セットが大きいため、ノードの全体的なパフォーマンスが低下する場合は、シャーディングを使用します。限界に達する前に、必ずシャードを行ってください。システムは、挿入時または更新時のシャーディングの場合にのみチャンクを分割します。シャードを長く待ちすぎると、不均等な分配になることがあります。