Azure Functions ランタイム バージョンの概要

現在、Azure Functions では、次の 3 つのバージョンのランタイム ホスト (3.x、2.x、および 1.x) がサポートされています。 3 つのすべてのバージョンは、運用環境シナリオでサポートされています。

重要

バージョン 1.x はメンテナンス モードであり、Azure portal、Azure Stack Hub ポータル、または Windows コンピューター上のローカルでの開発のみをサポートします。 拡張機能は、それ以降のバージョンでのみ提供されます。

この記事では、各種のバージョン間のいくつかの相違点、各バージョンを作成する方法、およびバージョンの変更方法について詳細に説明します。

Languages

バージョン 2.x から、ランタイムでは言語拡張モデルが使用されており、関数アプリ内のすべての関数が同じ言語を共有する必要があります。 関数アプリ内の関数の言語はそのアプリの作成時に選択され、FUNCTIONS_WORKER_RUNTIME 設定に保持されます。

次の表は、各ランタイム バージョンでどのプログラミング言語が現在サポートされているかを示しています。

Language 1.x 2.x 3.x
C# GA (.NET Framework 4.7) GA (.NET Core 2.21) GA (.NET Core 3.1)
プレビュー (.NET 5.0)
JavaScript GA (Node 6) GA (Node 10、8) GA (Node 14、12、10)
F# GA (.NET Framework 4.7) GA (.NET Core 2.21) GA (.NET Core 3.1)
Java 該当なし GA (Java 8) GA (Java 11、8)
PowerShell 該当なし GA (PowerShell Core 6) GA (PowerShell 7、Core 6)
Python 該当なし GA (Python 3.7、3.6) GA (Python 3.8、3.7、3.6)
プレビュー (Python 3.9)
TypeScript 該当なし GA2 GA2

1 ランタイム バージョン 2.x を対象とする .NET クラス ライブラリのアプリは、.NET Core 3.1 の .NET Core 2.x 互換モードで実行できるようになりました。 詳細については、「Functions v2.x の考慮事項」を参照してください。
2 JavaScript へのトランスパイリングによってサポートされます。

サポートされている言語バージョンの詳細については、言語固有の開発者ガイドに関する記事をご覧ください。
言語サポートの計画的な変更については、「Azure ロードマップ」を参照してください。

特定のバージョンで実行する

既定では、Azure portal と Azure CLI で作成された関数アプリはバージョン 3.x に設定されます。 このバージョンは必要に応じて変更できます。 ランタイムのバージョンを 1.x にダウングレードできるのは、関数アプリを作成してから関数を追加するまでの間のみです。 2.x と 3.x の間の移行は、既存の関数が含まれているアプリでも許可されます。 既存の関数が含まれているアプリを 2.x から 3.x に移行する前に、2. x と 3.x の間の破壊的変更に注意してください。

ランタイムのメジャー バージョンを変更する前に、まず、最新のメジャー バージョンで実行されている別の関数アプリにデプロイして、既存のコードをテストする必要があります。 このテストは、アップグレード後に適切に実行されることを確認するのに役立ちます。

v3.x から v2.x へのダウングレードはサポートされていません。 可能であれば、常に、サポートされている最新バージョンの Functions ランタイムでアプリを実行してください。

Azure でのアプリのバージョンの変更

Azure の公開アプリから使用される Functions ランタイムのバージョンは、FUNCTIONS_EXTENSION_VERSION アプリケーションの設定によって決まります。 次のランタイムのメジャー バージョン値がサポートされています。

ランタイム ターゲット
~3 3.x
~2 2.x
~1 1.x

重要

他のアプリ設定の変更や関数のコード変更が必要になる可能性があるため、この設定を独断で変更しないでください。

詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」を参照してください。

特定のマイナー バージョンに固定する

最新のメジャー バージョンで実行されている関数アプリの問題を解決するには、アプリを特定のマイナー バージョンに固定する必要があります。 これにより、最新のメジャー バージョンでアプリが正しく実行されるようになります。 マイナー バージョンに固定する方法は、Windows と Linux で異なります。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」を参照してください。

古いマイナー バージョンは、定期的に Functions から削除されます。 特定の古いマイナー バージョンの削除などの、Azure Functions リリースに関する最新のニュースについては、Azure App Service のお知らせを観察してください。

バージョン ~2.0 に固定する

バージョン 2.x (~2) で実行されている .NET 関数アプリは、.Net Core 3 の長期サポート バージョンである .Net Core 3.1 で実行されるように、自動的にアップグレードされます。 .Net Core 3.1 で .NET 関数を実行すると、最新のセキュリティ更新プログラムと製品の機能強化を利用できます。

~2.0 に固定されている関数アプリは、引き続き .Net Core 2.2 で実行され、セキュリティやその他の更新プログラムを受信しなくなります。 詳細については、Functions v2. x に関する考慮事項に関するページを参照してください。

2.x から 3.x への移行

Azure Functions バージョン 3.x は、バージョン 2.x との下位互換性が高くなっています。 多くのアプリは、コードを変更することなく、3.x に安全にアップグレードできるはずです。 3.x への移行が推奨されますが、運用アプリでメジャー バージョンを変更する前に、広範囲なテストを必ず実行してください。

2.x と 3.x の間の破壊的変更

2.x アプリを 3.x にアップグレードする前に次の変更点にご留意ください。

JavaScript

  • context.done 経由で割り当てられた出力バインディングまたは戻り値が context.bindings の設定と同じ動作をするようになりました。

  • タイマー トリガー オブジェクトはパスカル ケースではなくキャメル ケースです。

  • dataType バイナリが指定された、イベント ハブにトリガーされる関数の場合、string ではなく、binary の配列を受け取ります。

  • HTTP 要求ペイロードには context.bindingData.req 経由でアクセスできなくなりました。 引き続き入力パラメーター context.req としてアクセスできるほか、context.bindings でアクセスできます。

  • Node.js 8 のサポートが終了し、3.x 関数では実行されません。

.NET Core

.NET クラス ライブラリ関数を実行する場合のバージョン間の主な違いは、.NET Core ランタイムです。 Functions バージョン 2.x は .NET Core 2.2 で実行されるように設計されており、バージョン 3.x は .NET Core 3.1 で実行されるように設計されています。

注意

.NET Core 2.2 のサポートに関する問題のため、バージョン 2 (~2) に固定された関数アプリは、基本的には .Net core 3.1 で実行されています。 詳細については、Functions v2.x 互換性モードに関するページを参照してください。

1.x からそれ以降のバージョンへの移行

最新のバージョンではなくバージョン 1.x のランタイムを使用するように記述された既存のアプリを移行することができます。 必要な変更の大部分は、.NET Framework 4.7 と .NET Core 間の C# API の変更など、言語ランタイムの変更に関連する変更です。 また、コードとライブラリが、選択した言語ランタイムと互換性があることを確認する必要があります。 最後に、以下で示すトリガー、バインド、および機能での変更にも注意してください。 最適な移行結果を得るために、新しいバージョンで新しい関数アプリを作成し、既存のバージョン 1.x の関数コードを新しいアプリに移植してください。

アプリ構成を手動で更新することで "インプレース" アップグレードすることが可能ですが、1.x から上位のバージョンへの移行には、いくつかの破壊的変更が含まれます。 たとえば、C# では、デバッグ オブジェクトが TraceWriter から ILogger に変更されています。 最新のバージョン 3.x のテンプレートに基づいて新しいバージョン 3.x プロジェクトを作成することで、更新された関数から始めます。

バージョン 1.x 後のトリガーとバインドの変更

バージョン 2.x 以降では、アプリの関数で使用される特定のトリガーとバインドの拡張機能をインストールする必要があります。 この例外は、拡張機能を必要としない HTTP トリガーとタイマー トリガーのみです。 詳細については、バインド拡張機能の登録とインストールに関するページを参照してください。

バージョン間には、関数の function.json や属性の変更もいくつかあります。 たとえば、イベント ハブの path のプロパティは eventHubName になりました。 各バインドのドキュメントへのリンクについては、既存のバインド一覧を参照してください。

バージョン 1.x 後の機能の変更

バージョン 1.x 後、いくつかの機能が削除、更新、置換されました。 このセクションでは、バージョン 1.x の後に後続のバージョンを使用した場合に気づく変更点について詳しく説明します。

バージョン 2.x では次の点が変更されました。

  • HTTP エンドポイントを呼び出すキーは、Azure Blob Storage 内で常に暗号化されて格納されます。 バージョン 1.x では、既定で Azure File Storage にキーが格納されていました。 アプリをバージョン 1.x からバージョン 2.x にアップグレードすると、ファイル ストレージ内の既存のシークレットはリセットされます。

  • バージョン 2.x ランタイムには、Webhook プロバイダーの組み込みサポートは含まれていません。 この変更はパフォーマンスを向上するために行われました。 Webhook のエンドポイントとして HTTP トリガーを使用することもできます。

  • ホスト構成ファイル (host.json) は空か、文字列 "version": "2.0" が含まれる必要があります。

  • 監視を改善するために、AzureWebJobsDashboard 設定を使用したポータルの WebJobs ダッシュボードは、APPINSIGHTS_INSTRUMENTATIONKEY 設定を使用する Azure Application Insights に置き換えられています。 詳しくは、「Azure Functions を監視する」をご覧ください。

  • 関数アプリ内のすべての関数は、同じ言語を共有する必要があります。 関数アプリを作成するときに、そのアプリのランタイム スタックを選択する必要があります。 ランタイム スタックは、アプリケーション設定の FUNCTIONS_WORKER_RUNTIME 値によって指定されます。 メモリ占有領域と起動時間を改善するために、この要件が追加されました。 ローカルで開発する場合は、この設定も local.settings.json ファイル に含める必要があります。

  • App Service プランでの関数に対する既定のタイムアウトは 30 分に変更されます。 host.json の functionTimeout 設定を使用して、手動でタイムアウトを無制限に変更することができます。

  • 従量課金プラン機能の場合、HTTP 同時実行のスロットルは既定で実装され、インスタンスあたりの既定の同時要求数は 100 です。 これは host.json ファイルの maxConcurrentRequests 設定で変更できます。

  • .NET Core の制限があるため、F# スクリプト (.fsx) 関数のサポートが削除されました。 コンパイル済みの F# 関数 (.fs) は引き続きサポートされます。

  • Event Grid トリガー Webhook の URL 形式は https://{app}/runtime/webhooks/{triggerName} に変更されました。

ローカルで開発されたアプリケーションのバージョン

関数アプリを次のように更新し、ターゲット バージョンをローカルで変更できます。

Visual Studio のランタイム バージョン

Visual Studio では、プロジェクトを作成するときにランタイムのバージョンを選択します。 Visual Studio 用の Azure Functions ツールは、ランタイムのメジャー バージョン 3 つをサポートしています。 デバッグ時と公開時には、プロジェクトの設定に基づいて正しいバージョンが使用されます。 バージョン設定は、.csproj ファイルの次のプロパティで定義されています。

バージョン 3.x
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

注意

Azure Functions 3.x と .NET では、Microsoft.NET.Sdk.Functions 拡張機能を 3.0.0 以上にする必要があります。

バージョン 2.x
<TargetFramework>netcoreapp2.1</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
バージョン 1.x
<TargetFramework>net472</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
Visual Studio で 2.x アプリを 3.x に更新する

2.x をターゲットにする既存の関数を開き、.csproj ファイルを編集し、上記の値を更新することで 3.x に移行できます。 Visual Studio では、プロジェクト メタデータに基づき、ランタイム バージョンがユーザーに代わって自動的に管理されます。 ただし、お使いのコンピューターでその Visual Studio で 3.x 用のテンプレートとランタイムが設定される前に 3.x アプリを作成していない場合にのみ可能です。 "プロジェクトで指定されたバージョンと一致する、利用可能な Functions ランタイムはありません" のようなエラーが表示されることがあります。 最新のテンプレートとランタイムを取得するには、新しい関数プロジェクトを作成する操作を進めます。 バージョンとテンプレートの選択画面に進んだら、Visual Studio で最新テンプレートの取得が完了するまで待ちます。 最新の .NET Core 3 テンプレートが利用できるようになり、表示されたら、バージョン 3.x 用に構成されているプロジェクトの実行とデバッグができます。

重要

バージョン 3.x 関数は、Visual Studio バージョン 16.4 以降を使用している場合にのみ、Visual Studio で開発できます。

VS Code と Azure Functions Core Tools

Azure Functions Core Tools は、コマンドラインの開発に使用されます。また、Visual Studio Code 用の Azure Functions 拡張機能からも使用されます。 バージョン 3.x に対して開発するには、Core Tools のバージョン 3.x をインストールします。 バージョン 2.x の開発には Core Tools のバージョン 2.x が必要です。他のバージョンも同様です。 詳細については、「Azure Functions Core Tools のインストール」を参照してください。

Visual Studio Code の開発の場合は、必要に応じてインストールされているツールのバージョンと一致するように azureFunctions.projectRuntime のユーザー設定を更新します。 この設定で、関数アプリの作成時に使用されるテンプレートと言語も更新されます。 ~3 でアプリを作成するには、azureFunctions.projectRuntime ユーザー設定を ~3 に更新します。

Azure Functions 拡張機能ランタイム設定

Maven および Java アプリ

ローカル実行に必要なコア ツールの 3.x バージョンをインストールすることで、Java アプリを 2.x から 3.x に移行できます。 バージョン 3.x でアプリが正しくローカル実行されることを確認したら、アプリの POM.xml ファイルを更新し、次の例のように、FUNCTIONS_EXTENSION_VERSION 設定を ~3 に変更します。

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

バインド

バージョン 2.x から、ランタイムでは、次の利点を提供する新しいバインド拡張モデルが使用されています。

  • サード パーティのバインド拡張のサポート。

  • ランタイムとバインドの分離。 この変更により、バインド拡張を個別にバージョン管理したり、解放したりできます。 たとえば、基になる SDK の新しいバージョンに依存する拡張のバージョンにアップグレードするよう選択できます。

  • より軽量な実行環境。ここでは、使用中のバインドのみがランタイムによって識別され、読み込まれます。

HTTP とタイマーのトリガーを除き、すべてのバインドを関数アプリ プロジェクトに明示的に追加するか、ポータルで登録する必要があります。 詳細については、「バインディング拡張機能を登録する」を参照してください。

各ランタイム バージョンでサポートされるバインドを次の表に示します。

この表は、Azure Functions のメジャー バージョンのランタイムでサポートされているバインディングを示しています。

種類 1.x 2.x 以降1 トリガー 入力 Output
Blob Storage
Azure Cosmos DB
Dapr3
Event Grid
Event Hubs
HTTP と Webhook
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 バージョン 2.x ランタイム以降では、HTTP と Timer を除くすべてのバインドを登録する必要があります。 「バインディング拡張機能を登録する」を参照してください。

2 トリガーは従量課金プランでサポートされていません。 ランタイム駆動のトリガーが必要です。

3 Kubernetes、IoT Edge、およびその他の自己ホスト型モードでのみサポートされます。

Function App タイムアウト期間

関数アプリのタイムアウト期間は、host.json プロジェクト ファイルの functionTimeout プロパティによって定義されます。 次の表は、両方のプランと各種ランタイム バージョンでの既定と最大値 (分単位) を示します。

プラン ランタイム バージョン Default 最大値
従量課金 1.x 5 10
従量課金 2.x 5 10
従量課金 3.x 5 10
Premium 1.x 無制限 無制限
Premium 2.x 30 無制限
Premium 3.x 30 無制限
App Service 1.x 無制限 無制限
App Service 2.x 30 無制限
App Service 3.x 30 無制限

注意

関数アプリのタイムアウト設定に関係なく 230 秒は、HTTP トリガー関数が要求に応答できる最大時間です。 これは、Azure Load Balancer の既定のアイドル タイムアウトによるものです。 より長い処理時間では、Durable Functions async pattern の使用を検討するか、実際の作業を遅らせて、即座に応答を返します

次のステップ

詳細については、次のリソースを参照してください。