CPU スペック読み方と試算方法 — コア数・vCPU・RPS逆算

CPUスペックの用語整理

スケールアップを議論する前に、CPU スペックの用語を正確に理解しておく必要がある。見積書や CloudWatch のメトリクスで出てくる数値の意味が曖昧なまま試算すると、必要リソースを大幅に読み誤る。

物理 CPU / ソケット

マザーボードに刺さっている CPU チップの数。「2ソケット構成」なら CPU が2枚実装されている。

物理コア

1枚の CPU チップ内の独立した演算ユニット数。並列実行できるスレッド数の物理的な上限。

論理コア（スレッド）

HyperThreading（SMT）を有効にした場合、1物理コアが2スレッドに見える。物理コア × 2 = 論理コア。

vCPU

仮想マシン（VM）に割り当てられた仮想 CPU。多くのクラウドでは論理コア1本 = 1 vCPU として扱う。

項目	例：Xeon Silver 4316（2ソケット）	確認コマンド（Linux）
ソケット数	2	`lscpu \| grep Socket`
物理コア / ソケット	20	`lscpu \| grep "Core(s) per socket"`
合計物理コア	40（= 20 × 2）	`lscpu \| grep "Core(s)"`
論理コア（HT有効時）	80（= 40 × 2）	`nproc` / `lscpu \| grep "CPU(s)"`
クロック	2.10 GHz（Turbo 3.40 GHz）	`lscpu \| grep MHz`

⚠️ HyperThreading（HT）は万能ではない

HT は CPU のアイドル時間を有効活用する技術であり、真の並列演算能力は物理コア数です。CPU バウンドな処理（暗号化・圧縮・数値演算）では HT の効果は限定的（1.2〜1.4 倍程度）なため、試算には物理コア数を基準とし、HT の恩恵は安全係数で吸収する方が安全です。

使用率ベースの試算

最も現実的な試算方法は、現在の CPU 使用率の実測値から必要コア数を求めるアプローチだ。既存サーバーがある場合はこの手法を使う。

手順 1：ピーク使用率を取得する

性能評価期間中（業務ピーク時間帯）に以下を計測する。平均ではなく 95パーセンタイル値（P95） をピーク使用率として扱うのが一般的だ。

Shell — Linux / CPU使用率取得

# 1秒ごとに60回サンプリング（全コア平均）
mpstat 1 60 | awk '/Average/ && $3!="CPU" {print 100 - $NF "%"}'

# sar で過去データを集計（-u: CPU使用率, sysstat が必要）
sar -u -f /var/log/sa/saDD | grep Average

# top でリアルタイム確認（b: batch mode, n: サンプル回数）
top -b -n 5 | grep "Cpu(s)"

# vmstat で全体傾向を把握（1秒間隔）
vmstat 1 30

手順 2：試算式を適用する

■ 必要コア数（使用率ベース）

必要コア数 = 現コア数 × ピーク使用率(%) ÷ 目標上限使用率(%)

例：16コアのサーバーがピーク85%稼働 → 目標上限70%で運用したい場合
→ 16 × 85 ÷ 70 ≈ 19.4 → 切り上げて 20コア以上

💡 目標上限使用率の目安

Webサーバー・APサーバーは 60〜70%、DBサーバーは 50〜60% を上限の目安にすると、突発的なスパイクに対応できる余裕が生まれます。バッチ処理が深夜に走るサーバーは昼夜の差を考慮してさらに低めに設定します。

スループット（RPS）からの逆算

新規構築や大幅な負荷増加が見込まれる場合は、 目標 RPS（Requests Per Second）から必要コア数を逆算する。既存サーバーがなくてもスペックを見積もれる。

手順 1：1リクエストあたりの CPU 消費時間を計測

負荷試験ツール（Apache JMeter / k6 / wrk）で実際にリクエストを流し、CPU 消費時間を計測する。

Shell — wrk による負荷試験

# wrk: 4スレッド・100接続・30秒間テスト
wrk -t4 -c100 -d30s http://target-server/api/endpoint

# 結果例
# Requests/sec:   1234.56       ← 実測 RPS
# Latency:          12.34ms avg  ← 平均レスポンスタイム

# mpstat でテスト中の CPU 使用率を並行取得
mpstat -P ALL 1 30

手順 2：試算式を適用する

■ 必要コア数（RPS逆算）

必要コア数 = 目標RPS × CPU処理時間(秒/req) ÷ 目標CPU使用率上限

例：目標 2,000 RPS、1リクエストあたりの CPU 処理時間が 5ms（= 0.005秒）、上限 70% の場合
→ 2000 × 0.005 ÷ 0.70 ≈ 14.3 → 16コア（次の偶数に切り上げ）

⚠️ CPU 処理時間 ≠ レスポンスタイム

レスポンスタイムには I/O 待ち（DB クエリ・ファイル読み込み）が含まれます。CPU 処理時間のみを測定するには、perf stat や APM ツール（Datadog / New Relic）の CPU プロファイリングを使い、I/O 待機を除いた実行時間を確認してください。

クラウドと物理の換算

クラウドの vCPU と物理コアは 1:1 ではない。適切に換算しないと、期待したパフォーマンスが出ない、あるいは過剰スペックを買い続けることになる。

AWS EC2 の vCPU の仕組み

AWS では基本的に 1 vCPU = 物理コア1本の HyperThread 1本 に相当する。つまり c6i.4xlarge（16 vCPU）は物理8コア × 2 HT の構成であり、物理コア 16 本分の演算能力があるわけではない。

環境	vCPU / 論理コア	対応する物理コア（目安）	備考
AWS EC2（c6i 系）	1 vCPU	0.5 物理コア（HT 有効）	Intel Xeon Ice Lake
AWS EC2（c6g 系）	1 vCPU	1.0 物理コア	Graviton3（ARM、HT なし）
GCP（C2 系）	1 vCPU	0.5 物理コア（HT 有効）	Intel Cascade Lake
Azure（Fsv2 系）	1 vCPU	0.5 物理コア（HT 有効）	Intel Skylake
物理（Xeon, HT 有効）	1 論理コア	0.5 物理コア	lscpu で確認
物理（Xeon, HT 無効）	1 論理コア	1.0 物理コア	BIOS 設定で無効化

物理コア交換時の計算例

物理サーバーの CPU 世代アップグレードでは、IPC（クロックあたりの命令数）の向上も加味できる。

■ 世代アップグレード後の等価コア数

等価コア数 = 旧コア数 × (旧クロック × 旧IPC) ÷ (新クロック × 新IPC)

例：Xeon E5-2680 v4（14コア 2.4GHz）→ Xeon Gold 6338（32コア 2.0GHz）へ換装。IPC は Skylake → Ice Lake で約 15% 向上（係数 1.15）
→ 必要旧コア数 28 を新CPUで賄う場合：28 × (2.4 × 1.0) ÷ (2.0 × 1.15) ≈ 29.2 vCPU → 30コア相当で余裕

✅ ARM（Graviton / Ampere）は vCPU = 物理コアで効率的

AWS Graviton3 や GCP Tau T2A（Ampere Altra）は HyperThreading を使わないため、1 vCPU = 1 物理コアです。同じ vCPU 数でも CPU バウンドなワークロードでは Intel / AMD より高いパフォーマンスが出ることが多く、スケールアップの代替として検討する価値があります。

安全係数と余裕設計

試算値はあくまで理論値であり、実運用では以下の要因で誤差が生じる。これらを吸収するための安全係数（余裕率）を必ず加算する。

誤差要因	影響	対処
計測時のサンプリング誤差	P95 でも真のピークを捉えていない可能性	×1.1〜1.2 のバッファ
バースト（突発的スパイク）	キャンペーンや障害時に通常の2〜3倍の負荷	×1.3〜1.5 のバッファ
OS・ミドルウェアのオーバーヘッド	カーネル処理・監視エージェントが5〜15%消費	×1.1〜1.15
将来の機能追加	アプリ改修で処理量が増加	6〜12ヶ月分の成長率を見込む
仮想化オーバーヘッド	ハイパーバイザーのノイジーネイバー	×1.05〜1.15（クラウドのみ）

■ 安全係数込みの最終必要コア数

最終コア数 = 試算コア数 × 安全係数（一般的に 1.3〜1.5）

上記の例（16コア試算）の場合：16 × 1.3 = 20.8 → 22〜24 vCPU 以上のインスタンスを選択

試算シートサンプル

以下の表を埋めることで、スケールアップの判断に必要な数値が揃う。

項目	値（例）	備考
現在のコア数	16 vCPU	lscpu / マネジメントコンソールで確認
ピーク CPU 使用率（P95）	82 %	sar / CloudWatch で計測
目標上限使用率	65 %	サーバー種による（Web: 70, DB: 55）
【使用率ベース試算値】	16 × 82 ÷ 65 ≈ 20.2	切り上げ：21
目標 RPS（将来）	3,000 req/s	トラフィック予測から
CPU 処理時間 / req	4 ms = 0.004 s	perf stat / APM で計測
【RPS 逆算値】	3000 × 0.004 ÷ 0.65 ≈ 18.5	切り上げ：20
採用する試算値（大きい方）	21	—
安全係数	× 1.3	バースト・将来拡張込み
最終必要コア数	21 × 1.3 ≈ 28	→ 32 vCPU インスタンスを選択

✅ 2つの試算値のうち大きい方を採用する

使用率ベースと RPS 逆算の両方を計算し、大きい方を基準にするのが安全です。両者が大きく乖離している場合は、計測条件に問題がある可能性があるため、再計測を検討してください。

まとめ

試算アプローチ	使いどころ	キーとなる数値
使用率ベース	既存サーバーあり・現状の延長線上	現コア数・P95 使用率・目標上限使用率
RPS 逆算	新規構築・大幅な負荷増加時	目標 RPS・CPU 処理時間/req・目標使用率
世代アップグレード換算	物理 CPU 交換・インスタンスファミリー変更	旧クロック・新クロック・IPC 比率

試算結果に安全係数（1.3〜1.5）を掛けた値を目安にインスタンス／CPU を選定する。次のステップとして、各サーバー種ごとのスケールアップ・ダウン判断指標を参照してほしい。