Azure Event Grid を選択する

  • 10 分

多くのアプリケーションでは、何かが発生したときやいくつかのオブジェクトが変更されたとき、発行/サブスクライブ モデルを使用して、分散されているコンポーネントに通知を行います。 Azure で実行される Web API を使用する音楽共有アプリケーションがあるとします。 ユーザーが新しい曲をアップロードしたとき、そのジャンルに関心を持つ世界中のユーザーのデバイスにインストールされているすべてのモバイル アプリに通知する必要があります。

このアーキテクチャでは、音声ファイルの発行者は、共有される音楽に関心を持つサブスクライバーを知っている必要はありません。 また、一対多の関係を用意し、複数のサブスクライバーがこの新しい曲に関心があるかどうかを自由に選択できるようにします。 Azure Event Grid は、このようなアーキテクチャに最適なソリューションです。

Azure Event Grid とは

Azure Event Grid は、Azure Service Fabric を基盤として実行されるフル マネージドのイベント ルーティング サービスです。 Event Grid とは、Azure Blob Storage アカウントや Azure Media Services などのさまざまなソースから Azure Functions や Webhook などのさまざまなハンドラーに "イベント" を配布します。 Event Grid は、Azure でイベントベースのアプリケーションやサーバーレスのアプリケーションを簡単にビルドできるように開発されました。

Event Grid はほとんどの Azure サービスを発行者またはサブスクライバーとしてサポートしています。また、サードパーティのサービスでも使用できます。 動的に規模を変更できる低コストのメッセージング システムを備え、発行者はサブスクライバーに状態の変化について通知できます。 次は、Azure Event Grid が複数のソースからメッセージを受信し、サブスクリプションに基づいてそれらをイベント ハンドラーに配布している図です。

Azure Event Grid には、ソースをサブスクライバーに接続する概念がいくつかあります。

  • イベント: 発生内容。
  • イベント ソース: イベントの発生場所。
  • トピック: 発行者がイベントを送信するエンドポイント。
  • イベント サブスクリプション: イベントを (時には複数のハンドラーに) ルーティングするエンドポイントまたは組み込みメカニズム。 また、ハンドラーはサブスクリプションを使って受信イベントをインテリジェントにフィルター処理します。
  • イベント ハンドラー: イベントに反応するアプリまたはサービス。

次の図は、複数のイベント ソースと複数のイベント ハンドラーの間に配置された Azure Event Grid を示しています。 イベント ソースは Event Grid にイベントを送信し、Event Grid は関連するイベントをサブスクライバーに転送します。 Event Grid はトピックを使用し、どのイベントをどのハンドラーに送信するかを決定します。 イベント ソースによって各イベントに 1 つ以上のトピックがタグ付けされ、イベント ハンドラーによって関心があるトピックがサブスクライブされます。

Diagram of various event sources sending messages as topics to the Event Grid which in turn sends messages to subscribing event handlers.

イベントとは

イベントは Event Grid を通過するデータ メッセージであり、発生した内容を伝えます。 各イベントは自己完結型であり、最大 64 KB になります。Event Grid により定義されるスキーマに基づいていくつかの情報が含まれます。

[
  {
    "topic": string,
    "subject": string,
    "id": string,
    "eventType": string,
    "eventTime": string,
    "data":{
      object-unique-to-each-publisher
    },
    "dataVersion": string,
    "metadataVersion": string
  }
]
フィールド 説明
topic イベント ソースの完全なリソース パス。 この値は Event Grid によって指定されます。
subject 発行者が定義した、イベントの対象のパス。
id イベントの一意の識別子。
eventType このイベント ソース用に登録されたいずれかのイベントの種類。 この値に対してフィルターを作成できます (例: CustomerCreated、BlobDeleted、HttpRequestReceived)。
eventTime プロバイダーの UTC 時刻に基づく、イベントが生成された時刻。
data イベントの種類に関連する特定の情報。 たとえば、Azure Storage で作成されている新しいファイルに関するイベントには、lastTimeModified 値など、ファイルの詳細が含まれます。 または、Event Hubs イベントには、キャプチャ ファイルの URL が含まれます。 このフィールドは省略可能です。
dataVersion データ オブジェクトのスキーマ バージョン。 スキーマ バージョンは発行者によって定義されます。
metadataVersion イベント メタデータのスキーマ バージョン。 最上位プロパティのスキーマは Event Grid によって定義されます。 この値は Event Grid によって指定されます。

ヒント

Event Grid はイベントを送信し、何かが発生したか、変化したことを示します。 しかしながら、変更された実際のオブジェクトはイベント データに含まれません。 その代わり、多くの場合、変更されたオブジェクトを参照する目的で、URL または識別子が渡されます。

イベント ソースとは

イベント ソースは、Event Grid にイベントを送信する役割を担います。 各イベント ソースは、1 つまたは複数のイベントの種類に関連付けられます。 たとえば、Azure Storage は、BLOB 作成イベントのイベント ソースです。 IoT Hub は、デバイスによって作成されたイベントのためのイベント ソースです。 自分で定義したカスタム イベントのイベント ソースになるのは自分のアプリケーションです。 イベント ソースについては、この後で詳しく説明します。

Azure Event Grid には、イベント ソースと混同されることが多い、イベント パブリッシャーという概念があります。 イベント パブリッシャーは、Event Grid にイベントを送信することを決定するユーザーまたは組織です。 たとえば、Microsoft はいくつかの Azure サービスのためのイベントを発行しています。 イベントは自分のアプリケーションから発行できます。 Azure の外でサービスをホストしている組織は、Event Grid からイベントを発行できます。 イベント ソースは、そのパブリッシャーのためにイベントを生成する特定のサービスです。 これらの 2 つの用語は少々異なりますが、このユニットの目的上、Event Grid に "メッセージを送信するエンティティ" を表すために、"パブリッシャー" と "イベント ソース" を同じ意味で使用しています。

イベント トピックとは

イベント トピックはイベントをグループに分類するものです。 トピックはパブリック エンドポイントによって表されます。また、イベント ソースによりイベントが送信される送信先です。 アプリケーションを設計するとき、作成するトピック数を決定できます。 大規模なソリューションであれば、関連イベントのカテゴリ別にカスタム トピックが作成されます。小規模なソリューションであれば、すべてのイベントが 1 つのトピックに送信されることがあります。 たとえば、ユーザー アカウントの変更と注文の処理に関連するイベントを送信するアプリケーションを検討します。 イベント ハンドラーで両方のイベント カテゴリが必要になることはまずありません。 2 つのカスタム トピックを作成し、関心のあるトピックをイベント ハンドラーがサブスクライブできるようにします。 イベントのサブスクライバーはフィルターを適用し、特定のトピックから自分が求めるイベントの種類だけに絞り込むことができます。

トピックはシステム トピックとカスタム トピックに分割されます。

システム トピック

システム トピックは、Azure サービスが提供する組み込みのトピックです。 発行者がトピックを所有するため、Azure サブスクリプションにはシステム トピックが表示されませんが、トピックをサブスクライブすることはできます。 サブスクライブするには、イベントの発信元になるリソースに関する情報を入力します。 そのリソースにアクセスできる限り、そのイベントをサブスクライブできます。

カスタム トピック

カスタム トピックは、アプリケーションとサード パーティのトピックです。 カスタム トピックを作成した、またはカスタム トピックへのアクセス権を割り当てられた場合、サブスクリプション内にそのカスタム トピックが表示されます。

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

イベント サブスクリプションにより、イベント ハンドラーが受信を求めるトピックのイベントが定義されます。 サブスクリプションでは、その種類かその件名でイベントをフィルタリングできます。そのため、イベント ハンドラーが確実に関連イベントのみを受信できるようにすることができます。

イベント ハンドラーとは

イベント ハンドラー (イベント "サブスクライバー" と呼ばれることもあります) とは、Event Grid からイベントを受信できるあらゆるコンポーネント (アプリケーションまたはリソース) のことです。 たとえば、Azure Functions は、新しい曲が BLOB ストレージ アカウントに追加されたことに応答してコードを実行できます。 サブスクライバーは、自分が処理するイベントを決定できます。新しいイベントが使用できるようになると、関心のある各サブスクライバーに Event Grid から効率的に通知されます。ポーリングは必要ありません。

イベント ソースの種類

イベントは、次の Azure リソースの種類で生成される可能性があります。

システム トピックをサポートする Azure サービス

ここでは、システム トピックをサポートするいくつかの Azure サービスについて説明します。 システム トピックをサポートする Azure サービスの完全な一覧については、「Azure Event Grid でのシステム トピック」を参照してください。

  • Azure サブスクリプションとリソース グループ: サブスクリプションとリソース グループは、Azure の管理オプションに関連するイベントを生成します。 たとえば、ユーザーが仮想マシンを作成した場合、このソースによってイベントが生成されます。
  • コンテナー レジストリ: レジストリにあるイメージが追加、削除、変更されたとき、Azure Container Registry サービスによってイベントが生成されます。
  • Event Hubs: Event Hubs を使用すると、さまざまなデータ ソース (通常はログまたはメトリックに関連) からのイベントを処理したり、格納したりすることができます。 ファイルのキャプチャ時に、Event Hubs から Event Grid に対してイベントが生成されます。
  • Service Bus: アクティブなメッセージがあるが、アクティブなリスナーがいないとき、Service Bus では Event Grid にイベントが生成されます。
  • ストレージ アカウント: ユーザーが BLOB、ファイル、テーブル エントリ、キュー メッセージを追加するとき、ストレージ アカウントではイベントが生成されます。 イベント ソースとしては、BLOB アカウントと汎用 V2 アカウントの両方を使用できます。
  • Media Services: Media Services は動画および音声メディアをホストし、メディア ファイルの高度な管理機能を提供します。 Media Services では、エンコード ジョブが動画ファイルで開始されたときや完了したときに、イベントが生成されます。
  • Azure IoT Hub: IoT Hub は IoT デバイスと通信し、それから利用統計情報を収集します。 そのような通信が届くと、イベントが生成されます。

詳細については、「Azure Event Grid でのシステム トピック」を参照してください。

カスタム トピック

カスタム イベントを生成するには、REST API を使用するか、Java、GO、.NET、Node、Python、Ruby 上で Azure SDK を使用します。 たとえば、Azure App Service の Web Apps 機能でカスタム イベントを作成できます。 これは、ストレージ キューからメッセージがピックアップされるとき、worker ロールで発生する場合があります。

Azure 内でさまざまなイベント ソースが深く統合されることにより、ほとんどすべての Azure リソースに関連するイベントが Event Grid により配信されます。

イベント ハンドラー

Azure の次のオブジェクトの種類では、Event Grid からイベントを受け取ってそれを処理できます。

  • Azure Functions: Azure で実行されるカスタム コード。ホスト仮想サーバーまたはコンテナーの明示的な構成は必要ありません。 イベントに対する応答をコードでカスタマイズする場合、Azure 関数をイベント ハンドラーとして使用します。
  • Azure Logic Apps: Logic Apps を使ってビジネス プロセスを実装し、Event Grid イベントを処理します。 このシナリオでは、Webhook を明示的に作成しません。 Event Grid からのイベントを処理するようにロジック アプリを構成すると、Webhook が自動的に作成されます。
  • Webhook: Webhook とは、プッシュ アーキテクチャを実装する Web API です。 また、Azure Automation Runbook を使ってイベントを処理することもできます。 Webhook は、自動化された Runbook を使用したイベントの処理をサポートしています。 Runbook 用の Webhook を作成した後、Webhook ハンドラーを使用します。
  • Event Hubs: Event Hubs は、ソリューションで、イベント処理よりも前に Event Grid からイベントを取得する場合に使います。 イベントがイベント ハブに格納されたら、アプリケーションでは独自のスケジュールでイベント ハブからイベントを取得して処理できます。
  • Service Bus: サービス キューまたはトピックを、Event Grid からのイベントのハンドラーとして使用できます。
  • Storage キュー: Queue Storage を使って、プルする必要があるイベントを受け取ります。 応答に時間がかかりすぎる長期実行プロセスの場合に、Queue Storage を使用できます。 イベントを Queue Storage に送信することで、アプリでは独自のスケジュールでイベントをプルして処理することができます。
  • Microsoft Power Automate: Power Automate を使用してワークフローをホストすることもできますが、これは技術以外のスタッフにとって、より使いやすいツールです。

詳細については、「イベント ハンドラー」を参照してください。

Event Grid を使用する場合

次の特徴が求められる場合に、Event Grid を使用します。

  • 簡単: Event Grid では、ソースをサブスクライバーに簡単に接続できます。
  • 高度なフィルタリング:サブスクリプションでは、トピックから受け取るイベントを厳しく制限できます。
  • 展開:同じイベントやトピックにエンドポイントを無制限にサブスクライブさせることができます。
  • 信頼性:Event Grid では、イベントの配信を、各サブスクリプションに対して最大で 24 時間再試行します。
  • イベントあたり従量課金:送信するイベント数のみに対して支払いが行われます。

Event Grid はシンプルですが、汎用性のあるイベント配信システムです。 これを使用すると、確実かつ迅速に個別のイベントをサブスクライバーに配信できます。 検討するメッセージング モデルはもう 1 つあります。大規模な "ストリーム" のイベントを配信するにはどうすればよいでしょうか。 このようなシナリオの場合、Event Grid は、一度の配信で 1 つのイベントを配信するように設計されているため、最適ではありません。 代わりに、別の Azure サービスであるEvent Hubs に目を向ける必要があります。