DMA 지연측정을 위한 방법적 시론

지연을 말할 때 똑같은 값은 없습니다. 시간과 조건에 따라 다릅니다. 겉은 같지만 속을 보면 차이가 있습니다.

1.
4월 2일부터 주문수탁제도가 바뀌었습니다. 다 압니다. 누구나 DMA서비스를 이용할 수 있는 가능성이 생겼습니다. 그렇지만 누구나 이용할 수 없고 누구나 이용할 필요도 없습니다. 조건과 전략에 따라 선택하여야 합니다.

자신의 필요에 의해서 선택한 DMA서비스를 놓고 트레이더는 여러가지 생각을 가질 수 있습니다.

“내가 가장 빠른 속도로 주문을 낼 수 있다.”
“속도 경쟁에서 유리하니까 수익율이 당연히 높아지겠네.”

조금이라도 경험이 있으면 이런 생각이 환상임을 아십니다. DMA서비스를 받았다고 해서 끝이 아닙니다. 전략과 속도를 둘러싼 길고긴 투쟁의 시작입니다.

트레이더는 DMA서비스를 통해 시세와 주문에서 강점을 가지길 바랍니다. 증권사는 가장 빠른 서비스를 제공한다고 유혹하기까지 합니다. 그렇지만 현실은 다릅니다. 생각했던 것 만큼 속도가 나오지 않고 늦기도 합니다. 시간이 흐르면서 더 늦어지고 결국 다른 증권사로 옮깁니다. ELW 직업트레이더들이 보여주었던 모습입니다.

자! DMA를 이용하여 자동매매를 한다고 합시다. 계좌개설도 끝났고 시스템도 개발하였습니다. ‘내가 받고 있는 서비스 품질’을 어떻게 점검하여야 할까요? 몇 주동안 이런 저런 사람을 만나고 경험한 것을 정리하였습니다.

2.
트레이더가 준비한 서버이든, 아니면 증권사가 제공한 서버이든 속도에 가장 많은 영향을 주는 것은 네트워크 카드입니다. 일반적으로 제공받은 리눅스서버에 어떤 네트워크 카드가 설치되어 있는지를 확인하려면 lspci를 사용합니다. PCI슬롯에 연결되어 있는 모든 종류의 Device정보를 보여줍니다. Ethernet Card정보중 모델명을 확인하여 인터넷을 통해 상세정보를 확인합니다. 제가 사용하고 있는 개발서버는 Broadcom사의 NetXtreme II가 설치되어 있네요.

다음으로 DMA서버와 FEP(미니원장)간의 속도를 측정합니다. FEP는 증권사가 소유하므로 트레이더가 접근할 권한이 없습니다. 두 서버간의 레이턴시를 측정할 수 있는 방법은 여러가지 입니다. 예전에 소개한 sockperf도 있고 iperf도 있습니다. 비록 오픈소스이지만 앞서 두개의 도구는 FEP에 별도의 프로그램을 설치하여야 합니다. 증권사가 도움을 주지 않으면 불가능하므로 유일한 선택은 ping입니다.

Linux에서 제공하는 ping으로 측정할 수 있지만 조건을 지정하거나 통계를 처리할 때 불편합니다. 그래서 KRX Interparty Latency Project 때 사용했던 Uping을 사용하시면 좋습니다.소셜프로젝트 “KRX Inter Party Latency 측정”을 제안합니다

또 traceroute 명령어가 동작하면 traceroute FEP주소를 해보시길 바랍니다. FEP에 도달하기까지 어떤 라우팅장비를 거치는지를 알 수 있습니다. Hop Latency를 볼 수 있습니다.

여기서 잠깐. 10G 이야기를 자주 하였습니다. 1G와 10G 네트워크 카드를 사용할 때 다르다고 하였습니다. 또한 TOE기능을 지원할 때와 하지 않을 때도 다르다고 하였습니다. 1G, 1G TOE, 10G TOE를 상대적으로 비교할 기회가 있었습니다. 모두 Ping을 이용하여 시험을 하였습니다. TOE와 10G를 지원할 때 1G와 비교하여 큰 차이를 보여주더군요. ?현재 1G를 사용하고 있다면 (U)ping으로 측정한 후 네트워크카드를 교체한 후 다시 (U)ping으로 측정한 값과 비교해보시길 바랍니다. 숫자가 달라집니다.

만약 Uping을 사용했다면 jitter도 확인할 수 있다는 점입니다. 앞서 ping으로 시험한 결과중 마지막을 보면 min/avg/max/mdev가 있습니다. 이중 mdev가 jitter값입니다. 작으면 작을 수록 좋습니다. 네트워크가 일정한 품질이라는 뜻입니다.

한가지 더 확인할 부분이 있습니다. 앞서 주문서버와 증권사FEP처럼 증권사FEP와 거래소FEP간의 Ping 결과입니다. 증권사에 요청해서 받을 수 있으면 받으시길 바랍니다. 이 때 주의하여야 할 부분이 있습니다. 증권사FEP에 할당된 거래소FEP주소가 거래소 주문전달프로세스를 설치한 서버의 주소인지, 아니면 내부주소로 변환해주는 거래소라우터의 주소인지에 따라 다릅니다. 제 판단에 후자일 듯 합니다. 보안 등으로 이유로 대외로 공개된 주소는 네트워크장비의 주소라고 생각합니다. 이럴 경우 큰 의미를 부여하기 힘듭니다.

3.
레이턴시를 다룰 때 전제가 있습니다. 어떤 경우에도 똑같은 품질의 서비스는 불가능합니다. 기준에 따라 차이가 발생할 수 밖에 없습니다. 어떤 차이는 줄일 수 있고 어떤 차이는 줄일 수 없을 수 있습니다. 측정을 하는 것은 줄일 수 있는 요소를 찾아내서 최소화하자는 것입니다. ?이제 주문속도측정입니다.

주문속도는 크게 네가지로 이루어집니다.

첫째 시세수신지연
둘째 주문처리지연
셋째 증권사FEP지연(주문유효성검증 및 증거금처리 포함)
넷째 거래소주문접수지연

먼저 시세수신지연입니다. 코스콤이 운영하고 있는 시세분배시스템을 통해 시세를 받기 때문에 전 증권사의 시세속도가 동일하다고 생각하시나요? 당연히 아닙니다. 시세분배시스템이 회원사로 보낼 때도 약간씩 차이가 있고 증권사 내부에서도 네트워크 구성에 따라 시세 지연이 발생합니다. 만약 거래소가 해외거래소처럼 호가주문을 그대로 시세로 제공하고 ?Order-To-Quote Latency와 같은 정보를 제공하면 ?주문이 접수된 후 어느 정도후에 시세로 내려오는지 알 수 있습니다. 그렇지만 KRX의 경우 호가주문을 내더라도 호가접수된 후 바로 호가로 시세처리하지 않고 일정한 호가를 모아서 호가잔량정보로 제공합니다. 따라서 비교하기가 힘듭니다.

Order To Quote Latency

이와 관련하여 아는 후배로부터 다음과 같은 방안을 전해들었습니다.

A와 B의 증권사 서버 혹은 같은 증권사의 A서버와 B서버에서 거래하고자 하는 종목의 체결데이타를 장시작부터 수신합니다. 체결데이타를 받을 때마다 마이크로초단위로 시간을 기록합니다. 몇 일에 걸쳐 반복합니다. 측정을 하고자 하는 서버별로 최초 체결데이타부터 시작하여 다음 체결데이타사이의 차이를 계산합니다. ?체결데이타와 체결데이타의 차이값이 지연이 없다고 하면 모두 같아야 합니다. 그렇지만 네트워크 구성이 다 다르기때문에 값이 다릅니다. ?만약 어떤 서버 A의 차이가 1이라고 하고 다른 곳이 B가 1.1이라고 하면 A가 B보다 빠르다고 할 수 있습니다.

나름 타당한 방법으로 보이시나요? 저는 시간동기화를 할 필요없고 명확한 기준이 있기때문에 가능한 방법이라고 생각합니다. 다만 거래하는 증권사가 여러 곳이어야 합니다.
둘째 주문처리지연입니다. 전략개발을 마친 후 보통 루프백시험이나 코스콤 테스트장 시험을 합니다.이 때 로그를 이용하여 시세접수-전략진입-시그날생성-주문처리-주문전송-FEP수신-FEP송신-거래소접수-거래소체결까지 시간을 기록합니다. 시간동기화를 고민할 필요는 없습니다. 마이크로초단위로 기록하여야 하기때문에 NTP를 이용하여 동기화를 하여도 신뢰할 수 없습니다. 방법으로는 RRT(Round Robin Time)을 사용합니다.

셋째 증권사FEP지연입니다. 증권사마다 FEP전략이 다릅니다. 어떤 곳은 전사적 FEP전략을 취하고 어떤 곳은 t서비스도메인FEP전략을 취합니다. DMA서비스가 본 궤도에 오르면 DMAFEP와 전사적 FEP가 양립하는 것으로 발전하리라 생각합니다. FEP지연도 측정가능합니다. 주문을 받는 시간과 주문을 거래소로 전송하는 측정해서 통계를 내면 됩니다. 이상은 직접 혹은 증권사와 협의를 하여 수집가능한 데이타입니다.

넷째 가장 중요한 주문접수시간입니다. 거래소구간에서 지연이 발생할 가능성이 있는 가능성은 세가지입니다.

먼저 거래소의 주문전달프로세스를 설치한 하드웨어입니다. 거래소FEP는 주문을 처리하는 프로세스가 아닙니다. 주문전달프로세스입니다. 회원사로부터 받은 주문을 해당 매매체결프로세스로 전달하는 역할을 합니다. ?거래소가 전체 회원사들의 주문전달프로세스를 어떤 장비에 어떻게 할당하고 있는지를 공개하지 않습니다. 고객인 회원사도 알지 못합니다. 만약 주문전달프로세스별로 처리하는 데이타건수를 비슷하게 조정한다고 하면 회원사의 프로세스가 같은 FEP서버(하드웨어)에서 처리하지 않을 수도 있습니다. 하드웨어 사양이 같다고 하여도 OS와 Processing 및 주문처리건수에 따라 편차가 발생합니다.

다음은 주문전달프로세스가 매매체결프로세스로 전달하는 과정입니다. 제가 알기론 Exture는 Rendevous를 주문체결을 위한 미들웨어로 사용하고 있습니다. 이를 해석하면 아마도 pub/sub방식으로 주문전달프로세스와 매매체결프로세스가 통신하지 않을까 합니다. Rendevous는 브로커모델의 미들웨어입니다. 브로커가 publisher들의 메시지를 받아서 subscriber에 보냅니다. 브로커는 하나가 아니라 여러개도 가능합니다. 멀티도메인이라고 합니다. A브로커에서 발생한 정보를 B브로커에 연결한 subscriber에 전달할 수 있는 기능입니다. 주문전달프로세스와 매매체결프로세스간의 네트워크와 메시징미들웨어가 어떻게 구성되어 있는가에 따라 FEP세션별로 지연이 다르게 발생합니다. 만약 이 구간에서 1마이크로초라도 차이가 있다면 최소 5밀리초만큼의 지연으로 이어집니다. 왜냐하면 KRX가 발표한 자료에 따르면 호가주문을 처리하는 최소시간이 5밀리초이고 호가주문은 큐를 통하여 순서대로 처리하기때문입니다.

다음의 지연은 매매체결프로세스의 지연입니다. 체결이라고 하지만 체결은 접수와 체결로 나뉩니다. ?예전에 쓴?매매체결시스템의 속살을 보시면 매매체결프로세스는 접수Queue를 통하여 받고 다시 송신Queue를 통하여 회원사로 보냅니다. 물리적으로 Queue를 어떻게 설계하는지를 떠나서 큐데이타는 FIFO가 적용됩니다. 이상을 하나의 수식으로 정리하면 거래소 지연은 다음과 같습니다.

Exchange Latency = FEPTimeX2 + MessagingTimeX2 + (RECV Queue OrderNumber)X(Response ProcessTime)+(SND Queue OrderNumber)X(Sending ProcessTime)
+
FEPTime: 회원사와 거래소FEP간의 시간
MessagingTime:거래소FEP와 매매체결시스템사이의 전송시간
RECv Queue OrderNumber: 접수큐의 대기순서
Response ProcessTime: 주문접수하고 관련데이타를 테이블에 기록하고 결과를 송신큐에 보내는 시간
SND Queue OrderNumber:송신큐의 대기순서
SND ProcessTime:주문접수데이타를 거래소FEP로 보내는데 필요한 시간

아주 추상화하고 개념화한 시간입니다. Exture나 Exture+와 다를 수 있습니다만 크게 다르지 않을 듯 합니다.거래소 지연의 특징은 접수큐에 후순위로 진입하면 할수록 지연시간은 누적하여 늘어난다는 점입니다. 따라서 ?쟁점은 Queue OrderNumber입니다. 특정종목의 매매체결프로세스는 거래소 회원사의 FEP로부터 오는 모든 전문을 처리하여야 합니다. 예를 들어 회원사가 60이고 ?회원사 당 주문프로세스가 20이라고 하면 1200 개의 프로세스로 부터 주문이 옵니다. 한 세션당 주문이 5건이라고 하면 초당 6000건입니다. 만약 주문접수처리시간이 5밀리초가 걸리면 지연없습니다. 그런데 초당 주문이 10,000건이면 큐대기가 발생합니다. 대기순서가 2라고 하면 그만큼 시간이 더걸립니다. ?그러면 지연이 없는 주문접수시간은 얼마일까요? 거래소가 공개하지 않으니 알 수 없습니다. 어떤 이가 이런 방법을 사용하여 측정하라고 합니다.

?장마감이후에도 ?매매체결프로세스는 계속 동작을 합니다. 장운영정보를 이용하여 FEP에서 주문를 거부하지 않으면 매매체결프로세스로 주문을 보낼 수 있습니다. 이 때 접수응답이 오지 않고 거부응답이 옵니다. 유의미한 데이타를 얻을 때까지 시험을 해서 통계값을 구합니다.

이상으로 얻는 시간이 지연없는 주문접수시간입니다. 모든 주문이 지연없이 접수되는 경우는 없습니다. 앞서 이야기한 Response ProcessTime과 지연없는 주문응답시간을 기준으로 ?주문로그를 통계처리합니다. 예를 들면 25ms가 기준이고 Response ProcessTime이 5ms라고 하면 25, 30, 35, 40, 45,50식으로 응답시간대별 통계를 냅니다. 30 혹은 40이라는 시간대에 분포가 많으면 서비스품질이 좋지 않거나 전략에 문제가 있다는 뜻이겠죠.

4.
이상과 같은 방식으로 측정을 하였습니다. 품질이 떨어지는 서비스일 경우 어떻게 해야 할까요? 전략은 스스로 개발하였거나 발주를 하였기때문에 해결가능합니다. 그렇지만 나머지는 증권사 혹은 거래소의 도움을 필요로 합니다. 시세가 늦은 경우 네트워크환경을 확인해야 합니다. 만약 DMA서비를 위하여 별도로 구성한 경우라면 문제가 없지 않을까 합니다. 증권사 FEP의 지연은 증권사와 협의하여 개선하시면 됩니다. 물론 나타난 통계를 통해 문제가 있는지 없는지는 트레이더 여러분이 타사와 비교를 하든, 전문가와 상의를 하여야 합니다.

제일 어려운 일이 거래소구간의 지연입니다. 사실 대책이 없습니다. 문제가 있다고 하여도 해결할 방법이 마땅하지 않습니다. 앞서 거래소접수시간과 관련한 통계를 내었다고 가정하죠. 대부분의 주문이 30ms이상이라고 합시다. 무엇을 할 수 있을까요? 두가지 원인을 예측할 수 있습니다.

첫째는 주문시그날이 너무 늦게 발생할 수 있습니다. 시세가 늦거나 전략프로그램이 늦거나 혹은 미니원장의 지연이 크거나 하여 거래소매매체결프로세스에 늦게 간 경우입니다. 이 경우는 측정을 통하여 해결할 가능성이 있습니다.

둘째는 거래소구간의 지연입니다. 이 때 일정한 경향을 보인다고 하면 거래소구간일 확률이 높습니다. 예를 들면 한주 혹은 한달간의 통계를 내는 접수평균과 분포가 높은 쪽으로 일정한 흐름을 보인다면 거래소구간일 수 있습니다. 그렇지만 해결할 방법은 없습니다. 그것이 문제입니다. FEP세션을 쉽게 바꾸거나 증권사를 쉽게 옮겨야 하는데 쉽지 않습니다.

이상으로 시론을 마칩니다. 사람들이 별로 하지 않는 이야기라 일부러 오류가 있더라도 정리하였습니다. 지난 몇 주동안 머리를 끙끙 동여매면서 이런 궁리, 저런 궁리한 결과이기도 합니다. 물론 여러분에게 이야기도 들었습니다. ?결론은 “정답없다” 입니다. 정답이 없다는 말은 원인을 찾아서 해결할 수 있는 길이 많지 않다는 말이면서 지속적으로 투자를 해야 한다는 뜻입니다.

모든 주문은 경쟁을 합니다. 같은 증권사 뿐 아니라 다른 증권사와도 경쟁을 합니다. 무조건 빠르다고 수익률이 높지 않습니다. 전적으로 전략에 달렸습니다. 다만 같은 전략일 경우 속도가 빠르면 그만큼 매매체결프로세스에 빨리 가고 원하는 호가로 체결할 확율이 높아집니다. 지연이 제공할 수 있는 기회는 여기까지입니다.