クレジットカード イシュアシステム
マルチリージョン Active-Active × リクエストヘッジ × Strangler Pattern
可用性 (SLA目標)
99.99% 目標
RTO（目標復旧時間）
数分（ARC Routing Control + Active-Active 退避）
RPO（目標復旧時点）
数秒以内目標（Global Database / Global Tables / 補完ログ）
概算コスト
月 1,000,000 円〜（2リージョン、MSK、Aurora Global Database、DXを含む）
構成概要
- 可用性レベル
- マルチリージョン
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 超大規模（最大 5,000 TPS / 低レイテンシー承認）
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Amazon ECS / AWS Fargate
- Amazon MSK
- Amazon DynamoDB Global Tables
- Amazon Aurora Global Database
- Amazon ElastiCache for Valkey
- AWS Direct Connect
- AWS Transit Gateway
- Amazon Route 53
- AWS Application Recovery Controller
- Amazon S3
- AWS KMS
- Amazon CloudWatch
- AWS CloudTrail
概要
カード発行会社の Authorization と Reconciliation を AWS に段階移行し、Settlement は既存オンプレミスに残すハイブリッドなカードイシュア構成です。オンプレミスのカードネットワーク接続から Direct Connect と Transit Gateway で AWS へ取り込み、ECS と MSK で承認処理を疎結合化します。DynamoDB Global Tables、Aurora Global Database、ARC Routing Control により、リージョン障害時も処理継続を狙います。
★ 設計のポイント
- ▸Authorization / Reconciliation を AWS 化し、Settlement をオンプレミスに残す Strangler Pattern
- ▸カード番号や顧客IDなどのキーで処理リージョンを分離し、Active-Active と整合性を両立
- ▸テールレイテンシー対策としてリクエストヘッジを採用する余地を設ける
- ▸DynamoDB Global Tables と Aurora Global Database で取引状態と業務ルールを用途別に同期
システム構成図
周辺・運用機能（クロスカッティング / 全体に適用）
監視・運用
CloudWatch
CloudTrail
AWS Configセキュリティ・統制
IAM
KMS
Security Hub
GuardDutyハイブリッド接続
Direct Connect
Transit Gateway
Route 53データ・DR
DynamoDB
Aurora
S3コピーしてすぐ使える IaC
AWS Samples の FSI ケーススタディをカタログ化したものです。CDK サンプルは元リポジトリ側を参照し、ここでは構成判断と概念図に絞っています。
金融ワークロードアーキテクチャ解説 [クレジットカード イシュアシステム]
この構成を選ぶ理由
既存決済ネットワークや精算処理を一度に置き換えず、承認・突合から段階的に AWS 化することで、移行リスクと業務停止リスクを抑えます。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
オンプレ全面維持 | 高 | 既存運用は維持できるがピーク対応が硬直的 | 限定的 | 短期延命・規制上クラウド化できない領域 |
段階移行（Authorization/Reconciliation）採用 | 高 | ハイブリッド運用が必要 | 高い | カード承認を低リスクにクラウド化する場合 |
全面クラウド移行 | 非常に高 | 移行難易度が高い | 非常に高い | 既存制約が少ない新規カード基盤 |
採用時のトレードオフ
Active-Active は整合性設計が難しい
ハイブリッド運用の複雑性
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
決済
プラットフォーム
AWS Native + Hybrid
重要度
ミッションクリティカル（カード承認・突合）
DR方式
Active-Active / Multi-Region
接続方式
Direct Connect + Transit Gateway + オンプレミス決済ネットワーク
データ分類
機密（カード・顧客・取引情報）
✔ データ活用・統制の設計目標
- •承認処理の低レイテンシー、可用性、データ整合性を同時に監視する
- •リージョン間レプリケーションラグ発生時の補完ログと復旧手順を定義する
- •承認、突合、精算の境界を明確化し、段階移行時の業務リスクを抑える
- •カードネットワーク接続、オンプレミス連携、AWS処理の責任分界点を文書化する
⚠ 前提条件・留意事項
- •Settlement をオンプレミスに残す前提のため、ファイル連携、突合、夜間処理の運用設計が必要
- •Active-Active でも全データを単純に双方向更新するのではなく、キー分割や競合回避設計を前提とする
- •RTO/RPO はカードネットワーク側の接続、オンプレミス機器、運用切替手順に依存する
✓ メリット
- •カード承認のピーク負荷に合わせて ECS と MSK を独立スケールできる
- •マルチリージョン Active-Active によりリージョン障害への耐性を高められる
- •Strangler Pattern により既存精算処理を残しながら段階移行できる
- •補完ログと突合設計により復旧時の取引整合性を高められる
✗ デメリット
- •Active-Active、低レイテンシー、整合性を同時に満たす設計が難しい
- •Direct Connect、オンプレ機器、AWS の横断運用が必要
- •精算処理を残すためファイル連携・突合の設計負荷が残る
→ 主なユースケース
- •カード発行会社の承認系モダナイゼーション
- •既存メインフレーム/オンプレ決済基盤の段階移行
- •キャンペーンや大型セールで高TPSが必要なカード処理