ステップバイステップガイド:基本MongoDBシャードクラスターのデプロイ
設定サーバー、シャードレプリカセット、mongosルーター、シャーディング検証を含む基本MongoDBシャードクラスターをデプロイします。
ステップバイステップガイド:基本MongoDBシャードクラスターのデプロイ
MongoDBは、人気のNoSQLドキュメントデータベースであり、大量のデータを高いパフォーマンスと柔軟性で処理することに優れています。しかし、データが増加するにつれて、単一のサーバーやレプリカセットはスケーリングの限界に達する可能性があります。ここでシャーディングが登場し、データを複数のサーバー(シャード)に分散することで水平方向のスケーラビリティを実現します。
このガイドでは、学習目的でlocalhost上に基本的なMongoDBシャードクラスターを構築する手順を説明します。設定サーバー、シャードレプリカセット、mongosルーターを構成し、コレクションのシャーディングを有効にします。
MongoDBシャードクラスターの理解
MongoDBシャードクラスターは、データを分散およびルーティングするために連携する3つの主要コンポーネントで構成されています。
- シャードレプリカセット:これらは実際のデータを保持するノードです。各シャードは高可用性とデータ冗長性を提供するレプリカセットです。データはこれらのシャード間で分割されます。
- 設定サーバー(Configサーバー):これらはクラスターのメタデータを保存し、データチャンクとシャードのマッピングを含みます。MongoDB 3.2以降、設定サーバーは高可用性と一貫性のためにレプリカセット(CSRS - Config Server Replica Set)としてデプロイする必要があります。
mongosルーター:これらはクエリルーターとして機能し、クライアントアプリケーションにインターフェースを提供します。mongosインスタンスは、クラスターのメタデータに基づいてクライアント操作を適切なシャードに誘導します。アプリケーションはmongosに接続し、シャードに直接接続しません。
MongoDBシャードクラスターの概念図(画像クレジット:MongoDB公式ドキュメント)
前提条件
始める前に、以下を確認してください。
- 複数のマシン/VM:真に分散されたシャードクラスターには、少なくとも6〜9台のマシン/VM/Dockerコンテナが必要です。この基本的なチュートリアルでは、異なるポートを使用して単一のマシンでシミュレートできますが、本番環境では専用のリソースが必要です。
- 設定サーバー用に3台(configSrv01、configSrv02、configSrv03)
- 各シャードに最低2〜3台(例:Shard01-RS01、Shard01-RS02、Shard01-RS03; Shard02-RS01、...)
mongosルーター用に1台以上
- MongoDBのインストール:
mongodまたはmongosをホストするすべてのマシンにサポートされているMongoDBサーバーバージョンをインストールします。シェルコマンドにはmongoshを使用します。 - ネットワーキング:すべてのマシンが必要なポート(設定サーバー、シャード、
mongosのデフォルトはそれぞれ27017、27018、27019、27020、またはカスタムポート)で相互に通信できることを確認します。 - ディレクトリ構造:各
mongodおよびmongosインスタンス用に専用のデータおよびログディレクトリを作成します。
このガイドでは、簡略化のため、異なるポートとディレクトリを使用してlocalhostを使用します。本番環境では、実際のホスト名またはIPアドレスを使用します。
推奨ディレクトリ構造(localhost設定の例)
mkdir -p /data/db/configdb01 /data/db/configdb02 /data/db/configdb03
mkdir -p /data/db/shard01-rs01 /data/db/shard01-rs02 /data/db/shard01-rs03
mkdir -p /data/db/shard02-rs01 /data/db/shard02-rs02 /data/db/shard02-rs03
mkdir -p /data/log/config /data/log/shard01 /data/log/shard02 /data/log/mongos
デプロイ手順
ステップ1:設定サーバーのセットアップ(Configレプリカセット)
設定サーバーはシャードクラスターのメタデータを保存します。これらはレプリカセットとして実行する必要があります。
設定サーバー用に
mongodインスタンスを起動:各インスタンスには--configsvrおよび--replSetオプションが必要です。# Config Server 1 mongod --configsvr --replSet cfgReplSet --dbpath /data/db/configdb01 --port 27019 --bind_ip localhost --logpath /data/log/config/configdb01.log --fork # Config Server 2 mongod --configsvr --replSet cfgReplSet --dbpath /data/db/configdb02 --port 27020 --bind_ip localhost --logpath /data/log/config/configdb02.log --fork # Config Server 3 mongod --configsvr --replSet cfgReplSet --dbpath /data/db/configdb03 --port 27021 --bind_ip localhost --logpath /data/log/config/configdb03.log --forkヒント:本番環境では、
localhostを実際のIPアドレスまたはホスト名に置き換えてください。Configレプリカセットを初期化:設定サーバーインスタンスの1つに接続し、レプリカセットを初期化します。
mongosh --port 27019mongoシェル内:
rs.initiate({ _id: "cfgReplSet", configsvr: true, members: [ { _id : 0, host : "localhost:27019" }, { _id : 1, host : "localhost:27020" }, { _id : 2, host : "localhost:27021" } ] });ステータスを確認:
rs.status();
ステップ2:シャードレプリカセットのセットアップ
クラスター内の各シャードはレプリカセットです。2つのシャード(shard01およびshard02)をセットアップし、それぞれ3つのメンバーで構成します。
シャード1のメンバー用に
mongodインスタンスを起動:各インスタンスには--shardsvrおよび--replSetオプションが必要です。# Shard 1 Member 1 mongod --shardsvr --replSet shard01 --dbpath /data/db/shard01-rs01 --port 27030 --bind_ip localhost --logpath /data/log/shard01/shard01-rs01.log --fork # Shard 1 Member 2 mongod --shardsvr --replSet shard01 --dbpath /data/db/shard01-rs02 --port 27031 --bind_ip localhost --logpath /data/log/shard01/shard01-rs02.log --fork # Shard 1 Member 3 mongod --shardsvr --replSet shard01 --dbpath /data/db/shard01-rs03 --port 27032 --bind_ip localhost --logpath /data/log/shard01/shard01-rs03.log --forkシャード1のレプリカセットを初期化:シャード1のインスタンスの1つに接続します。
mongosh --port 27030mongoシェル内:
rs.initiate({ _id : "shard01", members: [ { _id : 0, host : "localhost:27030" }, { _id : 1, host : "localhost:27031" }, { _id : 2, host : "localhost:27032" } ] });シャード2のメンバー用に
mongodインスタンスを起動(追加のシャードがある場合は繰り返します):# Shard 2 Member 1 mongod --shardsvr --replSet shard02 --dbpath /data/db/shard02-rs01 --port 27040 --bind_ip localhost --logpath /data/log/shard02/shard02-rs01.log --fork # Shard 2 Member 2 mongod --shardsvr --replSet shard02 --dbpath /data/db/shard02-rs02 --port 27041 --bind_ip localhost --logpath /data/log/shard02/shard02-rs02.log --fork # Shard 2 Member 3 mongod --shardsvr --replSet shard02 --dbpath /data/db/shard02-rs03 --port 27042 --bind_ip localhost --logpath /data/log/shard02/shard02-rs03.log --forkシャード2のレプリカセットを初期化:シャード2のインスタンスの1つに接続します。
mongosh --port 27040mongoシェル内:
rs.initiate({ _id : "shard02", members: [ { _id : 0, host : "localhost:27040" }, { _id : 1, host : "localhost:27041" }, { _id : 2, host : "localhost:27042" } ] });
ステップ3:mongosルーターのセットアップ
mongosインスタンスはクライアントアプリケーションのエントリポイントです。これらは設定サーバーの場所を知っている必要があります。
mongosインスタンスを起動:--configdbオプションを指定し、設定レプリカセットのメンバーをリストします。# Mongos Router 1 mongos --configdb cfgReplSet/localhost:27019,localhost:27020,localhost:27021 --port 27017 --bind_ip localhost --logpath /data/log/mongos/mongos01.log --fork注:負荷分散と高可用性のために、複数の
mongosインスタンスを起動できます。これらはすべて同じ設定サーバーに接続します。
ステップ4:mongosに接続してシャードを追加
次に、mongosインスタンスに接続し、シャードレプリカセットをクラスターに追加します。
mongosに接続:デフォルトのMongoDBポート27017またはmongosに指定したカスタムポートを使用します。mongosh --port 27017シャードを追加:
sh.addShard()コマンドを使用し、レプリカセット名とそのメンバーの1つを指定します。sh.addShard("shard01/localhost:27030"); sh.addShard("shard02/localhost:27040");
ステップ5:データベースとコレクションのシャーディングを有効にする
シャードが追加されたら、特定のデータベースとそのデータベース内の特定のコレクションに対してシャーディングを有効にする必要があります。これにはシャードキーの選択が必要です。
データベースのシャーディングを有効にする:シャーディングするデータベースに切り替え、
sh.enableSharding()を実行します。use mydatabase; sh.enableSharding("mydatabase");コレクションをシャーディングする:
シャードキーを選択し、sh.shardCollection()を使用します。警告:効果的なシャードキーの選択は、パフォーマンスと均等な分散にとって重要です。不適切なシャードキーは、ホットスポットや非効率的なクエリを引き起こす可能性があります。一般的な戦略には、ハッシュ化キー、範囲キー、複合キーがあります。
この例では、フィールド
_idを持つコレクションmycollectionを想定します。sh.shardCollection("mydatabase.mycollection", { _id: "hashed" });ハッシュ化された
_idシャードキーは、単調増加する範囲_idキーよりも挿入をシャード間でより均等に分散するため、チュートリアルには簡単です。実際のアプリケーションでは、クエリパターンと書き込み分散からシャードキーを選択し、利便性だけで選択しないでください。
ステップ6:クラスターの確認
mongosに接続したmongoshから以下のコマンドを実行します:
sh.status();
db.adminCommand({ listShards: 1 });
次に、サンプルドキュメントを挿入し、シャーディングされたコレクションが存在することを確認します:
use mydatabase;
db.mycollection.insertMany([
{ _id: 1, name: "alpha" },
{ _id: 2, name: "beta" },
{ _id: 3, name: "gamma" }
]);
db.mycollection.getShardDistribution();
小さなテストデータセットはすぐに分割されない可能性があるため、数ドキュメント後に完全な分散を期待しないでください。重要な最初の確認は、sh.status()が両方のシャードをリストし、mydatabase.mycollectionがシャーディングされていることを示すことです。
本番環境の注意点
このlocalhost設定は構成要素を学ぶのに役立ちますが、本番環境ではより注意が必要です:
- レプリカセットのメンバー名はクラスターメタデータに保存されるため、
localhostではなく実際のホスト名を使用します。 - 設定サーバーを3メンバーのレプリカセットとして実行します。
- 各シャードを障害ドメイン全体にメンバーを分散したレプリカセットとして実行します。
- クラスターを公開する前に、認証と内部キーファイルまたはx.509認証を有効にします。
- クラスター対応のバックアップ計画の一部として、設定サーバーのメタデータとシャードデータをバックアップします。
- チャンク分散、バランサーアクティビティ、レプリケーションラグ、ディスク増加を監視します。
最終的なポイント
MongoDBシャードクラスターには3つの役割があります:設定サーバーはメタデータを追跡し、シャードレプリカセットはデータを保存し、mongosはクライアントトラフィックをルーティングします。まずこれらの役割を機能させ、その後、設計時間のほとんどをシャードキーに費やします。なぜなら、その選択がクラスターが負荷をきれいに分散するか、ホットシャードを作成するかを決定するからです。