해외 주식 API 발견. (한국투자증권 Open API)

GHTS 2022. 1. 21. 18:56 Posted by UnHa Kim

그동안 이베스트투자증권의 Xing API를 이용해서 국내 주식만 매매해 왔다.

한국 증시는 부진을 거듭하는 반면, 해외 증시(특히, 미국 증시)는 상승세를 이어가는 걸 보면서,

한국 주식 시장에만 투자하는 것은 분산 투자 면에서도 별로 좋은 생각이 아니라는 것을 깨달았다.

그리하여, 해외 주식 투자도 가능한 API를 찾던 중 발견한 게 

한국투자증권의 Open API이다. ('efriend Expert'로 검색해도 된다.)

 

API 기능을 설명하는 'efriend Expert Viewer'의 화면 일부를 캡쳐했는 데,

미국 뿐만 아니라, 중국, 일본 주식도 매매가 가능한 것을 알 수 있다.

문제는 이게 OCX형태로 구현되어 있어서 Go언어에서는 사용하기 무척 까다롭다는 것이다.

 

그렇다고 해서 모든 로직을 C#으로 옮겨가려고 하니, 정든 Go언어를 손에서 내려놓고 싶지 않다.

결국, OCX호출에 편한 C#로 API를 호출하는 독립된 프로세스를 두고,

Go언어로 작성된 매매 전략 모듈에서 윈도우 소켓을 통해서 호출하는 구조를 구상 중이다.

(투자 교육 때 뵌 현직 옵션 시스템 트레이더 분에게서 윈도우 소켓 프로그래밍에 대해서 들었던 게 중요한 힌트가 되었다.)

 

역시 끊임없이 삽질을 거듭하다보면 길을 찾게 되는 것 같다.

 

댓글을 달아 주세요

C언어 컴파일러 의존성 제거.

GHTS 2021. 7. 10. 06:55 Posted by UnHa Kim

GHTS는 과거 이베스트 증권사 API를 호출할 때

C언어를 통한 cgo방식(https://blog.golang.org/cgo)으로 하다가,

Go언어를 통한 DLL 방식(https://github.com/golang/go/wiki/WindowsDLLs)으로 갈아타면서,

2021년 1월경, 거의 모든 C언어 코드를 Go언어 코드로 대체하였다.

 

그러나, 몇몇 cgo특수 함수(C.GoBytes()등)가 남아 있어서 

GHTS를 사용하려면 여전히 C언어 컴파일러가 필요했고,

이는 GHTS를 처음 사용하는 사람에게 설치 난이도를 높이는 진입 장벽으로 작용하였다.

 

오늘 드디어 마지막 남은 cgo 특수 함수를 대체해서

더 이상 C언어 컴파일러를 설치하지 않아도 GHTS를 사용할 수 있게 되었다.

 

구글을 조금만 더 열심히 검색했더라면 금방 해결책을 찾을 수 있었을 텐데,

괜히 혼자 해결책 궁리하다가 너무 오래 걸린 것 같아서 아쉽긴 하지만,

뒤늦게라도 사용 편의성을 향상할 수 있어서 다행스럽다.

 

노하우가 중요한 시대가 아니라

적절한 구글 검색어를 생각해 내는 게 중요한 시대가 되었다는 것을 다시 한 번 실감한다.

 

 

 

 

댓글을 달아 주세요

  1. GrayrabbiT 2021.07.10 13:37 신고  댓글주소  수정/삭제  댓글쓰기

    와... 그럼 이제 golang 만으로되는거군요..
    전 너무 힘들어서 그냥 c#으로 갈아탔네요.

  2. UnHa Kim 2021.07.10 14:37 신고  댓글주소  수정/삭제  댓글쓰기

    해결이 너무 늦어서 죄송합니다.
    개발자가 문제를 제때 해결하지 못하면 다른 루트를 찾는 건 잘 하신 겁니다.
    어쨋든, 덕분에 문제점을 인식하고 해결책을 고민하게 되는 계기가 되었으니, 이후 다른 분들은 좀 더 편하게 사용할 수 있을 것 같습니다.
    감사합니다.

GHTS 개략 설명

GHTS 2021. 1. 13. 18:56 Posted by UnHa Kim

국내 증권사의 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://github.com/ugorji/go

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

RPC로 데이터를 전송하려면 우선 []byte로 변환하는 게 필요한 데,

여러가지 자료형 변환 중 가장 유명한 구글의 '프로토콜 버퍼'는

각 자료형을 정의하는 IDL파일을 작성해야 합니다.

구글 '프로토콜 버퍼'와 비슷한 기능을 하되 IDL 작성이 불필요한 방식으로는

(Go언어의 자료형 선언이 그 자체로 IDL 역할을 함.)

JSON과 MsgPack형식이 있는 데,

JSON은 호환성은 높지만 텍스트 방식이어서 효율성이 낮은 관계로,

바이너리 방식인 MsgPack을 선택했습니다.

Go언어에서 MsgPack 변환을 해 주는 go/codec 패키지 라이브러리를 사용했습니다.


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

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

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

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

 

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

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

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

댓글을 달아 주세요

  1. 익명 2021.01.14 21:58  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • UnHa Kim 2021.01.18 15:40 신고  댓글주소  수정/삭제

      확인해 보니 C언어 컴파일 의존성을 완전히 없앨 수는 없네요.

      API호출 과정에서 얻은 C 데이터를 Go 자료형으로 변환하는 과정에서 C언어 컴파일러의 도움이 필요하네요.

      정확히 말하면 cgo 패키지의 일부 특수 함수가 필요합니다.

      좀 더 확인하지 못한 점 죄송합니다.

    • UnHa Kim 2021.07.10 06:27 신고  댓글주소  수정/삭제

      이미 많은 시간이 흘러서 별 상관 없겠지만 혹시나 해서 추가 해 놓습니다.
      기존에 사용하던 cgo 특수 함수를 모두 순수 go언어 함수로 대체해서,
      C언어 컴파일러 의존성을 없앴습니다.

      https://ghts.tistory.com/51

  2. GrayrabbiT 2021.01.17 19:40 신고  댓글주소  수정/삭제  댓글쓰기

    댓글달아 주셔서 감사합니다. 혹시 깃 코드와 설명을 보다 의문이 나면 댓글로 여쭈어보아도 될까요?

    파이썬으로 돌아가려다가 왠지 go로 해보고 싶은 의지가 생겨버려서요. golang 엄청 재미난 언어네요..ㅎ

    • UnHa Kim 2021.01.17 19:52 신고  댓글주소  수정/삭제

      가끔 블로그 사이트 들를 때마다 확인해 보도록 하겠습니다.

      저도 다른 사람에게 피드백 받아보는 게 처음이라서 얼마나 할 수 있을 지는 모르겠습니다만,
      참신한 경험이라서 아직은 할만 합니다.

      티스토리 방명록은 추가했습니다만,
      질문/답변 게시판 추가하는 걸 모르겠습니다.

    • UnHa Kim 2021.01.17 20:03 신고  댓글주소  수정/삭제

      파이썬은 나중에 성능 문제가 발생하면 고성능 언어로 처음부터 새로 작성해야 할지도 모른다는 불안감과
      동적 자료형 때문에 버그가 발생해도 모르고 지나갈 수 있다는 불안감이 존재하죠.

      Go언어는 정적 자료형이기 때문에 사소한 버그는 미리 찾아낼 수 있으면서, 속도도 C언어 절반 정도로 파이썬보다 수백배 빠르기 때문에 성능 걱정 없구요.
      컴파일이 빨라서 개발 생산성도 괜찮은 데다가,
      무엇보다 동시처리가 간편한 게 다중 매매 전략 운용에 너무 편할 것 같아서 선택했습니다.

      동시처리를 콜백함수로 짜면 거의 지옥인데, (안 당해 보면 모릅니다.) 고루틴을 이용하면 일반적인 순차적 프로그래밍을 할 수 있어서 엄청 편합니다.

      요즘 파이썬도 비동기 프로그래밍 기능을 많이 보강했다고 하니까 이건 제가 잘못 알고 있을 수도 있습니다만,
      Go언어는 preemptive 동시처리이라서 await 같은 거 신경 안 써도 되니까,
      동시처리에서는 더 편한 것 같습니다.

      대신,
      Go언어는 OLE/OCX등 윈도우 기술과 호환성이 안 좋습니다.
      무엇보다 에러처리가 X 같습니다.
      줄줄이 if문으로 확인하거나,
      panic recover defer로 try-catch 비슷한 효과를 낼려고 해도 일일이 에러 확인을 해 줘야 합니다.

      Go언어에 제너릭(Generic)이 추가되면 에러 처리가 획기적으로 편해질 거라고 다들 기대하면서 버티고 있죠.

      빠르면 올해 말이나 내년에 Go언어에 제너릭이 추가된다고 하던 데, 저도 상당히 기대 중입니다.

  3. 익명 2021.01.17 20:38  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • UnHa Kim 2021.01.17 20:57 신고  댓글주소  수정/삭제

      TR이란 TRansaction의 약자입니다.

      증권사와 사용자 컴퓨터 간의 상호작용을 의미합니다.

      사용자는 증권사 서버에게 자기가 원하는 작동을 TR코드를 통해서 명시합니다.

      예를 들면,
      현재 서버 시각을 알고 싶다면 t0167
      현재가를 알고 싶다면 t1101
      주문을 넣고 싶다면 CSPAT00600
      등이죠.

      이베스트 TR코드는 API 패키지를 설치하면 함께 설치되는 DevCenter를 참고하세요.

    • UnHa Kim 2021.01.17 21:19 신고  댓글주소  수정/삭제

      자주 사용하는 TR코드

      현재가 : t1101/t8407
      호가 : t1102
      주문 : CSPAT00600/CSPAT00700/CSPAT00800 (정상/정정/취소)
      계좌 평가액 : CSPAQ12200
      보유 수량 : CSPAQ12300
      주문 가능 금액 : CSPAQ22200
      일일 가격 정보 : t1305/t8413
      전체 종목 코드 : t8436
      현재 서버 시각 : t0167

  4. Kyu1234 2021.10.28 12:59 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요, github에도 issue 남기긴 했는데, 혹시 사용하시는 xing dll 버전이 어떻게 되시나요?

  5. UnHa Kim 2021.12.05 13:55 신고  댓글주소  수정/삭제  댓글쓰기

    답변이 늦어서 죄송합니다.

    DLL이 업데이트 되면서 구조체에 필드가 추가되는 경우가 있는 데,
    그럴 경우 헤더 파일을 업데이트 한 후,
    소스 코드도 관련 필드를 읽어들이도록 좀 수정해야 합니다.
    그게 매번 업데이트 공지 사항을 모니터링 하지 않으면 필드가 추가되었는 지 모르니까 해당 프로세스를 빼먹습니다.

    말씀하신 항목은 수정해 놨습니다.
    사용해 보시고 문제 있으면 알려주십시오.

어제, 오늘, 금일, 당일, 전일.

GHTS 2019. 10. 10. 12:17 Posted by UnHa Kim

간단한 용어이지만 혼동을 유발하는 경우가 있어서 메모해 놓는다.

 

금일, 어제는 주말, 공휴일등 모든 일자를 포함해서 지칭하지만,

 

주식매매에서 '당일', '전일'은 증시 개장일만 고려해서 지칭한다.

 

 

- 당일 : 가장 최근 영업일.

 

- 전일 : 당일 이전 가장 최근 영업일.

 

금일이 개장일이면 '당일 == 금일'이다.

 

금일이 (주말, 공휴일 기타 이유로) 개장일이 아니면 '당일 != 금일'.

 

 

간단하지만 혼동되는 용어라서 정리를 해 보았다.

 

 

'GHTS' 카테고리의 다른 글

C언어 컴파일러 의존성 제거.  (2) 2021.07.10
GHTS 개략 설명  (11) 2021.01.13
어제, 오늘, 금일, 당일, 전일.  (0) 2019.10.10
소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07

댓글을 달아 주세요

소스코드 패키지 통합

GHTS 2019. 7. 27. 10:02 Posted by UnHa Kim

Go언어에서 GOPATH 의존성 시스템에서 Go모듈(Module) 시스템으로 넘어가면서,

 

그간 각각의 독립된 패키지에서 개발하던 기능들을

 

하나의 패키지로 모두 통합하고,

 

각각의 기능은 서브디렉토리에 분류하게 되었다.

 

 

GHTS 라이브러리를 불러다 쓰는 입장에서도

 

Go모듈 방식을 채용할 경우 버전 관리등이 한결 편해질 것으로 예상된다.

 

예전에 개발하던 개별 패키지들은 모두 삭제했으며,

 

통합된 패키지의 주소는 다음과 같다.

 

https://github.com/ghts/ghts

 

 

'GHTS' 카테고리의 다른 글

GHTS 개략 설명  (11) 2021.01.13
어제, 오늘, 금일, 당일, 전일.  (0) 2019.10.10
소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07

댓글을 달아 주세요

Xing API 현물 주식 주문 TR 테스트 완료.

GHTS 2018. 6. 25. 12:30 Posted by UnHa Kim

Xing API 현물 주식 주문 TR 기능 구현 후,

테스트를 진행하던 중 정정 및 취소 주문에서 에러가 발생해서,

오랜 시간동안 디버깅을 진행했다.


증상

정상 주문TR 실행 후 즉시, 정정 및 취소 주문 TR을 실행할 경우 에러가 발생.

정상 주문TR 실행 후 0.5초 가량 지난 후, 정정 및 취소하면 에러가 없음.


이유

정상 주문TR을 실행한 후 증권사 서버에서 응답을 받았더라도,

거래소 서버에는 아직 등록이 되지 않은 상태에서,

정정 및 취소 주문 TR이 오면 에러가 발생함.

0.5초 가량 기다리면 거래서 서버에도 등록이 되므로,

에러가 발생하지 않음.


해결책 

1. 0.5초 기다린다.

   : 0.02초에 주문이 실행되는 컴퓨터 매매 세계에서 0.5초는 기다리고 있기에는 너무 긴 시간.

   : 뭐라도 해야 한다.


2. 주문 체결 실시간 정보 확인

  : 거래소 서버에 등록이 된 것을 확인해 주는

   실시간 정보(SC0, SC1, SC2, SC3, SC4)를 수신한 이후에 정정 및 취소하면 에러 없음.

  : 실시간 정보가 UDP로 전달되므로, 패킷 로스로 인해서 제대로 전달되지 않을 가능성 존재.

  : 알고리즘이 복잡해 짐.


3. 단순 무식 반복.

  : 정정 및 취소 주문을 낼 때, 

    '잘못된 원주문번호' 내지 '주문 등록 대기 상태'라는 에러가 발생하면,

    정정 및 취소 주문TR 재실행.

 : TR 실행 및 응답은 TCP로 전달되므로, 항상 정확하게 응답을 받을 수 있다.

 : 에러 메시지를 보고 단순 재실행하기에 알고리즘도 간단하다.


3번 '단순 무식 반복' 방식을 채택하여 정정 및 취소 주문 TR 에러 해결.

이로써, 현물 주식 주문에 대한 내부 테스트 및 디버깅을 완료하고,

안정적인 주문 실행을 확인하였다.


처음에 에러 메시지를 제대로 확인하지 않아서 원인을 알지 못해,

DLL방식과 COM방식을 모두 시도해 보다가,

COM방식에서 에러 메시지를 확인하면서 실마리가 풀렸고,

테스트 서버의 에러 메시지에 버그가 있었던 것을 뒤늦게 발견하고 증권사에 수정 요청을 하는 등,

온갖 우여곡절을 겪은 기나긴 디버깅 이었다.


현 상황 : 2018년 6월 25일자로하도록 수정 및 디버깅을 마치고, 소스코드 커밋 완료.


이제 데이터 수집 및 분석을 시작할 단계...

'GHTS' 카테고리의 다른 글

어제, 오늘, 금일, 당일, 전일.  (0) 2019.10.10
소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07

댓글을 달아 주세요

Xing API에 숨겨진 지뢰 3

GHTS 2018. 6. 7. 11:48 Posted by UnHa Kim

Xing API를 DLL 방식으로 사용할 경우, 

초기화 과정에서 LoadLibrary() 호출은 반드시 Xing API DLL파일이 존재하는 디렉토리에서 해야 한다.


풀어서 쓰자면,


1. Xing API DLL이 설치된 디렉토리로 이동 (기본값은 C:\eBEST\xingAPI\)

2. LoadLibrary() 호출

3. 원래 작업 디렉토리로 복귀.

4. 설정화일 불러들이기 (ID, 암호등 로그인 정보 취득)

5. 로그인 과정 진행.


이렇게 반드시 Xing API 디렉토리로 이동하는 과정이 필요하다.

그렇지 않으면, 서버 접속은 되는 데, 로그인이 안 된다.

(당해보면 상당히 갑갑하다.)


COM방식에서는 이런 문제가 없다.

'GHTS' 카테고리의 다른 글

소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

Xing API에 숨겨진 지뢰 2

GHTS 2018. 6. 7. 11:37 Posted by UnHa Kim

CSPAT로 시작되는 주식 현물 주문 TR의 경우,

거래소에 주문이 등록되지 않은 상태에서도 

주문번호가 부여되고 TR에 대한 응답이 돌아온다.


그래서, 해당 주문번호에 대해서 정정 내지 취소 TR을 실행할 경우,

해당 주문번호가 존재하지 않는다는 에러가 발생하기도 한다.


그래서, 정정 내지 취소 주문 TR을 실행할 때는

SC0~4 실시간 정보를 확인하거나,

에러가 발생하면 재실행 하는 등의 보완이 필요하다.



'GHTS' 카테고리의 다른 글

소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

Xing API에 숨겨진 지뢰 1

GHTS 2018. 6. 7. 11:31 Posted by UnHa Kim

t1102 소진율(exhratio : float 6.2)는 수신값이 '265' 이런 식인데,

소수점이 없더라도 float 6.2 형식이니 2.65로 해석해야 한다.


그런데, 항상 이런 식이 아니며, float 자료형의 개별 항목마다 다를 수 있다고 한다.

소숫점이 포함된 값이 수신되기도 하고,

자의적으로 소수점을 추가하는 것이 오히려 에러를 유발할 수도 있다.


Xing API 개발자 간에 서로 협의가 제대로 않은 채 서로 다른 포맷을 사용하다가,

API가 공개된 이후에는 고칠 수가 없어서 지금껏 이대로 흘러온 것 같다.


Xing API에서 float 값을 쓸 때는 확인이 필요하다.

'GHTS' 카테고리의 다른 글

소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

ZeroMQ를 이용한 분산형 구조.

GHTS 2015. 3. 10. 16:01 Posted by UnHa Kim

Go언어의 고루틴(goroutine), 채널(channel)은 처음에는 거의 완벽한 동시처리 모델로 보인다.

그러나, Go언어는 같은 메모리 공간에서 여러 고루틴(goroutine)들을 실행하며, 고루틴끼리 서로 완벽하게 메모리를 분리하지는 못한다.

그리고, 채널은 락(Lock)보다 성능이 낮다보니, 프로그래머들은 채널 대신 락을 통해서 메모리를 공유하고자 하는 유혹을 계속 받게 되며, 그로 인해서, 고루틴 간의 채널을 통한 메시지 전송으로 안전한 동시처리를 하겠다는 아이디어는 너무나도 손쉽게 기존의 멀티스레딩 방식의 락을 통해 공유되는 메모리 모델로 되돌아간다.

 

멀티스레드 방식의 공유 메모리 모델이 뭐가 문제인지는 마이크로소프트가 발행한 "멀티스레딩 코드에서 발생하기 쉬운 11가지 문제점" (https://msdn.microsoft.com/en-us/magazine/cc817398.aspx)을 참조하시라.

(여러분이 사용하는 윈도우와 오피스를 개발한 그 마이크로소프트가 맞다.)

MS윈도우에서 실행되는 각종 서버 프로그램을 제작하면서, 성능을 높이기 위해서 멀티스레딩 방식의 공유 메모리 모델을 기반을 채택했던 마이크로소프트 사는 그 과정에서 메모리 공유로 인해서 생기는 문제를 혹독하게 겪고 나서, 위의 글을 배포하기에 이른다.

즉, MS조차도 문제가 많다고 인정한 것이 멀티스레딩의 메모리 공유 모델이다.

 

메모리가 완벽하게 분리되는 모델이 이렇게도 구현하기 힘든 것일까?

아니다. 운영체제 프로세스는 아주 오래 전부터 서로 독립된 메모리 공간을 가진 채 동시에 실행되었다.

(MS-DOS에는 프로세스 간 메모리 분리 기능이 없었고, 도스(DOS)에 기반을 둔 윈도우 3.1, 윈도우 95, 윈도우 98 시절에는 메모리 겹쳐쓰기 문제로 블루스크린과 함께 컴퓨터가 자주 다운되었다.

윈도우NT, 윈도우 2000 내지 윈도우XP부터 프로세스끼리 메모리가 완벽하게 분리되었으며, 이후로는 MS윈도우의 안정성이 눈에 띄게 좋아졌다.)

이렇게 좋은 독립 메모리 프로세스 모델을 놔 두고, 왜 그 골치아픈 메모리 공유형 멀티스레딩 모델이 대세가 된 것인지는 잘 모르겠다. (아마도 성능 차이 때문인듯..)

 

어쨋건 간에 여러 운영체제 프로세스가 서로 분리된 메모리 공간에서 서로 메시지를 주고 받으면서 함께 작동하는 모델... 태고적부터 존재했던 멀티프로세스 모델... 이것이 바로 진정한 액터모델이자 CSP모델이다.

이러한 형태 하에서, 모든 실행단위는 메모리가 완벽하게 분리되며, 당연하게도 멀티스레딩의 메모리 공유로 인한 각종 문제가 원천적으로 봉쇄되며, 예전처럼 순차적 실행을 가정하여  프로그램을 짜더라도, 각 실행단위들은 독립적으로 동시에 실행되면서 멀티코어 CPU의 능력을 모두 활용할 수 있다.

분리된 메모리 공간의 안정성, 손쉬운 순차적 프로그래밍, 멀티코어 CPU의 모든 능력 활용등을 모두 실현할 수 있는 데, 왜 다들 멀티 프로세스 모델을 태고적 구식모델이라고 생각하면서 꺼리는 것일까?

(요즘은 컴퓨터가 너무 좋아져서 멀티 프로세스 모델로 인한 성능 저하가 아직도 문제가 되는 지 의문이다.)

 

어쨋든 간에 프로세스 간에는 메모리가 너무 완벽하게 분리되어 있다보니, 서로 메시지를 주고 받을려면 IPC(Inter-Process Communication : 프로세스 간 통신)이라는 것을 사용해야 한다고 한다.

그런데, 유닉스와 윈도우 간에도 IPC 규격이 다르고, 호환이 안 된다.

요즘은 모든 컴퓨터끼리 인터넷의 TCP/IP으로 정보를 주고받는 게 너무 당연시 하는 세상이다 보니, IPC도 인터넷의  TCP/IP 소켓 방식으로 하는 게 자연스러워 보여졌고, 이것을 중앙집중형 서버에서 맡아서 해 주는 게 메시지큐(현재 국제표준은 AMQP 1.0)이며, 이후  정보교환 기능을 개별 실행단위에게까지 분산(하였지만 간편하게)한 것이 오늘의 주제인 ZeroMQ이다.

그로 인해서, 이제는 동시처리 프로그램을 짜기 손쉬워졌을 뿐만 아니라, 일부 실행단위를 아예 다른 컴퓨터로 이동시켜서 분산형 시스템을 만들기도 쉽게 되었다.

어쩌면 한참 입에 오르내리다가 조용히 사라진 SOAP(서비스 기반 아키텍쳐)의 진정한 후계자는 REST(단순 웹기반 서비스)가 아니라 ZeroMQ일지도 모른다.

어쨋든, 요즘 ZeroMQ가 각광을 받는 게 다들 멀티스레드의 메모리 공유모델에 넌덜머리가 나서이지 않을까 싶다.

 

ZeroMQ(혹은 그 후속작인 nanomsg)을 사용하면 동시처리 프로그램을 안전하고 간편하게 짤 수 있는 것 이외에도 생각하지 못한 장점들이 있다.

 

1. 필요에 따라서 다른 프로그래밍 언어들을 섞어서 쓸 수 있다.

- 주식 API의 예제코드를 그대로 복사해서 붙여넣기 한 후, 획득한 정보를 ZeroMQ를 통해서 다른 모듈에 전송해 주면 된다.

- 매매전략의 통계처리는 간편한 R이나 Python으로 하거나, 그 외 시스템 트레이딩 서적에 나온 예제 코드에 ZeroMQ 메시지 전송기능을 추가해서 그대로 시뮬레이션에 돌려볼 수 있게 된다.

- 처음에는 친숙히고 편한 프로그래밍 언어로 개발하고, 나중에 성능이 문제시 되는 부분만 분리하여 좀 더 어렵지만, 성능이 뛰어난 프로그래밍 언어로 다시 개발해서 교체해 나가면, 장기간 안정적인 발전이 가능해진다.

 

2. 서로 다른 저작권 형태의 소스코드를 섞어서 쓸 수 있다.

- 모두가 공유하는 소스코드는 GPL로 의무적으로 공개하도록 하여서, 소스코드를 공개하는 사람만 착취당하는 '죄수의 딜레마'와 같은 모순을 제거하여서 모두가 협력하여 개선할 수 있도록 유도한다.

- 각자 자기만의 매매전략은 타인에게 공개되는 순간 수익성이 사라지는 특징이 있다.

  (모든 전략은 수용한계(capacity)가 있으며 이를 넘어서면 수익성이 사라진다.)

이렇게 공개되면 안 되는 부분은 상업용 라이센스 모델을 채택하여야 하며, 이러한 비공개 상업용 소스코드와 GPL에 따른 의무적으로 공개해야 하는 소스코드 간에 서로 메시지를 주고 받으면서 하나의 시스템으로 구성하여 배포하되, 각 소스코드는 서로 다른 라이센스를 채택하는 것이 가능해진다.

 

 

즉, 프로그래밍 언어의 제한, 소스코드 라이센트의 제한에서 자유로워진다.

그간 Go언어로 개발해 오다가 독립된 메모리를 보장하는 방법을 고민하다가, 메모리에 안전한 Rust 언어도 만지작 거려보다가 결국은 ZeroMQ에서 답을 찾았다.

이제 슬슬 개발을 다시 시작해야 할 듯 하다.        

'GHTS' 카테고리의 다른 글

소스코드 패키지 통합  (0) 2019.07.27
Xing API 현물 주식 주문 TR 테스트 완료.  (0) 2018.06.25
Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요