Limit Order Book과 주문유효성

1.
본격적으로 ZeroDMA를 개발한지 7주가 넘어가고 있습니다. Market Data Feedhandler인 ZeroFeeder는 개발을 마무리하고 KRX의 시세유형별로 추가작업을 벌이고 있습니다. FEP와 데이타를 주고 받는 서비스인 ZeroMAG도 KRX를 기준으로 마무리작업중입니다. 전략 시뮬레이션을 위하여 가상 FEP와 가상매매체결서비스도 추가하고 있습니다. 이상은 복잡하지 않습니다. 다른 회사들도 다 하고 있는 일입니다. 다만 적용한 기술이 ZeroM을 기반으로 한 메시징기술이라는 점이 다릅니다. 흔히 메시징을 Loose Coupled Integration이라고 하는데 프로세스간 통합을 할 때 상당히 능률적이라는 생각이 듭니다. 저도 HTS플랫폼으로 여럿 개발해봤지만 비용이 다르네요.

가장 중요한 부분이 남아 있습니다. 트레이더가 사용할 API입니다. ZeroAPI라고 부릅니다. Market Data API, Order/Execution API는 이미 개발되었고 난이도가 있는 일은 아닙니다. 내부적으로 Data Layer라는 영역이 문제입니다. 트레이더가 필요한 정보를 정의하고 이를 사용할 수 있도록 Data API를 개발하는 일입니다. 예전에도 정리한 적이 있지만 Hash Table을 어떤 알고리즘을 써서 구성할지를 놓고 몇 주째 시험하고 있습니다. HAT와 같은 Cache-Conscious 알고리즘등을 시험하고 있습니다. 이렇게 해서 정리한 Memory Table을 ZeroTable이라고 부르고 있습니다. 튜닝중이지만 다음과 같은 시험을 하였습니다.

체결 및 최우선 호가 데이타 3,906,769건을 테이블에 입력하고 입력한 데이타 하나씩 검색하는 시간을 측정하였습니다. 가지고 과거데이타 자료는 같은 형식으로 찍힌 시간을 가지고 있습니다. 초단위 아래 6자리를 키로 잡아서 시험을 했습니다.

[07:30:01.672989]A3011KR7042660001230000000000000446(생략)

입력할 때 6자리가 같으면 수정(Replace), 다르면 추가(Insert)하였습니다.처리 데이터는 총 3,906,769건이고, 키 사이즈는 6바이트입니다. 중복데이터는 975,056건입니다. 이렇게 나온 통계자료를 가지고 각각 3,906,769로 나누었습니다. bsearch와 sequencial도 시험을 했지만 많은 차이가 나서 생략합니다. ZeroTable중 A타입은 흔히들 많이 사용하는 방식입니다. B타입은 알고리즘을 대폭 수정한 형식입니다. 아직 HAT과 같은 Cache-Conscious를 시험중입니다만 완성도가 낮아서 이번 시험에서는 생략하였습니다.(us=microsecond)

다른 자료를 찾아보면 항상 나오는 말이지만 시험은 데이타의 특성에 따라 달라진다는 점을 고려하여야 합니다. 그럼에도 ZeroTable B타입이 상대적으로 뛰어난 성능을 보여주고 있습니다. 1 마이크로초아래의 결과값입니다. ZeroTrade를 개발하기 위하여 많은 노력을 들이는 이유는 여러가지가 있습니다. 10G 환경은 소프트웨어와 달리 네트워크투자를 하면 가능합니다. 코로케이션 – 물론 이제는 DMZ로 통일되지만 – 도 증권사의 정책적인 결정과 투자자의 선택이면 가능합니다. 남은 영역은 소프트웨어를 통한 Latency 단축입니다. 그 중 데이타 관리와 처리가 큰 영역이라고 생각했고 아래 글도 도움을 주었습니다.

My first really technical post will be on how to build a limit order book, probably the single most important component of a trading system. ?Because the data structure chosen to represent the limit order book will be the primary source of market information for trading models, it is important to make it both absolutely correct and extremely fast.
How to Build a Fast Limit Order Book중에서

처음 Limit Order Book란 단어를 쉽게 이해하지만 왜 이것이 자동매매와 알고리즘트레이딩에 중요한지를 이해 못했습니다. 계속 고민을 했습니다. 결국 Market Microstructure라는 영역으로 넘어가더군요. 몇 가지 논문을 살짝 훌어보았습니다. 가장 대표적인 논문입니다. @dolppi님이 번역한 논문입니다. 또한 @drjoelkim 님이 블로그에서 추천한 글이기도 합니다.

2.
위의 논문은 머리가 아픕니다. 이미 머리가 굳은 제가 수학기호가 복잡한 논문을 이해할 수 없기때문입니다.더구나 그동안 차트나 기술적 지표를 가지고 트레이딩을 하던 투자자들만 보았고 직접 트레이딩을 하지 않기때문에 “알고리즘트레이딩의 전략을 설계할 때 Limit Order Book이 왜 중요할까”는 여전히 풀리지 않은 의문이었습니다. 그러다 실마리를 찾았습니다. 아주 오래된 논문이었습니다.

The Penn-Lehman Automated Trading (PLAT) Project

PLAT 프로젝트를 설명하는 글을 보면 Market Microstructure에 대한 아주 간단히 손쉽게 이해할 수 있도록 설명을 해줍니다. 덧붙여 PXS Simulation를 이용하여 Market Making을 설명한 아주 쉬운(^^) 논문입니다.

Two stock-trading Agents:Market Making And technical Analysis

위의 논문을 보면 저도 이해하는 이런 모델이 나옵니다.

호가정보를 기초로 하여 다양한 계산으로 매매와 관련된 정보를 구하는듯 하였습니다. 사실 한 달전쯤 @drjoelkim이 Limit Order Book을 설명해주었습니다. 다만 위의 그림처럼 단순하지 않고 복잡한 계산을 하고 있습니다. 금융공학책을 보면 나오는 복잡한 수식들입니다. 고차원적인 설명이라 이해를 못했다가 겨우 감을 잡았다고 할 수 있습니다. 단순 수식이 나온 논문이 나온지 10년이 넘었고 그 사이 시장을 분석하는 수학적 모델이 더 체계화되었고 복잡해졌다고 이해를 합니다. 이제 한가지 더 남았습니다.

앞서 소개한 How to Build a Fast Limit Order Book을 보시면 Add, Cancle, Execute란 이벤트를 처리하기 위하여 Binary-Tree로 호가정보를 처리하는 방법을 소개하고 있습니다. 과연 KRX시장의 주문을 처리할 때 도움이 될까요? 거래소가 시세정보를 제공하는 방법은 거래소마다 다릅니다. NASDAQ의 ITCH Feed를 보시면 하나의 전문으로 모든 시세정보를 처리합니다. 다만 우리처럼 시세를 유형별로 구분하지 않습니다. 대부분 해외거래소는 Order Add Message, Order Executed message, Order Cancel Message, Order Delete message, Order Replace message등으로 모든 시세를 처리합니다. 따라서 포르폴리오로 관리되는 종목들의 Limit Order Book을 관리하려면 앞서 이벤트를 가장 빨리 처리할 수 있어야 합니다. 더구나 초당 몇 만건의 데이타를 받아서 처리하여야 하기때문에 프로세싱 속도가 무척이나 빨라야 합니다. 아시는 분은 아시지만 시세는 주문과 분리된 데이타가 아닙니다. 호가주문(신규,정정,취소) 및 체결이 곧 시세입니다. NASDAQ의 시세처리방식은 매매흐름상 일관성을 가집니다. 반면 KRX의 시장정보 설계는 그렇지 않습니다. 아직 전 호가를 제공하지 않고 있고 제공하는 방식도 해외거래소와 다릅니다. 또한 10단계호가만을 별도로 공개하기때문에 Limit Order Book관리가 완전히 다릅니다.

3.
New Exture를 가동하면 시장정보가 어떻게 바뀔지 궁금합니다. 그렇지만 몇 년동안 현재와 같은 틀이 유지되기때문에 Processing Latency를 줄이는 노력은 다른쪽으로 집중하여야 합니다. 미국은 현재 주문실행뿐 아니라 새로운 영역에서 Low Latency 경쟁을 하고 있습니다. SEC가 제정한 Market -Access-Rule에 따른Pre Trade Risk Management입니다. 이미 몇 회사는 나노초단위의 시스템을 구축하였다고 합니다.

The company says that the field programmable gate array (FPGA) microchip is achieving latencies as low as 740 nanoseconds wire-to-wire. FPGA’s can have programming logic embedded in them so that they do not have to interact with software in order to complete a task, speeding the defined process up.

Functioning as a low-latency filter, the Fixnetix technology enables 20 pre-trade risks checks to be carried out in under 100 nanoseconds, minimising their impact on order latency.
Fixnetix claims “world’s fastest” pre-trade risk checks중에서

Pre-Trade Risk Management는 금융위의 ‘추가건전화방안’과 비교하면 ‘ 주문유효성 조항이라고 할 수 있습니다.

유효성 체크 항목 : 수량한도, 계좌번호, 매매종목, 보유한도, 증거금, 주문 가능시간, 가격구분(시장가, 주문가등), 호가단위, 주문 수량단위, 상하한가 등 (→증권사의 내부통제와 관련된 체크 포인트)

앞서 Limit Order Book 설계처럼 ?주문유효성 체크를 얼마나 빨리 할 수 있도록 자료구조와 알고리즘을 가져가는냐가 무척 중요한 경쟁요소가 아닐까 합니다. 가원장을 처리하기 위하여 저장매체를 다양하게 가져가는 듯 합니다. 어떤 곳은 MMDBMS(Main Memory)로 처리합니다. 주로 Altibase를 사용하고 Timesten을 사용하는 곳도 있습니다. 어떤 곳은 Hash Table을 사용하는 듯 합니다. 그렇지만 맨 처음 소개한 자료를 보시면 아시겠지만 Hash Table도 어떤 알고리즘을 사용하느냐에 따라 성능에서 많은 차이가 납니다. 물론 기준은 마이크로초단위입니다. 아마도 여러가지 시험을 많이 해야 할 듯 합니다.

트레이딩을 하지 않고 개발자도 아닌 사람이 어떻게 사물을 이해하고 개발팀과 협력하는지를 소개하였습니다. 혹 도움이 되셨나요? ?저도 모르는 것이 많아서 하나씩 배웁니다. 주변에 물어보더라도 제가 이해 못하는 경우도 많아서 문제의식을 계속 키워나가야 하거든요. Market Microstructure를 쉽게 설명한 글까지 읽었네요. 하여튼 세상은 넓습니다.

틀린 점이 있으면 지적해주세요.혹시 Hash Table을 사용하시면 비슷한 시험을 하시고 측정결과를 공유해주시면 어떨지(^^)