Azure Event Grid Namespaces (MQTT)

解決する課題

多数の IoT デバイスやクライアントを標準プロトコルの MQTT でつなぎ、デバイス同士のメッセージ交換と、クラウド側でのイベント処理の両方をマネージドに実現できます。

• 大量のデバイスを標準の MQTT で双方向接続し、ブローカ運用の手間をなくしたい
• デバイス間で直接 pub/sub（command/telemetry のやり取り）をしたい
• 受け取ったメッセージをAzure サービスへルーティングしてクラウド処理につなげたい
• デバイスごと・トピックごとにきめ細かい認可をかけ、なりすましや横取りを防ぎたい

主要概念と用語

• 名前空間（Namespace）: MQTT ブローカや Event Grid のプル/プッシュ機能を束ねる管理単位。MQTT を使うにはこの名前空間で MQTT 機能を有効化する
• MQTT ブローカ: 接続したクライアント間でメッセージを中継する pub/sub の中核。MQTT v3.1.1 と v5.0 をサポート
• クライアント: ブローカへ接続するデバイスやアプリ。クライアント認証情報（証明書のサブジェクトなど）で識別する
• トピック（MQTT トピック）: メッセージの宛先を表す階層的な文字列。発行者は特定トピックへ publish し、購読者は subscribe する
• トピック空間（Topic space）: ワイルドカードを含むトピックフィルタの集合。誰がどのトピックへ publish/subscribe できるかをこの単位でまとめて定義する
• パーミッションバインディング: クライアントグループとトピック空間を結びつけ、publisher か subscriber の権限を付与する設定
• ルーティング: ブローカが受け取った MQTT メッセージを、CloudEvents として Event Grid 名前空間トピックへ流し、Azure サービスへ届ける仕組み
• MQTT セッション: クライアントとブローカ間の接続状態。永続セッションでは切断中のメッセージ保持や再開ができる

仕様・制限・クォータ

• 対応プロトコル: MQTT v3.1.1 と v5.0。接続は TLS で暗号化し、平文接続は許可しない
• QoS: QoS 0 と QoS 1 をサポート。少なくとも 1 回配信のため、受信側は重複を前提に冪等に設計する
• 保持/共有購読など: MQTT v5.0 の機能（ユーザープロパティ、共有サブスクリプション、メッセージ有効期限など）に対応。利用可否は仕様の更新で変わり得るため公式を確認する
• メッセージサイズ・接続数・スループット: 1 メッセージのペイロード上限や同時接続クライアント数、毎秒のスループットなどに上限があり、必要に応じて引き上げを検討する。具体値は変動するため断定しない
• ルーティング先: MQTT メッセージは CloudEvents として名前空間トピックへルーティングでき、そこから Event Hubs や Service Bus などのハンドラへつなげられる

内部の仕組み

クライアントは TLS 接続でブローカへハンドシェイクし、提示した認証情報（X.509 証明書のサブジェクトや Entra ID トークンなど）でクライアントとして識別されます。識別されたクライアントはクライアントグループに分類され、グループに紐づくパーミッションバインディングによって、どのトピック空間へ publish/subscribe できるかが決まります。

発行者があるトピックへ publish すると、ブローカはそのトピックに一致するフィルタで subscribe している購読者すべてへメッセージを中継します。これがデバイス間 pub/sub の基本動作です。ワイルドカードを含むトピックフィルタにより、1 つの購読で複数トピックをまとめて受け取れます。

クラウド連携が必要な場合は、ブローカがメッセージを CloudEvents 形式に包んで Event Grid 名前空間トピックへルーティングします。そこから先は Event Grid のプル/プッシュ配信に乗り、Azure Functions や Event Hubs、Service Bus などへ届けてクラウド側の処理を起動できます。

設計パターン / ベストプラクティス

• トピック設計を先に固める: 階層を region/site/device/telemetry のように設計し、トピック空間とワイルドカードで認可をまとめやすくする
• 最小権限の認可: クライアントグループごとに publisher/subscriber を分け、デバイスは自分の領域のトピックだけ扱えるようにする
• テレメトリはルーティングで集約: デバイスからのテレメトリは名前空間トピックへルーティングし、Event Hubs でストリーム処理、Service Bus で確実な業務連携、と後段を使い分ける
• 冪等設計: QoS 1 の少なくとも 1 回配信を前提に、メッセージ ID 等で重複排除する
• 証明書のライフサイクル管理: 失効・ローテーションの運用を整備し、CA ベースの認証で大量デバイスを扱いやすくする

運用・監視

• Azure Monitor のメトリクスで、接続中クライアント数、publish/deliver の成否、ドロップ、ルーティングの配信状況などを監視する
• 診断ログを Log Analytics / Storage / Event Hubs へ送り、接続失敗や認可拒否、切断理由を追跡できるようにする
• 接続トラブルの切り分け: TLS のハンドシェイク、クライアント認証情報とクライアント識別の対応、パーミッションバインディングの権限、トピック空間のフィルタ一致を順に確認する
• ルーティング先（名前空間トピックの先のハンドラ）でデッドレターや配信失敗を監視し、取りこぼしを検知する

コスト

MQTT 機能は Event Grid 名前空間で提供され、運用に応じた従量課金が基本です。常時起動の専用ブローカを自前で持つ必要がありません。

セキュリティ

• 認証: クライアント証明書（X.509）による認証が基本で、CA ベースの一括登録に対応。アプリやサービスからの接続には Microsoft Entra ID 認証も利用できる
• 認可: クライアントグループ × トピック空間 × パーミッションバインディングで、トピック単位の publish/subscribe 権限を最小権限で設計する
• 通信の暗号化: 接続は TLS で保護され、平文の MQTT は許可しない
• ネットワーク制御: プライベートエンドポイントや公開アクセスの制限で、ブローカへの到達経路を絞れる

関連サービス・比較

最も近いのは AWS の IoT Core（MQTT ブローカ部分） です。どちらもマネージドな MQTT pub/sub と、メッセージのクラウドルーティングを提供します。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Event Grid 名前空間を作成し、MQTT を有効化
az eventgrid namespace create \
  --resource-group demo-rg \
  --name demo-ns \
  --location japaneast \
  --topic-spaces-configuration "{state:Enabled}"

# クライアントを登録（X.509 証明書のサブジェクト名で識別）
az eventgrid namespace client create \
  --resource-group demo-rg \
  --namespace-name demo-ns \
  --client-name device01 \
  --authentication-name "device01" \
  --state Enabled

# トピック空間を作成（このフィルタ集合へのアクセスをまとめて制御）
az eventgrid namespace topic-space create \
  --resource-group demo-rg \
  --namespace-name demo-ns \
  --name telemetry-space \
  --topic-templates "devices/+/telemetry"

# パーミッションバインディングで publisher 権限を付与
az eventgrid namespace permission-binding create \
  --resource-group demo-rg \
  --namespace-name demo-ns \
  --name device-publish \
  --client-group-name '$all' \
  --permission Publisher \
  --topic-space-name telemetry-space