令和7年度 秋期 データベーススペシャリスト試験 午後II 問1 コード決済の分散トランザクション設計

問1 コード決済業者の決済業務及びポイント管理業務におけるデータベースの実装・運用に関する次の記述を読んで，設問に答えよ。

A社は，バーコードを用いたキャッシュレスの決済サービス，及び商品購入などに応じて一定のポイントを付与するポイントサービスを提供している。A社では，ポイントサービス利用件数の急増を受けて，システムの変更を検討している。

〔業務・現行システムの概要〕

1. サービスの概要

(1) 決済サービス
① 決済サービスを利用する人（以下，決済会員という）は，決済会員登録を行い，金融機関などから一定の金額を決済サービスに入金した上で，物品購入などの支払に充てる。入金及び支払に伴う残高を決済残高という。
② 決済サービスに加盟する事業者（以下，決済加盟店という）は，決済サービスへの加盟申請，審査を経て決済加盟店登録を受ける。
③ 決済会員は，スマートフォンなどの携帯端末，決済加盟店の店舗に設置されたPC, POSなどの端末（これらをまとめて，以下，端末という）を使用して，バーコードを読み取ることで支払を行う。同じ決済会員が同時に複数の支払を行うことはない。
④ 決済は，決済会員の決済残高から支払金額を差し引くことで完了する。
⑤ A社は，月に1回まとめて決済金額を決済加盟店に支払う。

(2) ポイントサービス
① ポイントサービスを利用する人（以下，ポイント会員という）は，ポイント会員登録を行ってポイントサービスを利用する。
② ポイントサービスに加盟する事業者（以下，ポイント加盟店という）は，ポイントサービスへの加盟申請，審査を経てポイント加盟店登録を受ける。
③ ポイント会員は，ポイント加盟店での支払，くじ引き，イベント参加などによってポイントを獲得する。
④ 獲得したポイントには，有効期限の年月が決まっている。獲得したポイントはポイント残高として貯めておき，支払に充てることができる。
⑤ 獲得したポイントは，すぐにポイント残高に反映されることもあれば，翌日以降になる場合もある。

(3) サービス間の連携

決済金額の一部をポイントで支払い，残りを決済残高から支払う場合など，両方のサービスを連携した決済を行うことがある。

2. システム構成

現行システムのシステム構成を図1に示す。決済サービス，ポイントサービスそれぞれに専用のサーバ及びRDBMSを用いている。サーバ上ではサービスに用いるアプリケーションプログラム（以下，APという）が稼働している。両サービスを連携した処理は，決済APを介して決済DB，ポイントDBの両方にアクセスする。

3. テーブル構造

決済サービス，ポイントサービスのテーブル構造をそれぞれ図2，3に，主な属性の意味・制約を表1に示す。なお，属性名の#は番号，Cはコード，Fはフラグを略した記号である。

4. 主な処理

各サービスの主な処理の内容を表2に，表2中のS1，S2，P2，P3の処理概要とSQL文を表3〜6に示す。各処理は一つ以上のステップから成る。表2〜6中の二重引用符で囲んだ名前は，図2，3中のテーブル名である。

5. 現行システムで使用するRDBMSの排他制御機能

(1) トランザクションの ISOLATION レベルごとの排他制御は、次のとおりである。
① READ COMMITTED では，行の参照時に対象行の共有ロックを取得し，参照終了時に解放する。行の更新時に対象行の専有ロックを取得し，トランザクション終了時に解放する。
② REPEATABLE READ では，行の参照時に対象行の共有ロックを，行の更新時に対象行の専有ロックを取得し，トランザクション終了時に解放する。
③ SERIALIZABLE は，行の参照時又は更新時に表単位の専有ロックを取得し，トランザクション終了時に解放する。
(2) READ COMMITTED 及び REPEATABLE READ では，SELECT 文に FOR UPDATE 句を指定すると，行の参照時に対象行の専有ロックを取得し，トランザクション終了時に解放する。

〔現行システムの決済処理〕

決済処理では，表2中の処理 S2 及び P3 を一つのトランザクションとして実行するために，2相コミットプロトコルを用いている。

1. 決済処理の流れ

決済処理の正常実行時のシーケンス図を図4に示す。図中の①〜⑬は実行の順番を，時点A，Bは実行の流れにおける特定の時点を表している。

2. 障害からの回復

決済処理の実行中に障害によってポイントDBが異常終了する状況を想定した障害・回復の事例を表7にまとめた。表中の時点A，Bは，図4中の時点A，Bに対応している。

〔システム変更案の検討〕

ポイントサービスでは，ECサイトを運営する加盟店の増加によって，サービス利用件数が急増し，ポイントDBの応答性能，可用性の低下が問題になっている。その対策として，次のシステム変更案を検討している。

1. システムの構成変更

検討中のシステム構成を図5に示す。業務機能別に会員サービス，決済サービス，ポイントサービスに分け，サービスごとに専用のサーバとデータベースを配置する。各サービスには独立した疎結合のAP及びデータベースを用いて，サービス内部の実装は隠蔽する。サービスに連携するアプリケーションプログラミングインタフェース（以下，APIという）だけを公開し，APIを呼び出すごとに単一のトランザクションとして処理する。端末からのアクセス時には，会員サービスを入り口にして他のサービスに連携する。

(1) 会員サービス

① 決済会員，ポイント会員の会員情報の登録，端末からの接続認証など会員に関わる機能をもつAP，及び後述する複数サービスが関与する処理の実行制御を担うAPを配置する。

② 会員DBには，現行システムと同じRDBMSを使用する。“決済会員”，“ポイント会員ランク”及び“ポイント会員”テーブルを配置し，登録，認証に使用する。会員情報の登録，変更は他のサービスにも連携する。

(2) 決済サービス

① 決済APは，ポイントサービスと連携する処理を無効にすることを除いて変更せず，APIを決済APに連携することで，特定の機能を呼び出して実行する方式に変更する。

② 決済DBは，現行RDBMSのデータベースをそのまま使用する。

(3) ポイントサービス

① ポイントAPは応答性能，可用性を高めるために再構築する。APIをポイントAPに連携することで，特定の機能を呼び出して実行する方式に変更する。

② ポイントDBをNoSQLに分類されるデータベースに変更し，図3中の全てのテーブルのデータを移行する。新しいポイントDBは，次の特徴をもつ。

• ワイドカラムデータストアをもち，複数ノードにデータを分散して配置することで，高速性，高可用性を実現している。
• RDBMSにおけるテーブルと同様に，列及び主キーを定義できる。外部キーは定義できない。CRUD操作命令を行う言語をサポートしていて，表3〜6のSQL文と同様の操作を記述できる。
• 複数のCRUD操作命令をまとめて一つのトランザクションとして実行する機能はなく，CRUD操作命令の終了時点でデータへの操作が確定する。
• 2相コミットを実現する機能はない。

2. 処理方式の設計

現行の2相コミットに替えて，次の処理方式を検討している。検討に当たって，ポイントDBに格納するデータの設計には，RDBMSのテーブル構造を用いる。

(1) 処理方式

① 複数サービスが関与する処理の実行制御を担うAP（以下，オーケストレーターという）を会員サーバに配置する。

② 端末からの要求ごとにオーケストレーターを割り当て，他サービスへの要求送信と結果受信とを同期的に行うことで，処理を順に実行していく。

③ オーケストレーターは，ワークフローの機能をもち，登録した処理を状態に応じて実行していく。タイムアウトなどの例外によって処理が異常終了した場合には，処理が成功するまで一定回数のリトライを行う。

④ リトライを経ても処理が失敗した場合，オーケストレーターは，それ以前に終了した処理について，ワークフローの逆方向に取消処理を順に実行する。取消処理では，データの変更を伴う場合に，そのデータ変更を取り消すトランザクション（以下，補償トランザクションという）を実行する。

(2) 実行制御テーブルの追加

会員DBに“決済指示”テーブルを追加し，オーケストレーターによるトランザクションの実行状態の記録，実行の制御に用いる。追加するテーブルのテーブル構造を図6に示す。“決済指示”テーブルの決済指示#は，決済指示ごとに一意な番号を自動採番し，トランザクションの識別子として使用する。オーケストレーターは，処理実行の指示及び補償トランザクション実行の指示に合わせて，“決済指示”テーブルに対応する行の全列の値を他サービスに連携する。

(3) 決済処理の流れ

決済処理を次のように実行することにした。

① 決済サービスでは，S2を一つのAPIとして実行する。

② ポイントサービスでは，P3のステップP3-1〜P3-3のそれぞれに対応するAPIを用意し，会員サービスはAPIを順番に実行する。

③ 会員サービスでは，他のサービスへの実行指示に対する処理結果を“決済指示”テーブルの状態に記録していく。

検討中の決済処理の正常実行時のシーケンス図を図7に示す。図7中の①〜⑮は実行の順番を，時点C〜Eは実行の流れにおける特定の時点を表している。

3. テーブル構造及び処理の変更

(1) リトライへの対応

図7中の実行指示に対応する処理の中には，リトライによる実行指示を受けたときに，重複更新の発生が懸念されるものがある。これを避けるためのテーブル構造及び処理の変更を行う。㋑決済サービスでは，対策として図2中の一つのテーブルに列を一つ追加し，処理S2の先頭にステップを一つ追加する。ポイントサービスでも同様の対策を行う。

(2) ポイントDBの整合性確保

表6の処理P3は，ステップごとにデータ操作が確定するので，ステップ実行の合間に他のトランザクションから同じ会員のデータ更新があると，ポイントDB内のデータに不整合が生じるおそれがある。これを防ぐために“ポイント会員”テーブルに更新中Fの列を追加してTRUE又はFALSEを設定した上で，㋒P2及びP3に，それぞれ同じ内容の処理を行うステップを追加する。

4. 補償トランザクションの設計

ここまでの検討結果を踏まえて，決済処理の補償トランザクションを表8にまとめた。表8中の処理IDは表2の処理ID，表8中のステップは表4，6のステップに対応し，補償トランザクションは，図7中の実行指示と同じ単位で実行するものとする。

5. 障害からの回復

表8の補償要否が“要”のステップは，全て補償可否が“可”となるように対策を行った上で，決済処理実行中にポイントサービスが障害によって停止する状況を想定した障害・回復の事例を表9にまとめた。表中の時点C〜Eは，図7中の時点C〜Eに対応する。