Azure Blob Storage や Azure Resource Manager などの複数の Azure サービスからのイベントに、ほぼリアルタイムで反応する必要があるアプリケーションを開発しています。
アプリケーションは以下の要件を満たす必要があります：
手動の介入なしに、大量のイベントを処理すること。
イベントの種類やリソースパターンに基づいて、アプリケーションに関連する特定のイベントのみを受信すること。
処理アプリケーションが一時的に利用不能な場合でも、イベントを逃さないようにすること。
インフラストラクチャを管理せずにイベントを処理するために、Azure Functions を使用すること。
イベントのルーティングと処理に必要なカスタムコードの量を最小限に抑えること。
ソリューションを開発する必要があります。
解決策： Azure サービスからイベントを受信するために Azure Event Hubs をセットアップします。イベントを処理するために、Event Hub トリガーを使用する Azure Functions を使用したカスタムアプリケーションを開発します。関連するイベントを選択するために、Functions 内にカスタムフィルタリングロジックを実装します。
この解決策は目標を満たしていますか？
正解：B
この解決策が「いいえ」である理由は、主に 「カスタムコードを最小限に抑える」という要件を満たしていないから です。
1. カスタムフィルタリングロジックの問題
要件： カスタムコードの量を最小限に抑える。
解決策の不備： Event Hubs は、受信したデータの中身を判断してフィルタリングして配信する機能を持っていません。そのため、解決策にある通り「Functions 内にカスタムフィルタリングロジックを実装」する必要があります。これは、不要なイベントまで一度 Functions が受け取ってからコードで捨てることを意味し、要件に反します。
2. ルーティングの複雑さ
Event Grid の場合： イベントのルーティング（どのイベントをどこへ送るか）を GUIや設定ファイル（サブスクリプションのフィルター設定）だけで完結 できます。
Event Hubs の場合： 大量のデータをストリーミングすることには長けていますが、特定のイベントタイプに基づいて自動的に振り分ける機能がないため、コード量が増えてしまいます。
3. イベントソースとの親和性
Azure Blob Storage や Azure Resource Manager の状態変化を「イベント」として扱う場合、これらは Azure Event Grid と最初から連携できるように設計されています。Event Hubs を使うには、一旦 Event Grid で受け取ったものを Event Hubs に流すなどの追加設定が必要になり、構成が冗長になります。
コメント