はじめに
先日、クラウドリフトの案件に携わりました。提示された前提は「オンプレのハイパーバイザー用サーバーの CPU スペックを、そのままクラウド VM に当てはめたい」。
でも、ちょっと待ってください。クラウドでは同一のチップ/クロック/構成を指名できないうえ、オンプレ機は複数 VM を束ねる前提で高クロック/多コアになりがちです。結果、同じ数値を当て込むほどオーバースペックになり、費用対効果が悪化します。
本稿は、この案件を起点に「なぜズレるのか」「どう適正化するか」を実務フレームで再整理します。
1. 背景と論点（案件の出発点）
- 前提資料には「オンプレのハイパーバイザー用サーバーの CPU/メモリ値」が記載。
- 発注側は「クラウドでも“同等クロック/同等コア数”を調達したい」と要望。
- クラウドはインスタンス世代が流動し、同一 GHz でも IPC/キャッシュ/ターボ制御が異なるため体感性能は一致しない。
- ハイパーバイザー用途の太いサーバー ≠ 単一 VM に必要なスペックという構造差が存在。
2. どこでズレる？（構造差分の可視化）
| 観点 | オンプレ （ハイパーバイザー用） |
クラウド （IaaS/VM） |
サイジング観点 |
|---|---|---|---|
| 役割 | 多数 VM を集約/ 冗長吸収 |
用途ごとに小刻み配備 |
太め前提 vs 細切れ前提 |
| vCPU 定義 | 柔軟でオーバー コミット可能 |
多くは vCPU=HT1本 | 「8 vCPU」の 意味が違う |
| CPU クロック | 高クロックを持続 させやすい |
ターボ/電力制御は プロバイダ依存 |
同 GHz でも体感差 |
| I/O | ローカル NVMe/SAN 多い |
ネット越しブロック/ ローカル一時 |
I/O 設計が鍵 |
| スケール | 垂直中心 |
水平前提 （オートスケール） |
最初から大きく 買わない |
3. 意思決定フレーム
- 仮説：オンプレ 8CPU/32GB の VM は、クラウドでは 4vCPU/16GB で業務時間の 95% 程度を満たせる。
- 根拠：直近 30～90 日の p50/p95 CPU、ランキュー、メモリ常駐、IOPS/pps を収集すると、多くの業務系で平均 CPU 使用率は 20% 未満。
- 再検証（POC）：合成/リプレイ負荷で p95 レイテンシ×1.2 を閾値に段階増。
- 示唆：数値移植ではなく実効値ベースで小さく始め、観測しながら縮尺を合わせる。
4. 案件に適用したサイジング手順
-
対象選定：代表 VM（平常/ピーク/バッチ）を特定。
-
計測（30～90 日）：
CPU 利用率/ランキュー/steal、メモリ常駐/ページング、IOPS/待ち時間、pps/遅延。 -
初期サイズ算出：
C_initial = ceil( (U_p95 / U_target) * C_current * k )-
U_target=40% など /k=世代差補正 0.9～1.3 - メモリは 常駐 p95×1.3 を四捨五入。
-
-
小さめで POC：スローテスト/障害注入。
-
本番移行後も週次ライトサイジング：自動提案→承認→反映。
5. 数字合わせをやめる CPU クロックの扱い
5.1 同じ GHz でも同じ速さではない
- 世代差/キャッシュ/命令セット/NUMA/ターボ持続/スケジューリングで単一スレッド/全コア持続の挙動が変わる。
- 結論：GHz 揃えではなく、自アプリの実測（RPS/コア、p95/p99）で判断。
5.2 ピークの扱いを決めてコストを変える
| 方針 | 内容 | メリット | デメリット/ リスク |
向くケース |
|---|---|---|---|---|
| リッチ常設 | 最大値を常時 満たす高クロック /大サイズ固定 |
常に速い/ 運用簡単 |
コスト高/空き リソース発生 |
超低遅延SLO、 リサイズ不可 |
| 95% 設計＋ 一時拡張 |
p95 常設、上振れは 垂直一時アップ/ 水平スケール |
コスト最小/ 柔軟 |
一時遅延/ 再起動要件 |
大半の業務系 |
| ハイブリッド | 小さめ高周波× 複数＋オート スケール |
レイテンシと 費用の折衷 |
設計が複雑 | API/バッチ 混在 |
備考：一部クラウドの垂直一時アップは再起動を伴うため、メンテ時間とスケジュール拡張の併用が実務的です。
6. 初期目安
| 現行実効値 （オンプレ VM） |
クラウド 初期サイズ目安 |
補足 |
|---|---|---|
| CPU p95＜20%、 8 vCPU/32 GB |
2～4 vCPU/16 GB | CPU は段階増、メモリは実効＋30% |
| CPU p95≈50%、 8 vCPU/32 GB |
4～6 vCPU/16～32 GB | I/O 待ちも同時監視 |
| メモリ p95＞24 GB | メモリ最適化へ | CPU は維持 |
| I/O 待ち高 | プロビジョンド IOPS/ ローカル NVMe |
vCPU 増より I/O 設計 |
| 日中ピーク型 | オートスケール/ スケジュール拡縮 |
常時大型を買わない |
7. 移行後の最適化
-
週次ライトサイジング
- CPU p95＜20% が 2 週継続 → 1 段階ダウンサイズ。
- メモリ p95＞80% or ページアウト → メモリ重視へ。
- I/O 待ち高 → ボリューム/キャッシュ再設計。
-
水平スケール：スケジュール/しきい値/予測の 3 型。
-
原価最適化：90 日安定 → 予約/貯蓄、停止可 → スポット併用。
8. リスクとリスク発生時の代替案
| リスク | 具体例 | 回避策/代替案 |
|---|---|---|
| 数値移植で 過大購入 |
ハイパーバイザー用の 値を VM に当て込み |
実測→式→小さめ開始に変更 |
| 単一スレッド 劣化 |
同 GHz だが IPC が 低い世代 |
高周波/専有/ピン留めの検討 |
| I/O ボトル ネック |
EBS/PD 相当で待ち時間増 | IOPS/スループット予約、ローカル NVMe |
| 変更に弱い 運用 |
再起動が痛い | ローリング/カナリア、再起動時間の確保 |
9. なぜで深掘り
-
なぜ オンプレ値を当て込むとオーバースペック化するのか？
→ ハイパーバイザー前提の太い値だから。 -
なぜ 同じ GHz に合わせても体感が違うのか？
→ 世代/IPC/ターボ/スケジューリングの非対称があるから。 -
なぜ その非対称が見落とされるのか？
→ vCPU 定義や I/O 前提を共通言語にしていないから。 -
なぜ 適正サイズに収束しないのか？
→ 実測→検証→リサイズの運用ループがないから。 -
なぜ 運用ループがないのか？
→ p95・SLO・費用ラインが合意されていないから。
原因：構造差を数値化し共有する仕組みが欠落していること。
対策：現行を 30～90 日計測→式で初期化→小さめ開始→週次ライトサイジング→90 日で予約化。
おわりに
案件の学びは明快です。“オンプレの強いサーバーの数字”をクラウド VM に移植しない。GHz ではなく自アプリの実測で語り、p95 常設＋ピーク時拡張を前提に小さく始めて測る。この型に沿えば、性能とコストの両立は十分に実現できます。まずは代表の VM 1 台から、同じ要領で実施してみてください。