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

合同会社DMM.com

合同会社DMM.comは、会員数4,507万人（※）を誇る総合サービスサイト「DMM.com」を運営しています。
1998年の創業以来、多岐にわたる事業を展開し、現在は60以上のサービスを運営。動画配信や電子書籍、アニメなどの多様なエンタメサービスに加え、3DプリントやEV充電などのハードウェア分野、AIといった最先端のテクノロジーを取り入れた事業など、様々な事業を手掛けています。
2022年にはサブスクリプション会員システムの「DMMプレミアム」を立ち上げ、あらゆるエンタメ体験をシームレスにつなぐ「マルチエンタメ・プラットフォーム」の創造を目指しています。※2024年2月時点

アーキテクチャ設計の思想や意図

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

GMOペイメントゲートウェイ株式会社

GMOペイメントゲートウェイ株式会社（以下GMO-PG）はスタートアップ／ベンチャー向け決済インフラ「fincode byGMO」を開発しています。（※）

fincodeはカード決済だけでなく、コンビニ決済やPayPay、口座振替など日本国内の決済手段をモダンな開発者体験で実装・導入できる、GMO-PG連結企業集団の中では最も新しい決済代行サービスです。決済URL生成やサブスクリプション機能、プラットフォーム機能などの決済周辺機能により、エンジニアの実装コストを下げつつ新しいビジネスモデルの課金体系を実装可能です。初期費用・月額費用・オプション料金などは一切かかりません。

※ サービスの提供はグループ会社であるGMOイプシロン株式会社が行っています。

アーキテクチャ設計の背景や意図

fincodeは急成長するスタートアップ／ベンチャーのお客さまを多く抱えるため、サブスクリプション機能などの決済周辺機能の積極的な利用を想定したり、決済リクエストの急増に耐えるためのスケーラビリティを確保したりしつつ、カード情報を管理するためのセキュリティ基準である『PCI-DSS』への完全準拠が可能な、非常に高いレベルでセキュアである設計が求められます。



fincodeの基盤はオンプレミス基盤とクラウド基盤から成るハイブリッド構成です。

前者はGMO-PG連結企業集団全体の決済処理を長らく支えてきた信頼性のある決済基盤で、後者はECS/Fargateによりフルマネージされたコンテナアプリを中心とした、今どきのAWS基盤です。fincodeの開発チームは後者の開発・運用を行っています。

AWS基盤の方では高いレベルでセキュアかつスケーラビリティが担保されたサービスにするために以下のようなアプローチを採用しています。

• マイクロサービスアーキテクチャとマルチAZ、ECS/Fargate活用による冗長性と拡張性の確保
• DynamoDBを活用したリアルタイム流量制御
• 用途ごとにバッチ処理専用コンテナを起動。Step Functionsを活用し、スケーラブルなトランザクション管理を確立。
• PrivateLinkなどVPCエンドポイントを経由させた閉域アクセスによりPCI-DSS要件に適合しつつ、AWS内の通信を高速・安定化。
• Webhook通知を独立したECSタスクとして運用することで負荷を分散し、クリティカルな処理の安定性を確保。

これらが土台となり、決算説明会資料で開示した通り前年同期比406.3%の売上成長、つまりはお客様の急速な成長の支援を実現できています。

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

現状のfincodeはユーザー企業のトランザクション量が多くなると、管理画面上でのその情報の参照ができないという挙動が発生することがあります。データベース周りの負荷分散やクエリの効率化などはモダンなユーザー体験の提供というfincodeのテーマの上で解決しなければならない明確な課題です。

また、今後fincodeはプレスリリースで打ち出した通り、単なる決済インフラではなく企業間決済プラットフォームとしての機能を搭載したマルチFinTechインフラとしての進化を計画しています。

fincodeというサービスの中に決済代行事業ではない新たな事業ドメインを抱えることになるため、適切なサービスの分散・冗長化というお題目をより一層意識する必要があります。

◆執筆：
GMOペイメントゲートウェイ システム本部 関連事業サービス統括部 イプシロンサービス室長 米山 純司
GMOイプシロン fincode byGMO プロダクトマネージャー 中谷 仁貴

株式会社メルペイ

株式会社メルペイは、「信用を創造して、なめらかな社会を創る」をミッションに、スマホ決済サービス「メルペイ」をはじめ、後払い決済サービス「メルペイスマート払い」、クレジットカード「メルカード」を展開。決済・金融・シェアなどさまざまなお金にまつわるサービスに取り組んでいきます。

アーキテクチャ選択の背景や意図

メルペイの決済基盤はメルカリの各事業を支えるための基盤になっています。
アーキテクチャとしては、マイクロサービスアーキテクチャを採用しています。
背景には主に２つあります。

• 立ち上げ当初は、短期間でメルペイ・メルカリC2C向け機能を複数チームが並行開発する必要があり、各チームが自律的な開発・運用を可能にするアーキテクチャが求められた
• Fintech向けの決済基盤でもあり、高可用性が求められて障害影響を局所化できる設計が必要

サービス分割では「ドメイン境界」を重視し、過剰な細分化を避けつつ4領域に整理しています。

• 決済処理：メルペイ決済をはじめ、EC事業に必要な外部決済や法人向け請求書払いなど、さまざまな価値交換に対応する決済機能を提供
• 台帳・帳簿管理：価値変動の追跡・残高管理
• 外部決済機関接続：金融・決済機関APIの複雑性隠蔽
• 精算：手数料計算・加盟店売上確定、自動出金機能

サービスを分けることによって発生する決済トランザクションの整合性を確保する課題について、ステートマシンやワークフローを利用した分散型トランザクション管理の仕組み、またはサービス横断的なリコンサイル基盤を自社開発して対応しています。

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

事業拡大に伴い機能追加が加速し、一部ドメインが当初想定より複雑化してきました。単一チームの認知負荷が限界に近く、開発効率を維持するため、今後組織体制と合わせてドメイン再分割やドメイン境界の継続的な最適化を検討していきたいです。

現在、全事業向けに同一サービス群を共有する構成（Mutliple-tenant）になっているため、コアサービスの障害影響範囲が広域化する課題があります。今後事業側の規模と求められるサービスレベルに応じて、ドメインサービスを共通化したまま、事業専用の決済基盤（Single-tenant）の提供も検討していきたいと考えています。


◆執筆： Merpay Payment & Customer Platform Team、 Engineering Head　梁軍偉　@foghost

株式会社ネットプロテクションズ

後払い決済サービス「atone」について

ネットプロテクションズが開発・提供する「atone」は、通販・実店舗ともに使える後払い決済サービスです。購入者はお買い物をした後で代金を支払うことができ、銀行口座やクレジットカード情報の登録やチャージも不要で、すぐに利用可能となります。一方、atoneを導入した通販事業者は、取引成立直前に購入者が離脱してしまう「カゴ落ち」を防止でき、売り上げロスの減少につながります。

アーキテクチャ選択の背景や意図

ネットプロテクションズでは、モジュラモノリスを基本としたアーキテクチャを採用しています。システム全体の構造を統一感のあるものにしつつ、機能ごとに独立したモジュールを実装することにより、コードの重複を避け、再利用可能な共通ロジック層（例：モデル）を共通モジュールにまとめています。これにより、各モジュールが異なる処理を担当しながらも、同じロジックを繰り返し書くことを防ぎ、開発効率が向上しています。

　さらに、月末締めや翌月発行のフローに合わせたバッチ処理をスケジュールし、負荷の高い処理を分散しています。このバッチ処理のために、システム全体の負荷を適切にコントロールし、効率的な運用を実現しています。

　また、アクセスが集中する時期において、サービスのスケーラビリティを確保するために、コンテナ型のスケーリングが可能なECS on Fargateを採用しています。これにより、ピーク時に合わせた柔軟なスケールアウトが可能となり、高い可用性を維持しています。さらに、よく参照される会員システムについてはマイクロサービスとして分割し、疎結合な形で接続できるようにすることで、スケーラビリティをさらに高めています。

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

度重なる機能追加によりドメインが複雑化し、開発や運用の難易度が増していることが課題です。課題解消に向けて、まずはドメインの再設計を行い、システムの可視性や保守性を向上させる方針です。

　また、組織構成はドメイン単位で行われていますが、アーキテクチャ自体はその分割が反映されていません。このため、チーム間のコミュニケーションコストや、新規メンバーのオンボーディングコストが高くなっています。この問題を解決するためには、マイクロサービスのアーキテクチャに切り替え、ドメインごとに分割されたサービスを構築し、チームごとの担当範囲を明確にすることで、各チームの自立性と効率性を高めることを目指します。

　さらに、現在のシステムではバッチシステムの採用により、月末や月初のトランザクションの負荷が高まる傾向があります。ピーク時に合わせたインフラスペックにするためコストの問題があります。バッチ処理から脱却し、ストリーミングアーキテクチャを採用することで、リアルタイムで処理を行い、ピーク時の負荷を分散させ、システム全体の安定性とパフォーマンスを向上させる方針です。


◆執筆：atone プラットフォームチームリーダー/EM 南 樹里 @tree_nan2

株式会社スマートバンク

※家計管理サービス「B/43」は2025年3月24日にリニューアルし、新名称「ワンバンク」として提供を開始しました
　リニューアルに関する詳細はプレスリリースをご確認ください

スマートバンクは、「人々が本当に欲しかったものをつくる」をビジョンに掲げ、家計簿アプリとVisaプリペイドカードが一体となった 「ワンバンク」 を提供しています。

アーキテクチャ選択の背景や意図

ワンバンクのインフラでは、AWSのマネージドサービスを積極的に活用しています。
PCI DSS準拠の観点から以下の点でAWSを採用しました。

• PCI DSS観点の大きな差はデータセンターなどの要件9がほぼ全てスキップできる事
• PCI DSSに限った話ではないが、企業にとってオンプレミスで構築/運用していくことはかなりのハードルになる事

クラウド基盤を使用するとは言えAWS、GCP、Azureなど色々ありますが、 私の今までのスキルセットと、セキュリティ実績が高かったことからAWSでいくことにしました。 AWSでは数多くのPCI DSSに準拠しているため、QSA(Qualified Security Assessor)も判断し易い環境であるのは間違いないと思います。

Payment Card Industry Data Security Standard (PCI DSS) v4.0 on AWS
https://d1.awsstatic.com/whitepapers/compliance/pci-dss-compliance-on-aws-v4-102023.pdf

サーバー環境はFargateを採用し、 readonlyRootFilesystem:true とすることでIDS/IPSの要件をクリアできました。

可用性向上の取り組み

AutoScaleに関してもCPUとメモリにてスケールするように設定するとともに、リクエスト数でもスケールするようにしています。1台のコンテナで捌けるリクエスト数の80%を超えた場合にスケールアウトするようにしています。
アーキテクチャ図にあるadmin-webは可用性とコストの観点でCloudFront+S3で構成されています。ログインはGoogleのSSOを利用しておりAWS Cognitoで実現しています。

デプロイフローについて

デプロイフローに関しては、githubにてマージされたことをトリガーにCodepipelineが動作してデプロイされます。弊社ではnewrelicを使ってパフォーマンス計測を行っており、デプロイのタイミングでパフォーマンスに変化が見られることが多いため、デプロイ時にデプロイメントマーカーをつけるようにしています。詳しくは こちら のブログをご覧ください。

バックエンドについて

バックエンドは以下の理由からGolangとRuby on Railsを採用しており、一部Pythonも採用しています。

• Golang
  • Visa電文規格やカード印刷工場への入稿フォーマットなど型を持って制御したい
  • 大量のリクエストを瞬間的に捌きたい
• Ruby on Rails
  • 開発者が開発経験豊富なため開発スピードの重視
  • コード量や開発者が増えても対処できる点
• Python
  • SREで管理しているLambdaの開発に利用
  • SREメンバーに馴染みがあるため採用

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

ワンバンクは決済履歴も保存しており、決済とともにユーザー数が増えるとその決済履歴の閲覧によってDBの負荷が大きくなってしまいます。しかし現状ではReadとWriteの負荷を分散できておらず、Readの負荷をReadReplicaという形で分散することが課題の1つとなっています。 また、ワンバンクでは利用者の増加に伴い、アクセス数が増えてきております。PCIDSSの要件でもあるのですが、すべてのログをレビューする必要があります。SIEMテクノロジーの導入を行い、レビューをより確実に行うことも課題の1つとなっています。

◆執筆：エンジニアリング本部 SREチーム所属　上平 裕弥

株式会社UPSIDER

UPSIDERは「挑戦者を支える世界的な金融プラットフォームを創る」をミッションに、法人カード「UPSIDER」を始めとする複数事業を提供。法人カード「UPSIDER」の累計決済額は4,500億円超*1、提供サービスのユーザー数60,000社超*2の成長を支えるほか、シリーズDで154億円を調達し、累計資金調達額は600億円を突破*3。

法人カード「UPSIDER」は、独自のAI与信モデルにより最高10億円の利用枠を提供し、決済データのリアルタイム反映やバーチャルカード発行、会計ソフト連携など、成長企業のニーズに応える機能を搭載。高可用性を実現しつつ、スピーディな決済体験やシームレスな業務効率化を追求し、ユーザーへの提供価値を最大化。事業の成長を支える次世代の法人カードです。

アーキテクチャ選択の背景や意図

UPSIDERの決済システムは、高いスケーラビリティ、耐障害性、品質、そして開発スピードを両立するために、GKE/Istioを活用してマイクロサービスを採用しています。
決済に関わる処理は多岐にわたり、レイテンシーの許容度が低いオンライン処理から、深夜にバッチで実行する処理まで含まれます。
そこで、マイクロサービスにすることにより、特に安定性や低レイテンシーが求められる部分にリソースを集中させてスケーラビリティを確保したり、障害発生時には影響範囲を最小限に抑えることが可能となっています。また、サービスを分離することで、チームの開発スピードを維持しながら、より重要度の高いサービスの開発やテストにリソースを集中させることで品質も確保しています。

さらに、PCI-DSSというセキュリティ基準に対応するため、システムを2つのクラスタに分割しています。カード番号など高度なセキュリティ管理が求められるデータと処理を担う領域と、それ以外の領域を分離しました。これにより、高いセキュリティ基準を適用してコンプライアンスを確保しつつ、セキュリティ要件に縛られ過ぎずに効率的な開発ができるようになっています。

また、大規模な決済トランザクションにも対応できるよう、Google Cloud Spannerを採用。データの整合性を維持しながら、負荷に応じた柔軟なスケーリングを実現しています。

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

トラフィックとユーザー増加に伴うパフォーマンス課題

ユーザー数と決済トランザクションの増加により、さらなるパフォーマンス最適化が求められています。
非同期化の強化、データベースのアーキテクチャ改善、Kubernetesの設定調整など、複数のアプローチを並行して検討中です。また、決済のパターンやユーザーの利用方法が多様であるため、仕様と技術の両面から最適な設計を模索する必要があります。特に、決済の承認・拒否の判定においては、正確性を高めるほど処理が増えてレイテンシーやエラーが増加するので、両者のバランスを取ることが課題となっています。

オブザーバビリティの強化

マイクロサービス化によるシステムの複雑化に伴い、可観測性（オブザーバビリティ）の重要性が高まっています。
現在は、BigQueryに蓄積したデータでダッシュボードを組んだり、Grafana/Prometheusを用いたリアルタイムモニタリングとアラートの仕組みを構築しています。今後は、OpenTelemetryの導入を進め、分散トレースの可視化やより詳細なメトリクスの収集を強化し、システムの挙動をより深く分析できる環境を整えていきます。これにより、障害発生時の影響範囲を迅速に特定し、運用負荷を軽減しながら、安定した決済処理を実現していきます。

システム内の依存関係の改善

より高い耐障害性を確保し、開発の柔軟性を向上させるため、システム内の依存関係を見直し、リアーキテクチャを進めています。
例えば、不正利用の検知と決済処理を分離して、決済フローの安定性を向上させつつ、不正検知の高度化を独立して進められるように改善しています。

◆執筆：
UPSIDER Card　Engineering Manager / Tech Lead　Ryoya Sekino　@sekino_pii
UPSIDER Card　backend engineer　金正朋也　@thiefxx_


*1 法人カード「UPSIDER」リリースから、法人カード「UPSIDER」で決済された額の合計、2024年9月時点。
*2 法人カード「UPSIDER」および請求書カード払いサービス「支払い.com」の合計導入企業数、2024年9月時点。
*3 2024年11月末時点。