Lambda 함수 규모 조정 이행

동시성은 AWS Lambda 함수가 동시에 처리하는 전송 중인 요청 수입니다. 각 동시 요청마다 Lambda는 실행 환경의 개별 인스턴스를 프로비저닝합니다. 함수가 요청을 더 많이 수신하면 Lambda는 사용자가 계정의 동시성 한도에 도달할 때까지 실행 환경 수를 자동으로 조정합니다. 기본적으로 Lambda는 사용자 계정에 AWS 리전 내 모든 함수에 걸쳐 총 1,000개 동시 실행 한도의 동시성을 제공합니다. 특정 계정 요구 사항을 지원하기 위해, 할당량 증대를 요청하고 함수 수준의 동시성 제어를 구성하여 중요한 함수에 대해 제한이 발생하지 않도록 할 수 있습니다.

이 주제에서는 Lambda의 동시성 개념과 함수 스케일 인에 대해 설명합니다. 이 주제를 마치면 동시성을 계산하고, 두 가지 주요 동시성 제어 옵션(예약 및 프로비저닝)을 시각화하고, 적절한 동시성 제어 설정을 추정하며, 추가 최적화를 위한 지표를 보는 방법을 이해할 수 있습니다.

Sections

• 동시성 이해 및 시각화
• 함수의 동시성 계산
• 예약된 동시성 및 프로비저닝된 동시성 이해
• 동시성과 초당 요청 수에 대한 이해
• 동시성 할당량
• 함수에 대해 예약된 동시성 구성
• 함수에 대해 프로비저닝된 동시성 구성
• Lambda 조정 동작
• 동시성 모니터링

동시성 이해 및 시각화

Lambda는 안전하고 격리된 실행 환경에서 함수를 호출합니다. 요청을 처리하려면 Lambda가 실행 환경을 사용하여 함수를 호출(호출 단계)하기 전에 먼저 실행 환경을 초기화(초기화 단계)해야 합니다 .

참고

실제 초기화 및 호출 지속 시간은 선택한 런타임 및 Lambda 함수 코드와 같은 여러 요인에 따라 달라질 수 있습니다. 위 다이어그램은 초기화 및 호출 단계 지속 시간의 정확한 비율을 보여주기 위한 것이 아닙니다.

위 다이어그램에서는 사각형을 사용하여 단일 실행 환경을 나타냅니다. 함수가 첫 번째 요청(1 레이블이 있는 노란색 원으로 표시됨)을 수신하면 Lambda는 새 실행 환경을 생성하고 초기화 단계 중에 기본 핸들러 외부에서 코드를 실행합니다. 그런 다음 Lambda는 호출 단계에서 함수의 기본 핸들러 코드를 실행합니다. 이 전체 프로세스를 실행하는 동안 이 실행 환경은 사용량이 많아 다른 요청을 처리할 수 없습니다.

Lambda가 첫 번째 요청 처리를 마치면 이 실행 환경에서 동일한 함수에 대한 추가 요청을 처리할 수 있습니다. 후속 요청을 처리하기 위해 Lambda는 환경을 다시 초기화할 필요가 없습니다.

이전 다이어그램에서 Lambda는 실행 환경을 재사용하여 두 번째 요청(2 레이블이 있는 노란색 원으로 표시됨)을 처리합니다.

지금까지는 실행 환경의 단일 인스턴스(즉, 동시성 1)에만 초점을 맞췄습니다. 실제 환경에서 Lambda는 들어오는 모든 요청을 처리하기 위해 여러 실행 환경 인스턴스를 병렬로 프로비저닝해야 할 수 있습니다. 함수가 새 요청을 받으면 다음 두 가지 중 하나가 발생할 수 있습니다.

• 사전 초기화된 실행 환경 인스턴스를 사용할 수 있는 경우 Lambda는 이를 사용하여 요청을 처리합니다.

• 그렇지 않으면 Lambda는 요청을 처리하기 위해 새 실행 환경 인스턴스를 생성합니다.

예를 들어 함수가 10개의 요청을 수신하면 어떻게 되는지 살펴보겠습니다.

위 다이어그램에서 각 수평면은 단일 실행 환경 인스턴스(A~F의 레이블로 표시됨)를 나타냅니다. Lambda가 각 요청을 처리하는 방법은 다음과 같습니다.

요청	Lambda 동작	추론
1	새로운 환경 A 프로비저닝	첫 번째 요청, 사용 가능한 실행 환경 인스턴스가 없습니다.
2	새로운 환경 B 프로비저닝	기존 실행 환경 인스턴스 A가 사용 중입니다.
3	새로운 환경 C 프로비저닝	기존 실행 환경 인스턴스 A 및 B가 모두 사용 중입니다.
4	새로운 환경 D 프로비저닝	기존 실행 환경 인스턴스 A, B 및 C가 모두 사용 중입니다.
5	새로운 환경 E 프로비저닝	기존 실행 환경 인스턴스 A, B, C 및 D가 모두 사용 중입니다.
6	환경 A 재사용	실행 환경 인스턴스 A가 요청 1의 처리를 완료했으며 이제 사용 가능한 상태입니다.
7	환경 B 재사용	실행 환경 인스턴스 B가 요청 2의 처리를 완료했으며 이제 사용 가능한 상태입니다.
8	환경 C 재사용	실행 환경 인스턴스 C가 요청 3의 처리를 완료했으며 이제 사용 가능한 상태입니다.
9	새로운 환경 F 프로비저닝	기존 실행 환경 인스턴스 A, B, C, D 및 E가 모두 사용 중입니다.
10	환경 D 재사용	실행 환경 인스턴스 D가 요청 4의 처리를 완료했으며 이제 사용 가능한 상태입니다.

함수가 더 많은 동시 요청을 수신함에 따라 Lambda는 이에 대응하여 실행 환경 인스턴스의 수를 늘립니다. 다음 애니메이션에서는 시간 경과에 따른 동시 요청 수를 추적합니다.

이전 애니메이션을 서로 다른 여섯 개 시점에서 고정하면 다음과 같은 다이어그램을 얻을 수 있습니다.

이전 다이어그램에서는 어느 지점에서든 수직선을 그리고 이 선과 교차하는 환경의 수를 계산할 수 있습니다. 이를 통해 해당 시점의 동시 요청 수를 알 수 있습니다. 예를 들어 t1 시점에는 세 개의 동시 요청을 처리하는 세 개의 활성 환경이 있습니다. 이 시뮬레이션의 최대 동시 요청 수는 활성 환경 여섯 개에서 여섯 개의 동시 요청을 처리하는 t4 시점에 발생합니다.

한마디로, 함수의 동시성은 동시에 처리하는 동시 요청의 수입니다. 함수의 동시성이 증가함에 따라 Lambda는 요청 수요를 충족하기 위해 더 많은 실행 환경 인스턴스를 프로비저닝합니다.

함수의 동시성 계산

일반적으로 시스템의 동시성은 둘 이상의 작업을 동시에 처리할 수 있는 능력입니다. Lambda에서 동시성은 함수가 동시에 처리하는 전송 중인 요청의 수입니다. Lambda 함수의 동시성을 측정하는 빠르고 실용적인 방법은 다음 수식을 사용하는 것입니다.

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

동시성은 초당 요청 수와 다릅니다. 예를 들어 함수가 초당 평균 100개의 요청을 수신한다고 가정해 보겠습니다. 평균 요청 지속 시간이 1초인 경우에는 동시성도 100입니다.

Concurrency = (100 requests/second) * (1 second/request) = 100

하지만 평균 요청 지속 시간이 500ms인 경우에는 그럼 동시성은 50입니다.

Concurrency = (100 requests/second) * (0.5 second/request) = 50

50이라는 동시성은 실제로 무엇을 의미할까요? 평균 요청 지속 시간이 500ms인 경우 그럼 함수 인스턴스가 초당 두 개의 요청을 처리할 수 있다고 생각할 수 있습니다. 그러면, 초당 100개의 요청 로드를 처리하려면 함수의 인스턴스가 50개 필요합니다. 동시성이 50이라는 것은 Lambda가 제한 없이 이 워크로드를 효율적으로 처리하기 위해서는 50개의 실행 환경 인스턴스를 프로비저닝해야 한다는 것을 의미합니다. 이를 방정식 형식으로 표현하면 다음과 같습니다.

Concurrency = (100 requests/second) / (2 requests/second) = 50

함수가 두 배의 요청 수(초당 200개 요청)를 수신하지만 각 요청을 처리하는 데 걸리는 시간이 절반인 경우(250ms) 그럼 동시성은 여전히 50입니다.

Concurrency = (200 requests/second) * (0.25 second/request) = 50

동시성에 대한 이해도 테스트

실행하는 데 평균 200ms가 걸리는 함수가 있다고 가정해 보겠습니다. 최대 부하에서는 초당 5,000개의 요청이 관찰됩니다. 최대 부하 시 함수의 동시성은 얼마일까요?

정답

평균 함수 지속 시간은 200밀리초, 즉 0.2초입니다. 동시성 수식을 사용하여 숫자를 대입하면 1,000이라는 동시성을 구할 수 있습니다.

Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000

다르게 표현하면, 평균 함수 지속 시간이 200ms이면 함수에서 초당 5개의 요청을 처리할 수 있습니다. 초당 5,000개의 요청 워크로드를 처리하려면 1,000개의 실행 환경 인스턴스가 필요합니다. 따라서 동시성은 1,000입니다.

Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000

예약된 동시성 및 프로비저닝된 동시성 이해

기본적으로 리전 내 모든 함수에 걸쳐 사용자 계정의 동시성 한도는 1,000개의 동시 실행입니다. 함수는 이 1,000개의 동시성 풀을 온디맨드 방식으로 공유합니다. 사용 가능한 동시성이 부족하면 함수에서 제한이 발생합니다(즉, 요청 삭제가 시작됨).

일부 함수는 다른 함수보다 더 중요할 수 있습니다. 따라서 중요한 함수가 필요한 동시성을 확보하도록 동시성 설정을 구성해야 할 수 있습니다. 예약된 동시성 및 프로비저닝된 동시성의 두 가지 유형의 동시성 제어가 제공됩니다.

• 예약된 동시성을 사용하여 함수에 대해 계정의 동시성 부분을 예약합니다. 이는 사용 가능한 예약되지 않은 동시성을 다른 함수가 모두 차지하지 않도록 하려는 경우에 유용합니다.

• 프로비저닝된 동시성을 사용하여 함수의 여러 환경 인스턴스를 미리 초기화합니다. 이는 콜드 스타트 지연 시간을 줄이는 데 유용합니다.

예약된 동시성

함수가 언제든지 일정량의 동시성을 사용할 수 있도록 하려면 예약된 동시성을 사용합니다.

예약된 동시성은 함수에 할당하려는 최대 동시 인스턴스 수입니다. 예약된 동시성을 한 함수에 전용으로 사용하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 즉, 예약된 동시성 설정은 다른 함수가 사용할 수 있는 동시성 풀에 영향을 미칠 수 있습니다. 예약된 동시성이 없는 함수는 예약되지 않은 동시성의 나머지 풀을 공유합니다.

예약된 동시성을 구성하면 전체 계정 동시성 한도에 반영됩니다. 함수에 대해 예약된 동시성을 구성하는 데는 요금이 부과되지 않습니다.

예약된 동시성을 더 잘 이해하려면 다음 다이어그램을 살펴보세요.

이 다이어그램에서 이 리전의 모든 함수에 대한 계정 동시성 한도는 기본 한도인 1,000입니다. function-blue와 function-orange라는 두 개의 중요한 함수가 있고 일상적으로 호출량이 많을 것으로 예상된다고 가정해 보겠습니다. function-blue에 예약된 동시성 400단위를 제공하고 function-orange에 예약된 동시성 400단위를 제공하기로 결정합니다. 이 예에서는 계정의 다른 모든 함수가 나머지 200단위의 예약되지 않은 동시성을 공유해야 합니다.

이 다이어그램에는 주목해야 할 다섯 가지 사항이 있습니다.

• t1에 function-orange와 function-blue는 둘 다 요청을 수신하기 시작합니다. 각 함수는 예약된 동시성 단위의 할당된 부분을 사용하기 시작합니다.

• t2에 function-orange와 function-blue는 꾸준히 더 많은 요청을 수신합니다. 그와 동시에, 사용자가 다른 Lambda 함수를 배포하고 해당 함수가 요청 수신을 시작합니다. 이러한 다른 함수에는 예약된 동시성을 할당하지 않습니다. 해당 함수들은 나머지 200단위의 예약되지 않은 동시성을 사용하기 시작합니다.

• t3에 function-orange는 최대 동시성 400에 도달합니다. 계정의 다른 곳에 사용하지 않은 동시성이 있지만 function-orange는 거기에 액세스할 수 없습니다. 빨간색 선은 function-orange에서 제한이 발생하고 있음을 나타내며 Lambda가 요청을 삭제할 수 있습니다.

• t4에는 function-orange가 요청을 더 적게 받기 시작하고 더 이상 제한되지 않습니다. 하지만 다른 함수에서는 트래픽이 급증하여 제한이 시작됩니다. 계정의 다른 곳에 사용하지 않은 동시성이 있지만 이 다른 함수들은 거기에 액세스할 수 없습니다. 빨간색 선은 다른 함수에서 제한이 발생하고 있음을 나타냅니다.

• t5에는 다른 함수들이 요청을 더 적게 받기 시작하고 더 이상 제한되지 않습니다.

이 예에서 동시성을 예약하면 다음과 같은 효과가 있음을 알 수 있습니다.

• 함수는 계정의 다른 함수와 독립적으로 확장할 수 있습니다. 동일한 리전에 있는 모든 계정의 함수 중 예약된 동시성이 없는 함수는 예약되지 않은 동시성 풀을 공유합니다. 예약된 동시성이 없으면 다른 함수는 사용 가능한 모든 동시성을 다 사용하게 될 수 있습니다. 이렇게 하면 필요할 때 중요한 함수가 스케일 업되지 않습니다.

• 함수는 제어 범위를 벗어나 스케일 아웃될 수 없습니다. 예약된 동시성은 함수의 최대 동시성을 제한합니다. 즉, 함수는 다른 함수에 예약된 동시성 또는 예약되지 않은 풀의 동시성을 사용할 수 없습니다. 동시성을 예약하여 함수가 계정에서 사용 가능한 모든 동시성을 다 사용하지 못하게 하거나 다운스트림 리소스를 오버로드하지 못하게 할 수 있습니다.

• 계정에서 사용 가능한 모든 동시성을 사용하지 못할 수도 있습니다. 동시성 예약은 계정 동시성 한도에 반영되지만, 이는 다른 함수가 예약된 동시성 청크를 사용할 수 없다는 의미이기도 합니다. 함수가 예약한 동시성을 모두 사용하지 않으면 사실상 해당 동시성을 낭비하고 있는 셈입니다. 이는 계정의 다른 함수가 낭비되는 동시성을 활용했을 때 이점이 있는 경우가 아니라면 문제가 되지 않습니다.

함수에 대해 예약된 동시성 설정을 관리하는 방법에 대해 알아보려면 함수에 대해 예약된 동시성 구성을 참조하세요.

프로비저닝된 동시성

예약된 동시성을 사용하여 Lambda 함수에 예약된 최대 실행 환경 수를 정의합니다. 하지만 이러한 환경 중 어느 것도 사전 초기화된 상태로 제공되지 않습니다. 따라서 함수를 호출하는 데 새 환경을 사용하려면 먼저 Lambda가 새 환경을 초기화해야 하기 때문에 함수 호출 시간이 더 오래 걸릴 수 있습니다. 호출을 수행하기 위해 Lambda가 새 환경을 초기화해야 하는 경우 이를 콜드 스타트라고 합니다. 콜드 스타트를 해결하기 위해 프로비저닝된 동시성을 사용할 수 있습니다.

프로비저닝된 동시성은 함수에 할당하려는 사전 초기화된 실행 환경의 수입니다. 함수에 대해 프로비저닝된 동시성을 설정하면 Lambda는 함수의 요청에 즉시 응답할 준비가 되도록 해당하는 수의 실행 환경을 초기화합니다.

참고

프로비저닝된 동시성을 사용하면 계정에 추가 요금이 부과됩니다. Java 11 또는 Java 17 런타임 작업 시 추가 비용 없이 Lambda SnapStart를 사용하여 콜드 스타트 문제를 완화할 수도 있습니다. SnapStart는 실행 환경의 캐시된 스냅샷을 사용하여 시작 성능을 크게 향상시킵니다. 동일한 함수 버전에 SnapStart와 프로비저닝된 동시성을 모두 사용할 수는 없습니다. SnapStart 기능, 제한 사항 및 지원되는 리전에 대한 자세한 내용은 Lambda SnapStart를 사용하여 시작 성능 개선을 참조하세요.

프로비저닝된 동시성을 사용하는 경우에도 Lambda는 여전히 백그라운드에서 실행 환경을 재활용합니다. 하지만 Lambda는 항상 사전 초기화된 환경의 수가 함수의 프로비저닝된 동시성 설정 값과 같도록 합니다. 이 동작은 Lambda가 일정 기간 동안 비활성 상태인 환경을 완전히 종료할 수 있는 예약된 동시성과 다릅니다. 다음 다이어그램은 예약된 동시성을 사용하여 함수를 구성할 경우 단일 실행 환경의 수명 주기를 프로비저닝된 동시성과 비교하여 이를 보여줍니다.

이 다이어그램에는 주목해야 할 4가지 사항이 있습니다.

Time	예약된 동시성	프로비저닝된 동시성
t1	아무 일도 일어나지 않습니다.	Lambda가 실행 환경 인스턴스를 사전 초기화합니다.
t2	요청 1이 수신됩니다. Lambda가 새 실행 환경 인스턴스를 초기화해야 합니다.	요청 1이 수신됩니다. Lambda가 사전 초기화된 환경 인스턴스를 사용합니다.
t3	일정 시간 동안 비활성 상태로 있으면 Lambda가 해당 활성 환경 인스턴스를 종료합니다.	아무 일도 일어나지 않습니다.
t4	요청 2가 수신됩니다. Lambda가 새 실행 환경 인스턴스를 초기화해야 합니다.	요청 2가 수신됩니다. Lambda가 사전 초기화된 환경 인스턴스를 사용합니다.

프로비저닝된 동시성을 더 잘 이해하려면 다음 다이어그램을 살펴보세요.

이 다이어그램의 계정 동시성 한도는 1,000입니다. 400단위의 프로비저닝된 동시성을 function-orange에 제공하기로 결정합니다. function-orange를 포함한 계정의 모든 함수는 예약되지 않은 나머지 동시성 600단위를 사용할 수 있습니다.

이 다이어그램에는 주목해야 할 다섯 가지 사항이 있습니다.

• t1에 function-orange가 요청을 수신하기 시작합니다. Lambda가 400개의 실행 환경 인스턴스를 사전 초기화했으므로 function-orange는 즉시 호출을 처리할 수 있습니다.

• t2에 function-orange가 동시 요청 400개에 도달합니다. 따라서 function-orange의 프로비저닝된 동시성이 소진됩니다. 하지만 아직 예약되지 않은 동시성을 사용할 수 있으므로, Lambda는 이를 사용하여 function-orange에 대한 추가 요청을 처리할 수 있습니다(제한 없음). Lambda는 이러한 요청을 처리하기 위해 새 인스턴스를 생성해야 하며 함수에서 콜드 스타트 지연 시간이 발생할 수 있습니다.

• t3에는 function-orange에 대한 트래픽이 잠시 급증한 후 400개의 동시 요청으로 돌아갑니다. Lambda는 다시 콜드 스타트 지연 없이 모든 요청을 처리할 수 있게 됩니다.

• t4에 계정의 함수에서 트래픽이 급증합니다. 이 버스트는 function-orange 또는 계정의 다른 함수에서 발생한 것일 수 있습니다. Lambda는 예약되지 않은 동시성을 사용하여 이러한 요청을 처리합니다.

• t5에 계정의 함수가 최대 동시성 한도인 1,000단위에 도달하여 제한이 발생합니다.

이전 예에서는 오직 프로비저닝된 동시성만 고려했습니다. 실제 상황에서는 함수에 대해 프로비저닝된 동시성과 예약된 동시성을 모두 설정할 수 있습니다. 주중에 일정한 간접 호출 로드를 처리하지만 주말에 정기적으로 트래픽이 급증하는 함수가 있는 경우 이 방법을 사용할 수 있습니다. 이 경우 프로비저닝된 동시성을 사용하여 평일에 요청을 처리할 기준 환경 수를 설정하고, 예약된 동시성을 사용하여 주말에 급증하는 트래픽을 처리할 수 있습니다. 다음 다이어그램을 살펴보세요.

이 다이어그램에서 function-orange에 대해 프로비저닝된 동시성 200단위와 예약된 동시성 400단위를 구성한다고 가정해 보겠습니다. 예약된 동시성을 구성했으므로, function-orange는 예약되지 않은 동시성 600단위를 사용할 수 없습니다.

이 다이어그램에는 주목해야 할 다섯 가지 사항이 있습니다.

• t1에 function-orange가 요청을 수신하기 시작합니다. Lambda가 200개의 실행 환경 인스턴스를 사전 초기화했으므로 function-orange는 즉시 호출을 처리할 수 있습니다.

• t2에는 function-orange가 프로비저닝된 동시성을 모두 사용합니다. function-orange는 예약된 동시성을 사용하여 요청을 계속 처리할 수 있지만 요청에서 콜드 스타트 지연 시간이 발생할 수 있습니다.

• t3에 function-orange가 동시 요청 400개에 도달합니다. 따라서 function-orange는 예약된 동시성을 모두 사용합니다. function-orange는 예약되지 않은 동시성을 사용할 수 없으므로 요청이 제한되기 시작합니다.

• t4에는 function-orange가 요청을 더 적게 받기 시작하고 더 이상 제한되지 않습니다.

• t5에는 function-orange의 동시 요청이 200개로 감소하므로 모든 요청이 다시 프로비저닝된 동시성을 사용할 수 있습니다(즉, 콜드 스타트 지연 시간 없음).

예약된 동시성과 프로비저닝된 동시성 수는 모두 계정 동시성 한도와 리전별 할당량에 반영됩니다. 즉, 예약된 동시성과 프로비저닝된 동시성을 할당하면 다른 함수가 사용할 수 있는 동시성 풀에 영향을 미칠 수 있습니다. 프로비저닝된 동시성을 구성하면 AWS 계정에 요금이 부과됩니다.

참고

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

함수에 대해 예약된 동시성 설정을 관리하려면 함수에 대해 프로비저닝된 동시성 구성을 참조하세요. 일정 또는 애플리케이션 활용도를 기준으로 프로비저닝된 동시성 스케일을 관리하려면 Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화을 참고하세요.

Lambda에서 프로비저닝된 동시성을 할당하는 방법

프로비저닝된 동시성이 구성 직후에 온라인 상태가 되는 것은 아닙니다. Lambda는 1~2분의 준비 시간을 가진 후에 프로비저닝된 동시성 할당을 시작합니다. 각 기능에 대해 Lambda는 AWS 리전에 관계없이 매분 최대 6,000개의 실행 환경을 프로비저닝할 수 있습니다. 이는 함수의 동시성 확장 속도와 완전히 동일합니다.

프로비저닝된 동시성 할당 요청을 제출하면 Lambda가 할당을 완전히 마칠 때까지 해당 환경에 액세스할 수 없습니다. 예를 들어 5,000개의 프로비저닝된 동시성을 요청하는 경우, Lambda가 5,000개의 실행 환경 할당을 완전히 완료할 때까지 어떤 요청도 프로비저닝된 동시성을 사용할 수 없습니다.

예약된 동시성과 프로비저닝된 동시성 비교

다음 표는 예약된 동시성과 프로비저닝된 동시성을 요약하고 비교한 것입니다.

주제	예약된 동시성	프로비저닝된 동시성
정의	함수의 최대 실행 환경 인스턴스 수입니다.	함수의 사전 프로비저닝된 실행 환경 인스턴스 수를 설정합니다.
프로비저닝 동작	Lambda가 온디맨드로 새 인스턴스를 프로비저닝합니다.	Lambda가 인스턴스를 사전 프로비저닝합니다(즉, 함수가 요청 수신을 시작하기 전).
콜드 스타트 동작	Lambda가 온디맨드로 새 인스턴스를 생성해야 하므로 콜드 스타트 지연 시간이 발생할 수 있습니다.	Lambda가 온디맨드로 인스턴스를 생성할 필요가 없으므로 콜드 스타트 지연 시간이 가능하지 않습니다.
제한 동작	예약된 동시성 한도에 도달하면 함수가 제한됩니다.	예약된 동시성이 설정되지 않은 경우: 프로비저닝된 동시성 제한에 도달하면 함수가 예약되지 않은 동시성을 사용합니다. 예약된 동시성이 설정된 경우: 예약된 동시성 한도에 도달하면 함수가 제한됩니다.
설정하지 않은 경우 기본 동작	함수가 계정에서 사용 가능한 예약되지 않은 동시성을 사용합니다.	Lambda가 인스턴스를 사전 프로비저닝하지 않습니다. 예약된 동시성이 설정되지 않은 경우: 함수가 계정에서 사용 가능한 예약되지 않은 동시성을 사용합니다. 예약된 동시성이 설정된 경우: 함수가 예약된 동시성을 사용합니다.
요금	추가 요금이 없습니다.	추가 요금이 발생합니다.

동시성과 초당 요청 수에 대한 이해

이전 섹션에서 설명한 것처럼 동시성은 초당 요청 수와 다릅니다. 이는 평균 요청 시간이 100ms 미만인 함수 작업 시 특히 중요한 차이점입니다.

계정의 모든 함수에 대해 Lambda는 계정 동시성의 10배에 해당하는 초당 요청 수의 한도를 적용합니다. 예를 들어, 기본 계정 동시성 한도는 1,000개이므로 계정의 함수는 초당 최대 10,000개의 요청을 처리할 수 있습니다.

평균 요청 기간이 50ms인 함수를 예로 들어 보겠습니다. 초당 20,000개의 요청이 있을 때, 이 함수의 동시성은 다음과 같습니다.

Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000

이 결과를 바탕으로, 1,000이라는 계정 동시성 한도는 이 로드를 처리하는 데 충분할 것으로 예상할 수 있습니다. 하지만 초당 요청 수의 한도가 10,000개이기 때문에 함수는 총 20,000개의 요청 중 초당 10,000개의 요청만 처리할 수 있습니다. 이 함수에 제한이 발생합니다.

이 과정에서 반드시 함수에 대한 동시성 설정을 구성할 때 동시성과 초당 요청 수를 모두 고려해야 합니다. 이 경우, 초당 총 요청 수의 한도가 20,000개로 늘어나므로 계정 동시성 한도를 2,000개로 늘려달라고 요청해야 합니다.

참고

이러한 초당 요청 수의 한도를 근거로, 각 Lambda 실행 환경이 초당 최대 10개의 요청만 처리할 수 있다고 말하는 것은 올바르지 않습니다. 개별 실행 환경의 로드를 관찰하는 대신, Lambda는 할당량을 계산할 때 전체 동시성과 초당 전체 요청 수만 고려합니다.

동시성에 대한 이해도 테스트(100ms 미만 함수)

실행하는 데 평균 20ms가 걸리는 함수가 있다고 가정합니다. 최대 부하에서는 초당 30,000개의 요청이 관찰됩니다. 최대 부하 시 함수의 동시성은 얼마일까요?

정답

평균 함수 지속 시간은 20밀리초, 즉 0.02초입니다. 동시성 수식을 사용하여 숫자를 대입하면 600이라는 동시성을 구할 수 있습니다.

Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600

기본적으로 1,000개의 계정 동시성 한도는 이 로드를 처리하기에 충분해 보입니다. 하지만 초당 요청 수의 한도인 10,000개는 초당 30,000개의 들어오는 요청을 처리하기에 충분하지 않습니다. 30,000개의 요청을 모두 수용하려면 계정 동시성 한도를 3,000개 이상으로 늘려달라고 요청해야 합니다.

초당 요청 수 한도는 동시성을 포함하는 Lambda의 모든 할당량에 적용됩니다. 즉, 이는 동기식 온디맨드 함수, 프로비저닝된 동시성을 사용하는 함수 및 동시성 규모 조정 동작에 적용됩니다. 예를 들어, 동시성과 초당 요청 수 한도를 모두 신중하게 고려해야 하는 몇 가지 시나리오는 다음과 같습니다.

• 온디맨드 동시성을 사용하는 함수는 10초마다 500개의 동시성 또는 10초마다 초당 5,000개의 요청 중 먼저 발생하는 것에 의한 버스트 증가를 경험할 수 있습니다.

• 프로비저닝된 동시성 할당량이 10인 함수가 있다고 가정해 보겠습니다. 이 함수는 10개의 동시성 또는 초당 100개의 요청 중 먼저 발생하는 것 이후에 온디맨드 동시성으로 넘어갑니다.

동시성 할당량

Lambda가 리전의 모든 함수에 걸쳐 사용 가능한 총 동시성 수량에 대한 할당량을 설정합니다. 이 할당량은 두 가지 수준으로 존재합니다.

• 계정 수준에서 함수는 기본적으로 최대 1,000단위의 동시성을 가질 수 있습니다. 이 한도를 늘리려면 Service Quotas 사용 설명서에서 할당량 증가 요청을 참조하세요.

• 함수 수준에서 기본적으로 모든 함수에 걸쳐 최대 900단위의 동시성을 예약할 수 있습니다. 총 계정 동시성 한도에 관계없이 Lambda는 명시적으로 동시성을 예약하지 않는 함수에 대해 항상 100개의 동시성 단위를 예약합니다. 예를 들어 계정 동시성 한도를 2,000단위로 늘린 경우 그럼 함수 수준에서 최대 1,900단위의 동시성을 예약할 수 있습니다.

• 또한 Lambda는 계정 수준과 함수 수준 모두에서 해당 동시성 할당량의 10배에 해당하는 초당 요청 수 한도를 적용합니다. 예를 들어, 이는 계정 수준 동시성, 온디맨드 동시성을 사용하는 함수, 프로비전된 동시성을 사용하는 함수 및 동시성 규모 조정 동작에 적용됩니다. 자세한 내용은 동시성과 초당 요청 수에 대한 이해 단원을 참조하십시오.

현재 계정 수준의 동시성 할당량을 확인하려면 AWS Command Line Interface(AWS CLI)을 사용하여 다음 명령을 실행합니다.

aws lambda get-account-settings

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

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

ConcurrentExecutions는 총 계정 수준 동시성 할당량입니다. UnreservedConcurrentExecutions는 여전히 함수에 할당할 수 있는 예약된 동시성의 양입니다.

함수가 더 많은 요청을 수신하면 Lambda는이 계정 동시성 할당량에 도달할 때까지 이러한 요청을 처리할 수 있도록 실행 환경 수를 자동으로 스케일 업합니다. 그러나 갑작스러운 트래픽 폭증에 대응한 오버스케일링을 방지하기 위해 Lambda는 함수의 스케일 속도를 제한합니다. 이 동시성 확장 속도는 요청 증가에 대응하여 계정의 기능이 스케일 인할 수 있는 최대 속도입니다. (즉, Lambda가 새 실행 환경을 얼마나 빨리 생성할 수 있는지를 의미합니다.) 동시성 확장 속도는 함수에 사용할 수 있는 총 동시성의 양인 계정 수준 동시성 한도와는 다릅니다.

각 AWS 리전에서, 각 함수에 대한 동시성 규모 조정 속도는 10초당 1,000개의 실행 환경 인스턴스(또는 10초마다 초당 10,000개의 요청)입니다. 즉, Lambda는 10초당 최대 1,000개의 추가 실행 환경 인스턴스를 각 함수에 할당하거나, 초당 10,000개의 추가 요청을 각 함수에 수용할 수 있습니다.

일반적으로 이 제한 사항에 대해 걱정할 필요는 없습니다. Lambda의 스케일 속도는 대부분의 사용 사례에 충분합니다.

동시성 확장 속도가 함수 수준 제한이라는 점은 중요합니다. 즉, 계정의 각 함수가 다른 함수와 독립적으로 스케일할 수 있다는 의미입니다.

스케일 동작에 대한 자세한 내용은 Lambda 조정 동작을 참조하세요.