「想定外」の負荷での性能を測定する〜性能シミュレーションの適用例〜：性能エンジニアリング入門（最終回）（2/2 ページ）
性能モデルの構築とシミュレーションの結果
シミュレーション結果：改善前の状態
作成したモデルを基に、シミュレーションを実行した結果を示します（図3）。ここで紹介するのは、600ユーザーの負荷が掛かった場合と、800ユーザーの場合の状態のシミュレーション結果です。なお、400→600→800とユーザー数が変化した際の状況を比較するために、400ユーザーでの負荷テストの実測値を併記しています。
この結果を見ると、600ユーザー（このとき約4600ページビュー／分）では、レスポンス時間が10秒を超える画面が複数現れ、ユーザーから見ると「レスポンスが悪くてイライラさせられる」状態になると予想されます。さらに800ユーザー（このとき約4200ページビュー／分に低下）では、ログイン画面のレスポンス時間が急激に悪化し、ログインできない利用者も多数出てきて「サーバがダウンしている」ように見えるでしょう。
図3のグラフに示した3つのグループは、左から、400ユーザー（基準）、600ユーザー、800ユーザーの場合です。グラフ上の1本の棒が、1つの画面の応答時間を示しています。棒の中の色分けは、各種サーバやネットワークのうち、どこで時間を要しているかを示しています。
ボトルネック個所と性能改善の検討
400ユーザーの実測値および600〜800ユーザーでのシミュレーション結果から、アプリケーションサーバがボトルネックになって、高負荷時の性能が伸びないことが判明しました。また同時に、レスポンス時間も急激に悪化することが分かりました。
一般に、Webアプリケーションのボトルネックとなる可能性がある個所としては、以下のようなものが考えられます。
（1）アプリケーションロジック
（2）CPU不足
（3）メモリ不足
（4）ネットワークI/O
（5）ディスクI/O
今回のケースでは、分析の結果、原因はこれらの（1）〜（4）ではないことが判明しました。
（5）のディスクI/Oについても、今回の事例では、サーバのローカルHDDのI/Oがボトルネックになることはほぼないと考えられました。しかし、ネットワーク上のファイルサーバ（NFSサーバ）へのI/Oに依存する部分が大きいことも事実であり、これが当初から懸念されている部分でもありました。
また、ファイルサーバの性能限界やネットワーク負荷の面など、比較的観察しやすい点も問題はなさそうです。しかし、それでもボトルネックになっている可能性はあります。
再シミュレーションによる仮説の検証
こうした仮説を立てたならば、シミュレーションのメリットを生かして「NFSサーバ上のファイルI/Oを減らしたら性能はどうなるか？」を検証してみましょう。
まず、アプリケーションサーバ上のプロセスで、NFSサーバ上のファイルに複数回アクセスしていると思われる処理について、そのアクセス回数を半分にしてみます。例えば「10回のI/Oを5回に」「20回を10回に」といった具合です。もちろんこの時点では、このようなアプリ改修が現実的であるという根拠はありません。“仮に可能だったとしたら”という仮説に基づいた試算となります。
さて、この条件で、前のシミュレーションと同様に400〜800ユーザーの各シナリオをシミュレーション実行してみました。その結果が図4です。3つの負荷状態をそれぞれ図3と比較してみると分かるとおり、同じ負荷状態での同じ画面のレスポンスが相当程度改善していることが見て取れます。
改善前には、800ユーザーの負荷では20秒〜30秒も掛かっていた3画面の処理が、10秒強へと、応答時間が半分程度に短縮できています。また、その他の画面では10秒を超えるものはありません。この800ユーザーという高負荷状態においても、快適とはいえないまでも、かろうじて使用に耐え得る状態を維持できるであろうと予測できます。
この結果から、高負荷時にはNFSサーバへのファイルアクセスがボトルネックになってしまっている可能性が高く、そのアクセス回数を減少させることで高負荷時の性能を改善させられる可能性が高いことが、シミュレーション結果から判明しました。
シミュレーション技法適用上の課題と反省点
このようにシミュレーション技法をうまく適用すれば、システム構築プロジェクトにおいて性能品質を約束できるようになる重要な武器の1つになると考えています。
一方、適用に際しては難しさもあります。今回紹介した事例での適用に際しても、すべてが首尾よくいったというわけではありません。
以下に、いくつか課題を挙げます。
（1）シミュレーションモデルの構築にかなりの工数が掛かること
全機能をモデルに組み込むことは難しく、近似的に扱わざるを得ません。しかし、もともと性能シミュレーションでは、システム全体での性能特性を「マクロ的に予測する」ことが重要です。個々の機能単位のパフォーマンスを個別にすべて予測することを目標にしなければ、近似的モデルで十分だろうと考えます。
ただ、工数が掛かるということは、シミュレーション結果を得るまでに時間が掛かるということでもあります。
今回の事例では性能シミュレーションを、システムテスト後期フェイズにおいて、高負荷テストと併用しました。そのため、実機のテストで見つかった問題については、シミュレーション結果を待つ余裕もなく修正作業に入り、実機とシミュレーション用の性能モデルは次第に食い違ったものになってしまいました。結果として、性能シミュレーションは修正作業を後追いする形となり、「先回りして結果を予測して、それに基づいた改善策を示す」という効果が出しにくかった点が反省されます。
（2）DBサーバやストレージ装置の性能モデル構築の難易度が高いこと
測定を行わずにストレージ系のI/O量を把握するのは、ソフトウェアエンジニアにとっては難しいことです。実測定データが利用可能な場合でも、ストレージ装置のデータは解釈が難しいものの1つです。これについてはストレージの専門家に参画してもらった方が解決への近道になると思います。
（3）データ量増大に伴う性能影響の反映が難しいこと
現在のDBMSやファイルシステムは、当然のことながらデータ量に比例してI/O性能が悪化しないように工夫されています。このことが逆に、データ量が増大したときの性能特性の定量的予測を難しくしています。例えば、データ量が10倍になったときに、検索処理のI/O量とCPU使用量が何％増加すると見込んだらよいかが、シミュレーションモデルを作る上での課題となります。
（4）上流工程の段階で、ソフトウェアのリソース使用量の見積もりが難しいこと
上記の（2）（3）ではデータI/O量の見積もりの難しさについて触れました。それ以外にも、CPUにせよメモリにせよ、方式設計や外部設計をしている段階で、これから開発しようとしているアプリケーションシステムのリソース使用量を“適切な値で”予測することはかなり困難な作業です。
これについては、各種ITシステムの性能特性の事例データを多数持ち、類似事例のデータをベースにしてシミュレーションを行うのが得策であろうと考えています。
（5）サーバ仮想化環境やクラウド環境へ適用する際の課題
個々の仮想サーバにリソースを固定的に割り当てている場合には、仮想化機構が消費するリソースを別ワークロードとして設定しておくことで、このシミュレーション方法を適用することが可能です。
けれど、仮想サーバと物理サーバの対応付けが流動的な場合（昨今ではこれは特別なことではないでしょう）や、物理リソース以上にCPUなどをオーバーコミットして割り当てるような場合には、上記と同じような適用方法では無理があります。
これについてはまだ、解決の決定打を私は持ち合わせていません。物理サーバを共有する複数の仮想サーバを性能モデル上はひとまとめにする、などの代替策を取ることになるでしょう。
性能対策の今後〜性能技術力向上のために
性能品質の分野では、結果が冷徹に数字として出てしまいます。従って、工学的手法を着実に適用していくこと、すなわちエンジニアリングアプローチが必須の分野です。
性能エンジニアリングはまだ、構築後に得られる性能を、構築前の段階で100％的中させるほどに成熟しているわけではありません。業界全体としても緒に就いたところではないかと思っています。しかし、このシリーズで述べてきたことことを、再生産可能な状態に展開し、エンジニアを育成していくことこそが、目標達成の最短距離であると信じています。
「ITエンジニアは数字に弱い」といわれることがあります。一般には商人的感覚から、「カネ勘定に弱い」という意味で使われる場合が多いようです。けれど、私には「工学的な素養の足りないエンジニアが多い」という面もあるのではないかと感じています。前者についてはあまり心配していませんが、後者の方はとても心配です。
このシリーズを最後まで読んでいただいた方とは、この問題意識を共有できるのではないかと思います。これからも、ITエンジニアのレベル向上と、ITシステム構築のエンジニアリング化（工業化）に資する活動に、業界の中の意識を共有できる方々とともに取り組んでいければと思っています。
【参考情報】
- ＠IT：攻めの性能マネジメント
http://www.atmarkit.co.jp/farc/intro_index/attack_intro.html - ITpro：現場で使える性能マネジメント
http://itpro.nikkeibp.co.jp/article/COLUMN/20101101/353652/ - 「ITアーキテクト Vol.22」，IDGジャパン，2009年，特集1 システムの性能/投資対効果はアーキテクチャで決まる」
著者プロフィール
TIS株式会社 先端技術センター
溝口則行（みぞぐち のりゆき）
かつて高トラフィックなインターネットサイトの構築・運用に関わったことがきっかけで、性能問題に真面目に取り組む必要性を痛感する。以来、同業のSI'erとの研究会にてITシステムの性能や可用性の検証活動に取り組んでいるが、活動後のビールが楽しみで続けている。勤務先ではオープンソースソフトウェアの活用を推進。TIS先端技術センターでは、採れたての検証成果や知見などをWebサイト http://TECH-SKETCH.jp/ でも発信中。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。