1.
작년 초 NYSE에서 만든 자료를 보면서 눈에 익혔던 RDMA, LDMA. NYSE Technology에서 만든 Low Latency Messaging Middleware를 보면 나오는 단어들입니다.RDMA는 이해가 되었지만 솔직히 LDMA라는 말을 왜 사용하는지 이해를 못했고 단순히 Shared Memory를 사용한다는 뜻으로만 이해했습니다. 물론 틀린 이야기는 아닙니다. 그러다가 모 회사 자료를 검토하면서 IPC Messaging이라는 단어를 들었습니다.
보통 메시징을 이야기하면 Publish/Subcribe, Topic-Based라는 말을 자주 사용합니다. 그런데 IPC라는 단어를 사용하는 것이 생소하였습니다. IPC=Inter Process Communication으로 유닉스를 사용할 때 너무나도 자주 듣던 단어였습니다. 그런데 IPC통신 – 역전앞처럼 C가 Communication이라 동어반복입니다만 – 이라고 하지 않고 Messaging이라고 새로운 단어를 만들었습니다. 곰곰히 생각했습니다. 단서를 찾았습니다.
답은 Core-To-Core에 있었습니다. 90년대 초반부터 2000년대 중반까지 사용했던 서버들은 코어라는 개념이 등장하기 전이었습니다. 제가 마지막까지 회사에서 사용했던 서버는 Sun Enterprise 3500시리즈로 CPU가 4개, Memory가 4G인 제품이었습니다. 이때만 해도 어떤 업무를 하나의 서버에서 처리하지 않아고 분산처리한다고 하여 TCP/IP기반으로 시스템을 설계하였습니다. 그래서 특별한 경우가 아니면 IPC를 사용할 일이 별로 없었습니다.
그런데 최근 서버라고 나오는 제품은 4 Core Cpu가 여덟개면 32 Core입니다. 메모리도 아주 큽니다. 이런 서버면 하나의 서버에서 모든 업무를 다 처리할 수 있습니다. 물론 내부적으로 소켓을 기반으로 시스템을 설치하면 됩니다. 그렇지만 Latency가 발생합니다. 마이크로초단위의 지연까지 문제가 되는 상황이면 아주 큰 요인입니다.
더구나 Task 혹은 Process 혹은 Thread를 Core별로 할당할 수 있습니다. Multi-Core를 기반으로 한 서버에서 Core-To-Core 간의 IPC Messaging을 이용한 트레이딩시스템을 구축하면 아주 낮은 레이턴시를 얻을 수 있습니다.
The low latency test simulates the maximum core-to-core performance characteristics of one application sending messages directly to another. In the past, such applications were commonly deployed across a network with messaging delivering data between the trading applications. With today’s powerful multi-core servers, applications like low-latency trading or scientific analytics have the option of deploying the applications within cores on a single server with the messaging occurring using inter-process communications (IPC) over a shared memory transport. This approach is appealing when the latency introduced by a network makes a difference to the application’s performance (common with high-frequency trading), or when the throughput between applications is higher than available network bandwidth (common with scientific applications and high performance computing).
Solace achieves sub-400 nanosecond ipc messaging on Cisco중에서
전통적으로 Messaging제품의 강자라고 할 수 있는 제품은 IBM MQ와 Tibco Rendevous입니다. Low Latency가 중심화두가 되면서 이들 제품도 업그레이드하였습니다. Low Latency Messaging이라는 이름으로 제품이 나옵니다. 그 내용을 들여다 보면 기술은 동일합니다.
Shared memory for inter-process communication
IBM MQ의 LLM에 소개서에 있는 말입니다.
2.
몇 일전 Solace제품을 판매하는 회사에서 몇 분이 찾아왔습니다. 이런저런 상담(?)을 하였습니다. Q&A를 하였습니다. 그 때 나왔던 주제중 하나가 Solace Unified API입니다. Solace Messaging Router는 하드웨어와 소프트웨어가 하나로 통합된 메시징제품입니다. FPGA로 가장 낮은 레이턴시를 구현하였다고 합니다. 대략 400 나노초입니다. 29West가 900나노초라고 하니까 Solace가 좀더 낮은 듯 합니다.
특정한 회사의 제품을 선전하기보다 Unified API라는 말의 의미를 소개하고자 합니다. IPC를 위하여 사용하는 기술들은 보통 아래와 같습니다.
- Shared memory.
- Memory-mapped files.
- Semaphores, mutexes, condition variables and upgradable mutex types to place
them in shared memory and memory mapped files. - File locking.
- Relative pointers.
- Message queues
이중 어떤 기술을 사용할지는 소프트웨어 개발자가 결정할 일입니다. 어떤 기술을 사용하든 IPC는 하나의 서버에서 프로세스간 통신을 할 때 사용합니다. WAN이나 LAN환경일 경우 TCP/UDP Socket를 이용합니다. 예전에 개발하였던 HTS 미들웨어는 분산환경을 고려하여 기본프로토콜로 TCP Socket, 같은 시스템영역에서의 통신을 위하여 Domain Socket을 설정하도록 설계하였습니다. 분산에 촛점을 두고 TCP Socket과 같은 방식으로 사용하면서 IPC의 역할을 하는 Domain Socket을 사용하였습니다.
반면 Low Latency Messaging에서는 반대를 고민합니다. IPC를 기본으로 하고 분산환경에서도 IPC와 같은 방식으로 통신할 수 있도록 하자는 요구가 있습니다. 그런 고민의 연장성에서 나온 기능이 Unified API입니다. Solace가 어떻게 구현하였는지는 알 수 없지만 비슷한 서비스를 제공하는 오픈소스를 소개합니다. 저도 위와 같은 문제의식을 가지고 조사를 진행하면서 찾았고 시험을 해 본 제품들입니다. 물론 적용을 하지 않았습니다.(^^)
첫째는 Linx라는 오픈소스입니다. 회사의 연혁을 보면 임베디드분야의 강자인 듯 합니다.
LINX Interprocess Communications Services for Complex Distributed Systems
아래글을 보시면 임베디드시스템도 앞서 문제의식과 동일한 요구가 있었다는 느낌입니다.
A fact of life in today’s embedded systems is the increasingly distributed nature and complexity of the designs: multiple processor nodes on a network, multiple servers in a cluster, multiple processor boards or blades in a system, multiple processors on a board, and multiple CPU cores on a single SOC.
To simplify the programming, resource management and debugging of applications, there has been a recent movement to extend the Inter Process Communications (IPC) protocol?a common element in most operating systems?to better meet the requirements of this new environment. But as yet there is no common IPC standard. Each OS and many hardware platforms incorporate proprietary IPC mechanisms adapted to those environments. Enea, for example, has used the LINKHandler message passing protocol in its OSE and OSEsk since 1993.
LINX: an open source IPC for distributed, multicore embedded designs중에서
둘째는 TIPC입니다. 기술적 개념은 Linx와 동일합니다.
Transparent Inter-Process Communication protocol
위의 사이트에서 소스는 구하실 수 있지만 좀더 깊은 기술자료를 원하시면 아래를 참고하세요.
TIPC: Providing Communication for Linux Clusters
3.
이상의 내용은 글쓰기 위한 글이 아니라 실제 제품개발과정에서 조사하였던 내용들입니다. 이런 검토를 통하여 ZeroM도 구조를 변경하고 기능을 추가하였습니다. 이 글의 주제이기도 한 IPC Messaging을 구현하는 일이 가장 중요하였습니다.
제가 조사한 바에 따르면 국산 메시징제품이 없습니다. Tmax가 TPmonitor시장의 빈자리를 메웠던 것처럼 ZeroM이 빈자리를 메웠으면 하는 바람이 솔직히 있습니다. 그래서 T->M으로, Max->Zero로 변화를 주어 작명한 이유이기도 합니다.
FIX시장이 열렸을 때 IBM이나 Sybase와 같은 회사들이 미국제품을 가지고 들어왔습니다. 이 때 경쟁하였던 국내업체가 제가 창업했던 넥스트웨어와 데이타로드입니다. 그리고 8년이 지난 현재 데이타로드는 국내 FIX/OMS시장을 독점하고 있습니다. 국내시장은 여러 회사가 공존하기엔 작은 시장이지만 한 두회사가 생존하며 발전할 수 있는 시장이기도 합니다.
메시징시장이 열린다면 ZeroM도 그런 위치를 점하고 싶습니다.물론 저도 Low Latency Market을 위해 노력을 전력을 다해 뛰려고 합니다.(^^)
