Lambda 関数のスケーリング - AWS Lambda

Lambda 関数のスケーリング

初めて関数を呼び出すと、AWS Lambda により、関数のインスタンスが作成され、イベントを処理するためのハンドラーメソッドが実行されます。関数はレスポンスを返すときに、アクティブなまま待機した上で追加のイベントを処理します。最初のイベントの処理中に関数を再度呼び出すと、Lambda は別のインスタンスを初期化し、関数は 2 つのイベントを同時に処理します。さらにイベントが入ってくると、Lambda は使用可能なインスタンスにそれらを送信し、必要に応じて新しいインスタンスを作成します。リクエストの数が減少すると、Lambda は他の関数のスケーリングキャパシティーを解放するため、使用されていないインスタンスを停止します。

リージョンのデフォルトの同時実行クォータは 1,000 インスタンスから開始します。詳細情報、またはこのクォータの増加のリクエストについては、Lambda クォータを参照してください。関数ごとに容量を割り当てるには、関数に同時実行数のリザーブを設定することができます。

関数の同時実行数は、複数のリクエストを同時に処理するインスタンスの数を指します。最初のトラフィックバーストの場合、リージョンでの関数の累積同時実行数は最初のレベル (500 ~ 3000 の間) に達する可能性があり、これはリージョンによって異なります。バースト同時実行クォータは機能単位ではなく、リージョン内のすべての機能に適用されます。

バースト同時実行クォータ

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

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

  • 500 - その他のリージョン

最初のバーストの後、関数の同時実行数は、1 分ごとにさらに 500 インスタンス増加します。これは、すべてのリクエストを処理できる十分なインスタンス数が確保されるまで、または同時実行数の上限に達するまで続きます。リクエストが入ってくるスピードに関数のスケールが追いつけない場合、または関数が同時実行数の最大値に達した場合は、追加リクエストはスロットルエラーで失敗します (ステータスコード 429)。

次の例は、トラフィックのスパイクを処理する関数を示しています。呼び出しが指数関数的に増加すると、関数はスケールアップします。利用可能なインスタンスにルーティングできないリクエストに対しては、新しいインスタンスが初期化されます。同時実行数のバーストの制限に達すると、関数は直線的にスケーリングを開始します。同時実行数がすべてのリクエストを処理するのに十分ではない場合、追加のリクエストはスロットリングされて再試行されます。


      バーストの制限に達すると、同時実行数は直線的にスケーリングされます。追加のリクエストは調整されます。

Legend

  • 関数のインスタンス数

  • 未処理のリクエスト数

  • スロットリング対象

関数は、関数のリージョンのアカウントの同時実行数制限に達するまで、スケーリングを続けます。関数が需要に追いついてリクエストが減少し、関数の未使用のインスタンスはしばらくアイドル状態になった後に停止します。未使用のインスタンスは、リクエストを待機している間はフリーズされるため、料金は発生しません。

関数がスケールアップすると、各インスタンスによって処理される最初のリクエストは、コードのロードと初期化にかかる時間の影響を受けます。初期化コードに長い時間がかかる場合、平均レイテンシーとパーセンタイルレイテンシーへの影響が大きくなる可能性があります。レイテンシーの変動なしに関数をスケーリングできるようにするには、プロビジョニングされた同時実行数を使用します。次の例は、プロビジョニングされた同時実行数を使用し、トラフィックのスパイクを処理する関数を示しています。


      プロビジョニングされた同時実行数によるスケーリング。

Legend

  • 関数のインスタンス数

  • 未処理のリクエスト数

  • プロビジョニング済み同時実行

  • 標準の同時実行数

プロビジョニングされた同時実行数を設定すると、Lambda はその数の実行環境を初期化します。関数は非常に低いレイテンシーで受信リクエストのバーストを処理する準備が整います。プロビジョニングされた同時実行を設定すると、AWS アカウントに課金が発生することに注意してください。

プロビジョニングされた同時実行数がすべて使用中であるとき、関数は通常どおりスケールアップして追加のリクエストを処理します。

Application Auto Scaling は、プロビジョニングされた同時実行数のオートスケーリングを提供することで、この機能をさらに一歩進めます。Application Auto Scaling では、Lambda で生成される使用率メトリクスに基づいて、プロビジョニングされた同時実行数のレベルを自動調整するターゲット追跡スケーリングポリシーを作成できます。Application Auto Scaling API を使用して、エイリアスをスケーラブルターゲットとして登録し、スケーリングポリシーを作成します。

次の例では、関数は使用率に基づいて、プロビジョニングされた同時実行数の最小値と最大値の間でスケーリングします。オープンリクエストの数が増加すると、Application Auto Scaling は、設定された最大値に達するまで、プロビジョニングされた同時実行数を大規模なステップで増加させます。この関数は、使用率が低下し始めるまで、標準の同時実行数に基づいてスケーリングを継続します。使用率が一貫して低い場合、Application Auto Scaling は、より小さな定期的ステップで、プロビジョニングされた同時実行数を減少させます。


      Application Auto Scaling ターゲット追跡でプロビジョニングされた同時実行数をオートスケーリングします。

Legend

  • 関数のインスタンス数

  • 未処理のリクエスト数

  • プロビジョニング済み同時実行

  • 標準の同時実行数

関数を非同期的に呼び出す場合に、イベントソースマッピングを使用するか、別の AWS サービスを使用するかによって、スケーリングの動作は異なります。例えば、ストリームから読み取るイベントソースマッピングは、ストリーム内のシャードの数によって制限されます。イベントソースによって使用されていないスケーリングキャパシティーは、他のクライアントや他のイベントソースで使用できます。詳細については、以下のトピックを参照してください。

アカウントの同時実行レベルは、以下のメトリクスを使用してモニタリングできます。

同時実行メトリクス

  • ConcurrentExecutions

  • UnreservedConcurrentExecutions

  • ProvisionedConcurrentExecutions

  • ProvisionedConcurrencyInvocations

  • ProvisionedConcurrencySpilloverInvocations

  • ProvisionedConcurrencyUtilization

詳細については、「Lambda 関数のメトリクスの使用」を参照してください。