Skip to content

MS_AzureEventGrid

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 2 revisions

Azure Event Grid

概要

説明

  • イベント駆動のリアクティブ・プログラミングを
    可能にするメッセージのイベント・ハンドラ。
  • 以下の用途で使用される。
    • 操作の自動化
    • アプリケーション統合
    • サーバーレスの 1 コンポーネント

図表

アーキテクチャは下図のようになっており、

接続している。

図表

補足（Event Grid が担うのは「イベントの配線」）: 図の構造が示すとおり、
Event Grid 自体はメッセージを溜めるものではない。
「誰が発したイベントを、誰に届けるか」という配線を担当する。

【従来】 各サービスが個別に通知先を実装する
  Blob Storage ──独自の仕組み──→ Functions
  Key Vault    ──別の仕組み──→ Logic Apps
      ↑ 組み合わせの数だけ実装が必要

【Event Grid】 配線を一元化する
  Blob Storage ┐              ┌→ Functions
  Key Vault    ├→【Event Grid】┼→ Logic Apps
  カスタム     ┘  （フィルタ）  └→ Webhook

これにより、

効果 内容
疎結合 発生源は「誰が受け取るか」を知らない
後から増やせる サブスクリプションを追加するだけ
フィルタできる 必要なイベントだけ届ける
リトライが基盤側 ハンドラが一時的に落ちても再送される

クラウド アプリケーション アーキテクチャ ガイドの
「イベントドリブン アーキテクチャ」で述べた
Pub/Sub 型の具体的な実装がこれにあたる。

機能

機能要件的

非機能要件的

  • 拡張性・高性能（スケーラビリティ）
  • 信頼性（リトライ機能）
  • セキュリティ（認証）
    • SAS
    • キー

移行メモ（体裁）: 原典は括弧の閉じが欠落していたため補った
（「スケーラビリティ」「リトライ機能」の 2 箇所）。

補足（配信保証の性質）: 「信頼性（リトライ機能）」の中身を
押さえておく必要がある。

性質 内容
配信保証 At least once（少なくとも 1 回）
重複 起こり得る（ハンドラ側で冪等にする必要がある）
順序 保証されない
リトライ 指数バックオフで最大 24 時間（既定）
失敗時 **配信不能（デッド レター）**を Storage に退避できる

特に重要なのは、

  • 同じイベントが 2 回届くことがある → ハンドラを冪等に作る、
  • 順序は保証されない → 順序が要るなら
    Azure Service Busのセッション、
    または Event Hubsのパーティションを使う

という 2 点である。
クラウド アプリケーション アーキテクチャ ガイドの
「冪等操作の設計」がそのまま要求される。

また、デッド レターの設定を忘れると
失敗したイベントは黙って捨てられる。
本番では必ず設定しておくこと。

用語

イベント関連

イベント

  • イベントの最大許容サイズは 1 MB
  • 64 KB を超えるイベントは、64 KB の増分単位で課金。

補足（イベントに「データそのもの」を載せない）: 1 MB という上限が
示すとおり、Event Grid は大きなデータを運ぶ仕組みではない。

設計上の定石は、イベントには「場所」だけを載せることである。

【悪い例】 イベントにファイルの中身を載せる（数 MB）
             → サイズ制限、課金、性能のすべてで不利

【良い例】 イベントには「Blob の URL」だけを載せる
             ↓ ハンドラが必要に応じて取りに行く
           Blob Storage から本体を読む

これは Claim Check パターンと呼ばれる
（クラウド設計パターン）。
実際、Blob Storage が発するイベントは
標準でこの形（URL とメタデータのみ）になっている。

スキーマ

イベントのスキーマ

  • Event Grid Schema
    Azure 内だけで通用するフォーマット
    • 必須プロパティ
      • id：イベントの一意識別子
      • subject：パス
      • eventType：種類
      • eventTime：生成時刻（UTC）
    • その他プロパティ
      • topic：
      • data：データ
  • Cloud Event Schema
    クラウド間連携できるフォーマット
    • 必須プロパティ
      • id：イベントの一意識別子
      • source：イベント・ソースの種類、組織
      • type：イベントのタイプを説明する値
      • specversion：仕様のバージョン
    • その他プロパティ
      • datacontenttype：
      • dataschema：
      • time：
      • ...

補足（CloudEvents を選ぶべき理由）: 2 つのスキーマのうち、
新規開発では CloudEvents（v1.0）を選ぶのが現在の推奨である。

Event Grid Schema CloudEvents
標準化 Azure 独自 CNCF の標準仕様
他クラウドとの連携 不可 可（AWS、GCP、Knative 等も対応）
ツールの対応 Azure のみ 幅広い
Azure での扱い 従来の既定 入出力とも対応済み

ベンダ ロックインの回避という観点で意味があるほか、
Kubernetes（Knative Eventing）や Dapr との連携でも
CloudEvents が前提になる。

なお、Event Grid は入力と出力で別々にスキーマを指定できるため、
「Azure のサービスが発する Event Grid Schema を受け取り、
ハンドラには CloudEvents で渡す」という変換も可能である。

Pub/Subメッセージング・モデル

パブリッシャ

イベントの送信者

サブスクライバ

イベントの受信者

アーキテクチャ

イベント・ソース

イベントの発生元（≒パブリッシャ）

※ https://docs.microsoft.com/ja-jp/azure/event-grid/overview#event-sources

補足（「Azure リソース グループ」が挙がっている意味）: 一覧の中で
「Azure リソース グループ」だけ性質が違う。
これはリソースの作成・変更・削除という
管理操作（コントロール プレーン）のイベントを指す
（Azureの監視と管理の
「コントロール / 管理ログ」に対応）。

これを使うと、

用途 内容
ガバナンス タグの無いリソースが作られたら通知／自動でタグを付ける
セキュリティ パブリック IP が作られたら警告
コスト管理 高価な SKU の作成を検知
構成管理 変更を CMDB に反映

といった自動的な統制が実装できる。
クラウド利用時の注意事項で述べた
**「人が守るルールから、システムが強制する制約へ」**の
一手段になる（Azure Policy と併用する）。

トピック

  • イベントを受信するエンドポイント（サブスクライバの入口）
  • システム・トピック、カスタム・トピック
    • システム・トピック
      Azure サービスによって提供される組み込みのトピック。
      • パブリッシャがトピックを所有
      • サブスクリプションに表示されない。
      • サブスクライブすることはできる。
    • カスタム・トピック
      アプリケーションとサード・パーティのカスタムのトピックを作成しアクセス権を割り当てる。
      • パブリッシャとトピックの関係を設定可能（1:1 or n:1）
      • サブスクリプションに表示される。
      • （当然）サブスクライブできる。

イベント・サブスクリプション

  • トピック → イベント・ハンドラ（サブスクライバの出口）
  • トピックのサブスクライブ
  • イベント・ハンドラへ、
    イベントのルーティング・フィルタリングなど
    • ファンアウト
      イベントの複製（マルチキャスト・イベント風）
    • フィルタ
      イベントのフィルタリング
    • リトライ機能

補足（フィルタの掛け方が費用と性能を左右する）: Event Grid の課金は
**操作数（イベントの配信数）**に基づくため、
フィルタを適切に掛けることが直接コストに効く。

フィルタの種類は次のとおり。

種類 例 用途
イベントの種類 BlobCreated のみ 最も基本
subject の前方／後方一致 /blobs/input/ で始まる、.csv で終わる フォルダやファイル種別で絞る
高度なフィルタ data.contentLength が一定以上 JSON の中身で判定

ハンドラ側で「自分に関係ないイベント」を捨てているなら、
それはフィルタで絞るべきものである
（無駄に配信され、課金され、ハンドラが起動している）。

なお、「ファンアウト」は同じイベントを複数のハンドラに配る機能で、
各ハンドラは独立してリトライされる。
1 つが失敗しても他に影響しない点が、
自前で分岐を実装する場合との違いになる。

イベント・ハンドラ

イベントの送信先（≒サブスクライバ）

※ https://docs.microsoft.com/ja-jp/azure/event-grid/overview#event-handlers

補足（ハンドラに Service Bus / Queue を選ぶ理由）: 一覧に
他のメッセージング サービスが含まれている点が興味深い。
これには実務上の理由がある。

【直接 Functions に配る場合】
  Event Grid →（大量のイベント）→ Functions が一斉にスケール
                                      ↓
                                  下流の DB を圧迫する

【Queue / Service Bus を挟む場合】
  Event Grid → Queue（溜める）→ Worker が一定速度で処理
                                      ↓
                                  下流を守れる（負荷平準化）

つまり、Event Grid は「速く配る」ことに最適化されているため、
受け側が耐えられない場合はキューで受け止めるという設計になる
（クラウド アプリケーション アーキテクチャ ガイドの
「キュー ベースの負荷平準化」）。

また、Event Grid は順序を保証しないため、
順序が要る処理は Service Bus のセッションに渡す、という
使い分けもある。

その他

イベント・ドメイン

マルチテナント環境下で、各社のトピックへのイベント送信を行う仕組み。

補足: 「イベント ドメイン」は、
多数のトピックを 1 つの管理単位にまとめる機能である。

【ドメイン無し】 テナントごとにトピックを作る
  顧客A 用トピック（エンドポイント・認証キーが個別）
  顧客B 用トピック
  ... 数千テナントだと管理不能

【イベント ドメイン】
  1 つのドメイン エンドポイントに発行
     ↓ イベントの topic フィールドで宛先テナントを指定
  各テナントは自分のトピックだけをサブスクライブ（他は見えない）

送信側はエンドポイント 1 つ・認証 1 つで済み、
受信側は自分宛てだけが見える（アクセス制御が効く）。
SaaS 事業者が顧客ごとに通知を出す、といった用途に向く
（クラウド アプリケーション アーキテクチャ ガイドの
「デプロイ スタンプ」と同種のマルチテナント設計）。

パートナー・イベント

補足: 現在は Partner Events として、
Auth0、Tribal Group、SAP などのサードパーティ SaaS が
Azure のイベント ソースとして登録されている。
これにより、外部 SaaS の出来事を契機に Azure 側の処理を起動する
（例: ID プロバイダでのユーザ作成 → 社内システムへの反映）ことが
Webhook を自前で実装せずに実現できる。

参考

Qiita

https://qiita.com/tags/eventgrid

microsoft.com

Microsoft Azure

Microsoft Docs

Tags: 移行, クラウド, IoT, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally