Productivity & Career

『詳解 システム・パフォーマンス 第2版』を読む：スケーラビリティ分析とモデリングの深淵

Otama
8分で読了
Progress 13 / 13
目次

はじめに

[!NOTE] この記事は、筆者が鈍器本を読みながら書き殴った個人的な読書メモをAIに食べさせ、ブログ用に読みやすく再構成させたものです。

これまで、CPUやメモリ、ネットワークといった各リソースの内部構造と、それを安全に観察するためのトレーシングツールについてまとめてきました。しかし、ツールを叩いて現状の指標を見るだけなら、慣れれば誰でもできることですよね。

私たちが本当に目指すべきは、システムの将来の限界を予測し、アーキテクチャ変更の妥当性を数学的に証明できるようになることです。今回は「第2章 メソドロジ」の一部であり、システム評価のもうひとつの強力な武器となる「スケーラビリティ分析とアナリティカルモデリング」の極意をチートシート化しました。

1. 限界を暴く「ニーポイント」とスケーラビリティプロファイル

スケーラビリティ分析とは、CPUやメモリ、スレッドといったリソース（または負荷）の増減に伴って、パフォーマンスがどう変化するかを研究することです。

システムに負荷をかけていくと、いずれリソースの競合や100%の飽和、ひんぱんなキューイングが発生し、パフォーマンスが線形に伸びなくなる「ニーポイント（knee point）」に達します。このニーポイントがどこにあるのかを事前につかむことができれば、アーキテクチャの限界を早期に暴き出し、本番稼働前の問題解決へと確実につなげることができますよね。

限界の現れ方（スケーラビリティプロファイル）には、いくつかのパターンが存在します。

  • 線形: リソースの追加とパフォーマンスの向上が完全に比例する理想的な状態です。
  • 競合: 共有リソースの競合により、パフォーマンスの向上が目減りしていく状態。
  • コヒーレンス: データの整合性を維持するためのロックなどのオーバーヘッドが足を引っ張る状態。
  • シーリング: バスのスループット上限など、システム的な天井に達して完全に頭打ちになる状態。

2. 数式で未来を予測する「アムダールの法則」と「USL」

計測やシミュレーションで得られた実測値を土台として、将来のパフォーマンスを関数的に予測するのが「アナリティカルモデリング」です。グラフの目視だけでなく、数式に落とし込むことでシステムの限界をより深く学ぶことができます。

アムダールの法則 (Amdahl’s Law)

並列化によるスケール効果を阻害する「シリアルなコンポーネントの競合」を計算に入れたモデリング方法です。数式化すると以下のようになります。

C(N)=N1+α(N−1)C(N) = \frac{N}{1 + \alpha (N - 1)}
  • C(N)C(N): 相対的な能力、容量（スループットなど）
  • NN: CPU数やユーザーによる負荷の大きさなどのスケーリングするパラメータ
  • α\alpha: どれぐらいシリアルかを表す競合パラメータ（0≤α≤10 \le \alpha \le 1）

この式が意味するのは、システム内に直列（シリアル）でしか処理できない部分 α\alpha が存在すると、リソース NN を無限に増やしてもパフォーマンスは線形スケーラビリティから離脱していく、ということです。現場では、ロードジェネレータ等で範囲 NN の実測データを集め、gnuplot や R 言語などの非線形最小二乗法を使った回帰分析によって、この α\alpha を逆算して導き出します。

ユニバーサルスケーラビリティ法則 (USL)

アムダールの法則をさらに拡張し、データの同期やロックなどの「コヒーレンス（一貫性）」による遅れのファクターを追加したものがUSL（Universal Scalability Law）です。

C(N)=N1+α(N−1)+βN(N−1)C(N) = \frac{N}{1 + \alpha (N - 1) + \beta N (N - 1)}
  • β\beta: コヒーレンスパラメータ（β=0\beta = 0 の場合、アムダールの法則と同一になります）

この数式モデルと実測データをプロットし、実際のデータが予測モデルから外れたときこそが、システムへの理解や実際のスケーラビリティの欠陥を精査すべき決定的なポイントになります。

3. 待ち行列理論とキューイングネットワーク

システム内で発生するスレッド待ちやブロッキング、I/Oの遅延は、「待ち行列理論（Queueing Theory）」を用いてモデリングできます。

リトルの法則 (Little’s Law)

待ち行列理論の基礎となるリトルの法則は、以下の簡潔な数式で表されます。

L=λWL = \lambda W
  • LL: システム内の平均要求数（キューに入っている要求数）
  • λ\lambda: 平均到着率（スループットなど）
  • WW: 平均要求時間（キュー内での平均待ち時間、平均レイテンシなど）

これを用いれば、「負荷（λ\lambda）が倍になったら平均応答時間（WW）はどうなるか」といった問いに数学的に答えることができるわけです。

ケンドールの記法と M/D/1 モデル

キューイングシステムはケンドールの記法によって A/S/mA / S / m（到着過程 / サービス時間分布 / サービスセンター数）の形式で分類されます。 単純な例として、ワークロードを一定時間で処理するディスクを「マルコフ過程の到着時間、決定論的サービス時間、サービスセンター1つ」の M/D/1 モデル として考えてみましょう。

M/D/1 モデルにおける応答時間 rr は、サービス時間 ss と使用率 ρ\rho によって以下の数式で計算できます。

r=s(2−ρ)2(1−ρ)r = \frac{s(2 - \rho)}{2(1 - \rho)}

この数式が示す真実は残酷です。サービス時間が一定（たとえば1m秒）だとしても、使用率が60%を越えると平均応答時間が倍になり、80%を越えると3倍になるという急激なレイテンシの劣化を引き起こします。使用率が100%に達するずっと前から、システムはすでにキューイングによる悲鳴を上げ始めているのです。これは笑えませんね。

4. 現場のキャパシティプランニングと要素分析

数式モデリングで限界の形を知る一方で、実際のキャパシティプランニングにおいては、より実践的・経験則的なアプローチが推奨されています。

  • リソースの限界メソッド: サーバーへの要求ペースとリソース（CPU、メモリ、DBコネクション等）の使用率を時系列でモニタリングし、限界を使い切るポイントを外挿法で推定します。
  • 要素分析: システムを構成する要素（CPUコア数、メモリ量、圧縮の有無など）のすべての組み合わせをテストするのは不可能です。そのため、「すべてを最高値にした状態」からスタートし、要素をひとつずつダウングレードさせながらパフォーマンスの低下率とコストを計測していく、という手法を取ります。

また、システム全体の限界性能が分かれば、HPA（オートスケール）の上限も「最大Pod数 ＝ DBの最大許容コネクション数 / 1Podあたりのコネクションプール数」といった算数に落とし込むことができます。テキトーではなく、根拠を持ってスケーリングの上限を設定できるのは強みですね。

おわりに

この章を読むと、「スレッドやリソースを増やせば増やすほど速くなるはずだ」という素人的な直感がいかに危険であるかが痛いほどよくわかります。

最後に一つ。本書には、私がもっとも目当てとしていた「データベースを共通リソースとした場合（悲観ロックなど）のアムダールの法則やUSLを用いた具体的な計算例」といった、詳細な数式モデリングの実例は残念ながら含まれていませんでした。期待していただけに少し残念ですが、現実はそんなに甘くないということでしょう。

現場のベストプラクティスとしては、未知の変数が多すぎる本番システムをすべて複雑な数式に落とし込むのではなく、リソースの限界メソッドや「要素分析」のように、実際に負荷をかけて限定された組み合わせをテストし、パフォーマンスの低下率を計測するという「経験則的なアプローチ（実験による分析）」を主軸に行うのが現実解のようです。

これらのモデリング理論で「なぜ限界が来るのか」という裏付けを持ちつつ、説明の妥当性に自信を持てるように準備をしていきたいですね。

関連記事