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에서 답을 찾았다.
이제 슬슬 개발을 다시 시작해야 할 듯 하다.
