1.
블로그가 주된 일인 줄 아시는 분이 많지만 저는 ZeroAOS를 서비스하는 사업자입니다.(^^) 그래서 일부러 아래글을 항상 블로그 맨위에 고정시켜놓았습니다.
위의 글에서 ZeroAOS환경에서 전략을 개발하는 과정을 설명하였습니다. 첫번째 일은 Strategy Flowchart를 그리는 일이라고 했습니다. 아래는 어떤 블로그에 올라온 분의 전략입니다. 손으로 그린 그림입니다.
무슨 내용인지 알아보기 쉽지 않지만 자신의 생각을 흐름도로 그리면 다른 동료들과 소통하기도 쉽고 개발자와 협력하기도 편합니다. 사실 이런 모델을 만들려면 아주 많은 시간을 투자하여야 합니다.
이제 전략모델을 구체화하였습니다. 어떤 전략이 있습니다. 예를 들어 아래와 같은 전략이라고 해보죠.
위의 전략은 순차적(Sequence)으로 의사결정을 하는 모델입니다. 전략을 시작하여 이벤트가 발생할 때 순서에 따라 의사결정을 하면서 주문시그날을 만듭니다. 이런 전략을 구현할 때 복잡하지 않습니다.?이런 순차적인 전략이 아닌 다른 전략을 살펴보죠.
옆의 흐름도를 보면 좀 다릅니다. Marketcetera에서 가져온 그림입니다. 그림이 의도하는 바는 다르지만 저는 이런 의미로 사용하고자 합니다.
“시세A와 시세B를 받아서 시세A는 전략A와 전략B를 동시에 처리하여 시세B를 받아서 전략C와 전략D를 실행한다”
이를 전산모델로 구현하려고 생각을 해보죠.
우선 시세스위치에서 시세를 받습니다. 멀티캐스트수신입니다. 받은 시세를 각각 2개의 전략이 사용할 수 있도록 분배하여야 합니다. 하나의 프로세스 혹은 쓰레드이므로 통신이 아닌 어떤 방법을 사용하여야 합니다.
ZeroAOS의 요건을 정의할 때 부딪혔던 이슈입니다.어떤 방법이 가능할까요?
2.
병행성과 병렬성이라는 말이 있습니다. Concurrency와 Parallelism입니다. 전산문외한인 저도 한번 정리한 주제지만 art.oriented에서 정의한 내용이 머리에 쏙 들어옵니다.
Concurrency는 프로그램의 성질이고 parallel execution은 기계의 성질이다.
Concurrenty is a property of the prgoram and parallel execution is a property of the machine.
갑자기 병행과 병렬을 이야기한 이유는 앞서 이슈를 두가지 개념으로 풀어야 하지 않을까 생각했기때문입니다. 앞서 그림의 (3)을 보면 시세소스는 하나이고 시세를 사용하는 전략은 둘입니다. 병렬구조를 말할 때 자주 등장하는??single producer multiple consumer(SPMC) Queue구조입니다. 여러가지 방법이 있지만 인구에 회자하는 방법은 Lock Free Algorithm을 적용한 SPMP구조를 만드는 것입니다. Thread프로그래밍을 해본 분들이면 Lock을 자주 이야기합니다. Lock Latency를 줄이는 것도 Low latency를 구현하는 방법중 하나입니다. 그래서 Lock Free라는 말이 등장합니다. 이에 대한 글이 많지만 저같은 비전문가도 읽으면 “아!”하는 글이 있습니다.
An Introduction to Lock-Free Programming
세상에 길이 하나인 경우는 없습니다. 다른 방법도 많지만 이것저것 조사하다 보면 자주 접하는 단어입니다. 이제 이것을 어떻게 적용하여야 할까요? 다시금 앞서 그림으로 가보겠습니다. (1)과 (2)는 미들웨어 – CEP라고 되어 있지만 미들웨어라고 하고 이해하죠 – 를 통하여 전략이 이벤트를 수신(Consumer)합니다. 반대로 (3)은 중간에 Layer를 두지 않고 직접 Queue와 같은 것을 이용하여 Thread간의 데이타교환을 합니다.
두가지 방법을 ZeroAOS에 적용하면 (1)과 (2)는 ZeroAOS가 Multi-Sub-Strategy가 가능한 환경을 제공하는 방식입니다. (3)은 ZeroAOS의 이용자인 트레이더 혹은 개발자가 직접 내부처리를 하는 방법입니다. 서비스의 완성도를 위해서는 당연히 (1)과 (2)의 방식을 택하여야 합니다.
현재 ZeroAOS는 ZeroM을 통하여 실시간이벤트를 수신합니다. 분산환경이면 TCP/IP를 사용하고 로컬환경이면 IPC를 이용합니다. 물론 CPU Affinity를 적용합니다. 앞서 과제를 ZeroM에 적용할 때 TCP/IP이면 문제가 없습니다. Publish/Subscribe가 있습니다. IPC는 보통 Peer To Peer를 위한 방식입니다. 그래서 IPC를 Pub/Sub가 가능한 IPC를 변경하는 일이 필요했습니다. 물론 지금은 지원합니다.
3.
전략의 결과는 매도/매수입니다. 그렇지만 매도/매수라는 의사결정을 내리는 과정은 결과처럼 단순하지 않습니다. 흔히 전략하면 한가지 규칙에 의해 의사결정이 이루어진다고 생각할 수 있습니다. 물론 그런 경우도 있습니다. 마찬가지로 아닌 경우도 많습니다. 각자의 선택입니다. 다만 시장이 그리 단순하지 않다고 하면 전략이 단순할 수 없습니다.
복잡한 시장에 대응하기 위해서는 전략도 순차적인 모델이 아니라 병렬모델이어야 합니다. Multi-Consumer가 가능한 환경을 제공하는 것이 트레이딩플랫폼의 요건이 아닐까 합니다.
