性能とは

今回は「性能テスト」について紹介していきますが、その前に「性能とは何なのか」ということを考えてみたいと思います。性能とは何なのか？一言で言うと「システムが処理結果を返す力」です。

たとえば、インターネット上のショッピングサイトで商品を買ったことがある方は多いと思いますが、その時のことを思い浮かべてください。あなたは、とあるショッピングサイトにアクセスし、気に入った商品を選んでカートに追加し、商品購入の画面へ進み、商品を送ってもらう住所や決済のためのクレジット番号を打ち込み、やっとの思いで「商品購入」のボタンを押しました。しかし、なぜか何分たっても結果が返ってきません。不安になったあなたは一度ブラウザを閉じ、再度購入をしてみようとしたところで、やっと結果が返ってきました。それまでの時間、約3分。このような場合、あなたならどう感じますか？ もちろんイライラしますよね？ そう、この「システムが処理結果を返す力」こそが「性能」なのです。

この例では、「⁠システムが処理結果を返す力」がユーザの要望に応えられていないため、「⁠性能問題」が発生してしまっています。この「性能問題」を引き起こさないよう、システムの性能をあらかじめ把握しておくために実施するのが「性能テスト」なのです。

性能を把握するための要素

さて、それでは性能テストで性能を把握するためには、具体的には何を把握すればよいのでしょうか。結論から言うと、「⁠スループット」「⁠レスポンスタイム」「⁠リソース使用量」の3つの指標を把握する必要があります。

それでは先ほどの例で見ていきましょう。このショッピングサイトでは、普段は3秒以内に商品購入の処理結果を返していました。ところが、あなたがアクセスした時は、運悪くも特売セールの日であったらしく、普段の10倍ものユーザが商品を購入するためにアクセスしていたようです。つまり、大量のアクセスが発生したため、あなたへ結果を返す時間が遅くなってしまったようです。

ここで注目してほしいのは、「⁠性能」には「量を返す力」と「早く返す力」の2つの要素があることです。この2つの要素に分けて考えると、今回の例では、システムの「量を返す力」がアクセス数に追いつかなくなり、結果、「⁠早く返す力」が損なわれた、と考えることができます。

では、なぜ「量を返す力」がアクセス数に追いつかなくなってしまったのでしょうか。それを知るためには、システムの「力の源」がどれくらい使用されているかを調べればわかるはずです。システムの「力の源」とは何か？ それは「リソース」です。「⁠リソース」とはCPUやメモリ、ディスク、ネットワークなどの、システムが処理を行うために必要な資源のことを指します。

それでは、今回の例で挙げているシステムのリソースの使用量を見てみましょう。どうやらサーバのCPU使用率が常に100％にまで達しているようです。さて、今回の現象をまとめると、普段の10倍ものユーザがシステムにアクセスしてきたため、サーバのCPU使用率が100％に達してしまい、結果、あなたへ結果画面を返す時間が3分もかかってしまったようです。

ここまで見てきてわかった通り、システムの性能を把握するには「量を返す力」「⁠早く返す力」「⁠リソース使用量」の3つの要素を把握することが必要になります。そして、一般的に「量を返す力」のことを「スループット⁠」⁠、「⁠早く返す力」のことを「レスポンスタイム」という指標で表します。

スループットは、単位時間あたりに処理結果を返した件数です。たとえば、システムが1秒間に50件の処理結果を返していれば、スループットは「50件/秒」と表すことができます。一般的にはtps[1]やPV/s[2]などの単位で表すことが多いです。レスポンスタイムは、クライアントから処理要求を出してから、クライアントへ処理結果が返ってくるまでの時間です。複数の処理に対するレスポンスタイムを表すため、平均や90%ile[3]などの値で表すことが多いです。

このように、性能は「スループット」「⁠レスポンスタイム」「⁠リソース使用量」の3つの要素で評価されます。ここまでの話をまとめると図1のようになります。

性能テストの目的

さて、性能を把握するための要素がわかったところで、次は性能テストの目的について見ていきましょう。性能テストの目的は、冒頭でもお話しした通り、性能問題を引き起こさないためにあらかじめシステムの性能を把握しておくことです。具体的には「性能目標の達成」と「性能限界とその対応策」を把握する必要があります。それぞれについて見ていきましょう。

まず「性能目標の達成」ですが、この話をする前に性能目標について説明しなければなりません。性能目標とは、システムが必要とする性能のことです。例えば、1秒間に50人のユーザからアクセスがあり、それらのレスポンスタイムは3秒以内である必要があるシステムがあるとします。この場合、システムの性能目標は「スループット 50件／秒⁠」⁠、「⁠レスポンスタイム3秒以内」となります。この目標を満たしているかどうか、つまりシステムが必要とされる性能を持っているかを把握することが必要になります。

次に「性能限界とその対応策」ですが、これは、システムが出すことのできる最大の性能と、それ以上の性能を出すための対応策を把握することです。なぜこれらを把握する必要があるかというと、システムに対して性能限界以上のアクセスが発生しそうな場合に備えて、打つべき対策をあらかじめ立てておく必要があるからです。

今回のショッピングサイトの例だと、サーバのCPU使用率が100%まで達しており、性能問題が発生していました。したがって、この時に取るべき対策は、サーバのCPUを追加する、CPU使用率を下げるためのチューニングを施す等の対策が考えられます。しかし、これでは遅いのです。すでに性能問題は発生しています。もし、今回の特売セールで発生するアクセス数が、システムの性能限界以上のアクセス数であることがわかっていて、さらに性能限界に対する対策をあらかじめ立ててあれば、この性能問題は防げたはずです。そのため、性能限界以上のアクセスが発生しそうな場合に、予防的な対応がとれるよう、性能限界とその対応策を把握しておく必要があるのです。

ここまでの話をまとめると図2のようになります。

性能テストの方法

それでは、具体的に性能テストをどのように実施するのかについて見ていきましょう。簡単に言うと、システムに対して、運用中に想定されるアクセスを性能限界に達するまで段階的に増加させながら発生させ、その際の「スループット」「⁠レスポンスタイム」「⁠リソース使用量」を確認すればよいのです。

まず、アクセスの発生のさせ方ですが、一般的に「負荷生成ツール」というものを使用します。これは、1台のPCで複数ユーザのアクセスを発生させるツールです。負荷生成ツールの例としては、オープンソースのツールでは「JMeter」や「ApacheBench」などが挙げられます。負荷生成ツールには一般的にはスループットとレスポンスタイムを計測する機能が備わっています。そのため、この機能を使用すればスループットとレスポンスタイムが確認できます。

負荷生成ツールで発生させるアクセスに関しては、「⁠アクセスの種類」を考慮しておきましょう。たとえば、「⁠商品を購入する」「⁠商品を閲覧する」「⁠会員登録を行う」などの処理は、それぞれ違う画面遷移のアクセスになりますので、それぞれに合ったアクセスを発生させる必要があります。これらは「テストシナリオ」と呼ばれます。このテストシナリオを作りこむ機能も、一般的には負荷生成ツールに備わっています。

また、これらテストシナリオの「実行割合」も考える必要があります。運用中に発生する各テストシナリオのアクセス割合は、均等ではないはずです。たとえば、先ほどの例だと「商品を購入する」アクセスより、「⁠商品を閲覧する」アクセスの方が圧倒的に多いはずです。このように、性能テストで発生させるアクセスについては、運用中に実際に発生する割合を考慮する必要があります。

最後にリソース使用量ですが、これは一般的にはシステムのOSの機能を使用して確認します。Windowsであればパフォーマンスモニタ、UNIX系であればsar、vmstat、iostat、netstatなどを使用します。性能テストで一般的に確認されることが多いリソース使用量の種類を表1に挙げます。

ここまでで気付いた方もいると思いますが、実は「性能テスト」では同時に「負荷テスト」も実施しているのです。厳密に言うと「性能テスト」はレスポンスタイムが性能目標に達しているかどうかを確認するテストで、「⁠負荷テスト」はシステムがどこまでのスループットを出すことができるかを確認するテストです。しかし、両者を別々に実施するのは時間がもったいないので、一般的に「性能テスト」では両者を同時に実施します。

ここまでの話をまとめると図3のようになります。

性能評価の方法

最後に、性能テストで得られた結果を評価していく方法を見ていきましょう。性能の評価は、表2のような性能テストの結果から、図4のようなグラフを作成して行います。

図4は、横軸がアクセス数（件／秒⁠）⁠、左の縦軸がスループット（件／秒⁠）⁠、右の縦軸がレスポンスタイム（秒）です。このように、アクセス数を段階的に増加させて数回の性能テストを実施し、その結果を組み合わせてグラフ化し、評価をします。

まずは性能目標の達成確認をしましょう。今回の性能目標は、先ほど挙げた例と同じように、「⁠スループット50件／秒⁠」⁠、「⁠レスポンスタイム3秒以内」としましょう。図4と表2を見てみると、スループットが50件／秒の時のレスポンスタイムは2秒となっていることがわかります。したがって、このシステムは性能目標を達成していることがわかります。

では次に、限界性能を確認しましょう。限界性能は一般的には目標レスポンスタイムを超える前の測定とします。今回の結果を見てみると、アクセス数60件／秒の測定でレスポンスタイムが2.8秒、アクセス70件／秒の測定でレスポンスタイムが8秒になっていることがわかります。このことから、このシステムの性能限界は60件／秒であることがわかります。したがって、アクセス数が60件/秒の測定時のリソース使用量から、どのリソースが使い切られて性能限界に達しているかを確認し、それに対する対応策を立てる必要があります。

まとめ

昨今では、性能問題はシステムダウンと同等の扱いを受けるようになってきました。ですので、ひとたび性能問題を起こせば、それはシステムの顧客に多大な影響を及ぼし、一瞬で信頼を失ってしまいかねません。その信頼を取り戻すには多大な時間と労力が必要となるでしょう。

また、運用中に発生した性能問題というものは、そう簡単には解決できるものではありません。性能テスト時に性能限界に対する対応策が立ててあり、さらに、しっかりとした運用中の性能監視が施されているシステムなら問題はないのですが、そうでなかった場合、性能問題の原因が全くわからないため何も対策が打てず、何日間も性能問題を抱えたままシステム運用をすることになりかねません。そして最悪のケースでは、一度システムの運用を停止して性能テストを実施することになるでしょう。

こうした事態に陥らないためにも、システムをカットオーバする前に必ず性能テストを実施し、性能問題への対応策をあらかじめ用意しておきましょう。また、システムの運用開始後も性能監視ができる仕組みを導入し、確実に性能問題を予防することができる体制を整えておきましょう。