twirp : 간단한 RPC 프레임워크

GHTS 2020. 9. 29. 22:42 Posted by 정직한 UnHa Kim

GHTS가 RPC에 사용하는 nanomsg 관련 코드는 AST(Ahnlab Safe Transaction : 안랩 세이프 트랜잭션)에서  악성코드라고 오진하는 문제가 있어서 HTTP 기반의 RPC를 사용해서 오진을 피해야겠다고 생각하고 있었다.

그러나, 귀차니즘으로 인해 오랜 기간 미적대면서 시간이 흐르던 와중에

사용하기 쉬운 HTTP 기반 RPC 프레임워크를 발견했다.

 

github.com/twitchtv/twirp

 

twitchtv/twirp

A simple RPC framework with protobuf service definitions - twitchtv/twirp

github.com

 

트위치TV에서 대규모로 사용 중이라고 하니 안정성도 검증되었다고 봐야하고,

HTTP 1.1도 지원하니 프로그래밍 언어 간 호환성도 좋을 것 같다.

 

소개 문서를 읽고 있는 데 왠지 마음에 든다.

조만간에 nanomsg에서 twirp로 이전을 시도해 봐야겠다.

댓글을 달아 주세요

HTTP/2는 알고보니 RPC프레임워크 이었다.

GHTS 2019. 10. 12. 15:58 Posted by 정직한 UnHa Kim

HTTP는 문자열에 기반한 요청과 응답이 1:1 대응되는 프로토콜로만 알고 있었는 데,

뒤늦게 HTTP 2.0에 대해 알아보니,

바이너리에 기반한 M:N의 양방향 RPC프로토콜로 변해있었다.

 

참고 : https://developers.google.com/web/fundamentals/performance/http2

 

GHTS에서 API호출 프로세스와 나노메시지(nanomsg)를 RPC프레임워크로 사용하고 있다.

 

애초에는 zeroMQ를 사용했으나,

zeroMQ가 C++기반이라서 컴파일이 너무 느려서 개발 작업에 많은 방해가 되던 차에

nanomsg는 zeroMQ와 비슷한 기능을 가지면서도,

Go언어 구현체인 go-mangos의 존재 덕분에 컴파일 속도가 확연히 빨라져서,

개발 속도 향상에 많은 도움을 받았으며 그간 나름 만족스럽게 사용하고 있었다.

 

그러나, nanomsg는,

- 적은 수의 개발자

- 충분히 증명되지 않은 안정성

- 충분히 증명되지 않은 최적화

등의 문제로 인해서 찜찜한 면이 있었다.

 

HTTP/2는 구글의 SPDY를 토대로 수많은 수정과 초안을 거치며 규격이 정해진 데다가,

여러 인터넷 기업에서 사용되면서 안정성과 최적화 문제가 자연스럽게 해결된 상태인데다가,

Go언어 표준라이브러리에 포함되어 있기에 컴파일 속도까지 향상되므로,

여러모로 유리할 것 같아서,

RPC프레임워크를 nanomsg에서 HTTP/2로 바꾸는 게 낫겠다는 생각을 하게 되었다.

 

물론, 구글에서 gRPC라고 HTTP/2기반의 RPC프레임워크를 공개해 놨지만,

protocol buffer로 자료 변환을 하는 방식이 오히려 불편하게 느껴져서,

gRPC는 현 상황에서는 불필요한 복잡성만 도입하는 듯 하여 고려 대상에서 제외했다.

 

HTTP/2에 기반한 간단한 양방향 호출 예제는 h2conn을 참고하였다.

 

https://github.com/posener/h2conn

 

정말 단순하게 IPC를 실행하는 게 감동적이었다.

 

h2conn 예제는 json, gob 인코딩을 사용해서 문자열을 주고 받도록 되어 있는 데,

encoding/binary 패키지를 사용해서 바이너리 데이터를 주고받도록 변경하면,

그 즉시 RPC프레임워크로 바로 사용할 수 있을 듯 하다.

 

 

 

댓글을 달아 주세요

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

GHTS 2019. 10. 10. 12:17 Posted by 정직한 UnHa Kim

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

 

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

 

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

 

 

금일 : 오늘 

 

당일 : 가장 최근 영업일.

 

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

 

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

 

 

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

 

이것도 일자 상으로 어제와 전일이 다른 경우가 종종 있다.

 

만약, 오늘, 어제 모두 개장일이었다면, '전일 == 어제' 이다.

 

그러나, 만약 오늘은 개장했지만, 어제는 공휴일이었고, 그저께 개장일이었다면,

 

'전일 == 그제'가 된다.

 

만약, 중간에 연휴가 끼어있었다면?? -> 연휴 이전 마지막 개장일이 전일이 된다.

 

 

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

 

 

댓글을 달아 주세요

소스코드 패키지 통합

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

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

https://github.com/ghts/ghts

 

 

댓글을 달아 주세요

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에서 nanomsg로 이전.  (0) 2016.11.02

댓글을 달아 주세요

Xing API에 숨겨진 지뢰 2

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

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

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

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


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

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


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

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

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



'GHTS' 카테고리의 다른 글

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에서 nanomsg로 이전.  (0) 2016.11.02
NH OpenAPI 사용기  (0) 2015.09.09

댓글을 달아 주세요

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' 카테고리의 다른 글

Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ에서 nanomsg로 이전.  (0) 2016.11.02
NH OpenAPI 사용기  (0) 2015.09.09
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

ZeroMQ에서 nanomsg로 이전.

GHTS 2016. 11. 2. 11:02 Posted by 정직한 UnHa Kim

ZeroMQ를 사용하는 내내 대체로 만족스러웠지만,

ZeroMQ를 사용하기 위한 래퍼(wrapper : 중간단계) 컴파일로 인해서 

환경변수 설정이 복잡해지고, 컴파일 속도가 느려지는 불편함이 있었다.

 

그러던 중, ZeroMQ 수석 개발자가 시작한, 비슷한 기능의 nanomsg 프로젝트를 알게 되었다.

http://nanomsg.org/

 

nanomsg를 Go언어로 포팅한 go-mangos도 발견했다.

https://github.com/go-mangos/mangos

 

go-mangos를 사용하면 ZeroMQ와 비슷한 기능을 사용하면서도,

컴파일 속도도 빠르고, 환경변수를 설정할 필요도 적어져서, 개발이 훨씬 편리해졌다.

 

go-mangos의 안정성이 검증되지 않았지만,

빠른 컴파일, 단순함, 편리함의 유혹을 이기지 못하고, ZeroMQ에서 go-mangos로 이전해 버렸다.

https://github.com/ghts/lib



go-mangos를 개발한 Garrett D'Amore 옹(https://twitter.com/gedamore)은 

알고보니 Open Solaris 후속 프로젝트인 illumos 프로젝트의 창립자로 유명한 사람이고,

현재 go-mangos를 개발한 경험으로 nanomsg 메인터이너 자리를 차지하고,

nanomsg를 아예 처음부터 새로 짜겠다고 nanomsg nng 프로젝트를 진행 중이다.

(https://nanomsg.github.io/nng/ , https://github.com/nanomsg/nng )

.고로, go-mangos의 개발자 실력에 대해서는 믿어도 될 듯 하다.


아직까지 그럭저럭 잘 동작하는 듯 하다.

'GHTS' 카테고리의 다른 글

Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ에서 nanomsg로 이전.  (0) 2016.11.02
NH OpenAPI 사용기  (0) 2015.09.09
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

NH OpenAPI 사용기

GHTS 2015. 9. 9. 10:48 Posted by 정직한 UnHa Kim

NH OpenAPI를 사용해서 코딩해 본 후기


1. 문서가 부실하다.

: MS워드 형식의 문서만 봐서는 수신된 데이터를 해석할 수 없는 경우가 제법 있다.

: 설명이 아예 누락된 함수도 있다.

부실한 문서 문제를 해결방법은

: 첨부된 C++ 예제 소스코드를 읽기.

: OpenAPI 자유게시판을 검색한 후 관련 내용 없으면 질문.

: 부단한 삽질.


2. DLL 형식이라서 C, C++로만 사용 가능.

몇몇 타 증권사는 COM형태로 배포해 주던 데, NH투자증권의 OpenAPI는 그런 거 없다.

Go언어에 DLL을 직접 호출할 수 있는 기능이 있지만, 오히려 더 불편하게 느껴졌다.

DLL과 Go언어 간에 중계 역할을 하는 부분을 C언어로 코딩한 후, Go언어에서 cgo로 호출하는 것이 더 편리하게 느껴진다.

어쨌거나, C언어를 만져야 하는데, C언어는 메모리 자동관리가 안 되다보니 메모리 해제에 상당히 신경이 쓰인다.

포트란, 비주얼 베이직, 자바, C#, 파이썬, 루비, Go언어등 여러가지 언어를 써 봤지만, 메모리 관리하느라 골머리를 앓아보기는 처음이다.

그나마 Go언어의 defer문을 사용하면 메모리 해제하는 것을 깜빡 잊어버릴 가능성을 획기적으로 낮추어준다. 그러나, 이미 해제한 메모리 다시 해제하다가 컴퓨터가 뻗기 때문에 defer문도 남발하면 안 된다.


3. 비동기 방식이라 낯설다.

흔히 사용하는 RPC는 질의와 응답이 짝을 이루어서 순서가 일정하다.

그런데, NH OpenAPI는 질의를 마치면 언제 응답을 받을 지 모른다.

또한, 응답을 받기 전에 다른 질의를 할 수도 있다.

그리고, 복수의 질의에 대한 응답은 순서도 제멋대로 이다.

정확히 말하면 서버가 답변할 수 있는 질의부터 응답한다.

이 방식의 장점은 서버가 하나의 질의를 처리하는 데 오래 걸릴 경우에도 방해받지 않는다는 점이다.

설사, 서버가 응답을 보내주지 않더라도, 그에 무관하게 다른 질의를 보내서 응답을 받아볼 수도 있고,  시세변화에 따른 실시간 데이터도 받아보는 데 방해받지 않는다.

이 방식의 단점은 프로그래밍이 상당히 복잡해 진다.

윈도우 메시지 형태로 역호출이 수신되는 데, 무한 반복문에서 이러한 역호출 메시지를 처리해 줘야 한다.

불행 중 다행으로 Go언어의 고루틴(goroutine)을 사용하면 다른 작업을 수행하면서도 무한 반복문을 동시에 실행하는 문제를 간단하게 해결할 수 있다. 그래서, 낯설긴 하지만 프로그래밍 하기는 생각만큼 까다롭지는 않다. (동시처리 기능이 없는 다른 언어를 사용했다면 상당히 애 먹었을 듯 하다.)


하여튼,  한글을 알고, C언어를 알고, 증권용어를 인터넷 검색으로 알음알음 안다고 해도 API 문서만 읽고서는 프로그램 짜기가 어렵다.

API를 사용하면서 이렇게 애 먹기는 오랜만이다. (거의 처음인 듯..)


문서 내용이 혼동을 유발하는 예)

1. SDK 설명서에는 서버를 ini 설정화일에서 정해준다고 되어있는 데, 예제 소스코드를 보니 SetServer() 함수가 떠~억 하니 있다. 오히려, ini설정화일이 잘 안 먹히고, SetServer()함수가 잘 동작한다.

2. '전일대비_등락폭'이 '전일종가 vs 현재가'의 등락폭인 줄 알았는 데, 값이 이상하게 나와서 게시판에 질문해 보니, '전전일종가 vs 전일종가'의 등락폭이라고 한다.

이름을 '전일_등락폭'이라고 지었으면 이렇게 헷갈리지 않았을 텐데.

3. '거래량 비율'이라는 항목이 있어서 '거래량 vs 상장주식 총수량'인 줄 알았는 데 역시가 값이 이상해서 게시판에 질문해보니, '전일 거래량 vs 금일 거래량'이라고 한다.

이름을 '전일 대비 거래량 비율'이라고 지었으면 이렇게 헷갈리지 않았을 텐데.

4. '증거금 비율'이 실수형이어야 하는 데, [1]char이다. 게시판을 검색해 보니 다른 사람이 이미 질문했었고, 답변도 있다. 그 내용은 시장조치1, 시장조치2, ..., 시장조치6 중에서 1,2,3,4,5,6을 가리키는 것이라고 한다.  '시장조치'라고 해서 KRX증권거래소에서 무슨 조치를 한 내역인 줄 알았더니 그게 아니었다.

차라리, '종목별 추가정보'라고 불렀으면 덜 헷갈렸을 텐데.

5. '거래대금'과 '시가총액'의 숫자가 너무 작아서 삽질해 보니 '거래대금'은 100만원 단위, '시가총액'은 억원 단위이었다. 문서에 단위를 표시해 주면 간단하게 해결될 문제인데.

'GHTS' 카테고리의 다른 글

Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ에서 nanomsg로 이전.  (0) 2016.11.02
NH OpenAPI 사용기  (0) 2015.09.09
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요