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

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

　旧製品名称：LoadRunner Professional
　新製品名称：OpenText Professional Performance Engineering

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

本記事では、Citrix独自のICAプロトコルに対応したLoadRunnerを活用し、実効性の高い検証を行うための以下のポイントを解説します。

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ヶ月間だけ集中的に検証したい」といったスポットでのテスト要件にも柔軟に対応できます。

1台のサーバーで複数のユーザーセッションを処理するVirtual Appsでは、特定のサーバーへ負荷が集中しやすく、システム全体のボトルネックになりがちです。だからこそ、リアルタイムなモニタリングで「遅延が起きるかどうか」と「その原因」を特定することが不可欠です。

LoadRunnerなら、テスト対象サーバーに特別なエージェントを導入することなく、OS標準のカウンター経由でCPUやメモリ、ディスクI/Oのリソース値を直接取得可能。サーバーに余計な負荷をかけずに、負荷集中の兆候をいち早く、かつ正確に特定できます。

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

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

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

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

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

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

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

「負荷をかけること」は手段であり、ゴールは「ボトルネックの特定」です。そのためには、クライアント側の応答時間とサーバー側のリソース（CPU／メモリ／ディスクI/O）を、リアルタイムで重ね合わせて分析する必要があります。そうすることで、遅延の原因となっているコンポーネントを正確に特定できます。

負荷テストの計画では、問題が起きない前提でスケジュールを組んだり、リハーサルを省いて本番に臨んだりするケースが多く見られます。しかし、実際にはほとんどのプロジェクトで何らかの問題が発生しています。

過去には、リハーサルで解消できたはずの軽微な設定不備が本番当日に露呈し、テスト自体が延期になった例や、リリース直前のパフォーマンス不足に対して場当たり的な修正で対応せざるを得なくなった例もあります。

そのため、まずはリハーサルで「テスト環境そのもの」に問題がないかを十分に確認してください。そして、本番後のチューニングと再テストまでを見越した余裕のあるスケジュールを組むことが、システムの品質を確実に担保し、万全の状態でリリースするための鍵となります。

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

お客様にて「どのような状況を再現したいか」「何をもって成功とするか」を定義し、実際の業務に即したテストシナリオと明確な評価基準を設けます。

【評価基準の例】

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分間に何人ずつログインさせるか（ランプアップ）」といった負荷の上げ方を詳細に定義することで、始業開始時のログインストームや、日中の複合的な負荷状況を正確に再現します。

スクリプト・シナリオ例

前述したように、いきなり本番テストを行うのではなく、まずはリハーサルの実施を強く推奨します。

リハーサルを行うことで、スクリプトの調整不足やCitrix側の設定不備を事前に解消できます。また、問題発覚後のチューニングや再テストには数週間単位の期間を要するため、それらを見越した余裕のあるスケジュールを確保してください。

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

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

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

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

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

スケジュール例

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

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

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

矢野 英也

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

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