TWIMEの開発の歴史-モスクワ取引所の新しい高速インターフェース

このハブでは、モスクワ取引所向けの高速TWIMEインターフェースの開発における独自の経験について説明し、低レイテンシ（応答時間）が私たちにとって非常に重要である理由と、その削減方法について説明します。 結論として、モスクワ取引所が一部の分野で、たとえばNginx、VK、MailRuなどの高負荷の巨人よりも技術的である理由が少し明確になることを願っています。



高速TWIMEインターフェースとは何かを説明するには、遠くから始めなければなりません。 取引所で取引されているものは、取引手段と呼ばれます-価格があり、売買することができます。 取引手段は、たとえば、1バレルの石油、Sberbankの株式、または通貨ペアです。 デリバティブ市場-デリバティブ（デリバティブ）を取引するモスクワ取引所のセグメント-先物およびオプション。



取引所の主な機能は、取引商品の購入/販売の申請を受け付け、厳格な規則に従って申請を取引に結合し、完了した取引に関する情報を提供することです。

したがって、交換にはいくつかのタイプのインターフェースがあります。 取引インターフェースを使用すると、トランザクションを作成し、トランザクションに関する操作情報を受信できます。 取引時に最も重要なのは取引所の取引インターフェースです。 TWIMEプロトコルを実装したゲートウェイは、デリバティブ市場への新しい最速の取引インターフェースです。



取引所へのアクセスを高速化する方法についての質問に答える前に、なぜこれが必要であったかを説明します。



むかしむかし、電話で交換申請が受理されました。 アプリケーションの統合は、手動モードで行われました。 トランザクション内のアプリケーションの情報への配置からの遅延は、数秒または数分で計算されました。



現在、取引所はロシアの最高のデータセンターの光通信チャネルを介してアプリケーションを受け入れており、ミキシングは最高のハードウェアで行われます。 したがって、出願申請の時間は現在、数十マイクロ秒です。 同意して、申請を提出する時間を短縮する傾向は明らかです。



まず第一に、この必要性は取引所間の競争によって引き起こされます。 クライアントは、他の顧客に先んじて、さらにすべての取引所でラインストーンに先んじるために、できるだけ早く申請書を提出したいと考えています。 このアプローチにより、価格が変動したときに最良の価格で取引を行うことができます。 この場合、概して、アプリケーションがシステム内でどれだけ短縮されるかは重要ではありません。 主なことは、競争に先んじる時間をとることです。

交換に低遅延が必要なのはなぜですか？

取引所がアクティブなアプリケーションの本に該当する各トランザクションから収入を受け取ることは秘密ではありません。 関税はもちろん、市場や取引所によって異なりますが、スループットが大きいほど取引が多くなり、お金が稼がれるという点ですべて同じです。



時間が経つにつれて、応答はより複雑になります。 交換には、バーストのないスムーズな応答時間が必要です。 それ以外の場合は、「公正なプレイ」の原則に違反します。 あるユーザーがXマイクロ秒のアプリケーションを送信し、別のユーザーが10Xマイクロ秒のアプリケーションを送信し、遅延が取引所側で正確に発生した場合、利益を失うリスクがあり、トレーダーをひどく混乱させます。 レイテンシーの変動を0に減らすために、すべてのユーザーの応答時間をまったく同じにすることはできませんが、常にこのようなインジケーターに努力する必要があります。



応答時間の中央値は取引所にとって重要ですか？ 顧客にとって、中央値は、他の顧客の中央値と変わらない場合にのみ重要です。 それ以外の場合、重要ではありません。 取引所の構築における最新の傾向の1つは、取引所が減速するときです。 このような傾向は、マイケルルイスの悪名高い本「Flash Boys」から始まり、SEC（証券取引委員会）がこれらの遅い取引の1つを公開することを決定した2016年の夏にも続きました。







応答時間の中央値は取引所にとって重要ですか？ この質問は未解決のままです。 原則として、帯域幅、中央値、遅延のばらつきの妥協点を見つける必要があります。 たとえば、Nagleアルゴリズムを無効にすると中央値が低下しますが、スループットも低下します。 そのような例はたくさんあります。



デリバティブ市場にはどのような取引インターフェースがありますか？ これについては以前にブログで書いたので、一般的な用語でのみ繰り返します。



以前は、最速のインターフェイスはCGate APIでした。これは、単一のAPIを備えた一連のライブラリです。 CGateは、閉じられた内部交換プロトコルを介して交換機と通信します。 このインターフェイスは最速ですが、プロトコルが閉じており、ライブラリへのリンクが必要であるため、サポートされる言語とプラットフォームには自然な制限があり、多くのクライアントが望むFPGAを使用する方法はありません。



別の取引インターフェースはFIXです。 FIXプロトコルはアプリケーションを送信するための古くから実績のある標準であるため、クライアントにとって非常に便利です。 膨大な数のライブラリとFPGAソリューションが作成されています。 残念ながら、デリバティブ市場では、このインターフェイスはCGateよりもやや低速です。



そして、ほとんどの顧客は当然CGateを好みました。 新しいインターフェイスを開発しました。CGateよりも高速で、リンクを必要とせず、FPGAに適しています。開発には最先端の業界標準を使用します。その名前はTWIME（モスクワ取引所の取引ワイヤインターフェイス）です。

どのようにして応答時間を短縮できましたか？

利用可能な交換インターフェイスの綿密な分析を実施しました。 作業は2015年の夏を通して続けられました。 秋には、コアに向かって10μsのレイテンシを示す既製のプロトタイプがありました。 当時の最速のインターフェースよりも一桁高速でした。 12月までに公開テストを開始し、4月に本格的な運用を開始しました。



最速のインターフェースを開発する際、3つの側面に注目しました。

• システムアーキテクチャ、インターフェイスの概念的な変更。
• その前身から最高のものを取り出した新しいプロトコル。
• アルゴリズムは、ゲートウェイロジックの実装における特定の改善です。

建築の隅々を切り取ります。 最大の角度は、応答時間の影響を受けないいわゆる非トレーディング注文を含む、コアへのすべてのメッセージが通過する注文の共通ゲートウェイです。 このゲートウェイは、監視、認証、およびフラッド制御の機能を実行します。 その結果、TWIMEゲートウェイ内に必要な機能を実装し、過剰を投げました。 したがって、通常は共通のゲートウェイとコアが異なるボックスに配置されていたため、ネットワーク上の不要なホップを回避することができました。



1つのアドレスからTWIMEゲートウェイを介した交換への接続（TCP SYNの送信）を1秒に1回以上禁止します。 これにより、誤って作成されたクライアントアプリケーションや悪意のある攻撃の試みによる損害を減らすことができました。



新しいゲートウェイでは、数値識別子によるアプリケーションの発行を使用しています。これにより、クライアントが正しいツール識別子を取得するのが少し難しくなりますが、メッセージを減らすのに役立ちます。



新しい取引プロトコルを開発する際、さまざまな取引プラットフォームへのアクセスの統合に関心のある組織のコミュニティであるFix Communityの推奨事項を使用しました。



セッションレベルの基礎としてFIXPを採用し、プレゼンテーションレベルでSBEを使用します。一方で、アプリケーションレベルは、トレーディングシステムコアの内部メッセージフォーマットに可能な限り近いものであり、他方ではFIXセマンティクスを使用しています。 結果は、クライアントを実装するための非常にシンプルなプロトコルです。 FPGAに基づいた貿易ソリューションのメーカーから肯定的なフィードバックを受けています。



多くの交換があり、何百もの交換があります。入札者がプロトコルから動物園を維持するのは高価です。 プロトコルのシンプルさと統一により、TWIMEクライアントがより高度なハードウェアを使用し、非標準プロトコルの実装ではなく最適化に開発者の時間を費やすことができることを期待できます。



誰かがGoogle ProtoBufを使用しましたか？ 一部のテストでは、SBEはGPBと比較して数十倍の加速を示します。 SBEは、構造体へのポインタと構造体のサイズを送信システムコールに渡すことにより、「そのまま」ネットワークに送信されるC言語構造体に似ています。 したがって、シリアライゼーションとデシリアライゼーションは、コンパイル時のCスタイルのキャストです。 実際、すべてが少し複雑ですが、このアプローチの長所と短所は理解できると思います。



TWIMEの各メッセージには固定サイズがあります。 各メッセージの最初のフィールドはヘッダーのないメッセージのサイズで、2番目はメッセージタイプの識別子（構造）です。 メッセージのタイプによって、間違いなく長さを取得できますが、それは余分なスイッチであり、長い時間です。 ヘッダー内のさらに2つのフィールドは、スキーマ識別子とスキーマバージョンです。 これはすべて標準のSBEヘッダーです。 次に、ビジネスロジックの分野である価格、ツール、クライアントアカウントがあります。



バイナリコーディングを使用しているため、プロトコルはFIXよりも効率的です。 たとえば、FIXでは、ミリ秒の精度で19バイトかかりますが、TWIMEでは、ナノ秒の精度で8バイトかかります。 これは、Unix時代からのナノ秒数です。



また、交換の内部プロトコル（Plaza2）よりも効率的です。内部カーネルフィールドがないため、メッセージのサイズは平均で4倍小さくなります。







低遅延の最も重要な秘密は、クリティカルパスにロックがないことです。

OSスケジューラの1つのタイムスライス（OSプログラムに割り当てられた最小時間）の時間は通常、アプリケーションの処理時間よりも長いため、ミューテックスはクリティカルパス上の低遅延アプリケーションでは使用できません。 ミューテックスが使用されているため、クリティカルパスではメモリ割り当てを実行できません。



アフィニティおよびリアルタイムスケジューリングを使用して、コンテキストスイッチの数を最小限に抑える必要があります。 理想的には、ワーカースレッドのコンテキストスイッチをまったく持たないことが最善です。



これは一部の人にとっては当たり前のことのように思えるかもしれませんが、クリティカルパス上のミューテックスとメモリ割り当ての欠如、およびコンテキストスイッチの最小化は、低遅延アプリケーションの成功に必要な条件です。







私たちが行った最適化の1つは、ハートビートの使用です。 顧客の大部分は、1日を通して常にメッセージを送受信しています。この場合、クライアントがアクティブであり、ハートビートを必要としないことがすぐに明らかになります。 クライアントが他のメッセージがない場合にのみハートビートを送信する必要があります。



ハートビートが失われた場合のセッションブレークは、エクスチェンジのお客様にとって非常に重要です。 接続が切断された場合は、事前に交換機にすべてのアプリケーションをキャンセルするように依頼することができます。



したがって、他のインターフェイスで使用されるアルゴリズムでは、各メッセージでタイマーイベントを再登録する必要があります。 これは、リアクターのヒップからタイマーイベントを引き出し、ヒップに新しいイベントを追加する必要があることを意味します（これは、クライアントからの新しいメッセージごとに行われます！）。



新しいゲートウェイでは、他の方法で行った。 新しいユーザーが接続すると、リアクターにタイマーイベントを登録します。 クライアントからのメッセージごとに、メッセージがあったことを示すフラグが立てられます。 イベントがタイマーによってトリガーされると、フラグを確認して下げます。 フラグが立てられていない場合、クライアントはハートビートがスキップされたというエラーで切断します。



この方法では、最後のメッセージの後に特定の間隔でイベントを正確にトリガーすることはできません。 したがって、新しいゲートウェイは、最後のメッセージを受信して​​から1〜2の間隔でクライアントを切断します。 これが、ゲートウェイを高速化することにした妥協案です。



クライアントが取引所に送信する各メッセージは、実際には、保存して処理する必要がある公式文書です。 どの時点でメッセージが交換に来たと考えられますか？ メッセージは、TCP ACKによって確認された場合、技術的に交換機に到着したと見なされます。



交換機に過度の負荷がかかった場合、メッセージを使用していくつかの方法を実行できます。 それらは無視することも、正当な理由なしに拒否することもできません;それらはメモリに保存することができます。たとえば、RAMのキューに入れます。 これが、アプリケーションの一般的なゲートウェイの動作です。 メッセージを処理する最も効率的な方法ではなく、大量のメモリと余分なコピーメッセージが必要になる場合があります。



新しいゲートウェイでは、別の方法で、処理できるメッセージのみをソケットバッファーから読み取ります。 ゲートウェイの負荷が高い場合、サーバー側のTCPバッファーがブロックされ、TCP ACKメッセージがクライアントに届きなくなります。 したがって、バッファと非同期ソケットが詰まっているクライアントはEAGAINエラーを受け取り、交換に過度の負荷がかかった状況で以前のように取引を続けるか、戦略を変更する価値があるかどうかを自分で決定できます。







ゲートウェイで最も興味深いアルゴリズムの1つは、優先パケットサイズアルゴリズムです。



クライアントの1人が、超高速ハードウェアと独創的なコードを使用して、エクスチェンジがメッセージを処理するよりも速くエクスチェンジにメッセージを送信することを学んだと仮定します。これは、そのような状況でエクスチェンジが1つのクライアントのみにサービスを提供することを意味するのでしょうか？ それほど速くない入札者にとっては不誠実だからです。



以前に使用された問題の解決策には、各クライアントからのメッセージ数の追跡と、クライアント間のゲートウェイ時間の分散が含まれていました。 新しいゲートでは、より簡単なソリューションが見つかりました。 ソケットの研磨を繰り返すたびに、所定のN番目のバイト数だけを読み取ります。 したがって、クライアントの1つが1つのTCPセグメントで100メッセージを送信し、2番目が15メッセージ、3番目の5メッセージを送信し、優先パケットサイズが10メッセージである場合、最初の反復では3番目のクライアントからのメッセージのみが完全に処理されます。 最初のクライアントからのメッセージは、リアクターのポーリングを10回繰り返し、2番目の2回を繰り返します。



新しいゲートウェイで行った別の最適化は、以前のように動的な回路ではなく静的な回路を使用することです。



スキーマは、メッセージとその中のフィールドのコレクションです。 コンパイル時にメッセージフィールドが不明な場合、これは動的スキームであり、コンパイル段階でフィールドが既知の場合、静的スキームを取得します。 どちらのアプローチにもプラス面とマイナス面があります。 前者の場合、同じコードで異なるスキームを使用できます。 2番目の方法では、回路を変更するにはコードを再コンパイルする必要があります。 静的スキームにより、コンパイラは、たとえばログにメッセージを書き込むときなど、多くの追加の最適化を行うことができます。 静的回路からメッセージログに書き込むコードは、コンパイル段階でフィールドの数と種類がわかっているため、コンパイラによってインライン化される可能性が高くなります。



この資料は、モスクワ取引所のエンジニアであるニコライ・ビスコフによって作成されました。