Lambda Managed Instances 확장

Lambda Managed Instances는 호출이 도착할 때 확장되지 않으며 콜드 스타트를 지원하지 않아요. 대신 리소스 소비 신호를 사용해서 비동기적으로 확장해요. Managed Instances는 현재 CPU 리소스 사용률과 다중 동시성 포화도(multi-concurrency saturation)에 따라 확장돼요.

주요 차이점:

Lambda(기본값): 들어오는 호출을 처리할 여유 실행 환경이 없을 때 확장해요(콜드 스타트)
Lambda Managed Instances: 실행 환경의 CPU 리소스 사용률과 다중 동시성 포화도에 따라 비동기적으로 확장해요

트래픽이 5분 내에 두 배 이상 증가하면 Lambda가 수요를 충족하기 위해 인스턴스와 실행 환경을 확장하는 동안 스로틀(throttle)이 발생할 수 있어요.

출처: AWS Lambda 개발자 안내서

본문

확장 라이프사이클

Lambda Managed Instances는 분산 아키텍처를 사용해서 확장을 관리해요.

구성 요소:

Managed Instances - 사용자가 제공한 서브넷에서 사용자 계정으로 실행돼요
Router and Scaler - 호출을 라우팅하고 확장을 관리하는 공유 Lambda 구성 요소예요
Lambda Agent - 각 Managed Instance에서 실행되어 실행 환경 라이프사이클을 관리하고 리소스 소비를 모니터링해요

작동 방식:

용량 공급자(capacity provider)와 함께 함수 버전을 게시하면 Lambda가 사용자 계정에 Managed Instances를 시작해요. AZ 복원력을 위해 기본적으로 3개를 시작하고, 함수 버전을 ACTIVE로 표시하기 전에 세 개의 실행 환경을 시작해요.
각 Managed Instance는 같은 용량 공급자에 매핑된 여러 함수의 실행 환경을 실행할 수 있어요.
트래픽이 애플리케이션으로 흐르면 실행 환경이 리소스를 소비해요. Lambda Agent가 Scaler에 알리고 Scaler는 새 실행 환경이나 Managed Instances를 확장할지 결정해요.
Router가 리소스 소비가 높은 실행 환경에 호출을 보내려고 하면 해당 인스턴스의 Lambda Agent가 다른 환경에서 재시도하도록 알려요.
트래픽이 감소하면 Lambda Agent가 Scaler에 알리고 Scaler는 실행 환경을 축소하고 Managed Instances를 축소하기로 결정해요.

확장 동작 조정

다섯 가지 제어를 통해 Managed Instances의 확장 동작을 사용자 지정할 수 있어요.

함수 수준 제어

1. 함수 메모리 및 vCPU

함수의 메모리 크기와 vCPU 할당을 선택해요. 지원되는 가장 작은 함수 크기는 2GB와 1vCPU예요.

고려 사항:

함수의 다중 동시 실행을 지원하는 메모리와 vCPU 설정을 선택해요
Managed Instances에서 실행되는 함수는 다중 동시 워크로드를 지원해야 하므로 1vCPU 미만으로는 함수를 구성할 수 없어요
2GB 미만은 선택할 수 없어요. 이는 가장 낮은 비율을 가진 c 인스턴스의 2:1 메모리-대-vCPU 비율과 일치하기 때문이에요
Python 애플리케이션의 경우 Python이 다중 동시성을 처리하는 방식 때문에 4:1이나 8:1 같은 더 높은 메모리-대-vCPU 비율을 선택해야 할 수 있어요
CPU 집약적 작업을 실행하거나 IO가 적다면 vCPU를 두 개 이상 선택해야 해요

2. 최대 동시성

실행 환경당 최대 동시성을 설정해요.

기본 동작: Lambda는 다양한 애플리케이션에서 잘 작동하는 리소스 소비와 처리량의 균형을 맞춘 합리적인 기본값을 선택해요.

조정 지침:

동시성 증가: 함수 호출이 CPU를 거의 사용하지 않는다면 vCPU당 최대 64까지 최대 동시성을 높일 수 있어요
동시성 감소: 애플리케이션이 많은 메모리를 소비하고 CPU를 거의 사용하지 않는다면 최대 동시성을 줄일 수 있어요

중요: Lambda Managed Instances는 다중 동시 애플리케이션을 위한 것이므로 동시성이 매우 낮은 실행 환경은 확장 시 스로틀이 발생할 수 있어요. 호출이 동시성 한도에 도달한 실행 환경에 도착하면 Lambda는 해당 호출을 다른 곳으로 라우팅하고 로드를 처리하기 위해 새 실행 환경을 확장해요. 스로틀을 유발하는 리소스 제약을 식별하려면 Lambda 함수 지표 유형에 설명된 스로틀 사유 지표(ConcurrencyThrottles, CPUThrottles, MemoryThrottles, DiskThrottles)를 모니터링하세요.

3. 함수별 실행 환경

함수의 최소·최대 실행 환경 수를 설정해요.

기본 동작: 기본 최소값은 가용 영역(Availability Zones)에 걸쳐 실행 환경 3개이며, 기본 최대값은 없어요. 함수를 만든 후 두 값을 모두 재정의할 수 있어요.

조정 지침:

최소값 설정: 기준 트래픽에 대한 용량을 프로비저닝하고 갑작스러운 급증 중 스로틀을 줄여요. 3 미만의 값은 가용 영역 중복성을 줄여요.
최대값 설정: 실행 환경 수를 제한해서 스케일아웃을 제어하고 여러 함수가 용량 공급자를 공유할 때 노이지 네이버(noisy neighbor) 문제를 방지해요.
함수 비활성화: 최소값과 최대값을 모두 0으로 설정해서 함수를 삭제하지 않고 비활성화해요.

예시:

aws lambda put-function-scaling-config \
  --function-name my-lmi-function \
  --qualifier '$LATEST.PUBLISHED' \
  --function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=20 \
  --region us-east-1

중요 사항:

Qualifier 범위: 이러한 구성은 각 정규화된 ARN의 함수 수준에 적용돼요. $LATEST.PUBLISHED에 설정하면 구성이 향후 $LATEST.PUBLISHED 버전으로 전파돼요. 특정 버전에 설정하면 새로 게시되는 버전은 기본값으로 되돌아가요.
쌍 구성: 최소값과 최대값을 함께 설정해야 해요. 지정하지 않은 설정은 기본값으로 되돌아가요. MinExecutionEnvironments와 MaxExecutionEnvironments 모두 유효값 범위는 0~15000이에요. 최소값 0은 최대값도 0일 때만 유효해요.
비용 영향: 함수 비활성화는 함수 버전 수준에서 적용돼요. Lambda는 활성 실행 환경이 없으면 기본 EC2 인스턴스를 종료하며, 인스턴스 요금은 종료가 완료될 때까지(보통 몇 분 내) 계속 부과돼요.

용량 공급자 수준 제어

4. 대상 리소스 사용률

CPU 사용률 소비에 대한 자체 목표를 선택해요.

기본 동작: Lambda는 스로틀 없이 5분 내에 트래픽이 두 배로 늘어날 수 있도록 충분한 헤드룸(headroom)을 유지해요.

최적화 옵션:

워크로드가 매우 안정적이거나 애플리케이션이 스로틀에 민감하지 않다면 높은 수준으로 목표를 설정해서 더 높은 사용률과 더 낮은 비용을 달성할 수 있어요
트래픽 급증을 위한 헤드룸을 유지하려면 리소스 목표를 낮게 설정할 수 있으며, 이는 더 많은 용량을 필요로 해요

5. 인스턴스 유형 선택

허용되거나 제외되는 인스턴스 유형을 설정해요.

기본 동작: Lambda가 워크로드에 가장 적합한 인스턴스 유형을 선택해요. 가능한 인스턴스 유형 수를 제한하면 가용성이 낮아질 수 있으므로 Lambda Managed Instances가 인스턴스 유형을 선택하게 하는 것을 권장해요.

사용자 지정 구성:

특정 하드웨어 요구 사항: 허용 인스턴스 유형을 호환 가능한 인스턴스 목록으로 설정해요. 예를 들어 높은 네트워크 대역폭이 필요한 애플리케이션이라면 여러 n 인스턴스 유형을 선택할 수 있어요
비용 최적화: 테스트·개발 환경의 경우 m7a.large 같은 더 작은 인스턴스 유형을 선택할 수 있어요

예약 확장(Scheduled scaling)

Amazon EventBridge Scheduler를 사용해서 함수의 최소·최대 실행 환경을 반복 또는 일회성 일정으로 조정해요. 이는 피크 시간 전 확장, 비피크 시간에 축소 같은 예측 가능한 트래픽 패턴에 유용해요.

스케줄러 구성:

대상 함수에서 lambda:PutFunctionScalingConfig 호출 권한을 부여하는 EventBridge Scheduler 실행 역할을 만들거나 기존 역할을 사용해요.
cron 또는 rate 표현식을 사용해 일정을 만들고, 범용 대상으로 PutFunctionScalingConfig API를 타깃으로 해요. Input 페이로드에 새 MinExecutionEnvironments와 MaxExecutionEnvironments 값을 지정해요.

예시 1: 계획된 피크 트래픽을 처리하도록 확장

피크 시간 전에 확장하고 이후에 축소하는 두 개의 일정을 만들어요. 각 일정은 업데이트된 MinExecutionEnvironments와 MaxExecutionEnvironments 값으로 PutFunctionScalingConfig API를 타깃으로 해요.

오전 8:00 UTC에 확장(min=100, max=1000):

aws scheduler create-schedule \
  --name "ScaleUpLambdaManagedInstances" \
  --schedule-expression "cron(0 8 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 100, \"MaxExecutionEnvironments\": 1000}}"
  }'

오후 6:00 UTC에 축소(min=5, max=20):

aws scheduler create-schedule \
  --name "ScaleDownLambdaManagedInstances" \
  --schedule-expression "cron(0 18 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 5, \"MaxExecutionEnvironments\": 20}}"
  }'

예시 2: 비피크 시간에 비활성화하고 재활성화

MinExecutionEnvironments와 MaxExecutionEnvironments를 모두 0으로 설정하면 함수 버전을 삭제하지 않고 비활성화해요. 비활성화된 함수는 트래픽에 따라 자동으로 다시 확장되지 않아요. 또 다른 예약 작업을 통해 0이 아닌 값을 설정해서 명시적으로 재활성화해야 해요.

오후 10:00 UTC에 비활성화(min=0, max=0):

aws scheduler create-schedule \
  --name "DeactivateLambdaManagedInstances" \
  --schedule-expression "cron(0 22 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 0, \"MaxExecutionEnvironments\": 0}}"
  }'

오전 7:00 UTC에 재활성화(min=10, max=20):

aws scheduler create-schedule \
  --name "ReactivateLambdaManagedInstances" \
  --schedule-expression "cron(0 7 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 10, \"MaxExecutionEnvironments\": 20}}"
  }'

조정 지침:

예측 가능한 피크가 있는 워크로드의 경우 트래픽 패턴에 맞게 여러 일정을 만드세요. 하나는 피크 시간 전에 함수를 확장하고 다른 하나는 피크 시간 후에 축소하세요. 각 일정은 업데이트된 MinExecutionEnvironments와 MaxExecutionEnvironments 값으로 동일한 패턴을 따라요.
예약 확장은 실행 환경의 프로비저닝된 하한과 상한을 조정하지만, 최소와 최대 사이의 실제 확장은 여전히 CPU 사용률과 동시성 포화도에 응답해요.
예약 확장 후 5분 내에 트래픽이 두 배 이상 증가하면 용량이 프로비저닝되는 동안 스로틀이 발생할 수 있어요.
함수를 비활성화하기 위해 0으로 확장할 때는 재활성화에 0이 아닌 값을 가진 명시적 PutFunctionScalingConfig 호출이 필요하다는 점을 기억하세요.

다음 단계

Lambda Managed Instances용 용량 공급자에 대해 알아보기
다중 동시성 처리를 위한 런타임별 가이드 검토
용량 공급자의 VPC 연결 구성
확장 동작을 최적화하기 위해 확장 지표 모니터링

더 알아보기 (Learn more)

Lambda Managed Instances에 대한 자세한 내용은 Lambda Managed Instances를 참고하세요.