メインコンテンツへスキップ
このドキュメントでは、EKB AWS/EKS インフラストラクチャの災害復旧 (DR) 戦略、目標復旧時間 (RTO)、および目標復旧時点 (RPO) について説明します。組み込みの HA 機能、アクティブなバックアップ システム、リカバリ手順、既知のギャップについて説明します。
デプロイ手順については、Terragrunt デプロイ ガイド を参照してください。

アーキテクチャと高可用性の概要

インフラストラクチャコンポーネント

現在の HA 機能


RTO / RPO ターゲット


バックアップ システム

1. Terraform / Terragrunt 状態 — S3

バックアップの内容: すべてのインフラストラクチャの状態 (EKS、ネットワーキング、IAM、Helm リリース)。 実装:
  • 環境ごとの S3 バケット: ekb-terraform-state-<env-name> (terragrunt/environments/<env-name>/state/ 経由でブートストラップ)
  • バージョニングが有効 — 以前の状態のバージョンを復元できます
  • サーバー側暗号化 (AES-256)
  • 状態ロック用の DynamoDB テーブル
リカバリ: S3 内の以前の状態バージョンにロールバックしてから、terragrunt apply を再実行します。 RPO: terragrunt apply コミットごと — 継続的。

2. EBS 永続ボリューム — AWS Data Lifecycle Manager

バックアップの内容: ポッドに接続された EBS ボリューム (Automator PostgreSQL、Supabase MinIO、ステートフル ワークロード)。 実装: 環境タグを対象とした AWS Data Lifecycle Manager (DLM) ポリシー。
回復:
RPO: 最大 24 時間 (毎日のスナップショット)。 DLM スケジュールの頻度を増やすことで削減します。

3. CloudNativePG (HA Supabase DB) — Barman クラウド バックアップ

適用対象: ENABLE_CNPG=true および ENABLE_HA_SUPABASE_DB=true を含む環境。 バックアップの内容: CloudNativePG Postgres クラスター (ha-supabase-db)。これには、S3 または MinIO への継続的な WAL (先行書き込みログ) ストリーミングと、CNPG ScheduledBackup CRD を介したスケジュールされた完全なベース バックアップが含まれます。 実装 (values/ha-supabase-db.yaml で構成):
バックアップ ステータスを確認:
ポイントインタイムリカバリ (PITR):
RPO: WAL 対応クラスターではほぼゼロ (WAL アップロード間隔によって制限される数秒の遅れ)。

4. ElastiCache Redis — マルチ AZ レプリケーション

適用対象: ENABLE_AWS_SERVICES=true のある環境。 Redis はプライマリ データ ストアではなく、一時的なキャッシュ データとセッション データを保持します。 DR では、バックアップ/リストアではなく、高速フェイルオーバーに焦点を当てています。 実装:
  • 自動フェイルオーバーによるマルチ AZ の有効化
  • 保存時および転送中の暗号化
  • プライマリ ノードの障害により、レプリカが自動的に昇格されます (< 1 分)
RPO: Redis データは設計上一時的です。フェイルオーバー後のキャッシュミスが予想されます。アプリケーションはデータベースから再入力されます。

5. Amazon MQ (RabbitMQ) — メッセージキュー

適用対象: ENABLE_AWS_SERVICES=true のある環境。 実装:
  • 単一インスタンス (デフォルト) またはアクティブ/スタンバイ展開
  • ブローカーの再起動中に、送信中のメッセージが失われる可能性があります。消費者が冪等になるように設計してください
  • 管理 UI はポート 15671 (SSL) で利用可能
RPO: 単一インスタンス — 障害時に送信中のメッセージが失われる可能性があります。このリスクを軽減するには、アクティブ/スタンバイ展開モードを使用してください。

自動回復メカニズム

Karpenter — ノードのプロビジョニングとリカバリ

  • 統合: WhenEmptyOrUnderutilized — アイドル状態のノードは自動的に終了します
  • スポット割り込み処理: SQS 割り込みイベントをリッスンします。終了前にスポットノードをドレインして置き換えます
  • ノード ドリフト: 古い AMI または構成を使用しているノードは、enable_drift = true の場合に自動的に置き換えられます
  • 回復時間: 新しいノードが 0 ~ 10 分でプロビジョニングされます

KEDA — ポッドの自動スケーリング

  • 最小レプリカ数: すべてのサービス (Web、API、Celery、Automator) で 2 — 単一障害点を防止します
  • CPU しきい値: 60 ~ 70% でスケールアウトがトリガーされます
  • メモリしきい値: 80% でスケールアウトがトリガーされます
  • スケールダウン安定化: 30 秒 — バタつきを回避します
  • 回復時間: 失敗したポッドは 0 ~ 2 分以内に再スケジュールされます

Kubernetes ポッドのアンチアフィニティ

すべてのステートレス サービスは、kubernetes.io/hostnamepreferredDuringSchedulingIgnoredDuringExecution アンチアフィニティを使用して、ノードと AZ にポッドを分散します。

回復手順

シナリオ 1: AZ の障害

予想される動作: Karpenter は残りの AZ に交換ノードをプロビジョニングします。 KEDA はポッドを再スケジュールします。 ALB は、異常なターゲットへのルーティングを停止します。 検証:
通常の状況では、手動介入は不要です。

シナリオ 2: Postgres プライマリ ノードの障害 (CloudNativePG)

CloudNativePG は、レプリカを自動的にプライマリに昇格させます。
アプリケーションは PgBouncer 経由で再接続します。接続文字列を変更する必要はありません。

シナリオ 3: スナップショットから EBS ボリュームを復元する


シナリオ 4: インフラストラクチャの完全な再構築

致命的な障害が発生した後、またはリージョンを再構築するときに使用されます。
推定 RTO: 完全なクラスターの場合は 30 ~ 60 分。 EBS/CNPG データを復元する必要がある場合は 60 ~ 120 分。

シナリオ 5: Terragrunt 状態のロールバック


可観測性とアラート (SigNoz)

ENABLE_SIGNOZ=true の場合、SigNoz は monitoring 名前空間にデプロイされ、以下を提供します。
  • すべての EKB サービスの分散トレース
  • k8s-infra DaemonSet エージェント経由のクラスター メトリック (CPU、メモリ、ポッド ステータス)
  • すべてのポッドからのログの集計
  • アラート — SigNoz でアラート ルールを設定して、ポッドのクラッシュ ループ、高いエラー率、またはノードの負荷を通知します
DR の目的では、SigNoz ダッシュボードは、インシデント後の診断と回復の確認のための主要なツールです。 SigNoz データ自体は EBS PV に保存され、EBS スナップショット ポリシーの対象となります。

ギャップと推奨事項