仮想化で重要な事前検証と運用管理
ベンチマークテストのルール
ベンチマークテストの方法は、体系だってまとめられていないこともあり、あまり参考にすることができる情報が無い。ここではいくつかの守るべきルールについて解説する。
できるだけ実際のアプリケーションとデータを使うこと
様々なベンチマーク専用ソフトが存在するが、その使用方法や結果の分析はかなりの熟練を要する。もっとも手っ取り早い方法は、仮想化環境上で動作させたいアプリケーションとデータを実際に動かしてみることだ。
様々な条件で測定すること
ある特定条件のみで測定した結果は、その結果の妥当性を検証できない。例えば、以下のような様々な条件で同一の処理を行い、その結果を比較対照することで結果の妥当性を検証する。
- 仮想化しない場合
- 仮想マシンが1台の場合と複数の場合
- テスト処理のパラメータを変更した場合
- 機器構成を変更した場合
- 仮想マシンの設定を変更した場合
よくある誤解として、仮想マシンにCPUリソースをたくさん割り当てるとそれだけ性能が向上すると思われがちだが、物理、仮想に限らずSMPはOSやアプリケーションがマルチスレッドなどの並列処理を行うことではじめて性能が発揮される。アプリケーションの実行効率が良くないと、逆に性能が出ない場合もあるので注意したい。
数値化すること
性能は「速い」「遅い」で説明されがちだが、これらは相対的な尺度での判断である。システムの性能は絶対的な尺度で測られなければならない。
例えば以下のような目標値を設定して測定を行う。
- ある処理を○秒以内で完了
- 仮想マシンが○台同時にある処理を行い、○秒以内ですべて完了
- ○秒間で○件以上の処理を完了
リソースの使用状況を把握すること
単にテストを実行して結果だけを見るのではなく、テスト実行中のCPUやストレージの状況も見ておく必要がある。
例えば、あるテストで期待通りの結果が得られなかった場合、単にCPUなどのリソースが処理をせず遊んでいただけという場合がある。特に限界性能を測定するのであれば、各リソースが完全に使い切られた状態を作り出した上での結果を測定しなければならない。
図2: 新旧CPUのベンチマーク比較(クリックで拡大) |
この例では、新しいCPUでは3VMではCPUリソースを使い切れておらず、限界性能が6VMにあることが分かる。
手早く終わらせようとしないこと
ベンチマークテストの作業はシステム構築と異なり非建設的な作業のように思われるためか、手早く終わらせようとする傾向がある。そのため、テストの実行時間を秒単位で短く設定することがほとんどだ。しかし、きちんとしたベンチマークテストは、短くても5分、できれば10分以上処理を行った上での値を取り出してやる必要がある。
ベンチマークテストは短距離走ではなく、中距離から長距離のランニングだと考えるといいだろう。
結果を鵜呑みにしないこと
いくつかの結果が得られたところで、表やグラフにまとめてみただけで終わりとしてはいけない。もしテスト方法が根本的に間違っていれば、結果は全て意味のない数値となる。このような間違いは、条件を変えた結果の変化を観察することで分かることが多い。
例えば、負荷を高くしているにも関わらず、限界を超えても性能がまったく落ちないなど、動作としてあり得ない結果になっていないか確認する必要がある。
図3: Hyper Threadingのベンチマーク(クリックで拡大) |
この例では、Hyper Threadingを有効にすることで性能が30%程度向上しているが、仮想CPU数が増えすぎると少しずつ性能が低下していくことでピーク性能が「仮想CPU数=論理CPU数」であることが分かる。
ベンチマークテストは簡単なようでいて、意外と奥が深い作業である。可能な限りじっくりと取り組めるようにしたい。