AWS Lambda の同時実行制限とスロットリングを理解する

はじめに

こんにちは、山本です。

今回はAWS資格勉強中に遭遇したAWS Lambdaに関する同時実行制限とスロットリングについて概念や対処法についてまとめます。
私と同じように資格試験奮闘中の方やスロットリングの壁に悩んでいる方に刺さる内容になれば幸いです。

Lambda の同時実行とは？

よく資格試験にも出題されるキーワードである「同時実行」とは、「同時に動いているLambdaの数」 のことを指しています。

Lambdaではリクエストごとにサービスの裏でコンテナをリクエスト毎に独立して起動することで同時に複数の処理を並列実行することができます。デフォルトではアカウント単位で1000個のソフト制限（同時実行数の上限）が設定されています。

もし制限を超えてしまうリクエストが発生した場合（以下の例を参照）、後述するスロットリングという現象が起きます。

例：1秒間に2000リクエストが来た場合、制限値（1000）を超えているのでスロットリングが発生する。

スロットリングの挙動

同時実行数の制限を超えてしまった場合（スロットリングが発生した場合）の処理については、呼び出しが同期呼び出しなのか、非同期呼び出しかどうかで挙動が異なります。

同期呼び出し(例：API Gateway等)

同期呼び出し時にスロットリングが起こった場合、429(Too Many Requests)エラーをクライアント側に返します。

同期呼び出しでは、「呼んだ側（クライアント）」が結果をすぐに受け取る必要があるため、制限を超えると即座にエラーが返却され形になっています。

非同期呼び出し(例：S3イベント,EventBridge等)

非同期呼び出し時にスロットリングが起こった場合、超過したリクエストは一旦キューに挿入され、Lambda側でリトライを実施（最大6時間）します。
リトライを実施しても失敗し続ける場合はDLQ(デッドレターキュー)や再送先に転送します。(別途設定が必要)

同期呼び出しとの違いは、呼んだ側は結果を待つ必要がないため、Lambda サービス内部でリトライや遅延処理が可能になっているという点です。

以上のように、呼び出しの種類によってスロットリング時の挙動が全く異なるという点に注意しなければなりません。

ベストプラクティス

以下では、公式ドキュメントやAPN(AWS Partner Network)ブログを読み漁っていく中で紹介されていたベストプラクティスやメトリクスの説明についていくつか取り上げています。

1.ワークグループごとに予約済み同時実行数(Reserved Concurrency)を設定する。

予約済み同時実行数とは、あるLambda関数に最低限の「同時実行枠」を保証するという仕組みです。
これにより、クリティカルな関数がスロットリングで止まってしまうリスクを避けることができます。

例：「バッチ処理用 Lambda」に 100、「通知送信用 Lambda」に 50 を予約済み同時実行数として設定しておけば、他の関数が暴走しても設定を施した関数の実行分は確保される。

aws.amazon.com

2.大量トラフィックが予想される関数はプロビジョンド同時実行(Provisioned Concurrency)を利用する。

プロビジョンド同時実行とは、常に指定数のLambda関数実行用コンテナをスタンバイ状態で用意しておく仕組みです。
関数がトリガーされてからコンテナを起動するという作業を省いてくれるので、API Gateway の裏で使うようなレスポンス遅延を許容できない関数(同期呼び出し)に有効な設定となっています。

docs.aws.amazon.com

3.非同期イベントは再試行設計を意識する。

前述の通り、非同期呼び出し（Amazon S3 イベントや Amazon EventBridge など）は、スロットリング時に自動でリトライされる特性を持っています。
しかし、リトライ上限を超えて失敗が続いた場合のためにリトライ失敗時に DLQ（デッドレターキュー）や Amazon SQS/SNS に送信する設定を施すことで、「失敗時の逃げ場」を用意しておく必要があります。

aws.amazon.com

4.CloudWatch メトリクスで可視化し、アラームを設定する

リトライ失敗時に DLQ（デッドレターキュー）や Amazon SQS/SNS に送信する設定を施すことで自動的にスロットリング問題に対応できる構成を作れますが、あまりにもスロットリングの回数が多い場合はサービスクォータで同時実行数を引き上げるなど対策を取る必要があります。
その判断方法としてCloudWatch メトリクスで可視化するという方法があります。

具体的には、ConcurrentExecutions（現在の同時実行数）やThrottles（スロットリングされたリクエスト数）を監視対象にして、制限に引っかかった場合にアラートを飛ばすなど設定しておくという方法が挙げられます。

docs.aws.amazon.com

おわりに

いかがでしたでしょうか。
Lambdaの同時実行数に関してはよく資格試験にも取り上げられている内容ですが、個人的には「1000個の同時実行制限なんてそうそう行かないだろ」など考えていました。
しかし、実務を経験する中で意外と簡単にその頭打ち(スロットリング)は発生するもんだなとひしひしと感じています。

このような事態に遭遇した際に毎度アラートを人間が検知して修正するのではなく、後続の処理を事前に定義しておくことや処理自体のメンテナンスをしっかりと行っておくことが効率的な運用の肝なのではないかと今回の記事を書きながら学びました。

実務でも、プロダクトを試作する際にもこのスロットリング問題には必ずぶち当たる壁だと思うので、この記事が壁を壊すための手掛かりになれば幸いです。