2001년과 2012년의 시세데이타

1.
빛보다 빠른 중성미자를 발견했다고 과학계가 들썩이고 있습니다. 이론상으로 시간여행이 가능합니다. 이제 타임머신을 타고 2001년 여의도로 가보죠. 이 때 증권거래소(KSE)가 시세전송방식을 어싱크에서 UDP로 변경하고 호가제도도 5단계호가에서 10단계호가로? 바꾼 때입니다. 증권사마다 발등에 불이 떨어졌습니다. 호가데이타가 대폭 늘어나는 결정입니다.

거래소 시세 정보 전송 방식은 내년 1월 어씽크에서 UDP로 변경된다. UDP방식은 어씽크 방식에 비해 시세 정보 전송 속도가 약 2배 빠르기 때문에 증권사들이 처리해야 하는 시세량은 전체적으로 약 1.5배 늘어나게 된다. 증권사들은 늘어나는 시세 정보 처리를 위해 네트워크를 증설하거나 시스템 업그레이드를 위한 솔루션 도입, 서버 교체 등의 조치를 취해야 하며 대형사들의 경우 이에 대한 비용으로 약 50억원씩을 지출해야 한다.

당시 지점BP를 운용하고 있었기때문에 지점과의 회선 및 서버를 늘리기 위한 투자가 따랐습니다. 당연히 투자를 하여야 하는 증권사는 볼멘 소리를 했습니다. 투자비를 줄이기 위한 솔류션이 필요하였고 두가지 방향으로 대안이 나왔습니다.

하나는 시세압축전송기술입니다. 대표적인 곳이 대신증권입니다.

대신증권은 5일 기존의 시세데이터량을 약 3분1수준으로 줄여서 전송하는 ‘시세압축 전송프로그램’을 개발, 6일부터 사이버투자자들을 대상으로 본격 서비스를 실시한다고 밝혔다.’시세압축 전송프로그램’은 기존의 시세데이터량을 약 3분1로 줄여서 보내는 기술로, 투자자들이 받아보는 시세전달속도가 과거보다 2배이상 높아지고, 개인투자자 컴퓨터의 안정성도 개선되는 효과가 있다.

대신증권외에도 미래로가는길과 같은 회사는 자체솔류션을 개발하여 판매하였습니다. 대신증권이나 미래로가는길이 어떤 압축알고리즘을 사용하였는지 알 수 없지만 데이타량을 줄여서 투자를 절감하자는 목적은 동일하였습니다.

다른 하나는 메시징제품인 Smartsocket의 Reliable Multicasting을 이용하는 방법이었습니다. 기억하기로 국내에 적용된 사례가 없습니다.(^^)

2.
다시 타임머신을 타고 현재로 돌아옵니다. 2012년 초 한국거래소는 차세대시세분배시스템을 개통합니다. 대역폭을 늘리면서 데이타의 전송량을 대폭 늘린다고 합니다. 아울러 이벤트가 발생할 때마다 호가를 제공하는 방식을 적용한다는 이야기도 들립니다. 이럴 경우 어떤 변화가 있을지 아래에서 정리하였습니다.

ATS시대와 트레이딩시스템(1)

물론 위의 글은 ATS도입에 따른 변화를 분석했지만 현재 Exture에서 호가를 이벤트단위로 제공할 경우 얼마만큼 데이타가 늘어나는지도 분석하였습니다.물론 추론일 뿐입니다. 최소한 2001년 변화이상의 영향을 줄 듯 합니다. 현재 차세대 시세분배시스템때문에 여러가지 투자를 진행하고 있는 듯 합니다. 2001년 당시 지점전용선의 대역폭을 높이는 방향이라고 하면 지금은 사내 백본의 대역폭을 1G에서 10G로 높이는 쪽인 듯 합니다. 이석이조의 효과를 올릴 수 있는 투자입니다. 주문속도를 개선하는 부수입(?)도 있습니다.요즘 하드웨어나 네트워크장비의 성능이 좋기때문에 투자여력만 있다고 하면 문제가 되지 않습니다.

그렇지만 투자는 이것으로 끝이 아닙니다. 2001년처럼 지점전용선은 아니지만 인터넷접속자를 위하여 대역폭을 늘리는 투자를 하여야 합니다. 이 또한 비용의 문제입니다. 비용이 아닌 대안이 필요한 영역이 있습니다. HTS 투자자들의 PC입니다. ?최근에 나온 인텔의 i7과 메모리가 4G이상인 PC를 사용하는 투자자처럼 일정 성능이상의 컴퓨터를 사용하는 투자자들은 문제가 없습니다. 그렇지만 노후한 기종의 컴퓨터를 사용하는 투자자는 다릅니다. 시세를 처리하려다 PC가 엄청 느려지는 현상이 발생하니까 증권사 콜센터로 전화를 막 합니다. 투자자의 불만이 쌓여갈 수 밖에 상황입니다.

증권IT부서가 대안을 내놓아야 합니다.여러가지 방법이 가능합니다. 어떤 자리에서 잠깐 듣기로 차세대호가를 처리하는 포트를 따로 둘 예정이라고 증권사도 있다고 합니다. 아마도 PC의 사양을 고려하여 차세대호가를 처리할 수 있는 경우엔 해당포트를 통하여 데이타를 처리하고 그렇지 않으면 현재방식대로 처리하려는 모양입니다. 나름 타당하다는 생각을 했습니다. 단 한가지 약점이 있습니다. HTS와 관련된 시스템을 수정하여야 합니다.

우선 2001년에 적용하였던 방법을 다시금 살펴보았으면 합니다. 2001년에 어떤 압축기술을 적용하였는지 모르지만 국제적으로 보면 크게 두가지 기술을 시세데이타 압축에 사용합니다. Zlib와 FAST입니다. 이와 관련되어 FIX위원회의 FAST Protocol 토론방에 올라온 글을 소개합니다.

ZLIB is a generic text compression library based on the LZ77 (Lempel Ziv 1977) family of compression algorithms. It allows you to compress any message stream without reconfiguration or adaptation so in that sense ZLIB is less complex to deploy. I would argue that this difference is small given that the implementation of a feed is content specific anyway.The implementation (ie. the code) of FAST and ZLIB respectively are fairly complex but (having implemented both) I believe FAST is easier to implement than ZLIB.

ZLIB and ZLIB-like implementations have been used by the CME, OMX (SAXESS and CLICK), Nasdaq (ITCH) and others. As far as I know, CME has discontinued its use of ZLIB and OMX has discontinued at least some of their use of a ZLIB-like implementation. Not sure if ITCH compression is still being offered.

The big drawbacks with ZLIB is its relatively high processing overhead and its reliance on a long history of data to compress effectively. As a consequence ZLIB in not well-suited for high performance situations nor when UDP over multicast is used.

It has been shown that the processing overhead of ZLIB is more than 30 times higher than FAST in some use cases. The compression ratios of ZLIB and FAST are comparable for TCP streams and FAST has much better compression efficiency for in the UDP case.

In summary, if you plan to provide a low to medium thruput market data feed which is not latency sensitive and you plan to use TCP as your transport, then ZLIB could used to compress your data.

For other scenarios I would recommend that you review the commercial alternatives available for deploying a FAST-based feed.
Use zlib for market data중에서

시세데이타 압축이란 발상이 비단 한국뿐 아니라 세계 어디에서도 고민하는 공통의 과제라는 점을 보여줍니다. 그리고 2001년 발표된 기술들이 그리 독창적이지 않았다는 점도 알 수 있습니다. 그렇지만 한발 더 나아가면 Zlib를 이용한 기술이 FAST로 이어졌다는 점입니다. 시세데이타 포맷을 표준화하려는 노력을 주도하였던 SIIA FISD는 MDDL Streaming이라는 표준을 내놓았습니다. FAST와 비슷합니다. 반복되는 부분을 없애고 압축하는 방식입니다. MDDL의 ?Streaming기술이 FAST Protocol로 이어졌다고 생각합니다. 시장의 요구를 IT담담자들이 중지를 모아 표준을 만든 사례입니다.

하여튼 Zlib와 달리 CPU오버헤드가 작은 FAST를 도입하는 것이 앞서 문제를 해결하는 한 방법일 수 있습니다. 더불어 Exture+도 지원하겠다고 한 표준이기때문에 시도할 필요는 있습니다. 다만 FAST의 경우 데이타순서가 매우 중요합니다. 사슬처럼 서로 연결되어 메시지를 Decoding하여야 하기때문입니다.

3.
앞서 인터넷회선망의 대역폭을 늘리는 투자가 필수적이다고 하였습니다. 아무리 별도의 포트를 둔다고 하더라도 현재 실시간데이타전송이 Point-To-Point로 이루어지는 한 어쩔 수 없습니다. 이와 비슷한 고민을 하였던 곳이 있습니다. 웹하드서비스를 제공하는 업체들입니다. 동영상을 다운받으려고 수만의 이용자가 한 서버에 접속을 하려고 하니까 부하를 견디지 못하는 일이 발생하였습니다. 이 때 등장한 것이 Torrent와 같은 개념입니다. 이용자가 동의하면 이용자PC를 전송서버로 사용하는 알고리즘을 적용하였습니다.

해결하려는 지점은 단순합니다. 중앙서버로 몰리는 시세전송부하를 분산하는 것입니다. 대역폭 부하를 줄이는 기장 기본적인 방법은 ?P2P 대신에 Multicast를 적용하면 됩니다. 그렇지만 사내구간이 아닌 인터넷구간에서 멀티캐스팅을 적용하기 힘듭니다. 만약 지금도 증권사 지점BP(권역별 BP)가 있다고 하면 이를 이용하는 방법이 방법이 되지 않을까 합니다. 권역별로 Internet Streaming Service를 제공할 수 있는 기능을 두는 방식입니다. 이럴 경우 서비스 구성을 단순히 하려면 현재 HTS서버와 같은 구조가 아니라 메시징미들웨어를 적용하는 것이 손쉬울 듯 합니다. 권역별 스트리밍서버에 Market Data Feed Handler와 ?MOM을 두고 HTS클라이언트는 Pub/Sub방식으로 해당되는 종목만 받도록 하면 됩니다. 이런 방법이 의미가 있다고 생각하면 저에게 문의를 하셔도 됩니다. ZeroFeeder와 ZeroM 및 시세API를 사용하면 됩니다.(^^) 잠시 영업이었습니다.

좀더 폭넓은 시각으로 접근할 수 있습니다. 시세스트리밍서비스를 아웃소싱하는 방식입니다. 일본TSE가 Arrowhead를 도입한 후 온라인증권사중 일부가 전호가서비스를 아웃소싱하였다는 사례를 소개한 적이 있습니다.

Arrowhead와 증권산업구조조정 2

이와 비슷한 모델을 만들어보는 것도 좋지 않을까 합니다. 지난달 말부터 다음,네이버와 같은 포탈들이 시세데이타 실시간서비스를 제공한다고 합니다. 물론 코스콤으로부터 인터넷으로 시세를 받아 고객에게 제공하는 서비스입니다. 포탈들이 조금더 투자한다면 Market Data Internet Streaming Service가 가능하지 않을까 생각합니다. 코스콤도 물론 가능할 듯 합니다. 실시간시세서비스와 같은 부담을 주는 서비스를 아웃소싱하고 주문서비스에 집중하는 것도 방법입니다.

4.
시간이 흘러도 비슷한 문제는 계속 발생합니다. 증권사가 Knowledge Base가 있으면 이를 통하여 지식전수를 할 수 있지만 그렇지 않으면 경험에 의합니다. 2001년도 과제와 2012년도 과제가 동일하지 않습니다. 그렇지만 해결의 시작은 비슷하지 않을까 합니다.

그런 뜻으로 이런저런 상상을 해보았습니다.