同時実行数、スロットリング、予約済み同時実行数

Lambdaは、関数を同時実行することでスケールします。つまり、同時に発生したイベントごとに1つの実行が行われます。同時に100件のリクエストが到着すると、Lambdaは関数を100個並列に実行します。基盤となるインフラストラクチャはAWSが自動的に管理します。アカウントレベルの同時実行数制限は、デフォルトではリージョンあたり1,000件の同時実行です（ソフトリミットであり、サービスクォータの申請によって引き上げられます）。

同時実行数は、次の式で計算します。同時実行数 = 1秒あたりのリクエスト数 × 平均処理時間（秒）。関数が1秒あたり500件のリクエストを処理し、各処理に0.2秒かかる場合、100件の同時実行が必要です。この式を理解すると、アカウントの制限で十分かどうか、またトラフィックの多いイベントの前にクォータの引き上げを申請する必要があるかどうかを予測できます。

Lambdaが同時実行数の制限を超えるリクエストを受け取ると、超過分をスロットリングします。同期呼び出し（例：API Gateway）では、スロットリングされたリクエストに429 TooManyRequestsExceptionが直ちに返され、呼び出し元が処理する必要があります。非同期呼び出し（例：S3イベント）では、Lambdaがイベントをキューに入れ、最大6時間再試行してからデッドレターキューに送信します。

予約済み同時実行数は、特定の関数に対して一定数の同時実行を保証し、その数をアカウントのプールから予約します。目的は2つあります。（1）キャパシティを保証する：他の関数がアカウントのクォータを使用していても、その関数で常に指定数の実行を利用できます。（2）同時実行数を制限する：関数が予約数を超えて実行されることはなく、下流の依存サービスが過負荷になるのを防ぎます。

試験で重要なシナリオです。Lambda関数が、接続数の上限が50のRDSデータベースに書き込むとします。同時実行数を制御しない場合、Lambdaが数百の同時実行までスケールし、すべてのデータベース接続を使い果たして、すべての関数でエラーが発生する可能性があります。予約済み同時実行数を40に設定すると、Lambdaが同時に使用するデータベース接続数は40を超えないため、RDSインスタンスを保護できます。これは、接続数に制限があるサービスを呼び出すLambda関数に共通して適用できる重要なパターンです。

プロビジョニング済み同時実行数は、指定した数のLambda実行環境を事前に初期化し、コールドスタートなしですぐに応答できる状態にします。これは、100ミリ秒のコールドスタートさえ許容できない、レイテンシーに敏感なAPIで特に重要です。プロビジョニング済み同時実行数では、環境がアイドル状態でも時間単位の料金が発生するため、予測されるトラフィックパターンに応じてプロビジョニング数を調整できるよう、Auto Scalingと組み合わせてください。

これらは混同されがちですが、目的は異なります。予約済み同時実行数は、アカウントプールから割り当てるキャパシティを制限・保証しますが、コールドスタートをなくすものではありません。プロビジョニング済み同時実行数は、実行環境を事前にウォームアップしてコールドスタートをなくしますが、他の関数が同じプールを使用することを防ぐものではありません。スループットの上限を設定するには予約済み同時実行数を、レイテンシーを改善するにはプロビジョニング済み同時実行数を使用してください。両方を同じ関数に併用することもできます。

Lambdaは同時実行数の上限まで瞬時にスケールするわけではありません。アカウントレベルのバースト制限（初期スケール速度）があり、これはリージョンによって異なります。通常は初期バーストが3,000で、その後、制限に達するまで1分あたり500件ずつ追加実行されます。急激で大規模なスパイク（急増したトラフィックやタイムセールなど）が予想されるアプリケーションでは、プロビジョニング済み同時実行数を使用して十分な環境を事前にウォームアップし、初期急増時にバースト制限によるスロットリングが起きないようにしてください。

次の主要なCloudWatchメトリクスを使用して、Lambdaの同時実行数を監視します。

• ConcurrentExecutions：現在実行中のインスタンス数
• Throttles：スロットリングされた呼び出し数（正常なシステムではゼロになるはずです）
• UnreservedConcurrentExecutions：アカウントレベルの未予約プール
• ProvisionedConcurrencyUtilization：使用中のプロビジョニング済みキャパシティの割合

Throttlesにアラームを設定し、スロットリングがエンドユーザーに影響する前に通知を受け取れるようにしてください。

Lambdaを同期的に呼び出すシステム（API GatewayやSDKによる直接呼び出し）を設計する場合は、呼び出し元にジッター付き指数バックオフを実装してください。AWS SDKには再試行ロジックが組み込まれていますが、API Gateway経由のLambdaでは、クライアントアプリケーションで429レスポンスを処理する必要があります。SQSがトリガーするLambdaでは、SQSサービス自体が再試行を処理します。ソースキューのMaximum Receivesを適切に設定し、再試行を使い果たした場合に備えてDLQを設定してください。

Kinesis Data StreamsとDynamoDB Streamsでは、Lambdaの同時実行数はシャード（Kinesis）またはパーティション（DynamoDB）の数によって制限されます。各シャードまたはパーティションは、常に1つのLambda同時実行によって処理されます。Kinesisのシャードが10個ある場合、このトリガーに対してLambdaは最大10件を同時実行します。つまり、ストリームベースのトリガーで発生するスロットリングの問題は、通常、同時実行数の制限を引き上げるのではなく、シャード数を増やすことで解決します。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、次のことを学びました。予約済み同時実行数は、関数の同時実行数を保証するとともに上限を設定し、下流サービスを保護して可用性を確保します。プロビジョニング済み同時実行数は環境を事前に初期化し、レイテンシーに敏感なワークロードでコールドスタートを排除します。また、スロットリングは、同期呼び出しでは429エラーとして、非同期呼び出しではキューに入れられた再試行として現れます。Throttles CloudWatchメトリクスで監視してください。次は、大規模な依存関係を管理するためのLambda Layersとデプロイパッケージについて学びます。