🎓 レベル:標準 | 重要度:A(必須)
📎 前提:クラウドとは・IaaS/PaaS/SaaS | 関連:主要サービスの地図(計算・保存・ネットワーク・DB)・スケーリングと自己修復
要点(BLUF)
- クラウドは使った分だけ課金。だからコストは「何を・どれだけの時間・どれだけの量動かしたか」で決まる。消し忘れと過剰スペックが事故の二大要因。
- スケーリングは2方向。スケールアップ(垂直)=1台を強くする、スケールアウト(水平)=台数を増やす。クラウドが得意なのは後者。
- オートスケールは需要に応じて台数を自動で増減し、「ピークに合わせて常時確保」する無駄を消す。これが従量課金の真価。
概念 ── コストは「量 × 時間」で動く
オンプレの費用は「買った瞬間に確定」ですが、クラウドは動かしている間ずっとメーターが回ります。主な課金軸は次の通り(具体単価は要最新確認)。
| 資源 | 課金の軸 | 注意点 |
|---|---|---|
| 計算(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 で暴走課金の天井を必ず設けます。
なぜ水平+オートスケールなのか
- 無駄をなくすため:従量課金の利点は「使わないとき払わない」。常時ピーク確保はオンプレと同じ無駄を持ち込むことになる。
- 壊れても続けるため:水平に分散していれば1台の故障が全停止にならない。スケーリングと可用性は同じ設計から出てくる。
- でも歯止めは要る:自動で増えるということは、バグや攻撃で自動で課金が膨らむということ。上限と予算アラートで守る。
⚠️ よくある誤解・落とし穴
- 「止めれば必ず無料」→ 種別による。停止中も保存・予約分が課金されることがある。**消す(delete)**まで安心しない。
- 「egress は気にしなくていい」→ 大量配信・リージョン間コピー・ログ転送で外向き通信費が主要因になることがある。CDN・同一リージョン集約で抑える。
- 「オートスケールに上限を付けない」→ 障害や攻撃で青天井に増殖し、高額請求に。
maxと予算アラートは必須。 - 「とにかく大きいインスタンス」→ 過剰スペックは常時無駄。小さく始めてメトリクスで右サイズに。
- 「コストはあとで見る」→ タグ付け・予算アラート・コスト可視化を最初から入れる。FinOps の基本(要最新確認の各社ツール)。
対応ラボ
なし(概念トピック)。Kubernetes での実際の水平オートスケールは スケーリングと自己修復 で扱います。
関連
- 何を動かすか(計算の選択肢)は 主要サービスの地図(計算・保存・ネットワーク・DB)
- 従量課金を生む借り方の本質は クラウドとは・IaaS/PaaS/SaaS
- 自動の水平スケールと自己修復は スケーリングと自己修復
- キャパシティ設計の信頼性面は キャパシティと信頼性設計