다음을 통해 공유

C# 앱을 In-Process 모델에서 격리된 작업자 모델로 마이그레이션

중요

In-process 모델에 대한 지원은 2026년 11월 10일에 종료됩니다. 이 문서의 지침에 따라 앱을 격리된 작업자 모델로 마이그레이션하는 것이 좋습니다.

이 문서에서는 .NET 함수 앱을 In-Process 모델에서 격리된 작업자 모델로 안전하게 마이그레이션하는 프로세스를 안내합니다. 이러한 모델 간의 개략적인 차이점에 대해 알아보려면 실행 모드 비교를 참조하세요.

이 가이드에서는 앱이 Functions 런타임 버전 4.x에서 실행되고 있다고 가정합니다. 그렇지 않은 경우 다음 가이드를 사용하여 호스트 버전을 업그레이드해야 합니다. 이러한 호스트 버전 마이그레이션 가이드를 통해 작업할 때 격리된 작업자 모델로 마이그레이션하는 데도 도움이 됩니다.

지원되는 경우 이 문서에서는 격리된 작업자 모델의 ASP.NET Core 통합 을 활용하여 성능을 향상시키고 앱에서 HTTP 트리거를 사용할 때 친숙한 프로그래밍 모델을 제공합니다.

마이그레이션할 함수 앱 식별

다음 Azure PowerShell 스크립트를 사용하여 현재 In Process 모델을 사용하는 구독에서 함수 앱 목록을 생성합니다.

스크립트는 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 함수 앱은 In-process 모델을 사용할 때 .NET 6 또는 .NET 8을 대상으로 합니다.

함수 앱을 마이그레이션할 때 .NET의 대상 버전을 선택할 수 있습니다. Functions 버전 4.x에서 지원되는 다음 버전의 .NET 중 하나로 C# 프로젝트를 업데이트할 수 있습니다.

.NET 버전 .NET 공식 지원 정책 릴리스 유형 함수 프로세스 모델1,2
.NET 9 STS(2026년 5월 12일 지원 종료) 격리된 작업자 모델
.NET 8 LTS(2026년 11월 10일 지원 종료) 격리된 작업자 모델,
In Process 모델2
.NET Framework 4.8 정책 참조 격리된 작업자 모델

1격리된 작업자 모델은 .NET Framework뿐만 아니라 LTS(장기 지원) 및 STS(표준 기간 지원) 버전의 .NET을 지원합니다. in-process 모델 .NET 8로 끝나는 .NET의 LTS 릴리스만 지원합니다. 두 모델 간의 전체 기능 및 성능을 비교하려면 In Process 및 Isolate Worker 프로세스 .NET Azure Functions의 차이점을 참조하세요.

2 In Process 모델에 대한 지원은 2026년 11월 10일에 종료됩니다. 자세한 내용은 이 지원 공지를 참조하세요. 계속해서 완전한 지원을 받으려면 앱을 격리된 작업자 모델로 마이그레이션해야 합니다.

팁

격리된 작업자 모델에서 .NET 8로 업그레이드하는 것이 좋습니다. 이는 .NET에서 가장 긴 지원 기간을 갖춘 정식 릴리스 버전으로의 빠른 마이그레이션 경로를 제공합니다.

이 가이드에서는 .NET 9에 대한 구체적인 예제를 제시하지 않습니다. 이러한 버전을 대상으로 지정해야 하는 경우 .NET 8 예를 적용할 수 있습니다.

마이그레이션 준비

앱을 격리된 작업자 모델로 마이그레이션하기 전에 이 가이드의 내용을 철저히 검토해야 합니다. 또한 격리된 작업자 모델의 기능과 두 모델 간의 차이점을 숙지해야 합니다.

애플리케이션을 마이그레이션하려면 다음을 수행합니다.

  1. 로컬 프로젝트 마이그레이션 단계에 따라 로컬 프로젝트를 격리된 작업자 모델로 마이그레이션합니다.
  2. 프로젝트를 마이그레이션한 후 Azure Functions Core Tools 버전 4.x를 사용하여 앱을 로컬로 완전히 테스트합니다.
  3. Azure의 함수 앱을 업데이트하여 격리된 모델로 만듭니다.

로컬 프로젝트 마이그레이션

이 섹션에서는 격리된 작업자 모델로 이동하기 위해 로컬 프로젝트에 대해 수행해야 하는 다양한 변경 내용을 간략하게 설명합니다. 일부 단계는 .NET의 대상 버전에 따라 변경됩니다. 탭을 사용하여 원하는 버전과 일치하는 지침을 선택합니다.

팁

.NET의 LTS 또는 STS 버전으로 이동하는 경우 .NET 업그레이드 도우미 를 사용하여 다음 섹션에서 언급한 많은 변경 내용을 자동으로 수행할 수 있습니다.

먼저 프로젝트 파일을 변환하고 종속성을 업데이트합니다. 작업을 수행하는 동안 프로젝트에 대한 빌드 오류가 표시됩니다. 이후 단계에서는 해당 변경 내용을 적용하여 이러한 오류를 제거합니다.

프로젝트 파일

다음 예제는 버전 4.x에서 .NET 8을 사용하는 . csproj 프로젝트 파일입니다.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.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
스토리지 바인딩 Replace
Microsoft.Azure.WebJobs.Extensions.Storage
다음과 같이 바꿉니다.
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
이벤트 그리드 바인딩 참조를 다음으로 바꾸기
Microsoft.Azure.WebJobs.Extensions.EventGrid
최신 버전의
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR 서비스 바인딩 참조를 다음으로 바꾸기
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 확장은 최신 버전의 .NET용 Azure SDK에서 작동하며, 거의 모든 패키지는 형식 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에 대한 참조를 제거할 수 있습니다. 그러나 최상의 성능을 위해서는 다른 트리거 형식을 사용하는 함수의 경우에도 FrameworkReference를 ASP.NET Core로 유지해야 합니다.

Program.cs 파일은 일반적으로 Startup.cs 파일 FunctionsStartup 인 특성이 있는 모든 파일을 대체합니다. FunctionsStartup 코드가 IFunctionsHostBuilder.Services을 참조하는 위치에서는 Program.cs의 HostBuilder 메서드 내에 .ConfigureServices() 문을 추가할 수 있습니다. Program.cs 작업에 대한 자세한 내용은 격리된 작업자 모델 가이드의 시작 및 구성을 참조하세요.

앞에서 설명한 기본 Program.cs 예제에는 Application Insights 설정이 포함됩니다. Program.cs 프로젝트의 코드에서 들어오는 로그에도 적용할 로그 필터링을 구성해야 합니다. 격리된 작업자 모델에서 host.json 파일은 Functions 호스트 런타임에서 내보낸 이벤트만 제어합니다. Program.cs 필터링 규칙을 구성하지 않으면 원격 분석의 다양한 범주에 대한 로그 수준의 차이가 표시될 수 있습니다.

사용자 지정 구성 원본을 일부로 HostBuilder등록할 수 있지만 마찬가지로 프로젝트의 코드에만 적용됩니다. 또한 플랫폼에는 트리거 및 바인딩 구성이 필요하며 애플리케이션 설정, Key Vault 참조 또는 App Configuration 참조 기능을 통해 제공해야 합니다.

모든 항목을 기존 FunctionsStartup 파일에서 Program.cs 파일로 이동한 후 적용된 FunctionsStartup 특성과 클래스를 삭제할 수 있습니다.

함수 시그니처 변경

일부 주요 유형은 In Process 모델과 격리된 작업자 모델 간에 변경됩니다. 이들 중 대부분은 함수 시그리처를 구성하는 특성, 매개 변수 및 반환 형식과 관련이 있습니다. 각 함수에 대해 다음을 변경해야 합니다.

  • 함수의 이름도 설정하는 함수 특성입니다.
  • 함수가 ILogger/ILogger<T>를 가져오는 방법
  • 트리거 및 바인딩 특성과 매개 변수

이 섹션의 나머지 부분에서는 이러한 각 단계를 안내합니다.

함수 특성

격리된 작업자 모델의 Function 특성은 FunctionName 특성으로 대체됩니다. 새 특성의 서명은 동일하며 이름에만 차이가 있습니다. 따라서 프로젝트 전체에서 문자열 바꾸기만 수행할 수 있습니다.

로깅

In-process 모델에서는 함수에 선택적인 ILogger 매개변수를 포함할 수 있으며, 종속성 주입을 사용하여 ILogger<T>를 가져올 수도 있습니다. 앱이 종속성 주입을 이미 사용 중인 경우 격리된 작업자 모델에서도 동일한 메커니즘이 작동합니다.

그러나 ILogger 메서드 매개 변수를 사용하는 Functions의 경우 변경해야 합니다. 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 . 예를 들어 In-Process 모델에서 CosmosDB 입력 바인딩 특성을 사용한 경우 특성은 이제 CosmosDBInput이 됩니다.
    • 출력 바인딩은 일반적으로 해당 이름에 추가해야 합니다 Output . 예를 들어 In-Process 모델에서 Queue 출력 바인딩 특성을 사용한 경우 이 특성은 이제 QueueOutput이 됩니다.

  4. 바인딩의 참조 설명서에 지정된 대로 격리된 작업자 모델 버전을 반영하도록 특성 매개 변수를 업데이트합니다.

    예를 들어 In-Process 모델에서 Blob 출력 바인딩은 [Blob(...)] 속성을 포함하는 Access 특성으로 표시됩니다. 격리된 작업자 모델에서 Blob 출력 특성은 [BlobOutput(...)]입니다. 바인딩에는 더 이상 Access 속성이 필요하지 않으므로 해당 매개 변수를 제거할 수 있습니다. 그러면 [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")]은 [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]이 됩니다.

  5. 함수 매개변수 목록에서 출력 바인딩을 이동합니다. 출력 바인딩이 하나뿐인 경우 함수의 반환 형식에 적용할 수 있습니다. 여러 출력이 있는 경우 각 출력에 대한 속성을 사용하여 새 클래스를 만들고 해당 속성에 특성을 적용합니다. 자세히 알아보려면 여러 출력 바인딩을 참조하세요.

  6. 바인딩할 수 있는 형식은 각 바인딩의 참조 설명서를 참조하세요. 경우에 따라 형식을 변경해야 할 수도 있습니다. 출력 바인딩의 경우 In-Process 모델 버전에서 IAsyncCollector<T>를 사용하는 경우 이를 대상 형식 T[]의 배열에 대한 바인딩으로 바꿀 수 있습니다. 가능한 경우 입력 바인딩에 대한 바인딩 유형으로 또는 클라이언트를 직접 삽입하여 출력 바인딩을 나타내는 서비스에 대한 클라이언트 개체로 바꾸는 것을 고려할 수도 있습니다.

  7. 함수에 IBinder 매개 변수가 포함된 경우 제거합니다. 사용 가능한 경우 입력 바인딩에 대한 바인딩 형식으로 또는 직접 클라이언트를 삽입하여 나타내는 서비스에 대한 클라이언트 개체로 기능을 바꿉니다.

  8. 새 형식으로 작동하도록 함수 코드를 업데이트합니다.

local.settings.json 파일

local.settings.json 파일은 로컬로 실행할 때만 사용됩니다. 자세한 내용은 로컬 설정 파일을 참조하세요.

In-Process 실행에서 격리된 작업자 프로세스로 마이그레이션하는 경우, FUNCTIONS_WORKER_RUNTIME 값을 dotnet-isolated로 변경해야 합니다. local.settings.json 파일에 적어도 다음 요소가 있는지 확인합니다.

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

AzureWebJobsStorage에 대한 가치가 여러분에게는 다를 수 있습니다. 마이그레이션의 일부로 값을 변경할 필요가 없습니다.

host.json 파일

host.json 파일을 변경할 필요가 없습니다. 그러나 In-process 모델 프로젝트에서 Application Insights 구성이 이 파일에 있는 경우 Program.cs 파일을 추가로 변경할 수 있습니다. host.json 파일은 Functions 호스트 런타임의 로깅만 제어하며, 격리된 작업자 모델에서 이러한 로그 중 일부는 애플리케이션에서 직접 제공되므로 더 많은 제어를 제공합니다. 이러한 로그를 필터링하는 방법에 대한 자세한 내용은 격리된 작업자 모델에서 로그 수준 관리를 참조하세요.

기타 코드 변경

이 섹션에서는 마이그레이션을 진행하면서 고려해야 할 기타 코드 변경 내용을 강조 표시합니다. 이러한 변경 내용은 모든 애플리케이션에서 필요하지 않지만 시나리오와 관련된 변경 내용이 있는지 평가해야 합니다.

JSON 직렬화

기본적으로 격리된 작업자 모델은 JSON serialization에 System.Text.Json 을 사용합니다. serializer 옵션을 사용자 지정하거나 JSON.NET(Newtonsoft.Json)로 전환하려면 JSON serialization 사용자 지정을 참조하세요.

Application Insights 로그 수준 및 필터링

프로젝트의 Functions 호스트 런타임과 코드 모두에서 로그를 Application Insights로 보낼 수 있습니다. host.json 호스트 로깅에 대한 규칙을 구성할 수 있지만 코드에서 들어오는 로그를 제어하려면 Program.cs 일부로 필터링 규칙을 구성해야 합니다. 이러한 로그를 필터링하는 방법에 대한 자세한 내용은 격리된 작업자 모델에서 로그 수준 관리를 참조하세요.

예제 함수 마이그레이션

HTTP 트리거 예제

In-Process 모델에 대한 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에서 함수 앱 업데이트

함수 앱을 격리된 모델로 업데이트하는 경우 하나만 완료하면 앱에 오류가 발생하므로 두 가지 변경 내용을 함께 완료해야 합니다. 이러한 두 가지 변경 내용으로 인해 앱 프로세스가 다시 시작됩니다. 이러한 이유로 스테이징 슬롯을 사용하여 업데이트를 수행해야 합니다. 스테이징 슬롯을 사용하면 앱의 가동 중지 시간을 최소화하고 Azure에서 업데이트된 구성으로 마이그레이션된 코드를 테스트하고 확인할 수 있습니다. 그런 다음 교환 작업을 통해 완전히 마이그레이션된 앱을 프로덕션 슬롯에 배포할 수 있습니다.

중요한

앱의 배포된 페이로드가 구성된 런타임과 일치하지 않으면 오류 상태입니다. 마이그레이션 프로세스 중에는 일시적으로만 앱을 이 상태로 전환합니다. 배포 슬롯은 변경 내용이 프로덕션 환경에 단일 업데이트로 적용되기 전에 스테이징(비프로덕션) 환경에서 오류 상태가 해결되기 때문에 이러한 영향을 완화하는 데 도움이 됩니다. 슬롯은 또한 모든 실수를 방어하고 프로덕션에 도달하기 전에 다른 문제를 감지 할 수 있습니다.

프로세스 중에 스테이징(비프로덕션) 슬롯에서 오는 로그에 오류가 계속 표시될 수 있습니다. 이는 예상되는 상황이지만 단계를 진행함에 따라 사라져야 합니다. 슬롯 전환 작업을 수행하기 전에 이러한 오류가 더 이상 발생하지 않고 애플리케이션이 예상대로 작동하는지 확인해야 합니다.

배포 슬롯을 사용하여 함수 앱을 격리된 작업자 모델로 업데이트하려면 다음 단계를 사용합니다.

  1. 아직 배포 슬롯이 없다면 배포 슬롯을 만듭니다. 또한 슬롯 교환 프로세스를 숙지하고 최소한의 중단으로 기존 애플리케이션을 업데이트할 수 있는지 확인하고 싶을 수 있습니다.

  2. 애플리케이션 설정을 으로 설정하여 격리된 작업자 모델을 사용하도록 스테이징(비프로덕션) 슬롯의 구성을 FUNCTIONS_WORKER_RUNTIMEdotnet-isolated변경합니다. FUNCTIONS_WORKER_RUNTIME은 슬롯 설정으로 표시되지 않아야 합니다.

    또한 업데이트의 일부로 다른 버전의 .NET을 대상으로 하는 경우 스택 구성도 변경해야 합니다. 이렇게 하려면 스택 구성 업데이트를 참조하세요. 이후의 .NET 버전 업데이트에 대해 동일한 지침을 사용할 수 있습니다.

    CI/CD 파이프라인과 같은 자동화된 인프라 프로비저닝이 있는 경우 FUNCTIONS_WORKER_RUNTIME을 dotnet-isolated로 설정하고 올바른 .NET 버전을 대상으로 하도록 자동화 또한 업데이트해야 합니다.

  3. 마이그레이션된 프로젝트를 함수 앱의 스테이징(비프로덕션) 슬롯에 게시합니다.

    Visual Studio를 사용하여 프로세스 내 모델을 사용하는 기존 앱 또는 슬롯에 격리된 작업자 모델 프로젝트를 게시하는 경우 이전 단계를 동시에 완료할 수도 있습니다. 이전 단계를 완료하지 않은 경우 Visual Studio는 배포 중에 함수 앱을 업데이트하라는 메시지를 표시합니다. Visual Studio는 이를 단일 작업으로 제공하지만 이는 여전히 두 개의 별도 작업입니다. 중간 상태 동안 스테이징(비프로덕션) 슬롯의 로그에 오류가 계속 표시될 수 있습니다.

  4. 애플리케이션이 스테이징(비프로덕션) 슬롯 내에서 예상대로 작동하는지 확인합니다.

  5. 슬롯 교환 작업을 수행하여 스테이징(비프로덕션) 슬롯에서 변경한 내용을 프로덕션 슬롯에 적용합니다. 슬롯 교환은 단일 업데이트로 발생하므로 프로덕션 환경에서 임시 오류 상태가 발생하지 않습니다.

  6. 애플리케이션이 프로덕션 슬롯 내에서 예상대로 작동하는지 확인합니다.

이러한 단계를 완료하면 마이그레이션이 완료되고 앱이 격리된 모델에서 실행됩니다. 축하합니다! 마이그레이션이 필요한 다른 앱에 대해 필요에 따라 이 가이드의 단계를 반복합니다.

다음 단계

격리된 작업자 모델에 대해 자세히 알아보기