モバイルアプリからメッセージを受信した際にキューデータを処理するアプリケーションを開発しています。 以下の要件があります：
キューのサイズが 80 GB を超えないこと。
メッセージの 先入れ先出し (FIFO) 順序を使用すること。
Azure の コストを最小限 に抑えること。
ソリューション： .NET API を使用して、Azure Service Bus Queue にメッセージを追加します。Azure Service Bus Queue によってトリガーされる Azure Windows VM を作成します。
このソリューションは目標を達成していますか？
正解：B
このソリューションが「いいえ」である最大の理由は、「コストを最小限に抑える」という要件を満たせないからです。
1. コストの最適化に失敗している
Azure VM の問題: 問題文に「メッセージは一貫して（継続的に）送信されるわけではない」とあります。VM を使用する場合、メッセージが届かない待機時間中もインスタンスの実行料金（Windows VM ならライセンス料も含む）が発生し続けます。
サーバーレスの欠如: コストを最小化するには、メッセージが届いたときだけ実行され、待機時間は課金されない Azure Functions (Consumption Plan) を使用するのが最適解です。
2. 「トリガー」の非効率性
Azure VM 自体は「イベントによって自動的に起動する」サーバーレスな仕組みではありません。VM 内で常にプログラムを動かしてキューを監視（ポーリング）し続ける必要があり、設計として非効率です。
3. Service Bus は要件に合致している
メッセージングサービスとしての Service Bus は、FIFO (Sessions を使用) および 80 GB の容量制限 という要件を完璧に満たしています。しかし、処理側（VM）の選択がコスト要件に反しているため、ソリューション全体としては不合格となります。
コメント