Mímisbrunnr知恵の泉

← クラウドインフラ 一覧

🎓 レベル:標準 | 重要度:A(必須)

📎 前提:クラウドとは・IaaS/PaaS/SaaS | 関連:主要サービスの地図(計算・保存・ネットワーク・DB)スケーリングと自己修復

要点(BLUF)

概念 ── コストは「量 × 時間」で動く

オンプレの費用は「買った瞬間に確定」ですが、クラウドは動かしている間ずっとメーターが回ります。主な課金軸は次の通り(具体単価は要最新確認)。

資源課金の軸注意点
計算(VM/コンテナ)起動時間 × スペック止め忘れ・止めても課金される種別あり
保存(ストレージ)保存量 × 期間消さない限り増え続ける
ネットワーク外向き通信量(egress)入りは安い/無料、出が高いことが多い
マネージドDBインスタンス時間+IO+保存止めても課金が続く種別あり

特に見落としがちなのが egress(外向き通信)。クラウドからインターネットやリージョン外へ出るデータには料金がかかり、設計次第で大きく膨らみます。

仕組み ── 垂直 vs 水平スケーリング

負荷が増えたときの伸ばし方は2つ。

flowchart LR
    subgraph up["スケールアップ(垂直)"]
      u1["小さいVM"] --> u2["大きいVM(CPU・メモリ増強)"]
    end
    subgraph out["スケールアウト(水平)"]
      o1["VM 1台"] --> o2["VM 3台(ロードバランサで分散)"]
    end
スケールアップ(垂直)スケールアウト(水平)
やり方1台を強く台数を増やす
上限ハードの最大まで実質ほぼ無限
停止載せ替えで止まりがち無停止で増減しやすい
向くDBなど分割しにくいものステートレスなWeb/API
耐障害性1台が落ちると全滅1台落ちても継続

クラウドの思想は水平スケール優先。そのためにアプリは「どの1台が落ちても良い」ステートレス(状態をDBや外部ストレージに逃がす)に設計します。この発想がコンテナ(コンテナとは(名前空間・cgroups))と Kubernetes のオートスケール(スケーリングと自己修復)につながります。

仕組み ── オートスケール

需要は時間で波打ちます(昼ピーク・夜閑散)。ピークに合わせて常時台数を確保すると、谷の時間は無駄。オートスケールは指標(CPU使用率・リクエスト数など)を見て台数を自動増減します。

flowchart LR
    metric["メトリクス(CPU使用率など)"] --> rule["ルール判定(しきい値超なら増やす)"]
    rule --> scale["台数を増減"]
    scale --> metric
# 疑似オートスケール設定:CPU平均が60%を超えたら増やし、下回れば減らす
autoscaling:
  min_replicas: 2          # 最低2台(可用性のため)
  max_replicas: 10         # 上限(暴走課金の歯止め)
  target_cpu_utilization: 60

min で可用性の床を、max暴走課金の天井を必ず設けます。

なぜ水平+オートスケールなのか

⚠️ よくある誤解・落とし穴

対応ラボ

なし(概念トピック)。Kubernetes での実際の水平オートスケールは スケーリングと自己修復 で扱います。

関連

第1章 クラウドの基礎 目次