【ITニュース解説】How I handled 100K requests hitting AWS Lambda at once

2025年09月06日に「Dev.to」が公開したITニュース「How I handled 100K requests hitting AWS Lambda at once」について初心者にもわかりやすいように丁寧に解説しています。

作成日: 更新日:

ITニュース概要

AWS Lambdaで1分間に10万リクエストが集中し、Lambdaの同時実行数上限やRDSのコネクション過多が発生。対策として、API GatewayとLambdaの間にSQSを挟み、リクエストをバッファリング。Lambdaの同時実行数を制限し、RDS ProxyでDB接続を制御。非同期API向けだが、同期APIではレート制限やコンテナ化が必要。

ITニュース解説

システムエンジニアを目指す君へ。この記事は、AWS Lambdaを使ったシステムで、大量のリクエストが急に押し寄せた際にどう対応したか、その経験談を語っている。これは、君が将来、大規模なシステムを構築・運用する上で非常に役立つ知識になるはずだ。

まず、システムの構成を見てみよう。API Gatewayという、外部からのリクエストを受け付ける窓口があり、そこからLambdaという、サーバーレスでコードを実行できるサービスに処理が渡される。そして、LambdaはRDSというデータベースにアクセスしてデータを保存・取得する。

通常時は問題なく動作していたこのシステムが、ある夜、1分間に約10万件のリクエストが殺到したことで、3つの問題が発生した。

1つ目は、Lambdaの同時実行数の上限を超えてしまったことだ。Lambdaは、同時に実行できるインスタンス数に上限がある。大量のリクエストが来ると、この上限を超えてしまい、新しいリクエストを処理できなくなる。

2つ目は、RDSへの接続数が急増し、データベースがダウン寸前になったことだ。Lambdaが大量にデータベースに接続しようとするため、データベース側のリソースが不足し、処理が遅延したり、最悪の場合、データベースが停止してしまう。

3つ目は、コールドスタートによるレイテンシの増加だ。Lambdaは、しばらく使われていないインスタンスを再利用する際に、起動に時間がかかることがある。これをコールドスタートという。大量のリクエストが来ると、Lambdaが新しいインスタンスを頻繁に起動する必要があり、コールドスタートの影響で処理時間が長くなってしまう。

これらの問題を解決するために、筆者はシステムに「バッファ」を導入した。具体的には、API GatewayとLambdaの間に、SQSというメッセージキューを挟んだのだ。SQSは、メッセージを一時的に保管する場所で、LambdaはSQSからメッセージを取り出して処理する。

この変更により、システムは以下のように動作する。

  1. API Gatewayがリクエストを受け付ける。
  2. API GatewayがリクエストをSQSにメッセージとして投入する。
  3. LambdaがSQSからメッセージを取り出し、処理を実行する。
  4. LambdaがRDSにアクセスしてデータを保存・取得する。

さらに、筆者はAWSのいくつかの設定を変更することで、システムの安定性を高めた。

まず、「予約された同時実行数」を設定した。これは、Lambdaが同時に実行できるインスタンス数の上限を、安全なレベルに制限するものだ。例えば、50に設定した場合、Lambdaは最大でも50個のインスタンスしか同時に実行しない。これにより、データベースへの接続数が急増するのを防ぐことができる。

次に、「デッドレターキュー (DLQ)」を設定した。これは、Lambdaが処理に失敗したメッセージを保管する場所だ。もし、メッセージが破損していたり、Lambdaの処理にバグがあったりした場合、メッセージはDLQに送られる。これにより、問題のあるメッセージがシステムに悪影響を及ぼすのを防ぎ、後で問題の原因を調査することができる。

さらに、「CloudWatchアラーム」を設定した。これは、SQSのキューの深さ(キューに溜まっているメッセージの数)や、メッセージの経過時間などを監視し、異常があればアラートを発する機能だ。これにより、システムに問題が発生する前に、早期に検知し、対応することができる。

最後に、「RDS Proxy」を導入した。これは、LambdaとRDSの間に入るプロキシサーバーで、データベースへの接続を効率的に管理する。Lambdaがデータベースに接続する際に、RDS Proxyが接続をプールし、再利用することで、データベースへの負荷を軽減する。

これらの対策により、大量のリクエストが来ても、システムは安定して動作するようになった。10万件のリクエストが押し寄せても、データベースが過負荷になることはなく、Lambdaの同時実行数も安全な範囲に抑えられている。

ただし、この解決策は「非同期API」にのみ有効である。非同期APIとは、クライアントがリクエストを送信した後、すぐに結果を受け取る必要がないAPIのことだ。この場合、クライアントは「202 Accepted」というステータスコードを受け取り、リクエストが正常に受け付けられたことを確認する。Lambdaは、後でメッセージを処理し、結果をクライアントに通知する。

もし、APIが「同期API」である場合、つまり、クライアントがリクエストを送信した後、すぐに結果を受け取る必要がある場合は、別の解決策が必要になる。例えば、レート制限、プロビジョニングされた同時実行数、またはコンテナなどだ。

レート制限は、クライアントが一定時間内に送信できるリクエストの数を制限するものだ。プロビジョニングされた同時実行数は、Lambdaが常に一定数のインスタンスを起動しておくことで、コールドスタートの影響を軽減するものだ。コンテナは、Lambdaよりも柔軟な環境でコードを実行できる。

この記事から得られる教訓は、大規模なシステムを構築・運用する際には、予期せぬ事態に備えて、様々な対策を講じておく必要があるということだ。特に、大量のリクエストが急に押し寄せる可能性がある場合は、バッファを導入したり、AWSの機能を活用したりすることで、システムの安定性を高めることができる。システムエンジニアを目指す君は、これらの知識をしっかりと身につけて、将来、大規模なシステムを安全かつ効率的に運用できるように努力してほしい。

【ITニュース解説】How I handled 100K requests hitting AWS Lambda at once | いっしー@Webエンジニア