아래의 글이 담고 있는 것중 사실 관계가 틀릴 수 있습니다. 최근 HTS플랫폼이 어떤 변화를 하였는지 모르기때문입니다. 이점을 참고로 하시고 문제의식만 읽어주시길 바랍니다.(^^)
1.
Chrome과 홈트레이딩시스템의 윈도우 플랫폼. 거의 문외한입니다. 웹 브라우저는 하루 종일 이용하는 파워유저지만 브라우저의 구조를 꼼꼼히 살펴본 적은 없습니다. HTS의 윈도우 플랫폼도 화면만 관심을 두었지 내부 구조 역시 궁금하지 않았습니다. 그러던 어느 날. 2013년 여름쯤입니다. 어떤 후배와 트레이딩 플랫폼의 구조을 놓고 이야기를 나눌 기회가 있었습니다.
출발은 최근 HTS의 문제점이었습니다. 가장 두드러진 장애가 병목현상이라고 합니다. 이해가 힘들었습니다. 보통 트레이더가 사용하는 컴퓨터의 사양은 높습니다. CPU도 그렇고 메모리도 넉넉합니다. 그런데 병목이라고 합니다. 후배가 말한 병목은 이렇습니다.
“일반적으로 홈트레이딩시스템을 사용하면 주문창과 시세창을 같이 올려놓고 시세모니터링을 하면서 매매를 하려고 합니다. 동시호가가 끝난 후 장 시작을 하면 시세가 대량입니다. 시세창은 쏫아지는 시세를 받아서 그리드(Grid)에 표시하느라 바쁩니다. 화면에 시세를 그리는 작업을 하면서 정작 중요한 주문처리를 못한다는 점이 문제입니다. 병목입니다.”
이해가 힘들었습니다. 멀티코어환경이라 CPU 리소스가 충분한데 주문처리를 못합니다. 이유는 Drawing이었습니다. 윈도우의 구조상 프로세스에서 상속을 받은 쓰레드가 아무리 많다고 하더라도 화면에 그림을 그리는 쓰레드는 하나만 가능하다고 합니다. 어떤 분은 이것을 붓으로 표현하더군요. 솔직히 아직도 윈도우의 커널구조를 모르기때문에 이해를 잘못하고 있습니다.
어떻게 해결할 것인가? 구글이 만든 크롬를 연구했다고 합니다. 초창기 크롬과 IE의 구조는 달랐다고 합니다. 이런 구조의 차이때문에 크롬이 더 빠른 속도를 보여주었습니다. 크롬의 어떤 면이 이런 차이를 만들었을까요? The Chromium Projects-Multi-process Architecture에 있는 구조도를 살펴보도록 하죠. 그 때 제가 이해한 것이 맞다면 멀티 프로세스 구조인 RenderProcess가 차이를 만듭니다. 새로운 네트워크 접속이 일어날 때마다 메인 프로세스는 RenderProcess를 만들어 별도로 화면을 그리도록 합니다.
이런 구조이기때문에 작업관리자로 Chrome을 보면 항상 멀티 프로세스로 보입니다.
다시금 1998년부터 HTS를 개발한 C++ 파트너에게 똑같은 질문을 했습니다. 이런 답변을 하더군요.
“한국CNA가 처음 HTS를 개발하였던 98년전후 최초의 CAT은 멀티 프로세스 기반으로 구성하였다. 그런데 HTS 화면이 늘어나고 화면과 화면간의 메시지가 복잡해지고 다양해지면서 멀티프로세스 구조로 불가능하였다. 그래서 싱글프로세스/멀티 쓰레드 구조로 변경을 하였다.”
곰곰히 생각해보면 웹브라우저와 HTS의 화면에서 발생하는 이벤트는 큰 차이를 보입니다. 지난 20여년동안 HTS의 화면이벤트는 급속히 늘었고 다양해졌습니다. 멀티 프로세스구조로 이를 처리하려면 너무나 복잡해집니다. Trade Off라고 생각했습니다. 그러면 멀티 프로세스구조의 HTS 플랫폼은 어디에 적용할 수 있을까요? 파워유저를 위한 특화주문시스템이나 ZeroAOS의 터미날과 같은 특수한 이용자를 위한 플랫폼입니다.
2.
OpenMPI와 ZeroMQ의 구조에서 소개하였던 책이 ‘The Architecture of Open Source Applications’입니다. 이 책을 만든 곳은 The Architecture of Open Source Applications입니다. 여기서 새로운 책을 내놓았습니다. ‘The Performance of Open Source Applications’ 입니다. 이 중 한 꼭지가 High Performance Networking in Chrome입니다. 앞서 설명한 멀티 프로세스 구조를 이렇게 정리하고 있습니다.
Multi-process Architecture
Chrome’s multi-process architecture carries important implications for how each network request is handled within the browser. Under the hood, Chrome actually supports four different execution models that determine how the process allocation is performed.By default, desktop Chrome browsers use the process-per-site model, that isolates different sites from each other, but groups all instances of the same site into the same process. However, to keep things simple, let’s assume one of the simplest cases: one distinct process for each open tab. From the network performance perspective, the differences here are not substantial, but the process-per-tab model is much easier to understand.
The architecture dedicates one render process to each tab. Each render process contains instances of the Blink layout engine and the V8 JavaScript engine, along with glue code that bridges these (and a few other) components2.
Each of these render processes is executed within a sandboxed environment that has limited access to the user’s computer–including the network. To gain access to these resources, each render process communicates with the main browser (or kernel) process, which is able to impose security and access policies on each renderer.
Chrome의 커널과 고성능을 내는 이유가 궁금하시면 한번 읽어보시길 권합니다. 김지훈님은 이 글을 정리하여 발표하였습니다.
