モスクワ取引所の取引および清算システムのアーキテクチャの進化。 パート2

これは、Exchange の動作を保証する強力で高負荷のシステムを作成するための、私たちの茨の道についての長い物語の続きです。 最初の部分はここにあります: habr.com/ru/post/444300

謎のエラー

数多くのテストを経て、更新された取引および清算システムが稼働しました。そして、推理小説を書くことができるようなバグに遭遇しました。

メイン サーバーで起動した直後、トランザクションの 2 つがエラーで処理されました。 ただし、バックアップ サーバーではすべて問題ありませんでした。 メイン サーバー上で指数を計算する単純な数学的操作により、実際の引数から負の結果が得られることが判明しました。 研究を続けたところ、SSEXNUMX レジスタで、浮動小数点数を扱う際の丸めの原因となる XNUMX ビットの違いが見つかりました。

丸めビットを設定して指数を計算する簡単なテスト ユーティリティを作成しました。 私たちが使用した RedHat Linux のバージョンでは、不運なビットが挿入されたときの数学関数の操作にバグがあることが判明しました。 私たちはこれを RedHat に報告し、しばらくしてからパッチを受け取り、公開しました。 エラーは発生しなくなりましたが、このビットがどこから来たのかさえ不明でした。 関数がそれを担当しました fesetround 私たちは、想定されるエラーを探すためにコードを慎重に分析し、考えられるすべての状況をチェックしました。 丸めを使用するすべての関数を調べました。 失敗したセッションを再現しようとしました。 異なるオプションを備えた異なるコンパイラを使用しました。 静的解析と動的解析が使用されました。

エラーの原因が見つかりませんでした。

次に、ハードウェアのチェックを開始しました。プロセッサの負荷テストを実行しました。 RAMをチェックしました。 XNUMX つのセルでマルチビット エラーが発生するという非常にありそうもないシナリオのテストも実行しました。 無駄に。

最終的に、私たちは高エネルギー物理学の世界からの理論に落ち着きました。つまり、高エネルギー粒子がデータセンターに飛来し、ケースの壁を突き破ってプロセッサーに衝突し、トリガーラッチがまさにその部分に刺さったのです。 この不合理な理論は「ニュートリノ」と呼ばれました。 素粒子物理学から遠く離れている場合は、ニュートリノは外界とほとんど相互作用せず、プロセッサの動作に影響を与えることはできません。

障害の原因を特定できなかったため、念のため「問題のある」サーバーは運用から削除されました。

しばらくして、私たちはホット バックアップ システムの改善を開始しました。いわゆる「ウォーム リザーブ」(ウォーム)、つまり非同期レプリカを導入しました。 異なるデータセンターにある可能性のある一連のトランザクションを受信しましたが、ウォームは他のサーバーと積極的に対話しませんでした。

なぜこれが行われたのでしょうか? バックアップ サーバーに障害が発生した場合、メイン サーバーにウォーム接続されたサーバーが新しいバックアップになります。 つまり、障害発生後、システムは取引セッションが終了するまで XNUMX つのメイン サーバーに留まりません。

そして、新しいバージョンのシステムがテストされ、運用されると、丸めビット エラーが再び発生しました。 さらに、ウォーム サーバーの数が増加すると、エラーが頻繁に発生するようになりました。 同時に、具体的な証拠がなかったため、ベンダーは何も示すことができませんでした。

次に状況を分析したところ、問題は OS に関連している可能性があるという理論が浮上しました。 無限ループで関数を呼び出す単純なプログラムを作成しました。 fesetround、現在の状態を記憶し、スリープを通じて確認します。これは多くの競合スレッドで行われます。 スリープとスレッド数のパラメーターを選択した後、ユーティリティを実行してから約 5 分後にビット障害を一貫して再現し始めました。 ただし、Red Hat サポートはそれを再現できませんでした。 他のサーバーをテストしたところ、特定のプロセッサを搭載したサーバーのみがエラーの影響を受けやすいことが判明しました。 同時に、新しいカーネルに切り替えることで問題は解決されました。 結局OSを入れ替えただけで、バグの本当の原因は不明のままでした。

そして昨年突然、ハブレに記事が掲載されました。Intel Skylake プロセッサのバグを見つけた方法」 そこに記載されている状況は私たちの状況と非常に似ていましたが、著者はさらに調査を進め、エラーはマイクロコードにあるという理論を提唱しました。 また、Linux カーネルが更新されると、メーカーはマイクロコードも更新します。

システムの更なる発展

エラーは解消されましたが、この話によりシステム アーキテクチャを再考する必要がありました。 結局のところ、私たちはそのようなバグの繰り返しから守られていませんでした。

次の原則は、予約システムの次の改善の基礎となりました。

• 誰も信用することはできません。 サーバーが正しく機能しない可能性があります。
• 多数予約。
• コンセンサスの確保。 過半数の予約への論理的な追加として。
• 二重の失敗が発生する可能性があります。
• 活力。 新しいホット スタンバイ スキームは、以前のスキームよりも劣るものではありません。 取引は最後のサーバーまで中断されることなく続行されます。
• 遅延がわずかに増加します。 ダウンタイムが発生すると、多大な経済的損失が発生します。
• ネットワークの相互作用を最小限に抑え、遅延を可能な限り低く保ちます。
• 新しいマスターサーバーを数秒で選択します。

市場で入手可能なソリューションはどれも私たちには合わず、Raft プロトコルはまだ初期段階にあったため、独自のソリューションを作成しました。

ネットワーキング

予約システムに加えて、ネットワーク インタラクションの最新化も開始しました。 I/O サブシステムは多くのプロセスで構成されており、ジッターと遅延に最も大きな影響を与えました。 何百ものプロセスが TCP 接続を処理するため、それらを常に切り替える必要があり、マイクロ秒スケールではかなり時間のかかる操作です。 しかし、最悪の部分は、プロセスが処理するパケットを受信したときに、それを XNUMX つの SystemV キューに送信し、別の SystemV キューからのイベントを待機することです。 ただし、ノードの数が多い場合、あるプロセスでの新しい TCP パケットの到着と、別のプロセスでのキュー内のデータの受信は、OS にとって XNUMX つの競合するイベントを表します。 この場合、両方のタスクに使用できる物理プロセッサがない場合は、XNUMX つが処理され、XNUMX つ目は待機キューに入れられます。 結果を予測することは不可能です。

このような状況では、動的なプロセス優先度制御を使用できますが、これにはリソースを大量に消費するシステム コールを使用する必要があります。 その結果、クラシック epoll を使用する 8 つのスレッドに切り替えました。これにより、速度が大幅に向上し、トランザクション処理時間が短縮されました。 また、個別のネットワーク通信プロセスと SystemV を介した通信を廃止し、システム コールの数を大幅に削減し、操作の優先順位を制御するようになりました。 I/O サブシステムだけで、シナリオに応じて約 17 ～ XNUMX マイクロ秒を節約できました。 このシングル スレッド スキームはそれ以来変更されずに使用されており、マージンのある XNUMX つの epoll スレッドですべての接続を処理するには十分です。

トランザクション処理

システムの負荷が増大するため、ほぼすべてのコンポーネントをアップグレードする必要がありました。 しかし、残念なことに、近年のプロセッサのクロック速度の成長の停滞により、プロセスを正面から拡張することはもはや不可能になっています。 したがって、エンジンのプロセスを XNUMX つのレベルに分割し、その中で最も忙しいのは、口座内の資金の利用可能性を評価し、トランザクション自体を作成するリスク チェック システムであると決定しました。 しかし、お金は異なる通貨で使用される可能性があるため、リクエストの処理をどのような基準で分割する必要があるかを把握する必要がありました。

論理的な解決策は、通貨ごとに分割することです。XNUMX つのサーバーはドルで取引され、もう XNUMX つはポンドで取引され、XNUMX 番目のサーバーはユーロで取引されます。 しかし、このようなスキームでは、異なる通貨を購入するために XNUMX つのトランザクションが送信されると、ウォレットの非同期の問題が発生します。 しかし、同期は難しく、コストがかかります。 したがって、ウォレットごと、楽器ごとに別々にシャーディングするのが正しいでしょう。 ちなみに、ほとんどの西側取引所には当社ほどリスクを厳密にチェックするタスクがないため、ほとんどの場合、これはオフラインで行われます。 オンライン認証を実装する必要がありました。

例を挙げて説明しましょう。 トレーダーが 30 ドルを購入したいとすると、リクエストはトランザクション検証に進みます。このトレーダーがこの取引モードを許可されているかどうか、また必要な権利があるかどうかが確認されます。 すべてが正常であれば、リクエストはリスク検証システムに送られます。 取引を完了するための資金が十分であることを確認するため。 必要な量が現在ブロックされているというメモがあります。 その後、リクエストは取引システムに転送され、取引システムが取引を承認または不承認します。 取引が承認されたとします。その後、リスク検証システムによって資金のブロックが解除されたことがマークされ、ルーブルがドルに変わります。

一般に、リスク チェック システムには複雑なアルゴリズムが含まれており、リソースを大量に消費する計算が大量に実行されます。一見すると「口座残高」をチェックするだけではありません。

エンジン プロセスをレベルに分割し始めたとき、問題が発生しました。当時利用可能だったコードは、検証段階と検証段階で同じデータ配列を積極的に使用しており、コード ベース全体を書き直す必要がありました。 その結果、私たちは最新のプロセッサーから命令を処理するための技術を借用しました。つまり、各命令が小さなステージに分割され、XNUMX サイクルで複数のアクションが並行して実行されます。

コードを少し修正した後、並列トランザクション処理用のパイプラインを作成しました。このパイプラインでは、トランザクションがネットワークの対話、検証、実行、結果の公開という 4 つのパイプライン段階に分割されていました。

例を見てみましょう。 シリアルとパラレルの XNUMX つの処理システムがあります。 最初のトランザクションが到着し、両方のシステムで検証のために送信されます。 XNUMX 番目のトランザクションはすぐに到着します。並列システムでは、トランザクションはすぐに実行されますが、順次システムでは、最初のトランザクションが現在の処理段階を通過するのを待つキューに入れられます。 つまり、パイプライン処理の主な利点は、トランザクション キューをより高速に処理できることです。

これがASTS+システムを思いついた方法です。

確かに、コンベヤーもすべてがそれほどスムーズであるわけではありません。 隣接するトランザクションのデータ配列に影響を与えるトランザクションがあるとします。これは交換の典型的な状況です。 このようなトランザクションは他のトランザクションに影響を与える可能性があるため、パイプラインでは実行できません。 この状況はデータ ハザードと呼ばれ、そのようなトランザクションは単純に個別に処理されます。キュー内の「高速」トランザクションがなくなるとパイプラインが停止し、システムは「低速」トランザクションを処理してから、パイプラインを再開します。 幸いなことに、フロー全体に占めるこのようなトランザクションの割合は非常に小さいため、パイプラインが停止することはめったになく、全体的なパフォーマンスには影響しません。

次に、XNUMX つの実行スレッドを同期するという問題の解決に取り組みました。 その結果、固定サイズのセルを備えたリング バッファーに基づくシステムが誕生しました。 このシステムでは、すべてが処理速度に依存し、データはコピーされません。

• すべての受信ネットワーク パケットは割り当て段階に入ります。
• それらを配列に配置し、ステージ #1 で使用可能としてマークします。
• 1 番目のトランザクションが到着し、再びステージ No. XNUMX で使用できるようになります。
• 最初の処理スレッドは、使用可能なトランザクションを確認して処理し、XNUMX 番目の処理スレッドの次のステージに移動します。
• 次に、最初のトランザクションを処理し、対応するセルにフラグを立てます。 deleted — 新たに使用できるようになりました。

キュー全体がこの方法で処理されます。

各段階の処理には単位または数十マイクロ秒かかります。 また、標準の OS 同期スキームを使用すると、同期自体にさらに多くの時間を費やすことになります。 それが私たちがスピンロックを使い始めた理由です。 ただし、これはリアルタイム システムでは非常に悪い形式であり、RedHat はこれを行うことを厳密に推奨していません。そのため、100 ミリ秒のスピンロックを適用し、その後セマフォ モードに切り替えてデッドロックの可能性を排除します。

その結果、8 秒あたり約 XNUMX 万トランザクションのパフォーマンスを達成しました。 そして文字通りXNUMXか月後、 статье LMAX Disruptor については、同じ機能を持つ回路の説明を参照しました。

18 つのステージで複数のスレッドが実行される可能性があります。 すべてのトランザクションは、受信した順序で 50 つずつ処理されました。 その結果、ピーク パフォーマンスは XNUMX 秒あたり XNUMX トランザクションから XNUMX トランザクションに増加しました。

為替リスク管理体制

完璧には限界がないため、すぐに私たちは再び近代化を開始しました。ASTS+ の枠組みの中で、リスク管理と決済システムを自律的なコンポーネントに移行し始めました。 私たちは柔軟な最新アーキテクチャと新しい階層型リスク モデルを開発し、可能な限りクラスを使用するように努めました。 fixed_point 代わりに double.

しかし、すぐに問題が生じました。長年稼働してきたすべてのビジネス ロジックをどのように同期して、新しいシステムに移行するかということです。 その結果、新しいシステムのプロトタイプの最初のバージョンは放棄されなければなりませんでした。 現在実稼働環境で動作している XNUMX 番目のバージョンは、トレーディング部分とリスク部分の両方で動作する同じコードに基づいています。 開発中に最も困難だったのは、XNUMX つのバージョン間の git merge でした。 私たちの同僚エフゲニー・マズレノクはこの手術を毎週行い、そのたびに彼は非常に長い間罵倒しました。

新しいシステムを選択する際には、インタラクションの問題を直ちに解決する必要がありました。 データ バスを選択するときは、安定したジッターと最小限の遅延を確保する必要がありました。 InfiniBand RDMA ネットワークはこれに最適でした。平均処理時間は 4 G イーサネット ネットワークの 10 分の 99 です。 しかし、私たちを本当に魅了したのは、99,9 と XNUMX というパーセンタイルの違いでした。

もちろん、InfiniBand には課題もあります。 まず、別の API - ソケットではなく ibverbs です。 第二に、広く利用できるオープンソースのメッセージング ソリューションはほとんどありません。 私たちは独自のプロトタイプを作成しようとしましたが、非常に難しいことが判明したため、商用ソリューションである Confinity Low Latency Messaging (旧 IBM MQ LLM) を選択しました。

そこで、リスクシステムを適切に分割するという課題が生じました。 リスク エンジンを単に削除し、中間ノードを作成しない場合は、XNUMX つのソースからのトランザクションが混在する可能性があります。

いわゆる超低遅延ソリューションには並べ替えモードがあり、XNUMX つのソースからのトランザクションを受信時に必要な順序に並べることができ、これは注文に関する情報を交換するための別のチャネルを使用して実装されます。 しかし、このモードはまだ使用していません。このモードはプロセス全体を複雑にし、多くのソリューションではまったくサポートされていません。 さらに、各トランザクションには対応するタイムスタンプを割り当てる必要があり、私たちのスキームではこのメカニズムを正しく実装するのが非常に困難です。 したがって、メッセージ ブローカー、つまりリスク エンジン間でメッセージを分散するディスパッチャーを使用した古典的なスキームを使用しました。

XNUMX 番目の問題はクライアント アクセスに関連したものでした。複数のリスク ゲートウェイがある場合、クライアントはそれぞれのリスク ゲートウェイに接続する必要があり、これにはクライアント層への変更が必要になります。 この段階ではこの問題を回避したいと考えていたため、現在のリスク ゲートウェイの設計ではデータ ストリーム全体を処理します。 これにより、最大スループットが大幅に制限されますが、システム統合が大幅に簡素化されます。

複製

私たちのシステムには単一障害点があってはなりません。つまり、メッセージ ブローカーを含むすべてのコンポーネントを複製する必要があります。 私たちは、CLLM システムを使用してこの問題を解決しました。CLLM システムには、XNUMX つのディスパッチャーがマスター/スレーブ モードで動作できる RCMS クラスターが含まれており、一方に障害が発生すると、システムが自動的にもう一方に切り替わります。

バックアップ データ センターの使用

InfiniBand は、ローカル ネットワークとしての動作、つまりラックマウント機器の接続用に最適化されており、地理的に分散した XNUMX つのデータ センター間に InfiniBand ネットワークを敷設することはできません。 したがって、通常のイーサネット ネットワーク経由でメッセージ ストレージに接続し、すべてのトランザクションを XNUMX 番目の IB ネットワークに中継するブリッジ/ディスパッチャーを実装しました。 データセンターから移行する必要がある場合、どのデータセンターを使用するかを選択できます。

結果

上記のすべては一度に行われたわけではなく、新しいアーキテクチャの開発を何度か繰り返す必要がありました。 プロトタイプは XNUMX か月で作成しましたが、実際に動作するまでに XNUMX 年以上かかりました。 私たちは、トランザクション処理時間の増加とシステムの信頼性の向上の間で最善の妥協点を達成しようとしました。

システムが大幅に更新されたため、XNUMX つの独立したソースからのデータ回復を実装しました。 メッセージ ストアが何らかの理由で正しく機能していない場合は、XNUMX 番目のソース (リスク エンジン) からトランザクション ログを取得できます。 この原則はシステム全体に適用されます。

とりわけ、クライアント API を保持することができたので、ブローカーも他の人も新しいアーキテクチャに合わせて大幅な再作業を必要としなくなりました。 いくつかのインターフェイスを変更する必要がありましたが、オペレーティング モデルに大幅な変更を加える必要はありませんでした。

私たちは、アーキテクチャの XNUMX つの最も注目すべき革新である Risk Engine と BUS の略語として、プラットフォームの現在のバージョンを Rebus と呼びました。

当初は清算部分のみを割り当てたかったのですが、結果的に巨大な分散システムができてしまいました。 クライアントは、Trade Gateway、Clearing Gateway、またはその両方と対話できるようになりました。

私たちが最終的に達成したこと:

レイテンシレベルを削減しました。 トランザクション量が少ない場合、システムは以前のバージョンと同じように動作しますが、同時にはるかに高い負荷に耐えることができます。

ピーク パフォーマンスは、50 秒あたり 180 トランザクションから XNUMX トランザクションに増加しました。 さらなる増加は、注文照合の唯一の流れによって妨げられています。

さらに改善するには XNUMX つの方法があります。マッチングを並列化することと、ゲートウェイとの連携方法を変更することです。 現在、すべてのゲートウェイはレプリケーション スキームに従って動作しますが、このような負荷がかかると正常に機能しなくなります。

最後に、エンタープライズ システムを完成させようとしている人たちにいくつかのアドバイスをさせていただきます。

• 常に最悪の事態に備えてください。 問題は常に予期せず発生します。
• 通常、建築をすぐに作り直すことは不可能です。 特に複数のインジケーターにわたって最大限の信頼性を達成する必要がある場合はそうです。 ノードが多いほど、サポートに必要なリソースも多くなります。
• すべてのカスタムおよび独自のソリューションには、研究、サポート、メンテナンスのための追加リソースが必要です。
• システムの信頼性と障害後の回復の問題の解決を先延ばしにせず、初期設計段階で考慮してください。

出所： habr.com