바른모 블로그: 메시지 디스패처

제14회 한국자바개발자 컨퍼런스에서 필자가 발표한 "100줄로 완성하는 웹 서비스 플랫폼"은 원래 기업 통합 패턴(Enterprise Integration Patterns)의 메시지 디스패처 패턴(Message Dispatcher Pattern)을 설명하기 위한 프로젝트로 블로그 게시를 준비 중이다가 컨퍼런스에서 먼저 발표한 주제였다. 발표 당시 사실 전하고 싶었지만 제한된 시간으로 제대로 전하지 못했던 메시지 디스패처 패턴에 대한 이야기를 이 글을 통해 전하고자 한다.

기업 통합 패턴(Enterprise Integration Patterns)은 메시지 디스패처 패턴(Message Dispatcher Pattern)을 설명한다. 이 패턴은 다음과 같은 상황을 해결한다.

하나의 채널 위에서 메시지를 처리하는 복수의 소비자들을 조종하려면 어떻게 해야 할까?

Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf; Addison-Wesley 2004, 509쪽 그림 인용

메시지 디스패처는 경쟁 소비자 패턴(Competing Consumer Pattern)과 비슷하지만, 각 경쟁 소비자가 갖는 대등한 소비 패턴보다 정교하게 소비자들을 조종할 수 있는 패턴이다. 일반적으로 경쟁 소비자는 독립된 프로세스로 동작하는 반면 메시지 디스패처의 소비자는 스레드로 동작한다.

일반적으로 디스패처는 익숙한 용어이다. 가장 익숙하게 사용되는 곳은 Web MVC 프레임워크이다. 그러나 디스패처는 Web MVC보다 하부 구조인 서블릿 컨테이너의 매핑 정의에서부터 사용된다. 즉 서블릿 컨테이너의 배치 서술자(deployment descriptor)인 web.xml 파일에 <servlet-mapping> 태그의 URL 패턴과 서블릿을 지정하는 부분이 바로 서블릿 컨테이너에서 요청 URL과 서블릿을 연결하는 디스패치 매핑의 정의다. Spring MVC는 이 하부 디스패처 매핑에 다시 MVC 패턴을 위한 Spring의 자체 DispatcherServlet 클래스를 추가하여 서블릿 컨테이너가 수신한 웹 요청을 Spring 서비스(컨트롤러)로 디스패치한다.

웹에서 사용하는 디스패처는 웹의 요청과 응답을 중점으로 처리한다. 웹 디스패처는 수신한 요청으로부터 처리할 서비스를 탐색하고 탐색된 서비스로 요청을 전달하고 실행하여 실행 결과를 응답으로 반환하는 일련의 실행 작업을 처리한다. 반면 기업 통합 패턴의 메시지 디스패처는 메시지 중심이다. 기업 통합 패턴의 메시지 디스패처는 요청된 메시지를 실행자(performer)에게 디스패치한다. 메시지 디스패치 패턴에서 메시지 디스패처가 동기 방식으로 사용되는 경우 웹 디스패처처럼 메시지 디스패처의 요청 채널과 응답 채널은 동일하고, 비동기 방식으로 사용되는 경우 요청 채널과 응답 채널은 분리된다. 그러므로 메시지 디스패처를 웹 디스패처보다 더 포괄적인 패턴이라고 볼 수 있다. 즉 웹 디스패처도 메시지 디스패처의 일종으로 볼 수 있다.

웹 디스패처는 이벤트 기반 소비자로 일반적으로 POSA2의 반응자 패턴(Reactor Pattern)으로 구현된다. 반면 메시지 디스패처는 능동적인 폴링 소비자 패턴(Polling Consumer Pattern)이거나 수동적인 이벤트 기반 소비자 패턴(Event-Driven Consumer Pattern)도 될 수 있다. 반응자 패턴을 사용하는 웹 디스패처는 클라이언트의 요청에 대해 수동적으로 반응한다. 그러므로 클라이언트의 요청이 급증하는 경우 웹 디스패처는 병목이 발생할 수 있고, 웹 서비스가 장애인 경우 클라이언트는 웹 요청을 전달하지 못할 수가 있다. 이 문제를 해결하려면 별도의 부하 관리 로직을 웹 디스패처에 추가하여 부하가 급증하는 상황에 대처할 수 있다. 그러나 부하가 급증하는 상황을 우회하는 것은 그렇게 간단한 문제가 아니다. 웹 서비스에 장애가 발생하지 않게 하려면 웹 서비스의 안정성에 많은 노력을 기울여야 한다. 반면 메시지 디스패처는 능동적인 폴링 소비자가 될 수 있으므로, 자신의 상황에 맞추어 메시지의 처리량을 조정할 수도 있게 된다. 요청 메시지의 부하가 급증하거나 서비스를 중지하더라도 처리를 대기하는 메시지는 채널 즉 메시징 시스템의 큐에 일정시간 보관되기 때문이다. 즉 메시지 디스패처 패턴은 웹 디스패처 패턴보다 포괄적이기 때문에, 웹 디스패처 패턴의 부하 관리 방법에서는 고려되지 않는 비동기 시스템을 이용한 흐름 제어를 포함할 수 있다.

B2C를 위한 웹 서비스는 브라우저 화면 렌더링 위주의 컴퓨팅 시간이 길지 않은 단순 업무이고, 고성능 서버와 부하 분산기(Load Balancer)와 요청 부하의 예측을 통해 웹 서비스의 병목의 문제를 대비한다. 그리고 부하가 급증하는 경우나 애플리케이션에 장애가 발생한 경우, 네트워크 장비를 이용하여 웹 요청을 단순히 우회시키기도 한다. 그러나 B2B 웹 서비스에서는 위에 언급한 부하 급증이나 애플리케이션 장애 상황에서도 서비스를 중단할 수 없는 경우가 있다. 이런 장애 상황에서도 요청 기업은 장애 상태에 대한 구체적인 응답을 요구할 수도 있고, 요청의 수신도 요구할 수도 있다. 즉 기업 간 서비스는 일반 고객 서비스보다 거래의 중요도가 훨씬 더 높을 수 있기 때문이다. 이런 요구를 해결하기 위해서는 기업 통합 패턴의 보장 전송 패턴(Guaranteed Delivery Pattern)이 필요하다.

디스패처를 구현하는 일은 간단하지 않다. 디스패처는 독립적으로 동작하는 것이 아니라 요청 수신, 수행자 탐색, 할당, 전달, 처리, 응답 발신이 모두 포함돼야 제대로 동작할 수 있는 패턴이기 때문이다. 디스패처를 패턴으로 해석하는 방식도 제 각각이다. J2EE의 Dispatcher-View 패턴, POSA1의 Client-Dispatcher-Server 패턴, 기업 통합 패턴의 Message Dispatcher 패턴 등 Dispatcher를 포함하는 패턴은 다양하게 존재한다. 이 패턴들은 각각 강조하는 점과 쓰임새가 다르다. 그 중 "100줄로 완성하는 웹 서비스 플랫폼"에서는 메시지 디스패처의 관점의 디스패처를 구현했다.

JCO에서 발표한 “100줄로 완성하는 웹 서비스 플랫폼”은 발표 자료, 동영상, 프로그램 소스가 모두 공개되어 있으므로 통합 프레임워크가 웹 서비스를 구현하기 위해 어떻게 사용되었고 기업 통합 패턴의 메시지 디스패처가 어떻게 구현되었는지 해당 자료들을 참조하면 좀더 잘 이해할 수 있을 것이다.