Togda님의 질문에 대한 답변 – 구간별 Low Latency 적용방안

1.
togda 님의 방명록에 남기신 질문입니다.

안녕하세요. 곧 거래소의 파생상품 시세전달방식이 브로드캐스트에서 멀티캐스트방식으로 바뀐다고 하길래 smalllake님의 블로그를 공부하면서 궁금한점이 생겨서요. 제가 관련지식이 미약한 관계로 질문이 거칠게 느껴지실것 같습니다.

1. 위와 같은 시세데이타를 쌓는 형식 ISAM/Shared Memory/ MMDB/SAM에 따른 속도차이에서 만약 프랍데스크에서 fep에 데몬과 같은 방식으로 hft모듈을 만든다고 하더라도 위와 같은 형식에 따른 영향을 받는 건지요? 일반적으로 클라이언트단에서 시세를 받은 후 주문을 fep에 전송할 경우에는 중간에 시세서버라는게 따로 존재하기때문에 위의 영향을 받을 수 있겠다는 생각이 들지만요..

2. 만약 차이가 존재한다면 어떤 방식이 가장 기술적으로 빠르다고 할 수 있을까요?

장기적으로 트레이더로 생존하기 위해 c언어 책을 주말에 구매했는데 얼마나 도움이 될 지 답답하네요.. 점점 시장에서 매매를 하다보면 제가 영화매트릭스에서처럼 평범한 인간이 컴퓨터와 싸우고 있구나하는 생각이 듭니다.

그러면 하나씩 의견을 드리도록 하겠습니다.

2.

질문1:위와 같은 시세데이타를 쌓는 형식 ISAM/Shared Memory/ MMDB/SAM에 따른 속도차이에서 만약 프랍데스크에서 fep에 데몬과 같은 방식으로 hft모듈을 만든다고 하더라도 위와 같은 형식에 따른 영향을 받는 건지요? 

당연히 영향을 받습니다. Processing Latency(처리지연)이라고 할 수 있습니다. 보통 Prop Desk에서 트레이딩시스템을 구축할 때 정상적인 경우라고 하면 FEP로 바로 메시지가 전달되는 것이 아니라 주문처리를 하는 모듈을 거쳐서 원장을 거친 다음에 주문이 나가야 합니다. 그렇지만 워낙 속도가 중요하니까 이를 생략하고 바로 FEP에 붙일 수 있습니다.

FEP – Prop Trading System
FEP – Oder Management System – Prop Trading System

당연히 한군데를 더 거치니까 누구라도 느릴 것이다라고 짐작할 겁니다.

FEP – Prop Trading System으로 구성할 때도 몇가지 요인이 속도를 결정합니다.

첫째는 FEP입니다. 거래소의 규정에 따르면 시간우선의 원칙등 주문을 중개할 때 원칙이 있습니다. Prop 주문이 아무리 FEP에 빨리 전달된다고 하여도 시간순으로 주문을 보내면 전송순서에 따라 KRX로 가야 합니다. 만약 FEP에서 시간우선의 원칙이 아니라 채널우선과 같이 변형적인 규칙을 적용하면 이런 규칙을 적용한 시스템이 다른 시스템보다 빠릅니다. 물론 합법, 불법여부를 떠나서…

둘째는 Prop Trading System내부의 구조와 관련된 문제입니다. 매매시점을 어떻게 포착하느냐가 중요한 관건일 듯 합니다. 만약 Prop Trading System이 Client/Server와 같은 구성으로 되어 있고 Client에서 의사결정이 이루어지면 그 만큼 지연이 발생합니다. 반면 Terminal과 같은 방식으로 되어 있거나 자동주문과? 같은 형식으로 되어 있으면 그만큼 지연이 덜합니다.

또한 Point & click으로 의사결정을 하는 경우와 Automated System으로 하는 경우도 역시 차이가 발생합니다. 인간이 눈으로 보고 판단하는 시간동안 지연이 발생합니다.

셋째 Prop Trading System을 자동매매형태로 구축하였다고 할 경우 전략을 실행할 때 어떤 방법으로 하는가에 따라 지연이 달라집니다. 만약 종목 Tick데이타를 가지고 VWAP을 구하는 논리를 사용할 경우 Tick 데이타가 Oracle, 메모리DB, Shared Memory로 할 때 모두 다릅니다. 데이타를 Insert할 때와 Query조회를 할 때? 모두 지연이 다릅니다.

넷째는 Prop Trading System의 I/O와 CPU입니다. 만약 Prop에서 받은 시세데이타가 전 종목일 경우 I/O와 CPU사용이 많습니다. 그러면 CPU가 처리하여야 할 Process로 할당할 수 있는 리소스가 적어집니다. 이런 이유로 지연이 발생합니다.

마지막으로 질문중 FEP에 HFT프로그램을 설치하여 운용할 경우를 물어보셨습니다. 여기서 FEP는 아마도 주문FEP이지 않을까 합니다. 주문FEP는 증권사에서 가장 중요한 시스템중 하나라 다른 프로그램을 설치하도록 허가받기가 쉽지 않아 보입니다.(^^) 가능한다고 하더라도 시세데이타를 받으면 I/O가 높아져 결국 시스템전체로 지연이 발생하고 성능저하가 됩니다.

남는 경우는 시세FEP에 HFT를 설치하는 경우인데 역시 다른 서비스에 대한 영향이 있기때문에 쉽지 않을 듯 합니다.

결국 방법은 앞서 이야기하였던 구성중 시세FEP—>Prop Desk System(Terminal 혹은 자동) –> 주문FEP(채널별 시간우선)으로 하는 것이 가장 빠른 방법일 듯 합니다.

3.

2. 만약 차이가 존재한다면 어떤 방식이 가장 기술적으로 빠르다고 할 수 있을까요? 

질문1에서 의견을 말씀드린 것을 전제로 추가로 적어보겠습니다. 우선 리테일고객들이 사용하는 HTS구조는 벗어났으면 합니다. 즉, HTS는 리테일 고객을 위하여 서버에서 화면별 데이타를 처리하기 위한 어플리케이션서비스가 제공됩니다. 이를 위하여 시세를 Shared Memory등에 쌓습니다. 이 과정에서 높은 I/O때문에 지연이 커질 수 있습니다. 그래서 저는 가장 단순한 구조로 시스템을 설계하시는 것이 좋다고 판단합니다.

저는 Linux High Performance Edition가 되든, 아니면 Windows HPC Edition을 OS로 한 x86시스템을 선호합니다. 가능하면 HTS Platform을 기반으로 하여 시스템을 구축할 필요가 없다고 생각합니다. 인터넷을 보면 Low Latency, High Performance Messaging Middleware가 많습니다. 이를 기반으로 시스템을 구축하면 어떨까 합니다. Multicast로 전송된 파생상품 데이타도 Messaging Adaptor를 구성할 때 필요한 데이타만 사용합니다.? Feed Handler 같은 개념이 적용되면 특정한 종목만 Subscribe하면 되는데 KRX는 그런 서비스가 없기때문에 그냥 하드코딩방식으로 개발하셔야 할 듯…

마지막으로 질문에 대한 답변을 드리도록 하겠습니다. 개발자일 경우엔 소위 hard coding이 가장 높은 성능을 낼 가능성이 많습니다. 그렇지만 이런 방식은 Trading Desk가 트레이더, 퀀트, 소프트웨어 엔지니어로 구성된 경우에 한합니다. 모든 것을 트레이더 혹은 퀀트가 해야 할 경우엔 개발에 따른 지연도 고려하여야 하지 않을까 합니다.

이런 경우를 위하여 CEP/ESP와 같은 기술들이 등장하였습니다. 자바기반으로는 Esper라는 제품이 있고 윈도우환경에 익숙하시면 Microsoft SQL Server StreamInsight라는 CEP/ESP제품이 있습니다. C++ 혹은 F#을 사용하실 수 있으면 쉽게 접근이 가능합니다.

StreamInsight Resources
ESPer – Complex Event Processing

Market data Adaptor와 Order Adaptor등을 개발해놓으면 전략변경은 SQL수준에서 가능합니다.

4.
Low Latency는 어느 기술 혹은 어느 제품을 도입한다고 이뤄지는 목표가 아닙니다. 시스템환경,네트워크환경,어플리케이션구조등 다양한 요소가 결합되어 있기때문에 복합적으로 검토하여야? 한다는 말을 추가로 드립니다.

너무 길었죠?(^^)요약하면

당연히 Shared Memory가 제일 빠릅니다. FEP에 HFT프로그램을 올려놓는 경우는 쉽지 않을 듯 합니다. 전략은 끊임없이 변화하기 때문에 변경등을 고려하여 오픈소스 CEP/ESP등을 검토해보시면 좋을 듯 합니다.

혹 다른 의견이 계시는 분은 댓글로 남겨주시면 다른 차원으로 많은 생각을 하겠습니다.