決済システムの信頼性を支える技術と運用の実践

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2012-2025 BASE, Inc. 2 氏名：加賀野　祐（ykagano）所属：BASE株式会社 Cartチーム業務：バックエンドエンジニア趣味：お酒、旅行、キャンプ以下の決済サービスの開発を経験してきました - 2009年〜：NET CASH - 2012年〜：WebMoney - 2017年〜：Yahoo!ウォレット PayPay、PayPayカード - 2024年〜：BASE ykagano 自己紹介

Slide 3

Slide 3 text

© 2012-2025 BASE, Inc. ネットショップ作成サービス「BASE」 3 ショップ開設数（個人・法人・行政を含む） 240万ショップ以上 BASEかんたん決済利用料 3.6%+40円サービス利用料 3% コンセプト：「誰でも簡単に使えるネットショップ作成サービス」初期費用・月額費用 0円ショップオーナーのサポート機能が充実！個人でも決済機能をかんたん導入。審査もスピーディー！クレジットカード銀行振込コンビニ決済・Pay-easy 後払い（BASE Apps）キャリア決済 5年以内にネットショップを開設する際に利用したカート型ネットショップ開設サービス　調査委託先：マクロミル（ 2025年2月実施）

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2012-2025 BASE, Inc. クリス・デイトの言葉を紹介します 14 「非正規化」はあくまでも最後の手段であるという姿勢でのぞむ、というものだ。要するに、十分に正規化された設計をあきらめてよいのは、パフォーマンスを向上させるためのその他すべての戦略が要件を満たさない場合だけである。 DBでパフォーマンスを向上しないと要件を満たせない場合だけは非正規化するのもやむを得ないと捉えていますミック：著(2012) 達人に学ぶDB設計第5章論理設計とパフォーマンスより引用

Slide 15

Slide 15 text

© 2012-2025 BASE, Inc. 正規化/非正規化のメリット・デメリット 15 では決済システムにとって非正規化しないといけない理由とは何か、テーブルの正規化と非正規化のメリット・デメリットをあらためて表にまとめてみました観点正規化非正規化メリットデメリットメリットデメリット SELECT 整合性が高く重複が少ない JOINが多く遅くなる JOIN不要で高速冗長で整合性崩れやすい UPDATE 一箇所更新で済む更新が複雑になりやすいほぼなし複数箇所の更新が必要 INSERT 重複を避け効率的挿入処理が複雑書き込み回数が少ないデータが肥大化しやすい

Slide 16

Slide 16 text

© 2012-2025 BASE, Inc. 正規化/非正規化のメリット・デメリット 16 では決済システムにとって非正規化しないといけない理由とは何か、テーブルの正規化と非正規化のメリット・デメリットをあらためて表にまとめてみました決済システムでは、非正規化のメリットとして、INSERTの書き込み回数が少ないというのが大きなメリットと考えています決済システムには大量の決済負荷があり、いかに決済を完了させるまでの処理を短くするかが重要で INSERTの回数を減らすための設計が必要となります観点正規化非正規化メリットデメリットメリットデメリット SELECT 整合性が高く重複が少ない JOINが多く遅くなる JOIN不要で高速冗長で整合性崩れやすい UPDATE 一箇所更新で済む更新が複雑になりやすいほぼなし複数箇所の更新が必要 INSERT 重複を避け効率的挿入処理が複雑書き込み回数が少ないデータが肥大化しやすい

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 2012-2025 BASE, Inc. 決済処理に必要なDBの最小構成例 18 ● 決済リクエストテーブル ● 決済トランザクションテーブル ● 決済結果テーブルこの3つのテーブルへのINSERTのみで決済処理を考えてみます決済リクエスト REQUEST_ID REQUEST_DATE AMOUNT … CREATE_DATE UPDATE_DATE 決済トランザクション TRANSACTION_ID TRANSACTION_DATE AMOUNT … CREATE_DATE UPDATE_DATE 決済結果 REQUEST_ID PAYMENT_STATUS AMOUNT … CREATE_DATE UPDATE_DATE

Slide 19

Slide 19 text

© 2012-2025 BASE, Inc. DB含めた決済APIの最小構成例 19 こうしてINSERT処理だけにすることでパフォーマンスを向上させられます決済リクエスト REQUEST_ID … 決済トランザクション TRANSACTION_ID … 決済結果 REQUEST_ID … 決済リクエストが処理済みか判定なければ決済リクエストテーブルに書き込む決済結果テーブルにあれば冪等の結果を応答情報収集後、決済トランザクションテーブルに書き込む決済トランザクションログに書き込む（ DBダウン用）外部に決済をリクエスト決済の成否を決済結果テーブルに書き込む決済リクエストテーブルにあれば一意制約違反で応答決済API リクエスト決済失敗時は決済キャンセルのPub/Subに登録書き込み失敗時は決済キャンセルのPub/Subに登録

Slide 20

Slide 20 text

© 2012-2025 BASE, Inc. BASEではどうやっているのか 20 BASEでは決済手段ごとにテーブルを分けていますまた通信トランザクションは追記型でテーブルに記録してますこの辺りはどの決済システムも同じようにしているものと思います個人でも決済機能をかんたん導入。審査もスピーディー！クレジットカード銀行振込コンビニ決済・Pay-easy 後払いキャリア決済 PayPal Amazon Pay

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2012-2025 BASE, Inc. 負荷分散キャンペーンへ 24 そのため、最近はユーザーの購買意欲を分散させつつ売上を最大化するためにキャンペーンを長期間（1週間以上）続けたり、キャンペーンの終了時刻を深夜（AM2:00等）にするようになったものと思います ■アリババの独身の日は数週間ロイター：中国「独身の日」商戦終了、買い物客が増加　総売上高は推計26.6％増 https://jp.reuters.com/markets/japan/funds/ED7YUAMZVJIJ7BNQJEPFQQQMFM-2024-11-12/ ■超PayPay祭も数週間（AM2:00終了）コマースピック：Yahoo!ショッピング「超PayPay祭」で取扱高前年比112%を達成、2025年最高の売上記録 https://www.commercepick.com/archives/71111

Slide 25

Slide 25 text

© 2012-2025 BASE, Inc. キャパシティプランニング（容量計画）を行う 25 負荷が高いのがキャンペーンだと分かったら前回のキャンペーンや現在の決済数の伸び具合から半年先の目標負荷を決めます例えば現在決済APIに200tpsのトランザクションがあるとすると半年後には100tps増えて、300tpsになる見込みだとしますこの場合、負荷テストとしては見込みが上振れしても良いように、 100tpsの倍の200tps増の400tpsを目標とします現在 1ヶ月後 … 6ヶ月後 6ヶ月後の最大負荷または成り行きの 1年後 200tps 220tps … 300tps 400tps

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© 2012-2025 BASE, Inc. カード決済の負荷テスト 27 通常、決済代行を通して、カード会社に承認を取りに行くと遅くなります決済ネットワークも通るため、数秒かかりますアクワイアラー決済代行加盟店 CAFIS カード会社 CAFIS 加盟店アクワイアラーカード会社カード加盟店を管理しかし、カード会社のシステムに直接繋ぎ込みをして決済すれば早くなるため、大手企業はグループにカード会社を作ってオンアス取引（社内取引）をしています決済ネットワーク

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2012-2025 BASE, Inc. カード選択の仕組み 31 分散実行される複数コンテナの発射台がシーケンシャルにかつ重複しないカードを選択する仕組みが必要でしたそのため、1,000枚のテストカードの書かれたファイルをコンテナ数に分割して、コンテナごとに対象のファイルをシーケンシャルに参照するようにしましたカード会社 / アクワイアラー 1,000枚 200枚 200枚 200枚 200枚 200枚コンテナA コンテナB コンテナC コンテナD コンテナE 分割 1コンテナ100rpsのため秒間でカードは重複しない

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2012-2025 BASE, Inc. 負荷テストの実施 33 負荷テストを実施する際は、どこまでの負荷にシステムが耐えられるか確認するために、徐々に負荷を上げてテストします先ほどの例ですと、 200rps、250rps、300rps、350rps と徐々に上げていきますが、既に250tpsまでは問題ないことが分かっている場合は、 300rpsから始めたりしますシナリオ 1 2 3 4 5（目標） 6 7 rps 200rps 250rps 300rps 350rps 400rps 450rps 500rps 実行時間 5分 5分 5分 5分 5分 5分 5分

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2012-2025 BASE, Inc. 時系列の文字列 35 例えば2024年から2025年へ変わる1秒前にデータの書き込みが発生したとします「20241231235959ASDFGH」「20241231235959ZXCVBN」という2つの文字列を主キーにINSERTしようとした場合、先頭からの文字列の大半が同一ですそのため、Bツリー索引により同じリーフブロックが更新されてしまいスプリット待ちにより、DBの待機イベントが発生していました

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2012-2025 BASE, Inc. 対策 38 文字列全体を分散させることが必要だったため、主キーに入る値をハッシュ化した値に変更しましたハッシュ化前：20241231235959ASDFGH ハッシュ化後：6F5C6F7F3408F9FC4F91845E6C686B8ED8D61F51082B012F3C8989FD53D5F648 そしてハッシュ化前の値は新しく追加したカラムへ入れることにしました下記テーブルのイメージですカラム名データ型備考 REQUEST_ID varchar(255) リクエストID（ハッシュ化後） … … ORIGINAL_REQUEST_ID varchar(255) リクエストID（ハッシュ化前）

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© 2012-2025 BASE, Inc. 前提 42 まず前提ですが、バッチは処理する時だけ必要なシステムリソースが起動して、処理が終わったらシステムリソースを解放するようになっているのが理想です今ではサーバーや常設コンテナのシステムリソースを間借りして実行するよりも、バッチ単体でのコンテナ化と実行が主流になっていると思います CIもバッチ単体に対して実行できるような作りが望ましいです起動終了バッチ起動から終了までしか存在しない

Slide 43

Slide 43 text

© 2012-2025 BASE, Inc. 突合バッチについて 43 カード決済ではシステム間の決済結果を受け取れないことがありますシステム間の決済結果が異なったままにはできないため、突合バッチで注文システムと決済システム間の決済結果を突き合わせます（カード会社との突合が必要な場合もあります）決済システムアクワイアラーカード会社注文システム 10秒過ぎたため注文システム側がタイムアウト成功応答まで 0.5秒成功応答まで 10秒決済失敗決済成功

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© 2012-2025 BASE, Inc. 突合バッチでのチェック 45 システム間の結果が間違ってはならないので、複数の観点でチェックを行います 1件あたりでは、同一リクエストか、同一金額か、ステータスは一致しているか全件あたりでは、合計件数や合計金額が一致しているか確認します REQUEST_ID AMOUNT STATUS AAA… 1000 auth BBB… 2000 auth CCC… 3000 auth … … 合計件数合計金額 1000000 2,000,000,000 行の一致合計の一致 REQUEST_ID AMOUNT STATUS AAA… 1000 auth BBB… 2000 auth CCC… 3000 auth 合計件数合計金額 1000000 2,000,000,000

Slide 46

Slide 46 text

© 2012-2025 BASE, Inc. 突合バッチの機能テスト 46 CIで動作するバッチの機能テストではデータファイルに想定されるデータパターンを可能な限り用意します CI用のDBにデータを一時的に流し込み、そのデータをバッチに読み込ませて出力結果が一致することを確認します出力結果・合計件数・合計金額決済データ入力ファイル期待値・合計件数・合計金額バッチの突合処理決済データを DBに取り込む DB バッチの突合処理を実行する実行結果を確認するバッチのIN/OUTの結果を常に担保するテストシナリオ一致を確認

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© 2012-2025 BASE, Inc. 原因 48 パーティションキーの指定が甘かったことが原因です決済日というカラムがあります注文管理システムから渡される値で、この日の決済データとして共通に持つ値ですこの決済日はカーディナリティが低く（一意な値の種類が少ない）、INDEXを増やしたくないことから、作成日時のカラムと併用して検索をしていましたカラム名用途備考 PAYMENT_DATE 決済日 INDEXなし … … CREATE_DATE 作成日時パーティションキー

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© 2012-2025 BASE, Inc. まとめ 53 ● データベース設計 ○ パフォーマンスを向上させるためにDBの非正規化も選択肢 ○ 決済は追記型で処理することも選択肢 ● 負荷テスト ○ キャパシティプランニングを元に、性能要求を満たすための改善サイクルを回す ○ INSERTが多いテーブルの主キーに時系列な文字列（前方一致）は使わない ● バッチ設計 ○ バッチの機能テストではIN/OUTの結果を常に担保する ○ データが増加しても、変わらず処理ができるように長期的な視点での設計が必要

Slide 54

Slide 54 text

Slide 55

Slide 55 text