Azure Functions

解決する課題

サーバーを常時立てておくコストや運用の手間を、イベント駆動の実行に置き換えられます。

• サーバーを常駐させるのはもったいない／面倒 → トリガー発生時だけ動かす
• 急なスパイクに自動でスケールしてほしい（消費プランは 0 台までスケールイン）
• 「Blob がアップされたら処理」「キューにメッセージが来たら処理」「HTTP で呼ばれたら API」を接着剤的に書きたい
• 定期実行（cron）を、サーバーを立てずにタイマーで回したい

主要概念と用語

• 関数（Function）: 実行単位のコード。1 つのトリガーと複数のバインドを持つ
• トリガー（Trigger）: 関数を起動するイベント源。HTTP、Timer、Blob、Queue Storage、Service Bus、Event Hubs、Event Grid、Cosmos DB など
• バインド（Binding）: 入出力を宣言的に接続する仕組み。コードを書かずに入力データの取得や出力先への書き込みができる（入力／出力バインド。AWS Lambda には無い Functions 固有の概念）
• Function App: 関数をまとめてデプロイ・スケールする単位（ホスティングの箱）
• ホスティングプラン: 消費（Consumption）／Flex Consumption／Premium／App Service（専用）。スケール挙動と課金が変わる
• Durable Functions: 状態を持つオーケストレーションを書くための拡張（AWS の Step Functions 相当の領域をコードで実現）
• コールドスタート: アイドル後に新しいインスタンスを起動する初回遅延

仕様・制限・クォータ

• タイムアウト: 消費プランは既定 5 分・最大 10 分。Premium / 専用プランは既定 30 分で、無制限に設定可能（長時間処理は Durable Functions での分割を推奨）
• ランタイム: .NET（分離ワーカー）、Node.js、Python、Java、PowerShell をサポート。バージョンは Functions ランタイム（v4 系）に依存
• スケール: 消費プランは Scale Controller が自動で水平スケール。HTTP 等のインスタンス上限はプランごとに異なる（消費プランは Windows で最大 200 インスタンス程度）
• メモリ: 消費プランはインスタンスあたり 1.5 GB 程度。Premium / Flex では選択したインスタンスサイズに依存
• 一時領域や同時実行はプラン・言語ワーカー数（FUNCTIONS_WORKER_PROCESS_COUNT 等）で変化する

内部の仕組み

Azure Functions は Functions ランタイムホスト が WebJobs SDK を土台に動作し、登録されたトリガーを監視して関数を起動します。スケールは Scale Controller が担当し、キューの長さや HTTP の負荷といったメトリクスを見て、インスタンス数を水平に増減します。消費プランでは負荷が無ければ 0 までスケールインし、その状態から起動するのがコールドスタートです。

• イベント源（Blob/Queue/Service Bus 等）の監視と、バインドによる入出力の接続をランタイムが肩代わりする
• 同時に多くのイベントが来れば、その分インスタンスを並列に増やして処理する

設計パターン / ベストプラクティス

• ステートレスに作り、状態は Cosmos DB / Storage / Cache for Redis へ逃がす
• 小さく・速く（依存を減らし初期化を軽くしてコールドスタートを短縮）
• 状態を持つワークフローは Durable Functions（オーケストレーター／アクティビティ／ファンアウト・ファンイン、人間の承認待ちなど）で表現
• ポイズンメッセージ対策に Queue / Service Bus のリトライと毒キュー（poison queue / dead-letter） を活用
• 秘密情報はアプリ設定に直書きせず Key Vault 参照やマネージド ID で取得する

運用・監視

• 監視は Application Insights（実行回数、失敗、所要時間、依存関係の分散トレース、ライブメトリクス）が標準
• ログ／メトリクスは Azure Monitor に集約。失敗率や実行時間でアラートを設定
• スロットリングや遅延が出たら、ダウンストリーム（DB・外部 API）の限界やプランのインスタンス上限を確認
• デプロイは zip デプロイ（run-from-package）／GitHub Actions ／ Azure DevOps。設定はアプリ設定（環境変数）で管理

コスト

ホスティングプランの選択がコストとスケール挙動を決めます。

• 消費プランは 実行回数 ＋ GB 秒（メモリ × 実行時間） で課金され、無料枠が大きくアイドル時は無料
• 一定の常時負荷や低レイテンシ要件があるなら Premium / Flex のほうが総額・体感が有利になることがある（要計測）

セキュリティ

• 資格情報を直書きせず マネージド ID で他の Azure リソースへアクセスする（AWS の IAM ロール相当）
• アプリ設定の秘密は Key Vault 参照で外出しし、鍵・接続文字列の漏洩リスクを下げる
• HTTP トリガーは **認証レベル（function / admin キー）**や **Microsoft Entra ID 認証（Easy Auth）**で保護し、必要に応じて API Management を前段に置く
• ネットワーク分離が必要なら VNET 統合 / プライベートエンドポイント（Premium / Flex）を使う

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# リソースグループとストレージアカウントを作成
az group create --name demo-rg --location japaneast
az storage account create \
  --name demofuncstg$RANDOM \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_LRS

# 消費プランの Function App を作成（Node.js 20 / Functions v4）
az functionapp create \
  --resource-group demo-rg \
  --name demo-func-app \
  --consumption-plan-location japaneast \
  --runtime node \
  --runtime-version 20 \
  --functions-version 4 \
  --storage-account demofuncstg12345

# マネージド ID を有効化（資格情報の直書きを避ける）
az functionapp identity assign \
  --resource-group demo-rg \
  --name demo-func-app

# ローカルでビルドしたプロジェクトを zip デプロイ
az functionapp deployment source config-zip \
  --resource-group demo-rg \
  --name demo-func-app \
  --src ./app.zip