Azure Blob Storage や Azure Resource Manager などの複数の Azure サービスからのイベントに、ほぼリアルタイムで反応する必要があるアプリケーションを開発しています。
アプリケーションは以下の要件を満たす必要があります：
手動の介入なしに、大量のイベントを処理すること。
イベントの種類やリソースパターンに基づいて、アプリケーションに関連する特定のイベントのみを受信すること。
処理アプリケーションが一時的に利用不能な場合でも、イベントを逃さないようにすること。
インフラストラクチャを管理せずにイベントを処理するために、Azure Functions を使用すること。
イベントのルーティングと処理に必要なカスタムコードの量を最小限に抑えること。
ソリューションを開発する必要があります。
解決策： Azure Service Bus 名前空間をデプロイします。Azure サービスが Service Bus にイベントを送信するように構成します。イベントを処理するために、Service Bus トリガーを使用する Azure Functions を実装します。Service Bus のセッションとメッセージの遅延（deferral）を使用して、イベントの順序と信頼性を管理します。
この解決策は目標を満たしていますか？
正解：B
この解決策が「いいえ」である最大の理由は、「カスタムコードを最小限に抑える」という要件に反し、構成が複雑すぎるからです。
1. ネイティブ統合の不在
Azure Blob Storage や Azure Resource Manager (ARM) などの Azure サービスは、Azure Event Grid とネイティブに統合されています。これらのサービスから直接 Service Bus へイベントを送信するように「構成」するには、多くの場合、仲介するためのカスタムコードや追加のロジックが必要になります。
2. イベントフィルタリングの要件
要件には「特定のイベントのみを受信する（フィルタリング）」とあります。
Event Grid: 組み込みのフィルタリング機能（サブスクリプション側の設定）により、カスタムコードなしで「特定の種類のイベントだけを転送する」ことが可能です。
Service Bus: Service Bus 自体にデータを送る前にフィルタリングするか、受信側でロジックを書く必要があり、Event Grid に比べて手間がかかります。
コメント