原文：BitMEX Technology Scaling, Part 2: The Road to 100x ALEX NIMMO
この連載のパート１では、BitMEXの起源についてお話しました。
今日は、この連載のパート2をお届けします。オーバーロードと水平方向のスケーリングに関する問題について深く掘り下げます。前代未聞のボリュームを処理するためのこれまでの取り組みの結果について議論し、BitMEXエンジンの各パーツ、すなわち、直列でなければならない部分、並列化できる部分、そしてBitMEXのAPIファーストの利点について詳しく説明します。
パート3では、すでに導入されているコードの最適化、並列化されたシステム、そして、特定の機能が除去された理由について説明します。さらに、公正で平等なアクセスを確保するためのBitMEXの取り組みについてお話します。そしてそれが、当社がコロケーションの提供を拒否していることと、どのようにつながるのかということについてもお話します。
では、始めましょう。
成長
BitMEXは、仮想通貨の分野におけるユニークなプラットフォームです。業界最高レベルのレバレッジと機能を提供するために、BitMEXの取引エンジンは、仮想通貨業界や従来の金融業界における他の多くのエンジンと根本的に異なります。また、非常に正確な取引とマージニングを提供することはできますが、それは、まだ、それほど速くはありません。
2017年のBitMEXの1日あたり平均取引量は、129倍に増加しました。これは驚くべき成長であり、2018年および2019年も成長を続けました。
2016-2018年の1週間あたりの取り扱い注文数
2018-2019年の1週間あたりの取り扱い注文数
このチャートは、１つ前のチャートの最後のピークから始まっていることに注意してください。
ご覧のとおり、1週間あたりの注文数も2017年から急増しています。特に興味深いのは、2018年7月は、注文数が比較的少ないにもかかわらず、USD取引で過去最高の80億ドルを記録したことです。この記録は、110億ドルの取引が行われた先週の2019年5月11日まで破られることはありませんでした。これらの記録は、1取引所において取引された1日あたりの仮想通貨取引額としては、依然として過去最高額であり、XBTUSD 永久スワップは、これまでで最も取引された仮想通貨商品です。この商品はこれまで、新規参入業者、既存業者を問わず、様々な仮想通貨取引所によって何十回も模倣されてきました。
2018年5月、当社は、取引エンジンでの注文のキャンセル、修正、および発注行動を最適化し、kdb +が提供できるような速度に合わせるために、内部データ構造やアルゴリズム、さらには監査チェックの改良に注力し始めました。既存のトレーディングエンジンが、現在行っていることをはるかに速いスピードで続けられるよう、当社はこの作業にたいへん注力しました。この努力により、非常に短期間でパフォーマンスを10倍以上に向上させたことをたいへん誇りに思います。パフォーマンスは、最初の30日間で4.6倍に、8月末までには10倍に向上しました。パフォーマンスが向上したことで、取引エンジンにおけるほぼすべてのオーバーロードが7月中旬までには解消されました。この驚くべき結果を達成したテクノロジチームをたいへん誇りに思います。
下記は、すべての書き込みリクエスト（注文の発注、修正、キャンセル）のオーバーロードをパーセンテージで示したもの。
赤いほど、オーバーロードが強いことを示します。
2018年5月5日
2018年7月16日
市場は当社のこの能力拡大に反応し、BitMEXの取引量は急増しました。当社の1日あたりのビットコイン取引量は、仮想通貨業界初の100万XBT取引の水準に達しました。この能力増大により、当社は、業界初のETHUSDクワント永久スワップのような革新的な新商品の発売を継続することができたのです。このETHUSD 商品は、上場から6週間で、業界一取引量の多い商品となりました。2018年11月、1日の取引量は200万ビットコイン近くに達し、2019年5月には110億ドルに達したのです。
7月のグラフでは、完全にオーバーロードが解消されているように見えますが、このレポートを読んでいるあなたなら、そのままの状態が続いたわけではないことをご存じでしょう。なぜ完全に修正されていないのでしょうか？ なぜ100倍以上に達するよう、我々は努力を続けなかったのでしょか？
いくつかの背景をご説明しましょう。
順番待ち
BitMEX上のリクエストに対するサービスは、チケットカウンターに並んで順番を待つのと似ています。あなたは列（キュー）に並び、列が解消されたら、自分のリクエストを行います。
チケットを購入するのにどのくらい時間がかかりますか？ まあ、列をなしていなければ、非常に速く済ませることができるでしょう。インタラクションは、少なくとも個々のリクエストに対応している間は続きます。トラフィックとボリュームが非常に少ないほかのトレーディングサービスでもイライラが生じるのは、このためです。たとえリクエストのキューがそれほど長くなくても、最大能力が低い場合は、そうなります。
キューが非常に長い場合はどうなるか考えてみましょう。あなたのリクエストが処理される間だけでなく、あなたの前にいるすべての人の処理が終わるまで待たなければなりません。たとえ世界一やり手のスタッフがいたとしても、順番待ちの列ができ始めたら、普通は非常に不満を感じるものです。
単純で非常に素早く処理されるリクエストもありますが、複雑で時間のかかるリクエストもあります。リクエストそのものを回避することができる場合（たとえば、ユーザーの利用可能残高が、リクエストを完了するのに必要な額に達していない場合）、自動チェックインカウンターやバッグドロップのような最適化システムを使って、そういう人たちが順番待ちの列に入らないようにすることもできます。
Webサービス上のトラフィックも同様です。 たとえ個々の要求は非常に素早く処理できたとしても、たったひとつのリソースのために列ができれば、顧客満足度は低下します。
これと同じような話を以前聞いたことがあるでしょう。AmazonとAlibabaは、休日に大きなシステムダウンを起こしたことがありました。ツイッターには、この失敗を批判する声が上がりました。BitMEXを含む多くのプラットフォームもまた、たまに運悪く順番待ちの列を発生させしまうことがあります。
オーバーロード
ご存知かもしれませんが、「システムオーバーロード」は、この問題に対処するためにBitMEXが採用しているメカニズムのひとつです。信じられませんか？ いったいどうすれば、オーバーロードが「問題」ではなく、逆に「解決策」になるというのでしょう？ オーバーロードは、業界ではむしろ「負荷制限（ロードシェディング）」として知られる情報システムにおいて利用される防御のための仕組みです。システムがクラッシュして、一切のリクエストが処理できなくなる状態になるのを避けるため、いくつかのリクエストを無視することにより、システムのオーバーロードを回避するのです。
当社は、負荷制限に関する明確な規則とそのメカニズムを説明するための文書を公開しました。
未処理のリクエストの列がいっぱいでないときに注文を出す
未処理のリクエストの列がいっぱいであるときに注文を出す（オーバーロード）
これを理解するために、負荷制限を持たないシステムを考えてみましょう。需要の増加に伴い、順番待ちの列ができ、その列が長くなり始めます。
最悪の場合、どうなるでしょうか？ 市場が動いているとき、トレーダーの巨大な群れは、ポジションを増やしたり減らしたりするために、競って発注します。遅延はそのうち解消されると思うかもしれません。すなわち、サービスの質が低下するにつれて、トレーダーは発注ペースを落とし始め、ひとつずつ処理が終わるのを確認してから、次の注文を出すようになると思うかもしれません。しかし、実際には逆のことが起こります。応答時間が長くなると、自動裁定取引者は、迅速に市場に参加して、他の取引所と同等の流通価格を維持するということができなくなります。また経験豊富なトレーダーは、価格差を把握し、手動でより有利な取引を行おうとしますが、こうした行動がさらにキューを長くしてしまいます。
何らかの予防策がなければ、キューは何分もの遅れにつながる可能性があります。ユーザーが、待機中の注文を効果的に発注できなくなるにつれ、オーダーブックのスプレッドは拡大します。注文が実際にキューを通過し、執行されるまでの間に、素晴らしい市場価格が、ひどい価格に変わってしまいます。このような状況では、取引は事実上不可能です。これは単なる仮説ではありません。他の仮想通貨市場も直面している共通の課題なのです。
これに対するBitMEXの解決策は、取引エンジンのキューに入れる注文管理リクエストの最大数を制限することです。取引エンジンの前には、リクエストを、読み取り（すなわち、GET / api / v1 / positionなどのデータを取りに行くこと）と書き込み（たとえば、注文の発注/修正/キャンセルおよびレバレッジの変更など）を識別するサービスがあります。書き込みの場合は、メインエンジンに委譲され、キューができることになります。このキューが長くなり過ぎた場合、キューに参加させて待たせるのではなく、すぐに注文を拒否するようにしました。このキューの長さは、最悪の場合でも3～5秒のレイテンシー（待ち時間）になるよう、エンジンのパフォーマンスに合わせて調整されます。
負荷制限に関する当社の文書によれば、キャンセルのような特定の種類のリクエストは、そのサイズに関わりなくキューに入ることができますが、他のリクエストと同様、列の最後尾に並ぶことになります。
このようにすれば、トレーダーは、注文がキューの最後尾に並んだ後に、執行に時間がかかるということを知るのではなく、システムの遅れを即座に把握することができます。このため、エンジンが減速することはありません。実際、オーバーロード中は、エンジンが最大注文数に達すると、オーダーブックとトレードフィードは非常に速く動きます。
オーバーロード中の取引
トレーダーの中には、取引がオーバーロード中も続くということに不満を抱く人もいます。実際、私たちはこのことに関して、ツイッターやトレーダーのチャットルームで、多くの陰謀論を目にしてきました。基本的に、これらは真実ではありません。BitMEXのすべてのトレーダーは、平等にアクセス権を有し、同じキューの最後尾に並びます。取引エンジンはいつでも、キューに並んでいる人のリクエストから可能な限り速く処理していきます。
システムに入力する注文の数が、システムが処理できる数の5倍に達したら、注文の20％のみが受け入れられ、80％が拒否されます。どの注文が拒否され、どの注文が受け入れられるかに関しては、単に注文が到着した時点でキューに空きがあるかどうかで決まります。あなたのリクエストが、別の注文に対するレスポンスが行われた直後にシステムに到着した場合、キューが最大限度数を下回るため、あなたのリクエストは受け入れられることになります。あなたの直後に提示された注文は、受け付けられないかもしれません。
取引のピーク時には、BitMEXの注文入力は、通常の20～30倍に膨れあがります！ 1分あたりの執行取引が1億ドル以上に達したこともあります。もしこの状態が続けば、取引量は1時間あたり60億ドル、1日あたり1440億ドルを超えることになります。これは、BitMEXや他の仮想通貨プラットフォームで1日に記録された最高取引量の13倍に相当します。
画像上部：合計リクエスト数 紫= API、青=フロントエンド。
画像下部：10秒ごとに拒否された注文比率（パーセンテージ）。この事例は、異常に高い比率を示しており、オーバーロードが最悪であったことを示しています。実際には、1日のうちにBitMEXに送信されたすべての注文のうち、負荷制限によって拒否されるのは2～3％に過ぎません。
急激に市場が動いたため、上図では、注文数が大幅に増加しています。
常にスムーズな取引を提供するには、BitMEXは、取引の集中するこうした事態にも対応できるよう、大きく余裕のある容量を確保する必要があります。 以下に、この目標を達成する過程で直面したいくつかの課題を説明します。
高いスケーリング能力とアムダールの法則
スケーリング問題はどうすれば解決できるでしょうか？ スケーリングには「垂直方向」と「水平方向」の2種類があります。垂直方向のスケーリングは、個々のシステムの速度を上げることを意味します。これを実現するには、より高速なプロセッサを購入するか（幸運なことに、CPUに関してムーアの法則は適用されなくなっています）、作業量を減らす方法を見つける必要があります。一方、水平方向のスケーリングは、「お金で解決する」類いの問題です。より多くのサーバーを稼働させ、それらのサーバー間で負荷を分散させます。
Webサーバーは、水平方向にスケーリングが可能なサービスのよい例です。 適切に設計された、たいていのシステムでは、顧客の需要を処理するために、Webサーバーの数を増やすことができます。ある応答が別の応答に依存しない限り、食料品店のチェックアウト係のように、複数のサーバーを並行して作動させても問題ありません。
これは非常に単純化された例ですが、多くの場合、スケーラビリティ・ソリューションは、もっと徹底した「お金で解決する類いの問題」です。多くのシステムは水平方向に拡張します。ほとんどの顧客のエクスペリエンスは互いに完全に独立しており、Webサーバーを増やせば簡単に処理できます。 バッキングデータベースは、多くの場合、データを相互に複製しながら水平方向に拡張できます。
水平方向のスケーリングには限界があり、よくアムダールの法則として表現されます。 つまり、システムの水平方向のスケーリング能力は、直列なオペレーションが求められる場合（すなわち、特定の順序で実行されなければならないオペレーション）によって限定されます。たとえば、複数のサーバーを介して、並行して実行することにより、スピードアップしたい、単純でシングルスレッドなサービスを想像してみてください。パフォーマンス分析の結果、作業の25％は、順番に行われなければならないものだということが分かったとします。この場合、残りは並行して行うことができます。これは、あなたがお金をかけて、いくら多くのコアまたはサーバーを用意したとしても、その数に関係なく、1/25％= 4であるため、4倍のスピードアップしかできないことを意味します。このちょっとした直列な作業がボトルネックになります。
出典：https://learnyousomeerlang.com
この直列要件は、BitMEXがほかの多くの一般的なWebサービスと大きく異なる点です。 BitMEXの取引エンジンは、はるかに多くの直列要件を持っているため、並列化の可能性は著しく制限されます。
シーケンシャル問題：注文とリマージニング
BitMEXの取引エンジンは、先入れ先出し法（FIFO）で注文を処理しています。人気の高いインターネットプロバイダーに電話をしてもなかなかつながらず、保留にされるように、取引エンジンへのコールも、受信された順に処理されます。
これは市場の基本原則であり、変更することはできません。オーダーブックは、注文を順番に受け付ける必要があります。つまり、注文すること自体が問題なのです。アグレッシブな注文が行われると、それによって流動性が奪われ、他の注文は流動性を享受できなくなります。このため、個々のマーケットでは、マッチングを効果的に行うことができなくなります。ただし、マッチングは、マーケットごとに1つのプロセスにデリゲート（委譲）される場合があります。
BitMEXは本稿執筆時点において、エンジンの前で、プロキシと直接通信するAPIサーバーを約150台稼働させています。このプロキシは、データミラーへのリクエストの読み取り、pub / Subシステムへのウェブソケットデータの読み取り、エンジンへの直接的なリクエストの書き込みをデリゲートします。
ご想像のとおり、書き込みは、システムの中で最もお金のかかる部分であり、スケーリングが最も困難な部分でもあります。取引システムが効果的に機能するためには、次の条件が必要になります。
- すべての参加者が、同時に同一のマーケットデータを受け取らなければならない。
- 参加者は誰でもいつでも書き込みを送信できる。
- 書き込みが有効なうちに、パブリックステートを変更する場合は、その書き込みが承認され、執行された後に、変更されたワールドステート（世界の状態）は、すべての参加者に送信されなければならない。
このシステムは最適化されていないため、二次スケーリングを行います。すなわち、100人のユーザーが1分間に1つの注文を送信すると、10,000（100 × 100）マーケットデータパケットが各参加者に1つ生成されます。ユーザー数が10倍の1,000人になれば、100倍のマーケットデータ（1000 × 1000）が生成される、といった具合です。
この記事の冒頭で述べたように、BitMEXは2017年に129倍に成長しました。その間、当社のユーザー数もそれに比例して拡大しました。 これは、2017年12月31日には、2017年1月1日時点に比べ、約16,641倍（129 × 129）のメッセージが送信されたことを意味します。
システムの一貫性
BitMEXをスケーリングするのは難しい作業です。私たちは、従来のスポット取引やデリバティブ取引のプラットフォームではありません。サインアップから入金、取引までの顧客のライフサイクル全体を処理します。
100倍のレバレッジを安全に提供するためには、BitMEXのシステムが正しく、高速に作動しなければなりません。BitMEXは公正価格マーキングを使用しています。これは、オリジナルなシステムですが、しばしば模倣されることもあります。このシステムは、その金融商品の直近の取引価格ではなく、元になる原資産のスポット価格の総合指数を使用して、ユーザーのマージンを再決定するものです。これにより、BitMEX市場は、外部の流動性を参照して操作することがはるかに困難になります。
これが正しく作動するためには、BitMEXエンジンに一貫性がなければなりません。 マーク価格が変わるたびに、システムは、すべてのユーザーのオープンポジションのマージンを再計算します。このとき、システム全体が、制御ルーチンによって監査されます。すべてのオープンポジション、すべてのオープンオーダー、すべての残余マージンのコストは、入金合計額と正確に一致していなければなりません。1サトシでも不明金が出れば、システムはシャットダウンします。こうしたことが、初めの頃は何度か起こりました。これは、アフィリエイトの収入や手数料における四捨五入などで、そのサトシに多少の誤差が生じるためです。エラーが発生するたびに、わずかな資金を補填するという誘惑はありましたが、当社チームは、システムの支払能力が最も重要であると考えています。すなわち、可能な限り高度なスタンダードを採用する必要があるのです。システムは、状況が大きく変化するたびに、今日も正確なサトシ額合計を監査しています。
悪意のある者が、BitMEX上のデータベースにアクセスして、自分の残高を編集するというのは不可能です。システムは、お金がどこからも出ていないことを即座に認識し、致命的なエラーを発生させ、シャットオフするでしょう。
監査する前に、あなたのアカウント全体の現在価値、すなわち、すべてのオープンポジションとオープンオーダーの、新しい価格に基づく価値を、一から再計算する必要があります。これによりトレーダーは、自分のアカウントに十分な資金がない場合は、全く買うことができなくなります。トレーダーのBitMEXの残高がマイナスになることはありません。
このシステムをスピードアップすることが、当社がスケーリングに注力する目的のひとつです。 マッチングは比較的時間がかからず、簡単にスケーリングできます。マージニングの場合はそうはいきません。BitMEXは、常に「早いうちに速く修正する」よう努めてきました。したがって、この作業にかかった時間の多くは、主に正確性を期すためのものでした。不正確な結果は許容できないので、正しく分散されたシステムが、プロデューサーの遅延や失敗を検出し、負荷を再調整し、重要な処理を限られた時間内に完了できなければなりません。これには、慎重で体系的な注意と厳密なテストが必要です。
当社のエンジニアは、最適化を安全に行うことができるいくつかの重要分野を特定し、プラットフォームの容量を劇的に増加させるための新しい堅牢なアーキテクチャを提供できるよう、絶え間ない努力を続けています。
APIファーストデザイン（API第一主義に基づく設計）
BitMEXは他社とはかなり異なります。APIファーストを採用しているからです。 BitMEXのアーキテクチャは、取引エンジン、API、Webフロントエンドの3つの主要部分で構成されています。フロントエンドという用語に、「the」という冠詞は付けませんでした。なぜでしょう？
BitMEXを構築するとき、私たちは最高級のAPIを望みました。優れたAPIにより、開発者は堅牢なツールを簡単に構築できます。想像もしなかったような視覚化やインターフェースさえも可能にします。私たちがコーディングを始めた頃、仮想通貨取引のAPIの性能は使い物にならないレベルだったと言っても過言ではありません。その多くは、規則も、文書も、事前に作成されたアダプタも備えていませんでした。重要なデータがないことも多く、重要な機能はWebサイト上でしか実行できませんでした。さらに悪いことに、多くの場合、ウェブソケットフィードを備えておらず、非公開にしてWebサイト経由でのみアクセス可能なものも少なくありませんでした。
BitMEXは、この傾向を覆し、仮想通貨取引におけるAPIに新たなスタンダードを導入しました。いかなるプログラムでも利用できるよう、ウェブサイトはAPIを使用しなければならないと規定することにより、敢えて「ドッグフーディング」方針を採用しました。これは「the」フロントエンド（すなわち、そこでしか通用しないような独自のフロントエンド）がないことを意味します。当社にあるのは、単に一般的な公式のBitMEXフロントエンドに過ぎません。プロジェクトとしてのBitMEX ウェブサイトには、API開発者のEARといくつかのログインや登録不正使用防止メカニズム以外に特別なアクセスはありません。
これはまた、BitMEXにアクセスするためのメカニズムが、他のメカニズムより速くも遅くもないことを意味します。モバイルデバイス、ブラウザ、オーダーメイドのAPIコネクタ、あるいは「Sierra ChartのDTCインテグレーション」のどこから入っても、すべてのユーザーは、同じデータパスと同じキューに入ります。こうして、すべての人は公平に扱われます。
BitMEXは、最初から以下のものを備えていました。
- 注文、取引、オーダーブック、ポジション、マージン、金融商品などを含むすべてのテーブルのウェブソケット変更フィード。ここでは、すべてのテーブルは同一のフォーマットに従います。
- Swagger（スワッガー）仕様（現在OpenAPIと呼ばれる）を通じて人とマシン両方が使用可能な完全に文書化されたオープンAPI。
- GitHub上の複数のサンプルプロジェクト
- WebサイトとAPIコンシューマの両方に対する統一されたデータパス。
リアルタイムデータ
APIファーストデザインへのBitMEXのコミットメントは、リアルタイムデータの実装において異彩を放っており、このことは当社のウェブソケットを見れば分かります。上で述べたように、すべてのテーブルにはリアルタイムのフィードがあります。これは仮想通貨業界では初めてのことで、今でも非常にまれな状況です。さらに、すべてのテーブルは同じフォーマットに従っており、わずか30行のコードを書くだけで、いかなるストリームも処理できます。あるいは、当社のGitHubから入手して利用することもできます。
このデータは、エンジン自体によって生成されたチェンジストリームから流れ、個々のユーザーのサブスクリプションによってフィルタリングされます。これにより、テーブルのサブスクライブ、リクエストの作成、変更のためのストリーム上での待機など、BitMEX上でのインターフェースの構築において、非常に快適なフローが可能となります。一般に、HTTPリクエストに対するレスポンスは、エラーでない限り無視できます。これにより、アプリケーションにおいてありがちな二重性を回避することができます。すなわち、これまでのアプリケーションでは、ウェブソケットストリームとHTTPレスポンスの両方を別々に読み取って合体しなければならないため、おかしなコードとバグが発生していましたが、これを回避することができるのです。
私たちは、トップレベルのアプリケーションインターフェースを構築するという当社のこの理念が、ユーザーランドの最高の統合を実現するだけでなく、BitMEXウェブサイトと今後のモバイルアプリを最高のものにすると信じています。
当社のリアルタイムフィードは、BitMEXプラットフォームが正常に機能するために必要な、最も重要な部分です。私たちはこの目的に向かって、システムの大幅な内部修正を行っています。これにより、外部を変更せずに、レイテンシー（待ち時間）とスループット（処理速度）を大幅に改善することができると期待しています。当社はまもなく、このシステムのローンチとその結果を発表する予定です。
次のステップ
上記により、当社が将来100倍に成長することを見据えて、プラットフォームをスケーリングする際に直面する課題について、すべての方々に十分に説明することができていれば幸いです。私たちはプラットフォームの成功を誇りに思っており、ユーザーに感謝しています。ただし、今後も発展していくためには、改善し続ける必要があります。
BitMEXトレーディング・エンジン・チームは、プラットフォームの更新を週に数回リリースします。これらの段階的な変更は、トレーディング・プラットフォームの継続的で長期的なリアーキテクチャであると同時に、エンジンに対する戦術的なインプレース能力の向上でもあります。これらの努力、成功、失敗については、このシリーズのパート3でご説明します。
当社のエンジンチームは、システムのスループットの大幅な改善を定期的に行ってきました。まさに最近、2019年5月23日に、同チームは、インフラストラクチャにおける大規模なアップグレードを行い、新規注文の処理能力を最大70％向上させました。今後数カ月間にわたり、こうした容量の大幅な改善を実施し続けると同時に、プラットフォームのより大規模なリアーキテクチャを並行して行って参ります。
新規注文の中央値、平均値、および99パーセンタイルの処理時間。アップグレードされたコードは、01:20（世界標準時）頃に開始されました。
95パーセンタイルの注文キャンセル処理時間（APIを通じて利用可能な3種類のキャンセル操作の場合）
当社は、トレーディングエンジンのスケーリングを急速に進めていますが、チームのスケーリングも行っています。BitMEXは、電子商取引システム、スケーリング、インフラストラクチャ、セキュリティ、そしてWebの分野で、世界的に有名な専門家を雇用しています。あなたがこの記事に興味を持ったとすれば、あなたが、当社の欲する人材であることの証かもしれません。当社の採用ページにはワクワクするようなチャンスが記載されていますので、ぜひご覧ください。