デプロイ手順については、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 テーブル
terragrunt apply を再実行します。
RPO: terragrunt apply コミットごと — 継続的。
2. EBS 永続ボリューム — AWS Data Lifecycle Manager
バックアップの内容: ポッドに接続された EBS ボリューム (Automator PostgreSQL、Supabase MinIO、ステートフル ワークロード)。 実装: 環境タグを対象とした AWS Data Lifecycle Manager (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 で構成):
4. ElastiCache Redis — マルチ AZ レプリケーション
適用対象:ENABLE_AWS_SERVICES=true のある環境。
Redis はプライマリ データ ストアではなく、一時的なキャッシュ データとセッション データを保持します。 DR では、バックアップ/リストアではなく、高速フェイルオーバーに焦点を当てています。
実装:
- 自動フェイルオーバーによるマルチ AZ の有効化
- 保存時および転送中の暗号化
- プライマリ ノードの障害により、レプリカが自動的に昇格されます (< 1 分)
5. Amazon MQ (RabbitMQ) — メッセージキュー
適用対象:ENABLE_AWS_SERVICES=true のある環境。
実装:
- 単一インスタンス (デフォルト) またはアクティブ/スタンバイ展開
- ブローカーの再起動中に、送信中のメッセージが失われる可能性があります。消費者が冪等になるように設計してください
- 管理 UI はポート 15671 (SSL) で利用可能
自動回復メカニズム
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/hostname の preferredDuringSchedulingIgnoredDuringExecution アンチアフィニティを使用して、ノードと AZ にポッドを分散します。
回復手順
シナリオ 1: AZ の障害
予想される動作: Karpenter は残りの AZ に交換ノードをプロビジョニングします。 KEDA はポッドを再スケジュールします。 ALB は、異常なターゲットへのルーティングを停止します。 検証:通常の状況では、手動介入は不要です。
シナリオ 2: Postgres プライマリ ノードの障害 (CloudNativePG)
CloudNativePG は、レプリカを自動的にプライマリに昇格させます。シナリオ 3: スナップショットから EBS ボリュームを復元する
シナリオ 4: インフラストラクチャの完全な再構築
致命的な障害が発生した後、またはリージョンを再構築するときに使用されます。シナリオ 5: Terragrunt 状態のロールバック
可観測性とアラート (SigNoz)
ENABLE_SIGNOZ=true の場合、SigNoz は monitoring 名前空間にデプロイされ、以下を提供します。
- すべての EKB サービスの分散トレース
- k8s-infra DaemonSet エージェント経由のクラスター メトリック (CPU、メモリ、ポッド ステータス)
- すべてのポッドからのログの集計
- アラート — SigNoz でアラート ルールを設定して、ポッドのクラッシュ ループ、高いエラー率、またはノードの負荷を通知します