# Lambda 함수 규모 조정 이행
**동시성**은 AWS Lambda 함수가 동시에 처리하는 전송 중인 요청 수입니다. 각 동시 요청마다 Lambda는 실행 환경의 개별 인스턴스를 프로비저닝합니다. 함수가 요청을 더 많이 수신하면 Lambda는 사용자가 계정의 동시성 한도에 도달할 때까지 실행 환경 수를 자동으로 조정합니다. 기본적으로 Lambda는 사용자 계정에 AWS 리전 내 모든 함수에 걸쳐 총 1,000개 동시 실행 한도의 동시성을 제공합니다. 특정 계정 요구 사항을 지원하기 위해, [할당량 증대를 요청하고](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/) 함수 수준의 동시성 제어를 구성하여 중요한 함수에 대해 제한이 발생하지 않도록 할 수 있습니다.
이 주제에서는 Lambda의 동시성 개념과 함수 스케일 인에 대해 설명합니다. 이 주제를 마치면 동시성을 계산하고, 두 가지 주요 동시성 제어 옵션(예약 및 프로비저닝)을 시각화하고, 적절한 동시성 제어 설정을 추정하며, 추가 최적화를 위한 지표를 보는 방법을 이해할 수 있습니다.
**Topics**
+ [
## 동시성 이해 및 시각화
](#understanding-concurrency)
+ [
## 함수의 동시성 계산
](#calculating-concurrency)
+ [
## 예약된 동시성 및 프로비저닝된 동시성 이해
](#reserved-and-provisioned)
+ [
## 동시성과 초당 요청 수에 대한 이해
](#concurrency-vs-requests-per-second)
+ [
## 동시성 할당량
](#concurrency-quotas)
+ [
# 함수에 대해 예약된 동시성 구성
](configuration-concurrency.md)
+ [
# 함수에 대해 프로비저닝된 동시성 구성
](provisioned-concurrency.md)
+ [
# Lambda 조정 동작
](scaling-behavior.md)
+ [
# 동시성 모니터링
](monitoring-concurrency.md)
## 동시성 이해 및 시각화
Lambda는 안전하고 격리된 [실행 환경](lambda-runtime-environment.md)에서 함수를 간접 호출합니다. 요청을 처리하려면 Lambda가 실행 환경을 사용하여 함수를 간접 호출([간접 호출 단계](lambda-runtime-environment.md#runtimes-lifecycle-invoke))하기 전에 먼저 실행 환경을 초기화([초기화 단계](lambda-runtime-environment.md#runtimes-lifecycle-ib))해야 합니다 .
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-1-environment.png)
**참고**
실제 초기화 및 간접 호출 지속 시간은 선택한 런타임 및 Lambda 함수 코드와 같은 여러 요인에 따라 달라질 수 있습니다. 위 다이어그램은 초기화 및 간접 호출 단계 지속 시간의 정확한 비율을 보여주기 위한 것이 아닙니다.
위 다이어그램에서는 사각형을 사용하여 단일 실행 환경을 나타냅니다. 함수가 첫 번째 요청(`1` 레이블이 있는 노란색 원으로 표시됨)을 수신하면 Lambda는 새 실행 환경을 생성하고 초기화 단계 중에 기본 핸들러 외부에서 코드를 실행합니다. 그런 다음 Lambda는 간접 호출 단계에서 함수의 기본 핸들러 코드를 실행합니다. 이 전체 프로세스를 실행하는 동안 이 실행 환경은 사용량이 많아 다른 요청을 처리할 수 없습니다.
Lambda가 첫 번째 요청 처리를 마치면 이 실행 환경에서 동일한 함수에 대한 추가 요청을 처리할 수 있습니다. 후속 요청을 처리하기 위해 Lambda는 환경을 다시 초기화할 필요가 없습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-2-two-requests.png)
이전 다이어그램에서 Lambda는 실행 환경을 재사용하여 두 번째 요청(`2` 레이블이 있는 노란색 원으로 표시됨)을 처리합니다.
지금까지는 실행 환경의 단일 인스턴스(즉, 동시성 1)에만 초점을 맞췄습니다. 실제 환경에서 Lambda는 들어오는 모든 요청을 처리하기 위해 여러 실행 환경 인스턴스를 병렬로 프로비저닝해야 할 수 있습니다. 함수가 새 요청을 받으면 다음 두 가지 중 하나가 발생할 수 있습니다.
+ 사전 초기화된 실행 환경 인스턴스를 사용할 수 있는 경우 Lambda는 이를 사용하여 요청을 처리합니다.
+ 그렇지 않으면 Lambda는 요청을 처리하기 위해 새 실행 환경 인스턴스를 생성합니다.
예를 들어 함수가 10개의 요청을 수신하면 어떻게 되는지 살펴보겠습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-3-ten-requests.png)
위 다이어그램에서 각 수평면은 단일 실행 환경 인스턴스(`A`\$1`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는 이에 대응하여 실행 환경 인스턴스의 수를 늘립니다. 다음 애니메이션에서는 시간 경과에 따른 동시 요청 수를 추적합니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-4-animation.gif)
이전 애니메이션을 서로 다른 여섯 개 시점에서 고정하면 다음과 같은 다이어그램을 얻을 수 있습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-5-animation-summary.png)
이전 다이어그램에서는 어느 지점에서든 수직선을 그리고 이 선과 교차하는 환경의 수를 계산할 수 있습니다. 이를 통해 해당 시점의 동시 요청 수를 알 수 있습니다. 예를 들어 `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개의 동시성 풀을 온디맨드 방식으로 공유합니다. 사용 가능한 동시성이 부족하면 함수에서 스로틀링이 발생합니다(즉, 요청 삭제가 시작됨).
일부 함수는 다른 함수보다 더 중요할 수 있습니다. 따라서 중요한 함수가 필요한 동시성을 확보하도록 동시성 설정을 구성해야 할 수 있습니다. 예약된 동시성 및 프로비저닝된 동시성의 두 가지 유형의 동시성 제어가 제공됩니다.
+ **예약된 동시성**을 사용하여 최대 및 최소 동시 인스턴스 수를 모두 설정하여 함수에 대한 계정 동시성의 일부를 예약할 수 있습니다. 이는 사용 가능한 예약되지 않은 동시성을 다른 함수가 모두 차지하지 않도록 하려는 경우에 유용합니다. 한 함수가 동시성을 예약하면 다른 함수는 해당 동시성을 사용할 수 없습니다.
+ **프로비저닝된 동시성**을 사용하여 함수의 여러 환경 인스턴스를 미리 초기화합니다. 이는 콜드 스타트 지연 시간을 줄이는 데 유용합니다.
### 예약된 동시성
함수가 언제든지 일정량의 동시성을 사용할 수 있도록 하려면 예약된 동시성을 사용합니다.
예약된 동시성은 함수에 할당하려는 최대 및 최소 동시 인스턴스 수입니다. 예약된 동시성을 한 함수에 전용으로 사용하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 즉, 예약된 동시성 설정은 다른 함수가 사용할 수 있는 동시성 풀에 영향을 미칠 수 있습니다. 예약된 동시성이 없는 함수는 예약되지 않은 동시성의 나머지 풀을 공유합니다.
예약된 동시성을 구성하면 전체 계정 동시성 한도에 반영됩니다. 함수에 대해 예약된 동시성을 구성하는 데는 요금이 부과되지 않습니다.
예약된 동시성을 더 잘 이해하려면 다음 다이어그램을 살펴보세요.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
이 다이어그램에서 이 리전의 모든 함수에 대한 계정 동시성 한도는 기본 한도인 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`에는 다른 함수들이 요청을 더 적게 받기 시작하고 더 이상 제한되지 않습니다.
이 예에서 동시성을 예약하면 다음과 같은 효과가 있음을 알 수 있습니다.
+ **함수는 계정의 다른 함수와 독립적으로 확장할 수 있습니다.** 동일한 리전에 있는 모든 계정의 함수 중 예약된 동시성이 없는 함수는 예약되지 않은 동시성 풀을 공유합니다. 예약된 동시성이 없으면 다른 함수는 사용 가능한 모든 동시성을 다 사용하게 될 수 있습니다. 이렇게 하면 필요할 때 중요한 함수가 스케일 업되지 않습니다.
+ **함수는 제어 범위를 벗어나 스케일 아웃될 수 없습니다.** 예약된 동시성은 함수의 최대 및 최소 동시성을 제한합니다. 즉, 함수는 다른 함수에 예약된 동시성 또는 예약되지 않은 풀의 동시성을 사용할 수 없습니다. 또한 예약된 동시성은 하한과 상한 모두의 역할을 합니다. 함수에 대해 지정된 용량을 전용으로 예약하는 동시에 해당 한도를 초과하여 규모를 조정하지 않도록 합니다. 동시성을 예약하여 함수가 계정에서 사용 가능한 모든 동시성을 다 사용하지 못하게 하거나 다운스트림 리소스를 오버로드하지 못하게 할 수 있습니다.
+ **계정에서 사용 가능한 모든 동시성을 사용하지 못할 수도 있습니다.** 동시성 예약은 계정 동시성 한도에 반영되지만, 이는 다른 함수가 예약된 동시성 청크를 사용할 수 없다는 의미이기도 합니다. 함수가 예약한 동시성을 모두 사용하지 않으면 사실상 해당 동시성을 낭비하고 있는 셈입니다. 이는 계정의 다른 함수가 낭비되는 동시성을 활용했을 때 이점이 있는 경우가 아니라면 문제가 되지 않습니다.
함수에 대해 예약된 동시성 설정을 관리하는 방법에 대해 알아보려면 [함수에 대해 예약된 동시성 구성](configuration-concurrency.md)을 참조하세요.
### 프로비저닝된 동시성
예약된 동시성을 사용하여 Lambda 함수에 예약된 최대 실행 환경 수를 정의합니다. 하지만 이러한 환경 중 어느 것도 사전 초기화된 상태로 제공되지 않습니다. 따라서 함수를 간접 호출하는 데 새 환경을 사용하려면 먼저 Lambda가 새 환경을 초기화해야 하기 때문에 함수 간접 호출 시간이 더 오래 걸릴 수 있습니다. 간접 호출을 수행하기 위해 Lambda가 새 환경을 초기화해야 하는 경우 이를 [콜드 스타트](lambda-runtime-environment.md#cold-start-latency)라고 합니다. 콜드 스타트를 해결하기 위해 프로비저닝된 동시성을 사용할 수 있습니다.
프로비저닝된 동시성은 함수에 할당하려는 사전 초기화된 실행 환경의 수입니다. 함수에 대해 프로비저닝된 동시성을 설정하면 Lambda는 함수의 요청에 즉시 응답할 준비가 되도록 해당하는 수의 실행 환경을 초기화합니다.
**참고**
프로비저닝된 동시성을 사용하면 계정에 추가 요금이 부과됩니다. Java 11 또는 Java 17 런타임 작업 시 추가 비용 없이 Lambda SnapStart를 사용하여 콜드 스타트 문제를 완화할 수도 있습니다. SnapStart는 실행 환경의 캐시된 스냅샷을 사용하여 시작 성능을 크게 향상시킵니다. 동일한 함수 버전에 SnapStart와 프로비저닝된 동시성을 모두 사용할 수는 없습니다. SnapStart 기능, 제한 사항 및 지원되는 리전에 대한 자세한 내용은 [Lambda SnapStart를 사용하여 시작 성능 개선](snapstart.md)을 참조하세요.
프로비저닝된 동시성을 사용하는 경우에도 Lambda는 여전히 백그라운드에서 실행 환경을 재활용합니다. 예를 들어, [간접 호출 실패 후](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors) 이러한 현상이 발생할 수 있습니다. 하지만 Lambda는 항상 사전 초기화된 환경의 수가 함수의 프로비저닝된 동시성 설정 값과 같도록 합니다. 중요한 점은 프로비저닝된 동시성을 사용하더라도 Lambda가 실행 환경을 재설정해야 하는 경우 콜드 스타트 지연이 발생할 수 있다는 것입니다.
반대로 예약된 동시성을 사용하는 경우 Lambda는 일정 기간 동안 비활성 상태인 환경을 완전히 종료할 수 있습니다. 다음 다이어그램은 예약된 동시성을 사용하여 함수를 구성할 경우 단일 실행 환경의 수명 주기를 프로비저닝된 동시성과 비교하여 이를 보여줍니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
이 다이어그램에는 주목해야 할 4가지 사항이 있습니다.
| Time | 예약된 동시성 | 프로비저닝된 동시성 |
| --- | --- | --- |
| t1 | 아무 일도 일어나지 않습니다. | Lambda가 실행 환경 인스턴스를 사전 초기화합니다. |
| t2 | 요청 1이 수신됩니다. Lambda가 새 실행 환경 인스턴스를 초기화해야 합니다. | 요청 1이 수신됩니다. Lambda가 사전 초기화된 환경 인스턴스를 사용합니다. |
| t3 | 일정 시간 동안 비활성 상태로 있으면 Lambda가 해당 활성 환경 인스턴스를 종료합니다. | 아무 일도 일어나지 않습니다. |
| t4 | 요청 2가 수신됩니다. Lambda가 새 실행 환경 인스턴스를 초기화해야 합니다. | 요청 2가 수신됩니다. Lambda가 사전 초기화된 환경 인스턴스를 사용합니다. |
프로비저닝된 동시성을 더 잘 이해하려면 다음 다이어그램을 살펴보세요.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
이 다이어그램의 계정 동시성 한도는 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단위에 도달하여 제한이 발생합니다.
이전 예에서는 오직 프로비저닝된 동시성만 고려했습니다. 실제 상황에서는 함수에 대해 프로비저닝된 동시성과 예약된 동시성을 모두 설정할 수 있습니다. 주중에 일정한 간접 호출 로드를 처리하지만 주말에 정기적으로 트래픽이 급증하는 함수가 있는 경우 이 방법을 사용할 수 있습니다. 이 경우 프로비저닝된 동시성을 사용하여 평일에 요청을 처리할 기준 환경 수를 설정하고, 예약된 동시성을 사용하여 주말에 급증하는 트래픽을 처리할 수 있습니다. 다음 다이어그램을 살펴보세요.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
이 다이어그램에서 `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개로 감소하므로 모든 요청이 다시 프로비저닝된 동시성을 사용할 수 있습니다(즉, 콜드 스타트 지연 시간 없음).
예약된 동시성과 프로비저닝된 동시성 수는 모두 계정 동시성 한도와 [리전별 할당량](gettingstarted-limits.md)에 반영됩니다. 즉, 예약된 동시성과 프로비저닝된 동시성을 할당하면 다른 함수가 사용할 수 있는 동시성 풀에 영향을 미칠 수 있습니다. 프로비저닝된 동시성을 구성하면 AWS 계정에 요금이 부과됩니다.
**참고**
함수의 버전과 별칭에서 프로비저닝된 동시성의 양이 함수의 예약된 동시성까지 더해지면 그럼 모든 간접 호출은 프로비저닝된 동시성에서 실행됩니다. 이 구성은 게시되지 않은 버전의 함수(`$LATEST`)를 조절하여 실행을 금지하는 효과가 있습니다. 함수에 대해 예약된 동시성보다 더 많은 프로비저닝된 동시성을 할당할 수 없습니다.
함수에 대해 예약된 동시성 설정을 관리하려면 [함수에 대해 프로비저닝된 동시성 구성](provisioned-concurrency.md)을 참조하세요. 일정 또는 애플리케이션 활용도를 기준으로 프로비저닝된 동시성 스케일을 관리하려면 [Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화](provisioned-concurrency.md#managing-provisioned-concurency)을 참고하세요.
### Lambda에서 프로비저닝된 동시성을 할당하는 방법
프로비저닝된 동시성이 구성 직후에 온라인 상태가 되는 것은 아닙니다. Lambda는 1\$12분의 준비 시간을 가진 후에 프로비저닝된 동시성 할당을 시작합니다. 각 기능에 대해 Lambda는 AWS 리전에 관계없이 매분 최대 6,000개의 실행 환경을 프로비저닝할 수 있습니다. 이는 함수의 [동시성 확장 속도](scaling-behavior.md#scaling-rate)와 완전히 동일합니다.
프로비저닝된 동시성 할당 요청을 제출하면 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의 모든 할당량에 적용됩니다. 즉, 이는 동기식 온디맨드 함수, 프로비저닝된 동시성을 사용하는 함수 및 [동시성 규모 조정 동작](scaling-behavior.md)에 적용됩니다. 예를 들어, 동시성과 초당 요청 수 한도를 모두 신중하게 고려해야 하는 몇 가지 시나리오는 다음과 같습니다.
+ 온디맨드 동시성을 사용하는 함수는 10초마다 500개의 동시성 또는 10초마다 초당 5,000개의 요청 중 먼저 발생하는 것에 의한 버스트 증가를 경험할 수 있습니다.
+ 프로비저닝된 동시성 할당량이 10인 함수가 있다고 가정해 보겠습니다. 이 함수는 10개의 동시성 또는 초당 100개의 요청 중 먼저 발생하는 것 이후에 온디맨드 동시성으로 넘어갑니다.
## 동시성 할당량
Lambda가 리전의 모든 함수에 걸쳐 사용 가능한 총 동시성 수량에 대한 할당량을 설정합니다. 이 할당량은 두 가지 수준으로 존재합니다.
+ **계정 수준에서** 함수는 기본적으로 최대 1,000단위의 동시성을 가질 수 있습니다. 이 한도를 늘리려면 **Service Quotas 사용 설명서에서 [할당량 증가 요청](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)을 참조하세요.
+ **함수 수준에서** 기본적으로 모든 함수에 걸쳐 최대 900단위의 동시성을 예약할 수 있습니다. 총 계정 동시성 한도에 관계없이 Lambda는 명시적으로 동시성을 예약하지 않는 함수에 대해 항상 100개의 동시성 단위를 예약합니다. 예를 들어 계정 동시성 한도를 2,000단위로 늘린 경우 그럼 함수 수준에서 최대 1,900단위의 동시성을 예약할 수 있습니다.
+ 또한 Lambda는 계정 수준과 함수 수준 모두에서 해당 동시성 할당량의 10배에 해당하는 초당 요청 수 한도를 적용합니다. 예를 들어, 이는 계정 수준 동시성, 온디맨드 동시성을 사용하는 함수, 프로비전된 동시성을 사용하는 함수 및 [동시성 규모 조정 동작](scaling-behavior.md)에 적용됩니다. 자세한 내용은 [동시성과 초당 요청 수에 대한 이해](#concurrency-vs-requests-per-second) 섹션을 참조하세요.
현재 계정 수준의 동시성 할당량을 확인하려면 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 조정 동작](scaling-behavior.md)을 참조하세요.
# 함수에 대해 예약된 동시성 구성
Lambda에서 [동시성](lambda-concurrency.md)은 함수가 동시에 처리하는 전송 중인 요청의 수입니다. 두 가지 유형의 동시성 제어를 사용할 수 있습니다.
+ 예약된 동시성 - 함수에 할당된 최대 및 최소 동시 인스턴스 수를 설정합니다. 한 함수가 동시성을 예약하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 예약된 동시성은 가장 중요한 함수가 수신 요청을 처리하기에 충분한 동시성을 항상 확보하도록 하는 데 유용합니다. 또한 예약된 동시성을 사용하여 동시성을 제한하여 데이터베이스 연결 같은 다운스트림 리소스 과부하를 방지할 수 있습니다. 예약된 동시성은 하한과 상한 모두의 역할을 합니다. 함수에 대해 지정된 용량을 전용으로 예약하는 동시에 해당 한도를 초과하여 규모를 조정하지 않도록 합니다. 함수에 예약된 동시성을 구성하는 경우 추가 요금이 부과되지 않습니다.
+ 프로비저닝된 동시성 - 함수에 할당된 사전 초기화된 실행 환경의 수입니다. 이러한 실행 환경은 수신 함수 요청에 즉시 응답할 수 있도록 준비되어 있습니다. 프로비저닝된 동시성은 함수의 콜드 스타트 지연 시간을 줄이는 데 유용하며, 두 자릿수 밀리초 응답 시간으로 함수를 사용할 수 있도록 설계되었습니다. 일반적으로 대화형 워크로드에서 이 기능의 혜택을 가장 많이 활용합니다. 이는 웹 및 모바일 애플리케이션과 같이 사용자가 요청을 시작하는 애플리케이션이며 지연 시간에 가장 민감합니다. 데이터 처리 파이프라인과 같은 비동기식 워크로드는 지연 시간에 덜 민감하기 때문에 일반적으로 프로비저닝된 동시성이 필요하지 않습니다. 프로비저닝된 동시성을 구성하는 경우 AWS 계정에 추가 요금이 부과됩니다.
이 주제에서는 예약된 동시성을 관리하고 구성하는 방법에 대해 자세히 설명합니다. 이 두 가지 유형의 동시성 제어에 대한 개념적 개요는 [예약된 동시성 및 프로비저닝된 동시성](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)을 참조하세요. 프로비저닝된 동시성 구성에 대한 자세한 내용은 [함수에 대해 프로비저닝된 동시성 구성](provisioned-concurrency.md) 섹션을 참조하세요.
**참고**
Amazon MQ 이벤트 소스 매핑에 연결된 Lambda 함수는 기본 최대 동시성을 지원합니다. Apache Active MQ의 경우 최대 동시 인스턴스의 수는 5입니다. Rabbit MQ의 경우 최대 동시 인스턴스의 수는 1입니다. 함수에 예약 또는 프로비저닝된 동시성을 설정해도 이 한도는 변경되지 않습니다. Amazon MQ를 사용할 때 기본 최대 동시성 증가를 요청하려면 지원에 문의하십시오.
**Topics**
+ [
## 예약된 동시성 구성
](#configuring-concurrency-reserved)
+ [
## 함수에 필요한 예약된 동시성 정확히 예측
](#estimating-reserved-concurrency)
## 예약된 동시성 구성
Lambda 콘솔 또는 Lambda API를 사용하여 함수에 대해 예약된 동시성 설정을 구성할 수 있습니다.
**함수에 대해 동시성 예약(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 동시성을 예약하려는 함수를 선택합니다.
1. **구성(Configuration)**을 선택한 다음 **동시성(Concurrency)**을 선택합니다.
1. **동시성**에서 **편집**을 선택합니다.
1. **동시성 예약**을 선택합니다. 함수에 예약할 동시성의 크기를 입력합니다.
1. **저장**을 선택합니다.
**예약되지 않은 계정 동시성** 값에서 100을 뺀 값까지 예약할 수 있습니다. 나머지 100단위의 동시성은 예약된 동시성을 사용하지 않는 함수용입니다. 예를 들어, 계정의 동시성 한도가 1,000인 경우 1,000단위의 동시성을 모두 단일 함수에 예약할 수 없습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
함수에 대해 동시성을 예약하면 다른 함수가 사용할 수 있는 동시성 풀에 영향이 있습니다. 예를 들어 `function-a`에 대해 100단위의 동시성을 예약하는 경우 `function-a`가 예약된 동시성 100단위를 모두 사용하지 않더라도 계정의 다른 함수는 나머지 900단위의 동시성을 공유해야 합니다.
함수를 의도적으로 제한하려면 예약된 동시성을 0으로 설정합니다. 이렇게 하면 제한을 제거할 때까지 함수가 이벤트를 처리하지 않습니다.
Lambda API를 사용하여 예약된 동시성을 구성하려면 다음 API 작업을 사용합니다.
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
예를 들어, AWS Command Line Interface(CLI)를 사용하여 예약된 동시성을 구성하려면 `put-function-concurrency` 명령을 사용합니다. 다음 명령은 `my-function`이라는 함수에 대해 동시성 100단위를 예약합니다.
```
aws lambda put-function-concurrency --function-name my-function \
--reserved-concurrent-executions 100
```
그러면 다음과 같은 결과가 표시됩니다.
```
{
"ReservedConcurrentExecutions": 100
}
```
## 함수에 필요한 예약된 동시성 정확히 예측
함수가 현재 트래픽을 처리하고 있는 경우 [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 지표를 사용하여 해당 함수의 동시성 지표를 손쉽게 확인할 수 있습니다. 구체적으로, `ConcurrentExecutions` 지표는 계정의 각 함수에 대한 동시 호출 수를 보여줍니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
이전 그래프는 이 함수가 주어진 시간에 평균 5\$110개의 동시 요청을 처리하고 보통 하루에 최대 20개의 요청을 처리함을 보여줍니다. 계정에 다른 함수가 많이 있다고 가정해 보겠습니다. ** 이 함수가 애플리케이션에 중요하고 요청을 삭제하지 않으려면** 예약된 동시성 설정으로 20 이상의 숫자를 사용합니다.
또는 다음 수식을 사용하여 [동시성을 계산](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)할 수도 있습니다.
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
초당 평균 요청과 초 단위의 평균 요청 시간을 곱하면 예약해야 하는 동시성 양을 대략적으로 예측할 수 있습니다. `Invocation` 지표를 사용하여 초당 평균 요청 수를 추정하고 `Duration` 지표를 사용하여 평균 요청 지속 시간을 초 단위로 추정할 수 있습니다. 자세한 내용은 [Lambda에서 CloudWatch 지표 사용](monitoring-metrics.md) 섹션을 참조하세요.
업스트림 및 다운스트림 처리량 제한 사항도 잘 알고 있어야 합니다. Lambda 함수는 로드에 따라 원활하게 규모를 조정할 수 있지만 업스트림 및 다운스트림 종속성의 처리량 용량이 동일하지 않을 수 있습니다. 함수의 규모 조정 가능 범위를 제한해야 하는 경우, 함수에서 예약된 동시성을 구성합니다.
# 함수에 대해 프로비저닝된 동시성 구성
Lambda에서 [동시성](lambda-concurrency.md)은 함수가 동시에 처리하는 전송 중인 요청의 수입니다. 두 가지 유형의 동시성 제어를 사용할 수 있습니다.
+ 예약된 동시성 - 함수에 할당된 최대 및 최소 동시 인스턴스 수를 설정합니다. 한 함수가 동시성을 예약하면 다른 함수는 해당 동시성을 사용할 수 없습니다. 예약된 동시성은 가장 중요한 함수가 수신 요청을 처리하기에 충분한 동시성을 항상 확보하도록 하는 데 유용합니다. 또한 예약된 동시성을 사용하여 동시성을 제한하여 데이터베이스 연결 같은 다운스트림 리소스 과부하를 방지할 수 있습니다. 예약된 동시성은 하한과 상한 모두의 역할을 합니다. 함수에 대해 지정된 용량을 전용으로 예약하는 동시에 해당 한도를 초과하여 규모를 조정하지 않도록 합니다. 함수에 예약된 동시성을 구성하는 경우 추가 요금이 부과되지 않습니다.
+ 프로비저닝된 동시성 - 함수에 할당된 사전 초기화된 실행 환경의 수입니다. 이러한 실행 환경은 수신 함수 요청에 즉시 응답할 수 있도록 준비되어 있습니다. 프로비저닝된 동시성은 함수의 콜드 스타트 지연 시간을 줄이는 데 유용하며, 두 자릿수 밀리초 응답 시간으로 함수를 사용할 수 있도록 설계되었습니다. 일반적으로 대화형 워크로드에서 이 기능의 혜택을 가장 많이 활용합니다. 이는 웹 및 모바일 애플리케이션과 같이 사용자가 요청을 시작하는 애플리케이션이며 지연 시간에 가장 민감합니다. 데이터 처리 파이프라인과 같은 비동기식 워크로드는 지연 시간에 덜 민감하기 때문에 일반적으로 프로비저닝된 동시성이 필요하지 않습니다. 프로비저닝된 동시성을 구성하는 경우 AWS 계정에 추가 요금이 부과됩니다.
이 주제에서는 프로비저닝된 동시성을 관리하고 구성하는 방법에 대해 자세히 설명합니다. 이 두 가지 유형의 동시성 제어에 대한 개념적 개요는 [예약된 동시성 및 프로비저닝된 동시성](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)을 참조하세요. 예약된 동시성 구성에 대한 자세한 내용은 [함수에 대해 예약된 동시성 구성](configuration-concurrency.md) 섹션을 참조하세요.
**참고**
Amazon MQ 이벤트 소스 매핑에 연결된 Lambda 함수는 기본 최대 동시성을 지원합니다. Apache Active MQ의 경우 최대 동시 인스턴스의 수는 5입니다. Rabbit MQ의 경우 최대 동시 인스턴스의 수는 1입니다. 함수에 예약 또는 프로비저닝된 동시성을 설정해도 이 한도는 변경되지 않습니다. Amazon MQ를 사용할 때 기본 최대 동시성 증가를 요청하려면 지원에 문의하십시오.
**Topics**
+ [
## 프로비저닝된 동시성 구성
](#configuring-provisioned-concurrency)
+ [
## 함수에 필요한 프로비저닝된 동시성 정확히 예측
](#estimating-provisioned-concurrency)
+ [
## 프로비저닝된 동시성 사용 시 함수 코드 최적화
](#optimizing-latency)
+ [
## 환경 변수를 사용하여 프로비저닝된 동시성 동작 확인 및 제어
](#pc-environment-variables)
+ [
## 프로비저닝된 동시성을 사용한 로깅 및 청구 동작 이해
](#pc-logging-behavior)
+ [
## Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화
](#managing-provisioned-concurency)
## 프로비저닝된 동시성 구성
Lambda 콘솔 또는 Lambda API를 사용하여 함수에 대해 프로비저닝된 동시성 설정을 구성할 수 있습니다.
**함수에 대해 프로비저닝된 동시성 할당(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 프로비저닝된 동시성을 할당하려는 함수를 선택합니다.
1. **구성(Configuration)**을 선택한 다음 **동시성(Concurrency)**을 선택합니다.
1. **프로비저닝된 동시성 구성(Provisioned concurrency configurations)**에서 **구성 추가(Add configuration)**를 선택합니다.
1. 한정자 유형과 별칭 또는 버전을 선택합니다.
**참고**
함수의 \$1LATEST 버전에서는 프로비저닝된 동시성을 사용할 수 없습니다.
함수에 이벤트 소스가 있는 경우 이벤트 소스가 올바른 함수 별칭 또는 버전을 가리키는지 확인합니다. 그렇지 않으면 함수가 프로비저닝된 동시성 환경을 사용하지 않습니다.
1. **프로비저닝된 동시성** 아래에 숫자를 입력합니다.
1. **저장**을 선택합니다.
계정에서 **예약되지 않은 계정 동시성**(- 100)까지 구성할 수 있습니다. 나머지 100단위의 동시성은 예약된 동시성을 사용하지 않는 함수용입니다. 예를 들어, 계정의 동시성 한도가 1,000인데 다른 함수에 예약되거나 프로비저닝된 동시성을 할당하지 않은 경우 단일 함수에 대해 최대 프로비저닝된 동시성 900단위를 구성할 수 있습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)
함수에 프로비저닝된 동시성을 구성하면 다른 함수가 사용할 수 있는 동시성 풀에 영향이 줍니다. 예를 들어 `function-a`에 100의 프로비저닝된 동시성 단위를 구성하는 경우 계정의 다른 함수는 남은 900의 동시성 단위를 공유해야 합니다. `function-a`에서 100의 모든 단위를 사용하지 않더라도 마찬가지입니다.
동일한 함수에 예약된 동시성과 프로비저닝된 동시성을 모두 할당할 수 있습니다. 이 경우 프로비전된 동시성은 예약된 동시성을 초과할 수 없습니다.
이 제한은 함수 버전에도 적용됩니다. 특정 함수 버전에 할당할 수 있는 최대 프로비저닝된 동시성은 함수의 예약된 동시성에서 다른 함수 버전의 프로비저닝된 동시성을 뺀 값과 같습니다.
Lambda API를 사용하여 프로비저닝된 동시성을 구성하려면 다음 API 작업을 사용합니다.
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
예를 들어, AWS Command Line Interface(CLI)를 사용하여 프로비저닝된 동시성을 구성하려면 `put-provisioned-concurrency-config` 명령을 사용합니다. 다음 명령은 `my-function`이라는 함수의 `BLUE` 별칭에 대해 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": "2023-01-21T11:30:00+0000"
}
```
## 함수에 필요한 프로비저닝된 동시성 정확히 예측
[CloudWatch 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)를 사용하여 모든 활성 함수의 동시성 지표를 볼 수 있습니다. 구체적으로, `ConcurrentExecutions` 지표는 계정의 함수에 대한 동시 간접 호출 수를 보여줍니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
이전 그래프는 이 함수가 주어진 시간에 평균 5\$110개의 동시 요청을 처리하고 최대 20개의 요청을 처리함을 보여줍니다. 계정에 다른 함수가 많이 있다고 가정해 보겠습니다. ** 이 함수가 애플리케이션에 중요하고 호출할 때마다 지연 시간이 짧은 응답이 필요한 경우** 프로비저닝된 동시성 단위로 최소 20을 구성합니다.
다음 수식을 사용하여 [동시성을 계산](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)할 수도 있습니다.
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
필요한 동시성을 예측하려면 초당 평균 요청 수에 평균 요청 시간(초 단위)을 곱해야 합니다. `Invocation` 지표를 사용하여 초당 평균 요청 수를 추정하고 `Duration` 지표를 사용하여 평균 요청 지속 시간을 초 단위로 추정할 수 있습니다.
프로비저닝된 동시성을 구성할 때 Lambda는 일반적으로 함수에 필요한 동시성의 양 외에 10% 버퍼를 추가하도록 제안합니다. 예를 들어, 함수의 최대 동시 요청 수가 보통 200개인 경우 프로비저닝된 동시성을 220으로 설정합니다(200개의 동시 요청 \$1 10% = 프로비저닝된 동시성 220).
## 프로비저닝된 동시성 사용 시 함수 코드 최적화
프로비저닝된 동시성을 사용하는 경우 짧은 지연 시간을 위해 함수 코드를 재구성하여 최적화하는 것이 좋습니다. 프로비저닝된 동시성을 사용하는 함수의 경우 Lambda는 할당 중 모든 초기화 코드(예: 라이브러리 로드 및 클라이언트 인스턴스화)를 실행합니다. 따라서 실제 함수 간접 호출 중에 지연 시간에 영향이 없도록 초기화를 최대한 많이 기본 함수 핸들러 외부로 이동하는 것이 좋습니다. 반대로 기본 핸들러 코드 내부에서 라이브러리를 초기화하거나 클라이언트를 인스턴스화하면 프로비저닝된 동시성 사용 여부에 관계없이 간접적으로 간접 호출할 때마다 함수가 이를 실행해야 합니다.
온디맨드 간접 호출의 경우, 함수에서 콜드 스타트가 나타날 때마다 Lambda는 초기화 코드를 다시 실행해야 할 수 있습니다. 이러한 함수의 경우 함수에 필요할 때까지 특정 기능의 초기화를 지연할 수 있습니다. 예를 들어, Lambda 핸들러에 대한 다음 제어 흐름을 고려하세요.
```
def handler(event, context):
...
if ( some_condition ):
// Initialize CLIENT_A to perform a task
else:
// Do nothing
```
이전 예제에서는 개발자가 함수 기본 핸들러 외부에서 `CLIENT_A`를 초기화하는 대신 `if` 문 내부에서 초기화했습니다. 이를 통해 Lambda는 `some_condition`이 충족되는 경우에만 이 코드를 실행합니다. 기본 핸들러 외부에서 `CLIENT_A`를 초기화하면 Lambda는 모든 콜드 스타트에서 해당 코드를 실행합니다. 이로 인해 전체 지연 시간이 늘어날 수 있습니다.
함수에 X-Ray 모니터링을 추가하여 Lambda가 스케일 업됨에 따라 콜드 스타트를 평가할 수 있습니다. 프로비저닝된 동시성을 사용하는 함수는 실행 환경이 간접 호출 전에 준비되므로 콜드 스타트 동작이 나타나지 않습니다. 그러나 프로비저닝된 동시성은 \$1LATEST 버전이 아닌 함수의 [특정 버전 또는 별칭](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)에 적용되어야 합니다. 콜드 스타트 동작이 계속 나타나는 경우 프로비저닝된 동시성이 구성된 별칭 버전을 간접 호출해야 합니다.
## 환경 변수를 사용하여 프로비저닝된 동시성 동작 확인 및 제어
함수가 프로비저닝된 동시성을 모두 사용할 수 있습니다. Lambda는 온디맨드 인스턴스를 사용하여 초과 트래픽을 처리합니다. Lambda가 특정 환경에 사용하는 초기화 유형을 결정하려면 `AWS_LAMBDA_INITIALIZATION_TYPE` 환경 변수의 값을 확인합니다. 이 변수에는 두 가지 가능한 값(`provisioned-concurrency` 또는 `on-demand`)이 있습니다. `AWS_LAMBDA_INITIALIZATION_TYPE`의 값은 변경할 수 없으며 환경의 전체 수명 주기 동안 일정하게 유지됩니다. 함수 코드에서 환경 변수의 값을 확인하려면 [Lambda 환경 변수 검색](configuration-envvars.md#retrieve-environment-variables) 섹션을 참조하세요.
.NET 8 런타임을 사용하는 경우 프로비저닝된 동시성을 사용하지 않더라도 함수의 지연 시간을 개선하도록 `AWS_LAMBDA_DOTNET_PREJIT` 환경 변수를 구성할 수 있습니다. .NET 런타임은 코드가 처음 직접 호출하는 각 라이브러리에서 지연 컴파일 및 초기화를 수행합니다. 결과적으로 Lambda 함수의 첫 번째 간접 호출은 후속 간접 호출보다 오래 걸릴 수 있습니다. 이를 완화하기 위해 `AWS_LAMBDA_DOTNET_PREJIT`에 대해 세 가지 값 중 하나를 선택할 수 있습니다.
+ `ProvisionedConcurrency`: Lambda가 프로비저닝된 동시성을 사용하여 모든 환경에 대해 사전 JIT 컴파일을 수행합니다. 이것이 기본값입니다.
+ `Always`: 함수가 프로비저닝된 동시성을 사용하지 않는 경우에도 Lambda가 모든 환경에 대해 사전 JIT 컴파일을 수행합니다.
+ `Never`: Lambda가 모든 환경에 대해 사전 JIT 컴파일을 비활성화합니다.
## 프로비저닝된 동시성을 사용한 로깅 및 청구 동작 이해
프로비저닝된 동시성 환경의 경우 Lambda가 환경의 인스턴스를 재활용하므로 함수의 초기화 코드가 할당 중에 실행됩니다. Lambda는 환경 인스턴스가 요청을 처리하지 않더라도 초기화 비용을 청구합니다. 프로비저닝된 동시성은 계속 실행되며 초기화 및 간접 호출 비용과는 별도로 비용이 청구됩니다. 자세한 내용은 [AWS Lambda 요금](https://aws.amazon.com/lambda/pricing/)을 참조하세요.
프로비저닝된 동시성을 사용하여 Lambda 함수를 구성하면 Lambda는 간접 호출 요청에 앞서 해당 실행 환경을 사용할 수 있도록 사전 초기화합니다. Lambda는 환경이 초기화될 때마다 함수의 [Init Duration 필드](lambda-runtime-environment.md#runtimes-lifecycle-ib)를 JSON 로깅 형식으로 [platform-initReport](telemetry-schema-reference.md#platform-initReport) 로그 이벤트에 기록합니다. 이 로그 이벤트를 보려면 [JSON 로그 수준](monitoring-cloudwatchlogs-logformat.md)을 최소 `INFO`로 구성합니다. [Telemetry API](telemetry-api-reference.md)를 사용하여 Init Duration 필드가 보고되는 플랫폼 이벤트를 사용할 수도 있습니다.
## Application Auto Scaling을 사용하여 프로비저닝된 동시성 관리 자동화
Application Auto Scaling을 사용하여 일정에 따라 또는 사용률을 기준으로 프로비저닝된 동시성을 관리할 수 있습니다. 함수에 예측 가능한 트래픽 패턴이 수신되는 경우 예약된 크기 조정을 사용합니다. 함수가 특정 사용률(%)을 유지하도록 하려면 대상 추적 스케일링 정책을 사용합니다.
**참고**
Application Auto Scaling을 사용하여 함수의 프로비저닝된 동시성을 관리하는 경우 먼저 [초기 프로비저닝된 동시성 값을 구성](#configuring-provisioned-concurrency)해야 합니다. 함수에 초기 프로비저닝된 동시성 값이 없는 경우 Application Auto Scaling이 함수 규모 조정을 제대로 처리하지 못할 수 있습니다.
### 예약된 크기 조정
Application Auto Scaling을 사용하면 예측 가능한 로드 변경에 따라 자체 조정 일정을 설정할 수 있습니다. 자세한 내용 및 예제는 Application Auto Scaling 사용 설명서의 [Application Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)과 AWS Compute Blog의 [ Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/)를 참조하세요.
### 대상 추적
대상 추적을 통해 Application Auto Scaling은 스케일링 정책 정의 방식에 따라 CloudWatch 경보 세트를 생성하고 관리합니다. 이러한 경보가 활성화되면 Application Auto Scaling은 프로비저닝된 동시성을 사용하여 할당된 환경의 양을 자동으로 조정합니다. 예측 가능한 트래픽 패턴이 없는 애플리케이션에서는 대상 추적을 사용합니다.
대상 추적을 사용하여 프로비저닝된 동시성을 스케일링하려면 `RegisterScalableTarget` 및 `PutScalingPolicy` Application Auto Scaling API 작업을 사용합니다. 예를 들어, AWS Command Line Interface(CLI)를 사용하는 경우 다음 단계를 따르세요.
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
```
1. 조정 정책을 대상에 적용합니다. 다음 예제에서는 별칭에 대해 프로비저닝된 동시성 구성을 조정하여 사용률을 70% 가까이 유지하도록 애플리케이션 Auto Scaling을 구성하지만 10%에서 90% 사이의 값을 적용할 수 있습니다.
```
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이 별칭의 프로비저닝된 동시성을 줄입니다.
**참고**
Lambda는 함수가 활성 상태이고 요청을 수신하는 경우에만 `ProvisionedConcurrencyUtilization` 지표를 내보냅니다. 비활성 기간에는 지표를 내보내지 않으며 오토 스케일링 경보가 `INSUFFICIENT_DATA` 상태로 전환됩니다. 따라서 Application Auto Scaling은 함수의 프로비저닝된 동시성을 조정할 수 없습니다. 이로 인해 예상치 못한 요금 청구가 발생할 수 있습니다.
다음 예제에서는 프로비저닝된 동시성의 최소 양과 최대 양 사이에서 함수 크기가 사용률에 따라 조정됩니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**범례**
+ ![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/features-scaling-provisioned.instances.png) 함수 인스턴스
+ ![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/features-scaling-provisioned.open.png) 미결 요청
+ ![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) 프로비저닝된 동시성
+ ![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/features-scaling-provisioned.standard.png) 표준 동시성
미결 요청 수가 증가하면 구성된 최대값에 도달할 때까지 Application Auto Scaling이 프로비저닝된 동시성을 큰 폭으로 늘립니다. 이후 계정 동시성 한도에 도달하지 않은 경우 함수는 예약되지 않은 표준 동시성으로 계속 크기를 조정할 수 있습니다. 사용률이 떨어지고 낮게 유지되는 경우 Application Auto Scaling은 프로비저닝된 동시성을 주기적인 작은 단계로 줄입니다.
두 Application Auto Scaling 경보에서는 모두 기본적으로 평균 통계를 사용합니다. 트래픽이 빠르게 버스트되는 함수는 이러한 경보를 트리거하지 않을 수 있습니다. 예를 들어, Lambda 함수가 빠르게 실행되고(예: 20ms\$1100ms) 트래픽에서 빠른 버스트가 발생한다고 가정합니다. 이 경우 버스트 중에 요청 수가 할당된 프로비저닝된 동시성을 초과합니다. 하지만 Application Auto Scaling에서는 추가 환경을 프로비저닝하기 위해 최소 3분 동안 버스트 로드가 지속되어야 합니다. 또한 두 CloudWatch 경보 모두에는 Auto Scaling 정책을 활성화하기 위해 목표 평균에 도달하는 3개의 데이터 포인트가 필요합니다. 함수에서 트래픽이 빠르게 급증하는 경우 **평균** 통계 대신 **최대** 통계를 사용하면 프로비저닝된 동시성의 규모를 조정하여 콜드 스타트를 최소화하는 데 더 효과적일 수 있습니다.
대상 추적 조정 정책에 대한 자세한 내용은 [Application Auto Scaling의 대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
# Lambda 조정 동작
함수가 더 많은 요청을 수신하면 Lambda는이 계정 동시성 할당량에 도달할 때까지 이러한 요청을 처리할 수 있도록 실행 환경 수를 자동으로 스케일 업합니다. 그러나 갑작스러운 트래픽 폭증에 대응한 오버스케일링을 방지하기 위해 Lambda는 함수의 스케일 속도를 제한합니다. 이 **동시성 확장 속도**는 요청 증가에 대응하여 계정의 기능이 스케일 인할 수 있는 최대 속도입니다. (즉, Lambda가 새 실행 환경을 얼마나 빨리 생성할 수 있는지를 의미합니다.) 동시성 확장 속도는 함수에 사용할 수 있는 총 동시성의 양인 계정 수준 동시성 한도와는 다릅니다.
## 동시성 확장 속도
**각 AWS 리전에서, 각 함수에 대한 동시성 규모 조정 속도는 10초당 1,000개의 실행 환경 인스턴스(또는 10초마다 초당 10,000개의 요청)입니다**. 즉, Lambda는 10초당 최대 1,000개의 추가 실행 환경 인스턴스를 각 함수에 할당하거나, 초당 10,000개의 추가 요청을 각 함수에 수용할 수 있습니다.
일반적으로 이 제한 사항에 대해 걱정할 필요는 없습니다. Lambda의 스케일 속도는 대부분의 사용 사례에 충분합니다.
동시성 확장 속도가 함수 수준 제한이라는 점은 중요합니다. 즉, 계정의 각 함수가 다른 함수와 독립적으로 스케일할 수 있다는 의미입니다.
**참고**
실제로 Lambda는 10초당 1,000개의 유닛을 한 번 다시 채우는 대신 시간이 지남에 따라 지속적으로 다시 동시성 확장 속도를 다시 채우기 위해 최선을 다합니다.
Lambda는 동시성 스케일 요금의 미사용 부분을 누적시키지 않습니다. 즉, 어느 시점에서든 조정 속도는 항상 최대 1,000개의 동시 실행 단위라는 의미입니다. 예를 들어 10초 간격으로 사용 가능한 1,000개의 동시 실행 단위를 사용하지 않으면 다음 10초 간격으로 1,000개의 추가 단위가 누적되지 않습니다. 다음 10초 간격에도 동시성 스케일 비율은 여전히 1,000입니다.
함수가 계속해서 점점 더 많은 요청을 수신하는 한, Lambda는 계정의 동시 실행 한도까지 가능한 가장 빠른 속도로 스케일합니다. [예약된 동시성을 구성](configuration-concurrency.md)하여 개별 함수가 사용할 수 있는 동시성의 양을 제한할 수 있습니다. 함수가 확장하는 속도보다 더 빠르게 요청이 수신되거나 함수가 최대 동시성에 도달한 경우 그런 다음 추가 요청은 조절 오류(429 상태 코드)로 인해 실패합니다.
# 동시성 모니터링
Lambda가 함수에 대한 동시성 지표를 모니터링하는 데 도움이 되는 Amazon CloudWatch 지표를 내보냅니다. 이 토픽에서는 이러한 지표와 이를 해석하는 방법을 설명합니다.
**Topics**
+ [
## 일반 동시성 지표
](#general-concurrency-metrics)
+ [
## 프로비저닝된 동시성 지표
](#provisioned-concurrency-metrics)
+ [
## `ClaimedAccountConcurrency` 지표 작업
](#claimed-account-concurrency)
## 일반 동시성 지표
다음 지표를 사용하여 Lambda 함수의 동시성을 모니터링합니다. 각 지표의 단위는 1분입니다.
+ `ConcurrentExecutions` - 지정된 시점의 활성 동시 호출 수입니다. Lambda는 모든 함수, 버전 및 별칭에 대해 이 지표를 내보냅니다. Lambda 콘솔의 모든 함수에 대해 Lambda는 기본적으로 **지표** 아래의 **모니터링** 탭에 `ConcurrentExecutions`에 대한 그래프를 표시합니다. **MAX**를 사용하여 이 지표를 봅니다.
+ `UnreservedConcurrentExecutions` - 예약되지 않은 동시성을 사용하는 활성 동시 호출 수입니다. Lambda는 리전의 모든 함수에 대해 이 지표를 내보냅니다. **MAX**를 사용하여 이 지표를 봅니다.
+ `ClaimedAccountConcurrency` - 온디맨드 간접 호출에 사용할 수 없는 동시 실행 수입니다. `ClaimedAccountConcurrency`는 `UnreservedConcurrentExecutions`에 할당된 동시성 크기를 더한 값과 같습니다(즉, 예약된 총 동시성과 프로비저닝된 총 동시성 합계). `ClaimedAccountConcurrency`가 계정의 동시성 한도를 초과하는 경우 [더 높은 계정 동시성 한도](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)를 요청할 수 있습니다. **MAX**를 사용하여 이 지표를 봅니다. 자세한 내용은 [`ClaimedAccountConcurrency` 지표 작업](#claimed-account-concurrency) 섹션을 참조하세요.
## 프로비저닝된 동시성 지표
다음 지표를 사용하여 프로비저닝된 동시성을 사용하는 Lambda 함수를 모니터링합니다. 각 지표의 단위는 1분입니다.
+ `ProvisionedConcurrentExecutions` – 프로비저닝된 동시성에 대한 호출을 능동적으로 처리하는 실행 환경 인스턴스의 수입니다. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전 및 별칭에 대해 이 지표를 내보냅니다. **MAX**를 사용하여 이 지표를 봅니다.
`ProvisionedConcurrentExecutions`는 할당하는 프로비저닝된 동시성의 총 수와 동일하지 않습니다. 예를 들어, 100단위의 프로비저닝된 동시성을 함수 버전에 할당한다고 가정해 보겠습니다. 지정된 시간 동안 실행 환경 100개 중 최대 50개가 호출을 동시에 처리하는 경우 **MAX**(`ProvisionedConcurrentExecutions`) 값은 50입니다.
+ `ProvisionedConcurrencyInvocations` – Lambda가 프로비저닝된 동시성을 사용하여 함수 코드를 간접 호출되는 횟수입니다. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전 및 별칭에 대해 이 지표를 내보냅니다. **SUM**을 사용하여 이 지표를 봅니다.
`ProvisionedConcurrencyInvocations`는 총 호출 수를 계산하고 `ProvisionedConcurrentExecutions`는 활성 환경 수를 계산한다는 점에서 `ProvisionedConcurrencyInvocations`는 `ProvisionedConcurrentExecutions`와 다릅니다. 이러한 차이를 이해하려면 다음 시나리오를 고려하세요.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
이 예제에서는 분당 1개의 호출을 수신하고 각 호출을 완료하는 데 2분이 걸린다고 가정해 보겠습니다. 각 주황색 가로 막대는 단일 요청을 나타냅니다. 각 요청이 프로비저닝된 동시성에서 실행되도록 이 함수에 10단위의 프로비저닝된 동시성을 할당한다고 가정해 보겠습니다.
0분에서 1분 사이에 `Request 1`이 들어옵니다. **1분에서** **MAX**(`ProvisionedConcurrentExecutions`)의 값은 1입니다. 지난 1분 동안 최대 1개의 실행 환경이 활성화되었기 때문입니다. **SUM**(`ProvisionedConcurrencyInvocations`) 값도 1입니다. 지난 1분 동안 1개의 새 요청이 들어왔기 때문입니다.
1분에서 2분 사이에 `Request 2`가 들어오고 `Request 1`이 계속 실행됩니다. **2분에서** **MAX**(`ProvisionedConcurrentExecutions`)의 값은 2입니다. 지난 1분 동안 최대 2개의 실행 환경이 활성화되었기 때문입니다. 그러나 **SUM**(`ProvisionedConcurrencyInvocations`) 값은 1입니다. 지난 1분 동안 1개의 새 요청만 들어왔기 때문입니다. 이 지표 동작은 예제가 끝날 때까지 계속됩니다.
+ `ProvisionedConcurrencySpilloverInvocations` – 모든 프로비저닝된 동시성을 사용 중인 경우 Lambda가 표준 동시성(예약되거나 예약되지 않은 동시성)을 사용하여 함수를 간접 호출하는 횟수입니다. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전 및 별칭에 대해 이 지표를 내보냅니다. **SUM**을 사용하여 이 지표를 봅니다. `ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations`의 값은 총 함수 호출 수(즉, `Invocations` 지표)와 같아야 합니다.
`ProvisionedConcurrencyUtilization` – 사용 중인 프로비저닝된 동시성의 백분율(즉, `ProvisionedConcurrentExecutions` 값을 할당된 프로비저닝된 동시성의 총량으로 나눈 값). Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전 및 별칭에 대해 이 지표를 내보냅니다. **MAX**를 사용하여 이 지표를 봅니다.
예를 들어, 100단위의 프로비저닝된 동시성을 함수 버전에 프로비저닝한다고 가정해 보겠습니다. 지정된 시간 동안 실행 환경 100개 중 최대 60개가 호출을 동시에 처리하는 경우 **MAX**(`ProvisionedConcurrentExecutions`) 값은 60이고 **MAX**(`ProvisionedConcurrencyUtilization`) 값은 0.6입니다.
`ProvisionedConcurrencySpilloverInvocations` 값이 높으면 함수에 프로비저닝된 동시성을 추가로 할당해야 할 수 있습니다. 또는 사전 정의된 임계값을 기반으로 [프로비저닝된 동시성의 자동 크기 조정을 처리하도록 Application Auto Scaling을 구성](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency)할 수 있습니다.
반대로 `ProvisionedConcurrencyUtilization`의 값이 계속 낮으면 함수에 대해 프로비저닝된 동시성이 과도하게 할당되었을 수 있습니다.
## `ClaimedAccountConcurrency` 지표 작업
Lambda는 `ClaimedAccountConcurrency` 지표를 사용하여 온디맨드 간접 호출에 사용할 수 있는 계정의 동시성 수를 결정합니다. Lambda는 다음 수식을 `ClaimedAccountConcurrency`를 계산합니다.
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions`는 예약되지 않은 동시성을 사용하는 활성 동시 간접 호출 수입니다. 할당된 동시성은 다음 두 부분의 합계입니다(`RC`는 '예약된 동시성', `PC`는 '프로비저닝된 동시성'으로 대체).
+ 리전의 모든 함수에 대한 `RC` 합계.
+ `RC`를 사용하는 함수를 제외하고 `PC`를 사용하는 리전의 모든 함수에서 `PC` 합계.
**참고**
함수에서 `RC`보다 더 많은 `PC`를 할당할 수 없습니다. 따라서 함수의 `RC`는 항상 해당 `PC` 이상입니다. `PC` 및 `RC`를 모두 사용하는 함수에 할당된 동시성의 기여도를 계산할 때 Lambda는 둘 중 최댓값인 `RC`만 고려합니다.
Lambda는 `ConcurrentExecutions` 대신 `ClaimedAccountConcurrency` 지표를 사용하여 온디맨드 간접 호출에 사용할 수 있는 동시성 수를 결정합니다. `ConcurrentExecutions` 지표는 활성 동시 간접 호출 수를 추적하는 데 유용하지만 실제 동시 실행 가능 여부를 항상 반영하는 것은 아닙니다. Lambda는 예약 동시성과 프로비저닝된 동시성도 고려하여 가용성을 결정하기 때문입니다.
`ClaimedAccountConcurrency`를 설명하기 위해 함수 전체에서 많은 예약 동시성과 프로비저닝된 동시성을 구성하지만 거의 사용되지 않는 시나리오를 살펴봅니다. 다음 예제에서는 계정 동시성 한도가 1,000이고 계정에 두 가지 주요 함수(`function-orange` 및 `function-blue`)가 있다고 가정합니다. `function-orange`의 예약된 동시성 단위로 600을 할당합니다. `function-blue`의 프로비저닝된 동시성 단위로 200을 할당합니다. 시간이 지남에 따라 추가 함수를 배포하고 다음 트래픽 패턴을 관찰한다고 가정합니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/claimed-account-concurrency.png)
이전 다이어그램에서 검은색 선은 시간 경과에 따른 실제 동시성 수를 나타내고 빨간색 선은 시간 경과에 따른 `ClaimedAccountConcurrency` 값을 나타냅니다. 함수 전체에서 실제 동시성 사용률은 낮지만 이 시나리오에서는 `ClaimedAccountConcurrency`의 최솟값이 800입니다. `function-orange` 및 `function-blue`에 총 800의 동시성 단위를 할당했기 때문입니다. Lambda의 관점에서 이 동시성을 사용하도록 '청구'했으므로 다른 함수에 사용할 수 있는 남은 동시성 단위는 실제로 200입니다.
이 시나리오에서 할당된 동시성은 `ClaimedAccountConcurrency` 수식에서 800입니다. 그러면 다이어그램의 다양한 지점에서 `ClaimedAccountConcurrency`의 값을 파생시킬 수 있습니다.
+ `t1`에서 `ClaimedAccountConcurrency`는 800(800 \$1 `UnreservedConcurrentExecutions` 0)입니다.
+ `t2`에서 `ClaimedAccountConcurrency`는 900(800 \$1 `UnreservedConcurrentExecutions` 100)입니다.
+ `t3`에서 `ClaimedAccountConcurrency`는 다시 900(800 \$1 `UnreservedConcurrentExecutions` 100)입니다.
### CloudWatch에서 `ClaimedAccountConcurrency` 지표 설정
Lambda는 CloudWatch에서 `ClaimedAccountConcurrency` 지표를 생성합니다. 다음 수식과 같이 계정의 동시성 사용률 퍼센트를 얻기 위해 `SERVICE_QUOTA(ConcurrentExecutions)`의 값과 함께 이 지표를 사용합니다.
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
다음 스크린샷은 CloudWatch에서 이 수식을 그래프로 표시하는 방법을 보여줍니다. 녹색 `claim_utilization` 선은 이 계정의 동시성 사용률을 나타내며, 약 40%입니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
이전 스크린샷에는 동시성 사용률이 70%를 초과할 때 `ALARM` 상태가 되는 CloudWatch 경보도 포함되어 있습니다. 유사한 경보와 함께 `ClaimedAccountConcurrency` 지표를 사용하여 계정 동시성 한도 상향 조정을 요청해야 하는 시기를 사전에 결정할 수 있습니다.