이 문서에서는 애플리케이션에서 함께 Azure Event Hubs 사용하고 Azure Functions 경우 확장성 및 성능을 최적화하기 위한 지침을 제공합니다.
함수 그룹화
일반적으로 함수는 이벤트 처리 스트림의 작업 단위를 캡슐화합니다. 예를 들어 함수는 이벤트를 새 데이터 구조로 변환하거나 다운스트림 애플리케이션에 대한 데이터를 보강할 수 있습니다.
Functions에서 함수 앱은 함수에 대한 실행 컨텍스트를 제공합니다. 함수 앱 동작은 함수 앱이 호스트하는 모든 함수에 적용됩니다. 함수 앱의 함수는 함께 배포되고 함께 확장됩니다. 함수 앱의 모든 함수는 동일한 언어여야 합니다.
함수를 함수 앱으로 그룹화하면 함수 앱의 성능 및 크기 조정 기능에 영향을 줄 수 있습니다. 액세스 권한, 배포 및 코드를 호출하는 사용 패턴에 따라 그룹화할 수 있습니다.
그룹화 및 기타 측면에 대한 Functions 모범 사례에 대한 지침은 신뢰할 수 있는 Azure Functions 대한 모범 사례 및 Azure Functions 성능 및 안정성 향상을 참조하세요.
다음 목록은 함수를 그룹화하기 위한 지침입니다. 이 지침에서는 스토리지 및 소비자 그룹 측면을 고려합니다.
함수 앱에서 단일 함수를 호스트합니다 . Event Hubs가 함수를 트리거하는 경우 해당 함수와 다른 함수 간의 경합을 줄이기 위해 자체 함수 앱에서 함수를 격리할 수 있습니다. 다른 함수가 CPU 또는 메모리를 많이 사용하는 경우 격리가 특히 중요합니다. 이 기술은 각 함수에 호스트하는 함수 앱의 크기 조정에 직접적인 영향을 줄 수 있는 고유한 메모리 공간 및 사용 패턴을 가지고 있기 때문에 도움이 됩니다.
각 함수 앱에 고유한 스토리지 계정을 제공합니다. 함수 앱 간에 스토리지 계정을 공유하지 않습니다. 또한 함수 앱에서 스토리지 계정을 사용하는 경우 다른 스토리지 작업 또는 요구 사항에 해당 계정을 사용하지 마세요. 이러한 함수는 검사점 지정으로 인해 대량의 스토리지 트랜잭션을 가질 수 있으므로 Event Hubs가 트리거하는 함수에 대한 스토리지 계정을 공유하지 않는 것이 특히 중요할 수 있습니다.
각 함수 앱에 대한 전용 소비자 그룹을 만듭니 다. 소비자 그룹은 이벤트 허브의 보기입니다. 소비자 그룹은 보기가 다르므로 상태, 위치 및 오프셋이 다를 수 있습니다. 소비자 그룹을 사용하면 여러 소비 애플리케이션이 이벤트 스트림에 대한 고유한 보기를 가질 수 있으며 자체 속도와 자체 오프셋으로 독립적으로 스트림을 읽을 수 있습니다. 소비자 그룹에 대한 자세한 내용은 Azure Event Hubs 기능 및 용어를 참조하세요.
소비자 그룹에는 하나 이상의 소비자 애플리케이션이 연결되어 있으며 소비자 애플리케이션은 하나 이상의 소비자 그룹을 사용할 수 있습니다. 스트림 처리 솔루션에서 각 소비자 애플리케이션은 소비자 그룹과 동일합니다. 함수 앱은 소비자 애플리케이션의 대표적인 예입니다. 다음 다이어그램에서는 각 앱에 고유한 전용 소비자 그룹이 있는 이벤트 허브에서 읽은 두 개의 함수 앱의 예를 제공합니다.
함수 앱과 다른 소비자 애플리케이션 간에 소비자 그룹을 공유하지 마세요. 각 함수 앱은 각 소비자에 대한 오프셋 무결성을 보장하고 이벤트 스트리밍 아키텍처의 종속성을 간소화하기 위해 자체 할당된 소비자 그룹이 있는 고유한 애플리케이션이어야 합니다. 이러한 구성은 각 이벤트 허브 트리거 함수 자체의 함수 앱 및 스토리지 계정을 제공하는 방법과 함께 최적의 성능 및 크기 조정을 위한 기반을 설정하는 데 도움이 됩니다.
함수 호스팅 계획
모든 함수 앱은 세 가지 호스팅 계획 중 하나에 따라 호스트됩니다. 이러한 계획에 대한 자세한 내용은 Azure Functions 호스팅 옵션을 참조하세요. 세 가지 옵션의 크기를 조정하는 방법을 기록해 둡다.
소비 계획은 기본값입니다. 소비 계획의 함수 앱은 독립적으로 확장되며 장기 실행 작업을 방지할 때 가장 효과적입니다.
프리미엄 및 Dedicated 플랜은 CPU 및 메모리를 많이 사용하는 여러 함수 앱과 함수를 호스트하는 데 자주 사용됩니다. 전용 계획을 사용하면 Azure App Service 계획에서 함수를 정기적인 App Service 계획 속도로 실행합니다. 이러한 계획의 모든 함수 앱은 계획에 할당된 리소스를 공유한다는 점에 유의해야 합니다. 함수에 다른 부하 프로필 또는 고유한 요구 사항이 있는 경우 특히 스트림 처리 애플리케이션에서 다양한 계획에서 호스트하는 것이 가장 좋습니다.
Event Hubs 스케일링
Event Hubs 네임스페이스를 배포할 때 최대 성능 및 크기 조정을 보장하기 위해 올바르게 설정해야 하는 몇 가지 중요한 설정이 있습니다. 이 섹션에서는 Functions를 사용할 때 크기 조정에 영향을 주는 Event Hubs의 표준 계층 및 해당 계층의 고유한 기능에 중점을 둡니다. Event Hubs 계층에 대한 자세한 내용은 기본 및 표준 및 프리미엄 및 전용 계층을 참조하세요.
Event Hubs 네임스페이스는 Kafka 클러스터에 해당합니다. Event Hubs와 Kafka가 서로 어떻게 관련되는지에 대한 자세한 내용은 Apache Kafka에 대한 Azure Event Hubs란?을 참조하세요.
처리량 단위 이해(TU)
Event Hubs 표준 계층에서 처리량은 입력되는 데이터의 양으로 분류되며 시간 단위당 네임스페이스에서 읽습니다. TU는 미리 구매한 처리량 용량 단위입니다.
TU는 시간 단위로 청구됩니다.
네임스페이스의 모든 이벤트 허브는 TU를 공유합니다. 용량 요구 사항을 올바르게 계산하려면 게시자와 소비자 모두의 모든 애플리케이션과 서비스를 고려해야 합니다. 함수는 이벤트 허브에 게시되고 이벤트 허브에서 읽는 바이트 및 이벤트 수에 영향을 줍니다.
TU 수를 결정하는 데 중점을 두는 것은 수신 지점에 있습니다. 그러나 이벤트가 처리되는 속도를 포함하여 소비자 애플리케이션의 집계도 계산에 넣어야 합니다.
Event Hubs 처리량 단위에 대한 자세한 내용은 처리량 단위를 참조하세요.
자동 팽창으로 스케일 업
부하가 구성된 TU 수를 초과하는 상황을 수용하기 위해 Event Hubs 네임스페이스에서 자동 팽창을 사용하도록 설정할 수 있습니다. 자동 팽창을 사용하면 애플리케이션의 제한이 방지되고 이벤트 수집을 포함한 처리가 중단 없이 계속되도록 할 수 있습니다. TU 설정은 비용에 영향을 주므로 자동 팽창을 사용하면 과잉 프로비전에 대한 문제를 해결하는 데 도움이 됩니다.
자동 팽창은 특히 서버리스 솔루션의 컨텍스트에서 자동 크기 조정과 혼동되는 Event Hubs의 기능입니다. 그러나 자동 크기 조정과 달리 자동 팽창은 추가된 용량이 더 이상 필요하지 않을 때 축소되지 않습니다.
애플리케이션에 허용되는 최대 TU 수를 초과하는 용량이 필요한 경우 Event Hubs 프리미엄 계층 또는 전용 계층을 사용하는 것이 좋습니다.
파티션 및 동시 함수
이벤트 허브를 만들 때 파티션 수를 지정해야 합니다. 파티션 수는 고정된 상태로 유지되며 프리미엄 및 전용 계층을 제외하고 변경할 수 없습니다. Event Hubs가 함수 앱을 트리거하는 경우 동시 인스턴스 수가 파티션 수와 같을 수 있습니다.
소비 및 프리미엄 호스팅 계획에서 함수 앱 인스턴스는 필요한 경우 파티션 수를 충족하도록 동적으로 확장됩니다. 전용 호스팅 계획은 App Service 계획에서 함수를 실행하며 인스턴스를 수동으로 구성하거나 자동 크기 조정 체계를 설정해야 합니다. 자세한 내용은 Azure Functions 전용 호스팅 계획을 참조하세요.
궁극적으로 파티션 수와 함수 앱 인스턴스 수 간의 일대일 관계는 스트림 처리 솔루션의 최대 처리량에 이상적인 대상입니다. 최적의 병렬 처리를 달성하려면 소비자 그룹에 여러 소비자가 있어야 합니다. Functions의 경우 이 목표는 계획에서 함수 앱의 많은 인스턴스로 변환됩니다. 결과는 다음 다이어그램과 같이 파티션 수준 병렬 처리 또는 최대 병렬 처리 수준이라고 합니다.
최대 처리량을 달성하고 더 많은 양의 이벤트 가능성을 고려하도록 가능한 한 많은 파티션을 구성하는 것이 합리적일 수 있습니다. 그러나 여러 파티션을 구성할 때 고려해야 할 몇 가지 중요한 요소가 있습니다.
- 파티션이 많을수록 처리량이 늘어나게 됩니다 . 병렬 처리 수준은 소비자 수(함수 앱 인스턴스)이므로 파티션이 많을수록 동시 처리량이 높을 수 있습니다. 이 사실은 이벤트 허브에 대해 지정된 수의 TU를 다른 소비자 애플리케이션과 공유하는 경우에 중요합니다.
- 더 많은 함수에는 더 많은 메모리가 필요할 수 있습니다 . 함수 앱 인스턴스 수가 증가함에 따라 계획에 있는 리소스의 메모리 공간도 증가합니다. 어느 시점에서 너무 많은 파티션이 소비자의 성능을 저하시킬 수 있습니다.
- 다운스트림 서비스에서 역압의 위험이 있습니다. 더 많은 처리량이 생성되면 다운스트림 서비스가 압도적이거나 그로부터 역압을 받을 위험이 있습니다. 소비자 팬아웃은 주변 리소스에 대한 결과를 고려할 때 고려해야 합니다. 가능한 결과에는 다른 서비스의 제한, 네트워크 포화 및 기타 형태의 리소스 경합이 포함되었습니다.
- 파티션은 드물게 채워질 수 있습니다 . 많은 파티션과 적은 양의 이벤트의 조합으로 인해 파티션 간에 드물게 분산되는 데이터가 발생할 수 있습니다. 대신 적은 수의 파티션이 더 나은 성능 및 리소스 사용량을 제공할 수 있습니다.
가용성 및 일관성
파티션 키 또는 ID를 지정하지 않으면 Event Hubs는 들어오는 이벤트를 사용 가능한 다음 파티션으로 라우팅합니다. 이 방법은 고가용성을 제공하고 소비자의 처리량을 높이는 데 도움이 됩니다.
이벤트 집합의 순서가 필요한 경우 이벤트 생산자는 집합의 모든 이벤트에 특정 파티션을 사용하도록 지정할 수 있습니다. 파티션에서 읽는 소비자 애플리케이션은 적절한 순서로 이벤트를 받습니다. 이렇게 하면 일관성이 향상되지만 가용성은 저하됩니다. 이벤트의 순서를 유지해야 하는 경우가 아니면 이 방법을 사용하지 마세요.
Functions의 경우 이벤트가 특정 파티션에 게시되고 Event Hubs 트리거 함수가 동일한 파티션을 임대할 때 순서가 지정됩니다. 현재 Event Hubs 출력 바인딩을 사용하여 파티션을 구성하는 기능은 지원되지 않습니다. 대신 Event Hubs SDK 중 하나를 사용하여 특정 파티션에 게시하는 것이 가장 좋습니다.
Event Hubs에서 가용성 및 일관성을 지원하는 방법에 대한 자세한 내용은 Event Hubs의 가용성 및 일관성을 참조하세요.
Event Hubs 트리거
이 섹션에서는 Event Hubs가 트리거하는 함수를 최적화하기 위한 설정 및 고려 사항에 중점을 둡니다. 요소에는 이벤트 허브 트리거 바인딩의 동작에 영향을 주는 일괄 처리, 샘플링 및 관련 기능이 포함됩니다.
트리거된 함수에 대한 일괄 처리
이벤트 허브가 이벤트 일괄 처리 또는 한 번에 하나의 이벤트를 처리하도록 트리거하는 함수를 구성할 수 있습니다. 이벤트 일괄 처리를 처리하면 함수 호출의 오버헤드가 일부 제거되므로 더 효율적입니다. 단일 이벤트만 처리해야 하는 경우 외에는 호출 시 여러 이벤트를 처리하도록 함수를 구성해야 합니다.
Event Hubs 트리거 바인딩에 일괄 처리를 사용하도록 설정하는 방법은 언어마다 다릅니다.
- JavaScript, Python 및 기타 언어는 카디널리티 속성이 함수에 대한 function.json 파일의 여러 으로 설정된 경우 일괄 처리를 사용하도록 설정합니다.
- C#에서는 EventHubTrigger 특성의 형식에 대해 배열이 지정되면 카디널리티가 자동으로 구성됩니다.
일괄 처리를 사용하는 방법에 대한 자세한 내용은 Azure Functions 대한 Azure Event Hubs 트리거를 참조하세요.
트리거 설정
host.json 파일의 여러 구성 설정은 Functions에 대한 Event Hubs 트리거 바인딩의 성능 특성에서 중요한 역할을 합니다.
- maxEventBatchSize: 이 설정은 함수가 호출될 때 수신할 수 있는 최대 이벤트 수를 나타냅니다. 수신된 이벤트 수가 이 양보다 작으면 현재 사용 가능한 만큼의 이벤트로 함수가 계속 호출됩니다. 최소 일괄 처리 크기를 설정할 수 없습니다.
- prefetchCount: 프리페치 수는 성능을 최적화할 때 가장 중요한 설정 중 하나입니다. 기본 AMQP 채널은 이 값을 참조하여 클라이언트에 대해 가져오고 캐시할 메시지 수를 결정합니다. 프리페치 수는 maxEventBatchSize 값보다 크거나 같아야 하며 일반적으로 해당 금액의 배수로 설정됩니다. 이 값을 maxEventBatchSize 설정보다 작은 숫자로 설정하면 성능이 저하될 수 있습니다.
- batchCheckpointFrequency: 함수가 일괄 처리를 처리할 때 이 값은 검사점이 생성되는 속도를 결정합니다. 기본값은 1입니다. 즉, 함수가 일괄 처리를 성공적으로 처리할 때마다 검사점이 있음을 의미합니다. 검사점은 소비자 그룹의 각 판독기 파티션 수준에서 만들어집니다. 이 설정이 이벤트의 재생 및 재시도에 미치는 영향에 대한 자세한 내용은 이벤트 허브 트리거 Azure 함수: 재생 및 다시 시도(블로그 게시물)를 참조하세요.
여러 성능 테스트를 수행하여 트리거 바인딩에 설정할 값을 결정합니다. 이러한 옵션을 미세 조정하려면 설정을 증분 방식으로 변경하고 일관되게 측정하는 것이 좋습니다. 기본값은 대부분의 이벤트 처리 솔루션에 적합한 시작점입니다.
검사점 설정
검사점은 파티션 이벤트 시퀀스에서 판독기 위치를 표시하거나 커밋합니다. 이벤트가 처리되고 일괄 처리 검사점 빈도 설정이 충족될 때 검사점을 만드는 것은 Functions 호스트의 책임입니다. 검사점 지정에 대한 자세한 내용은 Azure Event Hubs 기능 및 용어를 참조하세요.
다음 개념은 검사점과 함수가 이벤트를 처리하는 방식 간의 관계를 이해하는 데 도움이 될 수 있습니다.
- 예외는 여전히 성공에 포함됩니다. 이벤트를 처리하는 동안 함수 프로세스가 충돌하지 않으면 예외가 발생하더라도 함수 완료가 성공한 것으로 간주됩니다. 함수가 완료되면 Functions 호스트는 batchCheckpointFrequency를 평가합니다. 검사점이 있는 경우 예외가 있는지 여부에 관계없이 검사점이 만들어집니다. 예외가 검사점 지정에 영향을 주지 않는다는 사실은 예외 검사 및 처리의 적절한 사용에 영향을 주지 않아야 합니다.
- 일괄 처리 빈도는 다음과 같습니다. 대용량 이벤트 스트리밍 솔루션에서는 batchCheckpointFrequency 설정을 1보다 큰 값으로 변경하는 것이 도움이 될 수 있습니다. 이 값을 늘리면 검사점 생성 속도가 줄어들고 결과적으로 스토리지 I/O 작업 수가 감소할 수 있습니다.
- 재생이 발생할 수 있습니다. 함수는 Event Hubs 트리거 바인딩을 사용하여 호출될 때마다 가장 최근의 검사점 을 사용하여 처리를 다시 시작할 위치를 결정합니다. 모든 소비자에 대한 오프셋은 각 소비자 그룹의 파티션 수준에 저장됩니다. 재생은 함수의 마지막 호출 중에 검사점이 발생하지 않고 함수가 다시 호출될 때 발생합니다. 중복 및 중복 제거 기술에 대한 자세한 내용은 Idempotency를 참조하세요.
이 문서의 뒷부분에서 설명하는 항목인 오류 처리 및 다시 시도에 대한 모범 사례를 고려할 때 검사점 이해가 중요합니다.
원격 분석 샘플링
Functions는 애플리케이션 성능 모니터링 기능을 제공하는 Azure Monitor의 확장인 Application Insights에 대한 기본 제공 지원을 제공합니다. 이 기능을 사용하면 함수 활동, 성능, 런타임 예외 등에 대한 정보를 기록할 수 있습니다. 자세한 내용은 Application Insights 개요를 참조하세요.
이 강력한 기능은 성능에 영향을 주는 몇 가지 주요 구성 선택 항목을 제공합니다. 모니터링 및 성능에 대한 주목할 만한 설정 및 고려 사항은 다음과 같습니다.
- 원격 분석 샘플링 사용: 처리량이 높은 시나리오의 경우 필요한 원격 분석 및 정보의 양을 평가해야 합니다. 불필요한 원격 분석 및 메트릭을 사용하여 함수의 성능 저하를 방지하려면 Application Insights에서 원격 분석 샘플링 기능을 사용하는 것이 좋습니다.
- 집계 설정 구성: Application Insights에 데이터를 집계하고 보내는 빈도를 검사하고 구성합니다. 이 구성 설정은 다른 여러 샘플링 및 로깅 관련 옵션과 함께 host.json 파일에 있습니다. 자세한 내용은 집계 구성을 참조하세요.
- AzureWebJobDashboard 사용 안 함: Functions 런타임 버전 1.x를 대상으로 하는 앱의 경우 이 설정은 Azure SDK가 WebJobs 대시보드에 대한 로그를 유지하는 데 사용하는 스토리지 계정에 연결 문자열을 저장합니다. WebJobs 대시보드 대신 Application Insights를 사용하는 경우 이 설정을 제거해야 합니다. 자세한 내용은 AzureWebJobsDashboard를 참조하세요.
샘플링 없이 Application Insights를 사용하도록 설정하면 모든 원격 분석이 전송됩니다. 모든 이벤트에 대한 데이터를 보내는 것은 특히 처리량이 많은 이벤트 스트리밍 시나리오에서 함수의 성능에 해로운 영향을 미칠 수 있습니다.
샘플링을 활용하고 모니터링에 필요한 적절한 양의 원격 분석을 지속적으로 평가하는 것은 최적의 성능에 매우 중요합니다. 원격 분석은 핵심 비즈니스 메트릭을 캡처하지 않고 일반적인 플랫폼 상태 평가 및 가끔 문제 해결에 사용해야 합니다. 자세한 내용은 샘플링 구성을 참조하세요.
출력 바인딩
Azure Functions Event Hubs 출력 바인딩을 사용하여 함수에서 이벤트 스트림에 게시를 간소화합니다. 이 바인딩을 사용할 경우의 이점은 다음과 같습니다.
- 리소스 관리: 바인딩은 클라이언트와 연결 수명 주기를 모두 처리하고 포트 고갈 및 연결 풀 관리에서 발생할 수 있는 문제의 가능성을 줄입니다.
- 적은 코드: 바인딩은 기본 SDK를 추상화하고 이벤트를 게시하는 데 필요한 코드의 양을 줄입니다. 이를 통해 더 쉽게 작성하고 유지 관리할 수 있는 코드를 작성할 수 있습니다.
- 일괄 처리: 여러 언어의 경우 일괄 처리가 이벤트 스트림에 효율적으로 게시되도록 지원됩니다. 일괄 처리는 성능을 향상시키고 이벤트를 보내는 코드를 간소화하는 데 도움이 될 수 있습니다.
Functions에서 지원하는 언어 목록과 해당 언어에 대한 개발자 가이드를 검토하는 것이 좋습니다. 각 언어의 바인딩 섹션에서는 자세한 예제와 설명서를 제공합니다.
이벤트를 게시할 때 일괄 처리
함수가 단일 이벤트만 게시하는 경우 값을 반환하도록 바인딩을 구성하는 것은 함수 실행이 항상 이벤트를 보내는 문으로 끝나는 경우에 유용한 일반적인 방법입니다. 이 기술은 하나의 이벤트만 반환하는 동기 함수에만 사용해야 합니다.
여러 이벤트를 스트림으로 보낼 때 일괄 처리를 사용하여 성능을 향상시키는 것이 좋습니다. 일괄 처리를 사용하면 바인딩이 가장 효율적인 방법으로 이벤트를 게시할 수 있습니다.
출력 바인딩을 사용하여 Event Hubs에 여러 이벤트를 보내는 지원은 C#, Java, Python 및 JavaScript에서 사용할 수 있습니다.
여러 이벤트 출력(C#)
C#의 함수에서 여러 이벤트를 보낼 때 ICollector 및 IAsyncCollector 형식을 사용합니다.
- ICollector<T>입니다. Add() 메서드는 동기 함수와 비동기 함수 모두에서 사용할 수 있습니다. 이 메서드는 호출되는 즉시 추가 작업을 실행합니다.
- IAsyncCollector<T>입니다. AddAsync() 메서드는 이벤트 스트림에 게시할 이벤트를 준비합니다. 비동기 함수를 작성하는 경우 IAsyncCollector 를 사용하여 게시된 이벤트를 더 잘 관리해야 합니다.
C#을 사용하여 단일 및 여러 이벤트를 게시하는 예제는 Azure Functions 대한 Azure Event Hubs 출력 바인딩을 참조하세요.
제한 및 역 압력
제한 고려 사항은 Event Hubs뿐만 아니라 Azure Cosmos DB와 같은 Azure 서비스에 대해서도 출력 바인딩에 적용됩니다. 해당 서비스에 적용되는 제한 및 할당량에 익숙해지고 그에 따라 계획하는 것이 중요합니다.
다운스트림 오류를 처리하려면 IAsyncCollector에서 예외를 catch하기 위해 .NET Functions에 대한 예외 처리기에서 AddAsync 및 FlushAsync 를 래핑할 수 있습니다. 또 다른 옵션은 출력 바인딩을 사용하는 대신 Event Hubs SDK를 직접 사용하는 것입니다.
함수 코드
이 섹션에서는 Event Hubs가 트리거하는 함수에서 이벤트를 처리하기 위해 코드를 작성할 때 고려해야 하는 주요 영역에 대해 설명합니다.
비동기 프로그래밍
특히 I/O 호출이 관련된 경우 비동기 코드를 사용하고 호출을 차단하지 않도록 함수를 작성하는 것이 좋습니다.
비동기적으로 처리하는 함수를 작성할 때 따라야 하는 지침은 다음과 같습니다.
- 모든 비동기 또는 모든 동기: 함수가 비동기적으로 실행되도록 구성된 경우 모든 I/O 호출은 비동기적이어야 합니다. 대부분의 경우 부분적으로 비동기 코드는 완전히 동기적인 코드보다 더 나쁩니다. 비동기 또는 동기 중 하나를 선택하고 선택을 계속 진행합니다.
- 호출을 차단하지 않습니다 . 차단 호출은 즉시 반환되는 비동기 호출과 달리 호출이 완료된 후에만 호출자에게 반환됩니다. C# 예제는 비동기 작업에서 Task.Result 또는 Task.Wait를 호출하는 것입니다.
호출 차단에 대한 자세한 정보
비동기 작업에 대한 차단 호출을 사용하면 스레드 풀이 부족해지고 함수 프로세스가 충돌할 수 있습니다. 현재 대기 중인 원래 호출을 보정하기 위해 차단 호출을 사용하려면 다른 스레드를 만들어야 하므로 충돌이 발생합니다. 따라서 작업을 완료하려면 두 배의 스레드가 필요합니다.
함수 크래시가 검사포인트를 업데이트하지 않으므로 Event Hubs가 관련된 경우 비동기 접근 방식을 통해 이 동기화를 방지하는 것이 특히 중요합니다. 다음에 함수를 호출하면 이 주기로 끝날 수 있으며, 함수 실행이 결국 시간이 초과될 때 중단되거나 천천히 이동하는 것처럼 보일 수 있습니다.
이 현상 문제를 해결하는 것은 일반적으로 트리거 설정을 검토하고 파티션 수를 늘리는 실험을 실행하는 것으로 시작됩니다. 조사를 통해 최대 일괄 처리 크기 또는 프리페치 수와 같은 여러 일괄 처리 옵션을 변경할 수도 있습니다. 적절하게 조정해야 하는 처리량 문제 또는 구성 설정이라는 인상을 줍니다. 그러나 핵심 문제는 코드 자체에 있으며 이 문제를 해결해야 합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 이 문서를 처음에 작성한 기여자는 다음과 같습니다.
보안 주체 작성자:
- David Barkol | 수석 솔루션 전문가 GBB
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
계속하기 전에 다음 관련 문서를 검토하는 것이 좋습니다.
- Azure Functions에서 실행 모니터링
- Azure Functions 안정적인 이벤트 처리
- 동일한 입력에 대한 Azure Functions 디자인
- ASP.NET Core 비동기 지침
- Azure Functions의 Azure Event Hubs 트리거