MongoDBの管理に関する考慮事項

以下は、無料でダウンロードできるホワイトペーパー「MongoDB Management andAutomationwithClusterControl」からの抜粋です。

MongoDBの管理に関する考慮事項

組み込みの冗長性

MongoDBの重要な機能は、レプリケーションの形で組み込まれた冗長性です。 2つ以上のデータノードがある場合は、それらをレプリカセットとして構成できます。このセットでは、プライマリノードに書き込まれたすべてのデータが、ほぼリアルタイムでセカンダリノードに複製されます。

データの複数のコピーを確保します。プライマリフェイルオーバーの場合、レプリカセット内の残りのノードが選出を実行し、勝者をプライマリに昇格させます。このプロセスには通常2〜3秒かかり、レプリカセットへの書き込みを再開できます。 MongoDBはまた、サーバーまたはレプリカセットへのより高速で安全な書き込みのためにジャーナルを使用し、書き込みの冗長性のレベルを構成する「書き込みに関する懸念」方式も採用しています。

レプリカセットを手動でデプロイするための大まかな手順は次のとおりです。

1. データベースノードごとに単一の物理ホストまたは仮想ホストを割り当て、MongoDBコマンドラインクライアントをデスクトップにインストールします。冗長レプリカセット構成の場合、少なくとも3つのノードが必要であり、そのうち少なくとも2つはデータノードになります。レプリカセットの1つのノードは、アービターとして構成できます。これは、必要に応じてプライマリの選出に投票を提供することによってクォーラムを構成するためだけに構成されたmongodプロセスです。データはアービタープロセスに複製されません。
2. 各ノードにMongoDBをインストールします。一部のLinuxディストリビューションにはMongoDBCommunityEditionが含まれていますが、最新バージョンが含まれていない場合があることに注意してください。 MongoDB Enterpriseは、MongoDBのWebサイトからダウンロードすることによってのみ入手できます。 MongoDB Enterpriseと同様の機能は、MongoDBEnterpriseまたはCommunityEditionのドロップイン代替品であるMongoDB用のPerconaServerを介して利用することもできます。
3. 「レプリケーションパラメータ」を使用して、レプリカセットの個々のmongod.conf構成ファイルを構成します。セキュリティのためにキーファイルを使用する場合は、これも今すぐ設定してください。キーファイルセキュリティを使用すると、役割ベースの認証も有効になるため、サーバーを使用するにはユーザーと役割も追加する必要があることに注意してください。各サーバーでmongodプロセスを再起動します。
4. ノード間の接続を確認します。 MongoDBレプリカセットノードがポート27017で相互に通信できること、およびクライアントが同じポート上の各レプリカセットノードに接続できることを確認する必要があります。
5. MongoDBコマンドラインクライアントを使用して、サーバーの1つに接続し、rs.initiate（）を実行してレプリカセットを初期化し、続いて追加ノードごとにrs.add（）を実行します。 rs.conf（）を使用して構成を表示できます。

これらの手順は、MongoDBシャーディングクラスターのデプロイと構成、またはリレーショナルデータベースのシャーディングほど複雑ではありませんが、特に大規模な環境では、面倒でエラーが発生しやすくなります。

スケーラビリティ

MongoDBは、水平方向にスケーリングできるため、「Webスケール」データベースソフトウェアと呼ばれることがよくあります。リレーショナルデータベースと同様に、より多くのCPUコア、より多くのRAM、より高速なディスク、またはバス速度の向上を備えた物理ホストをアップグレードするだけで、MongoDBを垂直方向にスケーリングできます。ただし、垂直スケーリングには、費用便益比と収穫逓減の両方、および技術的限界の両方の点で限界があります。これに対処するために、MongoDBには「自動シャーディング」機能があり、データベースを多くのホスト（または冗長性のためにレプリカセット）に分割できます。リレーショナルプラットフォームでもシャーディングが可能ですが、データベースの開始時に設計されていない限り、これには主要なスキーマとアプリケーションの再設計、およびクライアントアプリケーションの再設計が必要であり、これは面倒で時間のかかるエラーが発生しやすいプロセスになります。

MongoDBシャーディングは、クライアントがシャーディングされたクラスターに接続するルータープロセスと、クラスターメタデータ（各ドキュメントのクラスター内の場所）を格納する構成サーバーを導入することで機能します。クライアントがルータープロセスにクエリを送信すると、最初に構成サーバーを参照してドキュメントの場所を取得し、次に個々のサーバーまたはレプリカセット（シャード）からクエリ結果を直接取得します。
シャーディングはコレクションごとに実行されます。

ここで非常に重要なパラメータは、パフォーマンスの目的で、コレクション内の各ドキュメントに存在するインデックス付きフィールドまたは複合フィールドである「シャードキー」です。コレクションのシャード全体の書き込み分散を定義するのはこれです。そのため、選択が不十分なシャードキーは、パフォーマンスに非常に悪影響を与える可能性があります。たとえば、純粋に時系列ベースのシャードキーを使用すると、すべての書き込みが長期間にわたって単一ノードに送信される可能性があります。ただし、ハッシュされたシャードキーは、シャード間で書き込みを均等に分散しますが、結果セットが多くのノードから取得されるため、読み取りパフォーマンスに影響を与える可能性があります。

アービター

MongoDBアービターは、データノードとして機能しないように構成されたmongodプロセスですが、レプリカセットのプライマリが選出されるときに投票する機能のみを提供し、関係を断ち切り、分割投票を防ぎます。アービターは、データのコピーを保持したり、書き込みを受け入れたりしないため、プライマリにならない場合があります。レプリカセットに複数のアービターを含めることは可能ですが、通常はお勧めしません。

遅延レプリカセットメンバー

遅延レプリカセットメンバーは、冗長性のレベルを追加し、プライマリから一定の秒数遅れた状態を維持します。遅延メンバーはデータセットの「ローリングバックアップ」または実行中の「履歴」スナップショットであるため、さまざまなタイプの人的エラーからの回復に役立ちます。

遅延メンバーは「非表示」のレプリカセットメンバーであり、クライアントアプリケーションからは見えないため、直接クエリすることはできません。また、通常の操作ではプライマリにならない可能性があり、エラーからの回復に使用する場合は手動で再構成する必要があります。

バックアップ

レプリカセットまたはシャードクラスターのバックアップは、「mongodump」コマンドラインユーティリティを介して実行されます。 --oplogパラメーターと一緒に使用すると、oplogを含むデータベースのダンプが作成され、mongodインスタンスの状態のポイントインタイムスナップショットが作成されます。 --replayOplogパラメータを指定してmongorestoreを使用すると、バックアップの完了時にデータの状態を完全に復元して、不整合を回避できます。

より高度なバックアップ要件については、「mongodbconsistent-backup」と呼ばれるサードパーティのツール（コマンドラインベース）を利用できます。これは、シャードデータベースが複数のホストに分散している場合、シャードクラスターの完全に一貫したバックアップを提供します。複雑な手順です。

監視

MongoDBを監視するために、公式および非公式の両方の商用ツールが市場に出回っています。これらのツールは、一般に、MongoDBのみに焦点を当てた単一の製品管理ユーティリティです。多くは、既存のMongoDBアーキテクチャーでのコレクション管理、バックアップ、またはデプロイメントなど、特定の側面にのみ焦点を当てています。適切な計画がないと、追加のツールを環境に導入して管理する必要がある状況につながる可能性があります。

MongoDB、「mongotop」、および「mongostat」で提供されるコマンドラインツールは、環境パフォーマンスの詳細なビューを提供し、問題の診断に使用できます。さらに、MongoDBの「mongo」コマンドラインクライアントは、「rs.status（）」（またはシャードクラスター「sh.status（）」）を実行して、レプリカセットまたはクラスターとそのメンバーホストのステータスを表示することもできます。 「db.stats（）」コマンドは、ストレージの使用とデータボリュームに対応するドキュメントを返します。これらは、コレクションや、多くの内部メトリックにアクセスするための他の呼び出しに相当します。

あらすじ

これは、MongoDBを管理するための考慮事項の簡単な概要です。このような高レベルでも、使用可能なツールを使用してコマンドラインからレプリカセットまたはシャーディングクラスターを管理することは可能ですが、レプリカセットが多い環境や大規模な本番環境では拡張できないことはすぐにわかります。シャーディングされたクラスター。多くのホストとデータベースで構成される中規模から大規模の環境では、コマンドラインツールとスクリプトを使用してすべてを管理することはすぐに不可能になります。内部ツールとスクリプトを開発して環境を展開および維持することはできますが、これにより、新しい開発、リビジョン管理システム、およびプロセスを管理する負担が増えます。新しいデータベースサーバーのバージョンをサポートするためにツールの変更が必要な場合、データベースサーバーの単純なアップグレードは複雑なプロセスになる可能性があります。
サーバーのバージョン

しかし、内部ツールとスクリプトがなければ、MongoDBクラスターを自動化および管理するにはどうすればよいでしょうか。ホワイトペーパーをダウンロードして、その方法を学びましょう！