取引が集中すると板が固まる？　マーケットデータフィードの直し方と、誰に直してもらえるか

取引が集中する局面で、取引画面の板が固まる、飛ぶ、あるいはありえない価格を表示するなら、原因はたいてい三つの場所のどれかにある。取引所のフィードが入ってくるところで更新が失われているか、板の組み立てが間違っているか、数百の画面に板が届くのが遅すぎるかだ。誰かに依頼する前に最も混雑した1時間を計測し、そのうえで、検討するすべての会社をその日の記録でテストする。

壊れたマーケットデータフィードは、画面上でどう見えるのか

症状が出るのは、中央銀行の発表や寄り付きのような、最も取引が集中する瞬間だ。画面の板が1〜2秒止まり、それから飛ぶ。取り消された注文が表示されたまま残る。買い手が付けている最も高い価格が、売り手が付けている最も低い価格を上回ることもある。これを交差した板と呼ぶ。単一の取引所では、寄り付きと引けのオークションの時間帯を除けば、そうした注文はすぐに約定するはずだ。だから、単一の取引所の板が画面上で交差しているなら、自社が持っているその板のコピーが間違っているということになる。

やがてサポートには、同じ銘柄で違う板を見ている二人のトレーダーからスクリーンショットが届く。あるいは、画面には別の価格が表示されていたとして、トレーダーが注文の約定価格に異議を唱える。

なぜ更新は失われたり、順番どおりに届かなかったりするのか

取引所の板のフィードは、小さな変更の流れだ:注文の追加、注文の取消、約定。自社のシステムは、スナップショットと呼ばれる板の完全なコピーから始め、変更を順番に適用していく。変更にはそれぞれ番号が振られているので、欠けたものがあれば見つけられる。Nasdaq は TotalView-ITCH 5.0 フィードの仕様書で、このフィードは「順序付けられた一連のメッセージで構成される」、つまり順番に番号が振られていると述べている。

取引が集中する局面では、変更の流れが急増する。その一部は途中や自社のサーバーの内部で失われ、一部は順番どおりに届かない。システムがギャップを見逃せば、届いたものを何でも適用し、もう取引所と一致しない板を表示する。ギャップに気づいても復旧に数秒かかれば、画面は止まったままになる。

取引所は、クライアントが更新を失うことを前提にしている。CME Group は MDP 3.0 フィードのドキュメントで、ギャップのあとは「クライアントのシステムで保持しているすべての板が、もはや正しい最新の状態ではない可能性があると想定すべきである」と述べている。

フィードはシステムのどこで壊れるのか

場所は三つあり、それぞれに別の直し方が必要だ。三つ目をエンジニアはファンアウトと呼ぶ。一つの更新の流れが、扇状に多くの画面へ広がるからだ。上でリンクした技術記事が、三つすべてを詳しく扱っている。

一つ目の場所は取り込み口、つまり取引所のフィードが届くところだ。失われたデータを取り戻す手段を用意している取引所もある。Nasdaq の配信プロトコルの一つである MoldUDP64 では、受信側が「取りこぼしたパケットを検出し、再要求する」ことができる。CME は A と B と呼ばれる二つの回線で同じストリームを二重に送り、板を最新の状態に戻すためのスナップショットのフィードを別に用意している。だが、システムがギャップに気づかなければ、どれも役に立たない。

次に板が組み立てられる。ここでの危険は、変更が二重に適用されること、順番を外れて適用されること、あるいは間違ったスナップショットの上に適用されることだ。暗号資産取引所の Binance は、スナップショットをライブのストリームにつなぐための正確な手順をガイドに示している。その手順を踏まずに組み立てた板も、価格を表示し、問題なく見える。だが、その価格は間違っている。

最後がファンアウトで、ここで板は、接続している画面ごとに一つずつ、数百のトレーダーのセッションへ送り出される。弱いモバイル回線につながったトレーダーや、止まってしまったターミナルは、更新をゆっくりとしか読まない。サーバーがそのセッションを待てば、ほかのすべてのセッションも待たされる。そのセッション向けにたまっていく更新を際限なく積み上げさせるのも、解決にはならない。サーバーのメモリが尽き、全員にとっての障害になるからだ。

よくできたシステムでは、サーバーが更新を一度だけ順番に並べ、同じ結果をすべてのセッションに送る。遅れたセッションは、途中の段階を飛ばして板の最新の姿を受け取るか、サーバーが理由を添えて接続を切り、画面が新しいコピーを取って再接続するかのどちらかになる。フィードは、複数の場所で同時に壊れることもある。

誰かに依頼する前に、何を計測すべきか

過去1か月で最も混雑した1時間を選び、その1時間について次の数字を集める:

• ギャップ:取引所のフィードごとに、システムが欠けた更新番号を見つけた回数。システムがそれを数えていないなら、それが最初の発見になる
• 復旧時間:再構築のそれぞれにどれだけかかり、そのあいだトレーダーに何が見えていたか
• 遅延:メッセージに付いた取引所のタイムスタンプから、更新が自社のサーバーを出てトレーダーへ向かう瞬間までの時間。いくつかのテスト用ターミナルでは、画面に表示されるまでの時間も測る。中央値と99パーセンタイル、つまり100件の更新のうち99件がそれを下回る時間を取る。サーバーの時計は正確な時刻源と同期させておく。そうでなければ、数字に意味はない
• セッション:いくつのセッションがどれだけ遅れたか、そしていくつが切断されたか。それぞれの理由も添えて

次に、混雑した1日の生のフィードを、届いたとおりに、各パケットの到着時刻とともに記録する。その記録を実際の速度とそれより速い速度で再生することが、候補リストのすべての会社に課すテストになり、修正のたびに繰り返すテストにもなる。

自社のハンドラを直すか、買うか、ファンアウトを作り直すか

取引所のフィードを取り込み、板を維持するソフトウェアをフィードハンドラと呼ぶ。道は三つあり、どれを選ぶべきかは計測が示すはずだ。後ろの二つは組み合わせることもできる。

自社のフィードハンドラを直すのが理にかなうのはどんなときか

見逃されるギャップや遅い再構築のように、計測が一つのはっきりした欠陥を指していて、コードを知っている人がまだ社内にいるなら、今あるフィードハンドラを直す。

• 向いているケース:欠陥を名指しでき、それ以外の設計は機能している
• コスト:開発の時間と、記録したフィードを再生するテスト環境
• コードの所有者:自社
• 限界:問題が板を画面に送る部分にあるなら、取り込み口を直しても役に立たない

フィードハンドラやマネージドフィードを買うべきなのはどんなときか

既製のフィードハンドラとは、取引所に接続し、ギャップを捉え、正しい最新の板を自社のシステムに渡すライセンス型のソフトウェアだ。マネージドフィードはさらに先まで担う:マーケットデータのベンダーが各取引所に接続し、自社はそのベンダーから一つの形式の一つのストリームを受け取る。

• 向いているケース:標準的な形式の取引所が多数あり、各取引所がフィードに加える変更をいちいち追いかけたくない
• コスト:ライセンス料と、製品を自社のシステムにつなぐ作業。誰がデータを配信するにしても、取引所自身のデータ料金とライセンス条件は、たいてい引き続き適用される
• 自社に残る仕事:数百のトレーダーの画面に板を届けることと、遅いセッションへの対処
• コードの所有者:製品を所有するのはベンダー。連携部分と、そこから先のすべては自社が所有する

ファンアウトの作り直しをチームに依頼すべきなのはどんなときか

取り込み口は機能しているのに問題が続くなら、トレーダーにデータを送る層を作り直す。トレーダーごとに違う板が見え続けている、遅いセッション一つがほかを道連れにしている、あるいは今よりずっと多くのセッションに配信する計画がある、といった場合だ。

• 向いているケース:遅延が、取引所と自社のサーバーのあいだではなく、自社のサーバーと画面のあいだで増えている
• コスト:開発とテストの時間、そしてローンチ後にシステムを運用する人員
• コードの所有者:契約にそう明記されていれば自社

依頼する前に、会社をどう確かめるか

候補リストのすべての会社に、同じ五つのテストを課す:

• 記録したフィードの再生。実際の速度と、その数倍の速度で、相手の会社が納品するもの、あるいはデモするものに流す。ギャップ、再構築、復旧時間、遅延を、現在のシステムのものと比べる
• ギャップをどう捉えるか。良い答えは、システムが変更を適用するのは、その番号が次に期待される番号であるときだけだ、というものだ。番号が欠けていれば、システムは少し待ち、それから変更を再要求するか、板を再構築する。それまでは、板が最新ではないことを示す印を付けておく。そのあいだトレーダーに何が見えるのかを尋ねる
• 一人の遅いトレーダーに何が起きるか。再生中に一つのセッションをわざと遅くしてもらう。ほかのセッションの遅延が変わってはならない
• 遅延をどう計測するか:どのタイムスタンプからどの地点まで、どのパーセンタイルで、どの負荷とハードウェアで測るのか、そして時計をどう同期させているのか
• コードを誰が所有するのか、そして会社が自社のものとして手元に残す部分を、どんな条件で使えるのか

危険信号は何か

• 誰も計測値を見ないうちに、最初の答えとして「サーバーを増やします」が出てくる
• 「信頼性の高い接続を使っているので、何も失われません。」Binance は、転送中にデータを失わない接続方式である WebSocket で更新を送っているが、それでも同社のガイドは、イベントが抜け落ちたときにクライアントがどうすべきかを説明している

amBrain はどこに位置づけられるか

amBrain はアルゴリズム取引の基盤を構築する:注文執行、マーケットデータ、プレトレードのリスク管理。

amBrain のウェブサイトには、こう書かれた一行がある:「トレーディングターミナルの開発、注文管理システム、FIX プロトコルによる取引所連携。」

amBrain は、トレーディングとアドテクの遅いシステムを診断する。稼働中のプラットフォームをエンドツーエンドで計測し、時間がどこで費やされているかをレポートで特定する。

amBrain は2019年からソフトウェアを作っている。チームについては一行でこう説明している:「最大40人のチームで、その約75%がシニア。」働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。顧客は、amBrain の再利用可能なコンポーネントを除き、プロダクトとコードの完全な所有権を保持する。

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。amBrain が構築したどのシステムについてもレイテンシの数字を挙げず、価格や期間も示さない。

amBrain が候補リストに入っているなら、ほかのすべての会社と同じ五つの質問を amBrain にも投げかけ、合意するどの仕事についても、自社で記録したフィードを合格基準にする。

よくある質問

• サーバーを増やせば直るのか。それだけでは直らない。システムが変更を順番どおりに適用しない、あるいは最も遅いセッションを待ってしまうなら、サーバーを増やしても同じ欠陥が繰り返されるだけだ。サーバーを足すのは、今のサーバーの容量が尽きかけていることを計測が示してからにする
• 更新をまとめて、送る数を減らせるか。板については、できる。エンジニアはこれをコンフレーションと呼び、取引所自身が行っていることもある。Binance のドキュメントは、現物の板の変化を流すストリームの更新速度を 1000 ms または 100 ms と定めている。このストリームが示すのは最新の姿であって、途中の一歩一歩ではないことをトレーダーに伝えておく。約定や注文の確認はまとめてはいけない。一つでも落とすと、取引履歴が誤ったものになるからだ
• Rust や C++ で書き直さなければならないのか。必ずしもそうではない。見逃されるギャップや、最も遅いセッションを待ってしまうサーバーは設計上の欠陥であり、言語を変えても消えない。Rust と C++ にはガベージコレクタ、つまり Java や Go などの言語で書かれたプログラムを一時停止させることがある自動のメモリ回収の仕組みがない。これは、すべての更新を扱う部分で役に立つ。言語が何であれ、ピーク時に計測した遅延を求める
• 修正にはどれくらいの期間がかかるのか。欠陥がどこにあるか、そして取引所とセッションの数による。各社に、計測と、記録したフィードを再生するテスト環境までを含む第1フェーズの見積もりとスケジュールを出してもらう。上の五つのテストを合格基準にする