■ 脅威モデルと対策

| 脅威 | リスクレベル | 対策 |
|------|------------|------|
| カード情報の窃取 | 致命的 | PCI DSSスコープ分離、トークナイゼーション |
| 不正送金 | 致命的 | 多要素認証、取引金額制限、AMLスクリーニング |
| APIへのDDoS | 高 | WAF + Shield Advanced、レート制限 |
| 内部不正アクセス | 高 | RBAC + 最小権限、監査ログ、特権アクセス管理 |
| SQLインジェクション | 中 | パラメータバインディング、WAFルール |

■ 認証・認可フロー

User → Mobile App: 生体認証 / PIN
  → API Gateway: JWT（短寿命15分）
    → Kong: JWT検証 + レート制限チェック
      → Service: スコープベースの認可チェック
        → DB: RLSによる行レベルアクセス制御

高額取引（10万円以上）:
  追加のステップアップ認証（SMS OTP or 生体認証の再確認）

■ データ保護

転送時:
  - 外部通信: TLS 1.3必須
  - サービス間: mTLS（Istio Service Mesh）
  - gRPC: TLS暗号化チャネル

保管時:
  - Aurora: AES-256 (AWS KMS CMK)
  - S3: SSE-KMS
  - ElastiCache: at-rest暗号化有効
  - カード情報: トークナイゼーション（カード番号はTokenization Serviceのみ保持）

鍵管理:
  - AWS KMS: マスターキー管理
  - CloudHSM: PCI DSS対象の暗号鍵
  - 鍵ローテーション: 年次自動ローテーション

■ メトリクス設計

ビジネスKPI:
  - 決済成功率: > 99.5%（5分間隔で集計）
  - 決済処理時間: p99 < 800ms
  - 日次取引額: リアルタイム集計
  - 不正検知率: 不正取引/全取引の比率

システムKPI:
  - API可用性: > 99.99%
  - Pod再起動回数: < 1回/日
  - DB接続プール使用率: < 80%
  - Kafkaコンシューマーラグ: < 1000メッセージ

■ ダッシュボード構成

1. エグゼクティブダッシュボード（経営層向け）:
   - 日次/月次取引額、決済成功率、アクティブユーザー数
   - 前月比・前年比のトレンド

2. オペレーションダッシュボード（SRE向け）:
   - SLI/SLOの現在値とバーンレート
   - インフラリソース使用率、エラーレート
   - デプロイ状況、直近のインシデント

3. サービスダッシュボード（開発チーム向け）:
   - サービス別のレイテンシ・エラーレート
   - 分散トレーシング（Jaeger）
   - ログの集約ビュー

■ アラート戦略

| 重要度 | 条件 | 通知先 | 対応時間 |
|--------|------|--------|---------|
| P1（緊急） | 決済API 5xx > 1% / 5分 | PagerDuty → オンコール | 5分以内 |
| P1（緊急） | 決済成功率 < 99% / 5分 | PagerDuty → オンコール | 5分以内 |
| P2（高） | API レイテンシ p99 > 2秒 | Slack #alerts + PagerDuty | 30分以内 |
| P3（中） | DB接続プール > 80% | Slack #alerts | 4時間以内 |
| P4（低） | ディスク使用率 > 70% | Slack #monitoring | 翌営業日 |

■ レイテンシ目標（SLO）

| サービス | p50 | p95 | p99 | 計測ポイント |
|---------|-----|-----|-----|------------|
| QRコード決済 | 200ms | 500ms | 800ms | API Gateway → レスポンス |
| 残高照会 | 50ms | 100ms | 200ms | Redis Cache Hit時 |
| 送金 | 300ms | 800ms | 1500ms | Saga完了まで（同期部分） |
| 投資注文 | 500ms | 1000ms | 2000ms | 注文受付まで |

■ スループット目標

通常時:
  - 決済: 1,000 TPS
  - 送金: 500 TPS
  - 残高照会: 5,000 TPS

ピーク時（キャンペーン・年末）:
  - 決済: 5,000 TPS（通常の5倍）
  - 送金: 2,000 TPS
  - 残高照会: 20,000 TPS

■ スケーリング戦略

| コンポーネント | スケーリング方式 | トリガー |
|--------------|----------------|---------|
| Payment Pod | HPA (CPU > 60%) | 水平スケーリング: 3→20 Pod |
| Account Pod | HPA (RPS > 1000/pod) | 水平スケーリング: 3→15 Pod |
| Aurora Reader | Auto Scaling | 接続数 > 70% |
| ElastiCache | クラスターモード | シャード追加（手動） |
| Kafka | パーティション追加 | コンシューマーラグ監視 |

■ RPO/RTOマトリクス

| ティア | サービス | RPO | RTO | DR構成 | 年間コスト |
|-------|---------|-----|-----|--------|-----------|
| Tier 1 | 決済、残高 | 0 | < 1分 | Active-Active(AZ) | 高 |
| Tier 2 | 送金、KYC | < 1秒 | < 5分 | Hot Standby | 中〜高 |
| Tier 3 | 投資、通知 | < 1分 | < 30分 | Warm Standby | 中 |
| Tier 4 | 分析、レポート | < 1時間 | < 4時間 | Backup & Restore | 低 |

■ フェイルオーバー判断基準

自動フェイルオーバー:
  - AZ障害: Route 53ヘルスチェック失敗 → 自動AZ切り替え
  - DB障害: Aurora自動フェイルオーバー（30秒以内）

手動フェイルオーバー（SREリード承認必要）:
  - リージョン障害: 大阪リージョンへの切り替え
  - 判断基準: プライマリリージョン復旧見込み > 30分の場合

手順:
  1. Route 53ヘルスチェック: プライマリ異常検知（自動、30秒）
  2. SREリード判断: リージョンフェイルオーバーの要否（手動、5分以内）
  3. Aurora昇格: セカンダリをWriterに昇格（自動、1分）
  4. EKSスケールアウト: 大阪リージョンをフル構成に（自動、3分）
  5. DNS切り替え: TTL 60秒で反映

■ DR訓練計画

| 頻度 | 訓練内容 | 参加者 |
|------|---------|--------|
| 月次 | DBリストアテスト | SREチーム |
| 四半期 | リージョンフェイルオーバー（計画的） | エンジニアリング全体 |
| 半期 | 縮退運転モード切り替え訓練 | エンジニアリング + CS |
| 年次 | ゲームデー（全体DR訓練） | 全社 |