들어가며

#1 이전글을 작성하기 위해 자료를 찾던 중 JMS(Java Message Service)를 소개하는 오라클 문서를 발견했다.
해당 문서에서는 MOM(Message-Oriented Middleware)이라는 용어가 나왔는데,
당시 다소 낯설은 용어 때문에 자세히 읽어보는 것을 보류했었다. 그래서 이번에 MOM이 무엇인지 살펴보려 한다.

미들웨어(Middleware)

• 앞서 언급된 오라클 문서의 내용을 임의로 편집하여 해석하였습니다.

비즈니스 상황에 따라 지속적으로 변하는 소프트웨어의 변화를 수용하기 위해서는 가능한 효과적으로 새로운 컴포넌트를 통합하고 기존의 컴포넌트들을 확장시켜야 한다. 다양한 컴포넌트들을 통합하는 가장 쉬운 방법은 서로 다른 형태임에도 불구하고 커뮤니케이션이 가능하도록 계층(layer)을 제공하는 것이다. 이러한 계층을 미들웨어라고 한다.

미들 웨어는 크게 통신 방식에 따라 3종류로 분류되며 다음과 같다.

1. RPC-based Middleware(Remote Procedure Call)

• 분리된 어플리케이션의 프로시저(procedure)호출을 가능하게 하는 미들웨어

2. ORB-based Middleware(Object Request Broker)

• 객체(Object)의 분산 및 공유를 가능하게 하는 미들웨어

3. MOM-based Middleware(Message Oriented Middleware)

• 메시지(Message)송,수신을 통하여 분산된 어플리케이션 간의 통신을 가능하게 하는 미들웨어

위와 같은 분류체계는 프로시져(Procedure), 객체(Object), 메시지(Message)중 어떤 것을 중심으로 통신하는지에 따라 분류한 것으로 보여진다만..
프로시져, 객체, 메시지의 개념적인 구분에 대한 설명이 자세히 나와있지는 않은 듯 하다.

MOM(Message-Oriented Middleware)

MOM시스템은 기본적으로 클라이언트, 메시지, MOM제공자(provider)로 구성된다.
MOM제공자는 메시지를 전달(deliver) 및 전송(route)함에 있어서 크게 2가지 아키텍처를 갖는다.(일부 MOM제품들은 2가지 형태의 방법을 모두 제공하기도 한다.)

1. 중앙집중화된 서버 형태
2. 분산된 서버 형태

MOM시스템의 장점

RPC, ORB기반의 시스템들이 동기적으로 통신하는 것과는 달리 MOM기반의 시스템은 비동기적으로 통신하며,
컴포넌트들 간에 상대적으로 약한 결합이 발생한다는 점에서 이점이 있다.
따라서 클라이언트는 메시지를 보내고 난 이후에 다른 작업을 진행할 수 있다.(응답을 기다리지 않고)

MOM시스템의 또 다른 이점은 관리자 인터페이스를 추가한다면 성능을 관측하고 조정할 수 있다는 것이다.
클라이언트 프로그램의 관점에서 보면 메시지 송수신과 메시지의 처리에만 집중하면 된다는 점에서 효과적이다.

MOM시스템의 단점

MOM시스템은 컴포넌트들 간에 느슨한 결합(비동기적인 통신) 때문에 Message처리가 실패하더라도 Message를 호출한 Client는 작업을 이어나간다.
즉, 이러한 점에서 실패를 추적하는 것이 까다로울 수 있다.

마치며

'미들웨어'도 'MOM'도 아직은 낯설지만 생각보다 어려운 내용이 아닌 것 같은 느낌을 받는다.
Celery와 Message Queue가 곧 Client와 Message Provider일 것이기에,
구현체로서의 Celery를 다루다보면 MOM에 더 익숙해질 수 있을 것 같다.
별개로, 영문 문서를 읽다보니 뒤로 갈수록 빨리 마무리 짓고 싶은 마음이 강해지더라..

Celery란 무엇인가

Celery공식 문서에서는 Celery를 이렇게 소개한다.

Celery is a simple, flexible, and reliable distributed system to process vast amounts of messages, while providing operations with the tools required to maintain such a system

정의에 따르자면 Celery는 (단순하고 유연하고 신뢰할만한) '메시지를 처리하는 분산된 시스템'이다.

다만 해석을 더하자면, Celery는 시스템 그 자체라고 보기는 어렵고 시스템을 구성하는 한 요소로 봐야될 듯 하다.
위 정의에서도 언급되듯이 Celery는 시스템을 유지하기 위해서 다른 도구들을 필요로 한다.
추측하자면 도구들은 Redis 혹은 RabbitMQ를 비롯한 Message Broker를 지칭하는 듯 하다.

메시징 시스템

그렇다면 메시지를 처리하는 분산된 시스템은 무엇일까.. 무슨 일을 하는, 어떤 목적을 갖는 시스템인 것일까..
보다 익숙한 표현으로서 '메시징 시스템'을 검색하면 JMS(Java Message Service)를 소개하는 오라클 문서가 나온다.
해당 문서에서는 MOM(Message-Oriented Middleware)라는 단어가 나온다.. 익숙치 않은 '미들 웨어'라는 단어가 다시 등장한다.
MOM에 대한 이해는 접어두고 위키피디아를 이용해보자..

위키피디아에서 Messaging System이 나온다. 정확히는 Enterprise Messaging System이다. 정의를 살펴보자.

An enterprise messaging system (EMS) or messaging system in brief[1] is a set of published enterprise-wide standards that allows organizations to send semantically precise messages between computer systems.

'의미론적으로 정확한(sementically precise)메시지 전송을 컴퓨터 시스템 간에 가능하게하는 표준들의 집합'이라고 한다.
다소 명확하게 이해가 안되는 부분이 있지만 억지로 해석을 해보자면

• '의미론적으로 정확한(sementically precise) 메시지' -> 아마 통신 규약(protocol)을 염두한 것이 아닐까 추측해본다.
• '컴퓨터 시스템 간에', '메시지 전송' -> 메시징 시스템이 분산된 시스템 사이에서 메시지를 전송하는 시스템인건 맞는 듯하다. 컴퓨터가 전송하는게 뭐.. 데이터겠지만, 다만 메시지가 정확히 어떤 형태인지는 아직 아리송하다.
• '표준들의 집합' -> 표준이라는 건 규칙을 말하는 것일까, 가장 이해하기 어려운 부분이다.

정의에 너무 천착할 수는 없고 여하튼 그 이름에서 느껴지는 이미지를 크게 벗어나지는 않는다.

'분산된 시스템 사이에서 메시지 형태의 데이터 송수신을 가능하게 하는 시스템'정도로 정리해 볼 수 있지 않을까 싶다.

마무리

목표는 Celery의 정확한 역할과 사용법을 찾아 보고, 나아가 Message Broker로서 자주 사용되는 Redis와 RabbitMQ의 차이를 정리해보는 것이였지만.. 역시 문서로 정리한다는 것은 품이 많이 들어간다.
MOM은 꼭 다시 살펴보자.