Mímisbrunnr知恵の泉

← MLOps 一覧

🎓 レベル：標準　|　重要度：B（推奨）

📎 前提：レイテンシとスループットのトレードオフ　|　関連：クラウド・インフラ／SRE・DevOps 全体目次（クラウド）

要点（BLUF）

1. CPU と GPU の使い分け

観点CPUGPU
得意小バッチ・分岐の多い処理・低トラフィック大バッチの行列演算・深層モデル
コスト安い（遊んでも痛くない）高い（遊ばせると割高）
向くモデル勾配ブースティング・線形・小NN大規模NN・LLM（LLMの推論サービングと最適化基盤）

GPU は「まとめて大量に計算する」ほど元が取れます。小さなバッチをぽつぽつ処理するだけなら、高価な GPU は稼働率が低く割高になります。バッチング（レイテンシとスループットのトレードオフ）で GPU を埋められるかが分岐点です。

2. 垂直・水平・オートスケール

flowchart TB
  V["垂直スケール：1台を強く（CPU増/GPU化）"] --> L1["上限あり・単一障害点"]
  H["水平スケール：台数を増やす"] --> L2["上限が高い・冗長性あり"]
  A["オートスケール：負荷に応じて台数を増減"] --> L3["コスト最適・ただしスケール遅延"]

3. 動く最小例：負荷から必要インスタンス数を見積もる

「ピーク QPS を、目標稼働率を超えない範囲で捌くには何台要るか」を見積もる最小キャパシティ計算です。

import math

def required_instances(peak_qps, per_instance_qps, target_utilization=0.7,
                       min_instances=2):
    """ピーク負荷を target_utilization 以下で捌くのに必要な台数。
    余裕（ヘッドルーム）と最小冗長台数を考慮する。"""
    raw = peak_qps / (per_instance_qps * target_utilization)
    n = max(min_instances, math.ceil(raw))
    actual_util = peak_qps / (n * per_instance_qps)
    return n, actual_util

# 1台が安全に捌けるのは 200 QPS、ピークは 1500 QPS
for peak in [300, 1500, 5000]:
    n, util = required_instances(peak, per_instance_qps=200)
    print(f"ピーク {peak:>4} QPS -> 必要 {n:>2} 台 "
          f"（稼働率 {util*100:.0f}%・目標70%以下）")

出力：

ピーク  300 QPS -> 必要  3 台 （稼働率 50%・目標70%以下）
ピーク 1500 QPS -> 必要 11 台 （稼働率 68%・目標70%以下）
ピーク 5000 QPS -> 必要 36 台 （稼働率 69%・目標70%以下）

出力の意味：1台が安全に 200 QPS 捌けるとき、ピーク 1500 QPS には 11 台必要です（稼働率68%で目標70%以下に収まる）。ポイントは稼働率に余裕（ヘッドルーム）を持たせること——100%稼働で設計すると、わずかな急増やスケール遅延で破綻します。目標稼働率70%は「急増・コールドスタートの吸収代」です。オートスケールはこの台数を負荷に応じて自動調整しますが、**コールドスタート（新インスタンスが温まる時間）**を見込むため、しきい値は余裕を持って早めに発火させます。

4. 運用の勘所

なぜそうするのか

スケーリングを「水平＋オートスケール＋ヘッドルーム」で設計するのは、負荷は変動し、ハードは即座には増えないからです。垂直スケールは上限と単一障害点を抱え、急増に弱い。水平＋オートスケールなら冗長性とコスト最適性を両立できますが、新インスタンスが温まるまでの遅延（コールドスタート）があるため、100%稼働を狙うと急増を吸収できません。だから稼働率に余裕を残し、しきい値を早めに発火させる——「変動とスケール遅延に耐える設計」がキャパシティ計画の本質です。

⚠️ よくある落とし穴

対応 lab

関連ノート