ストーリー

RPO/RTO設計

サービスティア別のRPO/RTO

NexPayのサービスを重要度に応じてティア分けし、それぞれに適切なRPO/RTOを定義します。

RPO/RTOとコストの関係

コスト vs RPO/RTO:

コスト
  ↑
  │  ★Active-Active
  │  │
  │  │         ★Active-Standby
  │  │         │
  │  │         │     ★Warm Standby
  │  │         │     │
  │  │         │     │         ★Backup & Restore
  │──┼─────────┼─────┼─────────┼──────────────────→ RTO
  0  1分       5分   30分      4時間

  Tier 1: 決済は1分RTO → Active-Activeが必須
  Tier 4: 分析は4時間RTO → Backup & Restoreで十分

  ※ "全部をActive-Activeにする"は過剰投資

「DR設計のポイントは”すべてを最高レベルで守る”ではなく、“ビジネス影響に応じて適切に設計する”ことだ。限られた予算で最大の事業保護を実現する判断力が問われる」 — 佐藤CTO

マルチリージョン構成

NexPayのリージョン構成

NexPay マルチリージョン構成:

┌─────────────────────────────────┐
│         Route 53                │
│    (Health Check + Failover)    │
└──────────┬──────────────────────┘
           │
    ┌──────┴──────┐
    ▼             ▼
┌──────────┐  ┌──────────┐
│ Tokyo    │  │ Osaka    │
│ (Primary)│  │(Standby) │
│          │  │          │
│ ┌──────┐ │  │ ┌──────┐ │
│ │EKS   │ │  │ │EKS   │ │
│ │Pods  │ │  │ │Pods  │ │ ← Warm Standby（最小構成で稼働）
│ └──────┘ │  │ └──────┘ │
│          │  │          │
│ ┌──────┐ │  │ ┌──────┐ │
│ │Aurora│◄├──┼─┤Aurora│ │ ← Aurora Global Database
│ │Writer│ │  │ │Reader│ │   （レプリケーション遅延 < 1秒）
│ └──────┘ │  │ └──────┘ │
│          │  │          │
│ ┌──────┐ │  │ ┌──────┐ │
│ │Redis │ │  │ │Redis │ │ ← ElastiCache Global Datastore
│ │Primary│ │  │ │Replica│ │
│ └──────┘ │  │ └──────┘ │
└──────────┘  └──────────┘

フェイルオーバー発生時:
  1. Route 53がTokyo異常を検知（30秒以内）
  2. OsakaのAuroraがWriterに昇格（< 1分）
  3. OsakaのEKSがフル構成にスケールアウト（< 3分）
  4. DNSがOsakaに切り替え（TTL: 60秒）

Aurora Global Databaseの設計

# Aurora Global Database設計
aurora_global:
  # プライマリリージョン（東京）
  primary:
    region: "ap-northeast-1"
    cluster:
      engine: "aurora-postgresql"
      version: "15.4"
      instance_class: "db.r6g.4xlarge"
      writer_instances: 1
      reader_instances: 2

    # 自動バックアップ
    backup:
      retention_period: 35     # 35日間保持
      preferred_window: "03:00-04:00"  # JST 12:00-13:00
      copy_tags: true

  # セカンダリリージョン（大阪）
  secondary:
    region: "ap-northeast-3"
    cluster:
      instance_class: "db.r6g.2xlarge"  # コスト最適化で小さめ
      reader_instances: 1

    # フェイルオーバー時の動作
    failover:
      promotion_timeout: "60s"
      target_instance_class: "db.r6g.4xlarge"  # 昇格時にスケールアップ
      target_reader_count: 2

  # レプリケーション
  replication:
    lag_target: "< 1秒"
    monitoring:
      metric: "AuroraGlobalDBReplicationLag"
      alarm_threshold: "5秒"

データバックアップ戦略

3-2-1ルールの適用

NexPayバックアップ戦略（3-2-1ルール）:

  3つのコピー:
    ① Aurora自動バックアップ（プライマリリージョン）
    ② Aurora Globalレプリカ（セカンダリリージョン）
    ③ S3クロスリージョンレプリケーション（長期保管）

  2つの異なるメディア:
    ① Aurora（マネージドDB）
    ② S3（オブジェクトストレージ）

  1つはオフサイト:
    ① 大阪リージョン（地理的に分離）

バックアップスケジュール

リストアテスト

// NexPayリストアテスト計画
interface RestoreTestPlan {
  // 定期的なリストアテスト
  schedule: {
    monthly: {
      test: "Aurora Point-in-Time Recovery";
      procedure: "前日のスナップショットから復元し、データ整合性を確認";
      successCriteria: "30分以内に復元完了。取引データの100%一致";
    };

    quarterly: {
      test: "フルリージョンフェイルオーバー";
      procedure: "大阪リージョンへの計画的フェイルオーバーを実施";
      successCriteria: [
        "フェイルオーバー完了: 5分以内",
        "データ損失: 0",
        "決済API復旧: 5分以内",
        "フェイルバック: 30分以内"
      ];
    };

    annual: {
      test: "全体DR訓練（ゲームデー）";
      procedure: "障害シナリオをシミュレーションし、BCP全体を実行";
      participants: "エンジニアリング全チーム + CS + 経営層";
    };
  };
}

BCP（事業継続計画）

NexPayの事業継続シナリオ

縮退運転モード

# NexPay縮退運転設計
degradation_modes:
  # Level 1: 軽度の劣化
  minor_degradation:
    trigger: "投資サービスまたは分析サービスの障害"
    actions:
      - "影響サービスの機能を一時停止"
      - "決済・送金は通常稼働を継続"
      - "ユーザーに機能制限を通知"
    user_impact: "投資機能が一時利用不可"

  # Level 2: 中度の劣化
  moderate_degradation:
    trigger: "カードネットワーク障害"
    actions:
      - "QRコード決済とP2P送金は継続"
      - "カード決済を一時停止"
      - "加盟店にオフライン決済手順を案内"
    user_impact: "カード決済が一時利用不可"

  # Level 3: 重度の劣化
  severe_degradation:
    trigger: "プライマリリージョン全体障害"
    actions:
      - "大阪リージョンにフェイルオーバー"
      - "残高照会と小額決済のみ許可"
      - "送金・投資を一時停止"
    user_impact: "送金・投資が一時利用不可。決済は制限付きで継続"

  # Level 4: 最小限サービス
  minimal_service:
    trigger: "複数リージョン障害 / 大規模セキュリティ侵害"
    actions:
      - "全サービスを読み取り専用モードに"
      - "残高照会のみ提供"
      - "新規取引を全面停止"
    user_impact: "残高確認のみ可能。全取引を停止"

キルスイッチ設計

// NexPayキルスイッチ設計
interface KillSwitchDesign {
  // サービス単位のキルスイッチ
  serviceLevel: {
    payment: "決済処理の即時停止（残高照会は維持）";
    transfer: "送金処理の即時停止";
    investment: "投資注文の即時停止";
  };

  // 機能単位のキルスイッチ
  featureLevel: {
    newUserRegistration: "新規登録の停止（DDoS対策）";
    cardPayment: "カード決済のみ停止";
    internationalTransfer: "海外送金のみ停止";
  };

  // 実装
  implementation: {
    storage: "AWS AppConfig (Feature Flags)";
    propagation: "全Podに60秒以内に反映";
    authorization: "SREリード以上の承認が必要";
    auditLog: "全キルスイッチ操作を監査ログに記録";
  };
}

まとめ

チェックリスト

• サービスティア別のRPO/RTOとDR構成の関係を理解した
• マルチリージョン構成（Active-Standby）のフェイルオーバーフローを把握した
• Aurora Global Databaseの設計とレプリケーション遅延を理解した
• 3-2-1バックアップルールとリストアテスト計画を設計できた
• 4段階の縮退運転モードとキルスイッチの設計を理解した

次のステップへ

次は「演習：横断的関心事を設計しよう」に進みます。Step 3で学んだセキュリティ、可観測性、パフォーマンス、DRの設計をNexPayの設計ドキュメントとして統合しましょう。

推定読了時間: 40分