負荷テストのデータ、読めてますか？：性能エンジニアリング入門（2）（2/2 ページ）
ピーク時になると応答時間が急激に悪化したので、とりあえずCPUとメモリを倍増しておけば大丈夫かな……と勘に頼って対応し、ドツボにはまった経験、ありませんか？ この連載では、インフラエンジニアなら最低限理解しておきたい性能問題の基礎を解説します。（編集部）
レベル2.2：テストシナリオに問題があった？
十分な時間を掛けて負荷テストを行い、結果を測定した場合でも、測定しようとした全機能（全画面）が目標どおりに測定できたかどうかを確認しないといけません。画面遷移の途中でエラーになってしまった場合に、後続の画面がなかなか実行されずに、測定サンプル数が極端に少なくなってしまうことはよくあります。このような例を示します。
例えば、ログイン画面→メニュー画面→条件入力→検索結果→（etc……）と続く画面遷移の中で、ログイン画面〜メニュー画面までは数千回実行されていて「十分な測定ができた」と安心していたら、その後の検索処理でエラーが頻発したために、検索結果画面は10回しか実行されていなかった、ということがあり得ます。
しかも、テスト開始直後のトランザクションはDBキャッシュが効かず、2回目以降よりも10倍も悪い応答時間だったとしたら、平均値としては残念な結果が算出されることになるでしょう。
レベル3: 極端に応答時間が悪くなる例に当たった？
測定サンプル数が多ければ例題のような逆転現象が起こらないかといえば、そんなことはありません。それでもやはり起こる場合があります。ここからが本当の性能問題です。
「カミナリの影響でネットワークが瞬断した」ような本当の異常値ではなく、一定の確率で再現する異常値が見られることがあります。低負荷時には見られないし、なかなか再現しないので「測定誤差」と片付けられる場合も多いかもしれません。
例えば、ほとんどの測定サンプルは高負荷時でも応答時間が100〜300ミリ秒の間で済んでいるのに、数％程度の割合で4秒（4000ミリ秒）を超える応答になってしまう場合があります。奇妙なことに、中間の0.6秒〜4秒になる場合は皆無。このような応答時間の分布グラフの「ふたコブ現象」は、テストに携わっているとときどき見られます。
このようなケースでは、90パーセンタイル値では上のコブが全部除外されてしまいますが、平均値では加算されてしまって、悪い結果になります。このケースでいえば、何らかの再現性のある明確な原因によって、上のコブ（4秒を超える待ち）が発生していると考えられます。根本的に性能問題を解決するには、その原因を除去する必要があるでしょう。
原因としては、いろんなことが考えられます。
例えば、ミドルウェアの設定値（コネクション数）が適切ではなく、タイムアウトエラーが中間層で起こっていているのに、アプリケーション層のエラーチェックが甘いのかもしれません。または、特定の条件に合致するデータにアクセスしようとしたときに、DB層での処理時間が急に長くなっているという場合もありそうです。
今回は測定データを読むことがテーマですからこれ以上は深掘りはしませんが、処理遅延がシステムを構成するどの層で起こっているか、その中のどの処理が原因かを追いかけていく性能プロファイリングが必要になるでしょう。
統計量について理解するための参考情報
パーセンタイル値や平均値などの統計量について勉強する場合、“統計学入門”のような数学の参考書が最初に思い当たりますが、面白く読める本はなかなか少ないでしょう。
その中で、オライリー・ジャパンの「Statistics Hacks」は読みやすいのでお勧めです。数学的に統計を理解するには不足しているかもしれませんが、本記事で解説したのと同じように、統計数値の意味を理解するのにはよいと思います。
【関連リンク】
オライリー・ジャパン - 「Statistics Hacks――統計の基本と世界を測るテクニック」
http://www.oreilly.co.jp/books/9784873113357/
また今回は、負荷テストの結果としてのパーセンタイル値を例示しましたが、実は、負荷テストツールにとっては、パーセンタイル値をリアルタイムで計算して表示するのは、比較的重い処理になります。ツールによっては、バージョンアップして基本機能からオプション扱いに変わっている場合もあるようなので、使用されるツールのマニュアルをご参照ください。一例として、OSSの負荷テストツール「JMeter」の解説記事を挙げておきます。
【関連記事】
Apache J Meter - User's Manual: Component Reference
http://jmeter.apache.org/usermanual/component_reference.html#Aggregate_Report
JMeterによるWebサーバ性能評価の勘所（3/3）（ただし、この記事は少しバージョンが古いときのものです）
http://www.atmarkit.co.jp/flinux/rensai/apache2_02/apache02c.html
次回の問題
さて、初回に提示した練習問題のうち、残るは1問となりました。
問3：チューニングポイントの優先度
APサーバとDBサーバの2層から構成されるITシステムがあります。高負荷時に平均1秒以内の応答時間が要件です。開発を終えて単発（低負荷）で性能を測定してみると、AP＝0.5秒、DB＝0.2秒が掛かり、合計0.7秒でした。高負荷状態になったときには1秒を超過することが懸念されます。さて、APサーバのロジックを改善する案と、DBサーバのデータ構造を改善する案の2案があるとき、どちらを優先させるのがよいでしょうか？
前回や今回に比べるとかなり実践的な雰囲気の問題ですが、前回の待ち行列の考え方が理解できているかどうかがポイントになります。ただし、今回と同様、この問題に書かれた条件だけでは確定的な結論には至りません。追加条件を仮定する必要があり、その条件によって回答は変わってきます。どうぞお楽しみに。
著者プロフィール
TIS株式会社 先端技術センター
溝口則行（みぞぐち のりゆき）
かつて高トラフィックなインターネットサイトの構築・運用に関わったことがきっかけで、性能問題に真面目に取り組む必要性を痛感する。以来、同業のSI'erとの研究会にてITシステムの性能や可用性の検証活動に取り組んでいるが、活動後のビールが楽しみで続けている。勤務先ではオープンソースソフトウェアの活用を推進。TIS先端技術センターでは、採れたての検証成果や知見などをWebサイト http://TECH-SKETCH.jp/ でも発信中。
Copyright © ITmedia, Inc. All Rights Reserved.