[AWS LAMBDA] 동시성 설정 및 오토스케일링 적용하기

안녕하세요?
곰군 입니다.

오늘은 클라우드 환경에서 서버리스 아키텍처의 대표적인 서비스 중 하나인 AWS Lambda에 관한 이야기를 해보려 합니다.
현대의 비지니스 환경에서는 응답시간이 매우 중요합니다. 사용자들은 서비스를 이용할 때 빠른 반응성을 기대하기 때문에, 느린 로딩 시간이나 응답 지연은 곧 사용자의 만족도 하락으로 이어질 수 있습니다. 이러한 문제 중 하나가 AWS Lambda에서 자주 발생하는 ‘콜드스타트’입니다.

콜드스타트는 람다 함수가 최초 실행될 때나 일정 시간 동안 호출되지 않아 종료된 후 재실행될 때 발생합니다. 이로 인해 사용자의 요청에 대한 응답이 지연될 수 있으므로, 이를 최소화하는 방법을 찾는 것은 중요한 과제입니다.

또한, 서비스 트레픽은 항상 일정하지 않습니다. 프로모션, 이벤트, 계절적 변동 등 다양한 요인에 따라 트레픽의 변동이 크게 발생할 수 있기 때문에, 이에 효과적으로 대응하기 위해서는 AWS Lambda의 오토스케일링 기능을 적절히 활용해야 합니다. 오토스케일링을 통해 자동으로 리소스를 조절하면 서비스 품질을 유지하면서 비용을 최적화할 수 있습니다.

본 글에서는 AWS Lambda의 동시성 설정과 오토스케일링 적용 방법을 통해 콜드스타트 문제를 최소화하고, 트레픽 변동에 따른 스케일링을 효율적으로 관리하는 방법에 대해 알아보겠습니다. 이를 통해 비지니스 환경에서의 응답시간 개선과 비용 최적화에 대한 인사이트를 제공하고자 합니다.

 

Lambda 프로비저닝된 동시성이란?

 Lambda 프로비저닝된 동시성 (Provisioned Concurrency)은 AWS Lambda에서 제공하는 기능으로, 사용자가 특정 수의 람다 함수 인스턴스(실행환경)를 미리 “예약”하여, 이벤트 호출 시 즉시 사용 가능하게 할 수 있습니다. 이는 Lambda 함수의 “콜드 스타트” 지연 시간을 거의 제거하여, 함수가 처음 호출될 때 발생할 수 있는 추가 대기 시간 없이 즉시 응답하게 합니다.

콜드 스타트는 무엇인가요?

Lambda는 상시 프로비져닝 되어있는 인스턴스가 아니라 작업이 없을 때에는 실행환경을 미리 준비해 두지 않습니다. 그래서 일정시간(대략 3~5분)동안 미작업 이후 람다를 호출하면 새로운 실행환경을 만들기 위해 람다가 코드를 다운하고 메모리, 런타임 등을 구성하고, 전역 코드를 실행하는 등의 준비 단계를 거치는데 이러한 준비부터 실행까지 이뤄지는 것을 Cold Start라고 부릅니다. 반대로 이미 실행환경은 준비되어있고, 코드만 다시 실행하는 것은 Warm Start라고 부릅니다. 콜드 스타트는 실제 운영 환경에서는 응답 시간에 영향을 주기 때문에 비즈니스나 워크로드에 따라 관리되어야 합니다.

동시성 설정 방법

1. 람다 코드의 새 버전을 발행
* 버전은 현재의 코드와 구성을 스냅샷으로 저장하는 것으로 버전을 설정해야 동시성 설정이 가능합니다.

* API 게이트웨이 변경이나 오토스케일링 적용이 필요하면 별칭을 생성합니다.
– 버전으로 동시성을 적요할 경우 호출 시 버전을 명시해야 해서 버전 변경 시마다 호출 부분의 변경이 필요합니다. 별칭을 구성하여 동시성을 적용하면 API 게이트웨이 변경이 필요 없고, 가중치 및 오토스케일링 설정이 가능하기 때문에 별칭을 구성하여 동시성을 적용하는 것을 추천합니다.

2. 동시성을 설정.

  구성(Configuration) 탭에 동시성(Provisioned Concurrency) 매뉴에서 동시설을 설정할 수 있습니다. 특정 Lambda 함수 버전 또는 별칭에 대해 동시성(Provisioned Concurrency)를 활성화할 수 있습니다($LATEST 사용 불가). 함수의 각 버전에 서로 다른 설정을 적용할 수 있습니다. 별칭을 사용하는 경우 이러한 설정을 해당하는 버전의 함수에 대해 활성화하기가 더 쉽습니다.

* 동시성을 예측하는 방법
(https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)

가. Invocation과 Duration으로 계산한다.
Concurrency = (average requests per second) * (average request duration in seconds)
초당 평균 요청에 평균 요청 기간(초)을 곱하면 예약해야 하는 동시성 양을 대략적으로 추정할 수 있습니다. 호출 지표를 사용하면 초당 평균 요청 수를 추정할 수 있고 기간 지표를 사용하면 평균 요청 기간(초)을 추정할 수 있습니다. 프로비저닝된 동시성을 사용하여 작업할 때 Lambda는 함수에 일반적으로 필요한 동시성 양 외에 10% 버퍼를 포함할 것을 제안합니다. 예를 들어 함수가 일반적으로 동시 요청 200개로 최대치를 기록한다면 프로비저닝된 동시성을 220으로 설정하십시오(동시 요청 200개 + 10% = 프로비저닝된 동시성 220개)..

나. CW의 ConcurrenExecutions 지표를 확인한다.

3. 람다 로그 확인

해당 람다의 모니터링- 로그 내용을 확인해서 작업한 버전으로 작업이 진행되는지 확인하면 동시성 적용이 잘되었는 확인할 수 있습니다.

Application Auto Scaling 적용하기

AWS Lambda는 서버리스 아키텍처에서 중요한 역할을 하며, Lambda의 동시성 기능은 빠른 응답 속도와 고성능을 제공해 주는 데 큰 장점이 있습니다. 그렇다면 왜 모든 사용자가 이 동시성을 최대한 활용하지 않을까요? 동시성에는 두 가지 제약 사항이 있습니다.

1. 제한량: AWS는 Lambda 함수에 대한 동시성 설정 수에 제한을 둡니다. 기본 제한량은 한 계정당 1,000개입니다. 이 제한량은 확장이 가능하지만, 무제한으로 증가시킬 수는 없습니다. 이러한 제한은 AWS 리소스를 효과적으로 관리하기 위한 방법 중 하나입니다.
2. 비용: 동시성을 높이면 사용되는 리소스와 비용도 증가합니다. 2023년 기준으로, x86 아키텍처의 경우 GB-초당 비용은 0.0000051254, Arn의 경우는 GB-초당 0.0000041003입니다. 따라서 동시성을 많이 사용할수록 비용이 급증하므로, 성능 대비 비용의 효율성을 꼭 검토해야 합니다.

외부 트래픽은 시시각각 변하며 예측이 어려울 수 있습니다. 이러한 트래픽의 변동성을 고려하여 동시성을 효율적으로 관리하려면:

• 스케일링: 실시간 트래픽 변동에 따라 동시성을 동적으로 조절하는 것이 중요합니다.
• 스케줄링: 정기적인 트래픽 패턴이 예측된다면, 스케줄링을 통해 미리 동시성을 조절할 수 있습니다.

AWS Lambda의 동시성은 매우 강력한 기능이지만, 그에 따른 제약 사항과 비용을 올바르게 고려하며 관리하는 것이 중요합니다.

Application Auto Scaling을 사용  하면 Lambda에 대한 프로비저닝된 동시성을 포함하여 다양한 리소스에 대한 자동 조정을 구성할 수 있습니다. 특정 CloudWatch 지표를 기반으로 하거나 특정 날짜 및 시간에 리소스를 확장할 수 있습니다. Application Auto Scaling에는 추가 비용이 없으며 사용한 리소스에 대해서만 비용을 지불하면 됩니다. 

스케일링
대상 추적(스케일링)을 사용하여 프로비저닝된 동시성을 확장하려면 RegisterScalableTarget및 PutScalingPolicy Application Auto Scaling API 작업을 사용하십시오.

1. RegisterScalableTarget 등록하기
   람다 명과 별칭, 최소/최대 동시성을 등록한다.

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. PutScalingPolicy 등록하기
           람다 명과 별칭, 정책명, 확장임계치를 설정합니다.

하기 예제 코드는 사용율이 70%에 가깝게 동시성을 유지하는 예제입니다.

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" }}'

해당 정책을 등록하게 되면 Cloudwatch에 해당 정책에 대한 ProvisionedConcurrencyUtilization High/Low 경보가 등록됩니다. 해당 경보에서 임계치 및 기간에 대한 내용 확인 및 수정이 가능합니다. 기민하게 확장이 필요할 경우 임계값을 조정하여 빠른 스케일링을 지정할 수 있으며, 반대의 경우 여유롭게 설정할 수 있습니다.

스케쥴링

 트레픽이 예상되거나 이벤트 등이 예정되어 있는 경우에는 스케쥴링이 효과적 입니다. 동시성에 대한 스케쥴링은Application Auto Scaling의 PutScheduledAction API를 사용하여 프로비저닝된 동시성을 예약할 수 있습니다. 하기 예제는 UTC(협정 세계시)를 기준으로 매일 11시 45분에 최소 동시성을 250으로 증가시키는 작업을 실행하도록 스케줄링합니다.

$ aws application-autoscaling put-scheduled-action --service-namespace lambda \

--scalable-dimension lambda:function:ProvisionedConcurrency \

--resource-id function:CreateOrder:prod \

--scheduled-action-name scale-out \

--schedule "cron(45 11 * * ? *)" \

--scalable-target-action MinCapacity=250

이벤트가 종료될 시점이 정해져 있으면 확장되어있는 동시성을 정리할 수 있습니다. 하기 예제는UTC(협정 세계시)를 기준으로 매일 13시 15분에 동시성을 정리합니다.

$ aws application-autoscaling put-scheduled-action --service-namespace lambda \

--scalable-dimension lambda:function:ProvisionedConcurrency \

--resource-id function:CreateOrder:prod \

--scheduled-action-name scale-in \

--schedule "cron(15 13 * * ? *)" \

--scalable-target-action MinCapacity=0,MaxCapacity=0

상기와 같은 방식으로 스케쥴링과 스케일링을 적절하게 사용하면 콜드스타트 문제를 최소화하고, 트레픽 변동에 따른 스케일링을 비용 효율적으로 관리할 수 있습니다.