市場時間がバッチスケジュールを支配する

一言でいうと

証券システムのバッチスケジュール・ログ形式・保存期間は、エンジニアが選んだものではなく、市場の運営時間と規制が決めたものであり、それを知らなければ、「このバッチを30分遅らせられませんか」のような提案をすることになります。

なぜ必要なのか

証券会社に入ってバッチスケジュール表を初めて見ると、奇妙に細かく詰まっています。08:30、08:40、09:00、15:20、15:30、15:40、16:00に何かが集中していて、その間は空いています。サーバー負荷を平らに均そうという提案は自然ですが、その提案が通らない理由があります。

時刻の1つ1つが、市場のルールに紐づいているからです。

08:30~09:00  장 시작 동시호가. 주문을 받되 체결은 하지 않는다
09:00        정규장 개시. 첫 체결이 쏟아진다
15:20~15:30  장 마감 동시호가. 종가를 정하는 구간
15:30        정규장 종료
15:40~16:00  시간외 종가 매매
장 종료 후    청산·결제 지시, 잔고 확정, 보고 파일 생성

このコードブロックの韓国語コメントは、08:30–09:00は寄り付きの板寄せで注文は受けるが約定はしないこと、09:00は通常取引時間の開始で最初の約定が殺到すること、15:20–15:30は引けの板寄せで終値を決める区間であること、15:30は通常取引時間の終了、15:40–16:00は時間外終値取引、取引終了後は清算・決済の指示、残高確定、報告ファイルの生成を行うことを述べています。

板寄せは特に重要です。この区間では、注文を受け付け続けますが、約定させずに溜めておき、締めの時刻に、1回で1つの価格で約定させます。システムの立場では、これは注文受付の負荷と約定の負荷が、時間的に分離されたあと、1点に集中するという意味です。09:00:00と15:30:00に、秒あたりの処理量が普段の数十倍に跳ね上がります。容量の見積もりを平均で行うと、この2点で破綻します。

そして、これらの時刻は交渉の対象ではありません。15:30に確定しなければならない終値が、15:31に確定すれば、その日のすべてのデリバティブの清算価格が狂います。「バッチを30分遅らせよう」という提案が通らない理由です。

どう動くのか

サーキットブレーカーと変動性緩和装置(VI)は、システム負荷の観点から、特に厄介な存在です。指数が一定の幅以上下がると、取引が数分間止まり、個別銘柄の価格が急変すると、その銘柄だけが短時間、単一価格に切り替わります。

負荷の観点で何が起きるかというと、次のとおりです。止まっている間も注文は入り続けてキューに溜まり、再開の時刻に、それが一度に解き放たれます。普段のピークの数倍が1点に集中しますが、その時点は予測できません。そのため、証券システムの容量の見積もりは、「通常のピークの数倍」を余裕として確保するのが慣行であり、その余裕を無駄だと判断して減らすと、サーキットブレーカーがかかった日に代償を払います。

注文記録の保存義務。資本市場法と下位規定は、注文・約定の記録を、定められた期間(たいてい10年)保存するよう求めています。これがシステムに残す痕跡は、単に「ディスクをたくさん使う」ではありません。

원본 그대로 보존해야 한다   가공한 것으로 대체할 수 없다. 그래서
                            정규화된 테이블과 원본 로그가 둘 다 남는다
변경 이력이 남아야 한다     덮어쓰기가 아니라 append 로 쌓는 구조가 된다
조회 가능해야 한다          분쟁이나 조사에서 특정 주문을 꺼내야 하므로
                            아카이브에도 색인이 필요하다

このコードブロックの韓国語コメントは、順に、原本のまま保存しなければならず加工物で代替できないので、正規化テーブルと原本ログの両方が残ること、変更履歴が残る必要があり上書きではなくappendで積む構造になること、照会できる必要があり紛争や調査で特定の注文を取り出すため、アーカイブにも索引が必要であることを述べています。

調査のとき、これは有利に働きます。ほかのドメインではすでに消えているはずの元データが、証券ではたいてい残っています。状態フィールドを信じず、元データから作り直せという助言が実行可能な理由は、この保存義務のおかげです。

市場監視(異常取引検知)がログの形式を規定します。監視システムは、特定の口座が、特定の銘柄の気配を繰り返し出しては取り消したか、引けの時間帯に集中的に注文を出したか、といったパターンを見ます。こうしたものを見るには、取り消された注文も、約定しなかった気配も、すべて残っている必要があります。そのため、「どうせ取り消された注文だからログから除こう」という最適化は、証券では不可能です。口座識別子・注文時刻・訂正履歴が必須フィールドとして埋め込まれているのも、監視の要求のためです。

現場での姿

ある現場で、注文ログの保存コストを減らそうと、約定せず取り消された注文を90日後に削除するポリシーを入れました。監査で指摘を受けて元に戻しましたが、戻すときに、すでに消したものは復旧されませんでした。元に戻せない最適化を規制の領域に入れる前には、必ずコンプライアンスに先に尋ねる必要があります。この判断は、エンジニア1人で下せる種類のものではありません。

もう1つ、海外の取引所を連携させると、市場ごとにタイムゾーンと休場日が異なります。韓国の休場日に米国市場は開いていて、その逆もあります。ここでよくある事故が、サーバーのローカルのタイムゾーンで日付を区切ることです。UTCの午前0時を基準に1日を区切ると、韓国基準の1日とずれて、引け直後の約定が翌日のバッチに入ります。その日の集計と翌日の集計が両方とも間違い、合計は合っているので、突合でも捕まりません。日付の境界は、市場の営業日を基準に明示する必要があります。

規制がシステム要件として降りてくる場所

資本市場側の規制は、文書としては長いですが、システムに降りてくるときは、いくつかの繰り返される要求に変わります。その形を知っておけば、新しい規制が来ても、何を尋ねるべきかがわかります。

第一に、記録の不変性。注文・訂正・取消・約定が時刻とともに残り、あとで変わってはいけません。そのため、更新するテーブルではなく追記するテーブルになります。「そのとき何を知っていたか」を再現できなければなりません。

第二に、時刻の精度。規制ごとに求める精度が違います(ミリ秒、マイクロ秒)。その精度で記録するには、時計の同期自体が要件になり、同期が崩れた区間も記録しなければなりません。

第三に、再構成可能性。特定の時点の板と注文状態を、再び作れなければなりません。スナップショットと増分を一緒に保管する理由がこれで、保管期間がそのまま保存コストになります。

第四に、権限と分離。注文を出す人と、その記録を直せる人が、違う必要があります。開発者が本番データベースに直接接続できれば、それ自体が指摘事項になります。

第五に、報告期限。決められた時刻までに、決められた形式で出す必要があり、遅れたり間違ったりすれば、それ自体が違反です。そのため、報告バッチの失敗を人がすぐに知る仕組みが、障害対応と同じくらい重要になります。

開発者が尋ねるべき3つの質問は、常に同じです。この値の基準時刻はいつか、どんな入力で計算したか、再計算したら同じ値が出るか。この3つに答えられれば、残りはコンプライアンス担当者との対話で解決します。

最後に、規制対応は機能ではなく制約です。あとから載せると、構造を変えなければなりません。新しい機能を設計するときに、記録・時刻・再現の3つを先に確認する習慣が、あとのコストを減らします。

次のクイズで確認すること

板寄せが負荷に与える影響、サーキットブレーカーの再開時点のキューの解消、保存義務がデータ構造に残す痕跡、市場監視がログ形式を規定する方法、そしてタイムゾーンと営業日の境界の扱い方を確認します。