ネームスペース
EMQX 5.9.0以降、ネームスペース機能により、ユーザーはMQTTクライアントを論理的にグループ化し、単一のEMQXクラスター内でトラフィック制限を適用できます。この機能は、複数のクライアントグループ（事業部門、アプリケーション、顧客など）が同じインフラを共有しつつ、論理的に分離されたスケーラブルなデプロイメントを可能にします。
EMQXのネームスペース機能は以下の2つの部分で構成されています。
- MQTTクライアントネームスペース — MQTTクライアントを（ユーザー名、SNI、またはその他の接続メタデータによって）論理的にグループ化し、ネームスペースごとのクォータ、レート制限、クライアントIDおよびトピックの分離設定を適用します。
- 管理ユーザーネームスペース — ダッシュボード、CLI、およびAPIユーザーをネームスペース付きロールで特定のネームスペースにスコープし、委任された管理者が割り当てられたネームスペース内のリソースのみを閲覧・操作できるようにします。EMQX 6.0以降で利用可能です。
信頼されたデプロイメントのみ
管理ユーザーネームスペースは、組織内のチームや事業部門を分離するなど、信頼された内部デプロイメント向けに設計されており、誤って互いの設定を変更するリスクを軽減します。これは強力な分離保証を提供せず、公開または信頼されていないマルチテナント環境のセキュリティ境界ではありません。公開マルチテナント環境で管理ユーザーネームスペースの利用を検討している場合は、EMQの営業担当までお問い合わせください。このユースケースは現時点で標準機能としてサポートされていません。
MQTTクライアントネームスペースについては、ネームスペース間のクライアント分離はオプトインであり、明示的な設定が必要です。ネームスペース間のクライアントが相互に信頼されていない場合は、分離メカニズムを参照し、必要なクライアントIDのオーバーライドやトピックマウントポイントを設定してください。
EMQX 6.1以降、ネームスペース関連の機能が強化され、元の意味論は変わらずにマルチテナント分離の設定が簡素化され、トピック分離の動作が統一されました。
ネームスペースとは
EMQX Enterpriseにおけるネームスペースは、MQTTクライアントの論理的分離とリソース管理のための仕組みです。異なる事業やテナントのクライアントを、共有されたEMQXクラスター内の別々のネームスペースに分割し、接続、メッセージ、クォータなどの分離を実現します。
ネームスペースは、tns（テナントネームスペース）という特別なクライアント属性で識別されます。この属性は自動的には生成されず、ユーザー名やServer Name Indication（SNI）などのクライアント接続メタデータから設定によって導出されます。
ネームスペースは、ダッシュボードやREST APIで明示的に作成されるか、定義されたルールに基づいてクライアント接続時に自動的に作成されるかにかかわらず、一度作成されると有効になります。
典型的なユースケース：企業内で複数の事業部門がクラスターを共有する場合、テナント単位のリソース分離管理、集中アクセス制御など。
ネームスペースで実現できること
クライアントとメッセージの論理的分離
ネームスペースにより、異なるテナント間でクライアントIDやトピックスペースを分離し、クライアントを論理的に区別できます。
注意
ネームスペースを有効にしても、クライアントIDのオーバーライドやトピックのプレフィックスは自動的には適用されません。これらは手動で設定する必要があります。詳細は分離メカニズムを参照してください。
テナント単位のクォータおよび接続制御
ネームスペースごとに同時接続数やメッセージパブリッシュレートの制限を設定でき、公平な利用とシステムの安定性を確保します。
強化されたログおよび運用可視性
ログにネームスペース識別子（
tns）が自動的に含まれ、クライアント活動の追跡、問題検出、テナント単位の診断が容易になります。ネームスペースベースのリソース監視
ネームスペースは、テナントごとの接続数やメッセージスループットなどのメトリクス収集の境界を提供し、キャパシティプランニングや運用インサイトに役立ちます。
管理ユーザーの分離
EMQX 6.0以降、ネームスペースはダッシュボード、CLI、APIユーザーにもネームスペース付きロールを通じて拡張されます。このページ上部の信頼されたデプロイメントのみの注意事項に記載された信頼モデルと必要な対策を参照してください。
- 管理ユーザーは特定のネームスペースに制限されたロール（例：
ns:team_a::administrator）で作成可能です。 - ネームスペース付きユーザーは割り当てられたネームスペース内のリソースのみを閲覧・操作できます。
- ネームスペース未対応のクラスター全体設定は閲覧可能ですが読み取り専用であり、グローバル管理者のみが変更可能です。
- EMQX 6.0.4以降、ネームスペース管理者は自身のネームスペース内でAPIキーを管理可能です。グローバルキーや他のネームスペースのキーにはアクセスできません。
- これにより、データ分離とともにテナント固有の安全な管理アクセスが実現します。
- 管理ユーザーは特定のネームスペースに制限されたロール（例：
マルチテナント管理
システム管理者は同一クラスター内で複数のネームスペースを管理でき、各テナントは分離されたリソースとユーザー権限の自己完結型環境で運用できます。
管理ネームスペースの運用セキュリティ
委任されたネームスペース管理者は、コネクター、ブリッジ、アクションなどのアウトバウンドターゲットを設定可能です。追加の制御なしでは、内部または機密ネットワークへの意図しないアクセスを許してしまう恐れがあります。
利用可能な場合はrule_engine.ssrfを有効にし、コネクター設定のテスト、作成、更新時にHTTPおよびMQTTコネクターのターゲットを検証してください。EMQX 6.0.4以降、このポリシーは他のコネクタータイプやランタイム接続には適用されません。EMQXホスト側でアウトバウンドネットワーク境界を強制するために以下のイグレス制御を追加してください。
- IdP、Webhook、コネクターバックエンドなど、承認済みの宛先へのアウトバウンドアクセスのみ許可。
- インスタンスメタデータサービス、ループバックアドレス、リンクローカルアドレス、内部管理ネットワークへのアクセスは明示的に必要な場合を除き拒否。典型的なブロック対象メタデータエンドポイントは
100.100.100.200、169.254.169.253、169.254.169.254、fd00:ec2::254など。 - 新しい統合や管理機能でアウトバウンドHTTP/TCP接続を開始する際は、ファイアウォールルールを必ず見直してください。
詳細はルールエンジンポリシーとファイアウォールルールによるSSRF緩和を参照してください。
分離メカニズム
EMQXは非常に柔軟で、ネームスペース導入前から複数の分離メカニズムをサポートしています。
ネームスペースは統一されたテナント識別子（client_attrs.tns）を提供し、クライアントID、トピックマウントポイント、関連設定を一貫したテナントコンテキストで整理可能にします。
ただし、分離ポリシーはビジネス要件に応じて明示的に設定する必要があります。ネームスペースを有効にしても、EMQXはクライアントIDやトピックの分離を自動的には有効化しません。
クライアントIDオーバーライド
信頼されていないマルチテナント環境では必須
異なるネームスペースのクライアントが相互に信頼されていない場合（例：各ネームスペースが外部顧客や別組織を表す場合）、EMQXがネームスペースを判別する際に適切なクライアントIDオーバーライド機構を必ず設定してください。
オーバーライドがないと、あるネームスペースのクライアントが他のテナントのクライアントIDを再利用でき、そのテナントのクライアントが切断されたり、永続セッションを乗っ取られたり、サービス拒否を引き起こす可能性があります。認証だけでは防げません。なぜならEMQXは実効クライアントIDでセッションをグローバルに識別するためです。
これにマウントポイントを用いたトピック分離を組み合わせ、トピックレベルのアクセスもネームスペース間で交差しないようにしてください。
EMQXが接続情報（ユーザー名、クライアントID、クライアント証明書など）から認証前にネームスペースを判別できる場合は、mqtt.clientid_overrideを設定します。例：
mqtt.clientid_override = "concat([client_attrs.tns, '-', clientid])"このルールはクライアントIDの先頭にネームスペースを付加し、競合を回避します。認証バックエンドがネームスペースや置換用クライアントIDに必要な値を判別する場合は、バックエンドにclientid_overrideを返すよう設定してください。両方の機構を同時に設定しないでください。詳細はクライアントID分離を参照してください。
マウントポイントを用いたトピック分離
異なるネームスペースのクライアントが同じトピック名に対して干渉せずにパブリッシュやサブスクライブを行う必要がある場合、マウントポイントを使ってトピックにネームスペースを自動的にプレフィックスできます。
EMQX 6.0以前では、マウントポイントは通常リスナー単位で設定されていました。例：
listener.{TYPE}.{NAME}.mountpoint = "${client_attrs.tns}/"複数リスナー環境では設定の重複が必要でした。
EMQX 6.1以降は、ネームスペースを統一されたトピックマウントポイントとして利用可能です。ネームスペースが判別されると、EMQXは内部的に{namespace}/をトピックのプレフィックスとして適用し、リスナーごとの設定なしに同等の分離効果を実現します。
後方互換性を維持するため、デフォルトでは認可（ACL）チェックにマウントポイントのプレフィックスは含まれません。
EMQX 6.1以降、以下を設定することでこの動作を有効化できます。
authorization.include_mountpoint = trueこれにより認可バックエンドはマウントポイント付きのトピックを受け取れます。
ルールのネームスペース分離
rule_engine.limit_selects_in_namespaceが有効（デフォルト）な場合、他のネームスペースのメッセージやクライアント関連イベントがネームスペース付きルールをトリガーするのを防ぎます。EMQXはclient_attrs.tnsでクライアントのネームスペースを識別します。EMQX 6.1.5以降、この設定はルールのRepublishアクションの出力トピックもルールのネームスペースに制限します。
トピックテンプレートのレンダリング後、EMQXはレンダリング結果がすでに<namespace>/で始まっていなければ、<namespace>/を先頭に付加します。すでに<namespace>/で始まるトピックは変更されません。グローバルルールやrule_engine.limit_selects_in_namespace = falseのデプロイメントは、ルールネームスペースを付加せずにレンダリング済みトピックにパブリッシュし続けます。
このRepublish動作はmqtt.namespace_as_mountpointには依存しません。この設定はクライアントのトピックパブリッシュやサブスクライブをネームスペース間で制限しません。クライアントのトピックアクセスを分離するには、マウントポイントと認可ルールによるトピック分離を設定してください。
マルチテナンシー対応状況
ネームスペースはEMQXマルチテナンシーの中核的な構成要素です。EMQX 5.9で導入されて以来、複数のサブシステムにわたり段階的に拡張されています。EMQXは以下のマルチテナンシー機能をサポートしています。
統一された管理およびMQTTネームスペース（6.0）
管理プレーン（ダッシュボード、CLI、API）とMQTTデータプレーンが同一のネームスペースモデルを共有。
ルールおよびデータ統合の分離（6.0）
ルール、アクション、ソース、コネクターにネームスペース分離を適用。
組み込みデータベース認証の分離（6.1）
組み込みデータベースに格納された認証データをネームスペース単位で分離。
組み込みデータベース認可の分離（6.1）
認可ルールを特定ネームスペースにスコープ可能。
Prometheusメトリクス分離（6.1、6.3で拡張）
EMQX 6.1以降、メトリクスをネームスペース別に公開・集約可能。6.3以降はルール、アクション、コネクターのデータ統合メトリクスにも適用。詳細はネームスペース別データ統合メトリクスのスクレイプを参照。
トピックメトリクス収集の分離（6.3）
ネームスペース管理者が作成したトピックメトリクス収集は、同一ネームスペースのクライアントがパブリッシュしたメッセージのみをカウント。ネームスペース管理者は自身のネームスペース所有の収集のみ管理可能で、グローバル管理者は全ネームスペースの収集を一覧可能。詳細はトピックメトリクスを参照。
保持メッセージクォータの分離
ネームスペースごとに保持メッセージ関連のリソース使用量を制限可能。
次のステップ
ネームスペースの概要と実現可能なことを理解したら、EMQXでの利用を開始するために以下を参照してください。
- ネームスペースの作成：ダッシュボードやREST APIで明示的にネームスペースを作成する方法や、クライアントメタデータに基づく自動作成について学べます。
- ネームスペースの設定と管理：ダッシュボードまたはREST APIでレート制限やセッションクォータを設定する方法。
- ネームスペースグローバル設定：ネームスペースの解決、分離メカニズム、トピックマウントポイント、認可処理などクラスター全体の動作を設定。
- クイックスタート：ネームスペースを体験する：MQTTXを使ったハンズオンガイドで、ネームスペースベースのクライアント・トピック分離を素早く試せます。