トラフィック急増対策、何から始めるべきか？仮想待合室・Rate Limit・ボット遮断の適用基準
サマリー
トラフィックが急増したからといって、すべてのリクエストを一律に制限すべきではありません。正常なユーザーが一斉にアクセスしているのか、特定のAPIが処理能力を超えているのか、あるいはボットやマクロが繰り返しリクエストを送信しているのかによって、必要な対策が異なるためです。
正常なユーザーの一時的なアクセス集中： 仮想待合室による流入制御が必要になる場合があります。
正常なAPIリクエストの過負荷： Rate LimitとあわせてAPIキューの導入を検討できます。
ボットやマクロの流入： リクエスト量を減らす前に、自動化されたリクエストを検知し、正常なユーザーと区別する必要があります。
サービス停止を目的としたDDoS攻撃： ネットワーク・セキュリティレイヤーでの個別の対策が必要です。
したがって、トラフィック急増に対応する際は、単にリクエスト量を確認するのではなく、「誰がリクエストしたのか」「どこでボトルネックが発生したのか」「処理能力を超えたリクエストをどのように扱うべきか」を、まず切り分ける必要があります。
最近、Coupang Playは、サッカー選手イ・ガンインが先発出場した試合を独占配信していた際、一時的なトラフィック増加により接続障害が発生したと発表しました。一部の利用者は、接続が正常化するまで約40分間、試合を視聴できませんでした。人気スポーツ中継で発生する瞬間的なピークトラフィックが、改めて運用上の課題として浮き彫りになった事例です。
ただし、外部に公開された情報だけでは、ログイン、認証、セッション、動画配信、バックエンドAPIのうち、実際にどこがボトルネックとなったのかを判断することはできません。
同じ「接続障害」であっても、原因はさまざまです。実際のユーザーが一斉にアクセスした可能性もあれば、特定のAPIにリクエストやリトライが繰り返され、バックエンドシステムへの負荷が高まった可能性もあります。また、正常なユーザーとともにボットやマクロが流入していた可能性や、サービス停止を目的とした攻撃が発生していた可能性についても、別途確認する必要があります。
では、トラフィックが突然集中したとき、企業は何から確認すべきなのでしょうか。サーバーを増強すべきか、ユーザーを待機させるべきか、それとも不正なリクエストを先に遮断すべきなのでしょうか。
トラフィックが急増したとき、なぜ原因の切り分けが必要なのか？
トラフィックの急増は、障害の原因というよりも、外部から観測される現象に近いものです。同じ接続遅延やエラーであっても、トラフィックを発生させた主体とボトルネックが生じた箇所によって、対応方法は異なります。
そのため、トラフィックが急増したときは、まず次の3つの問いを確認する必要があります。
誰がリクエストを発生させたのか？
サービスのどの部分で処理限界に達したのか？
処理能力を超えたリクエストをどのように扱うべきか？
誰がリクエストを発生させたのか？
WebサイトやAPIにアクセスするのは、実際のユーザーだけではありません。
商品を購入したり、サービスを利用したりする実際のユーザー
検索エンジンや正当なAIエージェント
在庫・価格・座席情報を繰り返し照会する自動化ツール
チケットや商品を買い占めるマクロ
サービス停止を目的としてリクエストを発生させる攻撃者
トラフィックを発生させた主体を区別せず、すべてのリクエストを一律に制限すると、正常なユーザーのアクセスまで遮断してしまう可能性があります。一方、すべてのリクエストを正常な需要とみなしてサーバーへ転送すると、自動化されたリクエストがインフラリソースを消費したり、サービス指標を歪めたりするおそれがあります。
どこで処理限界に達したのか？
接続障害が発生したからといって、必ずしもサーバー全体が処理限界に達しているとは限りません。実際のボトルネックは、次のような特定の機能で先に発生することがあります。
ログイン・認証・セッション生成
商品在庫の照会
クーポン発行
予約・注文の確定
決済
外部APIとの連携
データベース接続
例えば、ライブストリーミングプラットフォームの動画配信レイヤーが多数の視聴者を処理できたとしても、試合開始直前にログインやセッション生成のリクエストが集中すれば、認証システムや共通バックエンドが先に影響を受ける可能性があります。
したがって、運用チームが最初に確認すべきなのは「仮想待合室をどこに適用するか」ではなく、「どの部分が最初に処理限界に達したのか」です。
処理能力を超えたリクエストをどのように扱うべきか？
処理能力を超えたリクエストを、すべて同じ方法で扱う必要はありません。
即座にエラーとして処理してもよいリクエストか？
一時的に待機させた後で処理すべき正常なリクエストか？
リクエスト元に対する追加検証が必要か？
サービスへ到達する前に遮断すべき攻撃か？
例えば、単純な照会リクエストであれば、上限を超えた際に再試行を案内する方法もあります。一方、予約や決済のように、リクエストの失敗が取引の取りこぼしにつながる業務では、処理可能になるまで待機させた後、順番に処理する方法が適している場合があります。
正常なユーザーの増加、APIの過負荷、ボット攻撃をどう見分けるか？
トラフィックの急増は、大きく次の4つの状況に分類できます。
トラフィックの状況 | 確認すべき特徴 | 運用上の目標 | 主な対応方針 |
|---|---|---|---|
正常なユーザーの集中 | イベント・ニュース・キャンペーン後に、多数のユーザーが特定の機能へアクセス | 公平なアクセス機会とサービスの安定性を維持 | 仮想待合室・流入制御 |
正常なAPIリクエストの増加 | 特定APIの応答遅延、エラー、リトライの増加 | バックエンドの処理能力に合わせてリクエストの流れを管理 | Rate Limit・APIキュー |
ボット・マクロの流入 | 繰り返し呼び出し、異常なセッション・行動パターン | 自動化リクエストの識別・検証・遮断 | ボット管理 |
DDoSおよび攻撃トラフィック | サービス停止を目的とした大量・分散リクエスト | 攻撃トラフィックの吸収・遮断 | CDN・WAF・DDoS対策 |
ただし、実際の運用環境では、この4つのタイプを明確に分けられない場合があります。チケット販売開始のタイミングで正常なユーザーとマクロが同時に流入したり、自動化されたボットリクエストがアプリケーションレイヤーに大量に集中したりすることもあります。
そのため、リクエスト量や特定のIPアドレスだけでトラフィックの性質を断定すべきではありません。リクエスト頻度に加え、セッション、ブラウザ環境、接続元ネットワーク、行動パターン、アクセス先URLなど、複数の情報を総合的に確認する必要があります。
正常なユーザーが一斉にアクセスした場合：仮想待合室
マーケティングキャンペーン、チケット販売、履修登録、スポーツ中継など、実際のユーザーが特定の時間に集中する状況では、すべてのユーザーを一斉にサービスへ流入させることが問題となる場合があります。
仮想待合室は、システムが処理できるユーザーをすぐにサービスへ案内し、処理能力を超えたユーザーを一時的に待機させます。その後、サービスの処理能力に余裕が生じると、待機中のユーザーを順番に案内し、トラフィックの流れを管理します。
重要なのは、ユーザーを待たせることではなく、一度に集中した正常な需要を、サービスが処理可能な水準に調整することです。
正常なAPIリクエストが処理能力を超えた場合：Rate LimitとAPIキュー
APIトラフィックが急増した場合、一般的にはRate Limitによって、一定時間内に許可するリクエスト数を管理できます。設定された上限を超えたリクエストは、適用方式に応じて制限されたり、エラーレスポンスを受け取ったり、一定時間後に再試行することになります。
しかし、上限を超えたリクエストがすべて不要とは限りません。
決済・予約・申請などの正常なリクエストを即座に失敗させると、取引や業務が失われる可能性があります。また、クライアントが失敗したリクエストを自動的に再送信する仕組みであれば、リトライがさらなる負荷を生むこともあります。
このような環境では、次の点もあわせて確認する必要があります。
リクエストを一時的に遅延させてもよいか？
リクエストの失敗が取引や業務の損失につながるか？
現在、バックエンドシステムが処理できる量はどの程度か？
APIごとに業務上の重要度や処理優先度が異なるか？
上限を超えた正常なリクエストを破棄すべきでない場合は、APIキュー（待機列）にリクエストを保持し、バックエンドシステムが処理可能な速度に合わせて順次転送する方法を検討できます。
悪意ある自動化リクエストの場合：ボット検知と段階的な対応
ボットやマクロがトラフィックを発生させている場合は、リクエスト全体を減らす前に、自動化されたリクエストを正常なユーザーと区別する必要があります。
すべてのボットが悪意あるものとは限りません。検索エンジンクローラーのように、サービスの露出に必要なボットがある一方、在庫の買い占め、価格スクレイピング、チケット購入、アカウント乗っ取りなどを目的とする自動化ツールも存在します。
したがって、ボット対策では一律に遮断するのではなく、次のような段階で対応する必要があります。
実際のユーザーと自動化リクエストを区別する
自動化リクエストの目的とリスクレベルを判断する
疑わしいリクエストに追加検証を適用する
悪意あるリクエストを遮断する
正常なユーザーと許可されたボットには、従来どおりサービスを提供する
この場合、仮想待合室とボット管理は互いに代替する技術ではありません。ボット管理は不正な自動化リクエストを識別し、仮想待合室は正常なユーザーの需要をシステムの処理能力に合わせて管理します。
サービス停止を目的とした攻撃の場合：個別のDDoS対策
DDoSとは、多数のシステムやネットワークリソースを利用して攻撃対象へ大量のトラフィックを送り、正常なサービス利用を妨害する攻撃です。
仮想待合室やAPIキューは、正常な需要がシステムの処理能力を超えた際に、リクエストの流れを管理する技術です。そのため、これらをDDoS対策の代替手段として説明すべきではありません。
ネットワークレイヤーへの攻撃や、攻撃を目的とした大量のトラフィックには、CDN、WAF、専用のDDoS対策など、個別のセキュリティ体制が必要です。アプリケーションレイヤーで発生する自動化された不正利用とネットワーク攻撃を区別し、それぞれに適した対策を講じる必要があります。
実際の状況では、どのような対応が必要か？
スポーツ中継の開始と同時にログインが集中した場合
スポーツの試合開始直前に、実際の利用者によるログインやセッション生成のリクエストが集中した場合は、正常なユーザーによる瞬間的な需要を管理することが優先されます。
動画配信レイヤーだけでなく、ログイン、認証、セッション、契約状況の確認など、どの部分が最初に処理限界に達するのかを確認し、特定の流入経路に正常なユーザーが過度に集中する場合は、仮想待合室による流入制御を検討できます。
AIエージェントとリトライによって特定APIへのリクエストが増加した場合
AIエージェントによる1つのタスクが複数の社内・外部API呼び出しにつながり、失敗したリクエストでリトライが繰り返されると、バックエンドシステムの負荷は急速に高まる可能性があります。
この場合、AIからのリクエストを一律に遮断するのではなく、どのAPIで応答時間が増加しているのか、上限を超えたリクエストを遅延処理できるのか、失敗したリクエストを保持する必要があるのかを先に確認する必要があります。正常なリクエストを失わないことが求められる場合は、APIキューの導入を検討できます。
チケット販売開始と同時にマクロが流入した場合
チケットの販売開始時には、実際のファンによる需要と自動購入マクロが同時に集中する場合があります。
このとき、すべてのリクエストを同じ待機列に入れるだけでは、公平な購入機会を確保することは困難です。自動化リクエストを検知・検証・遮断したうえで、残った正常なユーザーの流入量をシステムの処理能力に合わせて管理する、多層的なアプローチが必要です。
自社サービスに必要な対策を確認するためのチェックリスト
トラフィック対策を選定する前に、次の項目を確認してみてください。
現在の流入は、正常なユーザーによる需要か、自動化されたリクエストか？
サービス全体が遅いのか、ログイン・予約・決済など特定の機能だけが遅いのか？
Webユーザーの流入が問題なのか、APIの処理能力が問題なのか？
処理できなかったリクエストをエラーとして終了させてもよいか？
失敗したリクエストのリトライが、さらなる負荷を生んでいないか？
リクエスト量だけでなく、セッション・行動・ブラウザのパターンにも異常が見られるか？
1つの対策だけで十分か、それとも複数のレイヤーで対策を組み合わせる必要があるか？
結局のところ、トラフィック対策で最初に問うべきなのは、「どれだけ多くのリクエストが流入したのか」ではありません。
「誰がリクエストし、どこで処理が滞り、処理能力を超えたリクエストをどのように扱うべきか」を、まず切り分ける必要があります。
正常なユーザーが集中する状況では仮想待合室、正常なAPIリクエストが処理能力を超える状況ではAPIトラフィック制御、悪意ある自動化リクエストにはボット管理が必要になる場合があります。攻撃を目的としたトラフィックには、個別のセキュリティ対策が必要です。
トラフィックの急増を1つの問題として捉えるのではなく、その原因とボトルネックが発生した箇所を切り分けることで、自社のサービス環境に適した対応の仕組みを設計できます。
FAQ
Q. トラフィックが急増したら、まずサーバーを増強すべきですか？
A. 必ずしもそうとは限りません。サーバーの増強は、継続的に増加する需要へ対応するために必要な場合があります。しかし、ログイン、データベース、決済APIなど、特定の箇所にボトルネックがある場合は、サーバーの台数を増やしても問題が解消されない可能性があります。一時的なトラフィックなのか、継続的な増加なのか、そして実際のボトルネックがどこにあるのかを、まず確認する必要があります。
Q. トラフィックの急増とDDoS攻撃は、何が違うのですか？
A. 正常なトラフィックの急増は、実際のユーザーによる需要が一時的に集中した状態です。一方、DDoSは、サービスを利用できない状態にすることを目的とした悪意ある攻撃です。ただし、外部から見える結果はいずれも遅延や障害として現れる可能性があるため、リクエスト元、行動パターン、対象となった機能、攻撃の特徴を総合的に確認する必要があります。
Q. 仮想待合室とRate Limitは、何が違うのですか？
A. 仮想待合室は、処理能力を超えたユーザーを一時的に待機させ、その後、順番にサービスへ案内します。Rate Limitは、一定時間内に許可するリクエストレートを管理するポリシーです。両者は、適用対象と、上限を超えたリクエストを扱う目的によって使い分ける必要があります。
Q. APIリクエストが処理能力を超えたら、すべて待機させるべきですか？
A. いいえ。即時応答が求められ、遅延そのものが失敗につながるAPIには、キューが適さない場合があります。一方、予約や決済のようにリクエストの取りこぼしが問題となる場合や、バックエンドの処理能力が限られている場合は、キューによる制御を検討できます。
Q. ボットトラフィックは、リクエスト頻度だけで見分けられますか？
A. リクエスト頻度だけでは十分ではありません。自動化ツールはIPアドレスを変更したり、正常なブラウザのように振る舞ったりすることができるため、行動パターン、セッション、ブラウザ環境、ネットワーク特性など、複数のシグナルをあわせて確認する必要があります。
Q. 仮想待合室とボット遮断を併用できますか？
A. 可能です。チケット販売や限定商品の販売など、正常なユーザーとマクロが同時に集中する状況では、ボット管理によって不正な自動化リクエストを識別し、仮想待合室によって正常なユーザーの流入量をシステムの処理能力に合わせて管理できます。
Q. CDNやWAFを導入していれば、仮想待合室は必要ありませんか？
A. CDNは主にコンテンツ配信と負荷分散、WAFはWeb攻撃の検知と遮断に使用されます。一方、仮想待合室は、正常なユーザーの需要がアプリケーションの処理能力を超えた際に、ユーザーの流入量を管理します。それぞれが担う課題は異なるため、現在のボトルネックとトラフィックの性質を基準に判断する必要があります。