原文：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％=...

こんにちは。BitMEX の CTO（最高技術責任者）Samuel Reed です。 BitMEX の構築に当たった過去 4 年間は驚きの連続でした。創業当時、私たちの 1 人として、このプラットフォームがこれほどの成功を収め、2018 年ビットコイン/USD 取引を支配するにようになると想像できませんでした。 2014 年から今日まで、BitMEX のプラットフォームはゼロから 1 日あたり平均取引高が 30 億ドルになるまでに成長しました。当社の主力商品、XBTUSDの取引高は、世界の仮想通貨商品の中で頂点にあります。当社は、世界中で、5 言語で世界中のお客様にサービスを提供し、ビットコイン価格の取得と流動性に関して上級プラットフォームとなっています。 BitMEX チームは、堅牢なモバイル商品を構築し、正真正銘クラス最高の技術チームを結成するなど、能力向上に全力で取り組んできました。私たちは、成功する目的となった要因のために、成功を喜びつつ、こうした栄光にあぐらをかくことはありません。むしろ、まったく逆で、今まで以上に忙しくしています。 当社は、コミュニティに、当社がどのように創設され、前進しているのかを知って欲しいと考えています。言い得て妙の名言どおり、「バグを克服するには、そのバグを理解しなければなりません」1 まずは、実話から始めます。 出典：russellfreeman.com 2014 年、私は、コーディングの集中セミナーを主催するGeneral Assembly社の香港でのウェブ開発パネルで講演していました。同社は、卒業間近の学生に、プロとして働く経験を味合わせたいと考えていました。私はその機会を利用して、自分の過去について話しました。小規模企業、新興企業、公的機関数社でいくつかのポジションを経験し、ソフトウェアエンジニアの需要の高さに驚いたことを強調しました。 かなり陽気な性格の人物が背後から質問しました。「CTO を募集中の現金に乏しい新興企業はどうやって自社をアピールしたらよいでしょう。このように競争的な状況で優秀な人材を引きつける方法にはどうしたらよいですか？」 「良い質問ですが、答えるのは難しいですね。資金調達無しでは、リスクと安定を天秤にかける重大な課題に向き合うことになります。経験豊富な開発者が、大手ハイテク企業での 20 万ドル以上の給与、快適でリソースに恵まれた環境を、週 80 時間以上の労働のために棒に振らなければならない理由などありません。基本的にあなたが探さねばならないのは、能なし（本当にそう言いました）です。ただし、多数のより有利な選択肢にかかわらず、リスクをとる覚悟のあるほどあなたのアイデアを信じている能なしをね。」私は質問者に幸運を祈り、公開討論会を続けました。 討論会の後、その質問者がやって来て、ビットコインデリバティブの取引所をやりたいのだと言いました。そのとき悟ったのです。私が能なしなのだと。そして、Arthur Hayes と私はビジネスパートナーとなりました。 多額の資金を調達することなく、私たちはアルファオンラインを...