ニフティの製品検査部は今年2月から，従来の機能テストに加え，負荷テストを実施している。テスト・ツールを効果的に使ってボトルネックを発見し，システムのチューニングをし，大規模アクセスにも耐えられるサービスを提供する。システムの限界を把握しておけば，稼働状況に応じて計画的なシステム補強ができる。ただし，適切な負荷テストには，高トラフィックを許容するテスト環境の構築と，テスト・ツールに関するノウハウが不可欠だ。
ニフティは今年に入り，サービスを開始する前に，システムに対する負荷テストを実施し始めた。大量のアクセスが見込まれるなかで，ユーザーの利便性を確保しようという狙いである。負荷テストの結果を分析し，システムを最適化することにより，サービスに必要なパフォーマンスを発揮することができる。また，システムに対するアクセス数の限界を把握しておくことで，アクセス数の増加やシステムの変更に迅速に対処できる。
機能テストだけでは不十分
|
|
写真1 ニフティのインスタント・メッセージ・サービス「デリポップ」の画面 クライアント・ソフトウエアをインストールして利用する。 |
しかし，機能テストだけでは不十分なのでは，という声が挙がってきた。ユーザーにストレスを感じさせないシステムの実現が求められているなかで，Webベースのアプリケーションや大規模なアクセスが予想されるシステムが増えてきたことからである。そこで，昨年の秋に負荷テストの実施を検討し始めた。
まずデリポップ・サービスで
最初に負荷テストを実施したのは，インスタント・メッセージ・サービス「デリポップ」である。デリポップは，専用ソフトウエアをインストールして，インターネット上で簡単な文章をやりとりするサービスである（写真1[拡大表示]）。今年2月にベータ版のサービスを開始し，5月から正式版として運用している。100万人のユーザー登録，2万人のユーザーの同時利用を想定したシステム構築を目指した。
|
|
図1 ニフティはサービスのリリース前にシステムを検査 ニフティのシステムは，社内で使うもの，インターネット上に公開するものを問わず製品検査部で必ず機能テストをする。負荷テストは任意。 |
負荷をかけるといっても，実際に何台ものパソコンを用意して同時にアクセスするといったやり方は現実的ではない。数千ユーザー規模のアクセスのテストも考えており，それだけの人的リソースもパソコンも用意できない。そこで，疑似的に多数のユーザー・アクセスを発生させることができる負荷テスト・ツールの利用を決め，マーキュリー・インタラクティブ・ジャパンの「LoadRunner」を選択した。機能テストで同社のテスト・ツール「WinRunner」を利用していたのでベンダー・サポートが受けやすかったからである。TCP（トランスミッション制御プロトコル）のほかに，UDP（ユーザー・データグラム・プロトコル）に対応していることも理由の1つである。当初，デリポップはUDPを利用する予定であり，ベータ版はUDPを実装していた。
ネット負荷の抑制のため3拠点を使ってテスト
本番のシステムは，アプリケーション・サーバー5台とデータベース・サーバー1台で構成する。アプリケーション・サーバーにデリポップのサーバー・プログラムを搭載し，ユーザー認証やメッセージ・データのやり取りを管理する。ユーザー情報，やり取りするメッセージは，データベースに登録される。
テスト・システムはWebサーバー1台，データベース・サーバー1台で構成した。単純計算で，本番システムで2万5000ユーザーの同時アクセスを可能とするためには，テスト環境で5000ユーザーの同時アクセスを実現する必要がある。
|
|
図2 負荷テストによる影響を抑えるため3拠点を使うテスト環境を構築 大森--館林間は十分な帯域がないため，負荷テスト用トラフィックを発生するエージェント・マシンは館林と100Mビット/秒程度で接続する蒲田に設置した。蒲田のエージェント・マシンを大森から制御する。 |
そこで，館林との間に100Mビット/秒程度の回線を引いてある東京都蒲田の拠点を利用することにした（図2[拡大表示]）。蒲田に疑似的なユーザーを作ってサーバーに負荷をかけるエージェント・マシンを設置し，それを大森のコントローラ・マシンで操作する形である。こうすれば，大森－蒲田間でやり取りするのは，エージェントへの指示などの制御情報だけで済む。
セキュリティの問題も浮上する。負荷テスト・ツールLoadRunnerはリモート・シェルを利用して通信をしている。これを利用できるように大森のネットワーク・セキュリティを変更する必要があった。ファイアウォールのルールを変更しなければならず，それは社内LANのセキュリティ・ポリシーの変更を伴う。ネットワーク管理者との調整に時間を取られることになった。また，ネットワークを介するテストなので，途中にあるルーターやファイアウォールのパフォーマンスもテスト結果に影響した。
それらを1つひとつ解決してようやくデリポップ・システムの負荷テストに取り掛かることができた。2月半ばから3月末日まで1カ月半のテスト期間のうち，このテスト環境の構築に大部分を費やした。
500ユーザーのアクセスでリリース
負荷テストをする際には，エージェントからどのようなアクセスをさせるかテスト・シナリオを作る必要がある。どのくらいの疑似的ユーザーを発生させ，どのような操作をさせるかを定義しておく。デリポップのテストでは，100ユーザー，300ユーザー，500ユーザー，1000ユーザーを疑似ユーザーとして発生させ，それぞれ，10バイト，100バイトと通信のデータ量を変えたシナリオを作成した。
|
|
写真2 マーキュリー「LoadRunner」のテスト結果 負荷テストの結果をさまざまなグラフにしてくれる。データをExcelに取り込むことも可能。 |
目標としていたのは5000ユーザー・アクセスだったが，今のシステム構成では，その数値までのパフォーマンス・アップは現実的ではないことがわかった。実際のアクセス数は見込みがつかないので，サービス開始後の様子を見ながら対応することにした。
5月には正式版がリリースした。その際，プロトコルをUDPからTCPに変えるなど若干のシステム変更があった。しかし，プログラムの根幹は変わらないため，300ユーザー，500ユーザーの負荷テストのみを実施し，パフォーマンスに影響が出ないことで十分と判断した。
デリポップのリリース後3カ月経過したが，システムは問題なく稼働している。実際のユーザーのアクセスは，テスト時のような頻繁ではなかった。その後，画像データをユーザー同士でやり取りする機能を追加した。「こうした負荷の増加は，負荷テストの段階でどのくらいまでは十分なパフォーマンスが出るかを把握しているので，機能追加に伴う負荷テストはしていない」（ニフティ システム統括部 製品検査部 課長 福山 誠氏）。
ツールの機能把握が不十分
今年8月には，ニフティのトップ・ページに広告バナーを出し，そのクリック履歴を記録するシステムの負荷テストを実施した。「アド・サーバー」と呼ぶもので，ニフティのトップ・ページにアクセスすると，ブラウザ上でJavaScriptが動作しアド・サーバーからバナーをダウンロードする仕組みである。
|
|
図3 負荷テストの結果が安定しなかったためテスト方法を変更 Webにアクセスすると，JavaScriptによりアド・サーバーからバナーをダウンロードする。テスト結果は，アクセス数の増加と，サ－バーのレスポンスがばらばらで，一貫性のないものになった。そこで，本来のテスト対象であるアド・サーバーのみにトラフィックをかけ，再度テストした。 |
ところが，アド・サーバーのバナーのダウンロードにかかる時間が，0.4秒と4秒の2つに分かれてしまうという結果になった。アド・サーバーのログを見ると，バナーのダウンロードを完了していないアクセスがある。マーキュリーに対応してもらったところ，疑似ユーザーの発生モードの選択を誤っていたことがわかった。
LoadRunnerでの疑似ユーザーの発生方法にはいくつかのモードがあり，そのうちテストで使用したのは「HTMLモード」であった。HTMLモードでは，サーバーに対してURLのアクセス要求を出し，サーバーのレスポンスを確認するだけの機能である。コンテンツのダウンロードを完了するところまでは見ていない。
そのため，コンテンツのダウンロードまでチェックする「HTTP詳細モード」に変更してテストした。ようやく正しいテストが実施できた。
