■ トップ5シナリオとアプローチ分析

#1 [可用性] 決済APIの99.99%可用性
  アプローチ: マルチAZ + マルチリージョン + 自動フェイルオーバー
  評価: ✅ 非リスク。AWSマネージドサービスの実績から達成可能
  感度点: Route 53のヘルスチェック間隔（30秒→15秒で改善可能）

#2 [セキュリティ] PCI DSS Level 1準拠
  アプローチ: トークナイゼーション + CDE分離 + mTLS
  評価: ✅ 非リスク。CDEスコープを最小化する設計は適切
  トレードオフ: 分離によるサービス間通信の増加

#3 [パフォーマンス] 決済レイテンシ p99 < 800ms
  アプローチ: gRPC + Redis + 非同期後続処理
  評価: ⚠️ 感度点。外部API（カードネットワーク）のレイテンシが支配的
  リスク: カードネットワーク遅延時にSLO未達の可能性
  軽減策: タイムアウト設定、キャッシュ活用、SLOの再検討

#4 [変更容易性] 新決済手段の追加（2週間以内）
  アプローチ: Strategy Pattern + Plugin Architecture
  評価: ⚠️ リスク。現設計ではPayment Serviceの変更が必要
  軽減策: Payment Gatewayパターンの導入を検討

#5 [スケーラビリティ] ピーク時5,000 TPS
  アプローチ: HPA + Cluster Autoscaler + Aurora Auto Scaling
  評価: ✅ 非リスク。EKSのスケーリング実績から達成可能
  感度点: Aurora Writerはスケールアウト不可（書き込みボトルネック）
  軽減策: CQRSにより読み取りをReaderに分散

■ NexPay リスクレジスター

| ID | カテゴリ | リスク | 影響 | 確率 | スコア | 軽減策 | 残存スコア | 受容 |
|----|---------|--------|------|------|--------|--------|----------|------|
| R1 | 技術 | カスケード障害 | 5 | 3 | 15 | Circuit Breaker + Bulkhead | 5 | CTO |
| R2 | 技術 | スキーマ進化の互換性破壊 | 4 | 3 | 12 | Schema Registry + CI検証 | 4 | TL |
| R3 | 技術 | Kafka可用性低下 | 5 | 2 | 10 | MSKマルチAZ + フォールバック | 5 | SRE |
| R4 | セキュリティ | PCI DSS監査指摘 | 5 | 2 | 10 | 早期QSA相談 + ギャップ分析 | 5 | CISO |
| R5 | セキュリティ | ゼロデイ脆弱性 | 5 | 2 | 10 | WAF + 迅速パッチ | 5 | CISO |
| R6 | PJ | Kotlinスキル不足 | 3 | 4 | 12 | 研修 + ペアプロ + 外部支援 | 6 | EM |
| R7 | PJ | スケジュール遅延 | 4 | 3 | 12 | バッファ20% + スコープ調整 | 8 | CTO |

■ リスクヒートマップ

            影響度
         1  2  3  4  5
    5  │  │  │  │  │  │
確  4  │  │  │  │R6│  │
率  3  │  │  │  │R2│R1│
    2  │  │  │  │  │R3,R4,R5│
    1  │  │  │  │  │R7│

赤(15+): R1 → 即座に対策実施
黄(8-14): R2,R3,R4,R5,R6,R7 → 軽減策を計画・実行

# ADR-004: サービス間通信にgRPCを採用

## ステータス
承認済み (2026-01-18)

## コンテキスト
マイクロサービス間の同期通信プロトコルを選定する必要がある。
要件: 低レイテンシ、型安全、双方向ストリーミング対応。

## 決定
サービス間の同期通信にgRPCを採用する。外部向けAPIはRESTを維持。

## 根拠
1. パフォーマンス: HTTP/2 + Protocol Buffers による低レイテンシ
2. 型安全: .protoファイルによるスキーマ定義とコード自動生成
3. ストリーミング: リアルタイム残高通知等の双方向通信に対応
4. Kotlin親和性: grpc-kotlinによる成熟したサポート

## 検討した代替案
- REST/JSON: パフォーマンスに劣る。スキーマの型安全性が弱い
- GraphQL: サービス間通信にはオーバースペック。クライアント向け
- Apache Thrift: gRPCと比較しエコシステムが縮小傾向

## 影響
+ レイテンシ改善（REST比で約50%削減）
+ コード生成による開発効率向上
- gRPC未経験メンバーの学習コスト
- デバッグがRESTより複雑（バイナリプロトコル）
- ブラウザからの直接呼び出し不可（BFF経由で解決）

# ADR-005: 可観測性基盤にOpenTelemetry + Grafana Stackを採用

## ステータス
承認済み (2026-01-20)

## コンテキスト
分散マイクロサービスの可観測性（メトリクス、ログ、トレース）基盤を
選定する必要がある。ベンダーロックインの回避が重要な要件。

## 決定
計装にOpenTelemetry、バックエンドにGrafana Stack（Mimir + Loki + Tempo）
を採用する。

## 根拠
1. ベンダーニュートラル: OTelはCNCF標準。バックエンド変更が容易
2. 統合性: メトリクス・ログ・トレースを1つのSDKで計装
3. コスト: Grafana Stack（OSS）はDatadog比で約60%のコスト削減
4. Kubernetes親和性: OTel Collectorのhelm chartが充実

## 検討した代替案
- Datadog: 機能は最も充実。しかし月額¥200万以上でコスト高
- AWS CloudWatch + X-Ray: AWSロックイン。カスタマイズ性不足
- ELK Stack: ログには強いが、メトリクス・トレースの統合が弱い

## 影響
+ ベンダーロックインの回避
+ 年間約¥1,200万のコスト削減（Datadog比）
- Grafana Stackの運用スキルが必要
- Datadogと比較してUI/UXが劣る部分がある
- OTel Collectorのチューニングが必要

# NexPay アーキテクチャレビュー結果サマリー

## 総合評価
設計はビジネス要件を概ね満たしている。
2つの要改善点と3つの残存リスクがある。

## 強み（非リスク）
- マルチAZ + マルチリージョン構成により99.99%可用性は達成可能
- PCI DSSスコープの最小化（トークナイゼーション）は適切
- EKS + HPAによるスケーリングは5,000 TPSに対応可能

## 要改善点
1. 外部API（カードNW）遅延時の決済レイテンシSLO
   → タイムアウト戦略の精緻化とSLOの段階的定義を検討
2. 新決済手段追加の容易性
   → Payment Gatewayパターンの導入を検討

## 残存リスク（受容済み）
1. カスケード障害（Circuit Breaker + Bulkheadで軽減）
2. スキーマ進化の互換性（Schema Registry + CI検証で軽減）
3. スケジュール遅延（20%バッファ + スコープ調整で軽減）

## 主要ADR
- ADR-001: マイクロサービス採用（PCI DSSスコープ分離）
- ADR-002: イベントソーシング（監査証跡の法的要件）
- ADR-003: Auth0採用（認証のBuy判断）
- ADR-004: gRPC採用（サービス間低レイテンシ通信）
- ADR-005: OpenTelemetry + Grafana Stack（ベンダーニュートラル可観測性）

## 次のアクション
- [ ] カードNW遅延のタイムアウト戦略を詳細設計
- [ ] Payment Gatewayパターンのプロトタイプ検証
- [ ] Phase 0の開始承認を取得