# Lambda 関数のスケーリングについて
**同時実行数**とは、AWS Lambda 関数が同時に処理できる未完了のリクエストの数のことです。Lambda は、同時実行リクエストごとに、実行環境の個別のインスタンスをプロビジョニングします。関数が受け取るリクエストが増えると、Lambda が実行環境数のスケーリングを自動的に処理し、これはアカウントの同時実行上限に達するまで行われます。Lambda はアカウントに対し、1 つの AWS リージョン内のすべての関数全体での合計数 1,000 を上限とした同時実行をデフォルトで提供しています。特定のアカウントニーズをサポートするため、[クォータの引き上げをリクエスト](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)したり、関数レベルでの同時実行コントロールを設定したりして、重要な関数でスロットリングが発生しないようにすることができます。
このトピックでは、Lambda での同時実行数と関数スケーリングについて説明します。このトピックを読み終える頃には、同時実行を計算する、2 つの主な同時実行コントロールオプション (予約された同時実行とプロビジョニングされた同時実行) を視覚化する、適切な同時実行コントロール設定を見積もる、およびさらなる最適化のためのメトリクスを表示する方法を理解できるようになります。
**Topics**
+ [
## 同時実行の概要と視覚化
](#understanding-concurrency)
+ [
## 関数の同時実行数の計算
](#calculating-concurrency)
+ [
## 予約済み同時実行数とプロビジョニングされた同時実行数について
](#reserved-and-provisioned)
+ [
## 同時実行数と 1 秒あたりのリクエスト数について
](#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-ib)) してから、それを使用して関数を呼び出す ([呼び出しフェーズ](lambda-runtime-environment.md#runtimes-lifecycle-invoke)) 必要があります。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-1-environment.png)
**注記**
実際の初期化と呼び出しの所要時間は、選択したランタイムや Lambda 関数コードなど、さまざまな要因に応じて異なります。上記の図は、初期化フェーズと呼び出しフェーズの所要時間の正確な割合を表すものではありません。
上記の図では、長方形を使用して単一の実行環境を表しています。関数が最初のリクエスト (ラベル `1` が付いた黄色い円) を受け取ると、Lambda が初期化フェーズ中に新しい実行環境を作成し、メインハンドラー外でコードを実行します。次に、Lambda は呼び出しフェーズ中に関数のメインハンドラーコードを実行します。この実行環境は、このプロセス全体を通じてビジー状態になり、他のリクエストを処理することはできません。
この実行環境は、Lambda が最初のリクエストの処理を終了した時点で、同じ関数に対する追加のリクエストを処理できるようになります。Lambda が、後続のリクエストのために実行環境を再度初期化する必要はありません。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-2-two-requests.png)
上記の図では、Lambda が実行環境を再利用して 2 番目のリクエスト (ラベル `2` が付いた黄色の円) を処理します。
これまでは、実行環境の単一のインスタンス (つまり、1 個の同時実行) のみに焦点を当ててきました。実際には、すべての受信リクエストを処理するために、Lambda は複数の実行環境インスタンスを並行してプロビジョニングする必要がある場合があります。関数が新しいリクエストを受け取ると、以下の 2 つのいずれかが行われる可能性があります。
+ 事前に初期化された実行環境インスタンスが利用できる場合は、Lambda がそれを使用してリクエストを処理する。
+ 利用できない場合は、Lambda が新しい実行環境インスタンスを作成してリクエストを処理する。
例として、関数が 10 個のリクエストを受け取った場合について検証してみましょう。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-3-ten-requests.png)
上記の図では、各横棒が単一の実行環境インスタンス (`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 はそれに応じて実行環境インスタンスの数をスケールアップします。以下のアニメーションは、同時リクエストの数を経時的に追跡するものです。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-4-animation.gif)
上記のアニメーションを 6 つの異なる時点で停止すると、以下の図が得られます。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-5-animation-summary.png)
上記の図では、任意の時点で垂直の線を引いて、その線に交差する環境の数を数えることができます。そうすることで、その時点での同時リクエストの数がわかります。例えば、`t1` の時点では、3 件の同時リクエストを処理する 3 個のアクティブな環境があります。このシミュレーションでは、`t4` の時点で最大数の同時リクエストが行われており、6 個のアクティブな環境が 6 件の同時リクエストを処理しています。
要約すると、関数の同時実行とは、関数が同時に処理している同時リクエストの数になります。Lambda は、関数の同時実行の増加に対応してより多くの実行環境インスタンスをプロビジョニングし、リクエストの需要を満たします。
## 関数の同時実行数の計算
一般に、システムの同時実行性とは、複数のタスクを同時に処理する能力のことです。Lambda での同時実行は、関数が同時に処理している未完了のリクエストの数です。Lambda 関数の同時実行を測定するためのすばやく実用的な方法は、以下の式を使用することです。
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
**同時実行の数は、1 秒あたりのリクエスト数とは異なります。**例えば、関数が 1 秒あたり平均 100 件のリクエストを受け取るとします。リクエストの平均所要時間が 1 秒の場合、同時実行の数も 100 になります。
```
Concurrency = (100 requests/second) * (1 second/request) = 100
```
ただし、リクエストの平均所要時間が 500 ミリ秒の場合、同時実行の数は 50 になります。
```
Concurrency = (100 requests/second) * (0.5 second/request) = 50
```
同時実行の数が 50 というのは、実際に何を意味するのでしょうか？ リクエストの平均所要時間が 500 ミリ秒の場合、関数のインスタンスは 1 秒あたり 2 件のリクエストを処理できると考えられます。その場合、1 秒あたり 100 リクエストの負荷を処理するには、関数のインスタンスが 50 個必要です。50 の同時実行は、このワークロードをスロットリングなしで効率的に処理するには Lambda が 50 個の実行環境インスタンスをプロビジョニングする必要があることを意味します。これを方程式で表現すると、以下のようになります。
```
Concurrency = (100 requests/second) / (2 requests/second) = 50
```
関数が 2 倍のリクエスト (1 秒あたり 200 件のリクエスト) を受け取り、各リクエストの処理に半分の時間 (250 ミリ秒) しか必要ない場合でも、同時実行の数は 50 のままです。
```
Concurrency = (200 requests/second) * (0.25 second/request) = 50
```
### 同時実行に関する理解度をテストする
実行に平均 200 ミリ秒かかる関数があるとします。負荷のピーク時には、1 秒あたり 5,000 件のリクエストがあります。負荷のピーク時における関数の同時実行の数を計算してください。
#### 回答
関数の平均所要時間は 200 ミリ秒、つまり 0.2 秒です。同時実行の式を使用し、これらの数値を代入すると、同時実行の数は 1,000 になります。
```
Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000
```
言い換えると、関数の平均所要時間が 200 ミリ秒の場合、その関数は 1 秒あたり 5 件のリクエストを処理できることになります。1 秒あたり 5,000 リクエストのワークロードを処理するには、1,000 個の実行環境インスタンスが必要です。したがって、同時実行の数は 1,000 になります。
```
Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000
```
## 予約済み同時実行数とプロビジョニングされた同時実行数について
デフォルトで、アカウントの同時実行はリージョン内のすべての関数全体で 1,000 に制限されています。関数は、この 1,000 の同時実行のプールをオンデマンドで共有します。利用できる同時実行数が不足すると、関数でスロットリングが発生します (つまり、リクエストがドロップされ始めます)。
関数の中には、他の関数よりも重要なものがあります。そのため、重要な関数が必要な同時実行を利用できるように、同時実行を設定することをお勧めします。同時実行コントロールには、予約された同時実行とプロビジョニングされた同時実行の 2 つのタイプのコントロールがあります。
+ **予約済み同時実行数**を使用して、同時インスタンスの最大数と最小数の両方を設定し、アカウントの同時実行数の一部を関数用に予約します。これは、他の関数が利用可能な予約されていない同時実行のすべてを使い切ってしまわないようにするために役立ちます。ある関数が予約済み同時実行を使用している場合、他の関数はその同時実行を使用できません。
+ **プロビジョニングされた同時実行**は、関数用の多数の環境インスタンスを事前に初期化するために使用します。これはコールドスタートレイテンシーの削減に役立ちます。
### 予約された同時実行
関数のために一定数の同時実行が常に利用可能であることを確実にしたい場合は、予約された同時実行を使用します。
予約済み同時実行数で、関数に割り当てる同時インスタンスの最大数と最小数を設定します。予約された同時実行を 1 つの関数専用の同時実行にすると、他の関数がその同時実行を使用することはできません。つまり、予約された同時実行の設定は、他の関数が利用できる同時実行のプールに影響を与える可能性があります。予約された同時実行がない関数は、残りの予約されていない同時実行のプールを共有します。
予約された同時実行の設定は、アカウント全体の同時実行上限にカウントされます。関数に対して予約済み同時実行を設定する場合、料金はかかりません。
予約された同時実行に関する理解を深めるため、以下の図を検証しましょう。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
この図では、このリージョン内のすべての関数に対するアカウントの同時実行上限が、デフォルト上限の 1,000 になっています。`function-blue` と `function-orange` の 2 つの重要な関数があり、大量の呼び出しが定期的に行われることが見込まれているとします。`function-blue` に予約された同時実行を 400 ユニット、`function-orange` にも予約された同時実行を 400 ユニット割り当てることにしました。この例では、アカウント内のその他すべての関数が、残りの予約されていない同時実行 200 ユニットを共有する必要があります。
この図には、以下の 5 つの注目点があります。
+ `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/ja_jp/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
この図には、次の 4 つの注目点があります。
| 時間 | 予約された同時実行 | プロビジョニングされた同時実行 |
| --- | --- | --- |
| t1 | 何も実行されません。 | Lambda が実行環境インスタンスを事前に初期化します。 |
| t2 | リクエスト 1 を受け取ります。Lambda は新しい実行環境インスタンスを初期化する必要があります。 | リクエスト 1 を受け取ります。Lambda は事前に初期化された環境インスタンスを使用します。 |
| t3 | アイドル時間がしばらく続くと、Lambda がアクティブな環境インスタンスを終了します。 | 何も実行されません。 |
| t4 | リクエスト 2 を受け取ります。Lambda は新しい実行環境インスタンスを初期化する必要があります。 | リクエスト 2 を受け取ります。Lambda は事前に初期化された環境インスタンスを使用します。 |
プロビジョニングされた同時実行に関する理解を深めるために、以下の図を検証しましょう。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
この図では、アカウントの同時実行上限が 1,000 になっています。`function-orange` にプロビジョニングされた同時実行を 400 ユニット設定することにしました。`function-orange` を*含めた*アカウント内のすべての関数が、残りの予約されていない同時実行 600 ユニットを使用できます。
この図には、以下の 5 つの注目点があります。
+ `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/ja_jp/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
この図では、`function-orange` のために、プロビジョニングされた同時実行を 200 ユニット、および予約された同時実行を 400 ユニット設定するとします。予約された同時実行を設定したので、`function-orange` が 600 ユニットの予約されていない同時実行を使用することはできません。
この図には、以下の 5 つの注目点があります。
+ `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 アカウントに料金が請求されます。
**注記**
関数の Versions and Aliases に割り当てたプロビジョニングされた同時実行数が、関数の予約された同時実行数に達すると、すべての呼び出しはプロビジョニングされた同時実行数を使用して実行されます。この設定には、非公開バージョンの関数 (`$LATEST`) をスロットリングする効果もあるため、その関数は実行されません。関数に対し、予約済同時実行数よりも多くのプロビジョニングされた同時実行を割り当てることはできません。
関数用にプロビジョニングされた同時実行の設定を管理するには、「[関数に対するプロビジョニングされた同時実行数の設定](provisioned-concurrency.md)」を参照してください。スケジュールまたはアプリケーションの使用状況に基づいてプロビジョニングされた同時実行のスケーリングを自動化するには、「[Application Auto Scaling を使用してプロビジョニングされた同時実行数の管理を自動化する](provisioned-concurrency.md#managing-provisioned-concurency)」を参照してください。
### Lambda がプロビジョニングされた同時実行性を割り当てる方法
プロビジョニング済み同時実行は、設定後すぐにはオンラインになりません。Lambda は、1～2 分の準備後に、プロビジョニング済み同時実行の割り当てをスタートします。AWS リージョン とは関係なく、Lambda は、関数ごとに 1 分あたり最大 6,000 個の実行環境をプロビジョニングできます。これは関数の[同時実行スケーリングレート](scaling-behavior.md#scaling-rate)とまったく同じです。
プロビジョニングされた同時実行を割り当てるリクエストを送信すると、Lambda が割り当てを完全に完了するまで、それらの環境にはアクセスできません。例えば、5,000 個のプロビジョニングされた同時実行をリクエストした場合、Lambda が 5,000 個の実行環境の配分を完全に終了するまで、リクエストでプロビジョニングされた同時実行を使用することはできません。
### 予約された同時実行とプロビジョニングされた同時実行の比較
以下の表は、予約された同時実行とプロビジョニングされた同時実行を要約し、比較したものです。
| Topic | 予約された同時実行 | プロビジョニングされた同時実行 |
| --- | --- | --- |
| 定義 | 関数の実行環境インスタンスの最大数。 | 関数用に事前にプロビジョニングされた、一定数の実行環境インスタンス。 |
| プロビジョニング動作 | Lambda が新しいインスタンスをオンデマンドベースでプロビジョニングします。 | Lambda がインスタンスを事前に (つまり、関数がリクエストの受け取りを開始する前に) プロビジョニングします 。 |
| コールドスタート動作 | Lambda はオンデマンドで新しいインスタンスを作成する必要があることから、コールドスタートレイテンシーが発生する可能性があります。 | Lambda はオンデマンドでインスタンスを作成する必要がないため、コールドスタートレイテンシーが発生することはありません。 |
| スロットリング動作 | 予約された同時実行の上限に達すると、関数がスロットルされます。 | 予約された同時実行が設定されていない場合: プロビジョニングされた同時実行の上限に達すると、関数は予約されていない同時実行を使用します。 予約された同時実行数が設定されている場合: 予約された同時実行の上限に達すると、関数がスロットルされます。 |
| 設定されていない場合のデフォルト動作 | 関数は、アカウントで利用できる、予約されていない同時実行を使用します。 | Lambda はインスタンスを事前にプロビジョニングしません。その代わり、予約された同時実行が設定されていない場合、関数はアカウントで利用できる、予約されていない同時実行を使用します。 予約された同時実行が設定されている場合: 関数は予約された同時実行を使用します。 |
| 料金 | 追加料金はありません。 | 追加料金が発生します。 |
## 同時実行数と 1 秒あたりのリクエスト数について
前のセクションで述べたように、同時実行の数は、秒あたりのリクエスト数とは異なります。この違いは、平均リクエスト時間が 100 ミリ秒未満の関数を扱う場合に特に重要になります。
アカウントのすべての関数で、Lambda はアカウントの同時実行数の 10 倍に相当する 1 秒あたりのリクエスト数の制限を適用します。例えば、デフォルトのアカウントの同時実行上限は 1,000 であるため、アカウントの関数は 1 秒あたり最大 10,000 件のリクエストを処理できます。
例えば、平均リクエスト時間が 50 ミリ秒の関数を考えてみましょう。1 秒あたり 20,000 件のリクエストの場合、この関数の同時実行数は次のようになります。
```
Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000
```
この結果に基づいて、アカウントの同時実行上限である 1,000 が、この負荷を処理するのに十分であると予想できます。ただし、1 秒あたりのリクエスト数が 10,000 に制限されているため、関数は合計 20,000 リクエストのうち 1 秒あたり 10,000 リクエストしか処理できません。この関数ではスロットリングが発生します。
ここで重要なのは、関数の同時実行設定を行う際には、同時実行と 1 秒あたりのリクエスト数の両方を考慮する必要があるということです。この場合、アカウントの同時実行上限を 2,000 に引き上げるようにリクエストする必要があります。そうすれば、1 秒あたりの合計リクエスト数を 20,000 に引き上げることができます。
**注記**
この 1 秒あたりのリクエスト数の制限に基づくと、各 Lambda 実行環境が 1 秒あたり最大 10 件のリクエストしか処理できないとするのは誤りです。個々の実行環境の負荷を観察する代わりに、Lambda は、クォータを計算するときに全体的な同時実行数と 1 秒あたりの全体的なリクエスト数のみを考慮します。
### 同時実行 (100 ミリ秒未満の関数) についての理解度をテスト
実行に平均 20 ミリ秒かかる関数があるとします。負荷のピーク時には、1 秒あたり 30,000 件のリクエストがあります。負荷のピーク時における関数の同時実行の数を計算してください。
#### 回答
関数の平均所要時間は 20 ミリ秒、つまり 0.02 秒です。同時実行の式を使用し、これらの数値を代入すると、同時実行の数は 600 になります。
```
Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600
```
デフォルトのアカウントの同時実行上限である 1,000 は、この負荷を処理するのに十分であると考えられます。ただし、1 秒あたりのリクエスト数が 10,000 に制限されると、1 秒あたり 30,000 件の受信リクエストを処理する場合に十分ではありません。30,000 件のリクエストに完全に対応するには、アカウントの同時実行上限を 3,000 以上に引き上げるようにリクエストする必要があります。
1 秒あたりのリクエスト数の制限は、同時実行を含む Lambda のすべてのクォータに適用されます。つまり、同期オンデマンド関数、プロビジョニングされた同時実行を使用する関数、および[同時実行のスケーリング動作](scaling-behavior.md)に適用されます。例えば、同時実行数と 1 秒あたりのリクエスト数の制限の両方を慎重に検討する必要があるシナリオを次に示します。
+ オンデマンド同時実行を使用する関数では、同時実行数と 1 秒あたりのリクエスト数のどちらかが、10 秒ごとにそれぞれ 500 と 5,000 まで急激に増加する可能性があります。
+ プロビジョニングされた同時実行割り当てが 10 の関数があるとします。この関数は、同時実行数と 1 秒あたりのリクエスト数のどちらかが、それぞれ 10 と 100 に達すると、オンデマンド同時実行にスピルオーバーします。
## 同時実行のクォータ
Lambda は、リージョン内のすべての関数全体で使用できる同時実行の合計数に対するクォータを設定しています。これらのクォータは、次の 2 つのレベルで設定されています。
+ **アカウントレベル**では、関数がデフォルトで最大 1,000 ユニットの同時実行を使用できます。クォータの引き上げをリクエストするには、「Service Quotas User Guide」(Service Quotas ユーザーガイド) の「[Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」(クォータ引き上げのリクエスト) を参照してください。
+ **関数レベルでは**、すべての関数全体で最大 900 ユニットの同時実行をデフォルトで予約できます。アカウントの同時実行数の合計制限に関係なく、Lambda は同時実行を明示的に予約しない関数に対して常に 100 ユニットの同時実行を予約します。例えば、アカウントの同時実行上限を 2,000 に引き上げた場合、関数レベルでは最大 1,900 ユニットの同時実行を予約できます。
+ アカウントレベルと関数レベルの両方で、Lambda は対応する同時実行クォータの 10 倍に相当する 1 秒あたりのリクエスト数の制限も適用します。例えば、これはアカウントレベルの同時実行、オンデマンド同時実行を使用する関数、プロビジョニングされた同時実行を使用する関数、および[同時実行のスケーリング動作](scaling-behavior.md)に適用されます。詳細については、「[同時実行数と 1 秒あたりのリクエスト数について](#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 秒ごとに 1 秒あたり 10,000 リクエスト) です。**つまり、Lambda は 10 秒ごとに最大 1,000 の追加実行環境インスタンスを各関数に割り当てるか、または 1 秒あたり 10,000 件の追加リクエストに対応できます。
通常、この制限について心配する必要はありません。ほとんどのユースケースでは、Lambda のスケーリングレートで十分です。
重要なのは、同時実行のスケーリングレートは関数レベルの上限であることです。つまり、アカウント内の各関数は、他の関数とは別個にスケールできます。
スケーリング動作の詳細については、「[Lambda のスケーリング動作](scaling-behavior.md)」を参照してください。
# 関数に対する予約済み同時実行数の設定
Lambda での[同時実行](lambda-concurrency.md)は、関数が現在処理している未完了のリクエストの数です。利用できる同時実行コントロールには、次の 2 種類があります。
+ 予約済同時実行数 — 関数に割り当てられた同時インスタンスの最大数と最小数を設定します。ある関数が予約済み同時実行を使用している場合、他の関数はその同時実行を使用できません。予約済み同時実行数は、最も重要な関数が受信リクエストを処理するのに十分な同時実行数を常に確保するのに役立ちます。さらに、予約済同時実行数は、データベース接続などのダウンストリームリソースが過負荷になるのを防ぐために同時実行を制限するために使用できます。予約済同時実行数は、下限と上限の両方の役割を果たします。これは指定されたキャパシティを関数専用に予約しつつ、それを超えるスケーリングを抑制します。。関数に対して予約される同時実行を設定する場合には追加料金がかかりません。
+ プロビジョニングされた同時実行 — これは、関数に割り当てる、事前に初期化された実行環境の数です。これらの実行環境は、受信した関数リクエストに即座に対応できます。プロビジョニングされた同時実行は、関数のコールドスタートレイテンシーを減らすのに役立ち、数十ミリ秒の応答時間で使用できるように設計されています。一般に、この機能のメリットを最も享受するのはインタラクティブワークロードです。ウェブアプリケーションやモバイルアプリケーションなど、これらはユーザーがリクエストを開始するアプリケーションであり、レイテンシーに最も敏感です。データ処理パイプラインなどの非同期ワークロードは、レイテンシーの影響を受けにくいことが多いため、通常はプロビジョニングされた同時実行数は必要ありません。プロビジョニングされた同時実行を設定すると、AWS アカウント に追加料金が請求されます。
このトピックでは、予約済み同時実行数を管理および設定する方法について説明します。これら 2 種類の同時実行制御の概念的な概要については、「[予約同時実行とプロビジョニング同時実行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)」を参照してください。プロビジョニングされた同時実行数の設定の詳細については、[関数に対するプロビジョニングされた同時実行数の設定](provisioned-concurrency.md) を参照してください。
**注記**
Amazon MQ イベントソースマッピングにリンクされた Lambda 関数には、デフォルトの最大同時実行数があります。Apache ActiveMQ の場合、同時インスタンスの最大数は 5 です。RabbitMQ の場合、同時インスタンスの最大数は 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. [**設定**]、[**同時実行**] の順にクリックします。
1. [**同時実行数**] で、[**編集**] をクリックします。
1. [**同時実行の予約**] をクリックします。関数用に予約する同時実行の量を入力します。
1. **[保存]** をクリックします。
**[予約されていないアカウントの同時実行]** の値から 100 を引いた値まで予約できます。残りの 100 単位の同時実行は、予約された同時実行を使用しない関数用です。例えば、アカウントの同時実行の上限が 1,000 の場合、1 つの関数で同時実行の 1,000 ユニットすべては予約できません。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
関数の同時実行数を予約すると、他の関数で使用できる同時実行数のプールに影響を与えることがあります。たとえば、`function-a` の同時実行に 100 ユニットを予約した場合、`function-a` が予約された同時実行の 100 ユニットすべてを使用しなくても、アカウント内の他の関数は残りの 900 ユニットの同時実行を共有する必要があります。
意図的に関数をスロットリングするには、予約済同時実行数をゼロに設定します。これにより、制限を削除するまで、関数のイベント処理が停止します。
以下の API オペレーションを使用して、Lambda 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/ja_jp/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
グラフによると、この関数は通常、1 日平均 5～10 件、最大で 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)
```
1 秒あたりの平均リクエスト数に平均リクエスト時間 (秒単位) を掛けると、予約する必要がある同時実行数の大まかな見積もりが得られます。1 秒あたりの平均リクエスト数は `Invocation` メトリクスを、平均リクエスト時間 (秒単位) は `Duration` メトリクスを使用して見積もることができます。詳細については、「[Lambda での CloudWatch メトリクスの使用](monitoring-metrics.md)」を参照してください。
アップストリームおよびダウンストリームでのスループットの制約について理解を深める必要があります。Lambda 関数は負荷に応じてシームレスにスケールしますが、アップストリームとダウンストリームの依存関係においてスループット能力は同じではない場合があります。関数のスケールの上限を制限する必要がある場合、関数で予約された同時実行数を設定します。
# 関数に対するプロビジョニングされた同時実行数の設定
Lambda での[同時実行](lambda-concurrency.md)は、関数が現在処理している未完了のリクエストの数です。利用できる同時実行コントロールには、次の 2 種類があります。
+ 予約済同時実行数 — 関数に割り当てられた同時インスタンスの最大数と最小数を設定します。ある関数が予約済み同時実行を使用している場合、他の関数はその同時実行を使用できません。予約済み同時実行数は、最も重要な関数が受信リクエストを処理するのに十分な同時実行数を常に確保するのに役立ちます。さらに、予約済同時実行数は、データベース接続などのダウンストリームリソースが過負荷になるのを防ぐために同時実行を制限するために使用できます。予約済同時実行数は、下限と上限の両方の役割を果たします。これは指定されたキャパシティを関数専用に予約しつつ、それを超えるスケーリングを抑制します。。関数に対して予約される同時実行を設定する場合には追加料金がかかりません。
+ プロビジョニングされた同時実行 — これは、関数に割り当てる、事前に初期化された実行環境の数です。これらの実行環境は、受信した関数リクエストに即座に対応できます。プロビジョニングされた同時実行は、関数のコールドスタートレイテンシーを減らすのに役立ち、数十ミリ秒の応答時間で使用できるように設計されています。一般に、この機能のメリットを最も享受するのはインタラクティブワークロードです。ウェブアプリケーションやモバイルアプリケーションなど、これらはユーザーがリクエストを開始するアプリケーションであり、レイテンシーに最も敏感です。データ処理パイプラインなどの非同期ワークロードは、レイテンシーの影響を受けにくいことが多いため、通常はプロビジョニングされた同時実行数は必要ありません。プロビジョニングされた同時実行を設定すると、AWS アカウント に追加料金が請求されます。
このトピックでは、プロビジョニング済み同時実行を管理および設定する方法について説明します。これら 2 種類の同時実行制御の概念的な概要については、「[予約済み同時実行とプロビジョニング済み同時実行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)」を参照してください。予約済み同時実行の設定の詳細については、「[関数に対する予約済み同時実行数の設定](configuration-concurrency.md)」を参照してください。
**注記**
Amazon MQ イベントソースマッピングにリンクされた Lambda 関数には、デフォルトの最大同時実行数があります。Apache ActiveMQ の場合、同時インスタンスの最大数は 5 です。RabbitMQ の場合、同時インスタンスの最大数は 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. **[設定]**、**[同時実行]** の順にクリックします。
1. **[プロビジョニング済み同時実行の設定]** で、**[設定を追加]** をクリックします。
1. 修飾子のタイプ、エイリアスまたはバージョンを選択します。
**注記**
プロビジョニング済み同時実行は、どの関数の \$1LATEST バージョンでも使用できません。
関数にイベントソースがある場合は、そのイベントソースが正しい関数エイリアスまたはバージョンを指していることを確認してください。正しくない場合、関数はプロビジョニング済み同時実行環境を使用しません。
1. **[プロビジョニング済み同時実行]** に数値を入力します。
1. **[保存]** を選択します。
アカウントで設定できるのは、**予約なしアカウントの同時実行数**から 100 を引いた数までです。残りの 100 単位の同時実行数は、予約済み同時実行を使用しない関数用です。たとえば、アカウントの同時実行数の制限が 1,000 で、他の関数に予約済みまたはプロビジョニング済み同時実行を割り当てていない場合、1 つの関数に対して最大 900 のプロビジョニング済み同時実行単位を設定できます。
![\[\]](http://docs.aws.amazon.com/ja_jp/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/ja_jp/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
グラフによると、この関数は平均 5～10 件、最大で 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)
```
必要な同時実行数を見積もるには、秒ごとの平均リクエスト数に平均リクエスト時間 (秒単位) を掛けます。1 秒あたりの平均リクエスト数は `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` の 3 つの値から 1 つを選択します。
+ `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)を [platform-initReport](telemetry-schema-reference.md#platform-initReport) ログイベントに JSON ログ形式で記録します。このログイベントを表示するには、[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 コンピューティングブログ」の「[定期的なピーク使用量に対する AWS Lambda のプロビジョニング済み同時実行のスケジューリング](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% 近くに維持します。ただし、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 に 2 つのアラームを作成します。最初のアラームは、プロビジョニング済み同時実行の使用率が一貫して 70% を超えたときにトリガーされます。これにより、Application Auto Scaling はプロビジョニング済み同時実行の割り当て数を増やして、使用率を下げます。2 番目のアラームは、使用率が一貫して 63% (70% ターゲットの 90%) を下回った場合にトリガーされます。これにより、Application Auto Scaling はエイリアスのプロビジョニング済み同時実行数を減らします。
**注記**
Lambda は、関数がアクティブでリクエストを受信している場合にのみ、 `ProvisionedConcurrencyUtilization` メトリクスを出力します。非アクティブの間はメトリクスは出力されず、自動スケーリングアラームは `INSUFFICIENT_DATA` 状態になります。その結果、Application Auto Scaling は関数のプロビジョニングされた同時実行数を調整することができません。これにより、予想外の請求が発生することがあります。
次の例では、関数が使用率に基づいて、プロビジョニング済み同時実行の最小値と最大値の間でスケールします。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**凡例**
+ ![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-scaling-provisioned.instances.png) 関数のインスタンス数
+ ![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-scaling-provisioned.open.png) 未処理のリクエスト数
+ ![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) プロビジョニング済み同時実行
+ ![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-scaling-provisioned.standard.png) 標準の同時実行数
オープンリクエストの数が増加すると、Application Auto Scaling は設定された最大値に達するまで、プロビジョニング済み同時実行数を大規模なステップで増加させます。この後、アカウントの同時実行数の上限に達していなければ、関数は引き続き標準の予約されていない同時実行でスケールできます。使用率が下がり、低いまま続く場合、Application Auto Scaling はプロビジョニングされた同時実行数を減少させるために、より小規模な定期的ステップを実行します。
Application Auto Scaling アラームはどちらも、デフォルトで平均統計を使用します。トラフィックのクイックバーストが起こる関数は、これらのアラームをトリガーしない可能性があります。例えば、Lambda 関数が瞬間的に (20～100 ミリ秒) 実行され、トラフィックがクイックバーストしたとします。この場合、バースト中はリクエスト数が割り当てられた同時実行数を超えます。ただし、Application Auto Scaling では、追加の環境をプロビジョニングするために、バーストロードを少なくとも 3 分間維持する必要があります。さらに、両方の CloudWatch アラームでは、自動スケーリングポリシーを有効にするために、ターゲット平均に達している 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 秒ごとに 1 秒あたり 10,000 リクエスト) です。**つまり、Lambda は 10 秒ごとに最大 1,000 の追加実行環境インスタンスを各関数に割り当てるか、または 1 秒あたり 10,000 件の追加リクエストに対応できます。
通常、この制限について心配する必要はありません。ほとんどのユースケースでは、Lambda のスケーリングレートで十分です。
重要なのは、同時実行のスケーリングレートは関数レベルの上限であることです。つまり、アカウント内の各関数は、他の関数とは別個にスケールできます。
**注記**
実際には、Lambda は 10 秒ごとに 1,000 ユニットを 1 回補充するのではなく、同時実行のスケーリングレートを時間経過と共に継続的に補充するよう最大限試みます。
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 ユニットのプロビジョニングされた同時実行を関数バージョンに割り当てるとします。任意の 1 分間で、100 個の実行環境のうち最大 50 個が同時に呼び出しを処理していた場合、**MAX** (`ProvisionedConcurrentExecutions`) の値は 50 になります。
+ `ProvisionedConcurrencyInvocations` – Lambda がプロビジョニングされた同時実行を使用して関数コードを呼び出す回数。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。**SUM** を使用してこのメトリクスを表示します。
`ProvisionedConcurrencyInvocations` は呼び出しの総数をカウントしますが、`ProvisionedConcurrentExecutions` はアクティブな環境の数をカウントするという点で、`ProvisionedConcurrencyInvocations` は `ProvisionedConcurrentExecutions` と異なります。この違いを理解するために、次のシナリオを考えてみます。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
この例では、1 分あたり 1 回の呼び出しを受け取り、各呼び出しの完了までに 2 分かかるとします。オレンジ色の横棒はそれぞれ 1 つのリクエストを表します。この関数に 10 ユニットのプロビジョニングされた同時実行を割り当て、各リクエストがプロビジョニングされた同時実行で実行されるとします。
0 分と 1 分の間に `Request 1` が入ります。**1 分の時点**では、それまでの 1 分間でアクティブだった実行環境は最大 1 つなので、**MAX** (`ProvisionedConcurrentExecutions`) の値は 1 です。それまでの 1 分間に入った新しいリクエストは 1 件だったため、**SUM** (`ProvisionedConcurrencyInvocations`) の値も 1 です。
1 分から 2 分の間に `Request 2` が入り、`Request 1` は実行し続けます。**2 分の時点**では、それまでの 1 分間でアクティブだった実行環境は最大 2 つなので、**MAX** (`ProvisionedConcurrentExecutions`) の値は 2 です。ただし、それまでの 1 分間に入った新しいリクエストは 1 件のみだったため、**SUM** (`ProvisionedConcurrencyInvocations`) の値は 1 です。このメトリクスの動作は、この例の終わりまで継続します。
+ `ProvisionedConcurrencySpilloverInvocations` – プロビジョニングされた同時実行がすべて使用されているときに、Lambda が標準的な同時実行 (予約された同時実行または予約されていない同時実行) で関数を呼び出す回数。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。**SUM** を使用してこのメトリクスを表示します。`ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` の値は、関数呼び出しの総数 (`Invocations` メトリクス) と一致するはずです。
`ProvisionedConcurrencyUtilization` - 使用中のプロビジョニングされた同時実行の割合 (`ProvisionedConcurrentExecutions` をプロビジョニングされた割り当て同時実行の合計量で割った値)。Lambda は、プロビジョニングされた同時実行が設定された関数バージョンとエイリアスごとにこのメトリクスを出力します。**MAX** を使用してこのメトリクスを表示します。
例えば、100 ユニットのプロビジョニングされた同時実行を関数バージョンにプロビジョニングするとします。任意の 1 分間で、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` は、予約されていない同時実行を使用している、アクティブな同時呼び出しの数です。割り当てられた同時実行数は、次の 2 つの部分の合計です (`RC` は「予約された同時実行」、`PC` は「プロビジョニングされた同時実行」に置き換えます)。
+ リージョン内のすべての関数の合計 `RC`。
+ リージョン内で `PC` を使用しているすべての関数の合計 `PC`。`RC` を使用する関数は除きます。
**注記**
1 つの関数に `RC` よりも多い `PC` を割り当てることはできません。したがって、関数の `RC` は常に、その関数の `PC` と同数かそれよりも多くなります。Lambda では、`PC` および `RC` によるこのような関数に割り当てられた同時実行性への寄与度を算出する際に、この 2 つのうちの最大値である、`RC` のみを考慮します。
Lambda は `ConcurrentExecutions` ではなく `ClaimedAccountConcurrency` メトリックスを使用して、アカウントがオンデマンド呼び出しに使用できる同時実行の量を判断します。`ConcurrentExecutions` メトリックスはアクティブな同時呼び出しの数を追跡するのに役立ちますが、実際の同時実行の可用性を必ずしも反映しているわけではありません。これは、Lambda では予約された同時実行とプロビジョニングされた同時実行も考慮して可用性を判断するためです。
`ClaimedAccountConcurrency` の例として、ほとんど使用されなくなっている関数全体で、多くの予約された同時実行とプロビジョニングされた同時実行を設定するシナリオを考えてみましょう。次の例では、アカウントの同時実行数の上限が 1,000 で、アカウントにとの 2 つの主要関数 `function-orange`、`function-blue` があるとします。`function-orange` には 600 単位の予約された同時実行を割り当てます。`function-blue` には 200 単位のプロビジョニングされた同時実行を割り当てます。時間の経過とともに、追加の関数をデプロイし、以下のトラフィックパターンに注目したとします。
![\[\]](http://docs.aws.amazon.com/ja_jp/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 0 `UnreservedConcurrentExecutions`) です。
+ `t2` では、`ClaimedAccountConcurrency` は 900 (800 \$1 100 `UnreservedConcurrentExecutions`) です。
+ `t3` でも、`ClaimedAccountConcurrency` は 900 (800 \$1 100 `UnreservedConcurrentExecutions`) です。
### CloudWatch での `ClaimedAccountConcurrency` メトリクスのセットアップ
Lambda は CloudWatch で `ClaimedAccountConcurrency` メトリクスを出力します。次の式に示すように、このメトリクスを `SERVICE_QUOTA(ConcurrentExecutions)` の値とともに使用すると、アカウントの同時実行使用率を取得できます。
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
次のスクリーンショットは、この数式を CloudWatch でグラフ化する方法を示しています。緑の `claim_utilization` 線は、このアカウントの同時実行使用率が約 40% であることを表しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
前のスクリーンショットには、同時実行使用率が 70% を超えると `ALARM` 状態になる CloudWatch アラームも含まれています。`ClaimedAccountConcurrency` メトリックスと類似のアラームを併用することで、アカウントの同時実行制限の引き上げをいつリクエストする必要があるかを事前に判断できます。