Azure Functions의 동시성

Azure Functions에서 단일 함수 앱 인스턴스를 사용하면 여러 이벤트를 동시에 처리할 수 있습니다. 동일한 컴퓨팅 인스턴스에서 실행되므로 메모리, CPU 및 연결 리소스를 공유합니다. 특정 호스팅 계획에서 특정 인스턴스에 대한 높은 수요로 인해 Functions 호스트는 증가된 부하를 처리하는 새 인스턴스를 자동으로 만듭니다. 이러한 동적 확장 계획에서는 동시성과 크기 조정 동작 간에 장단점이 있습니다. 앱 실행 방법을 보다 자세히 제어하기 위해 Functions는 동시 실행 수를 관리하는 방법을 제공합니다.

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

• 인스턴스별 동시성 수정: 개별 트리거와 관련된 동시성에 대한 호스트 수준 제한을 구성할 수 있습니다. 이 모델은 Functions의 기본 동시성 동작입니다.
• 동적 동시성: 특정 트리거 형식의 경우 Functions 호스트는 함수 앱에서 해당 트리거에 대한 최고 수준의 동시성을 자동으로 결정할 수 있습니다. 이 동시성 모델을 옵트인해야 합니다.

이 문서에서는 Functions에서 이벤트 기반 트리거의 동시성 동작과 이러한 동작이 동적 계획의 크기 조정에 미치는 영향에 대해 설명합니다. 또한 고정 인스턴스당 및 동적 동시성 모델을 비교합니다.

확장과 동시성

이벤트 기반 트리거를 사용하거나 HTTP 요청에 응답하는 함수의 경우 수요가 많은 기간 동안 동시 실행 제한에 빠르게 도달할 수 있습니다. 이러한 기간 동안 들어오는 요청을 처리하는 백로그를 방지하기 위해 인스턴스를 추가하여 함수 앱의 크기를 조정할 수 있어야 합니다. 앱 크기를 조정하는 방법은 호스팅 계획에 따라 달라집니다.

크기 조정이 발생하기 전에 함수 앱은 단일 인스턴스에서 동일한 형식의 여러 호출을 처리하여 부하 증가를 처리하려고 시도합니다. 따라서 지정된 인스턴스에서 이러한 동시 실행은 크기 조정 결정에 직접적인 영향을 줍니다. 예를 들어 동적 확장 계획의 앱이 동시성 제한에 도달하면 들어오는 수요를 따라잡기 위해 확장해야 할 수 있습니다.

앱에서 달성하려는 규모와 동시성의 균형은 처리(CPU 집약적 프로세스 제한) 또는 다운스트림 서비스(I/O 기반 제한 사항)에서 병목 현상이 발생할 수 있는 위치에 따라 달라집니다.

인스턴스당 동시성이 수정됨

기본적으로 대부분의 트리거는 대상 기반 크기 조정을 통해 고정 인스턴스당 동시성 구성 모델을 지원합니다. 이 모델에서 각 트리거 유형에는 인스턴스당 동시성 제한이 있습니다.

해당 트리거 형식에 대한 인스턴스별 특정 동시성을 설정하여 대부분의 트리거에 대한 동시성 기본값을 재정의할 수 있습니다. 많은 트리거의 경우 host.json 파일에서 동시성 설정을 구성합니다. 예를 들어 Azure Service Bus 트리거는 MaxConcurrentCalls 및 MaxConcurrentSessions 설정을 host.json에서 모두 제공합니다. 이러한 설정은 각 함수 앱이 각 인스턴스에서 동시에 처리하는 최대 메시지 수를 제어하기 위해 함께 작동합니다.

Apache Kafka 또는 Azure Cosmos DB 트리거를 사용하는 경우와 같은 특정 대상 기반 크기 조정 시나리오에서는 동시성 구성이 host.json 파일이 아닌 함수 선언에 있습니다. 다른 트리거 형식에는 인스턴스 간 부하 분산 호출을 위한 기본 제공 메커니즘이 있습니다. 예를 들어 Azure Event Hubs와 Azure Cosmos DB는 모두 파티션 기반 스키마를 사용합니다.

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

HTTP 트리거 동시성

Flex Consumption 플랜에만 적용됩니다.

HTTP 트리거 동시성은 특수한 유형의 고정 인스턴스별 동시성입니다. HTTP 트리거 동시성에서 기본 동시성은 인스턴스 크기에 따라 달라집니다.

Flex 사용 계획은 모든 HTTP 트리거 함수를 그룹으로 함께 크기 조정합니다. 자세한 내용은 함수별 크기 조정을 참조하세요.

다음 표에서는 구성된 인스턴스 메모리 크기에 따라 지정된 인스턴스의 HTTP 트리거에 대한 기본 동시성 설정을 나타냅니다.

^*Python 앱에서 모든 인스턴스 크기는 기본적으로 하나의 HTTP 트리거 동시성 수준을 사용합니다.

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

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

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

최적의 고정된 인스턴스별 동시성 확인

인스턴스당 동시성 구성이 수정되어 함수 제한 등 특정 트리거 동작을 제어할 수 있습니다. 그러나 이러한 설정에 대한 최적 값을 결정하기는 어려울 수 있습니다. 일반적으로 반복적인 부하 테스트 프로세스를 통해 허용 가능한 값에 도달해야 합니다. 특정 부하 프로필에 대해 작동하는 값 집합을 확인한 후에도 연결된 서비스에서 도착하는 이벤트 수는 매일 변경됩니다. 이러한 가변성으로 인해 앱이 최적이 않은 값으로 실행될 수 있습니다. 예를 들어 함수 앱은 요일 마지막 날에 까다로운 메시지 페이로드를 처리할 수 있으므로 동시성을 제한해야 합니다. 그러나 나머지 주 동안 메시지 페이로드는 더 가벼울 수 있습니다. 즉, 나머지 주에 더 높은 동시성 수준을 사용할 수 있습니다.

이상적으로 시스템은 각 인스턴스를 정상 상태로 유지하고 대기 시간을 낮게 유지하면서 인스턴스가 가능한 한 많은 작업을 처리할 수 있도록 허용해야 합니다. 동적 동시성은 해당 용도로 설계되었습니다.

동적 동시성

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

이점

동적 동시성은 다음과 같은 이점을 제공합니다.

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

동적 동시성 구성

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

기본적으로 동적 동시성은 꺼져 있습니다. 동적 동시성을 켜면 동시성이 각 함수에 대해 1 수준에서 시작됩니다. 동시성 수준은 호스트가 결정하는 최적 값으로 조정됩니다.

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

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

snapshotPersistenceEnabled 기본값인 경우 true학습된 동시성 값은 주기적으로 스토리지에 유지됩니다. 새 인스턴스는 한 수준에서 시작하여 학습을 다시 실행해야 하는 대신 해당 값에서 시작합니다.

동시성 관리자

백그라운드에서 동적 동시성이 켜지면 동시성 관리자 프로세스가 백그라운드에서 실행됩니다. 이 관리자는 CPU 및 스레드 사용률과 같은 인스턴스 상태 메트릭을 지속적으로 모니터링하고 필요에 따라 제한을 변경합니다. 하나 이상의 제한이 켜지면 호스트가 다시 정상화될 때까지 함수 동시성이 조정됩니다. 스로틀이 꺼지면 동시성이 증가할 수 있습니다. 필요할 경우 이러한 제한에 따라 필요에 따라 동시성을 위아래로 지능적으로 조정하는 데 다양한 추론이 사용됩니다. 시간이 지남에 따라 각 함수에 대한 동시성이 특정 수준으로 안정화됩니다. 최적 동시성 값을 결정하는 데 시간이 걸릴 수 있으므로 초기 또는 비활성 기간 후에 솔루션에 최적이 않은 값이 허용되는 경우에만 동적 동시성을 사용합니다.

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

동적 동시성이 켜지면 로그에서 동적 동시성 결정을 찾을 수 있습니다. 예를 들어, 다양한 제어 장치가 활성화될 때와 각 함수별로 동시성이 상향 또는 하향 조정될 때마다 로그 항목이 추가됩니다. 이러한 로그는 추적 테이블의 Host.Concurrency 로그 범주 아래에 기록 됩니다 .

확장 지원

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

다음 단계

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

• 신뢰할 수 있는 Azure Functions에 대한 모범 사례
• Azure Functions 개발자 가이드
• Azure Functions 트리거 및 바인딩