AWSサーバーレスは無限にスケールする？Lambda関数をテーマにサーバーレス環境のバーストトラフィックについて考える🤔

こんにちは！

これまで多くの AWS サーバーレスによるアプリケーション構築プロジェクトに携わってきましたが、お客様や現場からこのような声が上がってきます。

• サーバーレスだからサーバーリソースの管理は完全に不要！安心！
• サーバーリソースはAWSにお任せなのでアクセス数の試算なんて必要ない！
• バーストアクセスの考慮から解放された！

…ちょっと待ってください。

サーバーレスとは言え、サーバーインスタンスの実態はちゃんと存在します。
つまり、バーストアクセスを考慮しない、インフラのリソースのことは一切無視なんてことは出来ません。現実、AWSの公式ドキュメントを見るとバーストアクセスによるスロットリングの記載もちゃんとあります。

本記事は、サーバーレスに関わる全てのヒトが、サーバーレスのサーバーリソースに対する考え方を見直してもらうことを目的に、LambdaなどをはじめとしたAWSのバーストアクセスについて解説します。

想定する読者

• サーバーレステクノロジーのファン
• サーバーレスのアーキテクチャーに関わるヒト
• サーバーレス実装に関わるヒト

用語整理

バーストトラフィックとスパイクアクセスの違いに悩む人も多いかと思います。スパイクアクセスは「アクセス」のことを指しており、バーストトラフィックは「スパイクアクセスによって求めらた大量の処理要求」と解釈してください。

バーストトラフィック	大量の処理要求、データ量のこと
スパイクアクセス	急激なアクセス増加すること
スロットリング	一定時間内に受信可能なリクエスト数を制限し、制限を上回るリクエストがなされた際には受信を拒否しエラーをレスポンスすること

アクセスがスパイクされたなどをよく言いますが、これを言い換えると「一時的に大量のアクセスがあった」となります。

対して、「バーストトラフィックによってスロットリングが発生した」を言い換えると、「スパイクアクセスによってバーストトラフィックが発生しスロットリングが発生した」となります。

Lambdaのバーストトラフィック

リージョンによって同時実行可能なLambdaの台数が異なります

Edgeロケーションに位置するLambdaは、基本的にパラレル（並列）に処理が実行されます。実行するリージョンによって一度にパラレル処理できる台数が異なります。

3000	米国西部 (オレゴン)、米国東部（バージニア北部）、欧州 (アイルランド)
1000	アジアパシフィック (東京)、欧州 (フランクフルト)、米国東部 (オハイオ)
500	その他のリージョン

東京リージョンの場合、1,000を超える同時実行が行われた場合、Lambda関数のAPIは追加の呼び出しをスロットリングします。

Lambda は 1 分間ごとにスケールします

最初のバーストトラフィック発生時に、関数の同時実行数は 1 分ごとにさらに 500 インスタンス増加します。すべてのリクエストを処理できる十分なインスタンス数が確保されるまで、または同時実行数の上限に達するまで続きます。

また、Lambda関数は処理完了後、一定時間を待って追加の呼び出しがなければリソースが解放され、追加の呼び出しがあればそれに応じて処理を行います。（一瞬ホットスタンバイするようなイメージ）

Lambda のバーストトラフィックの試算

Lambda関数のバーストトラフィックを試算する際は、一回あたりの処理時間も加味した上で試算を行うことが必要です。例えば、一回あたりの処理が小粒であれば、 1 分当たりの実行数がたとえ大量でも処理が完了次第、即座に次の処理を行うことができます。

対して、Lambda関数に処理時間が大きい仕事を持たせると、次の処理を行うことができずスロットリングしやすくなります。バーストトラフィックの試算も重要ですが、それ以上にLambdaに極力小さな仕事をさせる設計が非常に重要と言えます。この辺りは、マイクロアーキテクチャーの思想をしっかり理解することが重要だと、私たちは考えています。

スロットリング時の挙動

Lambda関数を各イベント時に呼び出せるAWSサービス（S3やSQSなど）は、処理結果を待たずに、Lambda関数を非同期的に呼び出すケースが非常に多いです。その場合のスロットエラー（429）の挙動は下記となります。

• 最大 6 時間、関数を再度実行を試みる
• 再試行間隔は、最初の試行後 1 秒から最大 5 分まで指数関数的に増加

ユーザー数増加に伴うスロットリング対策

サービスのスケール時のスロットリングはうれしい悲鳴ですね。私たちは通常、下記のような対応を行います。

• Fargateを導入しLambdaと置き換える（月額費用が増加するので慎重に）
• 上限緩和申請を行い同時実行数を増やす
• Lambda関数のリザーブ購入を行い事前に実行数を購入しておく

関連記事

AWS Lambda 関数スケーリング

非同期の呼び出し

まとめ

サーバーレスのメリットは十分に理解しているものの、デメリットをしっかりと把握している方は意外と少ないのではないでしょうか。

プロダクトのプロトタイピング・シリーズAの前後まではLambdaで十分容易に乗り切れますが、グロースに伴うスパイクアクセス・バーストトラフィック増加時は、アーキテクチャーを再度慎重に検討しなければいけません。

サーバーレスでの運用、開発相談はお気軽にお問い合わせください。