なぜリアルな負荷テストには複数のIPアドレスが必要なのか

単一IPテストが問題ないように見える理由

単一IPによる負荷テストは、一見成功しているように見えます。スクリプトは実行され、ダッシュボードはデータで溢れ、遅延は目標範囲内に収まっています。しかし問題は、これらの結果がしばしば実際の本番トラフィックよりもテスト環境を反映しているという点です。

本番トラフィックは単一のアドレスから来るわけではありません。消費者向けのエンドポイントは、数千の住宅用ISP、モバイルキャリア、企業のNAT、およびデータセンタープロキシからのトラフィックを受け取ります。各リクエストは異なるCDNエッジノードに到達し、異なるミドルボックスを通過し、コネクションプールの異なるシャードにヒットします。これら多様性をすべて単一のソースIPに集約すると、ソースに基づく全てのレイヤが同じになってしまいます。ドレスは現実世界の対応物のない方法で動作し始めます。

その結果、実際の本番動作を反映しない誤解を招くパフォーマンスデータが得られます。

シングルIP負荷テストの7つの具体的な障害モード

シングルIP負荷テストは、いくつかの現実世界の動作を歪めたり、完全に見逃したりすることがあります。

1. レートリミッターが誤った数値を返す

現代のレートリミッターはソース識別子ごとに動作し、最も一般的な識別子はソースIPです。トークンバケット、固定ウィンドウ、スライディングウィンドウの各アルゴリズムはすべてこの特性を共有しています。認証トークンやユーザーIDに基づいて制限を設けるチームであっても、多くの場合、IPごとの制限を下層に設定しています。IPレイヤーは認証されていない悪用からアプリケーションを保護するものです。重い仮想ユーザーロードがすべて1つのIPからのトラフィックを発生させると、リミッターはその負荷を1クライアントと見なし、アプリケーションがストレスを感じる前にリクエストを拒否し始めます。アプリケーションは高速に見えますが、それはリミッターが負荷を吸収したためです。本番環境では、同じ総リクエスト率が何千もの異なるソースIPから到着し、リミッターは通過させるでしょう。

逆のケースも真です。リミッターに寛大なIPごとの予算がある場合、シングルIPテストはロードバランサーの集約制限にほとんど近づきません。アプリケーションは激しく負荷を受けますが、リミッターは介入せず、本番トラフィックが部分的にシェッドされる事実を隠します。

2. ハーネス上でWAFとボット検出がトリガーされる

1つのIPからの突発的かつ均一なリクエストパターンを監視するWAFは、まさに設計された通りに機能しています。負荷テストを検知し、トラフィックをフィンガープリントし、レート制限、チャレンジ、またはブロックを行います。一部のチームは、テストが疑わしく丸いスループット数で頭打ちになるのを経験して初めて、それがWAFの閾値だと気づきます。DDoS保護経路を試すテストには、まったく同じ理由で多様なソースが必要です—これらの防御は通常WAFとは別で、現実的に作用するためにソースIPの多様性にさらに依存しています。

テストのためにWAFを無効にすると、「症状」は「修正」されますが、より悪い問題が生じます：テスト経路が本番経路と一致しなくなります。多くのIPからのトラフィックのみが、WAFが本番閾値で作用中にアプリケーションが正常に動作するか検証できます。

3. CDNエッジ選択が1つのノードに凝縮される

CDNはリクエストをクライアントに最も近いエッジにルーティングします。1つのIPからのトラフィックは1つのエッジPOPに到着します。そこでキャッシュが溜まり、その後のすべてのリクエストはウォームストレージにヒットし、テスト期間中ずっとキャッシュヒットのレイテンシを報告します。一方、他の地域に散在する冷たいエッジの長いテールはまったく試されません。CDNを前面にしたサイトの負荷テストに関するガイダンスを読む人は、 sees これは次のように指摘されています：キャッシュ動作はリクエスト頻度だけでなく、ソースディストリビューションの関数です。

逆の場合も重要です。キャッシュミスのオリジンシールド動作では、CDNが同時発生したミスを単一のオリジンフェッチにまとめますが、これは1つのIPからは見えません。CDNが独立して扱うトラフィックがなければ、オリジン保護を検証することはできません。

4. AnycastおよびGeoDNSルーティングの決定は発動しない

Anycast IPはパケットをトポロジー上で最も近いデータセンターにルーティングします。GeoDNSはリゾルバーの場所に応じてホスト名を異なるIPに解決します。どちらの決定もリクエストがアプリケーションに到達する前に行われます。単一のテストソースからは、テストランナーがたどり着く1つのデータセンターしか見ることができません。リージョン間のルーティングやフェイルオーバーパス、遠隔リージョンへのレイテンシはすべて未検証のままです。

これは高価な盲点となる可能性があります。単一リージョンのテストは成功し、アプリケーションがグローバルに展開されると、テストが全く触れていなかったリージョンのユーザーはダッシュボードに表示されなかったレイテンシを体験します。Geo-distributed load testingはまさにこのギャップを埋めるために存在します。

5. コネクションプールの再利用とHTTP/2の合成がスループットを歪める

HTTP/2とHTTP/3クライアントは1つのオリジンごとに1つのコネクションを開き、その上でリクエストを多重化します。単一IP・単一クライアントから見ると、アプリケーションは何千ものストリームを担う1つの長寿命コネクションを見ています。サーバーのコネクション毎のアカウンティング、フローコントロールウィンドウ、先頭ブロッキングの動作は全てその1つのコネクションを反映しています。実際のプロダクションでは、何千ものコネクションがあり、それぞれが独自のフローコントロールウィンドウを持ち、スケジューラ圧力に独立に寄与しています。

同じことはロードバランサーでも起こります。コネクションごとのメトリクス、アイドルタイムアウトの回収、グレースフルリスタートのドレイン動作は、1つの太いコネクションと何千もの細いコネクションで全く異なって動作します。多くの異なるクライアントが多数のIPから負荷をかけるときにのみ、プロダクションのコネクション数分布を見ることができます。その分布を生成しないテストはこれらのいずれも検証できません。

6. ジェネレーター側のエフェメラルポートとソースNATの枯渇

Linuxのエフェメラルポート範囲は、単一のソースIPに対し宛先タプルあたり数万のポートしか割り当てません。1つのIPから高いコネクションレートを発する負荷ジェネレーターは数秒でポートを使い果たし、テストはシステムではなくテストハーネス側で頭打ちになります。クラウド環境ではさらに悪化します。NATゲートウェイの背後にあるEC2インスタンスは、同じゲートウェイを経由するすべてのトラフィックとポートプールを共有しているためです。これを経験した実務者はこれを「テストがこれ以上増えない壁」として知っており、単一IPテストにおけるTCPポート枯渇に関する長い説明文書で記述されています。

対策は単により強力なジェネレーターを用意することだけではありません。より独自の出口IPを持つジェネレーターをロードし、ポートプールを共有するのではなく複製します。

7. 可観測性が一つのバケットに集約される

多くの本番ダッシュボードはトラフィックをソースIP、ASN、または地理的地域ごとにバケット化します。単一IPのテストは単一のバケットを作成し、すべてのアラート、パーセンタイル、および飽和メトリクスがその一つのバケットに集約されます。テストを確認しているエンジニアは、見ている遅延が地域全体で均一か、一つに集中しているかを判断できません。また、実際のインシデントで使うスライス方法（最初の本能が「地域別のp99を見せて」や「ASN別のエラーレートを見せて」）を再現することもできません。ロードテストのメトリクスを本番のメトリクスと同じように扱うには、入力のソースの多様性が必要です。

クラウド出口の罠

複数のマシンに負荷テストを分散しようとするほとんどのチームは、それらのマシンを一つのクラウドアカウント、一つのリージョンの一つのNATゲートウェイの背後で稼働させます。その結果、技術的には複数IPですが、実際には単一ソースです。すべてのパケットは同じクラウドプロバイダの既知のASNからのソースIPで送信されます。WAF、ボット検出ベンダー、およびエッジプロバイダーはすべてクラウド出口範囲のレピュテーションデータを保持しており、多くはデフォルトでこれらの範囲からのトラフィックを特別に厳しく扱います。

これは二方向で重要です。まず、アプリケーションはテストをデータセンタートラフィックとして認識し、CDNのすべておよび多くのanycast展開で住宅用トラフィックとは異なるルーティングを受けます。次に、あなたのテストは競合ワークロードと同じネットワーク近隣から実行されるため、ベースラインの遅延がノイズになり、再現性が悪くなります。一般的なAWSロードテストセットアップはスケールには対応しますが、ソースの多様性には対応しません。

リアリズムには、ロード注入ネットワークが複数のクラウド、複数のリージョンにまたがり、理想的にはデータセンターと住宅用グレードの出口（例えば二つのクラウドプロバイダと住宅用またはモバイルキャリアの出口ネットワークを組み合わせる）が混在していることが必要です。そうすることで、テスト中にあなたのアプリケーションが見るIP/地理的な分布が本番に見られるものと似通います。

リアルなIP分布の実際

「多くのIP」というのは目標ではありません。目標は本番と一致する分布です。三つの特性が重要です。

地理的分布。 ユーザーの30％がEMEA、30％がAPAC、40％がアメリカにいる場合、テストはおおよそその割合で注入する必要があります。これが現実的なanycastルーティングとCDNエッジの選択を促します。また、単一地域のテストでは見えない遅い部分も浮き彫りにします。

ネットワークの多様性。 住宅ISP、モバイルキャリア、データセンターネットワークを混在させることで、MTU、パケットロス、中間ボックスの挙動など、プロダクションで見る動作の全範囲にアプリケーションをさらします。データセンターネットワークのみで実施されるテストは、モバイルネットワークがTLSを再交渉する方法やキャリアグレードNATが接続をクラスタリングする方法を見逃します。

現実のユーザーに似たIPごとのボリューム。 現実的なIPは1秒間に千リクエストを生成するわけではありません。NATの背後にいる数人の実際のユーザーのリクエストレートと、時折のパワーユーザーからのバッチを生成します。バーチャルユーザーシミュレーションは、IPごとのボリュームを尊重し、レートリミットやWAFのインタラクションを現実的な範囲内に保ちます。

単一IP vs 分散IP：それぞれが適切な時

現実世界のシナリオ

シナリオ1：「ブラックフライデーまで”合格”した」Eコマースのチェックアウト

一般的なパターンを考えてみましょう。アパレル小売業者が単一のクラウドリージョンから多くのバーチャルユーザーによる負荷テストを実施します。p95のチェックアウトレイテンシはSLO内に快適に収まります。ブラックフライデーになると、p95は数秒単位に跳ね上がり、カート放棄が増加します。

この種のインシデント後の分析で浮かび上がることが二つあります。CDNはほとんどのテストトラフィックを一つのPOPから提供していたことその間ずっと温かいままでした。実際の運用では、トラフィックが多くのPOPに分散し、そのうちいくつかはスパイク時にコールドスタートしました。2つ目の問題は、下流サービスのIPごとのレート制限です。テストは1つのIPの上限に即座に達し、その後はずっとその範囲内だったため、基盤となるキャッシュの無制限の成長経路を隠していました。同時HTTP対同時ブラウザの解説は、ハーネスの形状がユーザー数と同じくらい重要である理由を説明しています。

シナリオ2: セキュリティ監査に失敗したFintech API

少数のクラウドテストランナーから認証エンドポイントをロードテストする決済APIチームを考えてみてください。エンドポイントは目標RPSを予測可能なレイテンシーで維持します。数週間後、外部のセキュリティ監査が分散ソースパターンから同じエンドポイントにアクセスし、WAFの「異常なファンアウト」ルールをトリップさせました。スループットは崩壊し、監査ログはロードテストでは見られなかったブロックの一時停止を記録しました。

チームはWAFを通じてアプリケーションをテストしていましたが、WAFが疑わしいとみなすトラフィック形状では決してテストしていませんでした。監査がWAFが実際に介入した最初のケースでした。複数IP、複数ASNによるロードテストに移行することで、プリプロダクション環境で遅延の再現が可能となり、ルールを調整してから本番公開できます。これはまた、従来のHTTPロードテストが十分でない理由に関する多くの指針の背後にある故障モードでもあります。

シナリオ3: 静かなAnycastミスコンフィギュレーションのあるSaaSアプリ

パブリックAPIをAnycastロードバランサーの背後に移動し、標準のロードテスト準備チェックリストを実行するB2B SaaS企業を考えます。1つのリージョンからのテストは問題なく通過しました。公開後、遠隔のリージョンの顧客が予想の桁違いに高い中央値レイテンシーを報告しました。Anycastアナウンスが誤設定されており、そのリージョンからのトラフィックは最寄りのPOPではなく遠くのPOPへルーティングされていました。単一リージョンのテストでは検出できませんでした。なぜなら、ミスコンフィギュレーションはリゾルバがテストソースリージョンの外にある場合にのみ影響があったからです。

これは地理分散テストの典型的なケースです。ルーティングレイヤーの正確性は1つのソースからは見えません。

LoadViewがマルチIPロードテストを扱う方法

LoadViewはこの問題を中心に構築されています。プラットフォームの地理分散ロード注入ネットワークは、北米、EMEA、APAC、南米の数十のロケーションにわたっています。各ロケーションは独自の送信IP空間を持つ別々のクラウドリージョンであるため、これらすべてでテストを実行すると、ソースの分布がaターゲットアプリケーションがクラウドイグレスのアドレスのクラスターではなく、実際のユーザーの地理的およびネットワークの形状を反映していること。

上記の失敗モードに対して重要な設計上の選択肢は2つあります。まず、LoadViewは実際のブラウザでウェブアプリケーションの負荷テストを実行するため、接続数、HTTP/2の統合動作、サーバーでの接続毎の会計処理は、単なるプロトコルクライアントではなくリアルなユーザーのように見えます。次に、ロードインジェクターはクラウド側で管理されているため、チームがプロビジョニングするハーネスは不要で、NATゲートウェイのポートプールを管理する必要もなく、予算の都合で1つのリージョンで全ジェネレーターを実行する誘惑もありません。

この組み合わせは、どちらか一方よりも重要です。1つのIPからの実際のブラウザでも、上記のレート制限やWAFによる歪みを引き起こします。多くのIPでプロトコル専用のクライアントを実行しても、接続プールやHTTP/2の動作を正しく表現できません。複数のリージョンにまたがる多数のIPから実際のブラウザで負荷テストを行うことで、ネットワーク形状とクライアント形状の両方を、実際の本番環境と同様に再現できます。

ただし、期待値を正しく設定するための注意点として、LoadViewのジオ分散ネットワークはクラウドリージョン上に構築されているため、地理的・ASNの広域分布はありますが、初期設定のままでは住宅用やモバイルキャリアのイグレスは含まれません。本番トラフィックの意味ある割合がそれらのネットワークから来ている場合（たとえばモバイル中心の消費者向けアプリ）、LoadViewのリージョンクラウドインジェクターと、別途管理する住宅用またはキャリアグレードのソースを組み合わせるのが適切なパターンです。リアルなIP分布に関する前述の節では、ネットワーク多様性を単一ツールの特性ではなくテストプランの特性として扱っています。

実装チェックリスト

次回の重要なテストの前に、以下を順に確認してください。最初のステップは本チェックリストを上記のソース分布の議論に結びつけています。そこでマップした本番環境の形状が、その後すべてのステップで大きさの基準となる目標です。

本番のソース分布をマッピングする。1週間分のアクセスログを取得し、地域別、ASN別、IPプレフィックスの密度別にリクエストを分類します。NGINXやApacheの結合ログからユニークIPの数を得るには、例えば awk '{print $1}' access.log | sort -u | wc -l といった1行コマンドが使えます。これをGeoIPやASNのルックアップにパイプを通し、地域別とASN別の分布を作成します。その分布の形状がテストで再現すべきターゲットです。すでに同時ユーザーテストのデータを持っている場合は、それをベースラインとして使ってください。

スタック内のIP毎の制限を特定する。レート制限…rs at the edge, the API gateway, the application, and any third-party APIs。各々の予算に注意してください。少なくとも1つのIPで最も低い予算を超えないテストは、その制限を検証していません。

本番の割合に合わせてインジェクション領域を選択します。トラフィックの60％が北米から来る場合、ジェネレーターの60％もそこに所属させます。本番環境が不均衡な場合に「すべての地域を均等にテストする」ために過剰に回転させないでください。

送信先ASNの多様性を確認します。すべてのジェネレーターが1つのクラウド内にある場合でも、そのテストはクラウド送信の問題を抱えています。最低でも地域を混ぜ、さらに良いのはプロバイダーを混ぜることです（例えば、2つのクラウドプロバイダーを住宅用またはモバイルキャリアの出口ネットワークと組み合わせるなど）。

ソース別にレポートを分割します。レイテンシー、エラー率、スループットはそれぞれ地域とASNごとに分けて評価すべきです。もし分割結果が1つのバケットに収束する場合、そのテストは実質的に単一ソースでした。

既知のWAFルール発動を再現します。理解しているWAFルールをトリップさせるための小さなテストを実行し、それが発動することを確認します。もし発動しなければ、テストトラフィックはWAFにとって本番のように見えず、残りの結果も疑わしいものになります。

FAQ

なぜ単一IPからのロードテストは誤った数字を出すのですか？

本番トラフィックは多くのネットワーク上の多くのIPから到着します。レートリミッターやWAF、CDNエッジ、Anycastルーター、コネクションプールはいずれも、トラフィックが1つのソースから共有される場合に異なる動作をします。単一IPのテストは、実際のユーザーが決して通らない経路に負荷をかけ、逆にユーザーが常に通る経路を無視するため、レイテンシーやスループットの数字はテスト設定を反映しており、システムを反映していません。

JMeterのIPスプーフィングはマルチIPロードテストと同じですか？

いいえ。JMeterのIPスプーフィングはOSレベルで送信元IPを回転させますが、パケットは1台のマシンから1つのデフォルトルート、1つのASN、1つの地理的位置で送信されます。CDN、Anycastルーター、多くのWAFはネットワーク経路やASNをキーとして利用し、単にレイヤー3の送信元アドレスだけではありません。真のマルチIPロードテストは、別々のネットワークと地域にジェネレーターを分散させます。

リアリスティックなロードテストに必要なIP数はどれくらいですか？

特定の数はありません。適切な目標は、検証したいIPごとのレート制限を超えないように十分なIPおよび地理的多様性を持ち、CDNのエッジやルーティング分布が本番トラフィックの混合に大まかに合致することです。ほとんどの消費者向けアプリでは、複数の地域にわたる数十から数百の異なる送信元IPが必要です。

単一IPロードテストが許容されるのはいつですか？

単一IPテストは、コンポーネントレベルのチェック、つまりIPごとの制限がない内部ロードバランサーの背後にあるバックエンドサービス、データベースドライバーのベンチマーク、または応答の正確さだけを気にするスモークテストには問題ありません。ほとんどの場合、インターネット公開エンドポイントのエンドツーエンド性能検証には十分ではありません。

NATは単一IPを意味しますか？

多くのユーザーを表すことができますか？

NATおよびCGNATは多くの実際のユーザーを1つのアドレスの背後に圧縮するため、本番環境のIPごとのレート制限はある程度のクラスタリングを既に考慮しています。単一IPのテストの問題は、1つのIPが多くのユーザーを表せないことではなく、1つのIPが実際に持っているユーザーの分布を表せないことです。実際のトラフィックは1つではなく、数千のNAT出口にまたがっています。

防御できる数値を返す負荷テストを計画する

テストトラフィックが本番のソース形状に一致しない場合、テスト結果は本番を説明していません。多くの地域にわたる分散IP負荷テストは、キャパシティプランニング、セキュリティ検証、エッジルーティングの正確性のための「あると良い」ものではありません。分散負荷テストは、テストが実際のユーザーがアプリケーションに到達する方法を反映していることを確認するのに役立ちます。上記のチェックリストから始め、すべてのレポートをソースで区切り、次のリリース中ではなく、その前にWAFおよびレート制限の挙動に関する仮定を検証してください。