[번역] Microsoft Queuing Frameworks: SQL Service Broker vs. MSMQ

 원문주소: http://www.devx.com/dbzone/Article/34110

Microsoft Queuing Frameworks: SQL Service Broker vs. MSMQ

MS는 두개의 큐잉 프레임웍을 별도의 '브랜드'로 개발자들에게 제공했다: 그것이 바로 MSMQ와 SQL Service Broker다. 이 2개의 프레임웍은 많은 부분에서 같은 내용을 제공하지만, 몇 가지 중요한 부분이 다른데 그것들이 여러분의 큐잉 프로젝트를 선택하는 데 영향을 미칠 수 있다. MSMQ는 충분히 시간을 두고 검증된 기술이지만, SQL Service Broker는 대부분의 개발자들에게 새로운 것이다. 이 글은 이 프레임웍들 간에 몇 가지 다른 부분을 알려주고 여러분이 큐잉 기술을 선택하는 데 있어서 도움을 줄 것이다.

큐잉 프레임웍들은 아직도 엔터프라이즈 어플리케이션을 빌드하는 데 있어서 충분히 활용되지 못한 프레임웍들 중 하나다. 적절히 사용한다면, 그것들 덕분에 long-running 리소스 요청을 비동기로 처리하여 유저 인터페이스 반응이 개선되고, 몇 개의 서버들과 서비스들간에 부하가 분산되고, 접속이 끊긴 어플리케이션들에 비동기적인 접속을 제공하고, 클라이언트와 서버 사이의 커플링을 낮출 수 있다-그 외에도 여러 가지 장점이 있을 수 있다. 개발자들에게 진정한 이득은 이 서비스들을 제공하기 위한 어려운 구현들(heavy lifting)의 핵심적인 부분들을 MS가 이미 만들어 두었다는 점이다. 여러분에게는 SQL Server를 사용하면서 손으로 만든(hand-built) 큐를 유지하기 위한 author data schema이나 스토어드 프로시저가 전혀 필요하지 않다. 윈도우 개발자들을 위한 여러 다른 큐잉 서비스-IBM의 MQ 시리즈라든지 BEA의 MessageQ 같은-도 사용할 수 있지만, MSMQ와 Service Broker는 MS의 툴들을 사용하는 개발자들이 사용하기 가장 좋은 후보들이다. MSMQ의 비용, MS 개발자들에 대한 SQL Server의 효용성의 ubiquity, 그리고 이 두 프레임웍 모두를 사용하는 널리 퍼져 있는 윈도우 클라이언트 플랫폼들이 있기 때문에 MSMQ와 SQL Service Broker는 쉬운 선택이다.

MS는 본래 MSMQ를 Windows NT4 옵션 팩에 포함시켜 제공했었고, 이후로 여러 revision으로 발표되었다. DevX는 상세한 MSMQ의 내용과 프로그램 모델에 대한 몇 개의 글들을 올린 적이 있다-이 글의 왼쪽 컬럼에 있는 Related References section 링크를 보라. MSMQ는 모든 버전의 Windows Server(Windows NT 4 with the Option Pack 이후로), Windows 2000 Prof., 그리고 Windows XP에 무료로 포함되어 있다. MSMQ는 메시지를 송수신하고 큐를 관리하기 위한 API, COM, 그리고 .NET 인터페이스를 제공한다.

SQL Server 2005의 배포와 함께, MS는 또한 MSMQ를 대체하기 위한 Service Broker를 제공한다. DB 플랫폼과 더욱 밀착되어 있기 때문에, Service Broker는 데이터 집중적인 큐 연산에 더 효과적일 수 있다; 그러나, MSMQ와 달리, Service Broker를 사용하기 위해서는 반드시 SQL Server 라이센스가 필요하다. Service Broker의 기능성(functionality) 덕분에 여러분은 어떤 언어로든 SQL Server의 데이터에 접근할 수 있다. 또한, SQL Service Broker에 들어 있는 거의 모든 큐잉 연산은 T-SQL의 확장으로 실행될 수 있다.

MSMQ와 Service Broker 둘 다의 대중성에 비해 상호 비교가 없었다는 점은 놀랍다. 이 글에서 그 부분을 채우려고 한다.

두 툴들을 더 높은 시점에서 엄격하게 바라보면, 그 둘은 매우 닮아 있다; 둘 다 믿을 수 있는 first-in/first-out 우선 순위 큐잉과, 비동기 메시지 프로세싱, 그리고 다양한 언어의 접근 가능성을 제공한다. 그러나, 그것들의 다른 점으로 인해서 여러분은 둘 중 하나를 여러분의 개발 프로젝트에 적용하게 될 것이다.

표 1은 SQL Service Broker와 MSMQ를 간단하게 비교한 결과이다. 이 리스트는 별로 이해하기 쉽지는 않지만, 둘 사이의 가장 중요한 몇가지 차이를 보여준다. 포함된 주된 척도는 하나의 기술을 선택하는데 도움이 될만한 확인 가능한 특색들 또는 이슈들이다.

표 1. 특색 비교: 이 특색과 이슈들은 여러분이 MSMQ와 SQL Service Broker 중 여러분들의 개별적 프로젝트 또는 환경과 어울리는 하나의 기술을 결정하는 데 도움이 될 것이다.

특색/이슈	MSMQ	SQL Service Broker
가격	모든 비지니스 버전의 윈도우에서 공짜	SQL Server 2005 라이센스 필요
최대 성능	더 높은 성능	일반적인 메시징 함수들이 필요 없을 때는 더 낮은 성능
트랜잭션 성능	Distributed Transaction Coordinator를 사용했을 때는 비교적 비싼 트랜잭션	SQL Server의 내부 트랜잭션을 사용하는 효과적인 트랜잭션
코드 위치	큐잉 코드는 SQL Server에서 실행 불가능	메시지 프로세싱 로직은 SQL Server에서 실행 가능
타입 강제	메시지 타입과 계약을 통해 타입 강제 제공	타입 강제 없음
끊긴 큐잉	완전히 끊긴 상태에서의 큐잉 지원	메시지를 보내기 위해 SQL Server(최소한 Express Edition이라도)와 접속되어 있어야 함
백업	무시해서는 안 될 요소들만 백업	스탠다드 SQL Server 백업 프로시저를 통한 백업

이 표가 이 글의 남은 부분에 대한 편리하고 간단한 오버뷰가 될 것이다. 각각의 특색과 이슈를 살펴보자.

가격
MSMQ를 사용하는 데, 여러분은 반드시 Windows NT 4(Option Pack이 설치된), Windows 2000, Windows XP, Windows Server 2003 아무 버전 중 하나가 있어야 한다. 이런 광범위한 OS 플랫폼의 지원이 있기 때문에, 여러분이 'legacy' 플랫폼들에서 잘 돌아갈 큐잉 프레임웍을 찾는다면 MSMQ이 가장 좋은 선택이다. 거의 틀림 없이, SQL Service Broker 클라이언트는 이들 플랫폼 어디에서든 잘 돌아갈 것이다. 그 이유는 SQL Service Broker 클라이언트는 SQL Server 2005에만 접속할 수 있으면 작동되기 때문이다. 그러나, 많은 응용 프로그램들은 큐잉 컴포넌트들을 호스트하기 위해 SQL Server 2005를 추가로 설치하지 않은 환경에서 사용될 것이다.

작은 규모의 사업에서 흔히 발견되는 문제점은 과중한 부담을 짊어진 DB 서버이다. 아마도 DB 리소스의 가용성은 큐잉 플랫폼을 선택하는데 고려되지 않겠지만, 여러분의 DB가 이미 과부하 상태라면, 유일한 선택은 DB 플랫폼을 업그레이드 또는 증설하거나, 다른 큐잉 기술을 사용하는 것 뿐이다. 어떤 경우, 추가 DB 플랫폼을 설치하는 비용이 너무 많이 들어갈 수도 있다.

최고 성능
DB 플랫폼의 컴포넌트로서, SQL Service Broker에서 제공하는 메시징 성능의 신뢰도는 MSMQ에 비할 바가 아니다. 여러분이 MSMQ으로 트랜잭션 메시징을 사용하기로 결정했더라도, 여러분은 트랜잭션들을 관리하기 위해 DTC를 사용하는 추가 부담을 감수해야 한다. 그러나, 여러분의 응용 프로그램이 오류에 관대하다면(간혹 메시지를 잃어버린다 해도 괜찮다는 뜻) MSMQ는 더 나은 옵션일 수 있다. 개발자/관리자들에게 보안 및 메시지 손실 프로텍션을 끄더라도 괜찮다고 허락한다면 MSMQ로 더 나은 메시지 처리량을 얻을 수 있다. 보내고 받는 응용 프로그램들이 데이터-드리븐 응용 프로그램들이 아니라면 특히나 이것이 더 좋다. MSMQ는 더 나은 컨트롤의 입자성을 제공하여 메시지 퍼포먼스가 가장 중요할 때 유용하다.

분명히, 어떤 응용 프로그램에서든 보안성의 의도적인 제거는 바람직하지 않다. 더 나아가서, 필자는 이 방법이 메시지 유실을 참아줄 만한 극소수의 응용 프로그램에서나 사용될 만한 방법이라고밖에 생각이 안 된다. 그럼에도 불구하고, MSMQ는 개발자들에게 필요한 경우 사용할 수 있는 옵션이 될 수 있다.

트랜잭션 성능
대개의 경우, 큐잉 응용 프로그램들은 본래 데이터-드리븐 응용 프로그램들이다. 메시지 프로세싱 서비스는 데이터 보관소(data warehouse)에서 데이터를 찾고, 명령에 따라 아이템을 추가하는 등의 작업을 할 수 있다. 이런 경우에, SQL Service Broker를 사용한 큐잉 응용 프로그램은 MSMQ를 사용한 같은 응용 프로그램에 비해 어마어마한 이득을 볼 수 있는데, 그 이유는 SQL Service Broker는 트랜잭션 context들의 관리를 SQL Server 내부에서 하여 이득을 보기 때문이다. 반면 MSMQ는 반드시 Distributed Transaction Coordinator(DTC)에 의지하여야 MSMQ와 SQL Server 사이에 트랜잭션 컨텍스트들을 동일하게 할 수 있다. 특히 MSMQ와 DB가 다른 서버에서 돌아간다면, DTC를 사용함으로써 생기는 오버헤드는 엄청나다.

대부분의 경우, 큐잉 응용 프로그램이 데이터-드리븐 응용 프로그램을 지원한다면, SQL Service Broker가 가장 확실한 선택이다.

코드 위치
MSMQ와 SQL Service Broker는 둘 다 큐잉 응용 프로그램을 만드는 데 있어서 많은 유연성을 제공한다. 개발자들은 어떤 대중적인 개발 언어를 사용하든 큐잉 응용 프로그램을 만들 수 있다. 그러나, SQL Service Broker의 큰 장점 중 하나는 SQL Server에서 host하는 T_SQL을 이용해 sender와 receiver들을 작성할 수 있다는 점이다-SQL Server Broker는 자동으로 스토어드 프로시저를 활성화시켜 메시지를 처리하는 기능을 제공한다. MSMQ는 메시지들을 수신하고 처리하기 위해 외부 응용 프로그램이 필요하다. 그러므로, 데이터-드리븐 응용 프로그램에는 SQL Service Broker를 사용하면 더 많은 이득을 얻을 수 있다.

타입 강제?(Type Enforcement)
SQL Serviec Broker는 SQL Service Broker의 메시지 타입들(XML 스키마로 validate될 수 있는 named 데이터 타입들)과 계약들(sender로부터 전송된 메시지 다입들로의 변경)을 메시지 컨텐츠에 사용함으로써 MSMQ에 비해 엄청난 어드밴티지를 제공한다. MSMQ는 큐에 들어간 메시지들의 타입을 변경하는 서비스를 제공하지 않는다.

끊긴 큐잉(Disconnected Queuing)
MSMQ와 SQL Service Broker 모두 수신 큐가 없을 때 메시지를 보내는 방법을 제공한다. MSMQ는 MSMQ의 로컬 인스턴스를 필요로 하고, SQL Service Broker는 메시지를 받아줄 (최소한) SQL Server Express와의 접속이 필요하다. MSMQ와 SQL Server Express는 모두 무료지만, 대부분의 시나리오들에 있어서의 다른 문제는 SQL Server Express를 설치하고 설정하는 것이 그만한 가치가 있는가 하는 것이다. 여러분의 응용프로그램이 큐잉을 하기 위해 필수 요소 설정을 포함한 광범위한 SQL Server Express의 설치는 상당한 투자가 될 수 있다. MSMQ는 일반적으로 어떤 로컬 설정의 추가도 없이 끊긴 메시지를 관리한다.

만약 여러분의 응용 프로그램이 대상 큐가 사용 불가능할 때에도 메시지를 보내야 한다면(모바일 응용 프로그램을 생각해 보라), 이것은 여러분의 응응 프로그램에 충분한 고려 사항이 된다.

대체로, MSMQ는 끊긴 응용 프로그램을 위한 솔루션을 디자인할 때 보다 단순한 선택이 될 수 있다.

백업
평균적으로, SQL Service Broker 큐를 백업하는 것은 MSMQ 메시지 스토어의 백업에 비해 개발 그룹에게는 좀 더 자연스러운 프로세스이다. SQL Server에 상당히 의존하는 회사라면 잘 튜닝된 SQL Server 백업 프로세스를 가지고 있을 거라고 생각한다. SQL Service Broker 큐는 데이터 스트럭쳐이기 때문에, 그것들은 일반 DB 백업 프로세스와 동일하게 백업된다. 더 나가서, SQL Server에서 제공하는 증분 백업과 차이 백업, 그리고 복구 프로세스를 모두 사용할 수 있다.

반대로, MSMQ가 가능한 최고 속도의 메시징을 위해 최적화되어 있다면, 메시지는 오직 메모리에만 올라가 있을 것이다-그것들은 MSMQ 서비스를 재시작하기만 해도 모두 날아가 버린다. 불변의 MSMQ 메시지를 백업하는 것은 쉽지만, 작동 중인 MSMQ 인스턴스에 메시지들을 복구하려고 시도하는 것은 위험해 보인다. 거의 모든 상황에서, SQL Service Broker 큐의 메시지 백업이 더 쉽다.

다른 요소들
이 글에서, 필자는 MSMQ와 SQL Service Broker 사이에서 선택을 하기 위해 고려할 만한 요소들에만 집중하여 비교하려고 노력했다. 여러분은 여기 언급된 것들 말고 다른 요소들을 고려하려고 할 수도 있다.  일반적으로, 만약 여러분이 SQL 2005 인스턴스가 이미 사용중인 곳에서 데이터-드리븐 응용 프로그램을 개발한다면, SQL Service Broker의 사용을 심각하게 고려해야 한다. 그러나 만약 sender와 receiver 응용 프로그램들이 DB 서버와 연결되지 않고 SQL Server 2005의 설치가 불가능하다면 여러분은 MSMQ를 고려해야 한다.

끝으로, SQL Service Broker에는 이 글에서 다 담을 수 없는 넓은 범위의 지원되는 기능들(supported features)이 있으므로, SQL Service Broker가 점차 MSMQ를 누르고 MS 개발자들이 가장 많이 사용하는 큐잉 기술이 될 것이라고 생각한다. 이 이동은 SQL Server 2005 채택을 가속시킬 것이고, 그로 인해 가격 저항(비싸서 안사)이 떨어질 것이다. 만약 여러분이 SQL Service Broker를 사용한 응용 프로그램 개발에 흥미가 있다면, 정보를 얻을 수 있는 가장 좋은 길은 Roger Wolter의 책 "The Rational Guide to SQL Server 2005 Service Broker." 를 읽는 것이다.