지금은 메시징 시대

1.
20세기의 마지막, 2000년대는 Application Server의 전성시대입니다.
인터넷시대의 개막과 더불어 Web Application Server가 핵심어플리케이션이었습니다. 트레이딩도 같습니다. 최소한 한국의 경우 Trading Allication Server인 HTS 미들웨어의 전성시대였습니다. 그런데 AS의 전성시대가 막을 내리고 있습니다. Tmax도 한번의 좌절을 겪고 재기하고 있지만 예전 같지 않습니다. 그렇고 Bea는 아예 Oracle로 매각된지 오래입니다. TAS업체도 이제는 인력파견으로 명백을 유지하거나 별도 솔류션으로 이어갑니다. 수익성을 떨어진채로.

빈자리를 메우고 등장하는 분야가 메시징입니다. 물론 미국은 90년말부터 메시징이 핵심 어플리케이션이었습니다. Smartsocket이나 Rendevous 아니면 아주 유명한 IBM MQ도 증권IT와 관련한 세미나의 단골주제였습니다.

한국도 늦었지만 메시징이 서서히 달아오르고 있습니다. 이유는 Latency때문입니다. 다시 영업을 하면서 여기저기 이야기를 듣습니다. 어떤 업체는 29West를 밀고 있고 어떤 업체는 Rendevous를 밀고 있다고 합니다. 한국레드햇은 MRG를 밀고 있다고 합니다.

2.
제가 메시징에 관심을 가진 때는 2003년 FIX/OMS를 구축할 때입니다. FIX와 OMS를 어떻게 연결할까 고민을 하다 메시징을 선택하였습니다. 최초 모 증권에 납품할 때 자체기술이 없어서 Smartsocket을 납품하였습니다. 이후 가격때문에 별도의 제품을 개발하였는데 HiperM이었습니다. 몇 곳에 납품하였습니다. 지금은 FIX/OMS가 다른 제품으로 교체되어 사용하지 않습니다만 메시징은 어플리케이션간의 통합을 위해 아주 좋은 기술입니다 흔히들 Loosely Coupled라는 말로 표현합니다.

현재 ZeroM이라는 제품을 기획개발하기까지 몇 년동안 메시징제품을 분석하였습니다. 이 때 검토하였던 제품이 Wombat(지금은 NYSE Tecnologies로 합병), 29West, Solace입니다. Tibo나 IBM의 제품은 너무 유명해서 별도로 분석하지 않았습니다. 다른 관점에서 메시징 표준을 검토하였습니다. AMQP와 DDS입니다. AMQP는 JPMorgan이 개발하고 월스트리트에 협력하여 업그레이드하고 있는 표준입니다. DDS는 Omgeo에서 만든 표준입니다. 두개의 표준에 대해 예전에 간단히 언급하였습니다. DDS는 알티베이스의 CEP엔진에 도입되어 있습니다.

DDS와 대외계시스템

AMQP를 좀더 소개하겠습니다. AMQP나 DDS는 기술표준이 아니라 메시징과 관련한 업무표준입니다. JMS와 다른 표준이라는 뜻입니다. AMQP를 처음 설계개발한 곳은 JPMorgan과 iMatrix입니다. 이 때 개발한 제품을 오픈소스로 공개한 제품이 OpenAMQ입니다. 이후 AMQP를 지원하는 여러 제품등이 등장합니다. 그중의 하나가 Apace Qpid입니다. AMQP가 금융업무를 고려한 설계인 반면 DDS는 Omgeo에서 만든 표준답게 산업표준을 지향하고 만들었습니다. 이를테면 뉴스공급자를 위한 서비스등등.

이제 변화가 생깁니다. 표준이 등장하고 성장하다 보면 관련업체의 다양한 이해를 반영하여야 합니다. AMQP를 성장하는데 많은 노력을 한 iMatrix가 AMQP에서 탈퇴합니다. 이유는 너무 무거워졌다는 것입니다. 그래서 대안으로 만든 제품이 ZeroMQ입니다. Lightweight를 지행합니다.Redhat MRG은 이런 흐름속에 위치합니다. 현재 Redhat MRG는 OepnFabrics 과 AMQP의 오픈소스프로젝트인 Qpid를 결합한 제품입니다.

메시징기술도 멀티코어와 같은 하드웨어의 변화를 따랐습니다. 이런 노력을 한 곳이 Solace나 29West등이 아닐까 합니다. 최소한 기술문서를 보면서 든 생각입니다. 전통의 강자인 IBM이나 Tibco는 뒤늦게 합류하여 Low Latency제품을 최근에 내놓고 있습니다.
.
2002년 FIX시장이 형성되었을 때 외국IT사들이 밀고 들어왔습니다. 여러곳에서 입질을 하였지만 결국 실패하였습니다. 데이타로드와 넥스트웨어가 국산 솔류션을 가지고 있었기때문입니다. 지금도 비슷한 양상으로 흘러갑니다. 자본시장 참여자들이 레이턴시에 대한 관심을 표명하면서 미국등에서 검증된 제품이 들어옵니다.브랜드를 앞세워 시장에 진입하려고 노력하고 있습니다. 29West는 모처에서 유력하게 검토하고 있다고 합니다. Solace도 어떤 업체가 한국에 소개하려고 합니다. 영업이 방한하였다고 합니다. 자세한 정보는 없지만 국산메시징제품을 개발하는 곳이 제가 속한 곳 말고 더 있지 않을까 합니다. 있었으면 합니다.

메시징의 기본기능은 Publish/Subscribe입니다. 이런 기본기능을 빼놓고 최근 핵심이슈는 메시징레이턴시입니다. 29West가 0.9마이크로초(Sub Microsecond)를 달성했다고 합니다. 아이스트의 담당파트너와 협의한 결과 가능한 수치라고 합니다. 그래서 현재 마이크로초를 1마이크로초이하로 하려고 노력하고 있습니다. 그렇다고 메시징이 모든 것을 결정하지 않습니다. 레이턴시는 End-To-End Latency입니다. 트레이딩으로 말하면 시세를 전송할 때부터 체결 결과를 받을 때까지의 지연이 기준입니다. Low Latency가 목적인 시스템을 구현하려면 메시징을 중심으로 다양한 기술이 접목되어야 합니다. 그런 고민의 산물이 예전에 목차로 소개하였던 제안서입니다.

ZeroM은 최소한 메시징기술에 관한 국내에서 가장 오래 연구개발한 장인개발자의 숨결이 살아있는 제품입니다.(^^) 멀티코어를 고려한 기술은 당연히 제공하고 있습니다. 혹시 메시징기술을 도입하려는 계획이 있으신가요? 그러면 외산뿐 아니라 저와 같은 국산제품도 기회를 주시면 어떨까요? 너무 속 보이는 이야기를 했습니다.

4.
아래는 AMQP를 설계하였던 JPMorgan의 Hara가 쓴 글의 번역입니다. 전체는 아니고 일부입니다. 2010년에 완역을 하려고 시작했다가 미루고 미루고 미루어 그냥 일부만 공개합니다. 표준을 바라보고 개발하는 철학을 눈 여겨 보시면 어떨까 합니다.

아래글은 JPMorgan에서 개발하였지만 지금은 사실상의 표준(?)이라고 할 수 있는 AMQP프로토콜의 개발자인 John O’Hara가 발표한 논문입니다. 약간의 의역을 하였습니다. 

Toward a Commodity Enterprise Middleware

Can AMQP enable a new era in messaging middleware? A look inside standards-based messaging with AMQP

John O’Hara, JPMorgan

AMQP (Advanced Message Queuing Protocol)는 JPmorgan에서 프론트 및 백오피스시스템을 개발할 때 가졌던 경험과 좌절로 출발하였습니다.

1996년부터 200 년까지 시스템을 통합할 때 반복되는 문제들을 해결할 수 있는 표준화된 솔류션을 기다렸지만 기대는 무너져버렸습니다. 이런 결과로 AMQP는 2006년중반 아주 중요한(Mission Critical) 시스템에 실제로 적용하기 위해 개발되었습니다. 이 때 이천명의 이용자, 하루 억개의 메시지를 처리할 수 있었습니다.
이 논문은 표준에 기반한 메시징인프라를 구축하는 대안으로 AMQP를 소개하려고 합니다. AMQP는 바이너리방식의 유선프로토콜(binary wire protocol)이며 store-and-forward, publish-and-subscribe 및 다른 기술을 통합하여 시스템간에 어플리케이션메시지를 전달하기 위한 프로토콜입니다.

나는 instant messaging이나 엔드유저를 위한 메시징과 AMQP를 구별하기 위하여 application messages라는 용어를 사용하도록 하겠습니다. AMQP는 메시지가 중간에 사라지거나 정해진 시간내에 메시지가 전달되지 않거나 혹은 비정상적으로 진행될 경우를 대비한 시나리오가 준비되어 있습니다.

AMQP는 하드웨어, OS 혹은 프로그래밍언어으로부터 종속적이지 않을 뿐 아니라 다양한 네트워크 프로토콜 – TCP, SCTP 혹은 InFiniBand -등을 이용하여 고성능을 구현할 수 있도록 설계되어 있습니다.

왜 표준이 필요한가.(The Need for a Standard)

월스트리트에 있는 대부분 대형IB들은 어느정도 자체의 메시징미들웨어(MOM)을 가지고 있었습니다. 이들중 상당수는 없어졌거나 상용제품으로 대체되고 있습니다.

왜 대형IB들은 자체의 MOM을 구축했을까요? 금융서비스산업은 Pub/SUB기능 및 확실한 전송보장을 지원하는 기능을 갖는 메시징시스템을 필요로 합니다. 이상의 요구는 종종 현재 이용가능한 MOM이 제공할 수 있는 기능을 넘어서기도 하고 IB에서 MOM을 구축하기 위한 기술인력도 충분하기 때문에 자체적인 MOM을 개발한는 것은 충분히 선택가능한 접근방법입니다.

IB들은 자신들의 시스템구조에 끼여넣을 수 있는 고성능서비스가가능한 Message Bus를 찾고 있습니다. 웹서비스는 단위업무를 수행할 때 너무 많은 대역폭과 전산자원을 사용하기때문에 IB를 만족시킬 수 없습니다.

자동매매시스템의 성장으로 말미암아 MOM을 향상시키는 방법에 대한 관심이 폭발적으로 높아지고 있습니다. IB들은 시세데이타처리의 한계를 계속 넓혀서 OPRA(the Options Price Reporting Authority)에 따르면 초당 오십만건(500,000)을 넘어서고 있습니다. 정보를 처리하고 비즈니스트랜잭션을 처리하도록 하는 노력은 현재 계속 진행중입니다. 현재 마켓데이타의 건수가 시스템에서 처리할 수 잇는 건수를 넘어섰기때문입니다.

이상과 같이 현실에서 필요한 요건은 명확하게 주어졌지만 IB내부에서의 노력은 왜 지속되지 못할까요? 기술적인 능력은 있지만 IB들은 소프트웨어를 개발하는 전문회사가 아니기때문에 IB에서 오랜시간동안 한 문제에 열정을 다바쳐 집중하는 것은 매우 어렵기때문입니다.

IB들은 업무를 추진하는데 표준이 절대적으로 필요한 영역에서 공개적인 표준을 만들기 위해 공동작업을 하는데 익숙합니다. 예를 들어 FIX (Financial Information Exchange) protocol, FAST (FIX Adapted for Streaming), FpML (Financial products Markup Language) 그리고 SWIFT (Society for Worldwide Interbank Financial Telecommunication) 등이 좋은 사례입니다.

200 년에 나는 MOM (message-oriented middleware)기술을 표준화하기 위한 조사에 착수하였고 표준을 작성하였고 다시 이를 회사내에서 사용하였습니다.

현실화하다(Making it Happe)

이것은 산업에서 주도권을 확보한 것입니만 자체적으로 개발한 MOM은 아무리 작은 시장에서라도 성공할 수 없습니다. 현재 Ethernet, IP, E-mail, 웹과 같은 강력한 네트워킹 표준들은 몇가지 특징때문에 유명합니다. 로열티를 내 필요가 없고 특허권에 의해 사용상의 제약을 받지 않고 공개적으로 표준이 상세하게 정의되어 있으며 무상으로 유용한 시제품들은 사용할 수 있습니다. 자유와 유용성이 결합하여 사람들은 필요로 할 때 자유롭게 도입할 수 있게되었습니다.

성공적인 정착을 위하여 AMQP는 다음과 같은 특징을 가질 필요가 있었습니다.

누구나가 호환성을 가진 서비스를 개발할 수 있도록 완벽하게 정의되고 공개적이고 로열티가 없고 저작권의 보호를 받지 않는 규격을 만들어야 했습니다. 더구나 표준규격은 완전히 구현,개발과 구분되어야 했습니다. 그렇지 않으면 이익을 목적으로 하는 기관이 시장에 진입하기엔 불공정한 시장이 되기때문입니다. AMQP 상업적인 개발과 구현이 가능하여야 했고 그렇지 않으면 성공할 수 없다고 판단하였습니다.

1)AMQP은 규격을 실제로 구현하여야 했습니다. 그렇지 않으면 필요성을 절박하게 느끼는 현업 개발자들이 관심을 갖지 않거나 불필하게 느끼기 때문입니다. 또한 IETF의 표준초안이 될 수 있도록 하나이상 구현하여야 했습니다. 그래서 개발자들이 당장 돌려볼 수 있는 제품이 있습니다.

2)AMQP소프트웨어는 반드시 실 시스템에서 검증되어야 합니다. MOM은 어떤 시스템이건 핵심적이고 중요한 부분이고 신뢰할 수 있어야 합니다. 신뢰는 그냥 얻어지는 것이 아닙니다. 이를 위해 초기 적용자들의 두려움을 줄여주기 위해 반드시 핵심적인 업무시스템에 적용하여야 했습니다. 그래서 OpenAMQ와 Qpid를 함께 JPMorgan 업무시스템에 적용하였습니다. 이 시스템은 5대륙 2000명의 이용자가 사용하며 하루 억건의 데이타를 처리합니다.

3)마지막으로 AMQP는 초기단계부터 다른 사람들의 생각과 협력을 끌어내기 위해 개방성과 집단적 노력이 필요했습니다.이런 목적을 위해 우리는 주의깊게 규격을 정하고 소프트웨어를 함께 개발할 수 있는 파트너를 선택하였습니다. iMatix입니다. 오픈소스에 대한 공헌, 건강한 윤리의식을 가진 유럽계 개발회사이면서 기술적인 지식과 탁월한 글쓰기능력(Technical Writing)을 가진 집단이었습니다. 프로젝트는 은행에 의해 지원되었기 때문에 은행 내부를 설득하여야 했습니다. (wash its own face) 또한 프로젝트는 R&D가 목적이 아니었습니다. 운이 좋았지만 은행에서는 특수한 목적을 위해 대형시스템을 개선할 필요성이 있었고 결과적으로 AMQP투자가 좋은 결과를 낳았고 앞으로 갈 길이라는 확신을 CIO가 가질 수 있도록 하였습니다.