GHTS 개략 설명

국내 증권사의 API는 모두 32비트에서만 호출 가능합니다.

32/64비트 경계를 넘어서 OLE/OCX 간단한 호출하는 방법이 인터넷에 나와있지만,
증권사 API 호출 후 응답을 넘겨받는 데 꼭 필요한 'OLE 이벤트'는 작동하지 않더군요.
그래서, API 호출은 무조건 32비트 프로세스에서 해야 합니다.

(DLL, OLE, OCX 무관하게 32비트이어야 합니다.)

매매 전략 구동을 비롯한 모든 코드를 32비트로 실행해도 괜찮다면,

별도의 프로세스로 분리하지 않고 단일 프로세스 내에서 사용하면 간단하고 좋습니다.

 

그러나, 여하한 이유로 매매 전략을 64비트 프로세스에서 운용해야 한다면

증권사 API 호출을 독립된 32비트 프로세스로 분리한 후 상호 연동 시켜야 합니다.

 

GHTS에서는 다수의 매매 전략을 동시에 운용하는 상황을 상정하고 작성되었습니다.

모든 동시 다중 처리는 디버깅하기 몹시 까다롭기로 유명한

데이터 동시 액세스 충돌(이하 데이터 레이스) 버그 발생 가능성이 상존합니다.

Go언어에서는 이러한 버그를 추적할 수 있는 '레이스 감지기'를 제공하지만 64비트에서만 지원됩니다.

golang.org/doc/articles/race_detector.html

 

매매 시스템의 안정적인 운용을 위해서는

데이터 레이스 상황을 적절하게 디버깅 할 수 있어야 하기에

매매 전략을 64비트 프로세스에서 실행할 수 있어야 한다고 결정했으며,

증권사 API를 호출하는 기능을 별도의 32비트 프로세스로 분리했습니다.

 

그 과정에서 32비트 프로세스와 64비트 프로세스 간 자료교환을 위한 기술적인 문제는 다음과 같이 해결했습니다.

1. Go 자료형을 []byte로 변환
https://pkg.go.dev/encoding/gob

2. []byte 로 변환된 데이터를 전송 및 수신
https://github.com/nanomsg/mangos

RPC로 데이터를 전송하려면 우선 []byte로 변환하는 게 필요한 데, Go언어에는 Gob이라는 내장 변환 기능이 존재합니다.

이렇게 []byte로 변환된 데이터를 프로세스끼리 주고 받도록 해주는 기술로 가장 유명한 게 ZeroMQ입니다.

GHTS도 초반에는 ZeroMQ를 사용했습니다만,

ZeroMQ는 컴파일이 느리기로 유명한 C++언어로 작성된 관계로

ZeroMQ를 적용한 이후 컴파일이 느려져서 전체적인 개발 생산성에 큰 타격을 입었습니다.

 

이를 해결하기 위해서  비슷한 기능의 순수한 Go언어로 작성된 mangos를 채택했습니다.
https://github.com/nanomsg/mangos

이상 GHTS의 내부 구조가 지금처럼 분리된 이유와

이를 위해서 사용하는 의존성 라이브러리를 선택하게 된 이유를 간략히 설명드렸습니다.