Skip to content

MS_AzureFunctions

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure Functions

概要

イベント駆動のアプリケーションを処理するサービス

  • サーバレス・アーキテクチャ（.NET開発基盤部会 Wiki）
  • Azure WebJobsの後継
  • 非常駐型のプロセスをイベントによってトリガーして実行する。
    • イベント駆動の「機能」実行プラットフォーム
    • 柔軟で強力なスクリプト実行環境
    • HTTP API のエンドポイントとして公開可能
    • 様々なプログラミング言語に対応
      C#, Node.js/JavaScript, F#, Python,
      PHP, Batch, Bash（MS_Bash.md）, PowerShell
  • コールドスタートが非常に遅いと言う話は、
    ホスティング オプションで対応するのが一般的らしい。
  • Linux や Docker にも対応。

補足（コールドスタートとホスティング オプション）: 本文の
「ホスティング オプションで対応する」という一行は重要で、
プランの選択が性能特性を決める。

プラン 課金 コールドスタート VNET 統合
従量課金（Consumption） 実行回数・実行時間 あり（数秒） 不可
Flex Consumption 実行分＋常時稼働インスタンス 緩和できる（Always Ready） 可
Premium インスタンス確保 無い（事前ウォーム済み） 可
App Service プラン プランの費用 無い（常時起動なら） 可

コールドスタートは、

呼び出し → インスタンスの割り当て → ランタイム起動 → 依存関係の読み込み → 実行
           └────── ここが数秒かかる（アイドル後の初回のみ）──────┘

という構造で発生する。
アイドル状態が続くとインスタンスが解放されるため、
アクセスが疎らな API では毎回これに当たる。

対処は、

手段 内容
Premium / Flex プラン 事前ウォーム済みインスタンスを確保する（費用は増える）
定期的な ping タイマー トリガで自分を叩く（対症療法）
依存関係を減らす 起動時に読み込む DLL やパッケージを絞る
言語の選択 .NET Isolated / Node は比較的速い

対話的な API を従量課金プランで公開しない、というのが実務上の原則になる
（初回が遅い！も同種の問題）。

詳細

メリット・デメリット

メリット

  • インフラを抽象化し設計者はビジネス、開発者はコードに注力
    • データやリソースの連携部分を抽象化
    • 任意の処理が実装・実行できる
    • 業務要件に応じて自動的にスケーリング
  • 料金的/時間的なコストの低さ
    • 利用開始のコストは低く
    • 簡単に体験できる

デメリット

強いて言えばロックインされること。

補足（デメリットは「ロックイン」だけではない）: 「強いて言えば」と
あるが、実務では次の制約が効いてくる。設計段階で確認すべき点である。

制約 内容
実行時間の上限 従量課金は既定 5 分・最大 10 分。長時間処理は分割するか別基盤へ
コールドスタート 前述
状態を持てない 呼び出し間で状態が保持されない。外部ストアが必要（または Durable Functions）
ローカル デバッグとの差 ローカルでは動くが本番で動かない、が起きやすい（スケール、同時実行）
同時実行の制御が難しい 勝手にスケールするため、下流の DB を圧迫することがある
費用の予測が難しい 実行回数次第。暴走すると青天井になり得る

特に最後の 2 つは注意が要る。
「勝手にスケールする」ことは長所だが、
下流（DB や外部 API）がスケールしない場合、
Functions が並列に押し寄せて下流を落とす。
maxConcurrentCalls や host.json での同時実行数の上限設定、
あるいはキューによる平準化が要る
（クラウド アプリケーション アーキテクチャ ガイドの
「スロットル パターン」「キュー ベースの負荷平準化」）。

なお、「ロックイン」については、
バインディングを使うほど移植性が下がるという関係にある。
純粋な関数として書き、
バインディングを薄い層に留めれば移植性は保てる。

バインディングとトリガー

バインディング

トリガー

  • HTTP
    • サービスへ接続するもっとも簡単な方法
    • 簡単に作成でき、ワークフローを自動化
  • WebHook
    • 非同期処理の要求を受信するエンドポイント
    • ASP.NET の WebHook library を使えば、token 検証機能を利用可能
  • タイマー
    Cron の表現方法で記述可能

移行メモ: 原典の「バインディング」の項は見出しのみで
本文が存在しない。以下の補足で内容を補う。

補足（バインディングこそが Functions の本体）: トリガーだけが
説明されているが、バインディングは Functions の生産性を決める中核機能である。

種別 役割
トリガー 関数を起動するきっかけ（1 関数に 1 つ）
入力バインディング 起動時に外部データを引数として受け取る
出力バインディング 戻り値を外部に書き出す

例えば「Blob が置かれたら、Cosmos DB を引いて、キューに投げる」処理は、
接続コードを一切書かずに属性（または設定）だけで記述できる。

[Function("Sample")]
[QueueOutput("out-queue")]                       // 出力バインディング
public string Run(
    [BlobTrigger("in/{name}")] string content,    // トリガー
    [CosmosDBInput(...)] MyDoc doc)               // 入力バインディング
{
    return doc.Id + ":" + content.Length;
}

つまり、接続文字列の管理・リトライ・シリアライズを
ランタイムが肩代わりするのがバインディングの価値である。
前掲の「ロックイン」は、まさにこの利便性の裏返しになる。

主なトリガーには、本文の HTTP / WebHook / タイマーに加え、
Blob / Queue / Service Bus / Event Hubs / Event Grid /
Cosmos DB の変更フィード などがある
（Azureのメッセージング・サービス）。

なお、状態を持つ処理（複数関数のオーケストレーション、
長時間の待ち合わせ、人間の承認待ち）には
Durable Functions という拡張がある。
前掲の「状態を持てない」という制約への公式な答えである。

on Linux and Docker

Azure Function on Linux

  • OS は Ubuntu
  • C# は mono？（今なら Core や .NET5 だろうか？

Azure Function on Docker

  • Azure Functions runtime の Docker イメージを利用して、
  • 自分の Docker イメージを Azure Functions にデプロイできる。

補足（最新化：本文の疑問への回答）: 「今なら Core や .NET5 だろうか？」
という疑問はそのとおりで、現在 mono は使われていない。

.NET の Functions は 2 つのモデルに整理されている。

モデル 内容
インプロセス Functions ホストと同じプロセスで動く。.NET の版がホストに縛られる。サポート終了（2026 年 11 月）
分離ワーカー（Isolated） 別プロセスで動く。.NET の版を自由に選べる。現在の推奨

新規開発では分離ワーカー モデルを選ぶ。
インプロセス モデルは移行が必要になる。

また、Docker 対応については、現在は

  • Azure Functions のカスタム コンテナ（Premium / App Service プラン）、
  • Azure Container Apps 上での Functions ホスト

という選択肢があり、後者は
Functions のプログラミング モデルを保ったまま
Container Apps の基盤に載せられるため、
コンテナ前提の環境では有力である
（AzureのPaaS）。

FaaS config（MS_FaaSConfig.md）

参考

Qiita

microsoft.com

Microsoft Azure

Microsoft Docs

Azure Function on Linux and Docker

Azure Function on Linux

Azure Function on Docker

Tags: 移行, クラウド, コンテナ, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally