프로비저닝된 동시성 구성 함수에 필요한 프로비저닝된 동시성 정확히 예측 프로비저닝된 동시성 사용 시 함수 코드 최적화 환경 변수를 사용하여 프로비저닝된 동시성 동작 확인 및 제어 프로비저닝된 동시성을 사용한 로깅 및 청구 동작 이해 Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화

함수에 대해 프로비저닝된 동시성 구성

Lambda에서 동시성은 함수가 동시에 처리하는 전송 중인 요청의 수입니다. 두 가지 유형의 동시성 제어를 사용할 수 있습니다.

예약된 동시성 - 함수에 할당된 최대 동시 인스턴스 수를 나타냅니다. 한 함수가 동시성을 예약하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 예약된 동시성은 가장 중요한 함수가 수신 요청을 처리하기에 충분한 동시성을 항상 확보하도록 하는 데 유용합니다. 함수에 예약된 동시성을 구성하는 경우 추가 요금이 부과되지 않습니다.
프로비저닝된 동시성 - 함수에 할당된 사전 초기화된 실행 환경의 수입니다. 이러한 실행 환경은 수신 함수 요청에 즉시 응답할 수 있도록 준비되어 있습니다. 프로비저닝된 동시성은 함수에 대해 콜드 스타트 지연 시간을 줄이는 데 유용합니다. 프로비저닝된 동시성을 구성하는 경우 AWS 계정에 추가 요금이 부과됩니다.

이 주제에서는 프로비저닝된 동시성을 관리하고 구성하는 방법에 대해 자세히 설명합니다. 이 두 가지 유형의 동시성 제어에 대한 개념적 개요는 예약된 동시성 및 프로비저닝된 동시성을 참조하세요. 예약된 동시성 구성에 대한 자세한 내용은 함수에 대해 예약된 동시성 구성 섹션을 참조하세요.

참고

Amazon MQ 이벤트 소스 매핑에 연결된 Lambda 함수는 기본 최대 동시성을 지원합니다. Apache Active MQ의 경우 최대 동시 인스턴스의 수는 5입니다. Rabbit MQ의 경우 최대 동시 인스턴스의 수는 1입니다. 함수에 예약 또는 프로비저닝된 동시성을 설정해도 이 한도는 변경되지 않습니다. Amazon MQ를 사용할 때 기본 최대 동시성 증가를 요청하려면 AWS Support에 문의하십시오.

Sections

프로비저닝된 동시성 구성
함수에 필요한 프로비저닝된 동시성 정확히 예측
프로비저닝된 동시성 사용 시 함수 코드 최적화
환경 변수를 사용하여 프로비저닝된 동시성 동작 확인 및 제어
프로비저닝된 동시성을 사용한 로깅 및 청구 동작 이해
Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화

프로비저닝된 동시성 구성

Lambda 콘솔 또는 Lambda API를 사용하여 함수에 대해 프로비저닝된 동시성 설정을 구성할 수 있습니다.

함수에 대해 프로비저닝된 동시성 할당(콘솔)

Lambda 콘솔의 함수 페이지를 엽니다.
프로비저닝된 동시성을 할당하려는 함수를 선택합니다.
구성(Configuration)을 선택한 다음 동시성(Concurrency)을 선택합니다.
프로비저닝된 동시성 구성(Provisioned concurrency configurations)에서 구성 추가(Add configuration)를 선택합니다.
한정자 유형과 별칭 또는 버전을 선택합니다.

참고
함수의 $LATEST 버전에서는 프로비저닝된 동시성을 사용할 수 없습니다.
함수에 이벤트 소스가 있는 경우 이벤트 소스가 올바른 함수 별칭 또는 버전을 가리키는지 확인합니다. 그렇지 않으면 함수가 프로비저닝된 동시성 환경을 사용하지 않습니다.
프로비저닝된 동시성 아래에 숫자를 입력합니다. Lambda가 월별 예상 비용을 제공합니다.
Save(저장)를 선택합니다.

계정에서 예약되지 않은 계정 동시성(- 100)까지 구성할 수 있습니다. 나머지 100단위의 동시성은 예약된 동시성을 사용하지 않는 함수용입니다. 예를 들어, 계정의 동시성 한도가 1,000인데 다른 함수에 예약되거나 프로비저닝된 동시성을 할당하지 않은 경우 단일 함수에 대해 최대 프로비저닝된 동시성 900단위를 구성할 수 있습니다.

함수에 프로비저닝된 동시성을 구성하면 다른 함수가 사용할 수 있는 동시성 풀에 영향이 줍니다. 예를 들어 function-a에 100의 프로비저닝된 동시성 단위를 구성하는 경우 계정의 다른 함수는 남은 900의 동시성 단위를 공유해야 합니다. function-a에서 100의 모든 단위를 사용하지 않더라도 마찬가지입니다.

동일한 함수에 예약된 동시성과 프로비저닝된 동시성을 모두 할당할 수 있습니다. 이 경우 프로비전된 동시성은 예약된 동시성을 초과할 수 없습니다.

이 제한은 함수 버전에도 적용됩니다. 특정 함수 버전에 할당할 수 있는 최대 프로비저닝된 동시성은 함수의 예약된 동시성에서 다른 함수 버전의 프로비저닝된 동시성을 뺀 값과 같습니다.

Lambda API를 사용하여 프로비저닝된 동시성을 구성하려면 다음 API 작업을 사용합니다.

예를 들어, AWS Command Line Interface(CLI)를 사용하여 프로비저닝된 동시성을 구성하려면 put-provisioned-concurrency-config 명령을 사용합니다. 다음 명령은 my-function이라는 함수의 BLUE 별칭에 대해 100단위의 프로비저닝된 동시성을 할당합니다.


aws lambda put-provisioned-concurrency-config --function-name my-function \
  --qualifier BLUE \
  --provisioned-concurrent-executions 100

그러면 다음과 같은 결과가 표시됩니다.


{
  "Requested ProvisionedConcurrentExecutions": 100,
  "Allocated ProvisionedConcurrentExecutions": 0,
  "Status": "IN_PROGRESS",
  "LastModified": "2023-01-21T11:30:00+0000"
}

함수에 필요한 프로비저닝된 동시성 정확히 예측

CloudWatch 지표를 사용하여 모든 활성 함수의 동시성 지표를 볼 수 있습니다. 구체적으로, ConcurrentExecutions 지표는 계정의 함수에 대한 동시 간접 호출 수를 보여줍니다.

이전 그래프는 이 함수가 주어진 시간에 평균 5~10개의 동시 요청을 처리하고 최대 20개의 요청을 처리함을 보여줍니다. 계정에 다른 함수가 많이 있다고 가정해 보겠습니다. 이 함수가 애플리케이션에 중요하고 호출할 때마다 지연 시간이 짧은 응답이 필요한 경우 프로비저닝된 동시성 단위로 최소 20을 구성합니다.

다음 수식을 사용하여 동시성을 계산할 수도 있습니다.


Concurrency = (average requests per second) * (average request duration in seconds)

필요한 동시성을 예측하려면 초당 평균 요청 수에 평균 요청 시간(초 단위)을 곱해야 합니다. Invocation 지표를 사용하여 초당 평균 요청 수를 추정하고 Duration 지표를 사용하여 평균 요청 지속 시간을 초 단위로 추정할 수 있습니다.

프로비저닝된 동시성을 구성할 때 Lambda는 일반적으로 함수에 필요한 동시성의 양 외에 10% 버퍼를 추가하도록 제안합니다. 예를 들어, 함수의 최대 동시 요청 수가 보통 200개인 경우 프로비저닝된 동시성을 220으로 설정합니다(200개의 동시 요청 + 10% = 프로비저닝된 동시성 220).

프로비저닝된 동시성 사용 시 함수 코드 최적화

프로비저닝된 동시성을 사용하는 경우 짧은 지연 시간을 위해 함수 코드를 재구성하여 최적화하는 것이 좋습니다. 프로비저닝된 동시성을 사용하는 함수의 경우 Lambda는 할당 중 모든 초기화 코드(예: 라이브러리 로드 및 클라이언트 인스턴스화)를 실행합니다. 따라서 실제 함수 간접 호출 중에 지연 시간에 영향이 없도록 초기화를 최대한 많이 기본 함수 핸들러 외부로 이동하는 것이 좋습니다. 반대로 기본 핸들러 코드 내부에서 라이브러리를 초기화하거나 클라이언트를 인스턴스화하면 프로비저닝된 동시성 사용 여부에 관계없이 간접적으로 호출할 때마다 함수가 이를 실행해야 합니다.

온디맨드 간접 호출의 경우, 함수에서 콜드 스타트가 나타날 때마다 Lambda는 초기화 코드를 다시 실행해야 할 수 있습니다. 이러한 함수의 경우 함수에 필요할 때까지 특정 기능의 초기화를 지연할 수 있습니다. 예를 들어, Lambda 핸들러에 대한 다음 제어 흐름을 고려하세요.


def handler(event, context):
    ...
    if ( some_condition ):
        // Initialize CLIENT_A to perform a task
    else:
        // Do nothing

이전 예제에서는 개발자가 함수 기본 핸들러 외부에서 CLIENT_A를 초기화하는 대신 if 문 내부에서 초기화했습니다. 이를 통해 Lambda는 some_condition이 충족되는 경우에만 이 코드를 실행합니다. 기본 핸들러 외부에서 CLIENT_A를 초기화하면 Lambda는 모든 콜드 스타트에서 해당 코드를 실행합니다. 이로 인해 전체 지연 시간이 늘어날 수 있습니다.

환경 변수를 사용하여 프로비저닝된 동시성 동작 확인 및 제어

함수가 프로비저닝된 동시성을 모두 사용할 수 있습니다. Lambda는 온디맨드 인스턴스를 사용하여 초과 트래픽을 처리합니다. Lambda가 특정 환경에 사용하는 초기화 유형을 결정하려면 AWS_LAMBDA_INITIALIZATION_TYPE 환경 변수의 값을 확인합니다. 이 변수에는 두 가지 가능한 값(provisioned-concurrency 또는 on-demand)이 있습니다. AWS_LAMBDA_INITIALIZATION_TYPE의 값은 변경할 수 없으며 환경의 전체 수명 주기 동안 일정하게 유지됩니다. 함수 코드에서 환경 변수의 값을 확인하려면 Lambda 환경 변수 검색 섹션을 참조하세요.

.NET 6 또는 .NET 7 런타임을 사용하는 경우 프로비저닝된 동시성을 사용하지 않더라도 함수의 지연 시간을 개선하도록 AWS_LAMBDA_DOTNET_PREJIT 환경 변수를 구성할 수 있습니다. .NET 런타임은 코드가 처음 직접 호출하는 각 라이브러리에서 지연 컴파일 및 초기화를 수행합니다. 결과적으로 Lambda 함수의 첫 번째 간접 호출은 후속 간접 호출보다 오래 걸릴 수 있습니다. 이를 완화하기 위해 AWS_LAMBDA_DOTNET_PREJIT에 대해 세 가지 값 중 하나를 선택할 수 있습니다.

ProvisionedConcurrency: Lambda가 프로비저닝된 동시성을 사용하여 모든 환경에 대해 사전 JIT 컴파일을 수행합니다. 이것이 기본값입니다.
Always: 함수가 프로비저닝된 동시성을 사용하지 않는 경우에도 Lambda가 모든 환경에 대해 사전 JIT 컴파일을 수행합니다.
Never: Lambda가 모든 환경에 대해 사전 JIT 컴파일을 비활성화합니다.

프로비저닝된 동시성을 사용한 로깅 및 청구 동작 이해

프로비저닝된 동시성 환경의 경우 Lambda가 환경의 인스턴스를 재활용하므로 함수의 초기화 코드가 할당 중에 실행됩니다. 환경 인스턴스가 요청을 처리한 후 로그와 트레이스에서 초기화 시간을 확인할 수 있습니다. Lambda는 환경 인스턴스가 요청을 처리하지 않더라도 초기화 비용을 청구한다는 점에 주의합니다. 프로비저닝된 동시성은 계속 실행되며 초기화 및 간접 호출 비용과는 별도로 비용이 청구됩니다. 자세한 내용은 AWS Lambda 요금을 참조하세요.

또한 프로비저닝된 동시성을 사용하여 Lambda 함수를 구성하면 Lambda는 함수 간접 호출 요청에 앞서 해당 실행 환경을 사용할 수 있도록 사전 초기화합니다. 그러나 함수는 함수가 실제로 간접 호출된 경우에만 CloudWatch에 호출 로그를 게시합니다. 따라서 초기화가 미리 수행된 경우에도 첫 번째 함수 간접 호출의 REPORT 로그 줄에 초기화 지속 시간 필드가 나타납니다. 이는 함수가 콜드 스타트를 경험했다는 의미는 아닙니다.

Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화

Application Auto Scaling을 사용하여 일정에 따라 또는 사용률을 기준으로 프로비저닝된 동시성을 관리할 수 있습니다. 함수에 예측 가능한 트래픽 패턴이 수신되는 경우 예약된 크기 조정을 사용합니다. 함수가 특정 사용률(%)을 유지하도록 하려면 대상 추적 스케일링 정책을 사용합니다.

예약된 조정

Application Auto Scaling을 사용하면 예측 가능한 로드 변경에 따라 자체 조정 일정을 설정할 수 있습니다. 자세한 내용 및 예제는 Application Auto Scaling 사용 설명서의 Application Auto Scaling의 예약된 조정과 AWS Compute Blog의 Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage를 참조하세요.

대상 추적

대상 추적을 통해 Application Auto Scaling은 스케일링 정책 정의 방식에 따라 CloudWatch 경보 세트를 생성하고 관리합니다. 이러한 경보가 활성화되면 Application Auto Scaling은 프로비저닝된 동시성을 사용하여 할당된 환경의 양을 자동으로 조정합니다. 예측 가능한 트래픽 패턴이 없는 애플리케이션에서는 대상 추적을 사용합니다.

대상 추적을 사용하여 프로비저닝된 동시성을 스케일링하려면 RegisterScalableTarget 및 PutScalingPolicy Application Auto Scaling API 작업을 사용합니다. 예를 들어, AWS Command Line Interface(CLI)를 사용하는 경우 다음 단계를 따르세요.

함수의 별칭을 조정 대상으로 등록합니다. 다음 예제에서는 my-function 함수의 BLUE 별칭을 등록합니다.


aws application-autoscaling register-scalable-target --service-namespace lambda \
    --resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \
    --scalable-dimension lambda:function:ProvisionedConcurrency

조정 정책을 대상에 적용합니다. 다음 예제에서는 별칭에 대해 프로비저닝된 동시성 구성을 조정하여 사용률을 70% 가까이 유지하도록 애플리케이션 Auto Scaling을 구성하지만 10%에서 90% 사이의 값을 적용할 수 있습니다.


aws application-autoscaling put-scaling-policy \
    --service-namespace lambda \
    --scalable-dimension lambda:function:ProvisionedConcurrency \
    --resource-id function:my-function:BLUE \
    --policy-name my-policy \
    --policy-type TargetTrackingScaling \
    --target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'

다음과 유사한 출력 화면이 표시되어야 합니다.


{
    "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
    "Alarms": [
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
        },
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
        }
    ]
}

Application Auto Scaling은 CloudWatch에서 두 개의 경보를 생성합니다. 프로비저닝된 동시성의 사용률이 지속적으로 70%를 초과하면 첫 번째 경보가 트리거됩니다. 이 경우 Application Auto Scaling은 프로비저닝된 동시성을 더 많이 할당하여 사용률을 줄입니다. 두 번째 경보는 사용률이 지속적으로 63%(70% 대상의 90%) 미만인 경우에 트리거됩니다. 이 경우 Application Auto Scaling이 별칭의 프로비저닝된 동시성을 줄입니다.

다음 예제에서는 프로비저닝된 동시성의 최소 양과 최대 양 사이에서 함수 크기가 사용률에 따라 조정됩니다.

Application Auto Scaling 대상 추적으로 프로비저닝된 동시성 자동 조정.

범례

함수 인스턴스
미결 요청
프로비저닝된 동시성
표준 동시성

미결 요청 수가 증가하면 구성된 최대값에 도달할 때까지 Application Auto Scaling이 프로비저닝된 동시성을 큰 폭으로 늘립니다. 이후 계정 동시성 한도에 도달하지 않은 경우 함수는 예약되지 않은 표준 동시성으로 계속 크기를 조정할 수 있습니다. 사용률이 떨어지고 낮게 유지되는 경우 Application Auto Scaling은 프로비저닝된 동시성을 주기적인 작은 단계로 줄입니다.

두 Application Auto Scaling 경보에서는 모두 기본적으로 평균 통계를 사용합니다. 트래픽이 빠르게 버스트되는 함수는 이러한 경보를 트리거하지 않을 수 있습니다. 예를 들어, Lambda 함수가 빠르게 실행되고(예: 20ms~100ms) 트래픽에서 빠른 버스트가 발생한다고 가정합니다. 이 경우 버스트 중에 요청 수가 할당된 프로비저닝된 동시성을 초과합니다. 하지만 Application Auto Scaling에서는 추가 환경을 프로비저닝하기 위해 최소 3분 동안 버스트 로드가 지속되어야 합니다. 또한 두 CloudWatch 경보 모두에는 Auto Scaling 정책을 활성화하기 위해 목표 평균에 도달하는 3개의 데이터 포인트가 필요합니다. 함수에서 트래픽이 빠르게 급증하는 경우 평균 통계 대신 최대 통계를 사용하면 프로비저닝된 동시성의 규모를 조정하여 콜드 스타트를 최소화하는 데 더 효과적일 수 있습니다.

대상 추적 조정 정책에 대한 자세한 내용은 Application Auto Scaling의 대상 추적 조정 정책을 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

예약된 동시성 구성

조정 동작