仮想通貨交換所を動かす技術　マネーフォワードCTOが語る、高難度のシステムに求められること

マネーフォワードCTOが語る仮想通貨交換所

中出匠哉氏（以下、中出）：こんばんは。マネーフォワードの中出といいます。この中でマネーフォワードって会社のことご存知の方は、どのくらいいらっしゃいますか？

（会場挙手）

ありがとうございます。今日はマネーフォワードではなくて、マネーフォワードフィナンシャルというグループ会社があるんですが、そこで現在仮想通貨交換所をつくってまして、そこのお話させていただきたいと思います。

私は、マネーフォワードのCTOの中出といいます。マネーフォワードのCTOと兼務して、マネーフォワードフィナンシャルにも関わっております。マネーフォワードフィナンシャルというのは、仮想通貨やブロックチェーンを活用したビジネスをやろうということで立ち上げた、新しいグループ会社です。

私はもともとシンプレクス株式会社というSIerにいまして、株式やFXなどのシステムを主に開発していました。アルゴリズムトレーディングと言われるような、人が売買するのではなく、機械が売買したり、HFT（High Frequency Trading）などの高頻度取引と呼ばれるものをつくっていました。

そして、いろいろ縁があってマネーフォワードに入り、家計簿サービスなどをやっていたんですが、途中からCTOに就任して、今はマネーフォワードフィナンシャル株式会社も兼務しています。今日はこの話をさせていただきます。

仮想通貨取引所を作る上で大切なこと

今日は、仮想通貨取引所をつくっていますというお話です。「なぜ仮想通貨取引所？」ということなんですが、マネーフォワードフィナンシャルのビジョンとして、「世界中の人々に、フリーでフェアな金融サービスを提供したい」と思っていまして、その実現のために、仮想通貨が単なる投機目的の取引だけではなく、実際に送金や決済に使われるようにしていきたいなと思っています。

仮想通貨やパブリックなブロックチェーンは、そのインフラとして重要な役割を担っていくだろうと感じているんですが、その前段として、仮想通貨の実利用や健全な発展に貢献したい。現時点では、仮想通貨交換所は仮想通貨の発展に必要だと私たちは考えています。健全で安全な存在として仮想通貨交換所が存在している必要があると思っています。

仮想通貨交換所づくりについてです。今日は「何を気にしないといけないのか？」とか、「何が難しいのか？」「どうつくるのか？」「どんな技術を使っているのか？」ということをお話ししたいと思います。

まずは「何を気にしないといけないのか？」ということです。今、高い可用性が求められているのではないかと思っています。仮想通貨は世界中で取引されていて、日々大きな値動きをする可能性があると思っています。それをいつでも取引できるようにであったり、時々今の仮想通貨取引所は、計画停止などで数時間停止ということもあるんですが、実際その間にも値動きする可能性があって、本来はそういったことは健全ではないと思っていたりします。

そのため、たくさんの注文を処理できるキャパシティーが必要です。仮想通貨取引所はAPIを解放していて、botで取引される参加者さんもいらっしゃると思うんですが、それでキャパシティ不足になってサービス停止になってしまうようなことは避けるようなサービスにしていかなければいけないと考えています。

あとはセキュリティーですね。ここが一番大事で、ハッキングされてお金が盗まれるということが実際に起こりすぎていると思っています。ただ、今日はここの話はしません。

本当はサービスを停止させてはいけません。サービス停止の影響というのは、ユーザーが経済的な被害を被る可能性があります。例えば70万円で購入したビットコインが、サービス停止で売却も出金もできずに35万円まで価格が低下するみたいなことが起こると、当然その人はかなり経済的な被害を被るのではないかと思います。

ですので、ユーザーの資産を守ることが最優先だと考えています。ただ、取引所ってよく止まっていませんか？　仮想通貨の取引されたことがある方は、この中にどれぐらいいらっしゃいます？

（会場挙手）

少しいらっしゃいますね。まあ、よく止まっているんですよね。

取引単価は安いが注文数が多い

では、「何が難しいのか？」という話で、そのわけを説明していきたいと思います。各取引所はだいたいキャパシティー不足でサービスが停止をしているんですが、インフラの増強は最大限やっているはずですよね。それなりに利益も持っていて、インフラ投資できないはずがなくて、やっているはずなんです。

ちょっとどのぐらいの処理量があるのかを推測してみたいんですが、例えばFXは、1日1業者、大手で、2兆円ぐらいの取引量があります。例えば東京証券取引所の場合は、1日2兆円から3兆円ぐらいの取引量です。FXの大手は、1社で同等ぐらいの取引高あります。仮想通貨の大手も、ピーク時は1兆円ぐらいの取引があったようです。

ただ、仮想通貨のほうは、取引単価が圧倒的に安いんですよね。FXをやったことがある方はご存知かと思うんですけども、だいたい1注文で100万円ぐらいの取引なんですが、仮想通貨取引は数千や数万円で取引できてしまうので、取引単価はFXより安いと思ってます。

FXの場合は、ピーク時にだいたい秒間数千件ぐらいの注文ですが、おそらく仮想通貨取引所はそれを超えて、下手すると1万を超えてくる可能性あるように思っています。API解放してるので、もしかしたらもっと多いのかもしれません。

なるべくDBにアクセスしないように

サービスの特性ですけども、レートだったり、こちらからアウトプットしている、ユーザーに出している情報の鮮度が大事で、キャッシュで折り返すみたいなことはちょっとやりづらいようなサービス特性だと思っています。あと、仮想通貨の取引は、仮想通貨の種類ごとに最後はシングルスレッドでしか処理できないような部分が存在しています。

なので、実は仮想通貨取引所の本当の最後、ユーザー同士の注文をマッチングする部分というのは、1つのサーバーでしか動いてないはずなんですね。だから、サーバーをたくさん用意しても、実は最後の最後は1台のサーバーで、しかもシングルスレッドでマッチングしています。

さらに、注文ごとにユーザーの資産をロックしていかなければいけません。例えばブラウザを2つ開いて同時に売り注文を出したら二重で売れちゃった、みたいなことは当然やってはいけないので、そういうロックをしなければいけません。マッチングやロックにDBを使っていたら当然ぜんぜん間に合わないので、こういったことはすべてメモリ内で行われます。

あとは耐障害性ですね。サーバー障害が起こった時にデータがなくなるとか消えるといったことは、当然NGです。下手すると何千万円という取引が行われてるので、そういうことはぜんぜんダメです。整合性が失われるのも、当然NG。

機能要件がすごい厳しくて、かつ、単純にサーバーを増やしてスケールアウトするみたいなことが非常に難しいような特性を持ってます。

こういったことが原因で、安定したサービスを提供するってことが難しいんですけども、「どうつくるのか？」ということで、基本的にはなるべくDBへのアクセスはしないようにしています。

そして最新のデータは常にメモリに存在していて、「メモリにあるものってキャッシュでしょ」と思われるかもしれないですけども、実はキャッシュじゃなくて、それを正解のデータ、マスタのデータとして扱ってます。

DBは書き込まないわけにはいかないので、後から非同期で書き込むということをやっています。DBにアクセスせずにサービスを提供してるかっていうとそんなことはなくて、過去の注文履歴を照会する際などは、当然DBを見たりしています。このへんは、DBにアクセスさせてよいところは、Readレプリを並べるなどでぜんぜんスケールアウトできるので、このあたりはそれほど難しいところではありません。

耐障害性を担保する仕組み

あとは、基本はすべて非同期処理ですね。同期のディスクIOとかは絶対やっちゃダメで、プロセス間の通信はなんらかのMQ的な非同期通信でやりとりしています。プロセスが停止後復旧したりすると、未受信のメッセージを途中からリプレイしてそこから処理を再開するような、そうしたつくりになっています。

耐障害性ということで、正解のデータをメモリに持っているので、「そいつが落ちちゃったらどうするんだ？」ってことになるんですけども、データのバックアップはスタンバイノードのメモリに書き込みます。

データの記録の優先順位って、当然まずはローカルのプロセス内のメモリにデータを持っていて、リモートプロセスのメモリに自分のコピーを書き込みにいきます。その次にローカルディスクに書いたり、DBを含むリモートディスクに書くっていうことですよね。DBに書いたりローカルディスクに書くよりは、隣のノードのメモリに書いたほうが早い、っていうことです。

板での注文のマッチングはボトルネックになりやすいポイントで、スケールアウトできない。マッチングの部分は、本当に最後の最後の部分はシングルスレッドでやるしかありません。

そして、1注文のレイテンシがスループットを決めています。例えば1注文のマッチングに1ミリかかると、秒間1,000注文しかマッチングできないですよね。それではぜんぜん間に合わないので、マイクロ秒単位でマッチングをかけていきます。まあ、高速に動作させることを祈ってつくる、という作業が必要になります。

採用している技術

では、「どういった技術でやってるか？」ってことで、もともとこういった分野って、やはりCとかでつくって開発したりするんですけども、私たちは今、Goで開発しています。インメモリDBとかや、プロセス間通信はNATSというミドルウェアを使っています。

マイクロサービスアーキテクチャーになっていて、マイクロサービスが10を超えるぐらい存在しています。フロントエンドの通信はgRPCを使っていて、Consulとか、Fireabase Authenticationとか、そういったものを使っていたりします。

インフラはGCPを使っています。まあ、いろいろ、Load Balancerとか、Bigtableとか、いろいろ使おうとしています。

開発環境は、こんな感じです。そんなにめずらしいものは使ってないですね。これもちょっと説明してもしょうがないんですけど（笑）、いろいろマイクロサービスを配置してやっていたりします。

ということで、短い説明になってしまいましたが、ご清聴ありがとうございました。今絶賛開発中で、15名ぐらいの開発体制で開発しています。金融庁の登録の審査とかが厳しくて、いつ稼働できるかというのはあれなんですけども、サービス自体は年内ぐらいに開発させたい。そして審査が通り次第リリースしたい、と思っています。

こういった、ちょっと普通のサービスとは違う、難易度の高いミッションにチャレンジしたいと思ってくださる方のジョインをお待ちしています。以上です。どうもありがとうございました。

（会場拍手）