小規模なプロップトレーディング会社の注文執行が遅い:時間はどこで失われ、誰が直せるのか

執行の遅さを直せるのは、注文経路のうち時間が失われている部分を管理する当事者だ。だから最初の仕事は、その部分を突き止めることである。自社から見える各地点で注文にタイムスタンプを付ければ、最も大きな差が、誰に連絡すべきかを教えてくれる。ソフトウェア内部の遅延なら自社の開発者かエンジニアリング会社、距離ならホスティング事業者、ブローカー側の遅延ならブローカーだ。

「うちの注文執行は遅すぎる」とは、どういう意味なのか

この不満が指す問題は四通りあり、それぞれ対処すべき当事者が異なる。

• どの注文も遅い。遅延は、静かな朝でも寄り付きでもほぼ同じだ。これは、距離、ブローカーへの接続方法、注文が出ていく前に毎回自社のソフトウェアが行う遅い処理など、すべての注文が払っているコストがあることを示している
• 相場が活発になるまでは注文が速い。寄り付きやニュースのときに、遅延が跳ね上がる。注文はどこかのキューで待たされている。処理が追いつかないプログラム、メッセージ数の上限、別の処理で手一杯のマシンの後ろだ
• 注文は時間どおりに届いているのに、約定が遅い。指値注文は約定相手が現れるまで板に残り、動きの速い相場では価格が離れていく。タイムスタンプで、注文が遅れたかどうかはわかる。どの価格で取引できたかまではわからない
• 画面が遅れている。取引画面の価格が遅れると、トレーダーのクリックも遅れ、それを執行のせいにする。これはマーケットデータの問題で、このブログの別の記事で扱っている

この四つを見分けられるのは、実際の注文と、その注文が反応した価格に付いたタイムスタンプだけだ。どの日を調べるかは、トレーダーの苦情をもとに選ぶ。

自社のシステムと取引所のあいだで、ミリ秒はどこに消えているのか

注文は出ていく途中で四つの区間を通り、受付の確認はブローカーから返ってくる。取引所が注文を受理してから初めて返ってくる場合もある。

• 自社側。戦略かトレーダーが判断し、注文が組み立てられ、自社のチェックが走り、注文が送信される。遅延の原因は、送信前に行う処理、プログラムの停止、ネットワーク設定、または混み合ったマシンだ。この部分は、自社の開発者かエンジニアリング会社が変えられる
• 回線。注文は自社のサーバーからブローカーの接続ポイントまで移動する。ここでの遅延は、距離、インターネットの経路、VPN のような余分なホップによって生じる。短縮できるのは、ホスティング事業者やコロケーション事業者、またはネットワークエンジニアだ
• ブローカー。ブローカーのゲートウェイが注文を受け取り、チェックを実行し、取引所へルーティングする。遅延の原因は、ブローカー自身のシステムと、義務付けられたチェックだ。これを変えられるのはブローカーだけで、自社が選べるのは接続方法と、どのブローカーを使うかである
• 取引所。マッチングエンジンが注文を受理し、受付の確認を返す。ここで費やされる時間はわずかだ。Nasdaq は、高速な 10G のコロケーションネットワークで、注文から受付確認までの往復が50マイクロ秒未満だとしている。この部分は、誰を雇っても変えられない。できるのは、近づくことだけだ

米国では、ブローカーのチェックは任意ではない。SEC Rule 15c3-5 は、マーケットアクセスを持つブローカーに対し、「あらかじめ設定された適切な与信または資本の上限を超える注文の入力を防止」し、「適切な価格または数量のパラメータを超える」注文を拒否することを求めている。同じ規則は、これらの管理を「ブローカーまたはディーラーの直接かつ排他的な管理下」に置いている。チェックにどれくらい時間がかかるかをブローカーに尋ねることはできるが、規則上、ブローカーがそれを無効にすることはできない。

時間がどこで失われているかは、どうすればわかるのか

すべての注文について、四つのタイムスタンプを記録する:

• 判断:戦略またはトレーダーが送信を決めた時点
• 送信:注文が自社のサーバーを出た時点
• 受付:注文を受け付けたというブローカーの確認が、自社のサーバーに届いた時点
• 約定:約定の通知が届いた時点

判断から送信までは、自社のソフトウェアの領分だ。送信から受付までは回線とブローカーの往復で、ブローカーが取引所の受理を待つ場合は取引所の分も加わる。どちらの方式かはブローカーに確認すること。板に残っている注文の場合、受付から約定までの時間は、ほとんどが相場によるものだ。

もう一つ数字を計測する。自社のサーバーからブローカーの接続ポイントまでのネットワークの往復時間だ。送信から受付までのうち、どれだけが回線によるものかがわかる。

FIX は、FIX Trading Community が管理するトレーディング向けのメッセージ標準だ。FIX で接続している場合、ブローカーのメッセージには二つのタイムスタンプが入っている。メッセージが送信された時刻と、メッセージが報告するイベントが起きた時刻である。FIX の仕様ではこれらのフィールドを SendingTime と TransactTime と呼び、それぞれを誰の時計が設定しているかはブローカーに聞けばわかる。自社のタイムスタンプと並べれば、往復のどの部分がどちらの側で起きたのかがわかる。

自社のタイムスタンプとブローカーのタイムスタンプを比較できるのは、両方の時計が正確な場合だけだ。FINRA Rule 6820 は、Consolidated Audit Trail に報告するブローカー・ディーラーに対し、業務用の時計を NIST の原子時計との差50ミリ秒以内に保つことを求めている。EU の規則では、高頻度アルゴリズム取引を行う取引施設の参加者は、時計を UTC との差100マイクロ秒以内に保たなければならない。50ミリ秒のずれが許される時計では、数ミリ秒の遅延がどこで生じているかを突き止められない。

送信と受付はどちらも自社の時計で読むので、その間の時間には時刻同期が要らない。まずここから始める。その往復が短いのに注文がまだ遅く感じられるなら、自社のソフトウェアを調べる。長いなら、まず応答が届いたときにプログラムが停止していたり忙しかったりしなかったかを確認する。そうでなければ、時間は自社のソフトウェアの外で費やされている。

次に、最も遅い注文を見る。1週間分の注文を往復時間で並べ替え、100件に1件しか超えない時間を書き留める。寄り付き直後の数分間と、予定されたニュースの前後についても同じことをする。平均は、トレーダーが不満を訴える瞬間を覆い隠してしまう。

小規模なプロップファームで、執行を遅くしうるものは何か

まず、次の六つの原因を確認する。

• ブローカーの API が、自分で動かさなければならないプログラムを経由している。たとえば Interactive Brokers は、自社の TWS API を「Trader Workstation または IB Gateway への接続」に基づくものと説明しており、すべての注文はまずこのどちらかのプログラムを通る。ドキュメントはクライアント接続ごとに「毎秒50リクエスト」というデフォルトの上限を定め、場合によってはそのレートを超えると「一部の注文がキューに入り、遅延することがある」と警告している。その場合について、Interactive Brokers は FIX API への切り替えを勧めている。これがボトルネックなら、ほかにどんな接続方法があるかをブローカーに尋ねる
• サーバーが注文の行き先から遠い。オフィスのマシンや遠いクラウドリージョンは、すべての注文で行きと帰りの2回、距離の代償を払い、コードをどう変えてもそれは消えない。最短距離のために、Nasdaq は顧客に「サーバーと機器を Nasdaq のデータセンター内にコロケーションする」機会を提供している。コロケーションに費用をかける前に、自社のサーバーからブローカーの接続ポイントまでのネットワークの往復時間を計測する
• 注文の送信前に遅い処理が走っている。注文をデータベースに書き込むこと、ログの1行がディスクに届くのを待つこと、取引が許可されるかを別のサービスに問い合わせることは、どの注文にも待ち時間を加える。データベースやディスクが混んでいると、待ち時間は伸びる。注文に必要なものはメモリに置き、記録は注文が出たあとに書き込む
• ネットワーク設定が小さなメッセージを引き留めている。注文は小さなメッセージだ。Linux のマニュアルによれば、TCP_NODELAY というソケットオプションを設定しない限り、送信データは「送り出すのに十分な量がたまるまで」バッファリングされる。設定されているかどうかは、自社の開発者が確認できる
• プログラムが停止する。ガベージコレクタの中には、メモリを片付けるあいだプログラム全体を止めるものがある。作業の大半をプログラムの実行中に行う Go のガベージコレクタにも「短い stop-the-world の停止」があり、Go のガベージコレクタのガイドは、これをレイテンシの発生源の候補に挙げている。注文を送り出している最中に停止が起きれば、注文の出発は遅れる。同じマシンでチャート、バックテスト、レポートを動かしていても、注文がプロセッサを待つことになるため、同じような影響が出る
• ブローカー自身の経路が遅い。ブローカーのゲートウェイ、チェック、ルーティングはすべての注文の経路上にあり、その中は外から見えない。尋ねられるのは、接続ポイントがどこにあるか、どんな接続方式を提供しているか、自社のアカウントにどのメッセージ上限が適用されるか、自社の注文についてブローカー側のタイムスタンプを共有してもらえるか、である

それぞれの原因はどう直し、作業の規模はどれくらいになるのか

• どの注文でも判断から送信までが長い場合。遅い処理を注文経路から外し、ネットワーク設定を確認する。作業は自社コードの変更で、設定一つで済むこともある
• 混雑時に判断から送信までが跳ね上がる場合。注文が何を待っているのかを突き止める。停止、キュー、共有しているマシンなどだ。作業はコードかホスティングの変更で、設計そのものがキューを生んでいるなら注文経路の作り直しになる
• どの注文でも送信から受付までが長い場合。サーバーをブローカーの接続ポイントの近くに移すか、接続方式を変える。ホスティング契約と移設、あるいは新しい接続のための統合作業が必要になると考えておく
• 取引量が増えると送信から受付までが跳ね上がる場合。ブローカー側か自社の接続のどちらかで、突き当たっている上限を見つける。ブローカーと話すだけで済むこともあれば、自社側から送るメッセージを減らすだけで済むこともある
• 受付から約定までが長い場合。注文の種類と相場を確認する。これはエンジニアリングの仕事ではない

確認できた原因のうち、最も安く直せるものから直し、作り直しは最後に回す。誰も注文の時間を計測していないうちに、システムを書き直したりブローカーを乗り換えたりしてはならない。遅延は別の場所にあるかもしれないからだ。

注文執行の遅さを直すには、誰に頼めばよいのか

誰が助けになるかは、時間がどこで費やされているかによって決まる。

• 利用しているブローカー。自分の側を見て変えられる唯一の当事者だ。自社の注文についてのブローカー側のタイムスタンプ、上限、接続方法の選択肢を尋ねる
• ホスティング事業者やコロケーション事業者、または取引所の接続サービス部門。ブローカーや取引所の接続ポイントの近くにスペースを貸し、そこまでのネットワーク回線を販売する
• ライセンスを受けたトレーディングプラットフォームを通じて取引しているなら、そのベンダー。内部を変えられるのはベンダーだけなので、タイムスタンプを持って相談する
• トレーディングシステムを手がけるエンジニアリング会社。経路全体を計測したうえで、注文経路、リスクチェック、ブローカーへの接続など、自社側の部分を変更するか作り直す
• 自社の開発者（いる場合）。四つのタイムスタンプがあれば、有能な開発者なら経路の自社側にあるあらゆる原因を確認できる

誰に依頼するにしても、まず次の四つを尋ねる:

• 修正を提案する前に計測するか。具体的に何にタイムスタンプを付けるのか
• レポートは、自社側、回線、ブローカーを分けて示し、平均だけでなく最も遅い注文も示すか
• 提示する数字はどれも、どのパーセンタイルで、どの程度の負荷のもとで、いつの日付のものか
• 遅延がブローカー側にあるとわかったら、何を伝えてくれるのか

最後の質問への答えがそれでもシステムの作り直しなら、ほかの相手を探し続けること。

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

amBrain は、アルメニア・エレバンを拠点に、Rust で低レイテンシのトレーディングプラットフォーム、マッチングエンジン、リアルタイムビディングシステムを構築するソフトウェアエンジニアリング企業である。amBrain は、トレーディング、ベッティング、アドテクの遅いシステムを診断する。稼働中のプラットフォームをエンドツーエンドで計測し、時間がどこで費やされているかをレポートで特定する。

amBrain はアルゴリズム取引の基盤を構築する。注文執行、マーケットデータ、プレトレードのリスク管理である。トレーディング分野の仕事には、トレーディングターミナルの開発、注文管理システム、FIX プロトコルによる取引所連携が含まれる。amBrain は、別のチームのもとで停滞したプロジェクトを引き継ぎ、本番稼働まで持っていく。三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。

まだ始めたばかりなら、普段の日と忙しい日に四つのタイムスタンプを記録する。それを、amBrain でもほかの誰でも、相談する相手のところへ持っていけば、最初の打ち合わせを、時間がどこで費やされているかという点から始められる。

よくある質問

• システムを Rust で書き直せば、執行は速くなるのか。速くなるのは、時間が自社のソフトウェアの内部で失われている場合だけで、それも注文が通る部分に限られる。Rust は「ガベージコレクタを必要とせずに」メモリ安全性を保証するので、ガベージコレクションによる停止という原因はなくなる。混み合ったマシン、距離、ブローカーについては何も変わらない
• コードを変えずに計測できるか。システムがすでに送信した注文と受け取った確認を時刻付きでログに残していれば、できる。送信から受付までの往復は、そのログに記録されている
• 執行が速くなれば、よりよい価格で約定できるのか。それは誰にも約束できない。速さが縮めるのは判断から注文到着までの時間であり、実際に得られる価格は、流動性、注文の種類、その間の相場の動きにも左右される