Skip to content

MS_AzureFunctions

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 2 revisions

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

参考

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