バースト同時実行 - AWS Lambda

バースト同時実行

関数が受け取るリクエストが増えると、Lambda が実行環境数を自動的にスケールアップしてこれらのリクエストを処理します。これはアカウントの同時実行上限に達するまで行われます。ただし、Lambda のスケール速度には制限があります。ほとんどの場合、この制限について心配する必要はありませんが、次のようにこの点を考慮に入れる必要があるいくつかの特殊なケースがあります。

  • 新しい関数のデプロイ時に、最初にトラフィックのバーストが発生することが予想される場合

  • 既存の関数で突然トラフィックのバーストが発生することが予想される場合

突然のトラフィックのバーストに対応する際、Lambda は受信したすべてのリクエストを処理するためにすぐにスケールアップできない場合があります。これはオーバースケーリングを防ぐためです。バースト同時実行クォータは、アカウント内の関数がバーストに応じてスケールできる最大レート (つまり、Lambda が新しい実行環境を作成できる速度) です。バースト同時実行クォータは、アカウントレベルの制限です。このセクションでは、Lambda がバースト同時実行クォータを決定する方法と、特定のバーストシナリオにおけるバースト同時実行スケーリングの動作について詳しく説明します。

バースト同時実行レートの制限

新しい関数をデプロイすると、Lambda はそれらの関数を即座に最大 500 ~ 3,000 の実行環境インスタンスにスケーリングして、最初の大量のトラフィックを処理できます。正確な最大値は AWS リージョン によって異なります。

リージョン バースト同時実行の制限

米国西部 (オレゴン)、米国東部 (バージニア北部)、欧州 (アイルランド)

3,000

アジアパシフィック (東京)、欧州 (フランクフルト)、米国東部 (オハイオ)

1,000

その他のすべてのリージョン

500

バースト同時実行の上限を引き上げる必要がある場合は、AWS Support で問い合わせてください。現時点では、Service Quotas はバースト制限の変更をサポートしていません。

注記

バースト同時実行制限は、アカウントの同時実行制限を超えることはできません。例えば、米国西部 (オレゴン)、米国東部 (バージニア北部)、欧州 (アイルランド) の初期バースト同時実行制限は 3,000 で、デフォルトのアカウント同時実行制限である 1,000 を上回っています。そのため、デフォルトでは、この 3 つのリージョンの初期バーストは 1,000 までしかスケールできません。この 3 つのリージョンの関数で利用できるバースト同時実行数 3,000 ユニットをすべて活用するには、アカウントの同時実行制限の引き上げをリクエストしてください

最初のバースト増加後も、Lambda は次のルールに基づいて引き続き関数をスケールアップします。

  • 関数に追加のスケーリングが必要な場合、Lambda はリージョンに関係なく、1 分あたり最大 500 個の実行環境インスタンス (バーストクォータユニット) を追加してスケールアップできます。

  • 1 分ごとに 500 のバーストクォータユニットが継続して増加します。関数がこのレベルのスケーリングを必要としない場合、Lambda は、バケットがリージョンの最大バースト同時実行制限に達するまで、未使用のユニットを架空の「バケット」に保存します。たとえば、米国東部 (バージニア北部) では、バケットは 3,000 ユニットに達するまで、1 分あたり 500 ユニットを増やし続けることができます。将来的に関数でバーストが発生すると、Lambda はバケットからデータを引き出して関数をスケールアップします。

いずれの場合も、アカウントの同時実行数の上限に達していない限り、Lambda は利用可能な最速のペースでスケールし続けることができます。リクエストが入ってくるスピードに関数のスケールが追いつけない場合、または関数が同時実行数の最大値に達した場合は、追加リクエストはスロットルエラーで失敗します (ステータスコード 429)。

バースト同時実行の概要と視覚化

このセクションには、Lambda バーストの同時実行動作の理解に役立つスケーリング例のアニメーションが含まれています。このシナリオでは、米国東部 (バージニア北部) リージョンにアクティブな Lambda 関数があり、アカウントの同時実行の制限が 10,000 であると仮定します。数分間にわたって、関数が次のトラフィックパターンに遭遇したとします。


        トラフィックの急増を伴う特定のトラフィックパターンに Lambda がどのように対応するか。

次のアニメーションでは、3 つのバーストのそれぞれに応じて Lambda がどのようにスケーリングされるかを詳しく説明します。アニメーションをよく理解するために、グラフのさまざまな構成要素についてここで説明します。

コンポーネント 重要性

X 軸

時間

Y 軸

同時実行リクエスト

黒一色の線

関数が処理している実際の同時実行リクエスト数。

  • 8:59 の時点で、関数は同時リクエストを 0 件処理しています。

  • 9:00 の時点で、関数は同時リクエストを 2,000 件処理しています。

影付きの青色のリージョン

Lambda が関数用にプロビジョニングしたアクティブな実行環境の数。

  • 8:59 の時点で、Lambda は 0 個の実行環境をプロビジョニングしています。

  • 9:00 の時点で、Lambda は 2,000 個の実行環境をプロビジョニングしています。

影付きの緑色のリージョン

現在のバースト同時実行クォータを考慮した、関数の理論上の最大スケーリング容量。

  • 8:59 の時点で、関数は最大 3,000 の実行環境にスケールできます。

  • 9:00 の時点でも、関数は引き続き最大 3,000 の実行環境にスケールできます。

グラフの右側にあるオレンジ色の「バケット」

現在利用可能なバーストクォータ。

  • このシナリオの終わりの 9:07 の時点で、利用できる最大バーストクォータは 1,000 です。

パート 1: バースト #1 の処理 (8:58-9:00)

最初のアニメーションは、Lambda が最初の 2,000 件の同時実行リクエストを処理する方法を示しています。


          バースト #1 に対応して Lambda がどのようにスケールされるかを示すアニメーション。

このアニメーションの説明は次のとおりです。

  • 8:58 の時点では、3,000 のバーストクォータ全体を使用できます。関数は 9:00 までリクエストを受け取りませんが、Lambda は必要に応じて関数を最大 3,000 の実行環境に即座にスケールできます。

  • 9:00 の時点で、関数に突然 2,000 件の同時実行リクエストが発生します。Lambda は、使用可能な 3,000 バーストクォータのうち 2,000 個を使用して 2,000 個の実行環境をプロビジョニングします。その後、Lambda は 2,000 件の受信リクエストをすべて処理します。残りのバーストクォータは 1,000 で、Lambda は後で使用できるようにこれを残しておきます。

パート 2: 未使用のバーストクォータの蓄積(9:00 ~ 9:02)

2 番目のアニメーションは、使用されなかった場合に Lambda がバーストクォータユニットをどのように蓄積するかを示しています。


          Lambda が未使用のバーストクォータユニットをどのように蓄積するかを示すアニメーション。

このアニメーションの説明は次のとおりです。

  • 9:00 から 9:01 まで、実際の同時実行リクエストは 2,000 件未満にとどまるため、Lambda でスケールアップし続ける必要はありません。

  • 9:01 の時点で、バーストクォータユニットが 500 追加されます。今すぐ使用する必要はないため、Lambda では 500 ユニットすべてを残しておきます。使用可能なバーストクォータの合計は 1,500 になります。これにより、理論上の最大スケーリング容量が 3,500 まで増加することに注目してください。

  • 同じことが 9:01 から 9:02 の間でも起こります。9:02 の時点で、さらに 500 ユニットが追加され、使用可能なバーストクォータの合計は 2,000 になります。これにより、理論上の最大スケーリング容量は 4,000 まで増加します。

パート 3: バースト #2 の処理 (9:02-9:03)

3 番目のアニメーションは、蓄積されたバーストクォータを使用して Lambda が 2 回目のバーストを処理する方法を示しています。


          バースト #2 に対応して Lambda がどのようにスケールされるかを示すアニメーション。

このアニメーションの説明は次のとおりです。

  • 9:02 を過ぎて間もなく、関数に突然 2,000 件の同時リクエスト、つまり合計 4,000 件の追加リクエストが発生します。Lambda は、使用可能なバーストクォータ 2,000 をすべて使用して、さらに 2,000 個の実行環境をプロビジョニングします。その後、Lambda は 4,000 件の受信リクエストをすべて処理します。残りのバーストクォータは 0 です。

  • 9:03 の時点で、再度 500 ユニットを蓄積します。

パート 4: バースト #3 の処理とスロットリング (9:03-9:04)

4 番目のアニメーションは、バーストに応じて関数が一時的にスロットリングされるシナリオを示しています。


          バースト #3 に対応して Lambda がどのようにスケールされるかを示すアニメーション。また、一時的なスロットリングの例も含まれています。

このアニメーションの説明は次のとおりです。

  • 9:04 の時点で、再度 500 ユニットを蓄積します。使用可能なバーストクォータは 1,000 です。

  • 9:04 を過ぎて間もなく、関数に突然 1,500 件の同時リクエスト、つまり合計 5,500 件の追加リクエストが発生します。Lambda は、使用可能なバーストクォータ 1,000 をすべて使用して、さらに 1,000 個の実行環境をプロビジョニングします。これで Lambda は 5,000 件の受信リクエストを処理できますが、500 件のリクエストではスロットリングが発生します。

パート 5: 回復 (9:04-9:05)

5 番目のアニメーションは、Lambda が新しいバーストクォータユニットを迅速に使用して一時的なスロットリングから回復する方法を示しています。


          Lambda がスロットリングから回復する様子を示すアニメーション。

このアニメーションの説明は次のとおりです。

  • 9:05 の時点で、再度 500 ユニットを蓄積します。使用可能なバーストクォータは 500 です。

  • Lambda はただちにこの 500 ユニットを使用して 500 個の実行環境をプロビジョニングします。Lambda は 5,500 件の受信リクエストをすべて処理できるため、これでスロットリングは終了します。使用可能なバーストクォータは 0 です。

パート 6: まとめ (9:05-9:07)

最後の 6 番目のアニメーションは、不要な場合でも Lambda がバーストクォータユニットを蓄積し続ける様子を示しています。


          Lambda がバーストクォータユニットを蓄積し続ける様子を示すアニメーション。

このアニメーションの説明は次のとおりです。

  • 9:06 の時点で、再度 500 ユニットを蓄積します。使用可能なバーストクォータは 500 です。

  • 9:07 の時点で、再度 500 ユニットを蓄積します。使用可能なバーストクォータは 1,000 です。

注記

未使用の実行環境は、リクエストを待機している間はフリーズされるため、料金は発生しません。アイドル状態が長時間続いた場合、Lambda は自動的にそれらをシャットダウンします。