(仮) ブログ

主にWeb Apps や、Azure PaaS サービス を使う際に役立ちそうなことを書こうと思っています。

Azure Event Grid が一般公開(GA)になりました

目次

Azure Event Grid の一般公開(GA)

先週、Azure Event Grid が一般公開(GA)されました。 プレビューの時はいまいち良さがわかっていなかったのですが、一般公開を機に改めて勉強してみたところ、非常にいいサービスだと感じましたので書いていこうと思います。

azure.microsoft.com

ドキュメント内で記載されている、 Event Grid の具体例は、下記の 3 つです。

  • Blob Storage コンテナーに新しい写真が追加されるたびに画像分析を実行するサーバーレス関数

  • 仮想マシンが作成された場合や SQL Database がスピンアップされた場合、Event Grid は Azure Automation に通知することができ、サービス構成が正しく設定されているかの Validation や、タグ付けを自動で行うことが可能

  • オンプレミスアプリケーションのデータを送信するカスタム トピックを作成して、その後の処理を Azure で自動化

個人的には、 Youtube 動画で紹介している、既存のオンプレミス上のアプリケーションとの連携が熱いです。 既存のアプリケーションのコードを大きく変更することなく、他の Azure サービスと容易に連携ができる点が非常にいいです。

youtu.be

Azure Functions のトリガーとの違い

上の公式ドキュメントの Azure Functions の例を見たときに、

「Azure Functions には、すでに Blob Trigger や、HTTP Trigger があるのに、何で Event Grid を経由する方がいいの?」

と、思う方もいると思います。

Blob Trigger は、10,000 以上の BLOB が含まれるコンテナに対して、ログ ファイルをスキャンするという処理を行います。 実は、この処理に時間がかかって、長時間 Function がトリガーされないことがあるのです。 Event Grid と連携することで、ファイルの数が多いコンテナーに対しても高速に動作するようになります。

監視対象の BLOB コンテナーに 10,000 を超える BLOB が含まれる場合は、Functions ランタイムによりログ ファイルがスキャンされ、新規または変更された BLOB が監視されます。 このプロセスによって遅延が発生することがあります。 関数は、BLOB が作成されてから数分以上経過しないとトリガーされない可能性があります。 また、 ストレージ ログは "ベスト エフォート" ベースで作成されます。 すべてのイベントがキャプチャされる保証はありません。 ある条件下では、ログが欠落する可能性があります。 より高速で信頼性の高い BLOB 処理が必要な場合は、BLOB 作成時にキュー メッセージを作成することを検討してください。 次に、BLOB トリガーの代わりにキュー トリガーを使用して BLOB を処理します。 別のオプションは、Event Grid の使用です。「Event Grid を使用して、アップロードされたイメージのサイズ変更を自動化する」のチュートリアルをご覧ください。

docs.microsoft.com

なお、Event Grid 自体は、コンテンツを送信するわけではないため、実際のデータ取得は Azure Functions から入力バインドで取ってくる必要があります。

他のメッセージングサービスとの比較はこちらに書かれています。

docs.microsoft.com

また、配信の再試行の自動化も魅力的です。Event Grid は、自動的に指数バックオフ再試行ポリシーに基づいて配信を再試行します。

Event Grid は、HTTP 応答コードを使用してイベントの受信を確認します。

成功コード 次の HTTP 応答コードは、イベントが Webhook に正常に配信されていることを示します。 Event Grid は、配信が完了したとみなします。

  • 200 OK
  • 202 受理されました

エラー コード

次の HTTP 応答コードは、イベントの配信が失敗したことを示します。 Event Grid は、イベントの送信を再試行します。

その他の応答コードや応答がないことはエラーを示します。 Event Grid は配信を再試行します。

docs.microsoft.com

通常 HTTP 要求が失敗した場合には、自分でリトライをかけるように実装する必要がありましたが、Event Grid を経由することでその手間が軽減します。 また、複数のイベントハンドラーに対してメッセージの送信が可能になるため、Teams に投稿しつつ、メールを送ったり、Web サーバー上で複雑な処理を行ったりと、アプリからひとつのリクエストを投げるだけで Event Grid 上で処理の並列化が可能になります。

認証キーの管理も非常に楽になります。Azure Functions では、 認証キーの管理は自分で行う必要があり、複数の Function を呼び出すアプリケーションになると、その管理は非常に面倒です。Event Grid を経由することで管理すべきキーは Event Grid で統一されますので、管理は楽になるかと思います。

他にもいい点

データベースに変更があったかどうか、リソースに何か更新があったかなど、これまでロング ポーリングをして確認していたイベントを、Event Grid をうまく活用することで検知できるようになります。定期的に通信を行うようなアプリケーションは、月単位で見ると通信料がとんでもないことになったりするので、費用も抑えられますね。

最後に

Event Grid は100万イベントまで無料なので、色々と触って試してみてください。 現在、実際に触って色々と試しているところなので、そのうちそれについて書こうと思います。