Azure Load Testingで複数のテストエンジンを使うとき、「エンジンごとに送信元グローバルIP（パブリックIP）を分けたい」という要件はよくあります。本記事では、どこでVNet/Subnetを指定できるのか、サブネット分割だけでIPが分かれるのか、そして固定IPとして確実に分離するための現実的な設計（NAT Gateway/NVA）を具体例つきで解説します。
結論：エンジン単位ではなく「テスト単位」でネットワークを選ぶ。IPを分けたいならテストを分割する
先に結論から整理します。Azure Load Testingは、同じテスト内で複数エンジンを動かせますが、「エンジンごとにSubentを個別指定して、送信元IPを確実に分離する」ためのUI/設定は基本的に想定されていません。そのため、要件を満たすにはテストを分割し、各テストを別サブネット（＝別の出口設計）に紐づけるのが最も分かりやすく確実です。
- やりたいこと：4台のエンジン相当の負荷をかけつつ、送信元IPを4つに分ける
- 現実的な解：テストを4つ作り、各テストをPrivateトラフィックで別サブネットへ割り当てる
- IPを固定・分離したい：サブネットごとにNAT Gateway（推奨）またはNVAで出口のSNATを制御する
| 確認したい点 | 答え（実務での結論） | 重要な補足 |
|---|---|---|
| Load Testingのどこで、エンジンごとにサブネットを指定できる？ | テスト単位でVNet/Subnetを選ぶのが基本。エンジン単位の指定はできない前提で設計する。 | 「4エンジン＝4サブネット」をやりたいなら、4テストに分けて1エンジンずつが最短。 |
| サブネットを分ければ自動で別々のグローバルIPになる？ | 必ずしもならない。自動割り当てに依存し、固定/保証されたIPにはならない可能性がある。 | ホワイトリスト登録など「厳密なIP」が必要なら、NAT Gateway/NVAで出口IPを設計する。 |
| エンジン同士でIPを確実に分離する追加設定は？ | サブネットごとに別NAT（別Public IP）を割り当て、送信元を固定化する。 | あわせてNSG/UDR/DNS/同時実行時の運用も整えると事故が減る。 |
なぜ「サブネットを4つに分ければ、結果としてIPも4つになる」と言い切れないのか
まず押さえておきたいのは、送信元グローバルIPは“どのサブネットにいるか”だけで決まらないという点です。クラウドではアウトバウンド通信がSNAT（送信元NAT）され、どのパブリックIPで外に出るかは、以下の要因に左右されます。
- トラフィックモード（Public/Private）：Azureが管理する経路で出るのか、VNet経由で出すのか
- サブネットのアウトバウンド設計：NAT GatewayやFirewall/NVA、ルートテーブル（UDR）の有無
- 自動デプロイされるPublic IPの扱い：環境が作り直されるとIPが変わる、共有されるなどの可能性
- 同一出口を共有していないか：4サブネットでも、結局同じNAT/Firewallに向けていると送信元は同じになり得る
つまり、サブネットを分けるだけだと「別々のアウトバウンド経路を取りやすい」状況は作れますが、“このサブネットは必ずこのIPで出る”という保証にはなりません。固定・分離が要件なら、ネットワーク側で出口IPを明示的に制御するのが安全です。
Azure Load Testingの通信モードを整理：PublicとPrivateの違い
IP制御の話は、まず通信モードの理解から始まります。要点だけ表にまとめます。
| 項目 | Publicトラフィック | Privateトラフィック |
|---|---|---|
| 負荷生成の場所 | Azure Load Testingの管理プレーン側（Azure管理） | 指定したVNet/Subnet内（Azureがエンジンをデプロイ/利用） |
| 送信元IPのコントロール | 難しい（Azure側の割り当てに依存） | ネットワーク設計で制御可能（NAT Gateway/NVA等） |
| 対象がプライベートエンドポイント/社内NW | 向かない | 向いている（到達性を作れる） |
| ホワイトリスト登録用途 | 運用が不安定になりがち | 固定IP化しやすい |
今回の「エンジンごとに異なるグローバルIP」という要件は、実質的にPrivateトラフィック前提で考えるのが近道です。
テストごとにVNet/Subnetを指定する場所
VNet/Subnetの指定は、基本的に各テストの設定で行います。ポータルの見え方は多少変わることがありますが、流れは次のイメージです。
- Azure Load Testingリソースを開く
- 対象のテストを選択して設定画面へ
- 負荷設定（Load/Trafficに相当するタブ）を開く
- トラフィックモードを「Private」にする
- 利用するVNetとSubnetを選択する
ここで大事なのは、選べる単位が「テスト」である点です。つまり、1つのテストで4エンジンを動かしている場合、設定としては「そのテストが使うVNet/Subnet」しか決められず、エンジンAはSubnet-A、エンジンBはSubnet-B…といった指定はしづらい設計になります。
エンジンごとにIPを分離する現実的なアプローチ
要件を満たすための設計を、分かりやすく「やること」に落とします。
アプローチ：テストを4つに分割し、各テストを別サブネットへ割り当てる
「4台のエンジンを使いたい」＝「並列に4つの負荷生成単位が欲しい」という意味であれば、テストを4つ作って各テストのエンジン数を1にするのが最もシンプルです。
- Test-A：エンジン数1、Private、Subnet-A
- Test-B：エンジン数1、Private、Subnet-B
- Test-C：エンジン数1、Private、Subnet-C
- Test-D：エンジン数1、Private、Subnet-D
そして、各サブネットの出口に「別の固定パブリックIP」を割り当てることで、結果として「各テスト（＝各エンジン相当）が別IPでリクエストする」形を実現します。
[Azure Load Testing] | Test-A (Engine 1) ----> Subnet-A ----> NAT GW-A ----> Public IP-A | Test-B (Engine 1) ----> Subnet-B ----> NAT GW-B ----> Public IP-B | Test-C (Engine 1) ----> Subnet-C ----> NAT GW-C ----> Public IP-C | Test-D (Engine 1) ----> Subnet-D ----> NAT GW-D ----> Public IP-D
構成例：4サブネット + NAT Gatewayで「固定のグローバルIP」を作る
NAT Gatewayは「特定サブネットのアウトバウンドを、指定したパブリックIPにSNATする」ための定番構成です。負荷テストのように同時接続が増えがちな用途でも扱いやすく、ホワイトリスト登録にも向きます。
構成の全体像
| テスト | トラフィックモード | 割り当てSubnet | 出口（推奨） | 送信元グローバルIP |
|---|---|---|---|---|
| Test1 | Private | Subnet-A | NAT GW-A（Public IP-A） | Public IP-A（固定） |
| Test2 | Private | Subnet-B | NAT GW-B（Public IP-B） | Public IP-B（固定） |
| Test3 | Private | Subnet-C | NAT GW-C（Public IP-C） | Public IP-C（固定） |
| Test4 | Private | Subnet-D | NAT GW-D（Public IP-D） | Public IP-D（固定） |
手順：ネットワーク側でやること（NAT Gateway方式）
ネットワーク側の準備ができると、以降の運用がかなり安定します。
- サブネットを4つ用意する
- ロードテスト用に切り出す（他ワークロードと混ぜない）
- 将来の拡張（エンジン増・並列実行）を見越してアドレス枠に余裕を持たせる
- 名前例：
subnet-alt-a/subnet-alt-b…
- 固定のPublic IP（Standard/Static）を4つ作る
- ホワイトリスト登録する対象になるため、静的（Static）を前提にする
- 管理台帳に「用途（Test1用）」を必ず残す
- NAT Gatewayを4つ作り、それぞれにPublic IPを紐づける
- NAT GW-A → Public IP-A
- NAT GW-B → Public IP-B
- NAT GW-C → Public IP-C
- NAT GW-D → Public IP-D
- NAT Gatewayを各サブネットへ関連付ける
- Subnet-A ← NAT GW-A
- Subnet-B ← NAT GW-B
- Subnet-C ← NAT GW-C
- Subnet-D ← NAT GW-D
- NSG（ネットワークセキュリティグループ）を見直す
- 基本はアウトバウンド中心に許可（テスト先のFQDN/宛先IP/ポート）
- 不要なインバウンドは閉じる（エンジンは待受サーバではない）
- 組織の標準があるなら、その標準に合わせる
手順：Azure Load Testing側でやること（テスト分割 + Privateトラフィック）
- 同じテストシナリオ（JMeter）をベースに、テストを4つ作成する
- スクリプトは同一でもOK（管理しやすい）
- 必要ならパラメータで「どのテストか」を識別できるようにする（ヘッダ付与、ユーザーIDプレフィックスなど）
- 各テストでトラフィックモードをPrivateにし、VNet/Subnetを割り当てる
- Test1 → Subnet-A
- Test2 → Subnet-B
- Test3 → Subnet-C
- Test4 → Subnet-D
- 各テストのエンジン数を1にする
- 「1テスト＝1エンジン相当」にして、ネットワーク設計と1対1で結びつける
- 負荷を増やす場合は、各テストの仮想ユーザー数を増やすか、テスト数を増やすかを方針化しておく
- （可能なら）Public IPの自動デプロイを無効化する
- 環境によって表示名が異なることがありますが、意図は「Azure側が自動でPublic IPを作って出口を握る」のを避けること
- 出口はNAT Gateway（固定Public IP）に統一する
「Public IPの自動デプロイを無効化」する意図と、やらない場合のリスク
ホワイトリスト登録や監査で送信元IPが重要な場合、運用で困りやすいのが「自動で割り当てられたPublic IPがいつの間にか変わっていた」「想定外のIPで出てしまった」といったケースです。
自動デプロイのPublic IPは便利な反面、次のような不確実性が残ることがあります。
- 負荷実行環境が作り直されるタイミングでIPが変わる
- 複数のテストや実行でIPが共有され、期待した分離にならない
- 「固定IPが必要」という前提の運用（先方のホワイトリスト管理）と相性が悪い
そのため、“IPを自分で固定・管理したい”なら、NAT Gateway（またはNVA）に寄せて出口を一本化し、「どのサブネットはどのIP」という対応関係を明確にするのが実務的です。
IP分離を壊しやすい落とし穴
設計通りに見えても、実際には「同じIPで出てしまった」「突然変わった」という事故が起きます。よくある原因と対処を表にします。
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| 4テスト全部が同じ送信元IPに見える | 4サブネットが同じ出口（同一NAT/同一Firewall）を共有している | サブネットごとにNAT Gatewayを分ける（または出口を分岐する） |
| PrivateにしたのにIPが安定しない | Azure側の自動割り当てに依存している／固定IP化していない | Standard/StaticのPublic IP＋NAT Gatewayで固定化する |
| テスト実行が失敗する／エンジンが起動しない | サブネットの権限不足、NSG/ルートで必要な通信が塞がれている | Load Testingに必要な権限付与、NSG/UDRの見直し（最小許可の方針で） |
| ターゲット側で断続的な接続失敗が増える | 同時接続が増え、SNATポートが不足している可能性 | NATにPublic IPを追加してSNATポートを増やす／接続の再利用を促す |
| 一部の宛先だけ繋がらない | DNS/名前解決、プロキシ設定、ルーティングが宛先ごとに異なる | 名前解決の経路（DNS）と、宛先別のルートを点検する |
SNATポート枯渇と「負荷テストならでは」の設計ポイント
負荷テストで見落とされがちなのが、アウトバウンド側のSNAT資源です。テスト対象が同一ホスト/同一ポートに集中し、短時間で大量の新規接続を作ると、出口側で使えるポート（SNATポート）が不足し、タイムアウトや接続失敗が増えることがあります。
「IPを分ける」だけでなく、安定して負荷をかけ続けるために、次の観点もセットで押さえると失敗が減ります。
- NAT Gatewayに割り当てるPublic IPを増やす（必要な場合）
IPを増やすと、利用できるSNATポートの総量が増え、枯渇しにくくなります。 - 接続を使い回す（Keep-Alive/コネクション再利用）
毎リクエストで新規TCP接続を張る設計だと、出口のポート消費が跳ねやすいです。 - 負荷の当て方を分散する
ターゲットが複数ホスト（複数FQDN）で構成される場合、リクエストを分散できると一極集中を緩和できます。 - 失敗率の切り分け
「アプリの限界」か「ネットワークのSNAT限界」かをログで分ける（ターゲット側の受信ログが特に重要）
IP分離の設計をした後に「なぜか失敗が増えた」となった場合、アプリだけでなく出口（NAT）の観点で見直すと原因に辿り着きやすいです。
運用をラクにする：4テストを同一品質で回す管理のコツ
テストを分割すると、IP分離は実現しやすい反面、運用が雑になると「設定差分による結果ブレ」が出ます。4テストを同一品質で回すための実務的なコツをまとめます。
差分を最小化する設計
- JMeterスクリプトは共通化し、必要な違いはパラメータで吸収する
- 共通の環境変数/パラメータセットを作り、Test1〜Test4で同じものを参照する
- テスト名だけでなく、送信元IP（NATのPublic IP）と紐づく管理台帳を用意する
同時実行・結果比較の考え方
「4エンジン相当」の負荷を再現したいなら、Test1〜Test4を同時刻に開始するのが基本です。結果の見方は次のどちらかに寄せると整理しやすくなります。
| 見方 | 向いているケース | 集計のコツ |
|---|---|---|
| 4テストを合算して「全体の負荷」として見る | 総負荷に対するSLO/エラーレートを見たい | 同一期間で開始・終了を揃え、重要指標（P95/P99、失敗率）を横並びにする |
| テストごとに分けて「IP別の挙動」を見る | IPごとにレート制限や経路差がある、監査が必要 | ターゲット側で送信元IP別にログを切り、差分の原因を追いやすくする |
送信元IPの確認方法
構成ができたら、必ず「本当にIPが分かれているか」を確認します。最も確実なのは、テスト対象システム側のアクセスログで送信元IPを確認することです（実運用に近い）。
- ターゲット側のログ（Webサーバ、WAF、API Gateway、LBなど）で送信元IPを確認
- 検証用に、送信元IPを返すエンドポイントへ1回だけアクセスしてログを採取する（許可された環境のみ）
- IPが想定と違う場合は、NATの関連付け・ルート・プロキシ設定を疑う
ホワイトリスト登録が目的なら、確認できたIP（Public IP-A〜D）を先方に渡し、登録完了後に再実行して疎通を確かめる流れが安全です。
NAT Gateway以外の選択肢：NVA/Firewallで出口を制御するパターン
組織のネットワーク標準が「インターネット出口はAzure Firewall（またはNVA）経由」と決まっているケースもあります。その場合はNAT Gatewayよりも、Firewall/NVA側でSNAT（出口IP）を制御する構成になります。
ただし、エンジンごと（サブネットごと）に必ず別IPで出すという要件を満たすには、次のいずれかが必要になりがちです。
- サブネットごとに異なる出口（Firewallインスタンス/ポリシー）へルーティングする
- 出口装置側で「送信元サブネット別にSNAT先IPを分ける」設計が可能か確認する
- 運用・障害時切り戻しも含めて、ネットワークチームと設計合意を取る
自由度は高い一方で複雑になりやすいので、「負荷テストの送信元IP固定」が主目的なら、まずはNAT Gatewayでシンプルに作る方が成功率は上がります。
よくある質問
1つのテストで4エンジンを使いながら、エンジンごとにIPを4つに分けられませんか？
“確実に分ける”という意味では難しいと考えるのが安全です。テスト単位でVNet/Subnetを選ぶ設計になりやすく、エンジン単位の細かなネットワーク割当ができない前提で、テストを分割して設計するのが実務では安定します。
サブネットを分けるだけで、固定IPになりますか？
固定IPが必要なら、サブネット分割だけでは不足です。出口（SNAT）を固定できる仕組みとして、NAT Gatewayに静的Public IPを割り当てるのが分かりやすい解です。
ホワイトリスト登録目的ではなく「IPを4つに分けたい」だけなら、もっと簡単な方法はありますか？
目的が「固定」ではなく「分散」だけなら、設計の自由度は上がります。ただ、相手側の制限や監査要件が後から出ることも多いため、最初から固定できる設計（NAT Gateway）にしておくと手戻りが減ります。
4つのテストに分割すると、結果が見づらくなりませんか？
見づらさは確かに増えます。そこで、開始時刻を揃える・スクリプトやパラメータを共通化する・重要指標を横並びで比較するという運用ルールを先に決めておくのがおすすめです。「IP別に結果を見る」という価値が増えるので、分割のデメリットを相殺できます。
まとめ：エンジン別グローバルIPは「テスト分割」＋「出口設計」で実現する
- Azure Load Testingは、基本的にテスト単位でVNet/Subnetを指定する発想で設計すると迷いにくい
- エンジンごとにグローバルIPを分けたいなら、テストを4つに分割して各テストを別サブネットへ割り当てるのが実務的
- サブネット分割だけでは固定・保証されたIPにならないことがあるため、NAT Gateway（またはNVA）で出口IPを固定する
- 負荷テストではSNAT資源の影響も出るので、NATの設計・接続再利用・ログでの切り分けまで含めると安定する
この構成にしておくと、「テスト先にIPをホワイトリスト登録してもらう」「IP別にレート制限の影響を見る」「経路差を検証する」といった要件にも対応しやすくなります。最初に“出口IPの設計”まで作り切るのが、Azure Load Testingを実務で失敗させないコツです。
コメント