はじめに
Azure Functionsの専用(App Service)プランでシステムを運用していた際に、昨日までは正常に動いていたのに、突然動かなくなるという事象に遭遇しました。
私が構築していたのは、Blob Storageにファイルを置くと自動的に検知され、Event Hubs経由でFunctionsを呼び出してメールを送信する仕組みです。
最初は正常に動いていましたが、ある日突然、ファイルをアップロードしても通知メールが届かなくなりました。
本記事では、そのときの調査過程で分かった原因と解決策を紹介します。
システム構成
当時利用していたシステムの流れは以下のとおりです。
- Blob Storage にファイルをアップロード
- Event Grid がファイルアップロードを検知
- Event Hubs にイベントを送信
- Azure Functions がイベントを受け取り、メール送信
発生した問題
ある日、ユーザーから「ファイルをアップロードしたのに通知メールが届かない」との連絡がありました。調査の結果は以下のとおりです。
| コンポーネント | 状況 |
|---|---|
| Event Grid | 正常にイベントを検知 |
| Event Hubs | メッセージを受信済み（メトリクスで確認） |
| Azure Functions | 実行ログなし（呼び出されていない状態） |
つまり、Event Hubsまでは処理が流れているのに、Functionsに到達していない状況でした。
調査で判明した原因
日本語のMS公式ドキュメントには以下の記載がありました。
つまり、専用(App Service)プランでは数分間の非アクティブ後にアイドル化し、HTTP以外のトリガー（今回の場合はEvent Hubs）は反応しなくなる仕様であることが分かりました。
解決策：alwaysOn を有効化
「alwaysOn (常時接続)」を有効化することで、Functionsを常にアクティブに保ち、イベントを確実に処理できるようになりました。
方法①：Azure Portal設定手順
-
Azure Portalで対象のFunction Appを開く
-
左メニューから 「設定」>「構成」 を選択
-
「全般設定」 タブを開く
-
「常時接続」を オン に変更
-
保存
方法②：Azure CLI（IaC/自動化向け）
# alwaysOn を有効化
az functionapp config set \
--resource-group <リソースグループ名> \
--name <Functions名> \
--always-on true
この設定を行った後、再びFunctionsが安定して呼び出され、メール送信が復旧しました。
プランごとの違い
今回の経験を通じて、Functionsのホスティングプランごとに挙動が異なることを改めて理解しました。
| ホスティング プラン | Always On 必要性 | 主な特徴 | 典型ユースケース |
|---|---|---|---|
| 従量課金 | 不要 | 真のサーバーレス。イベントに応じ自動スケール | 不定期イベント、コスト効率重視 |
| Flex 従量課金 | 不要 | Linux 専用。VNet/メモリ選択/スケールの柔軟性 | 私設ネットワークや大規模スケール |
| Premium | 不要 | **常時ウォーム（Always Ready）**でコールドスタート回避、VNet/長時間実行 | 低遅延・高スループット・隔離要件 |
| 専用（App Service） | 必要 | Web Apps と同居可。非アクティブでアイドル化 | 既存 App Service 資産の流用 |
まとめ
- 事象: 専用(App Service)プランのFunctionsがEvent Hubsからトリガーされなかった
- 原因: アイドル状態により非HTTPトリガーを受け付けなかった
- 解決策: 「alwaysOn (常時接続)」を有効化
- 学び: プラン選定はコストだけでなく、挙動の違いを理解して行うことが重要
専用（App Service）プランは 既存の App Service 資産を流用しやすいため採用しましたが、非アクティブ時にランタイムがアイドル化し、HTTP 以外のトリガーでは起きないという仕様を見落としていました。
同様の構成の方は、Function App の alwaysOn (常時接続)を有効化してください