時計が三つあれば順序も三つある

一言でいうと

取引所時刻・ゲートウェイの受信時刻・アプリケーションの処理時刻は、それぞれ別の時計であり、どの時計で並べるかによって、「取消が先か約定が先か」の答えが入れ替わります。

なぜ必要なのか

イベント1つには、たいてい時刻が2つ以上刻まれています。初めて見ると、なぜこんなに多いのかわからず、適当に1つ選んで並べてしまいます。その選択が、結論を変えます。

ts_exch   거래소가 그 일이 일어났다고 찍은 시각
ts_recv   우리 게이트웨이가 그 메시지를 받은 시각
ts_proc   우리 애플리케이션이 그것을 처리한 시각

3つの韓国語コメントは、順に、取引所がその出来事が起きたと刻んだ時刻、こちらのゲートウェイがそのメッセージを受け取った時刻、こちらのアプリケーションがそれを処理した時刻を述べています。

3つの時刻の間隔は、ネットワーク経路とキューの長さによって変わります。問題は、経路が1つではないことです。約定通知と取消のレスポンスが、互いに異なるセッション、異なる回線、異なるプロセスを通って来ると、取引所で先に起きたことが、こちらにはあとから届きます。

どう動くのか

前のレッスンのその注文を、2つの時計で並べてみると、次のように分かれます。

거래소 시각 순서            수신 시각 순서
  cancel_req                  cancel_req
  fill        (누적 300)      cancelled
  cancelled                   fill        (누적 300)
--------------------------  --------------------------
마지막 이벤트 = cancelled   마지막 이벤트 = fill
결론: 취소된 주문           결론: 체결된 주문

このコードブロックの韓国語コメントは、左が取引所時刻の順序、右が受信時刻の順序であり、左は最後のイベントがcancelledで結論は取消された注文、右は最後のイベントがfillで結論は約定した注文であること(fillの括弧は累計300)を述べています。

同じ6行、同じ畳み込み規則で、答えが違います。そして、この違いは珍しくありません。取消のレスポンスは短いメッセージなので早く来て、約定通知は比較的遅い経路を通る構成がよくあるため、取消と約定が数ミリ秒の間で競合すると、ほぼ毎回順序が入れ替わります。

どちらを根拠にすべきか。市場で実際に起きたことの順序は、取引所時刻です。こちらの受信時刻は、こちらのインフラの事情であって、事実ではありません。そのため、事後の再構成・監査・紛争対応は、取引所時刻で並べます。同じ時刻に2つのイベントがあれば、取引所が付けた連番で区別します。並べ替えの基準が1つだけだと、同じ入力から毎回異なる答えが出ます。

ただし、受信時刻も捨てません。2つの時刻の差が遅延であり、遅延が跳ね上がる区間を探すのに使われます。そして、リアルタイム処理器は未来を見られないので、届いた順に処理するしかありません。リアルタイムの結果と事後の再構成の結果が異なりうることを認めたうえで、事後の再構成が正解であり、リアルタイムの結果はそれで補正するという手順を置くのが、現実的な答えです。

最もよい設計は、順序に結果が左右されないようにすることです。今回の場合、規則をこう変えれば、2つの時計の答えが同じになります。再生が終わったあとで累計約定が注文数量以上なら、状態は約定になる、というものです。根拠はドメインにあります。約定は取り消せない事実で、取消は残数量にだけ適用されます。残数量が0の注文に取消が届くのは正常であり、それが約定を消すことはありません。

現場での姿

取引所と紛争になると、双方が自分のログを持ち出します。取引所は自分の時刻で、こちらは自分の時刻で並べた表を出します。2つの表の順序が違えば、そこからは事実確認ではなく、どの時計を認めるかの問題になり、契約書と規定は、たいてい取引所時刻を基準に書かれています。そのため、こちらの時刻だけを残して取引所時刻を捨てるログ設計は、紛争でこちらを無防備にしてしまいます。

もう1つ、NTPが合っていないサーバー1台が、調査を何週間も拘束します。ある現場では、ゲートウェイ2台のうち1台の時計が約400ms進んでおり、その機器を通った注文だけが、取消が約定より先であると記録されました。データだけを見ると、特定の銘柄・特定の時間帯に集中しているように見えたので、市場要因をしばらく探しました。時刻を扱う調査では、時計そのものを最初に疑うほうが、時間の節約になります。

次のラボですること

同じイベントログを、取引所時刻と受信時刻でそれぞれ並べて、2セットの最終状態表を作り、結論が入れ替わる注文を正確に拾い出します。そのあと、順序に左右されない規則を入れて、2セットが同じになることを確認します。