Azure Blob Storage や Azure Resource Manager などの複数の Azure サービスからのイベントに、ほぼリアルタイムで反応する必要があるアプリケーションを開発しています。
アプリケーションは以下の要件を満たす必要があります：
手動の介入なしに、大量のイベントを処理すること。
イベントの種類やリソースパターンに基づいて、アプリケーションに関連する特定のイベントのみを受信すること。
処理アプリケーションが一時的に利用不能な場合でも、イベントを逃さないようにすること。
インフラストラクチャを管理せずにイベントを処理するために、Azure Functions を使用すること。
イベントのルーティングと処理に必要なカスタムコードの量を最小限に抑えること。
ソリューションを開発する必要があります。
解決策： 定期的な間隔で Azure サービスの変更を**ポーリング（監視）**するように Azure Logic Apps を設定します。Logic Apps 内で条件ロジックを適用して、関連するイベントをフィルタリングします。フィルタリングされたイベントを処理するために、Logic Apps から Azure Functions をトリガーします。
この解決策は目標を満たしていますか？
正解：B
この解決策が「いいえ」である理由は、主に 「ほぼリアルタイム」という要件を満たせないこと と、「ポーリング方式」による非効率性 にあります。
1. 「ほぼリアルタイム (near-real time)」の欠如
問題点: 解決策では「定期的な間隔でポーリングする」としています。ポーリング間隔が例えば 1 分であれば、イベントが発生してから最大 1 分の遅延が発生します。
Event Grid の利点: イベント駆動型（プッシュ方式）である Azure Event Grid を使えば、イベントが発生した瞬間に通知が飛ぶため、真の「ほぼリアルタイム」を実現できます。
2. 大量イベント処理への不適合
問題点: 大量のイベントが発生する場合、それらすべてを「ポーリング」で確認し、Logic Apps のワークフローを毎回動かすのは、コストとパフォーマンスの両面で非常に非効率です。
3. カスタムコードと構成の最小化
問題点: Logic Apps で複雑なフィルタリング条件を設定するのは、Event Grid のサブスクリプションフィルター（設定のみで完結）に比べると、ワークフローの設計という手間がかかります。
コメント