理Kotowary

クラウド — サーバを借りて、使った分だけ払う

大人こども
初級中級上級

概要 — まず全体をつかむ

中級ではIaaS/PaaS/SaaSと責任共有を見ました。上級では、可用性設計・自動化・運用の思想へ。

詳細 — 1段階ずつ追う

可用性をどう設計するか

「落ちない」ではなく「落ちても続く」を設計します。

  • SLA／SLO／SLI — 約束（SLA）、目標（SLO）、実測（SLI）。エラーバジェットで開発と安定のバランスを取る
  • リージョン／AZ／エッジ — 地理的な階層。マルチAZで局所障害に、マルチリージョンで広域障害に備える
  • フェイルオーバー — ヘルスチェック＋自動切替。データの複製と整合の設計が肝
やさしく言うと（中級）

クラウドは「どこまで任せるか」で層が分かれます。

  • IaaS — 仮想サーバ・ストレージ・ネットワークなど基盤を借りる（OS以上は自分で）
  • PaaS — 実行環境を借りる（OS・ミドルウェアはお任せ、アプリに集中）
  • SaaS — 完成したアプリを使う（メール・表計算など）
  • FaaS／サーバーレス — 関数だけ預け、実行時だけ課金・イベントで起動（サーバの存在を意識しない、任せる範囲のさらに上の層）

これらの土台にある仮想化には、OSごと積むVMと、カーネルを共有するコンテナがあります。

アニメーション『VMとコンテナの違い』を開く
仮想マシン（VM）OSをまるごと積む＝重いコンテナカーネルを共有＝軽い仮想マシン1アプリゲストOS（フルOS）仮想マシン2アプリゲストOS（フルOS）仮想マシン3アプリゲストOS（フルOS）ハイパーバイザハードウェアコンテナ1アプリ＋必要な部品だけコンテナ2アプリ＋必要な部品だけコンテナ3アプリ＋必要な部品だけコンテナエンジンホストOSカーネルを全コンテナで共有ハードウェアVMはゲストOSごと積むので重い／コンテナはホストのカーネルを共有しOSを積まないので軽い

登場人物メモ:

  • ※1 マネージドサービス — DB・キューなどの運用を事業者に任せる形
  • ※2 リージョン／AZ — 地域と、その中の独立した拠点。分散配置に使う

スケールと自動化

  1. 水平スケール前提 — ステートレス化し、台数で捌く
  2. オートスケール — メトリクス（CPU・キュー長）や予測でインスタンスを増減
  3. IaC — インフラを宣言的コードで管理（冪等・再現可能・レビュー可能）
  4. イミュータブルインフラ — 変更せず作り直して置き換える
  5. 段階リリース — Blue-Green／カナリアで、リスクを小さく出す
やさしく言うと（中級）
  1. 必要なサービスを選ぶ（層＝IaaS/PaaS/SaaS）
  2. 設定して即利用（プロビジョニング）
  3. 負荷に応じてオートスケールで増減
  4. 使った分だけ課金され、要らなければ破棄

運用の勘所

  • 責任共有の実像 — 基盤は事業者、設定・データ・権限は利用者。事故の多くは利用者側の設定
  • 可観測性 — ログ・メトリクス・トレース＋アラート。SLO違反を早く検知
  • コスト最適化 — 適切なサイズ、スポット／リザーブド、使わない資源の停止、データ転送費
  • マルチクラウド／ハイブリッド — ロックイン回避と可用性の一方で、運用は複雑化
やさしく言うと（中級）
  • 責任共有モデル — 基盤は事業者、設定・データ・権限は利用者の責任
  • スケール — 水平スケール前提。マルチAZで可用性を上げる
  • コスト最適化 — 使わない資源を止める、適切なサイズ、予約割引など
  • ロックイン対策 — 事業者独自機能への依存度を意識（ハイブリッド／マルチクラウド）

責任共有の境界は層（IaaS／PaaS／SaaS）で上下しますが、データとアクセス権限は常に利用者の責任です。

アニメーション『クラウドの責任共有モデル』を開く
責任共有モデル — どこまでが誰の責任か利用者の責任事業者（クラウド）の責任データアクセス権限（IAM）アプリOS設定・ミドルウェア仮想化基盤物理（サーバ・NW・建物）↑ アプリ側　／　土台 ↓IaaS基盤を借りる利用者の責任利用者の責任利用者の責任利用者の責任事業者の責任事業者の責任PaaS実行環境を借りる利用者の責任利用者の責任利用者の責任事業者の責任事業者の責任事業者の責任SaaS完成品を使う利用者の責任利用者の責任事業者の責任事業者の責任事業者の責任事業者の責任任せる範囲が広い層ほど、責任の境界は上へ動くデータとアクセス権限は常に利用者の責任 — 公開設定・権限ミスの漏洩は利用者側で起きる

⚠️ クラウドならではの障害

  • リージョン／AZ障害の波及 — 依存が集中していると広範囲に影響
  • コントロールプレーン障害 — 管理系が止まると、スケールや復旧操作ができない
  • コスト暴走 — オートスケールや転送費、消し忘れ
  • 設定ドリフト — 手作業の変更が積もり、再現できなくなる（IaCで防ぐ）
  • カオスエンジニアリング — わざと壊して、回復力を平時に検証する考え方
やさしく言うと（中級）
  • コスト暴走 — オートスケールや消し忘れで請求が急増
  • 設定ミスによる漏洩 — 公開設定・権限の誤り（責任共有の利用者側）
  • ベンダーロックイン — 独自サービスに深く依存し乗り換え困難
  • 障害の影響範囲 — リージョン障害が広範囲に及ぶことも（分散で緩和）

関連する知識

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. 高可用性のために、1つのリージョン内で電源・ネットワークが独立した区画に分けて配置するのは？

問2. サーバを「変更せず、新しいものに丸ごと置き換える」運用思想は？

問3. SLA・SLO・SLIの関係として正しいのは？

問4. 台数を増やして負荷をさばく「水平スケール」を成り立たせる前提はどれ？

問5. クラウドの「コントロールプレーン障害」が特に厄介なのはなぜ？

問6. 「カオスエンジニアリング」の説明として正しいのは？

問7. IaCで「同じコードを何度適用しても、最終的な状態が同じに保たれる」性質を何と呼ぶ？

問8. 新バージョンをまず少数のサーバ・一部の利用者にだけ出し、問題なければ広げていく段階リリース手法を、カタカナで何という？