＜技術解説＞Citrixのレスポンスが遅い…を未然に防ぐ！LoadRunnerによる負荷テストの勘所

現在LoadRunnerは新製品名称に変わっていますが、本記事では旧製品名称のLoadRunnerで記載しています。

Citrix Virtual Apps and Desktops（以下、Citrix）環境の遅延を未然に防ぐには、カタログスペックを過信せず、本番稼働前に「システムの限界点」を正確に把握しておくことが不可欠です。

本記事では、Citrix独自のICAプロトコルに対応したLoadRunner Professional（以下、LoadRunner）を活用し、実効性の高い検証を行うためのノウハウを公開します。

Citrixは非常に優れたソリューションですが、カタログスペック通りに動くかどうかは別問題です。実際の導入環境では、ネットワークやアプリの挙動が複雑に絡み合い、以下のような「想定外のパフォーマンス低下」が起きるケースがあります。

多くの企業が直面するのが、始業時間直後などにアクセスが集中する「ログインストーム」による影響です。短時間に大量のリクエストが押し寄せることで、StoreFrontやDelivery Controllerといった管理コンポーネント、さらにはセッションを受け持つRDSサーバーの負荷が急増します。

その結果、公開デスクトップやアプリが開くまでに多大な時間がかかったり、タイムアウトエラーが起きて社員が業務を開始できないケースもあります。

負荷はVDA（Virtual Delivery Agent）だけでなく、プロファイルサーバーやPVSサーバー（Provisioning Services）、およびそれらを結ぶネットワーク経路にも集中します。

その結果、仮想マシンの起動に失敗したり、移動プロファイルの読み込みに時間がかかりデスクトップが表示されない、といった問題が発生します。

ログイン完了後、ユーザーが業務アプリを一斉に操作することで、RDSサーバーのCPUやメモリが枯渇します。これにより、文字入力の反応遅延や画面描画のカクつき、アプリのフリーズといった現象が起き、ユーザー体験が著しく低下します。

これらの問題を未然に防ぎ、快適なCitrix環境を提供するためには、実環境に近い負荷をかけた検証が不可欠です。特に大規模環境やミッションクリティカルなシステムにおいては、本番稼働前に「机上の計算に基づく設計が、実際のサーバー環境（実機）でも正しく機能するか」を検証する負荷テストが極めて重要です。

アシストでは、Citrix環境の負荷テストツールとしてOpenText社の「LoadRunner Professional」を採用しています。

Citrix環境へのアクセスは、以下の2段階の通信で行われます。

JMeterなどのOSSツールは主にWebプロトコルには対応していますが、Citrix独自の画面転送プロトコルであるICAプロトコルには基本的には対応していません。その点、LoadRunnerはICAプロトコルに標準対応しているため、「StoreFrontへのログインから、公開アプリ上での業務操作まで」を一気通貫でテスト可能です。

LoadRunnerのライセンスは、システムのピーク時を想定した「テストで負荷を発生させるユーザー数」のみを対象としています。Citrixを利用する全ユーザー数で契約する必要がないため、大規模環境ほどコストを抑えられます。

さらに、利用期間についても1か月単位など、プロジェクトに合わせた短期契約が可能です。そのため、「システムのピーク時に想定されるユーザー負荷を、1ヶ月間だけ集中的に検証したい」といったスポットでのテスト要件にも柔軟に対応できます。

LoadRunnerは、テスト対象サーバーに特別なエージェントを導入することなく、OS標準のパフォーマンスカウンター経由でCPUやメモリ、ディスクI/Oのリソース値を取得できます。特に1台のサーバーで複数のユーザーセッションを処理するVirtual Appsでは、特定サーバーへの負荷集中が起こりやすくなります。

テスト実行中にリアルタイムでリソース状況をモニタリングできるため、ボトルネックの迅速な特定が可能です。

Citrix環境の導入やリプレースにおいて、稼働後のパフォーマンス不足を未然に防ぐには、実環境に近い負荷をかけた検証が不可欠です。

しかし、単にツールを動かすだけでは、本番の挙動を正確に予測することはできません。本番稼働への確かな根拠を得るために、現場で外してはならない「5つの勘所」を解説します。

Citrix環境の負荷テストは、「なんとなく負荷をかけて様子を見る」では意味がありません。現行環境でどのような問題が起きているのか、あるいは新環境で何を防ぎたいのかを言語化するところから始めます。

例えば、現行システムで始業時間帯のログインに時間がかかっているのであれば、「次期システムでは、同規模の同時ログインが発生しても、公開デスクトップが○秒以内に開くことを確認する」といった指標を整理し、言語化します。

目的が決まったら、「合格ライン」を数値で定義します。単一の平均値だけでなく、90パーセンタイル（全体の90%が目標値以内か）などの統計値を用いることで、ピーク時の「リアルな体感」に近い判断が可能になります。また、サーバー側のCPU使用率（継続して90%を超えない等）との両面で評価します。

Citrix環境の負荷テストでは、単なるWebシステムとは異なる「Citrix特有の挙動」を再現するシナリオ設計が重要です。

「一斉ログオン（ログインストーム）」だけでなく、日中の「複合的な業務操作」や「長時間連続利用によるリソース枯渇」など、実際の利用パターンに結びついたシナリオこそが、現場ユーザーにとって意味のあるデータとなります。

「負荷をかけること」は手段であり、ゴールは「ボトルネックの特定」です。クライアント側の応答時間と、サーバー側のリソース（CPU／メモリ／ディスクI/O）をリアルタイムで重ねて分析します。
どのコンポーネントが限界を迎えているかを正確に把握することが重要です。

事前のPoCや、潜在的な設定不備を洗い出すための「リハーサル」、さらにはチューニング後の再テストまでを見越した、数ヶ月スパンの余裕を持った計画が成功の鍵となります。

ここからは、アシストが実際に提供している負荷テスト支援のステップをご紹介します。

まずはお客様にて、「どのような状況を再現したいか」「何をもって成功とするか」を定義します。単にアクセスするだけでなく、実際の業務に即したシナリオと、明確な評価基準を設けることが重要です。

【シナリオと評価基準の例】

LoadRunnerは、メインの制御を行う「Controller」と、実際に負荷を生成する「Load Generator」で構成されています。Citrixの負荷テストでは画面転送の処理を行うため、一般的なWebシステムの負荷テストと比較してLoad Generator側に高いマシンスペックが求められます。

スクリプトやスペックによりますが、Load Generator 1台あたりで生成できる負荷は30〜40ユーザー程度です。そのため、目標とする同時接続数に応じて十分な台数を用意する必要があります。アシストではお客様のシナリオと過去の実績を踏まえて、最適な環境を構築します。

例)：1,000ユーザーの負荷をかける場合
余裕をもって、1台あたり30ユーザーと見積もると約34台のLoad Generatorが必要

環境構築後、負荷テストの実行計画（シナリオ）と、個々の操作手順（スクリプト）を作成します。

LoadRunnerの機能（VuGen）を使い、StoreFrontへのログインから公開アプリの操作までを記録します。デスクトップ内の操作（ICAプロトコル）は、転送されてくる画面の絵を操作するため、画像認識やマウス操作を主体としたRPAのような記述になります。

アシストでは過去のノウハウをもとに、以下のポイントを押さえてスクリプトを作成しています。

作成した個別のスクリプト（操作手順）を組み合わせ、本番の利用状況を模した「シナリオ（実行計画）」を作成します。

下図のように、「ログイン」や「業務操作」といったスクリプトを、検証目的に合わせて配分します。さらに「1分間に何人ずつログインさせるか（ランプアップ）」といった負荷の上げ方を詳細に定義することで、始業開始時のログインストームや、日中の複合的な負荷状況を正確に再現します。

スクリプト・シナリオ例

準備ができたら、いきなり本番テストを行うのではなく、リハーサルの実施を強く推奨しています。

本番相当のユーザー数でリハーサルを行うと、LoadRunner側のスクリプト調整不足だけでなく、Citrix側の設定不備が見つかることが多々あります。
大規模なテストには関係部署との細かなスケジュール調整が不可欠です。本番テストを確実に有意義なものにするためにも、リハーサル段階で潜在的な問題点を出し切っておくことが極めて重要です。

テスト終了後、収集したデータを分析しアシストにて報告書を作成します。LoadRunnerに付属する「Analysis」という分析ツールを使用すると、トランザクション応答時間の統計情報やサーバーリソースのグラフ表示を確認できます。「CPU使用率が高騰したタイミングで応答時間が遅延している」といった相関関係も確認可能です。

トランザクション応答時間の統計情報（報告書より）

CPU使用率のグラフ（報告書より）

プロジェクト開始前には、お客様のCitrix環境でLoadRunnerが問題なく動作するかを確認するPoCを実施しています。
ライセンスの手配、環境構築、スクリプト作成、リハーサル、本番テスト（および予備日）を含めると、PoCから結果報告までは3〜4ヶ月程度かかるケースもあります。

また、負荷テストの結果、大きなボトルネックが見つかりチューニングが必要になった場合は、再テストのためにさらに期間が必要です。余裕を持ったスケジュールをご検討ください。

スケジュール例

Citrix環境のパフォーマンスは、ユーザーの生産性に直結する重要な要素です。複雑な構成になりがちなCitrix環境だからこそ、LoadRunnerのように「Web」と「ICA」の両方に対応し、サーバーリソースまで詳細に可視化できるツールでの検証が求められます。

アシストではライセンスの提供だけでなく、豊富な実績に基づいた技術支援を提供可能です。Citrix環境のパフォーマンスに不安がある場合や、新規構築時の性能検証をご検討の際は、ぜひ一度ご相談ください。

「Citrixの負荷テストについて相談したい」「実際に製品を見てみたい」といった方は、ぜひ無料相談会やLoadRunnerのデモンストレーションにお申し込みください。専門エンジニアが、お客様の状況に応じてご提案をいたします。

矢野 英也

2001年入社。テストツールの紹介、サポート、技術支援を担当。年間何十件もの負荷テストを支援し、その経験を他のお客様にも伝えるべく、セミナーや技術情報配信を行っている。

月1回のゴルフと年1回の同期BBQを楽しみに日々奮闘中。昭和生まれのうま年。