Lambda 프로비저닝된 동시성 관리 - AWS Lambda

Lambda 프로비저닝된 동시성 관리

두 가지 유형의 동시성 제어를 사용할 수 있습니다.

  • 예약된 동시성 - 예약된 동시성은 함수에 대한 최대 동시 인스턴스 수를 보장합니다. 한 함수가 동시성을 예약하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 함수에 대해 예약된 동시성을 구성하는 데는 요금이 부과되지 않습니다.

  • 프로비저닝된 동시성 - 프로비저닝된 동시성은 함수의 호출에 즉시 응답할 준비가 되도록 요청된 수의 실행 환경을 초기화합니다. 프로비저닝된 동시성을 구성하면 AWS 계정에 요금이 부과됩니다.

이 주제에서는 프로비저닝된 동시성을 관리하고 구성하는 방법에 대해 자세히 설명합니다. 예약된 동시성을 구성하려면 Lambda 예약된 동시성 관리를 참조하세요.

Lambda에서 함수의 인스턴스를 할당하면 런타임은 함수의 코드를 로드하고 핸들러 외부에서 정의하는 초기화 코드를 실행합니다. 코드 및 종속성이 크거나 초기화 중에 SDK 클라이언트를 생성하는 경우 이 프로세스에 약간 시간이 걸릴 수 있습니다. 함수가 한동안 사용되지 않았거나, 확장해야 하거나, 함수를 업데이트할 때 Lambda는 새로운 실행 환경을 생성합니다. 이로 인해 새 인스턴스에서 제공하는 요청 부분이 나머지보다 긴 대기 시간을 갖게 되는 콜드 스타트가 발생합니다.

호출이 증가하기 전에 프로비저닝된 동시성을 할당하면 짧은 지연 시간으로 초기화된 인스턴스에서 모든 요청을 처리하도록 할 수 있습니다. 프로비저닝된 동시성을 사용하여 구성된 Lambda 함수는 일관된 시작 대기 시간으로 실행되므로, 대화형 모바일 또는 웹 백엔드, 대기 시간에 민감한 마이크로서비스 및 동기식으로 호출되는 API를 구축하는 데 이상적입니다.

참고

프로비저닝된 동시성은 함수의 예약된 동시성 및 리전 할당량에 포함됩니다. 함수의 버전과 별칭에서 프로비저닝된 동시성의 양이 함수의 예약된 동시성까지 더해지면 모든 호출은 프로비저닝된 동시성에서 실행됩니다. 이 구성은 게시되지 않은 버전의 함수($LATEST)를 제한하여 실행을 방지하는 효과가 있습니다. 함수에 대해 예약된 동시성보다 더 많은 프로비저닝된 동시성을 할당할 수 없습니다.

Lambda는 Application Auto Scaling과 통합되어 일정에 따라 또는 사용률을 기준으로 프로비저닝된 동시성을 관리할 수 있습니다.

프로비저닝된 동시성 구성

버전 또는 별칭에 대해 프로비저닝된 동시성 설정을 관리하려면 Lambda 콘솔을 사용합니다. 함수의 버전이나 별칭에서 프로비저닝된 동시성을 구성할 수 있습니다.

함수의 각 버전에는 프로비저닝된 동시성 구성이 하나만 있을 수 있습니다. 이 구성은 버전 자체에서 직접 있거나 버전을 가리키는 별칭에 있을 수 있습니다. 두 별칭은 동일한 버전에 대해 프로비저닝된 동시성을 할당할 수 없습니다.

별칭이 가리키는 버전을 변경하면 Lambda는 프로비저닝된 동시성을 이전 버전에서 할당 해제하고 새 버전에 할당합니다. 프로비저닝된 동시성이 있는 별칭에 라우팅 구성을 추가할 수 있습니다. 자세한 내용은 Lambda 함수 별칭 섹션을 참조하세요. 라우팅 구성이 설정되어 있는 동안에는 별칭에 대해 프로비저닝된 동시성 설정을 관리할 수 없습니다.

참고

게시되지 않은 버전의 함수($LATEST)에서는 프로비저닝된 동시성이 지원되지 않습니다. 프로비저닝된 동시성을 구성하기 전에 클라이언트 애플리케이션이 $LATEST를 가리키지 않는지 확인하세요.

해당 별칭 또는 버전에 프로비저닝된 동시성을 할당하려면
  1. Lambda 콘솔의 함수 페이지를 엽니다.

  2. 함수를 선택합니다.

  3. 구성(Configuration)을 선택한 다음 동시성(Concurrency)을 선택합니다.

  4. 프로비저닝된 동시성 구성(Provisioned concurrency configurations)에서 구성 추가(Add configuration)를 선택합니다.

  5. 별칭 또는 버전을 선택합니다.

  6. 할당할 프로비저닝된 동시성의 양을 입력합니다.

  7. Save를 선택합니다.

다음 작업을 통해 Lambda API를 사용하여 프로비저닝된 동시성을 구성할 수도 있습니다.

함수에 대해 프로비저닝된 동시성을 할당하려면 put-provisioned-concurrency-config를 사용합니다. 다음 명령은 BLUE이라는 함수의 my-function 별칭에 대해 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": "2019-11-21T19:32:12+0000" }

한 리전에서 계정의 동시성 할당량을 보려면 get-account-settings를 사용하세요.

aws lambda get-account-settings

다음 결과가 표시됩니다.

{ "AccountLimit": { "TotalCodeSize": 80530636800, "CodeSizeUnzipped": 262144000, "CodeSizeZipped": 52428800, "ConcurrentExecutions": 1000, "UnreservedConcurrentExecutions": 900 }, "AccountUsage": { "TotalCodeSize": 174913095, "FunctionCount": 52 } }

함수 구성 페이지에서 모든 별칭 및 버전에 대해 프로비전된 동시성을 관리할 수 있습니다. 프로비저닝된 동시성 구성 목록에는 각 구성의 할당 진행률이 표시됩니다. 프로비저닝된 동시성 설정은 각 버전 및 별칭에 대한 구성 페이지에서도 사용할 수 있습니다.

Lambda는 프로비저닝된 동시성에 대해 다음 지표를 내보냅니다.

프로비저닝된 동시성 지표
  • ProvisionedConcurrentExecutions – 프로비저닝된 동시성에서 이벤트를 처리 중인 함수 인스턴스의 개수. 프로비저닝된 동시성이 있는 별칭 또는 버전을 호출할 때마다 Lambda는 현재 개수를 내보냅니다.

  • ProvisionedConcurrencyInvocations – 프로비저닝된 동시성에서 함수 코드가 실행되는 횟수.

  • ProvisionedConcurrencySpilloverInvocations – 모든 프로비저닝된 동시성을 사용 중인 경우, 표준 동시성에서 함수 코드가 실행되는 횟수.

  • ProvisionedConcurrencyUtilization – 버전 또는 별칭의 경우 ProvisionedConcurrentExecutions 값을 할당된 총 프로비저닝된 동시성 양으로 나눈 값. 예를 들어 .5는 할당된 프로비저닝된 동시성의 50%가 사용 중임을 나타냅니다.

자세한 내용은 Lambda 함수 지표 작업 단원을 참조하세요.

프로비저닝된 동시성을 통해 대기 시간 최적화

프로비저닝된 동시성이 구성 직후에 온라인 상태가 되는 것은 아닙니다. Lambda는 1~2분의 준비 시간을 가진 후에 프로비저닝된 동시성 할당을 시작합니다. 함수가 부하에 따른 조정 방식과 마찬가지로 리전에 따라 최대 3000개의 함수 인스턴스를 한 번에 초기화 할 수 있습니다. 초기 버스트 이후 인스턴스는 요청이 이행될 때까지 분당 500의 일정한 속도로 할당됩니다. 동일한 리전에서 여러 함수 또는 함수 버전에 대해 프로비저닝된 동시성을 요청하면 모든 요청에 조정 할당량이 적용됩니다.


      프로비저닝된 동시성을 통해 확장됩니다.
범례
  • 함수 인스턴스

  • 미결 요청

  • 프로비저닝된 동시성

  • 표준 동시성

지연 시간을 최적화하기 위해 프로비저닝된 동시성을 사용하는 함수의 초기화 동작을 사용자 지정할 수 있습니다. 초기화 코드는 할당 시간에 실행되므로 지연 시간에 영향을 주지 않고 프로비저닝된 동시성 인스턴스에 대한 초기화 코드를 실행할 수 있습니다. 그러나 온디맨드 인스턴스의 초기화 코드는 첫 번째 호출의 지연 시간에 직접적인 영향을 미칩니다. 온디맨드 인스턴스의 경우 함수에 특정 기능이 필요할 때까지 해당 기능에 대한 초기화를 연기하도록 선택할 수 있습니다.

초기화 유형을 확인하려면 AAWS_LAMBDA_INITIALIZATION_TYPE의 값을 검사합니다. Lambda는 이 환경 변수를 provisioned-concurrency 또는 on-demand로 설정합니다. AWS_LAMBDA_INITIALIZATION_TYPE의 값은 변경 불가능하며 실행 환경의 수명 동안 변경되지 않습니다.

.NET 3.1 런타임을 사용하는 경우 프로비저닝된 동시성을 사용하는 함수의 지연 시간을 향상시키기 위해 AWS_LAMBDA_DOTNET_PREJIT 환경 변수를 구성할 수 있습니다. .NET 런타임은 코드가 처음으로 호출하는 각 라이브러리를 지연 컴파일하고 초기화합니다. 결과적으로 Lambda 함수의 첫 번째 호출은 후속 호출보다 오래 걸릴 수 있습니다. AWS_LAMBDA_DOTNET_PREJIT를 ProvisionedConcurrency로 설정하면Lambda는 공통 시스템 종속 항목에 대해 Ahead-of-Time JIT 컴파일을 수행합니다. Lambda는 프로비저닝된 동시성 인스턴스에 대해서만 이 초기화 최적화를 수행하므로 첫 번째 호출의 성능이 빨라집니다. 환경 변수를 Always로 설정하면 Lambda는 초기화할 때마다 Ahead-of-Time JIT 컴파일을 수행합니다. 환경 변수를 Never로 설정하면 Ahead-of-Time JIT 컴파일이 비활성화됩니다. AWS_LAMBDA_DOTNET_PREJIT의 기본값은 ProvisionedConcurrency입니다.

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

프로비저닝된 동시성을 사용하여 함수를 최적화하는 방법에 대한 자세한 내용은 Lambda 운영자 가이드를 참조하세요.

Application Auto Scaling으로 프로비저닝된 동시성 관리

Application Auto Scaling을 통해 일정에 따라 또는 사용률을 기준으로 프로비저닝된 동시성을 관리할 수 있습니다. 함수가 지정된 사용률을 유지하고, 최대 트래픽을 예상하여 예약된 크기 조정으로 프로비저닝된 동시성을 증가시키려면 대상 추적 조정 정책을 사용합니다.

대상 추적

대상 추적을 통해 Application Auto Scaling은 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 사용자가 정의하는 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 이는 트래픽이 늘어나는 예약된 시간이 없지만 특정 트래픽 패턴이 있는 애플리케이션에 이상적입니다.

필요에 따라 프로비저닝된 동시성을 자동으로 높이려면 RegisterScalableTargetPutScalingPolicy Application Auto Scaling API 작업을 사용하여 대상을 등록하고 조정 정책을 생성합니다.

  1. 함수의 별칭을 조정 대상으로 등록합니다. 다음 예제에서는 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
  2. 조정 정책을 대상에 적용합니다. 다음 예제에서는 별칭에 대해 프로비저닝된 동시성 구성을 조정하여 사용률을 70% 가까이 유지하도록 Application Auto Scaling을 구성합니다.

    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 대상 추적으로 프로비저닝된 동시성 자동 조정.
범례
  • 함수 인스턴스

  • 미결 요청

  • 프로비저닝된 동시성

  • 표준 동시성

이 두 경보는 모두 기본적으로 평균 통계를 사용합니다. 빠른 버스트의 트래픽 패턴이 있는 함수는 프로비저닝된 동시성을 확장하도록 트리거하지 않을 수 있습니다. 예를 들어 Lambda 함수가 빠르게 실행되고(20~100ms) 트래픽 패턴에서 빠른 버스트가 발생하면, 버스트 중에 들어오는 요청이 할당된 프로비저닝된 동시성을 초과할 수 있지만 버스트가 3분 동안 지속되지 않으면 Auto Scaling이 트리거되지 않습니다. 또한 CloudWatch가 목표 평균에 도달하는 세 개의 데이터 포인트를 얻지 못하면 Auto Scaling 정책이 트리거되지 않습니다.

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

예약된 조정

일정을 기반으로 조정을 수행하면 예측 가능한 로드 변경에 따라 조정 일정을 설정할 수 있습니다. 자세한 정보와 예제를 보려면 반복 피크 사용에 대한 AWS Lambda 프로비저닝된 동시성 예약을 참조하세요.