エンタープライズアプリケーションのための現実的なトラフィックパターンの生成方法

ほとんどのエンタープライズロードテストは、会議で誰かが決めた数字から始まります。5,000人の仮想ユーザー。10,000人。テストは合格し、レポートはファイルされ、しかしアプリケーションは四半期の最初の月曜日にクラッシュしてしまいます。

丸い数字は合意しやすいですが、ほとんど何も教えてくれません。実際のトラフィックはバーストで到着し、機能ごとに不均等に分割され、ボリュームがピークに達する正確な瞬間にその構成が変化します。均一なリクエストの平坦な壁を送るテストは、本番が行うのとは異なるコードパスを実行しており、キャッシュの挙動、クエリプラン、ロック競合などはライブシステムとは全く関係がありません。

すでに収集しているデータからトラフィックモデルを構築し、それを実行して結果に意味を持たせる方法を紹介します。

目次

1. エンタープライズのトラフィックが偽造しにくい理由
2. トラフィックデータがすでに存在する場所
3. 本番データからトラフィックモデルを構築する方法
4. トラフィックモデルが誤る箇所
5. 実際のエンタープライズトラフィックの形状
6. LoadViewでモデルを実行する方法
7. モデルを本番と照合する方法
8. 結論
9. よくある質問

エンタープライズのトラフィックが偽造しにくい理由

人数から直接テストを行うチームがつまずく3つのポイント。

同時接続数と到着率は同じ数字ではありません。 ステークホルダーが「5,000人のユーザーを処理する必要がある」と言った場合、どちらの意味か尋ねてください。同時に5,000人がサインインするのと、毎時5,000セッションが開始されるのは全く異なるテストです。間違えて多すぎる方向に考えると現実に起こらない負荷に何週間も調整を費やします。少なすぎる方向ではテストは何も教えてくれません。同時ユーザーテストは、どちらの数値を目標にしているかを知った上で意味を持ちます。これは利用者が実際に現れる様子を反映した到着率モデルと、固定の利用者数を維持する同時接続モデルとの違いです。パブリック向けトラフィックはほぼ常に前者で、コールセンターのデスクトップ、ライセンス座席、エージェントポータルなどユーザー数が限られたシステムは後者の挙動を示します。

トラフィックには形があり、その形が影響を与えます。 コネクションプール、オートスケーリンググループ、JITウォームされたアプリケーションサーバーは、限界値ではなく変化率に反応します。2,000の同時接続ユーザーを楽に処理できるシステムも、90秒で急増すると失敗します。

トランザクション構成はボリュームとともに変化します。 通常のボリュームではECサイトは主に閲覧ですが、フラッシュセール中はチェックアウトや在庫確認の呼び出しが同じリクエスト数に対し大きな割合を占めます。ダッシュボード上では総数は同じに見えますが、データベース負荷は違います。

平坦な仮想ユーザー数と形状のある到着曲線は、同じ平均スループットを生みつつスタックの全く異なる部分に負荷を与えます。

トラフィックデータがすでに存在する場所

新たな計測ツールは不要です。ほとんどはすでにどこかにディスクへ書き込まれています。作業はそれをセッションに紐づけ、ボットトラフィックを除外してから集計することです。

内部のエンタープライズアプリケーションは通常、解析タグをまったく持ちません。認証ログとアプリケーションサーバーログがギャップを埋めます。ログインイベントは到着率を示し、セッションあたりの最初と最後のリクエスト間の時間から持続時間が得られます。

本番データからトラフィックモデルを構築する方法

モデルは４つの出力で定義されます：到着率、トランザクション構成、思考時間の分布、地理的な分布。

ステップ1：モデル化する正確な時間帯を選ぶ

「ピークトラフィック」ではありません。ログから抽出した特定の日の特定の1時間です。過去12か月間の最も高いスループットの時間を取得し、さらに最も過酷なビジネスイベント（期末締め、オープン登録、ブラックフライデー、四半期報告）をカバーする別の時間帯も選びます。両方をモデル化してください。形状はほぼ同じではありません。

ステップ2：リクエスト数ではなくセッション数をカウントする

リクエスト数/秒は最も簡単に取得できますが、最も不安定な数値です。フロントエンドで3つのAPI呼び出しを1つにまとめるリリースを行うと、リクエスト数が3分の1に減っても需要は変わりません。セッション数/時間はユーザーの実際の行動を追跡します。シングルページアプリケーションでは特に差が大きく、1回のクリックが多数のバックグラウンドAPI呼び出しに広がります。

分析ウィンドウのセッション数/時間と、平均および90パーセンタイルのセッション持続時間を取得します。どちらも保持してください。ステップ3で重要になるのは尾部の値です。

ステップ3：セッション数を同時接続数に変換する

リトルの法則は到着率と同時接続数をつなぎます：

同時接続セッション数 = セッション数/時間 × （平均セッション時間（分） ÷ 60）

18,000セッション/時間 × (6分 ÷ 60) = 1,800 同時接続セッション

アプリケーションに18,000の同時仮想ユーザーを走らせると、実際のピークの10倍の負荷をテストしてしまいます。合格するはずのテストに失敗し、生産環境では決して到達しないボトルネックを追いかけることになります。

リトルの法則は平均値を使うため、P90は別のサイズ検査とし使用してください。P90が22分で平均が6分の計算では約6,600となります。これは遅い10パーセントのセッションと同じ長さでシステムをしのぐ同時接続数です。意図的に悲観的ですが、キャパシティプランニングでレポートスレッドやデータベース接続など稀少なリソースの計画に役立つ数値です。

ステップ4：トラフィックをビジネストランザクションに分割する

URLではなく、エンドポイントをビジネストランザクションにグループ化します：検索、詳細表示、カートに追加、請求書送信、レポート出力、給与計算。次に2つの構成を記録します。1つはウィンドウ全体のトランザクションシェア、もう1つは最も忙しい1分間のトランザクションシェアです。

任意のトランザクションで両者が数パーセント以上異なる場合は、両方の構成をテストに組み込みそれぞれシナリオとして実行してください。時間単位の構成だけではピーク時に最も急増するトランザクションが過小評価されます。

ステップ5：実際のセッションから思考時間を抽出する

思考時間を推測したり一定値を使ったりしてはいけません。固定の5秒停止はすべての仮想ユーザーを行進する列のように同期させて、実際の集団では生成されないとげとげしいスループットを生みます。

実際のセッション内の連続ページ読み込み間の間隔をRUMやAPMから取得し、それを分布として再現します。エンタープライズユーザーは二峰性を持つ傾向があります。流れを覚えていて素早くクリックする短い間隔と、ドキュメントの読書や電話応対中の長い間隔です。

ステップ6：ランプ（負荷の上昇）を実際の曲線に合わせる

ウィンドウ全体での分毎のセッション数をプロットし、テストのランプを一致させます。大半のエンタープライズアプリに当てはまる3つの形があります：

• ほぼ垂直。 製品リリース、チケット発売、証券取引所のオープン。ピークの同時接続数が2分以内に到達。
• 階段状。 各タイムゾーンで午前9時に起動される内部アプリ、地域ごとに1ステップ。
• 矩形波。 バッチ処理およびインテグレーショントラフィック。全容量でオン、全容量でオフ、ランプなし。

ステップ7：ユーザーがいる場所に負荷を配置する

分析やCDNログから地理的分布を取得し、同じ地域から負荷を発生させます。これは遠隔ユーザーのレイテンシを測るだけではありません。レイテンシは同時接続数に影響します。往復280msのセッションは20msのリンクのセッションより長く続くため、同一の到着率でより高い同時接続数を生みます。1地域からのみテストするとこれを完全に隠してしまいます。

トラフィックモデルが誤る箇所

全仮想ユーザーに同一のデータセットを使う。 10,000人の同じログイン、同じ商品ID、同じアカウント番号でキャッシュヒット率はほぼ100%になります。本番はそう動きません。実際の多様性に合う十分に広いデータセット（アカウントプール、SKUリスト、実行ごとのユニーク注文IDなど）でパラメータ化し、本番との比較でキャッシュヒット率を検証してから結果を信用してください。

ピーク時に他の処理が全く動いていない。 エンタープライズのピークはスケジュールされた処理と衝突します。夜間ETL、インデックス再構築、レポート生成、バックアップ、レプリケーション追いつき作業など。もし2時に照合ジョブが走り、バッチ統合ピークも2時なら、背景負荷のないクリーンなテスト環境は運用しているシステムを図っています。

ブラウザ集約型アプリでのプロトコルレベルテストのみ。 HTTPレベルのテストは記録されたリクエストを再生しますが、JavaScriptの実行、遅延ロード呼び出し、サードパーティタグの発火やレンダリングは行いません。シングルページアプリケーションや大型内部ポータルでは、クライアントが実際に行う大半の処理とユーザーに見える内容がすべて除外されます。実ブラウザでのウェブアプリ負荷テストが唯一の負荷下でのクライアントレンダリング計測方法です。

成功パスのみ。 実際のトラフィックにはカート放棄、戻るボタンループ、ログイン失敗、有効期限切れトークン、短気なダブルクリックなどが含まれます。ログイン失敗は別シナリオに値します。IDプロバイダーにアクセスし、通常はキャッシュをバイパスし、しばしばロックアウトロジックによって書き込みが追加されます。

実際のエンタープライズトラフィックの形状

頻繁に現れる3つのパターンと、それぞれのモデルが必要とするもの。

小売のフラッシュセールまたは製品ドロップ

到着はほぼ垂直で構成は3つのトランザクションに収束します：製品詳細、カートに追加、チェックアウト。商品ページがキャッシュ可能なら、みんな同じ人気アイテムを要求するためCDNヒット率は実際に向上し、単純なテストは簡単に見えます。負荷はキャッシュできない呼び出し、在庫チェック、カートの書き込み、支払い認証に一気に集中し、単一SKUの行レベル競合が発生します。混合比は1時間ではなくピークの1分でモデル化してください。

内部ERPの月末締め

セッション数は目立ちません。セッション長は異なります。レポート出力とバッチ投稿は数分かかり、到着率が平坦に見えても同時接続は増加します—リトルの法則が裏目に出る例です。また会計締め処理と重なるため背景負荷も計測に含めてください。長時間実行するレポートと投稿ユーザーは、それぞれ別のトランザクションクラスとして持続時間も別にしてください。平均に折りたたまないでください。

保険のオープン登録

数週間にわたり高負荷が続き、最後の2日間で急増します。セッションは長くなりがちで、利用者はプラン文書を読み、認証やダウンロードの処理が多くなります。数週間の部分は耐久テストであり、メモリリーク、コネクションプール枯渇、ログ量がピーク同時接続数より重要です。最終日の急増は別モデルで扱う必要があります。

LoadViewでモデルを実行する方法

モデルが完成すれば、テストセットアップはそれに従います。LoadViewは3種類の負荷曲線を提供し、モデルがどれを選ぶかを指示します：

EveryStep Web Recorderを使い、スクリプトがユーザーと同じ経路をリアルブラウザでデスクトップとモバイルのブラウザに跨って歩くように記録してください。地域分布は地理分散負荷注入ネットワークを使い、モデルのステップ7に合わせて設定します。

公開インターネットに接続しないアプリケーションの場合、オンプレミスのインジェクターがファイアウォール内部でロードテストを行い、同一プラットフォームへレポートし、これが多くの内部ERPやポータルトラフィックのモデル化方法となっています。

モデルを本番と照合する方法

トラフィックモデルは、出力を実物と比較するまでは仮説です。テスト実行中はバックエンド（データベース待機イベント、コネクションプール飽和、キュー深さ、オートスケール活動、CDNオリジン取得率、IDプロバイダー制限）をキャプチャしてください。これらの信号が以下の数値の解明に役立ちます。

実行後、同じ時間帯の本番との間で以下5つの指標を並べてください：

1. トランザクションあたりのスループット。 同じユーザー数でテストのスループットが本番よりかなり低ければ、思考時間が長すぎるかスクリプトが呼び出しを漏らしています。
2. トランザクション構成比率。 ここがずれるとスクリプトの分岐ロジックがユーザーの動きと合っていません。
3. キャッシュヒット率。 本番が70%の時にテストが95%ならデータセットが狭すぎます。
4. エラー率とエラー種別。 本番はほぼ常に基礎エラー率を持っています。テストでエラーがゼロなら何かを飛ばしています。
5. 平均セッション持続時間。 これはステップ3の同時接続計算全体を検証します。

続いてロードテスト結果を分析し、スクリプトを調整し再実行してください。通常2回の繰り返しで信頼できるモデルになります。

よくある質問

結論

現実的なトラフィックパターンは単一の数字ではなく4つの測定値です：セッション到着速度、セッション内の動作、ユーザーの行動間の待ち時間、接続地域。これらはすべてすでにログに存在しています。

これら4つを取得し、リトルの法則を使ってデータに裏付けられた同時接続数を出し、実際の1時間の形にランプを合わせます。そして本番と照合し調整します。これは丸い数字を選ぶより手間ですが、結果に基づいて行動できる唯一のテスト設計法です。

実ブラウザでトラフィックモデルをテスト

LoadViewは40以上のAWSおよびAzureゾーンからリアルブラウザでセッションフローを実行し、計測した到着パターンに合わせて負荷曲線を形作れます。エンタープライズロードテストプランはサブアカウント、SSO、レガシーツールからのスクリプト移行を含みます。

LoadViewパフォーマンスエンジニアとのデモを予約してトラフィックモデルを詳しく説明してもらいましょう。