#title Service Broker의 개념
[[TableOfContents]]

==== 개요 ====
Service Broker는 SQL Server 2005에서 새롭게 선보인 DBMS의 기능 중 하나로 비동기 메시지 처리를 위한 응용 프로그램 플랫폼이라 할 수 있다. Service Broker에는 분산 응용 프로그램은 물론 단일 데이터베이스 인스턴스 내의 응용프로그램에 사용할 수 있는 비동기 프로그래밍을 위한 인프라가 포함되어 있다. Service Broker를 이해하려면 다음과 같은 용어에 대한 이해가 필요하다. 용어를 이해하면 대부분 이해하는 것으로 봐도 된다.

 * Conversations(대화)
 * Message(메시지)
 * Contracts(계약)
 * Queues(큐)
 * Service(서비스)
 * Conversation Group(대화그룹)

각각의 용어에 대해서 살펴보자.  

==== Conversations(대화) ====
Conversation이란 끝점간의 안정적이고, 순차적이며, 비동기적인 메시지 전송이다. 대화 방식은 Dialog Conversation과 Monolog Conversation 이렇게 두 가지 방식이 있는데, Dialog Conversation은 정확히 두 끝점간의 양방향 메시지 전송이고, Monolog Conversation은 1:다의 끝점간의 메시지 전송이 가능한 대화 방식이다. SQL Server 2005의 Service Broker는 Dialog Conversation만 지원된다. 

attachment:sssb01.jpg

'''안정적(Reliable)'''
 * 메시지를 송/수신 할 때 문제가 발생하여 메시지의 송/수신이 중단 또는 실패되더라도 SQL Server는 계속 메시지 전달을 시도.
 * 안정성은 메시지 전달 시 발생할 수 있는 문제를 처리하는 코드를 따로 작성할 필요가 없음을 의미.
 * 필요에 따라 메시지를 계속 전달 할 필요가 없다면 메시지의 수명을 설정할 수 있다.
 * "안정적"의 또 다른 뜻은 통신 도중 메시지의 변경/소멸이 되지 않음을 뜻함.
 * Service Broker의 보안 설정이 Off라도 메시지 전송 시 변경여부를 확인하기 위하여 Checksum을 사용

'''순차적(In Order)'''
 * 보내진 순서대로 수신되고 처리될 것을 의미한다. 
 * 멀티 쓰레드 환경이나 네트워크 사정에 의해 수신되는 측에서 보내진 순서와 다르게 메시지를 받는다 하여도 보내진 순서대로 처리되므로 응용 프로그램에서는 메시지 처리 순서에 대한 수신 측의 처리는 신경 쓰지 않아도 됨

'''비동기적(Asynchronous)'''
 * 송신 응용 프로그램은 수신 측의 응용 프로그램에서 처리가 모두 끝날 때까지 기다릴 필요가 없음.
 * 2-Phase Commit처럼 빠른 시스템과 느린 시스템의 결합으로 처리 지연시간 발생으로 응용 프로그램이 전체적으로 느려지는 것을 걱정하지 않아도 된다. 

==== Message(메시지) ====
Message는 Conversation에서 교환되는 정보(또는 데이터)이다. 메시지의 구조는 다음과 같다. 

attachment:sssb02.jpg

메시지 헤더에는 반드시 메시지 유형이 포함되어야 한다. 전송되는 메시지는 XML형식일 수도 있고, JPG 파일 형식일 수도 있다. 메시지 유형의 이름은 서로 다른 데이터 정렬(Collation)로 구성된 데이터베이스간의 메시지로 전송될 수 있으므로 메시지 헤더는 이진 데이터 정렬을 사용한다. 그러므로 대소문자와 악센트 모두 정확히 일치시켜야 한다. 

수신된 메시지에 대해서 유효성도 검사할 수 있다. 대부분은 메시지는 기본적으로 XML형식을 권장한다. 하지만 XML 파싱의 부하가 존재하므로 적절한 옵션으로 운영 환경에서는 유효성 검사 옵션을 끄는 것이 바람직할 것이다. 메시지 유형의 자세한 정보는 sys.service_message_types 에서 확인 할 수 있다. 

==== Contracts(계약) ====
Contracts는 끝점 간의 협약이다. Service Broker는 계약을 강요할 수 있기 때문에, 대화를 처리하는 응용 프로그램은 처리할 수 없는 어떠한 메시지 유형도 수신하지 않을 것이라고 확신할 수 있다. 이 협약을 확실히 하기 위해서, 한 번 계약이 생성되면 메시지 유형의 목록을 변경할 수 없다. 유일한 방법은 계약을 삭제 후 재정의하는 것이다. 각 끝점에 대한 용어는 다음과 같다.

 * Initiator : 대화를 시작한 끝점
 * Target: 반대쪽 끝점

계약에 대한 자세한 정보는 sys.service_contracts에서 확인 할 수 있으며, 계약관계에 대한 자세한 정보는 sys.service_contract_message_usages에서 확인 할 수 있다. 

{{{
SELECT
	C.name Contract
,	M.name MessageType
,	CASE
		WHEN is_sent_by_initiator = 1 AND is_sent_by_target = 1 THEN 'ANY'
		WHEN is_sent_by_initiator = 1 AND is_sent_by_target = 0 THEN 'INITIATOR'
		WHEN is_sent_by_initiator = 0 AND is_sent_by_target = 1 THEN 'TARGET'
	END SentBy
FROM sys.service_message_types AS M 
	INNER JOIN sys.service_contract_message_usages AS U
	ON M.message_type_id = U.message_type_id
	INNER JOIN sys.service_contracts AS C
	ON C.service_contract_id = U.service_contract_id
ORDER BY 1, 2
}}}

==== Queues(큐) ====
메시지가 전달되는 동안에 메시지가 저장되는 곳을 Queue라고 한다. Service Broker의 큐는 메모리에 존재하는 것이 아니고, 디스크(정확히 테이블)에 저장된다. 그러므로 메시지가 안정적으로 전달될 수 있다. Queue가 존재하기 때문에 낮은 결합도(Loose Coupling)를 이야기 할 수 있다. Loose Coupling은 큐에 기록되는 작업과 기록된 작업을 읽어 가는 작업이 각각의 속도로 수행되는 것이 가능함을 말한다. 

Service Broker의 큐는 감춰진 내부 테이블을 사용하며, 자신만의 잠금 스키마를 사용한다. 내부적으로 감춰진 테이블을 사용하므로 여러 명령을 통해 Queue를 조작할 수 있다. 또한 CREATE QUEUE 명령으로 Queue를 생성할 때 FileGroup을 지정할 수 있어 Internal Table의 저장 위치를 지정할 수 있다. 만약 대용량 메시지 처리 시스템을 구현할 경우라면 Filegroup 지정을 통해 H/W의 성능을 제대로 이끌어 낼 수 있다. 

{{{
SELECT
	Q.name QueueName
,	I.name AS InternalName
FROM sys.service_queues AS Q
	INNER JOIN sys.internal_tables AS I
	ON Q.object_id = I.parent_object_id
}}}

만약 Queue의 내용을 보고 싶다면 SELECT하면 된다. Service Broker는 Queue와 같은 이름으로 뷰를 생성하기 때문에 조회가 가능하다. 조회 시는 Service Broker의 작업이 행에 대한 잠금을 얻기 때문에 WITH (NOLOCK)을 사용할 것을 권고한다. 

 * RETENTION 옵션: 메시지가 모두 처리될 때까지 Message Queue에 메시지는 저장된다. RETENSION 옵션이 켜져 있고, Status = 1 이면 처음 삽입된 메시지를 뜻하고, Status = 0이면 메시지가 읽혀졌음을 뜻한다. 
 * PRIORITY 옵션: 2005버전은 항상 0(Zero)이다. SQL Server 2005는 우선순위와 관계없이 순차적으로 처리되어야 한다. 구체적인 우선순위에 대한 처리 방법은 차기 버전으로 미뤄졌다. 

Queue의 종류는 일반 Queue와 sys.transmission_queue가 있다. Sys.transmission_queue는 메시지가 최종 목적지에 도달하기 전에 Service Broker가 메시지를 임시적으로 저장할 필요가 있을 경우에 메시지를 저장하는 곳이다. 이 Queue는 데이터베이스마다 1개 존재하며, 다음과 같은 경우 sys.transmission_queue를 사용한다. 

 * 목적지가 다른 SQL Server의 인스턴스에 존재할 경우
 * 목적지의 Queue가 비활성화된 경우(일반적인 원인은 ‘포이즌 메시지’)
 * 목적지의 Service Broker가 비활성화된 경우
 * 목적지를 알 수 없는 경우

==== Service(서비스) ====
Service는 끝점의 이름을 서비스의 이름으로 명명한다. 그러므로 다양한 의미를 가진 일반적인 Service는 SQL Server에서 단지 끝점의 이름을 뜻할 뿐이다. Queue의 이름을 그대로 Service 이름을 사용하지 않은 이유는 논리적인 독립성 때문이다. 즉, 물리적인 구성이 틀려도 같은 서비스 이름으로 응용 프로그램을 배포할 수 있기 때문이다. 

attachment:sssb03.jpg

서비스에 대한 제사한 정보는 sys.services에서 찾아 볼 수 있으며, 서비스와의 계약관계는 sys.service_contract_usages에서 찾아 볼 수 있다. 
{{{
--계약관계
SELECT
	S.name AS Service
,	Q.name AS Queue
,	C.name AS Contract
FROM sys.services AS S
	INNER JOIN sys.service_queues AS Q
	ON S.service_queue_id = Q.object_id
	INNER JOIN sys.service_contract_usages AS U
	ON S.service_id = U.service_id
	INNER JOIN sys.service_contracts AS C
	ON U.service_contract_id = C.service_contract_id
}}}

==== Conversation Group(대화그룹) ====
Conversation Group은 여러 메시지의 안정적인 순차적인 처리를 위해 필요한 옵션이다. 예를 들어, Message1, Message2, Message3가 순서대로 처리되어야만 트랜잭션이 실패가 아닌데, 멀티 쓰레드 환경에서 각각의 쓰레드가 메시지를 처리하여 Message2가 Message3보다 먼저 처리되었다면 이는 메시지 순서를 위반(아래 그림 참고)하는 것이다. 대화 그룹은 이러한 문제점을 해결해 준다. 

attachment:sssb04.jpg

Conversation Group은 다음과 같이 사용된다. 
{{{
BEGIN DIALOG @handle
FROM SERVICE InitiatorService
TO SERIVE 'TargetService'
ON CONTRACT 'TestContract'
WITH RELATED_CONVERSATION = @related_conversation_handle
}}}

==== Service Broker vs MSMQ ====
Microsoft의 대표적인 비동기 처리 솔루션은 MSMQ다. Service Broker는 자주 MSMQ와 비교되는데, 이를 정리하면 아래와 같다.  

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

==== 2008버전에서는? ====
2008버전에서 Service Broker에 우선순위를 매길 수 있는 기능과 진단도구를 제공한다. 우선순위는 다음과 같이 CREATE BROKER PRIORITY 문으로 설정할 수 있다. 1에서 10까지의 범위로 우선순위를 설정할 수 있으며 높을수록 우선순위가 높다. 
{{{
CREATE BROKER PRIORITY InitiatorAToTargetPriority
FOR CONVERSATION SET 
(
	CONTRACT_NAME = SimpleContract
,	LOCAL_SERVICE_NAME = InitiatorServiceA
,	REMOTE_SERVICE_NAME = N'TargetService'
,	PRIORITY_LEVEL = 3
);
}}}

비동기 처리라 모니터링이 쉽지 않은데 Microsoft는 ssbdiagnose라는 유틸리티를 제공하여 Service Broker의 진단을 도와준다. 2008버전에서는 Dialog Conversation도 지원되는 것으로 책에 쓰여있다.