다음을 통해 공유


Azure Functions의 동시성

이 문서에서는 Azure Functions 이벤트 기반 트리거의 동시성 동작에 대해 설명합니다. 또한 정적 및 동적 동시성 모델을 비교합니다.

Important

Flex 사용 계획은 현재 미리 보기로 제공됩니다.

Functions에서는 지정된 함수의 여러 실행 프로세스가 단일 컴퓨팅 인스턴스에서 동시에 실행될 수 있습니다. 예를 들어 함수 앱에서 증가된 부하를 처리하기 위해 여러 인스턴스로 확장되는 세 가지 함수가 있는 경우를 고려해 보세요. 이 시나리오에서 각 함수는 세 인스턴스 모두에서 개별 호출에 대한 응답으로 실행되고 지정된 인스턴스는 동일한 형식의 여러 호출을 처리할 수 있습니다. 단일 인스턴스에서의 함수 실행은 동일한 메모리, CPU 및 연결 리소스를 공유합니다. 여러 함수 실행이 각 인스턴스에서 동시에 실행될 수 있으므로 각 함수에는 동시 실행 수를 관리할 수 있는 방법이 있어야 합니다.

앱이 동적 크기 조정 계획(사용량 또는 Flex 사용 또는 프리미엄)에서 호스트되는 경우 호스트는 들어오는 이벤트 수에 따라 함수 앱 인스턴스 수를 스케일 업 또는 다운합니다. 자세한 내용은 이벤트 기반 크기 조정을 참조하세요. 전용(App Service) 계획에서 함수를 호스트하는 경우 인스턴스를 수동으로 구성하거나 자동 크기 조정 체계를 설정해야 합니다.

또한 이러한 크기 조정 결정은 지정된 인스턴스에서 실행의 동시성에 의해 직접적인 영향을 받습니다. 동적 크기 조정 계획의 앱이 동시성 제한에 도달하면 들어오는 수요를 따라잡기 위해 크기 조정해야 할 수 있습니다.

함수는 동시성을 관리하는 두 가지 주요 방법을 제공합니다.

  • 정적 동시성: 개별 트리거와 관련된 동시성에 대한 호스트 수준 제한을 구성할 수 있습니다. 이는 Functions의 기본 동시성 동작입니다.

  • 동적 동시성: 특정 트리거 유형의 경우 Functions 호스트는 앱에서 해당 트리거에 대한 최고 수준의 동시성을 자동으로 결정할 수 있습니다. 이 동시성 모델을 옵트인해야 합니다.

정적 동시성

기본적으로 대부분의 트리거는 호스트 수준 정적 구성 모델을 지원합니다. 이 모델에서 각 트리거 유형에는 인스턴스당 동시성 제한이 있습니다. 그러나 대부분의 트리거의 경우 해당 트리거 유형에 대해 인스턴스별 특정 동시성을 요청할 수도 있습니다. 예를 들어 Service Bus 트리거host.json 파일MaxConcurrentCallsMaxConcurrentSessions 설정을 모두 제공합니다. 이러한 설정은 각 함수가 각 인스턴스에서 동시에 처리하는 최대 메시지 수를 제어합니다. 다른 트리거 형식에는 인스턴스 간에 호출 부하를 분산하기 위한 기본 제공 메커니즘이 있습니다. 예를 들어 Event Hubs와 Azure Cosmos DB는 모두 파티션 기반 체계를 사용합니다.

동시성 구성을 지원하는 트리거 형식의 경우 선택한 설정이 실행 중인 모든 인스턴스에 적용됩니다. 이를 통해 각 인스턴스의 함수에 대한 최대 동시성을 제어할 수 있습니다. 예를 들어 함수가 CPU 또는 리소스를 많이 사용하는 경우 동시성을 제한하여 인스턴스를 정상 상태로 유지하고 크기 조정을 통해 증가된 부하를 처리하도록 선택할 수 있습니다. 마찬가지로, 함수가 제한 중인 다운스트림 서비스에 대한 요청을 수행할 때 다운스트림 서비스를 오버로드하지 않도록 동시성을 제한하는 것도 고려해야 합니다.

HTTP 트리거 동시성

Flex 사용 계획(미리 보기)에만 적용

Flex 사용 계획은 모든 HTTP 트리거 함수를 그룹으로 함께 크기 조정합니다. 자세한 내용은 함수별 크기 조정을 참조하세요. 다음 표에서는 구성된 인스턴스 메모리 크기를 기반으로 지정된 인스턴스의 HTTP 트리거에 대한 기본 동시성 설정을 나타냅니다.

인스턴스 크기(MB) 기본 동시성*
2048 16
4096 32

*Python 앱의 경우 모든 인스턴스 크기에 대한 기본 HTTP 트리거 동시성은 1입니다.

이러한 기본값은 대부분의 경우 잘 작동해야 하며, 이러한 기본값으로 시작합니다. 지정된 수의 HTTP 요청에서 HTTP 동시성 값을 늘리면 HTTP 요청을 처리하는 데 필요한 인스턴스 수가 줄어듭니다. 마찬가지로 HTTP 동시성 값을 줄이면 동일한 부하를 처리하기 위해 더 많은 인스턴스가 필요합니다.

HTTP 동시성을 미세 조정해야 하는 경우 Azure CLI를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 HTTP 동시성 제한 설정을 참조하세요.

이전 표의 기본 동시성 값은 사용자 고유의 HTTP 동시성 설정을 설정하지 않은 경우에만 적용됩니다. HTTP 동시성 설정을 명시적으로 설정하지 않은 경우 인스턴스 크기를 변경하면 표에 표시된 대로 기본 동시성이 증가합니다. HTTP 동시성 값을 구체적으로 설정한 후에는 인스턴스 크기가 변경되더라도 해당 값이 유지됩니다.

최적의 정적 동시성 확인

정적 동시성 구성을 사용하면 함수 제한과 같은 특정 트리거 동작을 제어할 수 있지만 이러한 설정에 대한 최적 값을 결정하기는 어려울 수 있습니다. 일반적으로 반복적인 부하 테스트 프로세스를 통해 허용 가능한 값에 도달해야 합니다. 특정 부하 프로필에 대해 적합한 값 세트를 결정하는 후에도 연결된 서비스에서 들어오는 이벤트 수가 매일 변경될 수 있습니다. 이러한 가변성은 종종 앱이 최적이 아닌 값으로 실행될 수 있음을 의미합니다. 예를 들어 함수 앱은 한 주의 마지막 요일에 특히 까다로운 메시지 페이로드를 처리할 수 있으므로 동시성을 제한해야 합니다. 그러나 나머지 요일에는 메시지 페이로드가 더 간단합니다. 즉, 나머지 요일에 더 높은 동시성 수준을 사용할 수 있습니다.

시스템이 각 인스턴스를 정상 상태로 유지하고 대기 시간을 낮게 유지하면서 가능한 한 많은 작업을 처리하는 것이 이상적인데, 동적 동시성이 바로 그렇게 설계되어 있습니다.

동적 동시성

이제 Functions는 동일한 계획에서 실행되는 모든 함수 앱에 대한 동시성 구성을 간소화하는 동적 동시성 모델을 제공합니다.

참고 항목

동적 동시성은 현재 Azure Blob, Azure Queue 및 Service Bus 트리거에 대해서만 지원되며 이를 사용하려면 아래 확장 지원 섹션에 나열된 버전을 사용해야 합니다.

이점

동적 동시성을 사용하면 다음과 같은 이점이 있습니다.

  • 간소화된 구성: 더 이상 트리거별 동시성 설정을 수동으로 결정할 필요가 없습니다. 시스템은 시간이 지남에 따라 워크로드에 대한 최적 값을 학습합니다.
  • 동적 조정: 동시성이 실시간으로 동적으로 상향 또는 하향 조정되므로 시스템이 시간에 따라 변화하는 부하 패턴에 적응할 수 있습니다.
  • 인스턴스 상태 보호: 런타임은 함수 앱 인스턴스가 편안하게 처리할 수 있는 수준으로 동시성을 제한합니다. 이렇게 하면 앱이 필요 이상으로 많은 작업을 수행하여 오버로드되는 것을 방지할 수 있습니다.
  • 처리량 향상: 개별 인스턴스가 신속하게 처리할 수 있는 것보다 더 많은 작업을 끌어오지 않기 때문에 전반적인 처리량이 향상됩니다. 따라서 인스턴스 간에 작업 부하를 보다 효과적으로 분산할 수 있습니다. 더 높은 부하를 처리할 수 있는 함수의 경우 기본 구성보다 높은 값으로 동시성을 높이면 더 높은 처리량을 얻을 수 있습니다.

동적 동시성 구성

host.json 파일의 호스트 수준에서 동적 동시성을 사용하도록 설정할 수 있습니다. 사용하도록 설정하면 이 기능을 지원하는 모든 바인딩 확장의 동시성 수준이 필요에 따라 자동으로 조정됩니다. 이러한 경우 동적 동시성 설정은 수동으로 구성된 동시성 설정을 재정의합니다.

기본적으로 동적 동시성은 사용하지 않도록 설정됩니다. 동적 동시성을 사용하도록 설정하면 각 함수에 대해 동시성이 1부터 시작되고 호스트에서 결정한 최적 값까지 조정됩니다.

host.json 파일에 다음 설정을 추가하여 함수 앱에서 동적 동시성을 사용하도록 설정할 수 있습니다.

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    } 

SnapshotPersistenceEnabledtrue(기본값)인 경우 학습된 동시성 값이 주기적으로 스토리지에 유지되므로 새 인스턴스가 1부터 시작하여 학습을 다시 실행하지 않고 해당 값에서 시작합니다.

동시성 관리자

백그라운드에서 동적 동시성을 사용하도록 설정하면 백그라운드에서 동시성 관리자 프로세스가 실행됩니다. 이 관리자는 CPU 및 스레드 사용률과 같은 인스턴스 상태 메트릭을 지속적으로 모니터링하고 필요에 따라 제한을 변경합니다. 하나 이상의 제한을 사용하도록 설정하면 호스트가 다시 정상 상태가 될 때까지 함수 동시성이 하향 조정됩니다. 제한을 사용하지 않도록 설정하면 동시성이 증가할 수 있습니다. 필요할 경우 이러한 제한에 따라 필요에 따라 동시성을 위아래로 지능적으로 조정하는 데 다양한 추론이 사용됩니다. 시간이 지남에 따라 각 함수에 대한 동시성이 특정 수준으로 안정화됩니다.

동시성 수준은 각 개별 함수별로 관리됩니다. 따라서 시스템은 낮은 수준의 동시성이 필요한 리소스 집약적 함수와 더 높은 동시성을 처리할 수 있는 더 간단한 함수 간에 균형을 유지합니다. 각 함수에 대한 동시성 균형은 함수 앱 인스턴스의 전반적인 상태를 유지하는 데 도움이 됩니다.

동적 동시성을 사용하도록 설정하면 로그에 동적 동시성 결정이 표시됩니다. 예를 들어 다양한 제한이 사용하도록 설정되고 각 함수의 동시성이 상향 또는 하향 조정될 때마다 로그가 표시됩니다. 이러한 로그는 추적 테이블의 Host.Concurrency 로그 범주 아래에 기록됩니다.

확장 지원

동적 동시성은 호스트 수준에서 함수 앱에 대해 사용하도록 설정되며 동적 동시성을 지원하는 모든 확장은 해당 모드에서 실행됩니다. 동적 동시성을 사용하려면 호스트와 개별 트리거 확장 간의 협업이 필요합니다. 다음 확장의 나열된 버전만 동적 동시성을 지원합니다.

내선 번호 버전 설명
Queue Storage 버전 5.x(스토리지 확장) Azure Queue Storage 트리거에는 자체 메시지 폴링 루프가 있습니다. 정적 구성을 사용하는 경우 BatchSize/NewBatchThreshold 구성 옵션에 의해 동시성이 제어됩니다. 동적 동시성을 사용하는 경우 해당 구성 값은 무시됩니다. 동적 동시성은 메시지 루프에 통합되므로 반복당 페치되는 메시지 수가 동적으로 조정됩니다. 제한을 사용하도록 설정하면(호스트가 오버로드됨) 제한이 사용하지 않도록 설정될 때까지 메시지 처리가 일시 중지됩니다. 제한을 사용하지 않도록 설정하면 동시성이 증가합니다.
Blob Storage 버전 5.x(스토리지 확장) 내부적으로 Azure Blob Storage 트리거는 Azure Queue Trigger에서 사용하는 것과 동일한 인프라를 사용합니다. 새/업데이트된 Blob을 처리해야 하는 경우 메시지는 플랫폼 관리형 제어 큐에 기록되고 해당 큐는 QueueTrigger에 사용되는 것과 동일한 논리를 사용하여 처리됩니다. 동적 동시성을 사용하도록 설정하면 해당 제어 큐의 처리를 위한 동시성이 동적으로 관리됩니다.
Service Bus 버전 5.x Service Bus 트리거는 현재 세 가지 실행 모델을 지원합니다. 동적 동시성은 다음과 같이 이러한 실행 모델에 영향을 줍니다.

단일 디스패치 토픽/큐 처리: 함수의 각 호출이 단일 메시지를 처리합니다. 정적 구성을 사용하는 경우 MaxConcurrentCalls 구성 옵션에 의해 동시성이 제어됩니다. 동적 동시성을 사용하는 경우 해당 구성 값이 무시되고 동시성이 동적으로 조정됩니다.
세션 기반 단일 디스패치 토픽/큐 처리: 함수의 각 호출이 단일 메시지를 처리합니다. 토픽/큐의 활성 세션 수에 따라 각 인스턴스가 하나 이상의 세션을 임대합니다. 각 세션의 메시지는 세션의 순서를 보장하기 위해 순차적으로 처리됩니다. 동적 동시성을 사용하지 않는 경우 동시성은 MaxConcurrentSessions 설정에 따라 제어됩니다. 동적 동시성을 사용하도록 설정하면 MaxConcurrentSessions가 무시되고 각 인스턴스가 처리하는 세션 수가 동적으로 조정됩니다.
일괄 처리: 함수의 각 호출이 MaxMessageCount 설정에 따라 관리되는 메시지의 일괄 처리를 진행합니다. 일괄 처리 호출은 직렬이므로 일괄 처리 트리거 함수에 대한 동시성은 항상 1이며 동적 동시성은 적용되지 않습니다.

다음 단계

자세한 내용은 다음 리소스를 참조하세요.