キャパシティプランニングの 3 軸:拡張・予測・問題切分と継続測定の目的 · log

LPIC201 の主題200(キャパシティプランニング)で、概念問題の答え合わせをしていて気づいたことがある。「継続的にシステムリソースを測定する目的は?」と聞かれて 1 つだけ選ぶ問題のつもりが、実は 3 つ全選択 が正解だった。キャパシティプランニングは「拡張・予測・問題切分」の 3 軸で、継続測定の目的もそれに 1 対 1 対応する。さらに「Web サーバの構成要素」は HW から利用者まで含む 6 階層だし、vmstat 出力からのリソース判定パターンも単一列ではなく組合せ判定が要る。本記事ではこの 概念寄りの章 を 1 本にまとめておく。

vmstatの読み方・ iostat / mpstat の読み方と対になる記事。

キャパシティプランニング 3 軸

軸	内容	例
拡張(Capacity Expansion)	将来の負荷増に備えて HW/SW 拡張計画	RAM 増設、HDD 追加、サーバ台数増
予測(Forecasting)	過去データから将来負荷を予測	sar / collectd の長期データから
問題切分(Bottleneck Identification)	性能劣化時のボトルネック特定	CPU / メモリ / ディスク / NW のどれが原因か

「拡張」は未来に備える、「予測」は過去から未来を読む、「問題切分」は現在の異常を特定する。時間軸が違う 3 つの活動を束ねた概念がキャパシティプランニング。

継続測定の目的(3 つ全選択型)

「継続的にシステムリソースを測定する目的」と問われたら 3 つ全部が正解になる。

障害の予兆検知(プロアクティブ監視)
性能改善計画の根拠データ取得
拡張計画(HW 増設)の根拠

これは前述の 3 軸とちょうど 1 対 1 対応する。

3 軸	継続測定の目的
問題切分	障害の予兆検知
予測	性能改善計画の根拠データ取得
拡張	拡張計画(HW 増設)の根拠

「1 つだけ選ぶ」つもりで読むと外す。全選択に切り替える合図は「継続測定の目的」「目的を全て選べ」など。

Web サーバの構成要素(6 階層)

[利用者]            ← アクセス元
   ↓
[コンテンツ]        ← HTML / 画像 / 動画 / DB データ
   ↓
[アプリケーション]  ← PHP / Python / Java 等のロジック
   ↓
[Web サーバソフト]  ← Apache / nginx
   ↓
[OS]                ← Linux 等
   ↓
[サーバ HW]         ← CPU / RAM / Disk / NIC

「Web サーバの構成要素」と問われたら、HW / OS / Web サーバソフト / アプリケーション / コンテンツ / 利用者 の 6 階層全てが該当する。物理リソース(HW / OS)だけで答えると、上位レイヤを取りこぼす。

構成要素の増加が当たるリソース

各要素が変動したときに、どのリソースに負荷が乗るかを 1 表で押さえておく。

増加要素	影響先リソース
利用者数	CPU / メモリ / NW
コンテンツ容量	ディスク / NW(転送量)
アプリ複雑度	CPU / メモリ
言語選択	CPU(インタプリタ vs コンパイル)

HW 増設の必要性

「アプリケーションの RAM 使用量が増加し、スワップ多発で性能劣化した場合の対応は?」という問いには、物理 RAM 増設(HW 増設) が正解。

思考フロー

swap 多発(si/so 高)
    ↓
RAM 不足が原因
    ↓
[対応 1] アプリのメモリ削減(チューニング、根本解だが時間が要る)
[対応 2] **物理 RAM 増設(HW 増設)** ← 標準解
[対応 3] スワップ拡張(応急処置、性能劣化は継続)

スワップ拡張は 応急処置にすぎず、根本解決ではない。RAM が物理的に足りないなら、増設するしかない。

対応策	階層	解の性質
アプリチューニング	SW	根本解(時間が要る)
HW 増設	HW	根本解(コストが掛かる)
スワップ拡張	SW	応急処置
サーバ分割	アーキテクチャ	構造的解

画像 → リソース判定(vmstat 応用)

主題200 の画像問題では vmstat 出力が出てきて「注目すべきリソースを選べ」というパターンがある。判定は単一列ではなく、列の組合せで行う。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 100000  10000 500000    0    0   100   200  500  300  5  2 90  3  0

注目リソース判定パターン

出力サイン	注目リソース	解釈
`wa` 高(10% 超)	ディスクI/O	iowait 高 = ディスク待ち
`si`/`so` 高	メモリ(スワップ)	スワップイン/アウト多発 = RAM 不足
`us`+`sy` 高(90% 超)	CPU	CPU 飽和
`b` 列大(uninterruptible sleep)	ディスクI/O	I/O 待ちプロセス多
`r` 列大(実行待ちプロセス数)	CPU	CPU 不足
`cs` 異常高	コンテキストスイッチ過多	プロセス過多 / I/O 多発

「1 つだけ選べ」と「2 つ選べ」では選び方が変わる。bi/bo 高 + wa 高が同時に見えれば「ディスクI/O」、si/so 高 + wa 高なら「メモリ + ディスクI/O」の 2 軸セット。vmstat の読み方そのものは vmstatの読み方を参照。

ボトルネック特定の手順

vmstat で全体俯瞰(CPU / メモリ / IO の異常列を見る)
異常な列に応じて深掘りコマンドを叩く
- CPU 高 → mpstat / top(プロセス毎)
- メモリ高 → free / sar -r
- ディスクI/O 高 → iostat / iotop
- NW 高 → netstat / iptraf

vmstat は 交通整理 の役で、原因の最終特定は専門コマンドに渡す、というのが運用上の感覚。

試験本番で踏みやすい罠 4 種

罠①: 「継続測定の目的」を 1 つだけ選ぶ

3 つ全選択が正解。「障害予兆 + 性能改善 + 拡張計画」。3 軸(拡張・予測・問題切分)と 1 対 1 対応していると思い出せば 3 つ選べる。

罠②: 「RAM 不足」へのスワップ拡張を根本解と誤認

スワップ拡張は応急処置。根本解は HW 増設(物理 RAM 追加)。性能劣化が続くシナリオで「スワップ追加」と答えると外す。

罠③: Web サーバ構成要素を「物理リソースだけ」と読む

利用者・コンテンツ・アプリも構成要素に含まれる。「HW + OS だけ」で答えると上位レイヤを取りこぼす。

罠④: vmstat 単一列でリソース判定

wa だけ見て「I/O」と即決すると、si/so 高 = メモリ起因の I/O 過多を見落とす。列の組合せで判定。

自己チェック

書きながら自問できるようにしておきたい項目:

キャパシティプランニングの 3 軸は何か(拡張・予測・問題切分)
「継続測定の目的」を全選択型で問われたら何を選ぶか(障害予兆 + 性能改善 + 拡張計画)
Web サーバの構成要素 6 階層は何か(HW / OS / Web サーバソフト / アプリケーション / コンテンツ / 利用者)
RAM 不足 + スワップ多発時の根本対応は何か(HW 増設、物理 RAM 追加)
スワップ拡張は根本解か応急処置か(応急処置)
vmstat の wa 高はどのリソースを示すか(ディスクI/O)
vmstat の si/so 高はどのリソースを示すか(メモリ、スワップ多発)
vmstat の us+sy 高はどのリソースを示すか(CPU)
ボトルネック特定の最初の一手は何か(vmstat で全体俯瞰)
「継続測定」と「スポット測定」の違いは何か(継続でないと予兆検知や予測ができない)

変更履歴

2026-05-06: 初版公開