Q&A
電子マネーや仮想通貨ではなくリアルマネーの話ですよね。
相談する場所が違う気がします。
分からないこと
会員のユーザー同士でお金のようなデータ(円やドル、仮想通貨、ポイントなど全てを含み、かつ法令を遵守できる、またユーザーにとって希少なもの)を交換するシステム(「送金」と表現することにします)をどのように作れば良いかわかりません。
ここで、想定しているのは、あるユーザーが別のユーザーに残高の一部を移動させるだけのシステムです。
追記(2019/10/25)
※法令遵守できるかどうかといった部分で、食い違いが起きてしまいましたので、より具体的なケースを記しました。
想定しているシステムについて追記します。
お金について、ユーザーが何らかの決済手段を用いて得た(購入したとは限りません)、サイト内のみ使えるポイントと定めます。
ここで、ポイントとは、あくまでサイトの所有物として、万が一紛失しても責任は問われないようなケースで、ユーザーにはそのことをよく理解しているものとします。
あるt時点のポイントのアカウントテーブルを次のように定めます。
| id | account | user_id |
|---|---|---|
| 1 | 100 | a |
| 2 | 70 | b |
上記のテーブルのt+1時点は、以下です。
| id | account | user_id |
|---|---|---|
| 1 | 90 | a |
| 2 | 80 | b |
id:1, user_id:aのアカウントから10引いて、id:2, user_id:bのアカウントに10足した状態を表現したということです。
上のシステムを作るとなった場合、どのようなアーキテクチャにしたら良いでしょうか。
考えたこと
私なりに考えたところ、
- 送金を表現するトランザクションログが、意義のある一定期間で保存が必要
- 現在の残高を表現するトランザクションログのスナップショットが必要
- データを絶対に紛失してはならない
- トランザクションの原子性、一貫性、独立性を満たす必要
- 4が満たされない(あってはならないバグが原因で)、または不正が行われた場合に、ある時点からリトライ・ある時点までロールバックできるようにすること
があるんじゃないかなと思いました。
5が思い浮かんだのは以前仮想通貨の取引所で、不具合が起きた時に、
残高やら取引履歴やらの全てが、不具合直前の状態が戻されたというニュースを聞いて、
印象に残っていたためです。
考えたことが全部合っている場合のアーキテクチャ
もし、上記の想定が合っているなら、
アプリケーションのアーキテクチャとして
- トランザクションログとしてkafkaのようなMQ
- at least onceなConsumerとして残高を冪等にRDBMSのデータベースへ記録するアプリケーション
- ある時点までのトランザクションを入力とした強制ロールバック用のアプリケーション
またデータについては
- 複数サーバーに同期的な書き込み
- トランザクションログを３年分?アーカイブとして保存する
と思いました。
以上、金融システム実装のご経験のある方からお話を伺いたいです。
※法律で、資金力の問題や、免許を取得しなければならないといったシステムと直接関係のない問題は全て解決できるものとします。システムアーキテクチャに関係のある法令(ログは3ヵ月は保持しましょうというような)を満たさない可能性をご存知であれば、ご指摘いただきたいです。
※セキュリティとして、ユーザーや管理者の認証や認可は全て正しく行われているものとします。お金固有のこだわらなくてはならないポイントがあれば、教えていただきたいです
取扱い可能な金額とリアルタイム性をどこまで保証するかは考えておいた方がいいと思います。あと、カネが絡むとサポートのプレッシャーが高くなりがちですね。
m.ts10806さん、ありがとうございます。
リアルマネーかどうかは定めません。いわゆるサイト内のみ使用可能なポイントや仮想通貨でも良いです。
takasima20さんありがとうございます。
リアルタイム性とはデータについて結果整合性を求めるかリアルタイム整合性を求めるかということですか？
もしくは、レプリカ間のfsyncのことについてですか？
取扱い可能な金額を考慮するとは、数字の型についてよく検討するということですか？
全く見当違いであればコメントいただきたいです。
でしたら「お金を送金」等の表現は改められた方が良いです。ポイントならまだ簡単な話ですが仮想通貨だとかなり難しい話になります。要は、要件定義を具体的にしないと話が進みませんということですね
タイトル、質問文、適宜訂正させていただきました。他、改めるべき箇所ございましたら、ご指摘いただければ幸いです。
「要件定義を具体的に」というご指摘最もか、と思います。
質問文、訂正いたします。
回答5件
0
設計以前の問題として、金融システム関連の法令・指針があるのはご存知ですか？
とりあえず、金融庁のページ貼っときます。
この中のどれを見ればいいかは知りませんが、個人でどうこう出来ることではありませんね。
投稿2019/10/24 23:55
総合スコア418
各種法令があり、資金決済法やら送金業やら銀行業やら、がんじがらめになっているのは知っています。法令をないがしろにしようとは思っていませんので、どうかご安心ください。
お聞きしたいのは、「絶対に不整合のあってはならないお金という性質を持つデータ」をどのように扱うべきかということです。
どうかよろしくお願いいたします。
0
その、送金、というのは具体的になにをするんでしょうか。
全てそれにかかってきますが。
投稿2019/10/24 22:47
総合スコア87747
例えば、残高を表すテーブルがあり、idとamountとuser_idのカラムがあったとします。
ある2ユーザー間でamountを送金額分、足し引きするようなものを想定しています。
もし何か追記必要であればコメントいただければ幸いです。
そういうデータのはなしではなく、実際の送金というのはどう考えてますか？
送金した、という指示があればあなたが現金書留にカネ入れて送るんですか？
ご不快に思わせてしまい、申し訳ございません。
「現金書留」を使う想定はしておりませんでした。
質問文、コメントいただいた後で、訂正させていただきました。
私の質問文の内容が不足しておりました。
ここで、お金とは、必ずしも国で定めたような広く流通するお金とは限らず、ユーザーにとって希少なもの=お金として読んでいただければ幸いです。
実際のカネじゃなければ、すきにすればいい、という話になりますね。
どれだけのことを許され、どれだけのことが許されないというのはあなたの頭の中にしかありませんし
y_waiwaiさんありがとうございます。
よく検討してみます。
0
システム設計以前にサービス設計したほうが良いですよ。
ちなみに、法律/ガイドラインは「絶対に不整合のあってはならないお金という性質を持つデータ」をどのように扱うべきかということを明文化したものです。
サービス設計の基幹であり、最低限満たすべき要件です。
投稿2019/10/25 05:01
退会済みユーザー
総合スコア0
te2jiさん、ありがとうございます。
よく法律について勉強しようと思います。
サービス設計後に参照されるのは、多くの場合 PCI DSS です。質問にあるような枝葉の話ではなくもう少し根幹の定義になります。
te2jiさんありがとうございます。
よく検討してみます。
0
自己解決
みなさま、私の未熟故な質問に真摯に答えてくださり、ありがとうございました。
アドバイスを一つ一つ検討していきたいと思います。
また、こちらの質問はこの自己解決の投稿を持って一度閉めさせていただきます。
回答に対するコメント(お礼含む)も以降、省略させていただきますので、
ご理解のほどよろしくお願いいたします。
投稿2019/10/25 07:57
総合スコア200
0
不整合な状態にならないようにしたいなら BeginTransaction～Commit or Rollback すればいいし、
ある時点に戻す必要があるのであれば適切な頻度でバックアップ取ればいいのではないでしょうか。
投稿2019/10/25 06:56
総合スコア559
workaholistさんありがとうございます。
私も、バックアップを取ることで実現できるのではないかと思いました。
しかし、ふと残高テーブルとは、送金というEventを大切にして、EventStreamのある時点の状態を表現すしたものに過ぎないんじゃないかなと思いました。
要するに、EventStreamにある送金Eventの連なりが真実であり、最も重要なデータで、残高テーブルが多少間違っていたとしても、EventStreamをもう一度さらえば残高テーブルをいつでも表現できるという状態が最も望ましいのではないかなと思いました。
あなたの回答
tips
プレビュー
