DMA가이드라인 이후 레이턴시 경쟁력은?

1.
ELW시장 건전화방안을 보고 신문에 보도된 증권사의 반응은 아주 의외인 경우도 있습니다.

이에 대해 증권사 파생상품 관계자는 “스켈퍼와 일반투자자의 차이는 실제로는 라인 속도 등의 문제가 아니였다”며 “이미 배경지식이나 실력이 동등하지 않기 떄문에 수익에서 차이가 나는 부분이 많았던 것”이라고 말했다.

위의 관계자는 솔직하지 않네요. 속도가 문제가 아니라고 말하면서 왜 속도가 달라지는 DMA가이드라인을 비판합니다.

ELW시장 건전화방안에 담긴 DMA가이드라인을 적용하면 어떤 현상이 발생할까요? 우선 레이턴시에 아주 중요한 영향을 미치는 방화벽을 추가한 상태로 금융위의 주문흐름도를 재구성하도록 하겠습니다.

위의 그림에서 맨오른쪽 방화벽 우측은 STOCKNet으로 KRX 및 코스콤이 관리하는 영역으로 증권사가 개입할 수 없는 영역입니다. 그동안 DMA서비스는 방화벽 좌측 주문전달서버(FEP)를 둘러싼 영역에서 이루어졌습니다. 최고의 혜택을 받았다고 하는 경우를 보면 전용 주문전달(FEP)프로세스를 이용하고? 주문프로세스를 FEP서버(하드웨어)에 위치하도록 하였습니다. 알만한 사람들은 아는 공연한 비밀이었습니다. 이제 주문관련 서버를 두번째 방화벽 좌측 = DMZ(DeMilitarized Zone)으로 이동하여야 합니다.

2.
그동안 레이턴시를 줄이기 위한 여러가지 시도가 있었습니다. DMA가이드라인 이후 새로운 과제가 눈앞에 떠오릅니다. DMZ와 내부구간을 연결하는 방화벽(Firewall)입니다. 이와 관련하여 좀 오래되었지만 2008년에 나온 자료를 하나 살펴보도록 하죠. Net2S Research는 Latency가 발생하는 주된원인이 네트워크보다는 어플리케이션 및 방화벽이라고 주장합니다.

Most financial institutions have tuned their networks or taken advantage of proximity hosting solutions. The network, on average, contributes to just 13% of a system?s overall latency. This is now the second smallest contributor, below messaging (at just 2%). The new latency culprits are the applications at 65%, and firewalls at 20%; which together contribute to 85% of overall latency today.

“Latency is produced at numerous steps in the trade processing chain, however it can be simplified into three main layers; the network, the middleware and the applications. Our research sought to dispel some of hype that circle? around the industry, and reveal the true landscape of latency requirements across all lines of business,” states Andrew Staniforth, Senior Consultant at NET2S and lead researcher of the study.

방화벽이 차지하는 비중이 20%입니다. DMZ구간에서의 Latency경쟁으로 변화한 상황에서 얼마나 성능좋은 방화벽을 사용하느냐가 중요한 경쟁력이라고 할 수 있습니다. 더구나 시세데이타이 점점 늘어납니다. 현재 기준으로 최적화된 방화벽이라도 시세량이 두배에서 네배까지 늘어나면 성능을 보장할 수 있을지 점거해야 합니다. 그래서 UDP/TCP Throughput 및 Latency가 좋아야 합니다. FortiGate가 내놓은 벤치마크 데이타는 놀랍다고 생각합니다. 10마이크로초 아래의 결과입니다.

Announced that latest benchmark tests show its FortiGate-3950B enterprise multi-threat security appliance has achieved 120 Gbps of low latency firewall performance using stateless UDP traffic and 114 Gbps of performance using stateful TCP application traffic. The tests were conducted with packets of all sizes, including 64,512 and 1518 byte packets, and showed performance of 170 million packets per second — more than 10 times faster than competitive products based on price/performance. The amount of latency introduced by the FortiGate-3950B was minimal, at 9.1 microseconds, and CPU utilization was also almost zero percent.

현재 보유하고 있는 방화벽을 놓고 비슷한 테스트를 해보시면 좋지 않을까 합니다. 사실 FortiGate사 제품은 아래 규정을 충족시키지 못하여 금융기관에서 사용할 수 없다고 합니다.

②제1항제1호의 침입차단시스템을 설치하는 경우 다음 각 호의 사항을 준수하여야 한다.

1. EAL3+등급(단, 개인정보 또는 금융회사의 주요정보가 수록되지 않은 전산장비를 보호하는 경우에는 EAL2 등급) 이상의?평가?인증(보안장비 인증을 담당하는 국가기관이 부여한 K4 등급은 EAL3+ 등급으로, K2 등급은 EAL2 등급으로 본다. 이하이 조에서 같다) 또는 감독원장이 인정하는 기관의 평가?인증을 받았거나 이에 준하는 것으로 감독원장이 인정하는 장비의 사용

2.
앞서 결과중 첫번째는 어플리케이션과 관련된 영역입니다. 이 부분은 두가지를 같이 검토하여야 합니다. 첫째는 분산환경으로 처리되는 업무와 그렇지 않은 부분입니다. 분산환경으로 처리되는 업무는 TCP/IP를 통하여 데이타통신을 할 수 밖에 없는 주문프로세스 -방화벽 – 주문전달(FEP)프로세스 및 시세수신프로세스-방화벽-시세스위치입니다. 이상은 10G환경으로 전환하거나 TOE기능을 지원하는? RNIC을 도입하여 시험하는? 것이 필요할 듯 합니다.

다른 한부분은 Inter-Process부분입니다. HTS를 설계할 때 대부분의 업무를 분산환경에서? 처리할 수 있도록 TCP/IP를 사용합니다. 물론 Domain Socket을 이용하는 경우도 있지만 기본은 TCP입니다. 그렇지만 Low Latency를 추구할 때 TCP은 중대한 지연요소입니다. 더구나 멀티코어시대가? 도래했기때문에 분산환경으로 처리할 업무도 하나의 서버에 처리가능합니다. 때문에 공유메모리나 IPC가 무척이나 중요해집니다. FIX Protocol의 FIPL은 이렇게 주장합니다.

Increasingly, said Henry Young, co-chair of FIX Protocol Inter-Party Latency Working Group and director of product development at latency measurement specialists TS-Associates, they will be forced to analyse the latency within their applications rather than over the networks that connect them.

As such, argued Young, application taps ? which measure the latency between functions within an application ? will grow in importance over network taps, as the industry reduces distributed architecture in a move to interprocess communications (IPC) and memory communications.

In order to properly monitor and analyse their low-latency solutions, firms will need to focus on potential bottlenecks in their systems. Rolf Andersson, co-chair FIX Protocol Market Data Optimisation Working Group and CEO at Pantor Engineering AB, said latency comes from a number of different areas in the process, from processing and communications overheads to scheduled latency, so precise measurement is needed to understand these various bottlenecks and optimise latency.

Part of understanding and measuring these bottlenecks requires implementation of application taps rather than network taps, Young said. Before, where firms had ‘daisy chains’ of servers, it was far easier to monitor the process and determine the cause of latency. Now, distributed architectures mean there is less latency to look at on the wire and thus network taps are harder to implement.

Network taps will then struggle to identify latency difficulties with the functions in a single section at the software component level, he said, hence the need for an application tap arises to monitor latency differences on this level rather than the server level.
Inter-Process Delay Emerges as Key Latency Challenge중에서

개발자분들은 다 아시는 내용이죠? 그렇지만 IPC나 Shared Memory를 OS에서 제공하는 라이브러리를 이용하여 개발하면 남과 다른 결과를 얻을 수 없습니다. 여기에 어려움이 있습니다. 메시징제품들이 서로 경쟁적으로 IPC를 개발하는 것도 이런 이유입니다.

DMZ구간으로 이동을 하든, 아니면 원래 DMZ에서 운영을 하든 증권사는 새로운 가이드라인에 따라 레이턴시측정을 해야 하지 않을까요? 그렇다면 위에 이용한 Net2S의 자료중 아래대목을 참고하시길 바랍니다.

It is essential for financial institutions to ensure time and resources are used to analyze their own business needs and choosing the right?solutions for different areas of the business. There are achievable and highly effective latency strategies to improve trading entities performance.

Firstly know the environment ” look step by step what components are traversed through the entire trade flow. Look at the network, hardware and applications and put measurement metrics in place: ideally end-to-end where possible, but inferred latency step-by-step is a good starting point. That may mean some applications have to be?modified to generate latency statistics. Sort out each step in the decreasing order of latency contribution, and compare each one of them against the industry benchmarks.

Secondly, keep it simple. Eliminate every non necessary step in the business flow as complex architectures are never fast and demutualise each bit of the infrastructure which has a reasonable cost.

Finally, optimize what you have. Take the big latency contributors (usually pricing or order management applications) and break them in two flavors: a reduced, low latency version for the instruments/activities that are latency sensitive, and a full version with rich functionality for the other products. But if that is still not enough, consider moving some of your chain outside of the firewall (risk/performance trade-off). Also consider lateral thinking such as?sensitivity pricing instead of accurate calculations for pricing apps and only use multicast middleware where strictly necessary (7+ subscribers per item).
Electronic Trading: The Latency Challenge 중에서

3.
레이턴시를 줄이기 위한 다양한 모색이 있었습니다. 아래와 같은 경우가 있었습니다.

특정한 트레이더들의 주문시스템이 주문전달서버(FEP)와 함께 위치한 경우
주문시스템을 DMZ에 위치하지 않고 내부구간에 위치하는 경우

금감위의 DMA가이드라인은 위와 같은 경우는 불법으로 규정하고 있습니다. 불법으로 규정된 방법으로 서비스하고 있는 현재의 DMA서비스는 모두 가이드라인이 효력을 발휘하는 7월이후부터 DMZ구간으로 모든 서버를 이동하여야 합니다.? 코로케이션서비스를 이용하던 트레이더들은 DMZ구간으로 서버를 이동하여야 하고 프로세스를 이용하던 트레이더들은 서버를 마련하거나 서버임대와 관련한 계약을 맺고 DMZ구간으로 옮겨야 합니다.

금융위원회와 금융감독원이 이와 관련된 부분을 어떻게 확인할지 향후 대책이 궁금합니다.