MongoDB の mongod と mongos の違いを整理する

MongoDB の Sharded Cluster（シャーディング構成）を触っていると、mongod と mongos という2種類のプロセスが登場します。

名前は似ていますが、担当する役割が異なります。

• mongod：データの保存や読み書きを担う、MongoDB のデータベースサーバー
• mongos：クライアントからのリクエストを、適切な Shard に振り分けるルーター

この記事では、両者の違いと、Replica Set・Config Server・systemd のサービスとの関係を整理します。

本記事は、mongod と mongos を別プロセスで動かす構成を中心に説明します。systemctl の例は、Linux で systemd を使ってサービスを管理している環境を想定しています。

mongod とは

mongod は、MongoDB のデータベースサーバープロセスです。データを保存し、読み書きの要求やデータベースの管理処理を実行します。¹

単体の MongoDB サーバーとして動かす場合も、Replica Set を構成する場合も、使用するのは mongod です。

Replica Set のメンバーも mongod

Replica Set は、複数の mongod で構成されます。代表的な役割は次のとおりです。²

役割	主な働き	データのコピー
Primary	アプリケーションからの書き込みを受け付ける	保持する
Secondary	Primary の変更を複製する。設定によって読み取り先にもなる	保持する
Arbiter	Primary を選ぶ選挙に参加する	保持しない

例えば、3メンバーの Replica Set を「Primary 1台、Secondary 2台」で構成できます。

Primary / Secondary は、Replica Set 内の mongod が担う役割です。 mongos の役割ではありません。

なお、Arbiter も mongod ですが、データセットのコピーを保持しません。そのため、「mongod は必ずユーザーデータを持つ」と言い切ると、Arbiter や専用の Config Server が例外になります。

状態と設定を確認するメソッド

mongosh で Replica Set のメンバーである mongod に接続すると、次のメソッドで状態や設定を確認できます。

メソッド	確認する内容
rs.status()	接続したメンバーから見た Replica Set の現在の状態。各メンバーの Primary / Secondary などを確認する3
rs.conf()	Replica Set の設定。メンバー一覧、選挙時の優先度、投票数などを確認する4
db.hello()	接続先の情報。Replica Set メンバーであれば、自身が Primary / Secondary かどうかなどを確認する5

rs.status() は状態、rs.conf() は設定を見るメソッド、と分けると分かりやすいです。

db.hello() は mongos でも実行できます。接続先を見分ける方法は後述します。

mongos とは

mongos は、MongoDB Sharded Cluster のルータープロセスです。

ユーザーデータをデータベースとして永続保存する役割は持たず、主に次の処理を行います。⁶

1. クライアントからリクエストを受け取る
2. 問い合わせが必要な Shard を判断する
3. 対象の Shard に処理を依頼する
4. 必要に応じて各 Shard の結果を取りまとめ、クライアントへ返す

そのため、アプリケーションから見たSharded Cluster への入口と考えると分かりやすいです。

問い合わせ先はシャードキーなどの条件で決まる

例えば、users コレクションが { user_id: 1 } をシャードキーとしてシャーディングされているとします。

db.users.find({ user_id: 100 })

この場合、mongos はシャードキーの値とクラスタのメタデータを使い、該当するデータを担当する Shard に問い合わせを送れます。

一方、シャードキーを含まない検索など、対象を絞れない場合は、そのコレクションの全 Shard に問い合わせることがあります。これを scatter/gather と呼びます。⁶

つまり、振り分け先は必ずしも1つの Shard とは限りません。

mongod と mongos の違い

項目	mongod	mongos
プロセスの役割	データベースサーバー	Sharded Cluster のルーター
データの保持	データやメタデータを保持する。ただし、Arbiter はデータのコピーを保持しない	ユーザーデータを永続保存しない
Replica Set のメンバー	Replica Set 構成の場合はメンバーになる	メンバーにならない
Primary / Secondary	Replica Set のデータ保持メンバーが担う役割	そのような役割はない
リクエストへの対応	データの読み書きを実行する	処理先を判断し、必要に応じて結果を取りまとめる
Sharded Cluster での位置付け	Shard や Config Server を構成する	クライアントからの入口になる

mongos は、ルーティングのために Config Server のメタデータをキャッシュします。「ユーザーデータを永続保存しない」ことと、「何の情報も持たない」ことは異なります。⁶

Config Server も mongod

Sharded Cluster には、Shard と mongos に加えて Config Server があります。

Config Server は、データがどの Shard に配置されているかなど、クラスタのメタデータや構成情報を管理します。mongos はその情報を取得・キャッシュし、リクエストの振り分けに利用します。⁷

Config Server で動いているプロセスも mongod です。

現在の Sharded Cluster では、各 Shard と Config Server をそれぞれ Replica Set として構成します。⁸

専用の Config Server を使う構成の一例を、以下に示します。

図の実線は Shard へのリクエスト経路、点線は Config Server のメタデータを参照する関係を示しています。内部通信は一部省略しています。

例えば、各 Replica Set を以下のように構成できます。

構成要素	構成例	主に保持するもの
Shard 0	mongod の Primary 1台 + Secondary 2台	ユーザーデータ
Shard 1	mongod の Primary 1台 + Secondary 2台	ユーザーデータ
専用の Config Server	mongod の Primary 1台 + Secondary 2台	クラスタのメタデータ・構成情報

Config Server の Replica Set にも Primary / Secondary があります。ただし、Config Server の Replica Set に Arbiter を配置することはできません。⁷

このように、mongod は Shard のデータノードだけを指す名前ではありません。

MongoDB 8.0 以降には、Config Server と Shard の役割を兼ね、ユーザーデータも保存する Config Shard という構成もあります。上の図は、専用の Config Server を使う場合の例です。⁷

mongos は複数配置できる

mongos は1つに限らず、複数配置できます。複数の mongos を配置することで、可用性や処理能力を高める構成を取れます。⁸

上の図では、mongos #1 と mongos #2 の両方が、同じ Sharded Cluster への入口になっています。

mongos 同士で Replica Set を構成するわけではなく、mongos に Primary / Secondary の区別もありません。

複数配置による冗長化を利用する場合は、アプリケーション側も複数の mongos に接続できるように設定します。

接続先が mongod か mongos かを確認する

mongosh で接続している相手を確認したい場合は、次のメソッドを実行します。

db.hello()

接続先が mongos であれば、応答に msg: "isdbgrid" が含まれます。⁵

以下は、mongos の応答から一部のフィールドを抜き出した例です。

{
  "isWritablePrimary": true,
  "msg": "isdbgrid",
  "ok": 1
}

ここで注意したいのは、isWritablePrimary: true だけでは、Replica Set の Primary と判断できないことです。

この値は、mongos や、Replica Set に所属していない単体の mongod でも true になります。接続先が mongos かどうかを見分ける場合は、msg フィールドを確認します。⁵

mongod と mongos を同じサーバーに配置することもできる

mongod と mongos は別プロセスなので、同じサーバー上で動かす構成も可能です。⁸

例えば、次のように配置できます。

サーバー	起動するプロセス
Server 1	mongod と mongos
Server 2	mongod と mongos
Server 3	mongod と mongos

これはプロセスの配置例です。Shard や Config Server を含むクラスタ全体の構成を示したものではありません。

同じサーバー・同じ IP アドレスで動かす場合は、待ち受けポートが重複しないように設定します。例えば、mongos を 27017、mongod を 27018 にする、といった設定です。

また、同居させると CPU やメモリを共有し、サーバー障害の影響も両方のプロセスが受けます。配置を決める際には、こうした点も考慮します。

mongos が mongod を起動するわけではない

同じサーバーで mongod と mongos が動いていても、mongos が mongod を子プロセスとして起動しているわけではありません。

systemd でそれぞれを独立したサービスとして管理する場合、例えば次のように対応付けます。

サービス名の例	起動するプロセス
mongod.service	mongod
mongos.service	mongos

このようなサービスが登録されている環境では、次のコマンドで状態を確認できます。

systemctl status mongod.service
systemctl status mongos.service

ただし、サービス名や登録の有無は、インストール方法や運用設定によって異なります。 mongos.service が必ず存在するわけではありません。

また、systemd のサービス名そのものが、起動する実行ファイルを決めるわけでもありません。実際の起動処理は、ユニットファイルの ExecStart= などで定義されます。⁹

定義を確認したい場合は、次のコマンドを使います。¹⁰

systemctl cat mongod.service
systemctl cat mongos.service

Linux で実際に動いているプロセスを確認するなら、pgrep も使えます。

pgrep -a -x mongod
pgrep -a -x mongos

-a は PID とコマンドラインの表示、-x はプロセス名の完全一致を指定するオプションです。¹¹

同じサーバーに配置されていること、同じサービスから起動されること、プロセスの親子関係は、それぞれ別の話です。

まとめ

mongod と mongos の違いは、次のように整理できます。

• mongod は、MongoDB のデータベースサーバープロセス
• mongos は、Sharded Cluster のルータープロセス
• Replica Set の Primary / Secondary を担うのは mongod
• Config Server を構成するプロセスも mongod
• mongos は複数配置できるが、Replica Set のメンバーにはならない
• mongod と mongos は同じサーバーに配置できる
• 同居していても、mongos が mongod を起動しているわけではない
• systemd のサービス名と、実際に起動するプロセスは、サービス定義を確認して判断する

まずは 「mongod は DB サーバー、mongos は Sharded Cluster のルーター」 と押さえると、構成図やプロセス一覧を読みやすくなります。

参考資料

1. MongoDB公式：mongod ↩

2. MongoDB公式：Replica Set Members ↩

3. MongoDB公式：rs.status() ↩

4. MongoDB公式：rs.conf() ↩

5. MongoDB公式：hello ↩ ↩² ↩³

6. MongoDB公式：Routing with mongos ↩ ↩² ↩³

7. MongoDB公式：Config Servers ↩ ↩² ↩³

8. MongoDB公式：Sharded Cluster Components ↩ ↩² ↩³

9. systemd公式：systemd.service ↩

10. systemd公式：systemctl ↩

11. Debian Manpages：pgrep(1) ↩