はじめに
仮想通貨取引所のコア処理をプレ実装設計した時のメモです
「東京証券取引所」の1日の注文受付数は、下記を参考に、2億7000万件/日が理想値です、注文受付時間は、9:00 - 15:00（1時間休み）なので、実運用時間は5時間です。つまり、5400万/hour = 15000注文/sec、秒間15000件の注文を受付可能であれば、東証と同レベルの取引所システムだと言えます
取引所のフロントエンドは、httpインタフェイスで、そのリクエストは一旦 FIFO キューとして利用するmysqlデータベースに保存します。WEB-FRONTは、このFIFOテーブル(インデクス無し)にINSERT SQLのみを発行することで、おおよそ20Kqpsまで対応できます。つまり秒間2万件の注文リクエストを「受け付ける」ことができます
https://bitflyer.com/ja-jp/explanation-virtual-currency-regulation
上記を参考にすると、仮想通貨取引所は、24時間365日運用されるようです（途中10分のシステムメンテナンス）。そうすると、最大で秒間15K注文を受け付け可能ということは、注文レコードは1日で「15K x 86400 ≒ 13億レコード」にも達してしまうので、データベース＠テーブルリソースのシャーディングが必須になります
もっともシンプルなデータベース・シャーディング配置は、ユーザグループ毎に注文レコードをシャーディングすることです
ユーザが注文を完了したタイミングとは、WEB-browser上でボタンを押下したタイミングではありませんし、Load-Balancer、nginx、http-serverに到達したタイミングでもありません。暗黙的にデータベースにcommitした順番だろうと定義しがちですが、「取引所コアエンジンに注文が到達したタイミングと定義」することで、注文のユーザ公平制御を担保できると定義します
これによって、ユーザグループ毎にシャーディングするというもっともシンプルな設計を採用できるのです。その場合、注文ステータスを以下のように考えます
| desc | note | |
|---|---|---|
| 1 | 注文保存 | データベースにINSERT完了 |
| 2 | 注文配信 | データベースからbinlogを通じてproxyがdequeし、取引所コアへgrpcで配信 |
| 3 | 約定 | 取引所コアが約定処理を実施 |
| 4 | 結果反映 | post processが約定処理結果をデータベースへINSERT、UPDATE反映 |
取引所モジュール
エンドポイント（web api）から、取引所（約定）機能、データベースを含めた取引所全体のモジュールブロックです
- アプリケーションレベルで冗長性を担保する+ モジュール間IPCがたすき掛けに接続される
- ネットワークレベルの冗長性は、裏面、表面という感じで表現
- データベースボトルネックをスケールアウトによって回避できる
- シングルポイントがあるシステムでの動的デプロイを可能とする
平たく言うと、mqなどのミドルウェアをなるべく利用せず、アプリケーションレイヤ、ネットワークレイヤの双方で冗長性を担保する設計
ネットワーク視点
ネットワーク視点から見たHA構成は以下のようになります。master x master で、互いのmasterイベントをlistenすることでデータベース冗長性 = 経路冗長性を実現します
モジュールシーケンス
データシーケンス
システムステータス
mysql@binlogをシステムの中枢に利用するときに、問題となるのが「どこからbinlog-listenerを開始するのか」というクリーンブート設計です、このシステムではシステムコントロールモジュールがクリーンブートを制御します
grpc
matching-engineでは、上り下り、双方向インタフェイスでgrpcとしました、grpcライブラリがボトルネックにならないことを確認しました
スレッドでのスケールはしませんでしたが、プロセス（コア）スケールすることを確認できました
注文シーケンス
フロント側から見た注文処理は、データベースにオーダーをINSERTするだけです。その後の処理は、バックグラウンドで
- matching_proxy
- matching_engine
- matching_publisher
の順に処理が進められます
ここまでで、High Performance な、仮想通貨取引所を意外とシンプルに実装設計可能なことが確認できました
取引所を実現するには、許認可に大きなコストがかかるとは思いますが、そのコア処理部は意外とシンプルに実装設計できそうでした。もちろん他にも、ユーザ画面、admin画面、ウォレット管理（物理的な）、体制構築（物理的な）等、がなければシステムにはなりません。