어느 ELW개발자의 글을 보고

1.
페이스북 Server Side Architecture Group에 올라온 글입니다. 저와 페북친구인 분들이 가입을 하셨는지 제 타임라인(Timeline)에서 글을 읽을 수 있었습니다. 보니까 들어본 이름이 몇 있습니다. 제가 정리했던 글도 보입니다. 더구나 토론중 나오는 투자자도 제가 아는 분이고 그 시스템을 개발했던 분도 아는 분입니다. 증권사도 어디인지 짐작이 갑니다.(^^)

글을 옮기면서 살짝 고민했습니다. 동의를 받아야 하는 것인지, 아닌지 애매합니다. 혹 프라이버시때문에 글을 내리라고 하면 기꺼이 내리도록 하겠습니다. 우선 토론이 이루어진 내용을 소개합니다. 글쓴이는 모두 익명으로 처리했습니다.

글쓴이)혼자서 개발하던 중에 네트워크 관련된 부분에서 능력의 한계를 느껴서, 이곳에 답답함을 토로합니다. 현재 개인 투자자의 의뢰를 받아 DMA (전용선거래) 자동매매 프로그램을 개발하고 있습니다.Windows 환경인데, 1Gbps로 연결된 상태에서 Multicast UDP 시세 수신을 받는데요.

개발한 프로그램의 실행속도는 시세 수신부터 매매전략 수행 후, 주문을 보내는데까지 0 microsecond 미만입니다.(구간별 실행시간 측정은 POCO C++라이브러리의 LocalDateTime 클래스를 사용했고, microsecond 단위까지 측정이 가능하며 결과는 0으로 나옵니다.)

일정에 쫓겨서 코드 최적화는 덜됐어도, Memory Map/Shared Memory, ZeroMQ 등을 통해 구조상 속도를 극대화 시키는 방법으로 구현해서, 이 결과에 저 스스로는 크게 만족했는데요.막상 실제 거래에서 돌려보니 타 증권사에서 사용중인 매우 느린 다른 프로그램에 비해 체결경쟁에서 밀리더군요.

물론, 증권사와 거래소 사이의 주문접수 시스템은 정보가 제한된 상태라 주문접수에서 밀릴 수도 있을겁니다.다만, 밀린다 해도 비교대상이 microsecond 단위도 아니고, 수 millisecond에서 수십 millisecond가 걸리기 때문에, 주문접수 시스템의 문제라고만 판단하기도 어려운 것 같습니다.

한가지 의심되는 부분은 Multicast UDP로 시세를 수신할 때 지연이 발생하는 것은 아닌가 싶은데요.시세 수신 네트워크 카드 설정을 확인한 결과, 수신버퍼가 512 Byte, 점보 프레임은 비활성화 상태였습니다.시세 수신 프로그램의 수신버퍼는 8KB였고요.거래소 시세는 550 Byte, 790 Byte 단위로 전달됩니다.

KOSPI 1000여개 종목, KOSDAQ 1000여개 종목, ELW 5000개 이상 종목에 대한 시세와 체결 데이터를 모두 수신하기 때문에, 여기서 병목현상이 발생하지 않았나 추측이 되는데…일단 이용하지 않는 체결 데이터 수신은 중단하려고 합니다.더불어 몇가지 시스템 튜닝을 통해 병목현상을 줄일 수 있지 않을까 예상을 하는데요.Windows 운영체제에서 네트워크 성능을 극대화 시키는 방법은 어떤 것들이 있을까요?

2.
위의 글을 보면서 매매시스템을 개발하는 개발자들이 겪는 고충을 100% 공감합니다. 트레이더를 위한 시스템은 트레이더가 체결율로 평가합니다. “기대했던 체결율이 나오면 잘만들었다” 하고 아니면 “체결율이 나오지 않으면 문제가 많은 시스템이다”라는 소리를 듣습니다.

체결율을 결정짓는 요소는 무엇일까요? 흔히 주문흐름(Order Flow)를 잘 모르는 트레이더들은 주문을 실행하는 전략시스템을 탓합니다. 과연 그럴까요? 주문 흐름은 다음과 같습니다. 한국거래소의 매매체결시스템과 코스콤의 시세분배시스템은 상수입니다. 이를 기준으로 살펴보겠습니다.

1)코스콤 시세분배시스템 -> 증권사 시세분배스위치
2)증권사 시세분배스위치 -> DMA 전략시스템 ( 증권사 시세분배스위치 -> 증권사 시세FEP -> DMA전략시스템)
3)DMA 전략시스템 -> 방화벽 -> 미니원장 및 증권사 FEP
4)증권사 FEP -> 거래소 FEP -> 거래소 매매체결시스템

이중에서 1)과 4)는 여의도전화국으로 거치는 WAN구간입니다. 평균 7~8ms만큼 지연이 발생합니다.Jitter를 고려하면 세자리 마이크로초를 넘는 편차를 보입니다. 전 증권사가 같습니다. 2)와 3)은 증권사와 고객의 등그에 따라 다릅니다. 그렇지만 어느 경우 낮은 두자리 마이크로초이내의 편자를 보입니다. 이상의 주문흐름을 놓고 위 개발자가 개발한 주문시스템이 차지하는 비중은 아주 작습니다. 말씀대로 몇 마이크로초라고 하면 Jitter까지를 고려하면 전체 레이턴시중 1%도 되지 않는 부분입니다. 그런데 1%가 체결율에 어떤 영향을 미칠까요? 모든 주문은 두가지 경쟁을 합니다. 첫째는 같은 증권사를 사용하는 트레이더간의 경쟁이고 둘째는 다른 증권사 트레이더와의 경쟁입니다. 이중 다른 증권사 트레이더와의 경쟁을 객관화하여 평가할 수 있는 방법이 현재 존재하지 않습니다. 물론 증권사 GPS와 같은 장비를 이용하여 시간동기화서비스를 제공하여 한국거래소 시간으로 동기화를 하면 객관화가 가능합니다. 1)의 지연이 얼마이고 4)의 지연이 얼마인지 수치화하여 다른 증권사의 숫자와 비교할 수 있습니다. 현재는 불가능합니다.

또한 1)과 4)로 인하여 발생하는 편차가 최소 1밀리초이상이기때문에 2)와 3)사이에서 몇 밀리초를 줄일 수 있는 기술이 없다면 2)와 3)사이에서 발생하는 두자리 마이크로초는 큰 의미가 없습니다. 그렇다고 절대로 영향이 없다는 뜻은 아닙니다. 트레이더가 숫자로 최선을 다해 할 수 있는 일은 같은 증권사내 경쟁에서 이기는 길이고 내부경쟁에서 이긴 후 외부와의 경쟁에서 이길 수 있도록 하늘에 맡겨야 합니다.(^^)

무엇을 할까요? 앞서 체결율이 떨어진다는 트레이더의 평가를 객관화하는 것이 순서상 첫째입니다. 2)와 3)의 흐름을 숫자화하여야 합니다. 위에서 개발자가 측정한 부분은 2)입니다. 그중에서 아주 작은 부분입니다. 시세를 받고 의사결정을 한 후 주문을 전송하는 구간입니다. 이것때문에 체결율이 떨어졌을까요? 아닐 수도 있습니다. 그래서 필요한 것이 2)와 3)사이에 전문을 흘러다닌 시간을 수집하는 것입니다. 기초적인 자료를 FEP가 가지고 있습니다. 또한 전략시스템의 로그도 이용하여 퍼즐맞추기를 하여야 합니다. 그러면 시세부터 시작하여 전략이 처리한 시간, 증권사 FEP가 주문을 거래소 보낸 시간과 주문접수 시간까지 하나의 표로 만들 수 있습니다. 이와 같은 자료를 만들려면 증권사 IT부서에 요청해야 합니다. 잘 주지 않습니다만 끊질기게 요청을 하셔야죠. 이제 데이타를 가지고 무엇을 할지를 결정하여야 합니다. 직접 해결가능한 구간도 있지만 증권사에 요청하여야 하는 부분도 있습니다.

3.
이런 경우가 있습니다.

“똑같은 시스템과 똑같은 프로그램 및 똑같은 전략을 놓고 운용을 하는데 체결율이…..”

트레이더가 책임지는 시스템이 똑같다고 하면 체결율이 비슷할 수 없습니다. 차이가 당연합니다. 증권사는 1)부터 4)까지 다 다르기때문입니다. 중요한 것은 경향(Trend)입니다. 서로 다른 몇 곳의 데이타를 비교하면 경향을 발견할 수 있습니다. 그리고 대책을 찾을 수 있습니다. 쉬운 경우입니다. 그런데 이런 경우가 있습니다.

“남들이 사용하는 시스템과 프로그램 및 전략으로 매매를 하는데 체결율이…..”

기대치보다 낮은 체결율을 보이고 원인을 개발자로 의심합니다. 이럴 때 해야 할 일은 2)에서 만들어놓은 수치를 가지고 매매체결시스템에 1순위가 호가접수를 한 주문의 비중을 따져보시길 바랍니다. 1순위 주문이 100%인 경우는 절대로 없습니다. “전산적으로 할 수 있는 일은 1순위 주문을 몇 %정도로 유지하느냐” 입니다. 만약 기대치가 100%라고 하면 트레이더가 주문흐름을 전혀 이해 못하는 경우입니다. 저는 50%만 넘으면 훌륭한 체결율이라고 판단합니다. 이 또한 쉽지 않습니다.

이런 경우 트레이더에게 요청하여야 할 것이 있습니다. 시장내에서 어떤 세력과의 경쟁에서 지고 있는지를 확인할 필요가 있습니다. 전산적으로 “지고 있다”는 말은 한국거래소 매매체결시스템의 Queue Order Priority에서 뒤진다는 뜻입니다. 이런 저런 풍문과 트레이더의 감각으로 추정을 해보아야 합니다. 또한 거래하고자 하는 상품의 거래원정보를 보면 거래원순위가 나옵니다. 만약 자신이 거래하고 있는 증권사가 거래원순위에 상위에 있다고 하면 증권사 내부의 경쟁이 치열하다는 뜻입니다.

주문간 외부 경쟁과 내부 경쟁은 다릅니다. 내부 경쟁일 경우 대부분 주문흐름중 1),3),4)는 같습니다. 거래규모가 큰 DMA거래자이면 독자적인 FEP를 사용하는 경우가 있습니다만 이를 제외하면 공통일 듯 합니다. 그래서 내부경쟁일 경우 한자리 마이크로초의 차이가 주문순서에 큰 영향을 줍니다. 하드웨어와 네트워크와 관련한 부분을 최적화하였다고 하면 어플리케이션 최적화는 사실 왕도가 없습니다.

다만 다음과 같은 제도를 염두해 두시길 바랍니다.

한국거래소의 ‘회원시스템 접속에 관한 기준’을 특정한 증권사가 DMA와 관련한 서비스를 독점하지 못하도록 하는 기능을 합니다. 증권사가 자기주문이든 고객주문이든 한국거래소와 주문체결전문을 주고 받기 위하여 사용할 수 있는 물리적 회선이 한정적입니다. 전 증권사가 동일합니다. 제한된 자원을 증권사내의 고객들이 나눠씁니다. 예를 들어 보죠. 1평의 땅이 있습니다. 어떤 1평은 두사람이 살고 있습니다. 어떤 1평은 백명이 살고 있습니다. 50평을 사서 두명이 1평을 쓰도록 하여야 하지만 앞서 ‘기준’은 못하도록 합니다. 증권사가 제공하는 1평이 큰 차이 없이 비슷하다고 하면 – 10G네트워크, DMA전용 미니원장과 FEP를 제공하는 서비스라고 하면 – 메뚜기 본성을 발휘하는 것도 좋은 선택이라고 생각합니다. 이것을 검증하기 위한 것은 여러개의 숫자 즉, 통계치입니다.

4.
다시 처음으로 돌아가도록 하겠습니다. 글쓴이가 비교대상으로 하는 ELW트레이더는 ‘Low Latency와 winsock2‘에서 언급했던 트레이더입니다.

매매서버를 어떻게 구성하셨는지 모르지만 10G를 사용하는 조건에서 – 1G로 구성하였다고 하더라도 – 한국거래소 시세분배시스템이 제공하는 초당 시세데이타를 놓고 볼 때 TCP/IP에서 병목이 발생하였다고 생각하지 않습니다. TCP/IP로 받은 데이타를 처리하는 어떤 구간에서 병목을 발생할 수 있겠죠. 데이타처리와 화면 및 전략은 IPC(Shared Memory 혹은 Memory Map)로 통신하도록 설계하신 듯 합니다. 흔히 병목이 일어나는 구간은 데이타처리와 화면이 만나는 부분인데 이와 관련한 부분이 어떤지 궁금합니다.

소프트웨어 구조를 전문적으로 논할 수 있는 능력이 없는 저의 입장에서 다음과 같은 의견을 드릴 수 있을 듯 합니다. 둘째가 가장 큰 효과를 가져오리라 생각합니다. 아주 뻔한 이야기입니다. 다만 하드웨어와 네트워크가 모두 같지 않다는 점을 상기하자는 취지입니다.

첫째 윈도우 8 혹은 윈도우 2012서버를 이용하여 RIO를 이용하여 어플리케이션을 재설계해보시면?
둘째 윈도우환경에서 TOE기능 – RDMA가 아닙니다 – 을 제공하는 네트워크카드로 교체해보시면?
셋째 CPU Affinity를 적용하면?

아래는 페북에 댓글로 달렸던 것들입니다. 지식을 공유하고 나누는 문화가 좋습니다.

의견A) NIC이 packet을 받고나서 실제 application이 그 data를 보기까지 지연될 수 있는 부분이 두가지가 있을거 같은데요. 1) NIC의 interrupt moderation 2) 다른 high priority interrupt에 의한 NDIS DPC 의 지연. 1 은 NIC(Ethernet Card) setting에서 interrupt moderation 설정을 확인해보시면 될것 같구요. 2는 DPC timer 측정하는 tool로 이상하게 높게 나오면 system에 존재하는 여러가지 service / device들을 제거하는 방법이 있을것 같네요. 이 외에 기타 background traffic의 interference를 줄이고 싶으면 보내는 traffic 을 high priority (tcmon 이라는 tool을 사용하면 DSCP / Ethernet priority 설정이 가능합니다.) 로 설정해보는것도 방법일 수 있는데 이건 switch 설정 / NIC설정에 따라 packet이 아예 drop될수도 있으니 조심하셔야 할것 같네요.

의견B)장건 시세 traffic을 받고 response가 나가기까지 application 에서 측정한게 아니라 kernel 에서 측정한 숫자를 보려면 wireshark같은걸로 한번 확인해보시는것도 좋을것 같습니다. 그리고 user level application process의 priority를 높이는것도 도움이 될것 같네요.

의견C)시세 수신 후, 전략 처리, 주문 패킷 조합까지 0 microsecond 라는게 좀 이상해서, 말씀하신, poco 라는 라이브러리의 LocalDateTime 클래스 소스를 좀 봤습니다. 처리를 GetSystemTime(AsFileTime)을 쓰네요. 이게 마이크로 단위까지 측정만 되는거고요, 실제 해상력은 시스템, OS 마다 다르며, Windows XP 라면 해상도가 15밀리세컨드입니다. 제대로된 프로파일링을 위해서는 Windows 에서는 반드시 QueryPerformanceCounter 를 써서 측정하시기 바랍니다. 받는 시세를 보니 개별종목 ELW 스캘핑 시스템인거 같은데요. 좋은 결과 있으시길… ^^

글쓴이) 저도 0 마이크로초로 측정되는게 다소 의아했지만, 마이크로초 단위로 현재시간 값을 남겨서 비교해도 0 마이크로초 밖에 안걸려서 큰 신경을 안썼습니다.
QueryPerformanceCounter는 예전에 제가 공개 프로그램 개발하면서 사용을 했지만, POCO의 편리성에 중독된데다가 Corss-Platform을 고려하자니 사용을 안하게 되더군요.
그래도 확인을 해보려고 사용해서 측정해보니, 기존에는 0 마이크로초가 나오던 구간에서 3 ~ 20 마이크로초로 다소 일관적이지 않은 값이 측정되네요.
갈길이 참 멉니다….

글쓴이)저도 그렇게 생각했는데, 해당 증권사에서 가장 수익률이 높은 투자자도 Windows를 사용하고 있고, Windows 튜닝과 특수 기능을 활용해서 비약적인 성능향상을 얻은 사례도 있습니다. 그리고 매매시스템이 자동으로 돌아간다고 무조건 데몬 형식으로 돌아가지 않습니다. 투자자 입장에선 언제든지 매매중에 개입을 해야하기도 하고, 진행경과를 비쥬얼로 확인할 수 있어야 합니다.모든걸 프로그래밍으로 논리적으로 풀어해칠 수 없는 분야가 금융이지요.결론적으로 GUI 프로그램까지 개발하느라 윈도우즈를 선택했습니다. ^^;
Windows 7 이상에서 제공되는 NetDMA나 Windows8 이상에서 제공되는 kRDMA를 사용하면, 보통의 Winsock2 보다 더 나은 성능을 얻는 것 같습니다.(참조 : http://www.smallake.kr/?p=10970) 그리고, 현재 매매 시스템이 운영되는 증권사에서 돌아가는 다른 투자자들 시스템은 12 마이크로초 ~ 20 마이크로초 정도라고 합니다.
(해당 증권사 전산담당자로부터 직접 들은 이야기입니다.) 거래소에서 주문접수를 5ms 이내에서 접수를 하기 때문에, 접수가 늦어서 밀리면 5 ms 만큼 손해를 봅니다. 밀리초 단위가 아니라 마이크로초 단위로 낮춰야 하는 이유죠.

“해당 증권사에서 가장 수익률이 높은 투자자도 Windows를 사용하고 있고, Windows 튜닝과 특수 기능을 활용해서 비약적인 성능향상을 얻은 사례도 있습니다.”라고 하는 부분은 좀 과장이 심하다는 생각입니다. 윈도우가 경쟁력이 있다는 말을 동의하지 않습니다. 그리고 특수한 튜닝과 특수기능을 사용했다고 합니다만 앞서 말씀드렸던 세가지를 하신다면 특별한 것이 없을 듯 합니다. 마지막으로 속도가 수익율을 속도가 100% 좌우한다는 생각이 틀렸습니다. ELW스캘퍼의 전략도 계속 변화하고 발전하고 있습니다. 1순위로 주문접수하는 비율은 크게 변화하지 않았는데 수익율이 떨어졌다고 하면 전략에 문제가 있습니다. 혹 이부분을 빼놓으신 것은 아닌지.

마지막으로 ELW매매시스템을 찾는 트레이더가 많다는 느꼈는데 아래 기사가 이유일지 궁금하네요.

최근 일부 증권사들을 중심으로 거래대금이 살아나고 있는 모습이다. 실제 올 1·4분기 현재 ELW 전체 거래대금은 8조420억원으로 지난해 2·4분기 이후 분기 이후 최대치를 기록했다. 이는 스캘퍼들을 대체하는 신종거래 증가와 ELW시장 규제 완화에 따른 기대감 때문으로 풀이된다.

당국의 규제로 스캘퍼들이 대거 사라지자 일부 증권사 프랍 트레이딩(prop trading· 자기매매)팀과 큰 손 투자자들이 LP들의 물량을 대거 받아 거래를 일삼고 있는 것으로 알려졌다. 이들은 장내 옵션 매매를 통해 ELW거래를 헤지하며 수익을 챙기는 행태를 보이고 있다.

외국계 증권사 한 관계자는 “현재 당국의 규제로 ELW 호가가 8~15%로 제한됐다. 하지만 LP로부터 물량을 챙겨 온 일부 스캘퍼와 프랍매매를 하는 증권사들이 개인투자자들과 물량을 치고받는 매매거래 행태를 보이고 있다”며 “더욱이 현재가가 70원 이하인 ELW는 기존대로 한틱(5원) 단위의 호가 제출이 가능하기 때문에 이 구간에서는 거래가 더욱 활발하다”고 설명했다.
신종거래에 살아나는 ELW..웃지 못하는 증권사