はじめに

2028年9月30日以降、Azure FunctionsのConsumption（従量課金）プランでLinuxの関数アプリを実行する機能は廃止されます。

Azure Functionsとは？ Azure Functionsは、サーバーの管理や設定を気にせずに、コードを実行できるMicrosoftのクラウドサービスです。特定のイベント（HTTPリクエスト、タイマー、データベースの変更など）が発生したときに自動的にコードが実行されます。

Function のスケールとホスティングオプション | Microsoft Learn

なぜ廃止されるのか？ Microsoftは、より高性能で柔軟な新しいプラン（Flex Consumption）を提供するため、古いプランのサポートを段階的に終了します。
新しいプランは、従来のプランの課題（仮想ネットワーク非対応、コールドスタートの遅さなど）を解決しています。

よって、今後新規で作成するFunctionsのプランは**Flex Consumption（Flex従量課金）**にする方が好ましいです。

本記事では、Flex Consumption プランとConsumptionプランの違い、移行時の変更点について紹介します。

Flex Consumptionとは

Flex Consumption プランは2024 年 11 月 に GA（一般提供）となった従来のCunsumptionプランの進化版的なプランで、より柔軟に利用することができるAzure Functionsの新しいプランです。

Azure Functions Flex Consumption プラン ホスティング | Microsoft Learn

Flex Consumption と Consumption プランからの変更点

主要機能の比較表

機能 Consumption Flex Consumption
ゼロスケール ✅ 可能 ✅ 可能
スケール動作 イベント駆動 イベント駆動（高速）
仮想ネットワーク ❌ 非対応 ✅ 対応
専用コンピュート（コールドスタート対策） ❌ なし ✅ 常時起動インスタンス（任意）
課金 実行時間のみ 実行時間 + 常時起動インスタンス
最大スケールアウトインスタンス数 200 1000

用語解説:

  • ゼロスケール: アクセスがないときは完全に停止（インスタンス数0）してコストを削減できる機能
  • イベント駆動: HTTPリクエストやタイマーなどのイベントが発生したときに自動的に関数が実行される仕組み
  • 専用コンピュート: 常に起動しているサーバーインスタンスのこと。コールドスタートを避けたい場合に有効（有料）
  • スケールアウトインスタンス数: 最大何台のサーバーまで自動増加できるか。Flex Consumptionは1000台まで対応するため、大規模なアクセス増加にも対応可能

Function のスケールとホスティングオプション

仮想ネットワーク統合

Flex Consumption プランでは、仮想ネットワーク統合が可能です。
今までは仮想ネットワークを使おうとするPremiumプランなどリクエストに応じた従量課金ではない高額なプランを利用する必要があったのですが、 Flex Consumptionプラン 仮想ネットワーク内で保護された他のAzureサービスと接続しながら、サーバーレスの課金とスケーリングの利点を活用できます。

具体的なメリット:

  • Azure SQL DatabaseやCosmos DBなどをインターネット非公開の設定で利用できる（セキュリティ強化）
  • 社内ネットワークとVPN接続している環境でも利用可能
  • 従来は専用プラン（Premium Plan等）でしか実現できなかった構成が、従量課金プランでも可能に

仮想ネットワーク統合の有効化

インスタンスサイズ

Flex Consumption プランで関数アプリを作成する際、実行インスタンスのメモリサイズを選択できます。
メモリサイズはコストに影響します。

インスタンスとは？ インスタンスは、関数を実行するための「仮想的なコンピューター1台」と考えてください。アクセスが増えるとインスタンスが自動的に増え、減るとインスタンスも減ります。

選択可能なインスタンスサイズ

メモリ（MB） CPUコア数
512 0.25
2048 1
4096 2

注意: CPUコア数は典型的な割り当てであり、初期インスタンスでは性能向上のために異なる場合があります。

メモリサイズ選択のポイント

  • 2048MB がデフォルトで、ほとんどのシナリオに適しています
  • 512MB や 4096MB は、同時実行数や処理能力に応じて選択します
  • メモリサイズはいつでも変更可能です
  • インスタンスのリソースは関数コードと Functions ホストで共有されます
  • メモリサイズが大きいほど、同時実行や高負荷処理に強くなります
  • HTTPトリガーの同時実行数はメモリサイズに依存します
  • CPUやネットワーク帯域はインスタンスサイズに比例して提供されます

関数単位のスケーリング

Flex Consumption プランでは、関数ごとにスケーリングが行われ、トリガータイプに応じてより予測可能なスケーリングが可能です。

従来との違い:

  • 従来（Consumption）: アプリ全体で1つのスケーリング設定。1つの関数が忙しくなると、他の関数も一緒にスケールアウトされ、無駄なコストが発生することがありました。
  • Flex Consumption: 各関数が独立してスケール。HTTPリクエスト処理だけ忙しい場合は、その関数だけがスケールアウトし、コスト効率が向上します。

スケールグループの一覧

スケールグループ トリガー 設定値
HTTPトリガー HTTP, SignalR http
Blobストレージトリガー（Event Grid） Blob blob
Durable Functions オーケストレーション, アクティビティ, エンティティ durable

その他の関数は function:<関数名> という形式で個別にスケーリングされます。

Always Ready (常時起動)インスタンス

Flex Consumption では、関数やスケールグループごとにAlways Ready (常時起動)インスタンスを設定できます。 これにより、コールドスタートの遅延を軽減できます。

コールドスタートとは？ 関数が使われていない状態から起動する際に発生する、初回リクエストの遅延のこと。例えば、夜間にアクセスがなく、朝の最初のアクセスで数秒待たされるような現象です。 詳しくはこちらの記事をご参照ください。

Always Readyインスタンスの仕組み:

  • 設定した数のインスタンスが常に起動しているため、即座にリクエストを処理できます
  • デフォルトは 0（ゼロ）で、必要に応じて設定します
  • 常時起動インスタンスは追加料金が発生しますが、レスポンス速度を重視する場合に有効です

設定例

HTTPグループに対して常時起動インスタンスを2に設定すると、常に2つのインスタンスが起動してリクエストを処理します。
必要に応じて追加インスタンスがスケールアウトされます。

具体例:

  • 常時起動インスタンス: 2台（Always Ready）
  • アクセスが急増すると、3台目、4台目…と自動的にインスタンスが追加される
  • アクセスが減ると、追加されたインスタンスは削除されるが、常に2台は起動したまま

注意: ゾーン冗長性（複数のデータセンターに分散配置してサービスの可用性を高める機能）が有効な場合、最低2インスタンスが必要です。

常時起動インスタンス数の設定

同時実行（Concurrency）

同時実行とは、1インスタンスで並列に実行される関数の数です。
最大同時実行数を設定することで、スケーリングの挙動に影響を与えます。
低い同時実行数では、より多くのインスタンスが必要になります。

具体例で理解する:

  • 同時実行数を10に設定した場合: 1つのインスタンスで最大10件のリクエストを同時処理
  • 11件目のリクエストが来た場合: 新しいインスタンスが起動して処理
  • 同時実行数を1に設定した場合: リクエスト1件ごとに1インスタンスが必要（並列処理なし）

設定のポイント:

  • 高い同時実行数: 少ないインスタンスで多くのリクエストを処理（コスト削減）。ただし、1つのインスタンスに負荷が集中
  • 低い同時実行数: 多くのインスタンスが起動（コスト増）。ただし、各インスタンスの負荷は軽い

設定オプション

  • HTTPトリガーの同時実行数設定：Set HTTP concurrency limits
  • 非HTTPトリガーの同時実行数設定：Target Base Scaling

Storage Accountの変更点

Storage Accountとは？ Azure上のクラウドストレージサービスです。Azure Functionsは、アプリケーションコード（ZIPファイル）や実行に必要な設定情報をStorage Accountに保存します。

1. アプリデプロイ用のコンテナ名が変更

コンテナ名は app-package-${Functionsのリソース名} の形式で、以下のファイルが格納されます：

kudu-state.json          # デプロイ状態を管理するファイル
released-package.zip     # アプリケーションコード（ZIPファイル）

Kuduとは？ Azure App ServiceやAzure Functionsのデプロイを管理する内部サービスです。開発者が直接触ることは少ないですが、裏側でアプリのデプロイやログ管理を行っています。

重要: コンテナがない場合は以下のエラーが発生します：

[StorageAccessibleCheck]
Error while checking access to storage account using Kudu.Legion.Core.Storage.BlobContainerStorage:
   BlobUploadFailedException:
       Failed to upload blob to storage account:
           The specified container does not exist.

対処法: Storage Account内に、app-package-{関数アプリ名} という名前のBlobコンテナを事前に作成してください。

2. DEPLOYMENT_STORAGE_CONNECTION_STRINGを環境変数に設定する必要がある

AzureWebJobsStorageと同様に、Blobの接続文字列を設定する必要があります。

設定例:

DEPLOYMENT_STORAGE_CONNECTION_STRING=DefaultEndpointsProtocol=https;AccountName=mystorageaccount;AccountKey=...

この設定により、Azure FunctionsがStorage Accountにアクセスしてアプリケーションコードを取得できるようになります。

デプロイ時の変更点

デプロイとは？ 作成したアプリケーションコードをAzure上にアップロードして実行可能な状態にすることです。

1. FUNCTIONS_WORKER_RUNTIME の設定が不要

Bicep（Azureのインフラをコードで管理するツール）でデプロイする際に、FUNCTIONS_WORKER_RUNTIMEの設定は不要です。

従来は、使用するプログラミング言語（Python、Node.jsなど）を明示的に設定する必要がありましたが、Flex Consumptionでは自動検出されます。

2. linuxFxVersion へのランタイムバージョン設定が不要

環境変数のlinuxFxVersionにPythonのランタイムバージョンを設定していると、以下のエラーが発生します：

The following site configuration property (Site.SiteConfig.LinuxFxVersion) for Flex Consumption sites is invalid.
Please remove or rename it before retrying. (CODE: 400)

GitHub Actionsとは？ GitHub上でコードを自動的にビルド・テスト・デプロイできるCI/CDツールです。コードをプッシュすると自動的にAzureにデプロイすることが可能です。

GitHub Actionsでアプリケーション設定する場合の修正例：

- name: Setting app setting
  uses: azure/appservice-settings@v1
  with:
    app-name: func-hogehoge-001
    mask-inputs: false
    # この箇所を削除（Flex Consumptionでは不要）
    # general-settings-json: '{"linuxFxVersion": "PYTHON|${{ env.PYTHON_VERSION }}"}'

3. GitHub Actionsでのデプロイ設定

Flex Consumptionプランにデプロイする際、GitHub Actionsのfunctions-actionには以下のパラメーターを設定する必要があります。

必須パラメーター

パラメーター 説明 推奨値
sku プランの種類を指定 flexconsumption
remote-build Kuduからのビルドアクションを有効化するか false

重要:

  • sku: publish-profile を使用して認証する場合のみ flexconsumption に設定。RBAC 資格情報を使用する場合は、skuパラメーターを含める必要はない。
  • remote-buildをtrueに設定すると、パッケージがFlex従量課金アプリにデプロイされる前にKuduからのビルドが実行されます
  • Oryxビルドはリモートビルド中に常に実行されるため、scm-do-build-during-deploymentやenable-oryx-buildは設定しないでください

GitHub Actions設定例

- name: 'Deploy Azure Function App'
  uses: Azure/functions-action@v1
  with:
    app-name: ${{ env.APP_NAME }}
    slot-name: production
    package: ${{ env.BUILD_ZIP_FILE_NAME }}
    sku: flexconsumption
    remote-build: false
    scm-do-build-during-deployment: false
    enable-oryx-build: false  # バイナリデプロイのためOryxビルドを無効化

設定のポイント:

  • publish-profile認証の場合: sku: flexconsumptionを明示的に設定
  • RBAC資格情報認証の場合: アクションが自動的にSKU値を解決するため、skuパラメーターは省略可能
  • バイナリデプロイ: ローカルまたはCI/CDパイプラインでビルド済みのパッケージをデプロイする場合、Oryxビルドは不要

Oryxとは？ Microsoftが開発したビルドシステムで、アプリケーションの言語やフレームワークを自動検出してビルドします。Azure App ServiceやAzure Functionsで使用されています。

4. デプロイ時のZIPファイル自動削除

従量課金プランでは、デプロイ時にZIPファイルがストレージアカウントに残り続ける問題がありましたが、Flex従量課金プランでは自動削除されるようになりました。

メリット:

  • ストレージの容量を圧迫しない
  • 古いデプロイファイルの手動削除が不要
  • ストレージコストの削減

5. スロットスワップが非対応

Flex Consumption プランでは、スロットスワップは非対応です。

スロットスワップとは？ 本番環境とステージング環境を瞬時に入れ替える機能。新しいバージョンをステージング環境でテストしてから、本番環境と切り替えることで、ダウンタイムなしのデプロイが可能になります。

代替案:

  • Blue-Green デプロイメント: 2つの関数アプリを用意して、トラフィックを切り替える
  • カナリアリリース: Azure Front DoorやTraffic Managerを使って段階的に新バージョンへ移行

コスト比較

注意: Flex ConsumptionプランはConsumptionプランよりも無料枠の回数が少なく、実行単価も高いため、コストは増加することになります。

項目 従来のConsumptionプラン Flex Consumptionプラン
無料枠(On Demand) 400,000 GB秒 / 100万回 100,000 GB秒 / 25万回
実行時間単価(On Demand) $0.000016 / GB秒 $0.000026 / GB秒
実行回数単価(On Demand) $0.20 / 100万回 $0.40 / 100万回
実行時間単価(Always Ready) - $0.000004〜$0.000016 / GB秒
実行回数単価(Always Ready) - $0.40 / 100万回

GB秒とは？ メモリ使用量（GB）× 実行時間（秒）で計算される単位。例えば、2GBのメモリで10秒間実行すると、20GB秒になります。

Azure Functions pricing

まとめ

Flex Consumption プランは、従来のConsumption プランの後継として、以下の点で優れています。

  • 仮想ネットワーク統合により、セキュアな環境でサーバーレス機能を実行可能
  • 常時起動インスタンスにより、コールドスタートを軽減
  • 関数単位のスケーリングにより、より効率的なリソース配分が可能
  • 最大1000インスタンスまで対応し、大規模なワークロードに対応

2028年9月30日のConsumptionプラン廃止に備えて、新規プロジェクトではFlex Consumptionプランの採用を検討することをお勧めします。