Service Broker의 장점

데이터베이스 통합

Service Broker의 통합된 디자인은 응용 프로그램 성능과 관리 면에서 장점을 제공합니다.

SQL Server와의 통합을 통해 외부 DTC(Distributed Transaction Coordinator)에 대한 추가적인 오버헤드 및 복잡성 없이 트랜잭션 메시지를 사용할 수 있습니다. 응용 프로그램에서는 하나 이상의 메시지를 받고 해당 메시지를 처리하며 단일 데이터베이스 트랜잭션 내에서 응답 메시지를 보냅니다. 트랜잭션이 실패하면 처리 작업을 다시 시도할 수 있도록 모든 작업이 롤백되고 수신된 메시지가 큐로 반환됩니다. 응용 프로그램에서 트랜잭션을 커밋할 때까지 어떤 작업도 이루어지지 않습니다. 응용 프로그램은 일관된 상태로 유지됩니다.

데이터, 메시지 및 응용 프로그램 논리가 모두 데이터베이스에 있으면 응용 프로그램의 관리(재해 복구, 보안, 백업 등)가 일상적인 데이터베이스 관리의 일부가 되고 관리자는 3-4개에 이르는 별도의 구성 요소를 관리할 필요가 없으므로 관리가 더욱 쉬워집니다.

기존 메시징 시스템을 사용하면 메시지 저장소와 데이터베이스에 일관성이 없게 될 수 있습니다. 예를 들어 구성 요소 하나가 백업에서 복원될 때 다른 구성 요소도 동시에 수행된 백업에서 복원되어야 합니다. 그렇지 않으면 메시지 저장소의 정보가 데이터베이스의 정보와 일치하지 않게 됩니다. Service Broker에서는 같은 데이터베이스에 메시지와 데이터를 저장하므로 불일치는 문제가 되지 않습니다.

공통 개발 환경도 데이터베이스 통합의 장점입니다. 응용 프로그램의 메시징 부분과 데이터 부분은 Service Broker 응용 프로그램에서 같은 SQL Server 언어 및 도구를 사용할 수 있으므로 메시지 기반 프로그래밍을 위한 데이터베이스 프로그래밍 기술에 익숙한 개발자의 능력을 적극 활용할 수 있습니다. Service Broker 서비스를 구현하는 저장 프로시저는 Transact-SQL 또는 CLR(공용 언어 런타임) 언어 중 하나로 작성할 수 있습니다. 데이터베이스 외부의 프로그램에서는 Transact-SQL 및 ADO.NET 같이 익숙한 데이터베이스 프로그래밍 인터페이스를 사용합니다.

이와 함께 데이터베이스 통합을 통해 자동 리소스 관리도 수행할 수 있습니다. Service Broker는 SQL Server 인스턴스의 컨텍스트에서 실행되므로 이 인스턴스의 모든 데이터베이스에서 전송 준비가 된 메시지를 모두 모니터링합니다. 따라서 각 데이터베이스는 Service Broker가 전체 SQL Server 인스턴스에서 리소스 사용을 관리하도록 지원하면서 자체 큐를 유지 관리할 수 있습니다.

메시지 순서 지정 및 조정

기존 메시징 시스템에서는 응용 프로그램이 잘못된 순서로 도착하는 메시지의 순서를 지정하고 조정하는 작업을 담당했습니다. 응용 프로그램 A에서 메시지 1, 2 및 3을 보내는 경우 응용 프로그램 B에서 메시지 1과 3을 받아 승인하지만 메시지 2에 대해서는 오류가 발생하는 경우를 예로 들어 보겠습니다. 이 경우 응용 프로그램 A가 메시지 2를 다시 보내지만 메시지 2는 메시지 1과 3 이후에 수신됩니다. 과거에는 메시지 순서에 문제가 발생하지 않도록 개발자가 응용 프로그램을 작성하거나 응용 프로그램에서 올바른 순서로 메시지를 처리할 수 있도록 메시지 2가 도착할 때까지 임시로 메시지 3을 캐시해야 했습니다. 그러나 두 가지 모두 간단한 해결 방법이 아닙니다.

기존 시스템의 또 다른 문제는 중복 배달입니다. 앞의 예에서 응용 프로그램 B가 메시지 2를 받지만 응용 프로그램 A로 보낸 승인 메시지가 손실될 경우 응용 프로그램 A가 메시지 2를 다시 보내게 되므로 응용 프로그램 B는 메시지 2를 두 번 받게 됩니다. 응용 프로그램 코드는 중복 메시지를 식별하여 삭제하거나 부정적인 영향 없이 중복 메시지를 다시 처리할 수 있어야 했습니다. 다시 말해서 두 가지 방법은 모두 구현하기 어려웠습니다.

메시지 조정 역시 처리하기 어려운 문제였습니다. 예를 들어 응용 프로그램은 수많은 요청을 서비스에 제출할 수 있습니다. 서비스에서는 요청을 병렬로 처리하고 처리가 끝나자마자 바로 응답을 반환합니다. 각 요청을 처리하는 데 걸리는 시간이 다르기 때문에 응용 프로그램에서는 보내는 메시지를 전송한 순서와는 다른 순서로 응답을 받습니다. 그러나 응답을 제대로 처리하기 위해서는 응용 프로그램에서 각 응답을 해당 보내는 메시지에 정확히 연결해야 합니다. 기존 메시징 시스템에서는 각 응용 프로그램에서 이러한 연결을 관리했기 때문에 응용 프로그램 개발 비용과 복잡성이 커졌습니다.

Service Broker는 메시지 순서, 고유한 배달 및 대화 식별을 자동으로 처리함으로써 이러한 문제를 해결합니다. 두 Service Broker의 끝점 사이에 대화가 설정되고 나면 응용 프로그램에서는 각 메시지를 보낸 순서대로 한 번씩만 메시지를 받습니다. 사용자 응용 프로그램에서는 추가 코드 없이 순서대로 정확히 한 번씩만 메시지를 처리할 수 있습니다. 마지막으로 Service Broker는 모든 메시지에 자동으로 식별자를 포함합니다. 응용 프로그램에서는 항상 특성 메시지가 속해 있는 대화를 알려 줍니다.

느슨한 연결 및 작업 유연성

Service Broker에서는 초기 응용 프로그램과 대상 응용 프로그램 사이에 느슨한 연결을 제공합니다. 응용 프로그램에서는 큐에 메시지를 보낸 다음 계속하여 응용 프로그램 처리를 진행하되 Service Broker를 통해 메시지가 대상에 도착했는지 확인할 수 있습니다. 이처럼 연결이 느슨하면 유연한 일정 예약이 가능합니다. 시작자는 여러 메시지를 내보낼 수 있고 여러 대상 서비스에서는 이를 병렬로 처리할 수 있습니다. 각 대상 서비스는 현재 작업에 따라 고유한 속도로 메시지를 처리합니다.

또한 큐 작업을 통해 시스템에서는 더욱 공평하게 처리를 배포할 수 있으므로 서버에 필요한 최대 용량도 줄어듭니다. 이렇게 하면 데이터베이스 응용 프로그램에서 전반적인 처리량과 성능이 향상됩니다. 예를 들어 여러 데이터베이스 응용 프로그램은 하루의 특정한 시간에 트랜잭션이 급증하기 때문에 리소스 사용이 증가하고 응답 시간이 느려집니다. Service Broker를 사용하면 이러한 응용 프로그램에 비즈니스 트랜잭션을 제출할 때 응용 프로그램이 모든 처리를 수행할 필요가 없게 됩니다. 대신 응용 프로그램에서는 Service Broker를 사용하여 백그라운드 처리를 수행하는 응용 프로그램에 트랜잭션에 대한 정보를 보낼 수 있습니다. 이러한 응용 프로그램은 일정 기간 동안 안정적으로 트랜잭션을 처리하지만 기본 입력 응용 프로그램에서는 새 비즈니스 트랜잭션을 계속하여 받게 됩니다.

대상을 즉시 사용할 수 없는 경우 메시지는 보내는 데이터베이스의 전송 큐에 남습니다. Service Broker에서는 메시지가 성공적으로 전송될 때까지 또는 대화의 수명이 만료될 때까지 메시지를 다시 시도하여 하나의 서비스가 대화 중 특정 시점에 잠시 사용 불가능하게 되더라도 두 서비스 사이의 안정적인 대화가 계속 진행될 수 있도록 합니다. 전송 큐의 메시지는 데이터베이스의 일부이므로 Service Broker는 인스턴스가 실패하거나 다시 시작해도 메시지를 배달합니다.

관련 메시지 잠금

기존 메시징 응용 프로그램에서 수행하기 가장 어려운 작업 중 하나는 여러 프로그램이 같은 큐에서 병렬로 메시지를 읽을 수 있도록 하는 것이었습니다. 기존 메시징 시스템에서는 여러 프로그램 또는 여러 스레드가 같은 큐에서 읽는 경우 메시지가 잘못된 순서로 처리될 수 있습니다. Service Broker에서는 대화 그룹 잠금을 통해 이러한 문제가 발생하지 않도록 합니다.

일반적인 주문 처리 응용 프로그램을 가정해 보겠습니다. 주문 헤더를 만드는 지침이 들어 있는 메시지 A와 주문 라인 항목을 만드는 지침이 들어 있는 메시지 B가 모두 큐에 수신되었습니다. 별도의 응용 프로그램 인스턴스가 이 두 메시지를 큐에서 빼서 동시에 처리하면 주문 라인 항목 트랜잭션은 먼저 커밋을 시도하게 되는데 주문이 아직 없기 때문에 커밋에 실패합니다. 차례로 커밋에 실패하게 되면 트랜잭션이 롤백되고 메시지가 다시 큐에 들어가 처리되므로 리소스가 낭비됩니다. 일반적으로 프로그래머는 메시지 A와 메시지 B의 정보를 단일 메시지로 조합하여 이 문제를 해결했습니다. 이러한 방법은 메시지가 두 개인 경우에는 간단하지만 수십, 수백 개에 이르는 메시지를 조정하는 데는 부족합니다.

Service Broker에서는 대화 그룹에서 관련 대화에 연결하는 방법으로 이 문제를 해결합니다. Service Broker는 같은 대화 그룹의 모든 메시지를 자동으로 잠그기 때문에 이러한 메시지는 하나의 응용 프로그램 인스턴스에서만 수신하고 처리할 수 있습니다. 한편 다른 응용 프로그램 인스턴스는 다른 대화 그룹의 메시지를 계속해서 큐에서 빼서 처리할 수 있습니다. 따라서 응용 프로그램에 복잡한 잠금 코드가 없어도 여러 병렬 응용 프로그램 인스턴스가 안정적이면서 효율적으로 작업을 수행할 수 있습니다.

자동 활성화

Service Broker의 기능 중 가장 유용한 것으로 활성화를 들 수 있습니다. 활성화를 사용하면 응용 프로그램이 큐에 도착하는 메시지 볼륨에 맞게 크기를 동적으로 조정할 수 있습니다. Service Broker는 데이터베이스 내부에서 실행되는 프로그램과 데이터베이스 외부에서 실행되는 프로그램 모두에서 활성화를 활용하는 기능을 제공합니다. 그러나 Service Broker에서는 응용 프로그램이 활성화를 사용할 필요가 없습니다.

Service Broker는 큐의 작업을 모니터링하여 사용 가능한 메시지가 있는 모든 대화에 대해 응용 프로그램이 메시지를 받는지 여부를 확인합니다. Service Broker 활성화는 큐 판독기가 수행할 작업이 있을 때 새 큐 판독기를 시작합니다. 큐 판독기가 수행할 작업이 있는 시기를 확인하기 위해 Service Broker에서는 큐의 작업을 모니터링합니다. 큐 판독기의 수가 들어오는 트래픽에 일치할 경우 큐는 정기적으로 큐가 비어 있는 상태 또는 큐의 모든 메시지가 다른 큐 판독기에서 처리 중인 대화에 속하는 상태에 이르게 됩니다. 큐가 일정 기간 동안 이러한 상태에 이르지 않으면 Service Broker는 다른 응용 프로그램 인스턴스를 활성화합니다.

응용 프로그램은 데이터베이스 내부에서 실행되는 프로그램과 데이터베이스 외부에서 실행되는 프로그램에 대해 서로 다른 활성화 방법을 사용합니다. 데이터베이스 내부의 프로그램에 대해서 Service Broker는 큐에서 지정한 저장 프로시저의 다른 사본을 시작합니다. 데이터베이스 외부의 프로그램에 대해서 Service Broker는 활성화 이벤트를 생성합니다. 이 이벤트를 모니터링하여 다른 큐 판독기가 필요한 시기를 확인할 수 있습니다.

Service Broker는 활성화를 통해 시작된 프로그램을 중지하지 않습니다. 대신 활성화된 응용 프로그램은 메시지가 도착하지 않은 일정 기간 이후 자동으로 종료되도록 작성됩니다. 이러한 방법으로 설계된 응용 프로그램을 사용함으로써 서비스에 대한 트래픽 변경으로 인해 여러 응용 프로그램 인스턴스가 동적으로 증가하고 감소할 수 있습니다. 또한 시스템이 종료되거나 다시 부팅되면 시스템을 다시 시작할 때 응용 프로그램에서 자동으로 큐의 메시지를 읽기 시작합니다.

기존 메시징 시스템에는 이러한 동작이 없으므로 지정된 시간에 특정 큐 전용인 리소스가 너무 많거나 적으면 종료되는 경우가 많습니다.

참고 항목

관련 자료