1.
KRX가 알고리즘트레이딩, 고빈도트레이딩(High Frequency Trading)이 주요 흐름이라고 확인하였습니다.
알고리즘트레이딩과 같은 매매 기법을 처리하기 위해 CEP 혹은 ESP기술을 적용하고 있습니다. 금융산업에서 중요한 역할을 하는 IT업체들이 관련 기술을 확보하기 위해 경쟁을 하고 있습니다.
우선 M&A라는 방식으로 기술을 확보하는 경우가 가장 일반적입니다. CEP의 선두업체라고 할 수?있는 Apama는 2005년 Progress Software에 인수되었습니다. 제가 한참 CEP/ESP를 검토하였던 2008년초,?IBM은 Aptsoft를 인수하여 Websphere제품군에 포함시켰습니다. Coral8이라는 CEP업체를 인수하였던 사이베이스가 또다른? 업체인 Aleri를 인수하였습니다.
사이베이스, CEP 선도업체 Aleri 인수
인포매티카,?복합이벤트처리 업체 에이전트 로직 인수
오픈소스진영과 제휴한 경우도 있습니다.? Oracle로 인수된 Bea는 유명한?오픈소스회사인 ESPer와 제휴하여 Weblogic Event Server를 2007년에 발표하였습니다. 오라클이 Bea를 인수한?이후 Oracle Complex Event Processing로 시장에 나왔습니다. 이제 마이크로소프트까지 공식적으로 시장에 진출합니다.
Microsoft To Launch Its Complex Event Processing Engine in May
이미 시세품을 다운로드 받아서 사용할 수 있습니다.
2.
CEP와 ESP를 다른 듯 같은 기술로 다룹니다. 그렇지만 CEP기술은 1980년후반부터 분산환경하에서 시스템들이 발생하는 이벤트들을 분석하기 위해 등장하였습니다. 반면 ESP는 1990년대 중반? DBMS업체들을 중심으로 실시간데이타를 분석하기 위하여 Continuous Query기술을 검토하여 시작하였습니다. ESP는 시간의 경과에 따라 변화하는 이벤트들의 집합인 Stream을 빠른 속도로 분석하기 위한 기술에 중점을 두는 반면CEP는 다양한 장소에서 발생하는 이벤트들의 집합인 Cloud에서 특정한 패턴의 정보를 추출하는 기술에 방점을 두고 있습니다.
때문에 ESP기술을 상업적으로 처음으로 적용한 대상이 알고리즘트레딩을 위한 마켓데이타분석이었습니다.반면 CEP기술은 BAM(Business Activity Monitoring)에 적용되었습니다. (What’s the Difference Between ESP and CEP?중에서 )
지난 몇 년사이에? EDA가 IT의 중요한 화두를 떠오르면서 CEP/ESP는 가장 중요한 기술로 떠올랐고 현재도 성장하고 있습니다.
NinePredictions for the Future of Event Processing (CEP)
Forrester Gives a Welcoming Wave to Complex Event Processing
3.
다시 금융시장으로 돌아오도록? 하죠. 미국이나 유럽의 금융회사들은 알고리즘트레이딩 및 CEP기술을 경쟁적으로 도입하고 있습니다. 제가 등록한 RSS뉴스중 일부입니다.
List?Group Releases CEP and Algo Trading Engine
Quant?Capital Deploys Aleri CEP Technology for Algorithmic Trading
City?Index and Curex Adopt StreamBase CEP
New?ConvergEx algo aims to simplify complex orders
Integral?Development Corp. Jumpstarts FX Algo Development
CEP기술을 기반으로 알고리즘트레이딩시스템이 적용된 금융회사는 삼성증권이 유일하다고 합니다. 2005년부터 Apama제품을 기반으로 한 PowerAlgo를 판매해온 코스콤의 노력(?)입니다. 삼성증권을 제외하면 현재 거의 도입한 CEP기반의 알고리즘트레이딩은 없습니다. IBM, Sybase, Oracle, Altibase과 같이 CEP제품을 판매하는 회사들도 관련된 사례가 아직은 없는 듯 합니다. 비용때문입니다. 아울러 금융IT를 하고 있는 회사가 관련된 R&D을 하고 있다는 기사 혹은 이야기를 본 적이 없습니다.물론 알티베이스와 같은 업체들의 투자는 예외입니다. 관심밖의 기술인 듯 하지만 몇 분이 지속적으로 CEP 및 알고리즘트레이딩에 관심을 보이고 있습니다.
Open, Standard and Tech – calmglow
Finance and Information Technologies
관련된 블로그를 보시면 어떤 회사에서 근무하시는지 나옵니다.(^^) 그러면 금융회사들은?? 최근 VIP용 트레이딩서비스가 증권IT의 화두입니다. 80 대 20의 법칙을 적용한 서비스전략이 VIP서비스입니다.
온라인 트레이딩 서비스 ‘굿아이 HTS(Home Trading System)’도 차별화된 콘텐츠개발과 맞춤형 서비스 제공을 통해 시장점유율이 가파르게 증가하는 추세다. ‘굿아이’의 온라인 트레이딩 부문에서의 우수성은 해외주식 트레이딩에서도 새 지평을 열었다는 평가를 받고 있다. 또 VIP 고객들을 위한 ‘굿아이 드림팀’을 발족,고객별 맞춤 화면 제공과 별도 전용 서버 제공 등으로 고객 만족도를 높이고 있다.
신한금융투자‥펀드·증권 고객 라이프스타일 맞춰 특화 중에서
VIP서비스는 다음과 같은 조건위에서 구성됩니다.
소수의 고객만이 사용하는 전용 서버(일반 서버의 경우 2000명전후의 고객이 동시에 사용)?주문속도를 개선하기?위한 맞춤 화면제공(맵을 이용한 화면개발이 아니라 하드코딩하는 방식)?주문속도를 개선하기 위하여 MMDB나 Shared Memory 이용하여 별도의 주문원장 구성?고객을 위한?별도의 서비스(단말이 아닌 서버단의 Stop-Loss형태의 주문 제공)
이상의 서비스를 전통적인 방식(Multi-Thread Server + Shared Memory 및 하드코딩)으로 개발하는 것도 가능하지만 CEP와 같은 기술을 적용하여 서비스를 구성할 수도 있습니다.? Dolphii님이 Apama로 구현한 Stop-Loss주문을 보면 간단합니다.물론 CEP엔진위에서 Continuous Query를 이용하여 구현하였습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
monitor StopOrder { // 변수정의 Tick tick; NewOrder newOrder; string STOP_SYMBOL := "101F3000"; float STOP_PRICE := 200.0; integer STOP_QTY := 50; // onLoad 는 main 함수라고 생각하시면 됩니다. action onLoad { /* "on"이라는건 이벤트를 수신하겠다는 의미이고, "on all"은 이벤트를 계속 수신한다는 뜻입니다. Tick 이벤트 중에 내가 원하는 종목코드와 가격이 있는 이벤트가 들어오면 "executeStop" 함수를 실행합니다. */ on all Tick(symbol=STOP_SYMBOL,price= STOP_PRICE):tick executeStop; } action executeStop { // 주문 정보 설정 newOrder.symbol := STOP_SYMBOL; newOrder.side := "SELL"; newOrder.price := STOP_PRICE; newOrder.quantity := STOP_QTY; newOrder.type := LIMIT; // "route"는 이벤트를 송신하겠다는 의미입니다. 신규주문을 송신하겠네요. route newOrder; } } |
아마도 Shared Memory를 이용하여 하드코딩하는 것과 비교하면 엄청 차이가 납니다. Agile Service(민첩한 서비스)가 가능합니다. 아쉽지만? 주변에 있는 증권회사나 증권IT회사는 여전히 10여년전에 탄생한 기술을 기반으로 영업을 하거나 서비스를 제공하고 있습니다. 오랜 기술이 무의하다는 뜻은 전혀 아닙니다. 오해가 없기를 바랍니다.
4.
CEP/ESP기술은 다양한 방식으로 확보할 수 있습니다. 가장 손 쉽고 비용이 많이 드는 방법은 관련 제품을 구매하는 것입니다.(^^) 이외에 오픈소스나 대학연구소의 결과물을 이용할 수도 있습니다. 오픈소스중 가장 유명한 제품은 예전에 소개하였던 Esper입니다. Java를 기반으로 Esper와 비슷한 제품이 Jboss에서 제공하는 Drools입니다.
Drool을 이용하여 알고리즘트레이딩을 구현하는 방법에 대한 개념적 접근은 앞서 말씀드렸던 파오리님의 블로그에 정리되어 있습니다.
OpenSource 기반의 Algorithmic Trading System 구축하기 (1)
OpenSource 기반의 Algorithmic Trading System 구축하기 (2)
Open Source 기반의 Algorithmic Trading System 구축하기 (3)
OpenSource 기반의 Algorithmic Trading System 구축하기 (4)
Java기반으로 된 오픈소스제품이 불편하시면 Visual C++로 개발된 오픈소스제품도 있습니다.
TVA’s “openPDC” an Open Source Streaming ProcessingEngine – A complete set of applications for processing streaming time-series data in real-time.
이상과 같은 오픈소스 제품외에? 대학연구소에서 수행한 프로젝트의 자료들도 참고하실 수 있습니다.
MIT/Brown/Brandeis “Aurora” Stream Processing Project
Berkeley’s “Telegraph” Project“
PIPES” Project at University of Marburg
Stanford’s The STREAM Project(Standford Stream Data Manager)
참고할만한 프로젝트들이 너무 많은 가요? 상용제품에 비해 완성도나 성능에서 많은 한계가 있습니다. 그럼에도 기본적인 설계 및 개발사상을 도움을 받을 수 있지 않을까 합니다.
5.
참고로 CEP/ESP와 관련하여 참고자료가 필요하신 분들을 위해 Streambase블로그에 올라온 자료를 소개드릴까 합니다.
CEP 101 for business people: Watch this 1 minute intro video?on CEP, event?processing, and StreamBase.
CEP for IT?architects: Brenda Michelson’s poston event driven architecture is from 2006, but it’s still the best?introduction I’ve seen.
CEP and its use in capital?markets: Visit the high frequency trading?section of the?StreamBase blog.
CEP in depth by?Gartner analyst Roy Schulte: Read?Event Processing: Designing?IT Systems for Agile Companies, by Roy and Mani Chandy
CEP case studies: Real-life stories?from the CME Group(Chicago Mercantile?Exchange), BlueCrest Capital Management, and PhaseCapital
(*)요즘 제안서를 작성하느라 몸이 바쁘네요. 정리가 잘되지 않은 글이라도 이해를 바랍니다.
좋은글 이제사 보게 되었네요. 감사합니다. ^^
1. CEP/ESP가 왜 필요할까요? 개념만 남은것 아닐까 싶은데, 그정도로 금융데이터 소스가 많고 빠른가요? 어짜피 개발속도와 실행속도중 택1이라면, HFT라면 후자일텐데… 저런 일반용도의 솔루션이 나름 최적화된 결과를 주나봐요?
2. 특히, 자바로 된 솔루션 또는 위에 ‘Apama로 구현한 Stop-Loss주문’의 소스처럼, 스크립트로 처리된 코드…와 HFT가 머리속에서 연관이 잘 안됩니다. 실행속도가 필요한 주제속에 개발속도가 잇점인 내용이 포함되어 있어서요. 두마리 토끼를 다잡지는 못할텐데 말입니다.
안녕하세요.
먼저 미국의 CEP/ESP제품들이 초당 처리하는 시세데이타는 최소 1,000,000건을 기준으로 합니다.미국의 자본시장구조가 한국과 달리 민간거래소중심이라 아주 다양한 거래소가 있고 이들 거래소 데이타를 기초로 의사결정을 하여야 합니다. 그래서 한국의 몇만건과 비교할 수 없습니다. 단적으로 옵션트레이딩을 위한 최소데이타 처리기준이 3,000,000건입니다.
한국과 달리 외국은 아주 다양한 거래소로부터 데이타를 받아 가공합니다. Reuter나 Bloomber 혹은 Interactive Data와 같은 데이타벤더들은 여러 거래소로부터 데이타를 공급받아 가공하여 제공합니다. 또한 교차상장은 보편적이고 Dark Pool이나 ECN등을 고려하면 더 늘어납니다.
이에 비해 한국은 그저 KRX 하나만 바라보면 됩니다. 주식을 거래하면 주식만, 파생이고 차익거래 혹은 ELW거래를 하면 선물/옵션시세를 같이 받아야 하지만 그렇다고 초당 틱데이타는 우리가 예상하는 수준을 벗어나지 않습니다. 아마도 5만건이하일 겁니다.
여기서 Shared Memory나 소켓등등을 이용하여 논리를 하나하나 구현하는 경우와 Continous SQL을 지원하는 CEP/ESP는 개발기간과 시장변화에 대한 대응에서 차이가 많을 듯 합니다.
Script라고 하든, SQL이라고 하던 기술적인 핵심은 초당 얼마만큼의 스트링데이타를 처리하여 원하는 패턴의 데이타를 찾을 것인가입니다. 1에서 적었던 것처럼 미국환경에서 발전한 제품이라 HFT에서 요구하는 요건을 충족시킬 수 있다고 생각합니다. 물론 제품마다 전략마다 다릅니다. HFT라고 할 때 Latency를 고려하는 부분이 아주 다양함은 제가 여러글에서 언급하였습니다.
CEP/ESP제품이 CEP/ESP의 전부가 아닙니다. 개념을 프로그램화하는 방법은 다양합니다. 그리고 범용과 트레이딩용은 다를 수 있습니다. Kdb+(Kx systems)는 시세데이타에 특화된 제품입니다. 아주 비싸긴 합니다. 예전에 문의하니까 삼성증권 아니면 상대를 하지 않겠다는 정도였습니다.
한국의 경험을 가지고 외국 환경을 보지 말았으면 합니다. HFT나 CEP/ESP를 도입하고 발전한 나름의 이유가 있으리라 생각합니다. 역사적 맥락, 현실적 근거없는 소프트웨어나 시스템은 없다고 생각합니다.
지금 확인하였습니다. 추석을 잘 보내셨는지요? 외국환경은 잘 몰랐네요. 감사합니다. 저는 뱅킹쪽만 해봐서 증권전산쪽은 뉴비입니다.
‘역사적 맥락, 현실적 근거’ 부분에 대한 고민으로 질물을 드린것입니다. 자바환경을 예를 들면, 제임스고슬링이 엔터프라이즈환경에 자바가 사용될 것이라고 상상도 못했을 것이라 확신합니다. 개발의도가 애플릿으로 대표되는 임베디드용이기 때문입니다. 그러다, WWW빅뱅속에 CGI의 낮은 퍼포먼스와 많은 종류의 서버 플랫폼, 교육용으로 좋은 PL구조 등등의 이유로 인해 ‘유지비용’의 관점에서 고용/피고용인들의 니즈를 맞춘 환경일 뿐이라는 겁니다. 애초부터 성능을 위한 구조가 아니라는 겁니다.
http://goo.gl/uran 이런 기사를 보면, 유지비용이 낮은 솔루션을 선택하는 현실적인 근거 같기도 하는… 엔지니어로서 나음의 좌절감을 느끼지만서두요.
저는 Java냐 C냐라듯이 개발언어가 모든 것을 결정한다는 식의 접근법은 좋아하지 않습니다. 개발언어는 언어일 뿐…
트레이딩시스템을 자바로 만들면 힘들고 C/C++로 만들어야 한다는 생각도 옳지 않습니다.예전에 HiperFX라는 FX트레이딩시스템을 개발할 때 Java환경이었고 외국의 경우도 Java로 된 시스템을 제공하는 것이 많습니다.은행권의 딜러용 플랫폼인 SDP는 실시간웹을 기반으로 제공하고 있습니다.
빅뱅식의 시스템 구축이 더이상 쉽지 않을 때, 언어를 두고 고민하는 것도 없어지지 않을지.
더 중요한 것은 IT의 성격이 변화하고 있다는 사실.