CPUを増やしても、返事が早くならない

架空事例：青葉機材の予約照会が混雑時に遅くなる。時間、件数、構成は独自の計算例で、実機測定ではない。並列化や平均値の式には、対象とする負荷・観測区間・処理の関係を明示する。

高速な計算機が、何かを待っている

予約を検索すると、一秒後に結果が届く。CPUの速い機種へ変更したが、体感はほとんど変わらなかった。

本事例の一秒を、互いに重ならない直列の区間へ分ける。CPUで計算する時間が0.2秒、DBや記憶装置を待つ時間が0.5秒、通信など残る時間が0.3秒だったとする。CPU部分だけを四倍にしても、全体は 0.2÷4＋0.5＋0.3＝0.85秒 である。

計算が速くなったのに、全体が四分の一にならないことは矛盾ではない。速くした区間が全体の一部だからだ。ただし、この足算は各区間が重ならないという作例の条件による。並行する呼出しの所要時間をすべて加えれば、利用者が実際に待った時間を二重に数える場合がある。

性能を考える出発点は、機器の名前ではなく、何の開始から何の終了までを短くしたいかである。原教材第14章のCPU時間と、第16章の容量・性能計画をこの線でつなぐ。1

命令数、CPI、周波数が答える範囲

CPUの実行時間を、命令数×平均CPI÷クロック周波数 と表す。CPIは一命令当たりのサイクル数であり、周波数は一秒当たりのサイクル数なので、単位を消すと秒になる。1

五億命令、平均CPIが2、周波数が2GHzなら、計算結果は0.5秒である。同じ仕事でも、命令セットやコンパイラによって命令数が変わり得るし、メモリ待ちなどによって平均CPIも変わる。周波数の高い方が必ず同じ比率で速いとは言えない。

このモデルを利用者の応答時間へそのまま置き換えない。プロセスがCPUを割り当てられるまでの待ちや、外部サービスの応答待ちは、別の経路から全体の時間へ入る。CPUの改善が効くかを判断するには、対象処理が実際にCPUで時間を使っているかを先に確認する。

一件を早くすることと、多くの件数を流すこと

パイプラインは、処理段階を重ねて、一定時間に完成できる件数を増やす。最初の一件が全段階を通る時間まで、同じ比率で短くなるとは限らない。スーパースカラは複数命令の発行・実行、SIMDは同じ命令を複数データへ適用することに関係する。1

この違いは、業務システムにも現れる。倉庫向け帳票を複数件並行して生成すれば、一時間に作れる帳票は増えるかもしれない。しかし、一件の帳票が外部の画像取得を待つ時間はそのままかもしれない。

毎秒何件を完了するかというスループットと、一件に何秒かかるかというレイテンシーを分ける。どちらも「性能」だが、要求する業務の事情が違う。夜間バッチでは所定の総量を朝までに終えること、対話画面では一操作を待てる時間が、それぞれ重要になり得る。

並列化できない部分が、改善の天井になる

固定した仕事量の75%を理想的に並列化でき、残り25%は変わらないとする。四つの処理資源へ均等に分け、同期や通信の追加費用を無視すれば、処理時間は元の 0.25＋0.75÷4＝0.4375 倍、速度は約2.29倍となる。

並列資源を無限に増やしても、残る25%があるため、理想上限は四倍である。これはアムダールの法則の形であり、改善しない部分が全体の速度向上を制限する。1

青葉機材では、帳票の各ページを並行して計算できても、最後の一つの共有ファイルへ順に書く処理が残っていた。その書込みが長いなら、計算担当を増やすほど効果は頭打ちになる。

なお、この比率は改善前の固定した処理を基準としている。データ量やアルゴリズムを変えた後まで同じ75%だと決めつけない。追加の同期やメモリ競合が大きければ、実測は理想値より悪くなる。式の上限は、実機の達成保証ではない。

使用率が低いのに、待ちがある

CPU使用率の平均が40%なら、余裕があるように見える。ところが、八つのコアの一つだけへ処理が集中していたり、短い混雑が長い集計区間へ薄められていたりすれば、待ち時間は残り得る。

Brendan GreggのUSE Methodは、資源ごとに使用率、飽和、エラーを分けて調べる。高い使用率の短い時間が平均に隠れることや、ソフトウェアの資源上限も分析対象になることを説明している。2

本事例では、CPUだけでなくDB接続プールを調べる。空いているCPUがあっても、利用可能なDB接続が尽きれば、要求は接続を待つ。反対にプールを増やせばよいとも限らない。DBへ一度に流れる仕事が増え、今度はDB内の競合が長くなるかもしれない。

「空きがある」と言うとき、その空きがどの資源のものかを特定する。物理メモリ、接続数、CPU時間枠、ストレージ容量は、互いの余りを自動的に代用できるわけではない。

同じ到着件数でも、滞在時間が伸びると混む

安定した運用を長く観測し、システムへ入る要求が毎秒40件、入ってから出るまでの平均時間が0.25秒だったとする。この境界内にいる要求の時間平均数は10件となる。

Littleの法則は、平均系内数L、系内へ実際に入る率λ、平均滞在時間Wの関係を L＝λW と表す。Karl Sigmanの講義資料は、長期平均の定義と、その対象となる系の選び方を明示している。3

同じ率で、平均滞在時間が一秒となる別の安定した状態なら、平均系内数は40件になる。要求数が増えなくても、依存先の遅延によって、内部で同時に抱える仕事が増えることが分かる。ただし、これは安定した状態の平均同士の比較であり、障害直後の一瞬の値をそのまま結ぶ式ではない。

また、この四十件を、そのまま必要なスレッド数だと解釈しない。非同期処理なら一つのスレッドが複数要求の待ちを扱うこともある。数えているのは要求であって、実装の実行単位ではない。平均系内数も、ピークに必要な容量を保証しない。

待ち行列だけを測ったなら、時間も待ちだけにする

受付後、実行開始までを待ち領域とし、実行中の処理を含めないなら、系内数は待っている要求だけである。この数に対応するWも、実行時間を含まない待ち時間でなければならない。

一方、受付から応答までを境界にするなら、待ちと実行の両方を含める。入口で拒否した要求の件数をλへ含めながら、通過した要求だけの時間をWへ使うと、対象が揃わなくなる。3

有限の観測窓では、窓の前から待つ要求や、窓の終わりにまだ完了していない要求も問題になる。完了した速い要求だけを集計して「平均が短い」と評価すると、停止に近い状態を見誤り得る。長期平均の関係と、今見えている測定値の集め方を分ける。

平均0.3秒の陰に、2.1秒の利用者がいる

百件のうち九十件が0.1秒、十件が2.1秒だったとする。平均は0.3秒である。平均0.5秒以内という条件なら通るが、一割の利用者は二秒以上待っている。

昇順に並べた観測値の何番目を見るかという単純な定義で、この百件の95パーセンタイルを95番目の値とすれば、2.1秒になる。分位点の補間方式はツールによって異なり得るので、少数標本では定義も確認する。平均と分位点は、同じデータについて異なる質問へ答える。

さらに、失敗した要求を即座に返すと、その速い失敗で全体の平均が改善する場合がある。Amazonの負荷制限の解説も、拒否された要求と成功した要求のレイテンシーを混ぜると、良く見える数値を作る危険を示している。4

青葉機材が短くしたいのは、利用者が必要な結果を得る時間である。成功した検索の時間、失敗割合、タイムアウトを分けて測る。返事が早いだけでは、仕事ができたことにならない。

増やす前に、入口と出口を観察する

待ちが長いとき、ワーカーを増やす案、処理する項目を減らす案、重複照会をまとめる案、受け付ける仕事に上限を設ける案がある。どれを採るかは、どこが詰まっているかで変わる。

負荷制限は、受け付けた仕事まで遅延で失敗する状態を避けるための一つの手段だが、拒否された利用者の要求が成功したことにはならない。4 本事例では、保留可能な帳票と即時性が必要な照会を分け、処理可能な量と待ちの上限を業務要件から考える。

改善後は、同じ種類の仕事、同じデータ量、同じ観測境界で比べる。そのうえで、キャッシュがない開始直後、ピーク、障害後に台数が減った条件を必要に応じて確認する。数字が変わったことと、狙った制約を解消したことを混ぜない。

知識を答案へ戻す

午前Ⅱ。 CPU時間、経過時間、スループット、レイテンシー、平均、分位点を区別する。並列化の式は固定した仕事と追加費用の仮定を、待ちの式は系の境界と平均の定義を確認する。

午後Ⅰ。 共有資源、直列部分、待ち場所、負荷の偏りを与件から探す。CPU増設や接続数の増加を、律速箇所と関係なく答えにしない。

午後Ⅱ。 性能要件、測定条件、特定した原因、選んだ方式、改善後の結果をつなぐ。理想計算と実測を分け、応答時間だけでなく成功率や業務の完了を評価する。

立ち止まって考える：平均系内数が十件だから、ワーカーを十個用意すれば必ず足りるか

平均系内数はピークの上限ではなく、ワーカーの個数とも同じではない。待ちを含む境界、実行モデル、到着の変動、依存先の能力を確認する。Littleの法則は平均量の関係を示すのであり、任意の容量で全要求を処理できると保証するものではない。

出典と照合範囲

[1] コンプリートテキスト第13・14・16・28章、IPA「SAシラバス Ver.5.2」4-7、4-15、5-5、8-4、18-1：CPU・並列化・性能計画・計算条件を出発点とした。時間配分、命令数、並列化率、百件の標本は独自に作成し、算術をPythonで確認した。実機性能を測定したものではない。公式シラバス

[2] Brendan Gregg, The USE Method：使用率・飽和・エラーの区別、短い高負荷と集計区間、ソフトウェア資源上限の説明を参照した。著者の経験的な効果の割合を本教材の保証としていない。著者の公開本文

[3] Karl Sigman, Notes on Little’s Law（2009）, pp.1–2：平均系内数・流入率・滞在時間の定義と系の選び方を、PDFの本文と画像で照合した。必要な長期平均が存在するなどの条件の下で使い、瞬時値やピークへ転用しない。Columbia University公開資料

[4] Amazon Builders’ Library, Using load shedding to avoid overload（2019）：過負荷時の仕事の保護と、速い拒否を成功時の時間へ混ぜる測定上の問題を参照した。AWS製品固有の設定を推奨する章ではない。公式日本語版