동시성, 스로틀링 및 예약된 동시성

Lambda는 함수의 동시 실행을 여러 개 수행하는 방식으로 확장합니다. 동시에 발생한 이벤트 하나당 실행 하나가 할당됩니다. 100개의 요청이 동시에 도착하면 Lambda는 함수 인스턴스 100개를 병렬로 실행합니다. 기본 인프라는 AWS가 자동으로 관리합니다. 계정 수준 동시성 제한은 기본적으로 리전당 동시 실행 1,000개입니다(소프트 제한이며 서비스 할당량 요청을 통해 늘릴 수 있습니다).

동시성은 다음과 같이 계산합니다. 동시성 = 초당 요청 수 × 초 단위 평균 처리 시간. 함수가 초당 500개의 요청을 처리하고 각 요청에 0.2초가 걸린다면 동시 실행 100개가 필요합니다. 이 공식을 이해하면 계정 제한이 충분한지, 트래픽이 많은 이벤트 전에 할당량 증가를 요청해야 하는지 예측할 수 있습니다.

Lambda가 동시성 제한을 초과하는 요청을 받으면 초과 요청을 제한합니다. 동기 호출(예: API Gateway)의 경우 제한된 요청에 429 TooManyRequestsException이 즉시 반환되며, 호출자가 이를 처리해야 합니다. 비동기 호출(예: S3 이벤트)의 경우 Lambda가 이벤트를 대기열에 넣고 최대 6시간 동안 재시도한 후 배달 못한 편지 대기열로 보냅니다.

예약된 동시성은 특정 함수에 대해 정해진 수의 동시 실행을 보장하고, 해당 실행 수를 계정 풀에서 예약합니다. 여기에는 두 가지 목적이 있습니다. (1) 용량을 보장합니다. 다른 함수가 계정 할당량을 사용하더라도 해당 함수에는 항상 그만큼의 실행 용량이 제공됩니다. (2) 동시성을 제한합니다. 함수가 예약된 수를 절대 초과하지 않으므로 다운스트림 의존성이 과부하되는 것을 방지합니다.

시험에 자주 나오는 핵심 상황을 살펴보겠습니다. Lambda 함수가 연결 제한이 50개인 RDS 데이터베이스에 씁니다. 동시성 제어가 없으면 Lambda가 수백 개의 동시 실행으로 확장되어 모든 데이터베이스 연결을 소진할 수 있고, 그 결과 모든 함수에서 오류가 발생할 수 있습니다. 예약된 동시성을 40으로 설정하면 Lambda가 동시에 사용하는 데이터베이스 연결 수가 40개를 넘지 않으므로 RDS 인스턴스를 보호할 수 있습니다. 이는 연결 수가 제한된 서비스를 호출하는 모든 Lambda 함수에 중요한 패턴입니다.

프로비저닝된 동시성은 지정된 수의 Lambda 실행 환경을 미리 초기화하여 콜드 스타트 없이 즉시 응답할 수 있도록 합니다. 콜드 스타트가 100ms만 발생해도 허용하기 어려운 지연 시간 민감형 API에서 특히 중요합니다. 프로비저닝된 동시성은 해당 환경이 유휴 상태일 때도 시간당 요금이 부과되므로, 예측한 트래픽 패턴에 따라 프로비저닝 수준을 조정하도록 자동 확장과 함께 사용하십시오.

두 기능은 자주 혼동되지만 목적이 다릅니다. 예약된 동시성은 계정 풀에서 할당되는 용량을 제한하고 보장하지만 콜드 스타트를 제거하지는 않습니다. 프로비저닝된 동시성은 실행 환경을 미리 준비하여 콜드 스타트를 제거하지만 다른 함수가 동일한 풀을 사용하는 것을 막지는 않습니다. 처리량을 제한하려면 예약된 동시성을 사용하고, 지연 시간을 개선하려면 프로비저닝된 동시성을 사용하십시오. 두 기능은 동일한 함수에서 함께 사용할 수 있습니다.

Lambda는 동시성 전체를 순간적으로 확장하지 않습니다. 계정 수준의 급증 제한(초기 확장 속도)이 있으며, 이 값은 리전에 따라 다릅니다. 일반적으로 초기 급증은 3,000개이고, 이후 제한에 도달할 때까지 분당 500개의 실행이 추가됩니다. 갑작스럽고 큰 폭의 증가(바이럴 트래픽, 한정 판매)가 예상되는 애플리케이션에서는 프로비저닝된 동시성을 사용해 충분한 환경을 미리 준비하십시오. 그러면 초기 급증 중 급증 제한으로 인해 요청이 제한되는 일을 방지할 수 있습니다.

다음과 같은 주요 CloudWatch 지표를 사용하여 Lambda 동시성을 모니터링하십시오.

• ConcurrentExecutions: 현재 실행 중인 인스턴스 수
• Throttles: 제한된 호출 수(정상적인 시스템에서는 0이어야 함)
• UnreservedConcurrentExecutions: 계정 수준에서 예약되지 않은 풀
• ProvisionedConcurrencyUtilization: 사용 중인 프로비저닝된 용량의 비율

제한이 최종 사용자에게 영향을 미치기 전에 알림을 받도록 Throttles에 경보를 설정하십시오.

Lambda를 동기 방식으로 호출하는 시스템(API Gateway, SDK 직접 호출)을 설계할 때는 호출자에 지수 백오프와 지터를 구현하십시오. AWS SDK에는 재시도 로직이 내장되어 있지만, API Gateway 앞단의 Lambda에서는 클라이언트 애플리케이션이 429 응답을 직접 처리해야 합니다. SQS가 트리거하는 Lambda의 경우 SQS 서비스 자체가 재시도를 처리합니다. 소스 대기열에서 Maximum Receives를 적절히 설정하고, 재시도를 모두 소진했을 때 사용할 DLQ를 구성하십시오.

Kinesis Data Streams와 DynamoDB Streams에서는 Lambda 동시성이 샤드(Kinesis) 또는 파티션(DynamoDB)의 수에 의해 제한됩니다. 각 샤드 또는 파티션은 정확히 하나의 동시 Lambda 실행이 처리합니다. Kinesis 샤드가 10개라면 Lambda는 해당 트리거에 대해 최대 10개의 동시 실행을 수행합니다. 따라서 스트림 기반 트리거의 제한 문제는 일반적으로 동시성 제한을 늘리기보다 샤드 수를 늘려 해결합니다.

이 단원에서 배운 AWS 솔루션스 아키텍트(SAA-C03) 개념을 이해했는지 확인해 보십시오.

이 단원에서는 다음을 배웠습니다. 예약된 동시성은 함수의 동시 실행을 보장하고 제한하여 다운스트림 서비스를 보호하고 가용성을 확보합니다. 프로비저닝된 동시성은 환경을 미리 초기화하여 지연 시간 민감형 작업에서 콜드 스타트를 제거합니다. 또한 제한은 동기 호출에서는 429 오류로 나타나고 비동기 호출에서는 대기열에 저장된 재시도로 나타나므로, Throttles CloudWatch 지표를 사용해 모니터링해야 합니다. 다음 단원에서는 대규모 의존성을 관리하기 위한 Lambda 레이어와 배포 패키지를 살펴봅니다.