대상 기반 크기 조정
대상 기반 크기 조정은 고객에게 빠르고 직관적인 크기 조정 모델을 제공하며 현재 다음과 같은 바인딩 확장에 지원됩니다.
대상 기반 크기 조정은 이전 Azure Functions 증분 크기 조정 모델을 이러한 확장 형식의 기본값으로 대체합니다. 증분 크기 조정은 크기 조정 시기에 대한 복잡한 결정를 통해 각각의 새로운 인스턴스 비율마다 최대 한 명의 작업자를 추가하거나 제거했습니다. 반면, 대상 기반 크기 조정을 사용하면 한 번에 4개의 인스턴스를 스케일 업할 수 있으며 크기 조정 결정은 간단한 대상 기반 수식을 기반으로 합니다.
이 수식 에서 이벤트 원본 길이 는 처리해야 하는 이벤트 수를 나타냅니다. 인스턴스당 기본 대상 실행 값은 Azure Functions 확장에서 사용하는 SDK에서 가져옵니다. 대상 기반 크기 조정이 작동하기 위해 변경할 필요는 없습니다.
고려 사항
대상 기반 크기 조정을 사용할 때 적용되는 고려 사항은 다음과 같습니다.
- 대상 기반 크기 조정은 사용량 플랜, Flex 사용량 플랜 및 Elastic Premium 플랜에서 기본적으로 함수 앱에 사용하도록 설정되어 있습니다. 이벤트 기반 크기 조정은 전용(App Service) 플랜에서 실행될 때는 지원되지 않습니다.
- 대상 기반 크기 조정은 Functions 런타임 버전 4.19.0부터 기본적으로 사용하도록 설정됩니다.
- 대상 기반 크기 조정을 사용할 때 크기 한도는 계속 적용됩니다. 자세한 내용은 스케일 아웃 제한을 참조하세요.
- 메트릭을 기반으로 가장 정확한 크기 조정을 수행하려면 함수 앱당 하나의 대상 기반 트리거 함수만 사용합니다. 또한 함수별 크기 조정을 제공하는 Flex 사용량 플랜에서 실행하는 것을 고려해야 합니다.
- 동일한 함수 앱의 여러 함수가 동시에 스케일 아웃을 요청하는 경우 해당 함수의 합계를 사용하여 원하는 인스턴스의 변경 사항을 확인합니다. 스케일 아웃을 요청하는 함수는 스케일 인을 요청하는 함수를 재정의합니다.
- 스케일 아웃 요청이 없는 스케일 인 요청이 있는 경우 최대 스케일 인 값이 사용됩니다.
옵트아웃
대상 기반 크기 조정은 기본적으로 사용 계획 또는 프리미엄 계획에서 호스트되는 함수 앱에 사용하도록 설정됩니다. 대상 기반 크기 조정을 사용하지 않도록 설정하고 증분 크기 조정으로 되돌리려면 함수 앱에 다음 앱 설정을 추가합니다.
| 앱 설정 | 값 |
|---|---|
TARGET_BASED_SCALING_ENABLED |
0 |
대상 기반 크기 조정 사용자 지정
인스턴스당 대상 실행을 조정하여 앱의 워크로드에 따라 크기 조정 동작을 다소 공격적으로 만들 수 있습니다. 각 확장에는 인스턴스당 대상 실행을 설정하는 데 사용할 수 있는 다양한 설정이 있습니다.
이 표에는 인스턴스당 대상 실행에 사용되는 host.json 값과 기본값이 요약되어 있습니다.
| 내선 번호 | host.json 값 | 기본값 |
|---|---|---|
| Event Hubs(확장 v5.x+) | extensions.eventHubs.maxEventBatchSize | 100* |
| Event Hubs(확장 v3.x+) | extensions.eventHubs.eventProcessorOptions.maxBatchSize | 10 |
| Event Hubs(정의된 경우) | extensions.eventHubs.targetUnprocessedEventThreshold | 해당 없음 |
| Service Bus(확장 v5.x+, 단일 디스패치) | extensions.serviceBus.maxConcurrentCalls | 16 |
| Service Bus(확장 v5.x+, 단일 디스패치값 세션 기반) | extensions.serviceBus.maxConcurrentSessions | 8 |
| Service Bus(확장 v5.x+, 일괄 처리) | extensions.serviceBus.maxMessageBatchSize | 1000 |
| Service Bus(Functions v2.x+, 단일 디스패치) | extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls | 16 |
| Service Bus(Functions v2.x+, 단일 디스패치 세션 기반) | extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions | 2000 |
| Service Bus(Functions v2.x+, 일괄 처리) | extensions.serviceBus.batchOptions.maxMessageCount | 1000 |
| Storage 큐 | extensions.queues.batchSize | 16 |
* Microsoft.Azure.WebJobs.Extensions.EventHubs 패키지의 v6.0.0에서 기본값 maxEventBatchSize가 변경되었습니다. 이전 버전에서는 이 값이 10이었습니다.
일부 바인딩 확장의 경우 인스턴스당 대상 실행은 함수 특성을 사용하여 설정됩니다.
| 내선 번호 | 함수 트리거 설정 | 기본값 |
|---|---|---|
| Apache Kafka | lagThreshold |
1000 |
| Azure Cosmos DB | maxItemsPerInvocation |
100 |
자세한 내용은 지원되는 확장에 대한 예제 구성을 참조하세요.
런타임 크기 조정 모니터링을 사용하도록 설정된 프리미엄 계획
런타임 스케일링 모니터링을 사용하도록 설정하면 확장 자체에서 동적 스케일링을 처리합니다. 스케일링 컨트롤러가 가상 네트워크에서 보호하는 서비스에 액세스할 수 없기 때문입니다. 런타임 스케일링 모니터링을 사용하도록 설정한 후에는 확장 패키지를 이러한 최소 버전으로 업그레이드하여 추가 대상 기반 스케일링 기능을 잠금 해제해야 합니다.
| Extension Name | 필요한 최소 버전 |
|---|---|
| Apache Kafka | 3.9.0 |
| Azure Cosmos DB | 4.1.0 |
| Event Hubs | 5.2.0 |
| Service Bus | 5.9.0 |
| Storage 큐 | 5.1.0 |
동적 동시성 지원
대상 기반 크기 조정은 더 빠른 크기 조정을 도입하고 인스턴스당 대상 실행에 기본값을 사용합니다. Service Bus 또는 스토리지 큐를 사용하는 경우 동적 동시성을 사용하도록 설정할 수도 있습니다. 이 구성에서 인스턴스당 대상 실행 값은 동적 동시성 기능에 의해 자동으로 결정됩니다. 제한된 동시성으로 시작하여 시간 경과에 따른 최적의 설정을 식별합니다.
지원되는 확장
host.json 파일에서 대상 기반 크기 조정을 구성하는 방법은 특정 확장 유형에 따라 달라집니다. 이 섹션에서는 현재 대상 기반 크기 조정을 지원하는 확장에 대한 구성 세부 정보를 제공합니다.
Service Bus 큐 및 토픽
Service Bus 확장은 Service Bus 트리거의 IsBatched 및 IsSessionsEnabled 특성에 따라 결정되는 세 가지 실행 모델을 지원합니다. IsBatched 및 IsSessionsEnabled의 기본값은 false입니다.
| 실행 모델 | IsBatched | IsSessionsEnabled | 인스턴당 대상 실행에 사용되는 설정 |
|---|---|---|---|
| 단일 디스패치 처리 | false | false | maxConcurrentCalls |
| 단일 디스패치 처리(세션 기반) | false | true | maxConcurrentSessions |
| 일괄 처리 | true | false | maxMessageBatchSize 또는 maxMessageCount |
참고 항목
크기 조정 효율성: Service Bus 확장의 경우 가장 효율적인 크기 조정을 위해 리소스에 대한 관리 권한을 사용합니다. 수신 권한을 사용하면 큐 또는 토픽 길이를 사용하여 크기 조정 결정을 알릴 수 없으므로 크기 조정이 증분 크기 조정으로 되돌아 갑니다. Service Bus 액세스 정책에서 권한을 설정하는 방법에 대한 자세한 내용은 공유 액세스 권한 부여 정책을 참조하세요.
단일 디스패치 처리
이 모델에서 함수의 각 호출은 단일 메시지를 처리합니다. maxConcurrentCalls 설정은 인스턴스당 대상 실행을 제어합니다. 특정 설정은 Service Bus 확장 버전에 따라 달라집니다.
다음 예제와 같이 host.json 설정 maxConcurrentCalls를 수정합니다.
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentCalls": 16
}
}
}
단일 디스패치 처리(세션 기반)
이 모델에서 함수의 각 호출은 단일 메시지를 처리합니다. 그러나 Service Bus 토픽 또는 큐의 활성 세션 수에 따라 각 인스턴스는 하나 이상의 세션을 임대합니다. 특정 설정은 Service Bus 확장 버전에 따라 달라집니다.
다음 예제와 같이 host.json 설정 maxConcurrentSessions를 수정하여 인스턴스당 대상 실행을 설정합니다.
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentSessions": 8
}
}
}
일괄 처리
이 모델에서 함수의 각 호출은 메시지 일괄 처리를 처리합니다. 특정 설정은 Service Bus 확장 버전에 따라 달라집니다.
다음 예제와 같이 host.json 설정 maxMessageBatchSize를 수정하여 인스턴스당 대상 실행을 설정합니다.
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxMessageBatchSize": 1000
}
}
}
Event Hubs
Azure Event Hubs의 경우 Azure Functions는 이벤트 허브의 모든 파티션에 분산된 처리되지 않은 이벤트의 수를 기준으로 크기를 조정합니다. 기본적으로 인스턴스당 대상 실행에 사용되는 host.json 특성은 maxEventBatchSize 및 maxBatchSize입니다. 그러나 대상 기반 크기 조정을 미세 조정하도록 선택하는 경우 일괄 처리 설정을 변경하지 않고 인스턴스당 대상 실행을 설정하도록 재정의하는 별도의 매개 변수 targetUnprocessedEventThreshold를 정의할 수 있습니다. targetUnprocessedEventThreshold가 설정된 경우 처리되지 않은 총 이벤트 수를 이 값으로 나누어 인스턴스 수를 결정한 다음, 균형 잡힌 파티션 배포를 만드는 작업자 인스턴스 수로 반올림합니다.
참고 항목
Event Hubs는 분할된 워크로드이므로 Event Hubs의 대상 인스턴스 수는 이벤트 허브의 파티션 수로 제한됩니다.
특정 설정은 Event Hubs 확장 버전에 따라 달라집니다.
다음 예제와 같이 host.json 설정 maxEventBatchSize를 수정하여 인스턴스당 대상 실행을 설정합니다.
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
host.json에 정의된 경우 targetUnprocessedEventThreshold는 다음 예제와 같이 maxEventBatchSize 대신 인스턴스당 대상 실행으로 사용됩니다.
{
"version": "2.0",
"extensions": {
"eventHubs": {
"targetUnprocessedEventThreshold": 153
}
}
}
스토리지 큐
스토리지 확장의 v2.x+의 경우 host.json 설정 batchSize를 수정하여 인스턴스당 대상 실행을 설정합니다.
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 16
}
}
}
참고 항목
크기 조정 효율성: 스토리지 큐 확장의 경우 visibilityTimeout이 있는 메시지는 여전히 Storage Queue API에 의해 이벤트 원본 길이로 계산됩니다. 이로 인해 함수 앱의 오버스케일링이 발생할 수 있습니다. 예약된 메시지에 Service Bus 큐를 사용하거나, 스케일 아웃을 제한하거나, 솔루션에 visibilityTimeout을 사용하지 않는 것이 좋습니다.
Azure Cosmos DB
Azure Cosmos DB는 함수 수준 특성인 MaxItemsPerInvocation을 사용합니다. 이 함수 수준 특성을 설정하는 방법은 함수 언어에 따라 달라집니다.
컴파일된 C# 함수의 경우 In Process C# 함수에 대한 다음 예제와 같이 트리거 정의에 MaxItemsPerInvocation을 설정합니다.
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
MaxItemsPerInvocation: 100,
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
참고 항목
Azure Cosmos DB는 분할된 워크로드이므로 데이터베이스의 대상 인스턴스 수는 컨테이너의 실제 파티션 수로 제한됩니다. Azure Cosmos DB 크기 조정에 대해 자세히 알아보려면 실제 파티션 및 임대 소유권을 참조하세요.
Apache Kafka
Apache Kafka 확장은 함수 수준 특성인 LagThreshold를 사용합니다. Kafka의 경우 원하는 인스턴스의 수는 총 소비자 지연을 LagThreshold 설정으로 나눈 값에 따라 계산됩니다. 지정된 지연의 경우 지연 임계값을 줄이면 원하는 인스턴스 수가 증가합니다.
이 함수 수준 특성을 설정하는 방법은 함수 언어에 따라 달라집니다. 다음 예제에서는 해당 임계값을 100으로 설정합니다.
컴파일된 C# 함수의 경우 Kafka Event Hubs 트리거의 In Process C# 함수에 대한 다음 예제와 같이 트리거 정의에 LagThreshold을 설정합니다.
[FunctionName("KafkaTrigger")]
public static void Run(
[KafkaTrigger("BrokerList",
"topic",
Username = "$ConnectionString",
Password = "%EventHubConnectionString%",
Protocol = BrokerProtocol.SaslSsl,
AuthenticationMode = BrokerAuthenticationMode.Plain,
ConsumerGroup = "$Default",
LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{
log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}
다음 단계
자세한 내용은 다음 문서를 참조하세요.