ストーリー

ATAMとは

概要

ATAM（Architecture Tradeoff Analysis Method）は、カーネギーメロン大学のSEI（Software Engineering Institute）が開発したアーキテクチャ評価手法です。

ATAMの目的:

  ① トレードオフの発見
    -- ある品質属性を優先すると、他の品質属性が犠牲になるポイント

  ② 感度点の特定
    -- アーキテクチャの小さな変更が品質属性に大きく影響するポイント

  ③ リスクの識別
    -- 品質属性の目標を達成できない可能性があるポイント

  ④ 非リスクの確認
    -- 設計が適切であると確認できたポイント

ATAMのプロセス

ATAMの9ステップ:

Phase 1: プレゼンテーション
  Step 1: ATAMの説明
  Step 2: ビジネスドライバーの説明
  Step 3: アーキテクチャの説明

Phase 2: 調査・分析
  Step 4: アーキテクチャアプローチの特定
  Step 5: 品質属性ユーティリティツリーの作成
  Step 6: アーキテクチャアプローチの分析

Phase 3: テスト
  Step 7: シナリオのブレインストーミングと優先順位付け
  Step 8: アーキテクチャアプローチの分析（追加シナリオ）

Phase 4: レポート
  Step 9: 結果の報告

NexPayへのATAM適用

Step 1-3: ビジネスドライバーとアーキテクチャの説明

■ ビジネスドライバー

1. 月間取引額1,000億円を安全に処理する決済基盤
2. 金融規制（PCI DSS、資金決済法）への準拠
3. 18ヶ月での市場投入
4. 100万ユーザーへのスケーリング
5. 99.99%の可用性（年間ダウンタイム52.6分以内）

■ アーキテクチャの主要決定

1. マイクロサービスアーキテクチャ（DDD + 境界づけられたコンテキスト）
2. イベントソーシング + CQRS（決済サービス）
3. マルチリージョン（東京 + 大阪）
4. Kubernetes (EKS) + Istio
5. Aurora PostgreSQL + Kafka

Step 5: 品質属性ユーティリティツリー

品質属性ユーティリティツリー:

可用性 (Availability)
├── [H,H] 決済APIの99.99%可用性
├── [H,M] リージョン障害時の5分以内フェイルオーバー
└── [M,M] 縮退運転モードでの部分稼働

パフォーマンス (Performance)
├── [H,H] 決済レイテンシ p99 < 800ms
├── [H,M] ピーク時5,000 TPSの処理
└── [M,L] 残高照会 p99 < 200ms

セキュリティ (Security)
├── [H,H] PCI DSS Level 1準拠
├── [H,H] カード情報のトークナイゼーション
└── [H,M] ゼロトラスト（mTLS + JWT）

変更容易性 (Modifiability)
├── [M,H] 新決済手段の追加（2週間以内）
├── [M,M] サービスの独立デプロイ
└── [L,M] 技術スタックの部分的入れ替え

凡例: [ビジネス重要度, 技術難易度]  H=High, M=Medium, L=Low

Step 6: アーキテクチャアプローチの分析

■ 分析結果

トレードオフ (Tradeoff):
  T1: イベントソーシング vs 実装複雑性
    - 効果: 完全な監査証跡、任意時点の状態復元
    - 代償: 実装複雑性の増大、イベントスキーマの進化管理
    - 判定: フィンテックの監査要件上、複雑性は許容

  T2: マイクロサービス vs 運用複雑性
    - 効果: チームの自律性、独立デプロイ、技術選択の自由度
    - 代償: 分散システムの運用複雑性、サービス間通信の信頼性
    - 判定: チーム規模(20名+)と要件を考慮し、複雑性は許容

  T3: マルチリージョン vs コスト
    - 効果: 99.99%可用性、リージョン障害への耐性
    - 代償: インフラコスト約1.5倍、データ同期の複雑性
    - 判定: 決済基盤の可用性要件上、コスト増は許容

感度点 (Sensitivity Point):
  S1: Kafkaのパーティション設計
    - 決済IDでパーティショニング → 順序保証
    - パーティション数の変更は再バランシングが必要
    → 初期設計で十分なパーティション数を確保すること

  S2: Aurora Global Databaseのレプリケーション遅延
    - 通常 < 1秒だが、大量書き込み時に遅延増加の可能性
    → 書き込み量のモニタリングとアラート設定が必須

リスク (Risk):
  R1: イベントスキーマの進化管理
    - スキーマの後方互換性を維持できないと、既存イベントの再処理が破綻
    → Schema Registryの導入とスキーマ進化ポリシーの策定

  R2: サービス間の障害伝播
    - Circuit Breakerの設定不備により、1サービスの障害が全体に波及
    → Istioのサーキットブレーカー設定のテスト・チューニング

非リスク (Non-Risk):
  N1: Aurora PostgreSQLの性能
    - r6g.4xlargeで1,000 TPS以上の処理実績あり。性能要件を満たせる
  N2: EKSのスケーリング
    - HPAとCluster Autoscalerにより、ピーク時5,000 TPSに対応可能

まとめ

チェックリスト

• ATAMの9ステップのプロセスを理解した
• 品質属性ユーティリティツリーを作成できた
• トレードオフ、感度点、リスクを特定できた
• 非リスク（設計が適切と確認できた点）を記録できた

次のステップへ

次は「リスク分析と軽減策」に進みます。ATAMで特定したリスクに対する具体的な軽減策を設計しましょう。

推定読了時間: 30分