アイコンとMongoDBが性能検証、IPFが毎秒6000件の決済処理　障害時もデータ損失ゼロ

アイコン・ソリューションズ（Icon Solutions）とMongoDBは本日、共同ベンチマークの結果を公表した。MongoDB Atlas上で稼働するアイコン・ペイメンツ・フレームワーク（Icon Payments Framework、IPF）は、毎秒6,000件のエンドツーエンドの決済取引（データベース操作にして毎秒約43万回）を平均エンドツーエンド遅延0.51秒で処理し、アプリケーションノードとデータベースノードの両方の障害からデータ損失ゼロで復旧した。

口座間決済の取扱量は、急速に即時決済インフラへと移行している。トラフィックはネット決済型のスキームから即時決済スキームへと移りつつあり、口座振替の取扱量も一部がリクエスト・トゥ・ペイ（支払要求）へ移行し、即時決済スキームを通じて決済されるようになると見込まれている。銀行にとってこれは、トラフィックのピークがより急峻になり、数秒単位のスキームSLA（サービス品質保証）に縛られる決済の割合が高まり、ダウンタイムが一切許されなくなることを意味する。耐障害性、可用性、低遅延を維持しながら毎秒数千件の決済を処理し続けることの難しさは、自社開発を行う金融機関によって往々にして過小評価されており、レガシー基盤を常時稼働の処理に対応させる改修も大きな課題となっている。

IPFは国際的に実績のある決済開発フレームワークで、シティ（Citi）、ナットウエスト（NatWest）、BNPパリバ（BNP Paribas）などのティア1銀行に採用されている。クラウドネイティブかつイベント駆動型のアーキテクチャを基盤とし、規模、耐障害性、継続的な可用性が基本要件となる環境向けに当初から設計されている。今回のベンチマークは、まさにその点を検証するために設計された。

ベンチマークでは、SEPA（単一ユーロ決済圏）インスタント送金の参照フローを使用した。各決済は、重複チェック、メッセージおよびスキームルールの検証、不正・制裁スクリーニング、為替レートの取得、資金の確保と記帳、スキームメッセージの生成を含む12の個別処理ステップを完了し、銀行の周辺システムはシミュレーターで代替した。IPFとMongoDB Atlasには、目標値を毎秒500件から6,000件の決済取引まで段階的に引き上げる「ラダー」テストを実施し、ピーク時だけでなく各段階でスループット、遅延、データベース負荷を観測できるようにした。その後、稼働中の取引負荷のもとで障害シナリオを実行した。

主な結果

• エンドツーエンドで毎秒6,000件の決済。IPFは毎秒6,000件の決済取引を処理し、各取引が12の処理ステップすべてを完了した。この業務スループットを支えたのは、2つのMongoDB Atlasクラスター全体での毎秒約43万回のデータベース操作で、内訳はIPFイベントジャーナルで約23万6000回、IPFオペレーショナル・データストアで約19万6000回だった。
• 即時決済のSLAを大きく下回る遅延。毎秒6,000件の取引時における平均エンドツーエンド遅延は0.51秒で、即時決済スキームが通常認める10秒の枠のごく一部にとどまった。永続化の遅延はピーク時でも30ミリ秒未満を維持した。
• ほぼ線形で予測可能なスケーリング。毎秒500件から6,000件までの間、アプリケーションとデータベースは歩調を合わせてスケールした。シャードあたりのCPU使用率と挿入レートはラダーの各段階に比例して上昇し、遅延は範囲の上限付近までほぼ横ばいで推移した。このため容量を確信をもって予測でき、成長を未知への跳躍ではなくインフラの関数として計画できる。
• 十分な余力。ピーク負荷時、MongoDB AtlasのホットシャードのCPU使用率は約50%、IPF決済サービスのポッドは約60%で稼働し、WiredTigerの書き込みキューはゼロのまま、レプリケーション遅延も終始低水準を保った。
• データ損失ゼロでの障害復旧。毎秒3,500件の稼働負荷のもと、IPFはアプリケーションノードの異常終了から90秒未満で、計画的なノード停止からは約60秒で復旧した。いずれのケースでも、すべての取引がデータ損失ゼロかつ手動介入なしで最終状態に到達した。IPFのシャード再配置機能が処理中の取引を残りのノードに再分配し、永続化されたイベントから状態を復元する。
• データベースのフェイルオーバーは秒単位。これとは別に、Atlasに組み込まれたフェイルオーバーテスト（顧客自身も実行可能）を用いて実施したMongoDB Atlasのプライマリノードのフェイルオーバーは、平均約5秒で完了した。その間も決済処理は継続し、決済の損失やアプリケーションの再起動は発生しなかった。
• 基盤の改善がそのまま決済性能に反映。MongoDB Atlas 8.0から8.3への移行により、永続化の遅延は約50%短縮され、毎秒4,000件の取引時で約40ミリ秒から約20ミリ秒に低下した。

銀行や決済サービス事業者にとって、その意義は実務的なものだ。容量を当て推量ではなく計画できること、障害が手動介入なしで解消されること、そしてすべてを自社開発したりレガシー基盤を改修したりすることなく最新の決済インフラへ移行する道筋が得られることである。こうした結果を可能にしたのはアーキテクチャだ。

今回の結果は、過大なハードウェアではなく、分散型のスケールアウト・アーキテクチャによって達成された。IPFは単一のクラウドリージョン内の3つのアベイラビリティゾーンにまたがるKubernetes上で12のアプリケーションポッドとして稼働し、並行かつ耐障害性のある処理にAkkaを使用した。また、IPFコネクター・フレームワークのバックプレッシャー付きストリームによって、負荷上昇時に下流の不正検知、制裁、会計システムが過負荷に陥るのを防ぎ、Kafkaで処理データをオペレーショナル・データストアにストリーミングした。永続化はイベントソーシングとCQRS（コマンド・クエリ責務分離）のパターンに従い、MongoDB AtlasがIPFイベントジャーナル（5シャードのクラスター）とIPFオペレーショナル・データストア（6シャードのクラスター）の双方を支えた。各シャードは32 vCPU、128 GBのRAMを備えたM80クラスのティアで稼働した。

容量は、シャーディングの拡大とサービスの分離によって追加できる。一括決済と個別決済を分ける、決済の開始・実行・清算でフローを分割する、あるいは地域別に分けるといった方法だ。このためベンチマークは、必要とする銀行や決済サービス事業者に対し、毎秒6,000件を超える明確な道筋を示している。分離された各サービスは、それぞれ単独で毎秒数千件の取引を処理できる。

「銀行には、即時経済に適応できる決済インフラが必要だ」と、アイコン・ソリューションズのストラテジー・ディレクター、トワン・ファン・ベーセコム（Toine van Beusekom）氏は述べた。「しかし、耐障害性、可用性、拡張性、超低遅延を維持しながら毎秒数千件の決済を処理し続けるのは容易ではなく、レガシーアーキテクチャに依存している、あるいはすべてを自社で構築している金融機関にとってはなおさらだ。今回のベンチマークは、IPFが常時稼働の世界における前例のない要求に応えるよう設計された代替アプローチを提供し、銀行が自信をもって決済の未来を切り開けるようにすることを示している」

「毎秒6,000件の決済時、データ層は毎秒50万回近いデータベース操作を処理し、ノード障害からは5秒で復旧し、データ損失はゼロだった」と、MongoDBのインダストリー担当バイスプレジデント兼グローバル・フィールドCTO、ボリス・ビアレク（Boris Bialek）氏は述べた。「即時決済に必要なのは、単なる静的な記録システムではなく、動的でイベント駆動型のデータ基盤だ。今回のベンチマークは、MongoDBがリアルタイムで、しかも十分な余力を残して何を実現できるかを示している。規模、耐障害性、運用性能を単一のマネージドプラットフォームで。それこそが現代の決済を動かすエンジンだ」

ベンチマークレポートはこちら：『妥協なきスケール：アイコン・ソリューションズとMongoDBが実現する常時稼働の決済』

毎秒500件から6,000件の決済取引までの各段階の全指標ラダーや、結果を達成した方法の詳細を含む完全なデータセットは、アイコン・ソリューションズまたはMongoDBに請求すれば入手できる。