Azure Event Grid

解決する課題

リソースで「何かが起きた」ことを、ポーリングせずに関係するシステムへ即座に伝えられます。

• 1 つのイベントを**複数のハンドラーへ同報（ファンアウト）**したい
• 発行側は宛先を意識せず、疎結合にイベントを通知したい
• Blob 作成・リソース変更などの Azure 内部イベントに反応して処理を起動したい
• 受け手が一時的にダウンしていても**リトライと配信不能（デッドレター）**で取りこぼしたくない

主要概念と用語

• イベント: 「何かが起きた」という最小限の事実。スキーマは CloudEvents 1.0（推奨）または独自の Event Grid スキーマ
• 発行元（パブリッシャー / ソース）: イベントを送る側。Azure サービス、独自アプリ、SaaS（Partner）など
• トピック: イベントの送信先エンドポイント。システム トピック（Azure サービス由来）、カスタム トピック（独自アプリ由来）、パートナー トピック（SaaS 由来）
• イベント サブスクリプション: トピックとハンドラーを結びつけ、フィルター・リトライ・デッドレターを定義する設定単位
• イベント ハンドラー（サブスクライバー）: Azure Functions / Logic Apps / Webhook / Event Hubs / Service Bus（Queue/Topic）/ Storage Queue / Hybrid Connections / Relay など
• フィルター: イベントタイプ・サブジェクトの前後方一致・属性（advanced filter）で購読者ごとに振り分け
• MQTT ブローカー機能: Event Grid 名前空間が提供する MQTT v3.1.1 / v5.0 のメッセージング（IoT デバイス向けの pub/sub）

仕様・制限・クォータ

• プッシュ型が基本: トピックへ送られたイベントを、各サブスクライバーへ HTTP で配信（名前空間ではプル配信も選択可）
• 配信の信頼性: 配信は 少なくとも 1 回（at-least-once）。同じイベントが重複し得るため、ハンドラーは冪等に設計する
• 順序保証は無し: イベントの到着順は保証されない
• リトライ: 既定で最大 24 時間／最大 30 回、指数バックオフでリトライ。失敗し続けたイベントは **デッドレター先（Blob）**へ退避できる
• イベントサイズ: Event Grid Topics では 1 イベント最大 1 MB（課金は 64 KB 単位で切り上げ）
• CloudEvents / Event Grid スキーマ: 受信・配信時のスキーマを選択でき、相互変換も可能
• サブスクリプション数・スループットなどはトピック種別ごとに上限があり、必要に応じて引き上げを検討

内部の仕組み

発行されたイベントは、まずトピックで受け取られ、各イベント サブスクリプションのフィルター条件に照合されます。条件に一致したサブスクライバーへ、Event Grid が HTTP でプッシュ配信します（ハンドラー側のポーリングは不要）。

ファンアウトは、1 つのトピックに複数のイベント サブスクリプションを紐づけることで実現します。各サブスクリプションは独立にフィルター・リトライ・デッドレターを持つため、ハンドラーごとに配信条件と再試行の挙動を分けられます。

配信に失敗した場合、Event Grid は指数バックオフでリトライし、リトライ期限／回数を超えると（設定していれば）デッドレター用の Blob コンテナーへイベントを書き出します。これにより、受け手の一時障害でイベントを失わずに済みます。Webhook ハンドラーを使う場合は、なりすまし防止のための**検証ハンドシェイク（validation handshake）**または Microsoft Entra ID 連携が必要です。

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

• ファンアウト: 1 トピック → 複数イベント サブスクリプション → 各ハンドラー（Functions / Logic Apps など）で並列処理
• バッファが要るなら Service Bus / Event Hubs を挟む: ハンドラーの処理が重い・流量変動が大きい場合は、ハンドラー先を Service Bus Queue/Topic や Event Hubs にして取りこぼしと急なスパイクを吸収する
• Service Bus Topics との役割分担: Service Bus Topics はブローカー内にメッセージを保持してプルで取り出すエンタープライズメッセージング、Event Grid はイベントをプッシュで配るルーティング基盤。「業務処理の確実な引き渡し」は Service Bus、「事実の通知・配布」は Event Grid と捉えると整理しやすい
• 冪等設計: at-least-once と無順序を前提に、イベント ID で重複排除し副作用を冪等化する
• デッドレター + リトライポリシーを必ず設定し、失敗イベントを失わない

運用・監視

• Azure Monitor のメトリクスで PublishSuccessCount / PublishFailCount / DeliverySuccessCount / DeliveryAttemptFailCount / DeadLetteredCount などを監視する
• 配信失敗時のチェック: ハンドラー側の HTTP 応答コード、エンドポイントの到達性、Webhook の検証状態、サブスクリプションのフィルター条件を確認
• デッドレター先 Blob を定期的に確認し、退避イベントの原因分析と再処理の運用を用意する
• 診断ログを Log Analytics / Storage / Event Hubs へ送って配信失敗・デッドレターを追跡できる

コスト

Event Grid はサーバーレスで、操作数（オペレーション）課金が基本です。常時起動のインフラ費用は不要で、無料枠も用意されています。

セキュリティ

• 認証/認可: 配信先 Webhook は Microsoft Entra ID 連携または検証ハンドシェイクで保護。発行側・操作権限は Azure RBAC で制御
• マネージド ID: トピック/名前空間にマネージド ID を付与し、配信先（Service Bus / Event Hubs / Storage Queue）へ資格情報レスで配信できる
• ネットワーク制御: プライベート エンドポイントや IP ファイアウォール、公開アクセス無効化でトピックを保護できる
• 鍵管理: アクセスキーは保護・ローテーションし、可能なら Entra ID 認証へ寄せる

関連サービス・比較（AWS との対応）

Event Grid は AWS の **SNS（通知・ファンアウト）**と **EventBridge（イベントルーティング）**の両方の役割を担います。比較の主軸として SNS との対応を示します。

ハンズオン / CLI例

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

# カスタムトピックを作成（独自アプリのイベント送信先）
az eventgrid topic create \
  --resource-group demo-rg \
  --name demo-topic \
  --location japaneast

# トピックのエンドポイントとアクセスキーを取得
TOPIC_ENDPOINT=$(az eventgrid topic show --resource-group demo-rg --name demo-topic --query "endpoint" -o tsv)
TOPIC_KEY=$(az eventgrid topic key list --resource-group demo-rg --name demo-topic --query "key1" -o tsv)

# Webhook をハンドラーにしてイベント サブスクリプションを作成（ファンアウトは本コマンドを複数回）
az eventgrid event-subscription create \
  --name to-webhook \
  --source-resource-id "$(az eventgrid topic show -g demo-rg -n demo-topic --query id -o tsv)" \
  --endpoint "https://example.com/api/eventgrid" \
  --included-event-types "Order.Created"

# カスタムトピックへイベントを発行（Event Grid スキーマの例）
curl -X POST "$TOPIC_ENDPOINT" \
  -H "aeg-sas-key: $TOPIC_KEY" \
  -H "Content-Type: application/json" \
  -d '[{
    "id": "1",
    "eventType": "Order.Created",
    "subject": "orders/123",
    "eventTime": "2026-06-03T00:00:00Z",
    "data": { "orderId": "123" },
    "dataVersion": "1.0"
  }]'