DMMの決済基盤アーキテクチャ

DMMの決済基盤では、多様な支払い手段やサービスをお客様が快適に利用でき、事業部の開発者が迅速にサービスを展開できること、さらに会計基盤と連携して経理業務や経営判断に役立つことが求められています。

DMM全体ではマイクロサービスアーキテクチャを採用しており、決済プラットフォームは「購入システム」「決済システム」の二つに分かれています。

提供される商品やサービスは、フロントエンドのレジで注文情報として収集され、その後の購入処理は購入システムにより一元的に管理されます。ポイントやクーポン、さらに決済システムとのデータ整合性を保証の上、注文処理の一連の流れを統括。

一方、決済システムはPCI DSSに準拠したクレジットカード情報管理を行い、決済代行事業者など外部サービスとの連携で安全かつ柔軟な支払い手段を提供しています。

また、システム設計は『リアクティブ宣言（The Reactive Manifesto）』に基づき、障害発生を前提とした耐障害性とスケーラビリティの高い設計を採用。イベントソーシングやイベント駆動による非同期通信を活用し、サービス間の依存関係を適切に制御するとともに、分散トランザクションに対する補償アクションの仕組みを取り入れ、高い柔軟性と信頼性を確保しています。

インフラ基盤は主にKubernetesを採用。別途、PCI DSS準拠が求められるクレジットカード情報管理領域は、明確に分離した運用体制下で厳格なセキュリティ基準を適用しています。

現在のアーキテクチャの課題と今後の展望

今回のアーキテクチャは、私たちが目指す理想を表したものです。

10年以上運用が続く現決済基盤は、インフラ基盤がオンプレミス、AWS EC2、Kubernetesといった複数の異なる環境下で技術的負債を多く抱えています。ソースコード管理もBitbucket、Github Enterprise、Github Cloudなど複数のリポジトリ管理システムが混在し、CIはJenkins、CircleCI、Github Actionsを使用しています。さらにCDは独自開発のデプロイツール、Elastic Beanstalk、ArgoCDが併存し複雑化しています。

モノリシックだったアプリケーションを分割した経緯から、購入システム内部にはポイント、クーポン、ボーナス、決済、サービスといった異なるドメインに関連したロジックが残存しているため、新しいサービスや支払い方法の追加の際にマイクロサービスとして独立した開発や運用が困難で全体的なコミュニケーションや調整が必要な状況です。

複雑でレガシーな状態のまま、購入処理のように高度な整合性が要求されるシステムの運用上、各種問い合わせや障害対応に時間を多く費やしています。これらの技術的負債を解消し、理想のアーキテクチャに向けてシステムのリライトに取り組んでいます。


◆執筆： プラットフォーム開発本部 第2開発部 決済グループ モダナイゼーションチーム　Team Leader　藤井善隆　@yoshiyoshifujii