Kubernetesクラスタ設計・運用実践ガイド

第6章：ストレージ設計と運用

ストレージは「永続化」「性能」「復旧」を同時に満たす必要があり、設計判断の影響が大きい領域です。
本章では、CSI/StorageClass を中心に、運用設計（バックアップ、障害対応）まで含めて論点を整理します。

学習目標

  • CSI/StorageClass の役割と、設計上の論点を説明できる
  • バックアップ/リストアと RTO/RPO を接続して設計できる
  • 典型障害（Attach 失敗、I/O 劣化）を切り分ける観点を整理できる

扱う範囲 / 扱わない範囲

扱う範囲

  • CSI/StorageClass の運用観点（互換性、拡張、更新）
  • スナップショット/バックアップ（概念と運用）
  • Stateful ワークロードの保護（設計論点）

扱わない範囲

  • 特定ストレージ製品の詳細設定
  • データベース固有のバックアップ戦略の網羅

定義（この章の用語）

  • CSI: Kubernetes からストレージを操作するためのインターフェース（Provision/Attach/Mount 等）
  • StorageClass: ストレージの種類/特性（性能、暗号化、AZ、Binding モード等）を表すクラス
  • Stateful ワークロード: データを保持し、復旧時に「状態」を戻す必要があるワークロード

背景（なぜ重要か）

  • ストレージは「復旧」の実効性に直結します。設計が曖昧なまま運用すると、障害時に復旧できません。
  • クラスタのアップグレードやノード入れ替えで、CSI/ノード/Control Plane の互換性問題が顕在化しやすい領域です。

手順/例：設計・運用の進め方（型）

  1. データ要件（RTO/RPO、保持、暗号化、規制）を整理する
  2. 用途別に StorageClass を定義する（標準クラス + 例外クラス。例外は期限付きで管理）
  3. バックアップ方式を決める（ボリュームスナップショット、アプリ/DB レベルのバックアップ等）
  4. 復旧手順を Runbook 化し、演習して所要時間を記録する
  5. 典型障害（Provision/Attach/Mount、I/O 劣化）を Playbook 化し、監視と接続する

失敗例（例）:

  • 「永続化はアプリ側で何とかする」と合意がなく、バックアップ/復旧の責任が空白になる
  • 一時的なクォータ緩和やクラス追加が放置され、後から運用負債になる

代替案（例）:

  • 要件が厳しく運用負荷が大きい場合、状態をクラスタ外（マネージド DB 等）へ寄せ、Kubernetes 側は stateless を基本にします。

注意点（運用）

  • Multi-Attach（RWO の同時アタッチ等）は典型障害です。アクセスモードと配置（ノード/ゾーン）を設計で吸収します。
  • スナップショット/バックアップの可否は環境に依存します。可用性と整合性の前提（要確認）を明記して運用してください。

実務チェック観点（最低5項目）

  • StorageClass の標準（用途別クラス、暗号化、性能）と利用ガイドがある
  • バックアップ/リストアの責任範囲と手順が明文化され、演習されている
  • ストレージ関連の監視（I/O レイテンシ、エラー、容量）とアラートがある
  • 典型障害（Attach/Provision 失敗、I/O 劣化）の Playbook がある
  • アップグレード時（CSI/ノード/Control Plane）の互換性確認手順がある

よくある落とし穴

  • 永続化の責任範囲（アプリ/基盤）が曖昧なまま運用に入る
  • バックアップが存在しても、復旧演習がなく実効性が担保できない

まとめ / 次に読む

Edit this page on GitHub