性能対策、できてますか？：性能エンジニアリング入門（1）（2/2 ページ）
3つの練習問題
この連載の前半は、練習問題を出し、それに解説を加える形式で進めていきます。2問目と3問目は次回以降に解説していきます。
では早速、問題です。
問1：待ち行列の基本
ある受付業務を、2カ所の窓口AとBで行っていましたが、来客の少ないBをAに一本化することにしました。Aの受付数は20％増加しますが、十分にこなせるはずと考えていました。ところが、客の待ち時間が2倍になりクレームが頻発。どうしてこのようなことが起こるか説明できますか？
問2：平均値とパーセンタイル値
ある機能の応答時間を測定したところ、平均値が500ミリ秒、90パーセンタイル値が350ミリ秒でした。これからどのような性能問題が考えられるでしょうか？
問3：チューニングポイントの優先度
APサーバとDBサーバの2層から構成されるITシステムがあります。高負荷時に平均1秒以内の応答時間が要件です。開発を終えて単発（低負荷）で性能を測定してみると、AP＝0.5秒、DB＝0.2秒が掛かり、合計0.7秒でした。高負荷状態になったときには1秒を超過することが懸念されます。さて、APサーバのロジックを改善する案と、DBサーバのデータ構造を改善する案の2案があるとき、どちらを優先させるのがよいでしょうか？
問1 - 待ち行列の基本の解説
基本情報処理技術者（FE）の教科書に出てきそうな問題ですね。
この例題は性能問題の最も基礎的な待ち行列に関するものですが、多くの場合、待ち行列については公式を覚えるだけで、性能問題につながる本質が理解されているとは言い難いように思います。受験用に“ρ／(1-ρ)”のような公式を覚えたものの、「これが何にどう使えるんだ？」と思った方も多いと思います。
ところで、話の題材を「2台のサーバ」としてサーバ統合のたとえ話にした方がITシステム向け問題らしくはなるのですが、ここではあえて「2つの窓口」という話にしています。その理由については後述します。
解説
この例題は待ち行列の説明をする際によく出てくる有名な話です（注1）。ただし、題材は窓口業務ではなくて、出港する護送船団の話で、第二次世界大戦中に米国海軍が実際に失敗した事例に基づいているとのこと。出航時間が想定以上に遅延する事態になったために、敵国の工作によるサボタージュを真剣に疑ったとの話もあるらしいのです。この実話のように、性能問題を短絡的に理解しようとすると間違いやすいということです。
待ち行列では、全体のキャパシティに対する利用率が高くなってくると、平均待ち時間が急激に増えてきます。
これは、利用率が低いうちは問題になりません。待ち時間はほとんど変わらないか、せいぜい業務量に少し比例するように見えるだけです。
利用率と待ち時間の関係は図2のようになります。利用率が80％〜90％くらいになると、わずかな処理量の増加でも平均待ち時間が大きく変化するようになります。高負荷時の性能問題は多くの場合、この傾向を見誤る点に原因があります。
図2 処理可能な総量に対する利用率と平均待ち時間具体的に、例題のように、＋20％で2倍時間が掛かるようになるケースを見てみましょう。
窓口で処理を行う時間（サービス時間）の平均を6分とします。毎時6人の客が来ると、（6×6）／60＝0.6で稼働率は60％になります。この場合、窓口でのサービス時間を含めた待ち時間は6×2.5＝15分となります。
ここで、窓口を統合して毎時8人の客にサービスをしなければならなくなると、稼働率はまだ80％で余裕がありそうに思えますが、待ち時間は6×5＝30分にまで増加してしまいます。
上記の試算では、窓口でサービスを受けている間のサービス時間も含めて、待ち時間として計算していますが、サービス時間を除いた純粋な待ち時間だけでも同じことです。平均サービス時間は混雑具合とは関係せず変わらないので、むしろ、よりはっきりと差が現れることになります。
以上が、問題「窓口を統合したら待ち時間が大きく増えてしまったこと」に対する解答です。
さて、例題の例えを、サーバ統合ではなくて窓口の統廃合にした理由について補足します。
上述の待ち時間は、窓口の数によって大きく変わります。簡単にいうと、窓口数が多いときには、利用率が高くなっても待ち時間が少なくてすみます（図3）。2つの窓口に別々に行列を作るときと、行列を1本にするときとでは待ち時間が変わるのです。銀行のATMコーナーなどで、行列を1列にさせているのはこれと同じ理由からです。
図3 窓口数が増えると混雑に強くなる。ただし、100％の直前で急激に悪化するのは同じITシステムの場合、この説明でいう窓口に当たるのは、CPUなどのサーバ資源になるでしょう。CPUが1つだけ、というシステムは、現在では非現実的でしょう。しかも、ネットワーク→CPU→ディスクI/Oのように、待ち行列が縦にも多段階で構成されていて、上記のようにスッキリと説明できるしろものではありません。そのため、待ち行列の基本的な特徴を簡潔に説明するために、条件をシンプルにしたかったというのが理由です。
ただし、条件が複雑なITシステムの場合でも、利用率が100％に近づいてくると、まだ余裕があるはずなのに急激に待ち時間が悪化するという傾向そのものは共通しています。高負荷時の性能値は、低負荷時の測定値から単純計算できないのです。
図2に示したような一番シンプルな待ち行列なら計算も可能ですが、現在のITシステムの複雑度は、手作業で計算可能な範囲を超えています。性能改善の手段として、「実システムで高負荷テストを実施して測定しなさい」と強くいうのは、直感や単純計算では結果を見誤る可能性が高く、実際の性能値は実システムで測定するまで分からないことが理由です。
注1：森村英典・大前義次, 「応用待ち行列理論 (ORライブラリー13)」, 日科技連、1975（待ち行列に関するいろんな参考書で書かれていることだと思いますが、私が参照したのは上記の書籍です）。
さて、次回の問題は？
さて、次回は問2について解説します。
ある機能の応答時間を測定したところ、平均値が500ミリ秒、90パーセンタイル値が350ミリ秒でした。これからどのような性能問題が考えられるでしょうか？
今回の待ち行列の基礎よりも、もうちょっと実践的な解説になるはずです。また、問題文は極端にシンプルですが、性能対策に関連するいろんな課題を隠してあります。どうぞお楽しみに。
著者プロフィール
TIS株式会社 先端技術センター
溝口則行（みぞぐち のりゆき）
かつて高トラフィックなインターネットサイトの構築・運用に関わったことがきっかけで、性能問題に真面目に取り組む必要性を痛感する。以来、同業のSI'erとの研究会にてITシステムの性能や可用性の検証活動に取り組んでいるが、活動後のビールが楽しみで続けている。勤務先ではオープンソースソフトウェアの活用を推進。TIS先端技術センターでは、採れたての検証成果や知見などをWebサイト http://TECH-SKETCH.jp/ でも発信中。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。