指摘 追加課題 運用保守 Veleroを使ったバックアップとリストア #185
Description
バックアップの必要性
タイトル：現状の課題 (K8sマニフェスト構成管理の必要性)
※方向性と「：人的ミスから迅速に復旧できない」の部分は不要かも
課題①：人的ミスから迅速に復旧できない
- 問題点: 人的ミスによるリソース削除や設定変更が発生した際に、迅速に元の状態へ戻せない。
- 起きること: 手作業での復旧が必要となり時間がかかる、もしくは完全に元に戻せないリスクがある。
- 対応の方向性: Kubernetesリソースおよびデータをバックアップし、誤操作時にも迅速にリストアできる仕組みを導入する。
課題②：ハードウェア/クラスタ障害時のデータ保護と継続性が不十分
- 問題点: ハードウェア障害やクラスタ障害が発生した場合を想定した、データ保護および継続性が不十分
- 起きること: 障害発生時にデータが失われ、サービス停止が長期化することで、業務やユーザーへの影響が大きくなる。
- 対応の方向性: クラスタ障害時にもデータを安全に復旧できるよう、Persistent Volume を含めたバックアップと災害復旧手順を整備する。
課題③：本番データを安全に他環境へ複製できない
- 問題点: 本番環境のデータを開発・ステージング環境へ安全に複製するための標準的な仕組みが用意されていない。
- 起きること: 検証やテストに本番相当のデータを使用できず、環境差異による不具合の見逃しや検証品質の低下につながる。
- 対応の方向性: バックアップデータを活用し、本番データを安全に開発・ステージング環境へリストアできる運用を確立する。
課題④：クラスタ移行・マルチクラスタでのデータ同期が困難
- 問題点: クラスタ移行やマルチクラスタ構成を前提としたデータ同期・移行手段が明確に整理されていない。
- 起きること: クラスタ移行時の作業負荷が高くなり、データ不整合や移行ミスが発生するリスクが高まる。
- 対応の方向性: クラスタ間でリソースとデータを一貫して移行・同期できるバックアップ/リストア手段を導入する。
解決策
Velero
Kubernetes ネイティブなバックアップツールであり、
Kubernetes リソースと Persistent Volume を統合的に管理できる。
災害復旧やクラスタ移行を主目的とした機能を備えており、本プラクティスではこれを採用する。
etcd スナップショット
Kubernetes コントロールプレーン（etcd）をバックアップし、
クラスタ全体の状態を保存する方式。
ただし、EKS ではユーザー側での取得・管理ができない。
アプリケーション固有ツール
データベースダンプなど、アプリケーションごとに特化したバックアップ手法。
細かな制御が可能な一方で、Kubernetes 全体を横断した統合管理には向かない。
本プラクティスでは
Kubernetes 環境におけるリソースとデータを包括的にバックアップ／リストアできる仕組みとして、
Velero を採用する。
Velero によるバックアップとリストア
リソースバックアップ
Deployment、Service、ConfigMap などの Kubernetes リソースを YAML 定義としてバックアップする。
ボリュームバックアップ
Persistent Volume のデータを、CSI スナップショットまたは Restic を用いて保護する。
選択的バックアップ
名前空間、ラベル、リソース種別を指定することで、必要な対象のみを柔軟にバックアップできる。
スケジュールバックアップ
cron 形式による定期実行を設定し、バックアップを自動化する。