메시지, 메시징 그리고 MOM

1.
얼마전 두 주동안 ‘Message, Messaging 및 MOM’이라는 주제의 교안을 만들고 교육을 하느라 정신 없었습니다. ZeroM이라는 제품을 판매하고 있지만 저는 그닥 ‘메시징’의 전문가가 아닙니다. 교육을 한다고 이것 저것 자료를 보고 정리하면서 새롭게 익힌 것들이 많았습니다.

‘메시지’ 혹은 ‘메시징’이라는 단어를 사용할 때 암묵적으로 ‘실시간(Realtime)’을 전제로 깔고 이야기를 했습니다. 실시간이라는 속성이 없으면 메시지 혹은 메시징이 아니라는 뜻이죠. 그래서 저는 메시징을 “비동기적 방식의 실시간 통신”이라는 의미로 사용하였습니다. 그런데 메시지(Message)는 여러가지 의미가 있습니다. 그중 “메시지란 프로그램들 간에 사건, 요청 또는 응답을 묘사하기 위해 지정된 형식으로 구성된 데이터”라는 정의가 눈에 들어오더군요. 제가 이해하고 있던 바와 달랐습니다. 미들웨어라는 항목을 정리하면서 Transaction이라는 단어도 마찬가지입니다. 트랜잭션도 동기적인 방식의 데이타처리로만 이해하였습니다. 이렇게 이해하면 Transactional Messaging이라는 말을 이해하기 힘듭니다. 그렇지만 하나의 작업을 완전무결하게 처리하도록 하는 일련의 과정을 의미하더군요. ACID도 이 때문에 등장한 듯 하네요. 기본적인 개념을 정리하지 못하니까 이곳 저곳에서 사용하는 같은 단어를 이해할 때 골머리가 아팠습니다. 어떤 사물을 정리할 때 개념은 항상 중요합니다. 전산기술도 마찬가지입니다.

기초를 정리하고 응용을 정리하였습니다. 메시징미들웨어(Message Oriented Middleware)을 정리하기 위해 이런저런 자료를 뒤졌습니다. MOM을 이용하기 할 때 가장 많이 사용하는 개념이 P2P(Peer To Peer)와 Publish/Subscribe입니다. 사실 이것이 모두 다라고 생각했습니다. 그게 아니더군요. 이전에 메시지를 처리하는 기술적 구조가 있더군요. 90년대말 SmartSocket으로 유명한 Talarian이 발표한 자료중 일부입니다.

Message Queuing
In message queuing, program-to-program communications occur via a queue, which is typically a file. It allows programs to send and receive information without having a direct connection established between them. A program simply gives messages to the message queuing service, identifying by name the queue in which it wishes the message to be placed. The message queuing service acts as an intermediary, and the mechanism by which the message is transmitted is completely hidden from the application programs. In large, enterprise-wide applications, queues can be set up to forward the messages to other queues. Message queuing provides safe storage of information and is most appropriate where ?applications cannot be connected directly (for example, in mobile computing). However, message queuing tools require considerable configuration to set up correctly and performance can be poor. If access to a queue is lost for any reason, the entire system can be affected.

Message Passing (Publish-Subscribe)
Message passing has proven popular for building large, distributed applications. This approach differs from message queuing in that rather than oblige applications to retrieve the information they request, the information is more efficiently pushed to the interested parties. One increasingly popular flavor of message passing uses a model of communication known as publish-subscribe (pub/sub). In pub/sub, programs subscribe to (register interest in) a subject. Programs also publish (send) messages to the subject. Once a subject has been subscribed to by a program, the program will receive any messages published to that subject in the distributed application. Subjects are defined by the application developer. In traditional network applications, when two processes must communicate with each other, they need network addresses to begin communicating. If a process wants to send a message to many other processes, it first would need to know the physical network addresses of the other processes and then create a connection to all those processes. This architecture does not scale well because configuration is complicated and tedious. The publishsubscribe communications model provides location transparency, allowing a program to send the message with a subject as the destination property while the middleware routes the message to all programs that have subscribed to that subject.

Message Queuing방식의 MOM으로 대표적인 제품은 80년대에 탄생하여 현재까지 계속 진화를 거듭하고 있는 IBM의 WebsphereMQ를 들 수 있습니다. 메시징기술의 변화를 겪는 90년대 중반부터 후반까지는 인터넷이 보급되는 때입니다. 위의 인용도 지적하듯이 Message Queuing은 작은 단위의 컴퓨터나 프로세스를 통합하는데 적합합니다. 지금도 Message Queuing은 증권사에 많이 사용합니다. 주문메시지를 신뢰성있게 처리하여야 하는 주문전달프로세스(FEP)가 그렇습니다. 그런데 Message Queuing이 인터넷시대에 부적합하였고 이러한 기술적 요구에 부응한 것이 Message Passing이라는 느낌입니다. 기술이란 사회적 요구에 부응하기 위한 탄생하는 경우가 아주 많습니다. 최근 스마트혁명이 시작되면서 Websocket이나 HTML5을 이용한 Internet Messaging 기술을 요구하는 것도 같은 경우가 아닐까 합니다.

2.
Message Passing이라는 말을 찬찬히 보면 어디서 들어본 듯한 단어입니다. 유닉스 개발자들이 보는 책을 보면 나오는 IPC(Inter Process Communication)도 Message Passing입니다. Message Passing을 찾으면 기본유형(Basic)이라고 나오는 예제가 IPC기술입니다. 아마 유닉스가 처음 등장하였을 때 IPC기술은 대단히 혁신적인 발상이지 않았을까 합니다. 파일이나 큐같은 것을 쓰지 않고 프로세스끼리 통신을 할 수 있기때문입니다. Message Passing이 인터넷시대를 맞아 새롭게 재탄생한 것이 Pub/Sub방식의 메시징입니다. 이 때부터 지금까지 Publish/Subscribe방식의 Message Passing이 메시징기술의 주류입니다. 그렇다고 Message Queuing과 Message Passing이 서로 대립되는 구조는 아닙니다. 요즘 나오는 제품들은 보면 두가지 구조를 통합합니다. 예를 들어 대표적인 JMS제품인 ActiveMQ의 경우 두가지 구조를 가지고 있습니다.

Message Passing은 하드웨어기술의 혁신에 따라 또다른 변화를 겪습니다. 멀티코어시대가 도래합니다. 서버와 서버간의 통신도 중요하지만 서버내에서 어떻게 통신하는지도 중요합니다. 본격적인 병렬컴퓨팅이 등장합니다. Parallel Computing을 말할 때 핵심은 Thread간의 통신입니다. 두가지 기술을 많이 언급합니다. Shared Memory방식과 Message Passing방식입니다. 전자는 Queue를 이용한 Message Queuing의 확대판으로 보입니다. 후자는 말 그대로 Message Passing입니다. MPI라고 말할 때 MP입니다. 혹시 병렬컴퓨팅에 관심이 있으시면 아래글을 읽어보시길 바랍니다. 짧지만 잘 정리해놓았습니다.

Introduction to Parallel Computing

사람들의 상상력은 결국 지난 경험을 현대적으로 재해석하는 것이 아닐까 합니다. 창조성을 이야기할 때 경험과 노력이 중요하다고 하는 것과 같은 이치입니다. 상상력의 반복이라는 느낌을 주는 기술이 IPC기술입니다. 앞서 유닉스의 IPC와 비슷한 기술이 최근 메시징기술의 핵심에 자리잡고 있습니다. 멀티코어환경에서 Low Latency를 요구하는 시대적 흐름에 따라 등장한 IPC Messaging입니다.

IPC Messaging

Messaging과 관련된 기술이나 제품을 보면 같은 메시징이라고 하더라도 서로간에 호환되지 않습니다. 통합을 하려면 별도의 어댑터같은 것을 이용하여 하여야 합니다. 다시 말하면 사실상의 표준이 존재하지 않는다는 뜻입니다. 표준이 주는 장점은 너무나 많고 그것을 잘 알고 있는 IT업계와 소비자들은 표준을 고민하기 시작합니다. 그렇게 탄생한 표준이 바로 AMQP와 Data Delivery Service입니다.

지금은 메시징 시대

3.
앞서 교재와 교육을 준비하면서 가졌던 생각을 두서없이 정리하였습니다. 비전공자가 역사적 변화와 요구에 따라 메시징기술의 변화를 이해한 결과라고 보시면 됩니다.

ZeroM을 개발판매를 하고 있지만 메시징기술로 놓고 보면 한국자본시장은 미개척지입니다. 멀티프로토콜의 Exture+가 등장하고 ATS가 여러개 나타나면 메시징의 중요성은 점점 더 커지지 않을까 합니다. 국내에 메시징 관련 기술을 가지고 서비스나 제품을 제공하는 곳들이 있습니다. 데이타로드는 Formula, 대신증권은 Infoway라는 제품(?)입니다. 메시징과 관련된 노하우를 가진 곳이 앞으로 변화에 더 잘 적응할 수 있지않을까 조심스럽게 예측해 봅니다.

(*)몰랐던 사실이 하나 있습니다. KB투자증권이 Tibco의 EMS를 사용하고 있다고 하네요. 메시징을 기반으로 EAI로 진화한 제품이지만 Tibco의 메시징기술이 바탕입니다.

아래는 RSS를 읽다가 찾았습니다. 혹시 64bit C/C++ 개발에 관심이 있는 분들이 북마크해놓으시면 좋을 듯 합니다.

Lessons on development of 64-bit C/C++ applications

The course is composed of 28 lessons devoted to introduction to 64-bit systems, issues of building 64-bit applications, methods of searching errors specific to 64-bit code and code optimization. Such questions are also considered as estimate of the cost of moving to 64-bit systems and rationality of this move.

Lesson 01. What 64-bit systems are.
Lesson 02. Support of 32-bit applications.
Lesson 03. Porting code to 64-bit systems. The pros and cons.
Lesson 04. Creating the 64-bit configuration.
Lesson 05. Building a 64-bit application.
Lesson 07. The issues of detecting 64-bit errors.
Lesson 08. Static analysis for detecting 64-bit errors.
Lesson 09. Pattern 01. Magic numbers.
Lesson 10. Pattern 02. Functions with variable number of arguments.
Lesson 11. Pattern 03. Shift operations.
Lesson 12. Pattern 04. Virtual functions.
Lesson 13. Pattern 05. Address arithmetic.
Lesson 14. Pattern 06. Changing an array’s type.
Lesson 15. Pattern 07. Pointer packing.
Lesson 16. Pattern 08. Memsize-types in unions.
Lesson 17. Pattern 09. Mixed arithmetic.
Lesson 18. Pattern 10. Storage of integer values in double.
Lesson 19. Pattern 11. Serialization and data interchange.
Lesson 20. Pattern 12. Exceptions.
Lesson 21. Pattern 13. Data alignment.
Lesson 22. Pattern 14. Overloaded functions.
Lesson 23. Pattern 15. Growth of structures’ sizes.
Lesson 24. Phantom errors.
Lesson 25. Working with patterns of 64-bit errors in practice.
Lesson 26. Optimization of 64-bit programs.
Lesson 27. Peculiarities of creating installers for a 64-bit environment.
Lesson 28. Estimating the cost of 64-bit migration of C/C++ applications.

One file(the print version as well).