ロードテストは認識の問題があります。依然としてボリュームの演習として広く扱われています：ユーザー数、リクエスト数、スループット量。これらの数字は設定が簡単で、報告も簡単で、実行間で比較もしやすいです。しかし、それらは不完全です。
本番システムは「ユーザー」を静的な数としては経験しません。時間を通じたアクティビティとして経験します。リクエストは不均一に到着し、セッションは重なり合います。ユーザーは一時停止し、再試行し、フローを放棄し、後で戻ってきます。いくつかのセッションは短く軽量です。その他は長期にわたり状態を維持します。これらの動態はピークの同時接続数よりもはるかにインフラの挙動を形作ります。
ここでロードテストモデリングが重要になります。バズワードではなく、トラフィックが実際にどのように動作するかを記述する学問としてです。セッション、ペーシング、ユーザー行動は合成テストを信用できるシミュレーションに変えるメカニズムです。これらがなければ、適切に実行されたロードテストであっても結果は安心できるように見えても、実際の障害を予測できません。
ロードテストモデリングはユーザー数の設定ではない
ロードテストモデリングの本質は、負荷がシステムにどのように入り、蓄積され、時間とともに持続するかを定義する行為です。それは設定作業でもなく、仮想ユーザーの目標数を選ぶことと同義でもありません。ロードモデルはシステムが経験する圧力の形を記述し、その圧力がどのように進化し、重なり合い、複合的に作用するかを含みます。
実際の環境では負荷は均等かつ瞬時にかかるわけではありません。負荷は波のように到来し、アクティブなセッションを通じて持続し、アイドル期間に一旦止まり、再試行や戻りを通じて再出現します。これらの動態はリソースが短時間だけ使われるのか連続的に負荷がかかるのか、内部状態が安定するのか変動するのか、障害が早期に表面化するのか潜在したままかを決定します。ロードモデリングはこれらの動態を偶然に任せるのではなく、意図的に捉えるために存在します。
ロードモデルは次のような質問に答えます：
- ユーザーは時間経過でどのように到着するか？
- どれくらいの期間アクティブでいるのか？
- どんなアクションを行い、どの順序でか？
- アクション間にどれだけのアイドル時間があるのか？
- いつ、なぜ離脱するのか？
同じリクエスト量を生成しても、これらの質問の答え方によってシステムの挙動は大きく異なります。ゆっくりと到来する千の短命なセッションは、長期間接続され認証され状態を維持する200の長時間セッションと同等ではありません。違いはメモリ使用量、接続プール、キャッシュの有効性、バックグラウンドタスクの負荷に現れます。
チームが同時接続数のみに注目すると、負荷をスナップショットに削減してしまいます。モデリングは時間の次元を取り戻し、そこにほとんどの実際の障害が存在します。
現実の単位としてのセッション
セッションは意図が時間をかけて進行することを表します。これはユーザーが実際にアプリケーションと対話する最も近い抽象化です。
セッションは重要です。なぜなら状態が蓄積するからです。認証トークンは発行され更新されます。キャッシュは温まり劣化します。サーバー側のセッションストアが増加します。データベース接続は期待よりも長く保持されます。ステートレスなアーキテクチャでさえ、繰り返されるアクセスパターンや共有リソースを通じてセッションに似た挙動を示します。
多くのシステムでは障害はピークリクエスト率よりもセッション期間とより強く相関します。メモリリーク、遅いガベージコレクション、スレッド枯渇、接続の飢餓はすべて短時間のピークではなく、持続的なセッション活動の後に表面化する傾向があります。
セッション認識型ロードテストはこの挙動を露わにします。システムにバーストではなく連続性を管理させます。リソースが適時解放されるか、バックグラウンドのクリーンアップが追いつくか、パフォーマンスが突然崩壊するのではなく段階的に劣化するかを明らかにします。
セッションを無視すると攻撃的に見えるが運用上浅いテストになります。セッションモデリングは持続性を導入し、持続性こそがシステムを正直に試す場所です。
ペーシング：時間は隠れた変数
ペーシングはセッション内でアクションが時間に沿ってどのように分配されるかを定義します。思考時間、ステップ間の遅延、新しいセッション開始の速度を含みます。
ペーシングが不適切だと誤解を招くロードテスト結果の最も一般的な原因の一つです。連続でトランザクションを実行する速いループは現実の何時間もの活動を何分かに圧縮します。これは本番ではほとんど存在しない人工的な競合パターンを生み、持続的な圧力によって表面化する時間依存の障害を隠してしまいます。
同様に問題なのは過度に同期されたペーシングです。すべての仮想ユーザーが同時に動作すると、システムの経験はs 非現実的なリクエストの整合性。プロダクショントラフィックはノイズが多い。リクエストは不完全に重なり合う。ユーザーによっては躊躇する者もいれば、すぐにリトライする者もおり、フローを完全に放棄する者もいる。
ペーシングはオープンとクローズドのワークロードモデルも区別する。クローズドモデルでは、ユーザーは応答を待ってから進行する。オープンモデルでは、システムの状態に関係なく到着が続く。それぞれに正当なユースケースがあるが、異なるストレスプロファイルを生み出す。間違ったモデルを使うと、自信を持った結論が実際のトラフィック条件で失敗する可能性がある。
正確なペーシングはテストを遅くしない。それを伸ばす。それがシステムに徐々に劣化を示させるものであり、単なる急性の障害ではない。
ユーザー行動がシステムの結果を形成する
ユーザー行動は負荷の上に重ねられたランダムなノイズではない。それ自体が負荷の構造である。
異なる行動パターンは根本的に異なる方法でシステムにストレスをかける。読み取り重視のブラウジングはキャッシュとCDNエッジに負荷をかける。書き込み重視のトランザクションフローはデータベースとキューに圧力をかける。アイドルセッションはメモリと接続スロットを消費する。リトライの挙動は障害を緩和するのではなく増幅する。
微妙な行動の変化でも結果が変わることがある。遅延下でのリトライの積極性が少し増えるだけでバックエンドの負荷が倍増する。わずかに長いセッション時間がキャッシュの有効容量を超えることがある。放棄の増加はクリーンアップ経路を完了しない部分状態を残す。
行動モデリングはチームにこれらの現実と向き合うことを強いる。それは負荷テストを理想化されたフローから実際の利用パターンの乱れたパターンへと移行させる。すべてのエッジケースをシミュレートする必要はない。支配的な行動を特定し、時間経過で自然に相互作用させることが必要だ。
システムが障害を起こすのはユーザーが完璧に振る舞うからではない。ユーザーが現実的に振る舞うからである。
持続的負荷とピーク負荷
ピーク負荷テストは有用である。天井を見つける。システムが完全に応答しなくなる場所を示す。しかし多くのプロダクションインシデントはその天井のはるか下で起きる。
持続的負荷は異なる問題のクラスを露呈させる。ゆっくりだが無制限に増加するメモリ。作業セットの変動により減衰するキャッシュ。満たされるよりも遅く排出されるキュー。最初は正しく反応し、長時間では不適切に振る舞うオートスケーリング。
これらの問題は短時間の攻撃的なテストでは顕在化しない。現実的なセッション重複とペースに基づくアクティビティが数時間続くことで現れる。実際の運用で表面化した時には、「トラフィック異常」と誤認され、アーキテクチャの挙動とは見なされないことが多い。
負荷テストモデリングは持続的テストを実用的かつ意味のあるものにする。テストの期間をシステムが実際に失敗するタイムラインに合わせる。
プロダクションに一致する負荷モデルの設計
効果的な負荷モデルは仮定ではなく観察に基づいて構築される。
プロダクションの分析、アクセスログ、APMデータは到着率、セッション長、一般的なパスを明らかにする。ユーザーがどこで停止し、どこでリトライし、どこでフローを放棄するかを示す。これらのシグナルはモデリングの決定を直接導くべきである。
実用的なアプローチは、少数の代表的なセッションタイプの特定から始まる。各セッションタイプはフロー、期間範囲、ペーシング特性を定義する。到着率はこれらのセッションの重なりを決める。アイドル時間と放棄は後付けではなく意図的に含まれる。
モデルは現実と検証されるべきである。セッションの長さやスループットが観察データと大きく乖離する場合、モデルは調整されるべきである。目標は秒単位の精度ではない。システムレベルでの忠実性である。
負荷モデリングは反復的である。アプリケーションが進化するにつれて行動も変わる。テストもそれに合わせて進化しなければならない。静的なモデルは静的な信頼を生み出すが、それは稀にしか正当化されない。
LoadViewによる負荷テストモデリングの適用
負荷モデリングは状態、タイミング、行動を第一級の関心事として尊重するツールを必要とする。リアルなブラウザベースのテストは、セッションの連続性を保持し、クライアントサイドのレンダリング、JavaScriptの実行、ネットワーク競合を含む現実的な実行経路を強制することでこれを可能にする。これらの制約は、ユーザー行動を近似する人工的な遅延に頼るのではなく、自然にペーシングと相互作用のタイミングを形成するため重要である。
LoadViewのスクリプト化されたユーザーフローは、多段階のインタラクションにわたってセッションを持続させつつ、思考時間、アイドル期間、リトライ行動を明示的に管理できる。シナリオベースのテストにより、一つのテスト内で複数のセッションタイプを同時に実行可能にし、長時間継続する行動と短時間の行動がプロダクショントラフィックの割合を反映して重なり合う。持続的かつ段階的な負荷構成により、システムがピーク需要時だけでなく、圧力が蓄積し持続する際にどう反応するかを明らかにする。
価値は生成することではなくより多くの負荷。それは正しい負荷を生成することにあります。
結論：負荷テストはモデリングの分野である
負荷テストは最初のリクエストが送信される前に成功または失敗が決まります。成功または失敗はモデル内で起こります。
セッション、ペーシング、ユーザーの行動がシステム内での負荷の現れ方を決定します。これらはメモリ使用、接続の寿命、キャッシュの効果、障害モードを形作ります。無視すると、見た目は印象的でも予測能力の低いテストが生まれます。
成熟したパフォーマンステストは負荷モデリングを第一級の分野として扱います。攻撃性よりも現実性を、スナップショットよりも時間を重視します。モデリングに投資するチームは、単に障害を早期に発見するだけでなく、それをより深く理解します。
結局のところ、システムはユーザー数に反応するのではありません。時間の経過で展開する行動に反応します。負荷テストも同様であるべきです。