遅いところを直すだけでいいのですか？〜難しいチューニング個所の判断〜：性能エンジニアリング入門（3）（1/2 ページ）

はじめに

　前回「負荷テストのデータ、読めてますか？」では、負荷テストによって測定される値の中から、平均値とパーセンタイル値という極めて基本的な値から読み取れる事柄や、想定される性能問題について考えました。

　負荷テストは、高負荷状況での性能を確認するために重要なものです。しかし「負荷テスト→性能チューニング→再び負荷テスト」というモグラたたき的な対応ではなく、事前に高負荷状況でどうなるかを予測した上でシステム構築を行い、負荷テストはあくまで想定どおりの性能が出ているかどうかの確認作業としたいものです。

　そのために、第1回目で取り上げた待ち行列の特徴を考慮に入れ、「複数サーバから構成されるシステムが高負荷状況でどのような挙動を示すのか」を想定できることが必要になります。

問3：チューニングポイントの優先度

　前回の問題と同じように、問題文の記述だけでは不明なことがたくさんあります。いい換えると、その隠れた条件次第で、正解は1つではありません。また、APサーバかDBサーバかを画一的に決定できるとも限りません。

　以下ではいくつかの考え方を述べてみたいと思います。

経験則に基づく3つの改善案

【案1】「改善案が2つ考えられるなら、両方やればよいだろう」

　これが最も素直な答えかもしれません。性能トラブルが発生したときには、単一の改善策で問題がすべて解決することはまれでしょうから、複数の改善策を並行して検討すべきなのは確かです。

【案2】「一番処理時間が長い部分から削るのが鉄則。だからAPサーバを優先すべき」

【案3】「APのロジックを見直してもわずかしか改善できないことが多いが、DB側を見直すと性能が劇的に改善されるケースが多い。だからDBサーバを優先させる方がいい」

　この【案2】と【案3】のような経験則的な解答もあるでしょう。これはこれで妥当な判断かもしれません。

　けれど、今回の例題で考えてほしいのは“高負荷時にどうなるのか？”という点です。上記の【案1】【案2】【案3】にはいずれもこの観点が入っていません。その際には、問題では隠れている条件についても考える必要があります。

性能を定量的に扱うため、条件を明確に

　問題文に書いてあったのは、「APサーバの処理の方がDBサーバの処理よりも2倍以上重い」ということだけです。たったこれだけでは、性能について具体的な検討はできません。性能を数値として議論しようと思うならば、次の3点を明らかにする必要があります。

1. 負荷の程度（どのような処理をどれだけこなす必要があるのか）
2. 資源の量（サーバのCPUやI/O性能、ネットワークの帯域幅など）
3. 資源使用量の単価（処理を単発で実行したときの資源の使用量）

　話を複雑にしすぎないため、実際に稼働するシステムからするとシンプルすぎますが、これらの3つについて次のように仮定します。負荷の内容としては単一の処理だけ考え、資源はサーバのCPUだけにしておきます。

　CPUという資源を測る量は時間です。1CPU（シングルコア）の資源量は1秒につき1秒分です。マルチコア×複数CPUの場合はその数になります。

　1回実行するのに0.1秒かかる処理は、10コアあれば、毎秒100回処理できます。ただしサーバ仮想化環境では、異なる性能のCPUを持つ複数のサーバを全体でシェアするので、単純にCPU時間で資源量を測るのは困難です。そこで、GHz（ギガヘルツ）単位で仮想サーバのCPU資源量を示す場合がありますが、基本的には同じことです。

　ここで、1つ注意すべき点があります。問題文では「APサーバでは0.5秒掛かった」としか言っておらず、これがそのままCPUを消費した時間かどうかは分かりません。しかし、低負荷状態での実行では、掛かった時間≒CPU消費時間と見なしてよいケースが多いでしょう。

　例外は、大量のファイルアクセスがあるバッチ処理などや、DBサーバでキャッシュ率が低くならざるを得ないような場合です。もちろん、1処理ごとのCPUの使用時間を正確に測れる場合は測った方がよいのですが、難しい場合には低負荷時の実処理時間から推定し、代替することもあります。

条件を踏まえたおおざっぱな試算結果

　上記の条件で、低負荷時から高負荷時までの性能特性をおおざっぱに試算すると図1のようになります。多重並列処理の場合の待ち行列計算などは正確には計算に組み入れられていませんが、傾向としてはおおよそこのようになるはずです。

図1　秒間の処理量（横軸）と平均応答時間（縦軸）の関係

　応答時間の要件1.0秒を維持できるのは、改善前では60件／秒程度まで、AP改善の場合もほぼ同じ程度でしょう。DB改善の場合には、何とか100件／秒くらいまで伸びてくれそうです。なぜこうなるのかを少し説明します。

構成要素ごとの処理可能な上限値を知る

　最初のポイントは、APサーバ、DBサーバそれぞれの処理可能な上限値を知ることです。処理可能な上限値を決める要素は、サーバのCPUやメモリ、ディスクI/Oなどのほか、ネットワークの遅延や帯域などさまざまですが、前述の条件の通り、ここではCPUについてだけ考えます。

　実際のシステム構築の際にCPUしか考慮していないとしたら、それは明らかな考慮漏れです。ここではCPUだけにしておかないと話が複雑になりすぎますので、割り切ってそのようにしています。ご了承ください。

改善前の状態

　APサーバの総CPU能力は80コアですから、80÷0.5秒＝160件／秒が計算上の上限となります。DBサーバについては16コアなので、16÷0.2秒＝80件／秒が計算上の上限になります。

　ただ、複数CPUや複数サーバにしたときのスケーラビリティが100％（ロスなし）というのは都合がよすぎますので、再びざっくりとですが、90％と仮定しておきます。すなわち、改善前のAPサーバとDBサーバの処理可能量の上限は以下のようになります。

　ただし、1回目の待ち行列の基本で説明したとおり、この上限値（待ち行列での稼働率：ρ＝1）に到達する前に、待ち時間が急激に長くなって飽和することになります。

APサーバを改善した場合

　改善後の処理可能な上限量も計算してみます。

　改善されたAPサーバの処理能力上限は（80÷0.25）×0.9＝288件／秒になります。DBサーバは改善されないので、処理可能な上限値の72件／秒のままです。この状態では、DBサーバが処理可能な上限値の72件／秒に届く前に飽和してしまいます。

　詳しく計算はしていませんが、応答時間1秒を超えるのは60件／秒くらいでしょうか。AP側を改善すると、低負荷時の応答時間が0.7秒から0.45秒に大きく改善しますが、高負荷になっていくのと同じように、DBサーバの処理上限である72件／秒の前で飽和して破たんします。

　つまり、負荷が上がった場合には、性能は改善前とあまり変わりません。DBサーバ側が先に飽和してしまう状況では、このボトルネックを解消しない限り、ほかをいくら改善しても解決には至らないのです。

DBサーバを改善した場合

　APサーバは改善されていませんから、144件／秒が処理可能な上限です。DBサーバの処理能力上限は改善されて（16÷0.1）×0.9＝144件／秒になります。

　つまり、APサーバとDBサーバの両方の処理能力上限が144件／秒になり、最初は改善効果は低いように見えます。しかし高負荷に耐えられるようになるため、100件／秒くらいまでは応答時間1秒の範囲内で持ちこたえてくれそうです。

　「APサーバの方が並列多重度が大きい」といった点は後から提示した条件ですので、「そりゃずるい」と思われるかもしれませんが、実運用を考えるとそれほど奇異な条件ではないはずです。低負荷時の、例えば開発中に測定した結果と、高負荷時の結果は逆転することだってあるという一例です。

　この試算はあくまでも“上記で設定した条件の場合”です。条件が変われば答えも変わります。APサーバ側が先に限界に達する条件ももちろんあり得ますし、CPU以外がボトルネックになることもあります。