中級ではIaaS/PaaS/SaaSと責任共有を見ました。上級では、可用性設計・自動化・運用の思想へ。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
可用性をどう設計するか
「落ちない」ではなく「落ちても続く」を設計します。
- SLA／SLO／SLI — 約束（SLA）、目標（SLO）、実測（SLI）。エラーバジェットで開発と安定のバランスを取る
- リージョン／AZ／エッジ — 地理的な階層。マルチAZで局所障害に、マルチリージョンで広域障害に備える
- フェイルオーバー — ヘルスチェック＋自動切替。データの複製と整合の設計が肝
スケールと自動化
- 水平スケール前提 — ステートレス化し、台数で捌く
- オートスケール — メトリクス（CPU・キュー長）や予測でインスタンスを増減
- IaC — インフラを宣言的コードで管理（冪等・再現可能・レビュー可能）
- イミュータブルインフラ — 変更せず作り直して置き換える
- 段階リリース — Blue-Green／カナリアで、リスクを小さく出す
運用の勘所
- 責任共有の実像 — 基盤は事業者、設定・データ・権限は利用者。事故の多くは利用者側の設定
- 可観測性 — ログ・メトリクス・トレース＋アラート。SLO違反を早く検知
- コスト最適化 — 適切なサイズ、スポット／リザーブド、使わない資源の停止、データ転送費
- マルチクラウド／ハイブリッド — ロックイン回避と可用性の一方で、運用は複雑化
⚠️ クラウドならではの障害
- リージョン／AZ障害の波及 — 依存が集中していると広範囲に影響
- コントロールプレーン障害 — 管理系が止まると、スケールや復旧操作ができない
- コスト暴走 — オートスケールや転送費、消し忘れ
- 設定ドリフト — 手作業の変更が積もり、再現できなくなる（IaCで防ぐ）
- カオスエンジニアリング — わざと壊して、回復力を平時に検証する考え方
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 高可用性のために、1つのリージョン内で電源・ネットワークが独立した区画に分けて配置するのは？
問2. サーバを「変更せず、新しいものに丸ごと置き換える」運用思想は？
問3. SLA・SLO・SLIの関係として正しいのは？
問4. 台数を増やして負荷をさばく「水平スケール」を成り立たせる前提はどれ？
問5. クラウドの「コントロールプレーン障害」が特に厄介なのはなぜ？
問6. 「カオスエンジニアリング」の説明として正しいのは？
問7. IaCで「同じコードを何度適用しても、最終的な状態が同じに保たれる」性質を何と呼ぶ？
問8. 新バージョンをまず少数のサーバ・一部の利用者にだけ出し、問題なければ広げていく段階リリース手法を、カタカナで何という？