次の方法で共有

.NET アプリをインプロセス モデルから分離ワーカー モデルに移行する

  • [アーティクル]

重要

インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 この記事の手順に従って、アプリを分離ワーカー モデルにに移行することを強くお勧めします。

この記事では、.NET 関数アプリをインプロセス モデルから分離ワーカー モデルに安全に移行するプロセスについて説明します。 これらのモデル間の高レベルの違いについては、「実行モードの比較」を参照してください。

このガイドでは、アプリが Functions ランタイムのバージョン 4.x で実行されていることを前提としています。 そうでない場合は、ホストのバージョンをアップグレードするためのガイドに従う必要があります。

これらのホスト バージョン移行ガイドは、作業中に分離ワーカー モデルに移行するのにも役立ちます。

移行する関数アプリを特定する

次の Azure PowerShell スクリプトを使用して、現在インプロセス モデルを使用しているサブスクリプション内の関数アプリの一覧を生成します。

スクリプトは、Azure PowerShell が使用するように現在構成されているサブスクリプションを使用します。 サブスクリプションを変更するには、最初に Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' を実行し、<YOUR SUBSCRIPTION ID> を評価したいサブスクリプションの ID に置き換えます。

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

ターゲットの .NET バージョンを選択する

Functions ランタイムのバージョン 4.x では、インプロセス モデルを使用する場合、.NET 関数アプリは .NET 6 をターゲットとします。

関数アプリを移行すると、.NET のターゲット バージョンを選択できます。 C# プロジェクトを Functions バージョン 4.x でサポートされている次のいずれかのバージョンの .NET に更新できます。

.NET バージョン .NET 公式サポート ポリシー のリリースの種類 Functions プロセス モデル1、2
.NET 9 プレビュー3 分離ワーカー モデル
.NET 8 LTS (2026 年 11 月 10 日にサポート終了) 分離ワーカー モデル、
インプロセス モデル2
.NET 6 LTS (2024 年 11 月 12 日にサポート終了) 分離ワーカー モデル、
インプロセス モデル2
.NET Framework 4.8 ポリシーを参照 分離ワーカー モデル

1分離ワーカー モデルでは、.NET の長期サポート (LTS) と標準期間サポート (STS) の各バージョンと、.NET Framework がサポートされます。 インプロセス モデルでは、.NET の LTS リリースのみがサポートされます (.NET 8 で終了)。 2 つのプロセス モデル間の完全な機能の比較については、インプロセスと分離ワーカー プロセスの .NET Azure Functions の違いに関するページを参照してください。

2 インプロセス モデルのサポートは、2026 年 11 月 10 日に終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 完全なサポートを受け続けるには、分離ワーカー モデルにアプリを移行する必要があります。

3 プレビュー バージョンの使用に関するサポート、現在の制限、手順の詳細については、分離ワーカー モデルの .NET バージョンのプレビューに関するページを参照してください。

ヒント

分離ワーカー モデルでは .NET 8 にアップグレードすることをお勧めします。 これが、.NET のサポート期間が最も長い完全リリース バージョンへのクイック移行パスです。

このガイドでは、.NET 9 (プレビュー) または .NET 6 の具体的な例については説明しません。 これらのバージョンをターゲットにする必要がある場合は、.NET 8 の例を適応させることができます。

移行を準備する

まだ実行していない場合は、Azure PowerShell を使用して、現在の Azure サブスクリプションで移行する必要があるアプリの一覧を特定します。

アプリを分離ワーカー モデルに移行する前に、このガイドの内容をよく確認してください。 また、分離ワーカー モデルの機能と、2 つのモデルの違いについても理解する必要があります。

アプリケーションを移行するには、次の手順を実行します。

  1. 「ローカル プロジェクトを移行する」の手順に従って、ローカル プロジェクトを分離ワーカー モデルに移行します。
  2. プロジェクトを移行したら、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
  3. Azure の関数アプリを分離モデルに更新します。

ローカル プロジェクトを移行する

このセクションでは、ローカル プロジェクトを分離ワーカー モデルに移行するために必要なさまざまな変更の概要を説明します。 一部の手順は、.NET のターゲット バージョンに基づいて異なります。 タブを使用して、目的のバージョンに一致する手順を選択します。 以下の手順はローカル C# プロジェクトを想定しています。代わりに C# スクリプト (.csx ファイル) がアプリで使用されている場合、プロジェクト モデルに変換してから続行してください。

ヒント

LTS または STS バージョンの .NET に移行する場合は、.NET アップグレード アシスタント を使用して、次のセクションで説明する多くの変更を自動的に行うことができます。

最初に、プロジェクト ファイルを変換して、依存関係を更新します。 すると、プロジェクトのビルド エラーが表示されます。 以降の手順では、対応する変更を行ってこれらのエラーを除去します。

プロジェクト ファイル

次の例は、バージョン 4.x で .NET 6 を使用する .csproj プロジェクト ファイルです。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

次のいずれかの手順を使用して、分離ワーカー モデルで実行されるようにこの XML ファイルを更新します。

以下の手順はローカル C# プロジェクトを想定しています。代わりに C# スクリプト (.csx ファイル) がアプリで使用されている場合、プロジェクト モデルに変換してから続行してください。

.csproj XML プロジェクト ファイルには、次の変更を加える必要があります。

  1. PropertyGroup の値を設定します。TargetFramework から net8.0。

  2. PropertyGroup の値を設定します。AzureFunctionsVersion から v4。

  3. 次の OutputType 要素を PropertyGroup に追加します。

    <OutputType>Exe</OutputType>

  4. ItemGroup で。PackageReference リストで、Microsoft.NET.Sdk.Functions へのパッケージ参照を次の参照に置き換えます。

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

    Microsoft.Azure.WebJobs.* 名前空間内の他のパッケージへの参照を書き留めます。 これらのパッケージは後の手順で置き換えます。

  5. 次の新しい ItemGroup を追加します。

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

これらの変更を行うと、更新されたプロジェクトは次の例のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

プロジェクトのターゲット フレームワークを変更するには、プロジェクト コードの外部でツールチェーンの一部を変更する必要がある場合もあります。 たとえば、VS Code では、ユーザー設定またはプロジェクトの .vscode/settings.json ファイルを使用して、azureFunctions.deploySubpath 拡張機能の設定を更新することが必要な場合があります。 ビルド ステップまたは CI/CD パイプラインの一部として、フレームワーク バージョンへの依存関係があるかどうかを確認します。これはプロジェクト コードの外部に存在する可能性があります。

パッケージ参照

分離ワーカー モデルに移行する場合は、アプリケーションが参照するパッケージを変更する必要があります。

まだ更新していない場合、次に示すものの最新の安定バージョンを参照するようにプロジェクトを更新します。

アプリが使用するトリガーとバインドによっては、アプリは別のパッケージ セットを参照する必要がある場合があります。 次の表に、最も一般的に使用されるいくつかの拡張機能の置換を示します。

シナリオ パッケージ参照の変更
タイマー トリガー 追加
Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage のバインド Replace
Microsoft.Azure.WebJobs.Extensions.Storage
with
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs、
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues、
Microsoft.Azure.Functions.Worker.Extensions.Tables
BLOB のバインド 次の
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
キューのバインド 次の
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
テーブルのバインド 次の
Microsoft.Azure.WebJobs.Extensions.Tables
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB のバインド 次の
Microsoft.Azure.WebJobs.Extensions.CosmosDB
および/または
Microsoft.Azure.WebJobs.Extensions.DocumentDB
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus のバインド 次の
Microsoft.Azure.WebJobs.Extensions.ServiceBus
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs のバインド 次の
Microsoft.Azure.WebJobs.Extensions.EventHubs
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid のバインド 次の
Microsoft.Azure.WebJobs.Extensions.EventGrid
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service のバインド 次の
Microsoft.Azure.WebJobs.Extensions.SignalRService
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions 次の
Microsoft.Azure.WebJobs.Extensions.DurableTask
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(SQL ストレージ プロバイダー)		 次の
Microsoft.DurableTask.SqlServer.AzureFunctions
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Netherite ストレージ プロバイダー)		 次の
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid のバインド 次の
Microsoft.Azure.WebJobs.Extensions.SendGrid
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka のバインド 次の
Microsoft.Azure.WebJobs.Extensions.Kafka
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ のバインド 次の
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
依存関係の挿入
とスタートアップ構成		 次への参照を削除します
Microsoft.Azure.Functions.Extensions
(分離ワーカー モデルでは、この機能が既定で提供されます)

検討するべき拡張機能の全一覧については、「サポートされているバインド」を参照し、分離プロセス モデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。 対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。

ヒント

このプロセス中に拡張機能のバージョンを変更するとき、場合によっては、host.json ファイルの更新も必要になります。 使用する各拡張機能のドキュメントを必ず読んでください。 たとえば、Service Bus 拡張機能では、バージョン 4.x と 5.x の間で構造に破壊的変更があります。 詳しくは、「Azure Functions の Azure Service Bus バインド」をご覧ください。

分離ワーカー モデル アプリケーションでは Microsoft.Azure.WebJobs.* 名前空間や Microsoft.Azure.Functions.Extensions 内のどのパッケージも参照するべきではありません。 これらへの参照が何か残っている場合は、それらを削除する必要があります。

ヒント

アプリは、トリガーとバインドの一部として、またはスタンドアロンの依存関係として、Azure SDK の種類にも依存している場合があります。 この機会を利用して、これらも同様に更新する必要があります。 Functions 拡張機能の最新バージョンは、Azure SDK for .NET (ほとんどすべてのパッケージの形式は Azure.* です) の最新バージョンで動作します。

Program.cs ファイル

分離ワーカー プロセスで実行できるよう移行する場合は、Program.cs ファイルをプロジェクトに次の内容で追加する必要があります。

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

この例には、パフォーマンスを向上させ、アプリで HTTP トリガーを使用するときに使い慣れたプログラミング モデルを提供するための ASP.NET Core 統合が含まれています。 HTTP トリガーを使用しない場合は、ConfigureFunctionsWebApplication の呼び出しを ConfigureFunctionsWorkerDefaults の呼び出しに置き換えることができます。 それによって、プロジェクト ファイルから Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore への参照を削除できます。 ただし、最適なパフォーマンスを得るためには、他のトリガー タイプを持つ関数の場合でも、ASP.NET Core への FrameworkReference を保持するべきです。

Program.cs ファイルで置換されるファイルに FunctionsStartup 属性がある場合は、通常は Startup.cs ファイルです。 FunctionsStartup コードが IFunctionsHostBuilder.Services を参照する場所で、代わりに HostBuilder の .ConfigureServices() メソッド内のステートメントを Program.cs に追加できます。 Program.cs の操作については、分離ワーカー モデル ガイドの「スタートアップと構成」をご覧ください。

上記の既定の Program.cs の例には、分離ワーカー モデル用の Application Insights 統合のセットアップが含まれます。 実際の Program.cs の中で、プロジェクト内のコードから受け取るログに適用する必要があるログのフィルター処理も構成する必要があります。 分離ワーカー モデルにおいて、host.json ファイルが制御するのは、Functions ホスト ランタイムによって生成されたイベントだけです。 Program.cs でフィルター規則を構成しない場合、テレメトリのさまざまなカテゴリに対して異なるログ レベルが表示される場合があります。

HostBuilder の一部としてカスタム構成ソースを登録することはできますが、これらが適用されるのも同様にプロジェクト内のコードに対してだけであることに注意してください。 トリガーとバインドの構成はプラットフォームでも必要であり、これは、アプリケーション設定、Key Vault 参照、または App Configuration 参照機能を通して提供する必要があります。

既存の FunctionsStartup から Program.cs ファイルへすべてを移動すると、FunctionsStartup 属性と、それが適用されていたクラスを削除できます。

関数シグネチャの変更

一部の主要な種類は、インプロセス モデルと分離ワーカー モデルの間で変更されます。 これらの多くが関連している属性、パラメーター、および戻り値の型は、関数シグネチャを構成しています。 関数のそれぞれに対して、以下に変更を加える必要があります。

  • 関数属性 (関数の名前も設定します)
  • 関数がどのように ILogger/ILogger<T> を取得するか
  • トリガーとバインドの属性とパラメーター

このセクションの残りの部分では、これらの手順について説明します。

関数の属性

分離ワーカー モデルの Function 属性は FunctionName 属性に置き換えられます。 新しい属性は同じシグネチャを持ち、唯一の違いは名前にあります。 そのため、行えるのはプロジェクト全体にわたる文字列置換だけになります。

ログ記録

インプロセス モデルでは、省略可能な ILogger パラメーターを関数に含めるか、依存関係の挿入を使用して ILogger<T> を取得することができます。 アプリに既に依存関係の挿入を使用していた場合、同じメカニズムが分離ワーカー モデルでも作用します。

ただし、ILogger メソッド パラメーターに依存した関数の場合は、変更を行う必要があります。 依存関係の挿入を使用して ILogger<T> を取得することをお勧めします。 次の手順を使用して関数のログ記録メカニズムを移行します。

  1. 関数クラスで、private readonly ILogger<MyFunction> _logger; プロパティを追加して、MyFunction を関数クラスの名前に置き換えます。

  2. ILogger<T> をパラメーターとして受け取る関数クラスのコンストラクターを作成します。

    public MyFunction(ILogger<MyFunction> logger) {
    _logger = logger;
}

    先ほどのコード スニペットに含まれる MyFunction の両インスタンスを、関数クラスの名前に置き換えます。

  3. 関数コードの中のログ記録操作で、ILogger パラメーターへの参照を _logger に置き換えます。

  4. ILogger パラメーターを関数シグネチャから削除します。

詳細については、「分離ワーカー モデルでのログ記録」をご覧ください。

トリガーとバインディングの変更

前の手順でパッケージ参照を変更したとき発生したトリガーとバインディングのエラーを、これから修正します。

  1. すべての using Microsoft.Azure.WebJobs; ステートメントを削除します。

  2. using Microsoft.Azure.Functions.Worker; ステートメントを追加します。

  3. 各バインディング属性で、属性の名前をそのリファレンス ドキュメントの指定のとおりに変更します。「サポートされるバインディング」インデックスをご覧ください。 一般的に、属性名の変更は次のとおりです。

    • トリガーは、通常は同じ名前のままです。 たとえば、QueueTrigger が両モデルの属性名になります。
    • 入力バインディングは、通常は "Input" をその名前に追加する必要があります。 たとえば、CosmosDB 入力バインディング属性をインプロセス モデルで使用した場合、この属性は CosmosDBInput になります。
    • 出力バインディングは、通常は "Output" をその名前に追加する必要があります。 たとえば、Queue 出力バインディング属性をインプロセス モデルで使用した場合、この属性は QueueOutput になります。

  4. 属性パラメーターを、バインディングのリファレンス ドキュメントで指定されているように、分離ワーカー モデル バージョンが反映されるように更新します。

    たとえば、インプロセス モデルで、BLOB 出力バインディングは、Access プロパティを含む [Blob(...)] 属性で表現されます。 分離ワーカー モデルでは、BLOB 出力属性は [BlobOutput(...)] になります。 バインディングに Access プロパティは必要でなくなるため、パラメーターを削除できます。 そのため、[Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] は [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")] になります。

  5. 出力バインディングを関数パラメーター リストから取り出します。 出力バインディングがひとつだけある場合は、これを関数の戻り値の型に適用できます。 複数の出力がある場合、各出力のプロパティで新しいクラスを作成し、属性をこれらのプロパティに適用します。 詳細については、「複数の出力バインディング」を参照してください。

  6. それぞれのバインディングのリファレンス ドキュメントで、バインディング先にできる種類について参照してください。 場合によっては、種類の変更が必要になることがあります。 出力バインディングでは、インプロセス モデル バージョンで IAsyncCollector<T> を使用した場合、これを対象になる種類の配列である T[] へのバインディングに置き換えることができます。 出力バインディングを、それが表すサービスのクライアント オブジェクトに、使用可能な場合は入力バインディングのバインディングの種類として、あるいはクライアントを自分で挿入することにより、置き換えることも検討できます。

  7. 関数に IBinder パラメーターが含まれる場合は、それを除去してください。 機能を、それが表すサービスのクライアント オブジェクトに、使用可能な場合は入力バインディングのバインディングの種類として、あるいはクライアントを自分で挿入することにより、置き換えます。

  8. 関数コードを更新して、すべての新しい種類で機能するようにします。

local.settings.json ファイル

local.settings.json ファイルは、ローカルで実行している場合にのみ使用されます。 詳細については、「ローカル設定ファイル」を参照してください。

インプロセスの実行から分離ワーカー プロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。 local.settings.json ファイルに少なくとも次の要素が含まれていることを確認してください。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

'AzureWebJobsStorage'' の値は、違っている場合があります。 その値を移行処理の一部として変更する必要はありません。

host.json ファイル

host.json ファイルに変更は必要ありません。 ただし、このファイル内の Application Insights 構成がインプロセス モデル プロジェクトからのものである場合、Program.cs ファイルに追加の変更を加える必要があるかもしれません。 host.json ファイルが制御するのは、Functions ホスト ランタイムからのログだけであり、分離ワーカー モデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。

その他のコード変更

このセクションでは、移行を行う際に考慮する必要があるその他のコード変更に焦点を当てます。 これらの変更はすべてのアプリケーションで必要なわけではありませんが、何かが自分のシナリオに関連するかどうかを評価する必要があります。

JSON シリアル化

既定では、分離ワーカー モデルは JSON シリアル化に System.Text.Json を使用します。 シリアライザー オプションをカスタマイズしたり、JSON.NET (Newtonsoft.Json) に切り替えたりするには、こちらの手順を参照してください。

Application Insights のログ レベルとフィルター処理

ログは、Functions ホスト ランタイムとプロジェクト内のコードの両方から Application Insights に送信できます。 host.json では、ホスト ログの規則を構成できますが、コードからのログを制御するには、Program.cs の一部としてフィルター規則を構成する必要があります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。

関数移行の例

HTTP トリガーの例

インプロセス モデルの HTTP トリガーは次の例のようになります。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

移行後のバージョンの HTTP トリガーは次の例のようになります。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Azure で関数アプリを更新する

関数アプリを分離モデルに更新するには、2 つの変更を同時に完了する必要があります。これは、1 つだけを完了すると、アプリはエラー状態になるためです。 これらの変更により、アプリ プロセスが再起動されます。 これらの理由から、ステージング スロットを使用して更新を実行する必要があります。 ステージング スロットを使用すると、アプリのダウンタイムを最小限に抑え、Azure の更新された構成を使用して移行されたコードをテストおよび確認できるようになります。 その後、スワップ操作を通じて、完全に移行したアプリを運用スロットにデプロイできます。

重要

アプリのデプロイされたペイロードが構成済みのランタイムと一致しない場合、アプリはエラー状態になります。 移行プロセス中に、アプリをこの状態にします (理想的には一時的に限定します)。 デプロイ スロットを使用すると、変更が 1 つの更新として運用環境に適用される前に、ステージング (非運用) 環境でエラー状態が解決されるため、この影響を軽減できます。 また、スロットであらゆるミスを防ぎ、運用環境に到達する前に他の問題を検出できます。

プロセス中に、ステージング (非運用) スロットからのログにエラーが表示される場合があります。 これは想定内のことですが、手順を進めるとこれらは解消されます。 スロット スワップ操作を実行する前に、これらのエラーが発生しなくなったこと、アプリケーションが期待どおりに機能していることを確認する必要があります。

以下の手順に従って、デプロイ スロットを使用し、関数アプリを分離ワーカー モデルに更新します。

  1. まだの場合はデプロイ スロットを作成します。 また、スロット スワップ プロセスを理解し、中断を最小限に抑えて既存のアプリケーションを更新できるようにすることもできます。

  2. FUNCTIONS_WORKER_RUNTIME アプリケーション設定を dotnet-isolated に設定して、分離ワーカー モデルを使用するようにステージング (非運用) スロットの構成を変更します。 FUNCTIONS_WORKER_RUNTIME は "スロット設定" としてマークしないでください。

    更新の一部として別のバージョンの .NET も対象にしている場合は、スタック構成も変更する必要があります。 これを行うには、分離ワーカー モデルのスタック構成を更新する手順に関する記事を参照してください。 今後、.NET バージョンの更新を行う際にも同じ手順を実行します。

    CI/CD パイプラインなどの自動化されたインフラストラクチャ プロビジョニングがある場合は、FUNCTIONS_WORKER_RUNTIME を dotnet-isolated に設定したままにし、正しい .NET バージョンを対象とするように自動化も更新されていることを確認します。

  3. 移行したプロジェクトを関数アプリのステージング (非運用) スロットに発行します。

    Visual Studio を使用して、インプロセス モデルを使用する既存のアプリまたはスロットに分離ワーカー モデル プロジェクトを発行する場合、前の手順を同時に完了することもできます。 前の手順を完了していない場合、Visual Studio では、デプロイ時に関数アプリを更新するように求められます。 Visual Studio では、これは 1 つの操作として表示されますが、それでも 2 つの独立した操作です。 中間状態でも、ステージング (非運用) スロットからのログにエラーが表示される場合があります。

  4. アプリケーションがステージング (非運用) スロット内で期待どおりに機能していることを確認します。

  5. スロット スワップ操作を実行します。 これにより、ステージング (非運用) スロットで行った変更が運用スロットに適用されます。 スロット スワップは 1 回の更新として行われるため、運用環境での一時的なエラー状態が発生することを回避できます。

  6. アプリケーションが運用スロット内で期待どおりに機能していることを確認します。

これらの手順を完了すると、移行が完了し、アプリは分離モデル上で動作します。 お疲れさまでした。 移行が必要な他のアプリについては、必要に応じてこのガイドの手順を繰り返します。

次のステップ

分離ワーカー モデルに関する詳細情報