[Service Broker] 시작하며...

이런 저런 핑계를 대며 미루고 미뤘던 Service Broker - 이하 SSB라고 쓰겠습니다 - 에 대한 포스팅을 시작합니다.

- MESSAGE TYPE
- CONTRACT
- QUEUE
- SERVICE
- ROUTE
- ENDPOINT
- REMOTE SERVICE BINDING

SSB를 구성하는 개체들입니다만.. 각각의 역할과 각 개체 간의 상관 관계를 이해하기가 쉽지는 않더군요.
아마 MS SQL 구성 요소 중 가장 불친절한 친구 중 하나가 아닌가 싶습니다.

그럼에도 공부할 가치가 있는가?
네, 전 있다고 생각합니다.

Service Broker 란?

BOL을 보면 "메시징 및 큐", "서로 다른 데이터베이스 간에 통신", "데이터베이스 작업을 여러 데이터베이스에 분산" 이란 말이 나옵니다.

SSB를 제외하고 "서로 다른 데이터베이스 간에 통신", "분산" 이라고 할 만한 것으로 무엇이 떠오르시나요?
통신이라고 말하긴 어렵지만 그래도 전 OPENQUERY, OPENROWSET, DPV (Distributed Partitioned View) 정도가 생각 납니다.

결국은 Linked Server에서 파생하는 기능들입니다. (단, OPENROWSET은 빼야겠죠?)

Linked Server가 매우 유용하긴 하지만 제약이 따릅니다.
트랜잭션을 보장하기 위해 DTC를 사용해야하고 원격 서버에서의 처리가 완료될 때까지 대기해야 한다는 점입니다.
만약 원격 서버가 죽어 있다면? 당연히 Query 실행 전체가 실패합니다.

이 때문에 정책적으로 Linked Server를 사용하지 않고 별도의 Middleware Server를 개발하는 회사가 많습니다.

이에 반해, SSB는 TCP/IP를 사용하여 서로 다른 인스턴스 간에 메시지를 주고 받으며.. 큐를 사용하기 때문에 원격 서버에 메시지가 전달되는 것을 기다리지 않습니다.

즉, 비동기 처리가 가능하게 되었습니다.

그러면서도 메시지가 목적지에 배달되는 것을 보장하며, 원한다면 트랜잭션도 보장합니다.
(전송 못한 메시지가 있으면 SQL Server 프로세스가 내려가지도 않습니다. ㅠ.ㅠ)


Service Broker의 용도

다시 BOL을 인용해 보겠습니다.

- 비동기 트리거
- 안정적인 쿼리 처리
- 안정적인 데이터 수집
- 클라이언트 응용 프로그램에 대한 서버 측 분산 처리
- 클라이언트 응용 프로그램에 대한 데이터 통합
- 대량 일괄 처리

제목만으로는 모호하죠? 네, 뭔가 뜬 구름 잡는 느낌이 듭니다.

일단.. 제가 맡은 새 프로젝트에서 SSB를 두 가지 용도로 사용할 계획인데요, 포스팅도 이 두가지 용도에 초점을 맞춰 진행할 생각입니다.

1. 여러 게임 DB에서 한대의 게임 로그 DB로 게임 로그를 XML 포맷으로 전송 - 안정적인 데이터 수집에 해당

저는 게임 서버가 직접 쌓는 로그를 믿지 않습니다. 이유요? 정확하지 않기 때문입니다. 남기는 이벤트와 데이터 모두..

그래서 DB에서 각 이벤트 별로 변경 전 이미지와 변경 후 이미지를 직접 로깅하는 것을 선호하죠. (거의 Audit 수준)
막상 게임이 서비스되고 운영이 시작되면 로그의 정확성이 주는 잇점이 막대하기 때문입니다.

문제는 어디에 데이터를 적재하느냐인데, SSB를 제외하면 Local에 쌓고 Daily Batch로 ETL 처리할 수 밖에 없습니다.
그런데 이런 방식은 ETL 처리에 시간이 적지 않게 소요되고 실시간으로 로그를 조회하지 못하는 단점이 있습니다.

SSB를 사용하여 메시지의 처리 순서를 보장할 필요 없이 단방향으로 성능 위주의 로그 적재 프로세스를 다루겠습니다.

2. 게임 DB의 특정 테이블을 웹 & 모바일 App에서 접근하는 DB로 복제 - 비동기 트리거에 해당

log shipping, mirroring, replication을 사용하지 않고 SSB를 사용해 테이블을 복제하는 방법입니다.

게임 DB의 내용 중 웹이나 모바일에서 활용할 만한 데이터가 많습니다.
하지만 게임 DB에 직접 접속할 수는 없는 일이겠죠?

실시간이어야 한다는 조건을 달면 복제 기능 중 트랜잭션 복제를 사용하거나.. 별도의 솔루션 도입을 고려해 볼 수 있습니다.
후자는 추가비용이 발생하니 제외하고, 전자가 가장 일반적이겠습니다.

하지만, 복제 기능을 사용하면 테이블에 guid 컬럼이 붙게되는데.. 이게 영 못마땅합니다. ^^;

레퍼런스가 별로 없는 방법이기는 하지만.. 호기심이 생겼습니다.
잘되면 가장 효율적인 복제 수단 중 하나가 될테니까요.

p.s
최근 약 2년이 조금 못되는 기간.. 넥슨에서 서비스하고 있는 [드래곤 네스트] 모델링과 DB 개발을 전담하고 있습니다.
아.. 지금은 전담이 아니군요.
함께 일하는 DBA가 세분 더 있습니다.

고백하자면 게임을 처음부터 끝까지 모델링해 본 것은 [드래곤 네스트]가 처음이었습니다.
그 전에는 영화, 커뮤니티, 게임 빌링, SNS를 각각 2, 3년씩 했었습니다.

그리고 지금은 내년 CBT 예정인 새 프로젝트의 DB 개발을 하고 있습니다.

아는만큼 보인다고.. 마침 장르도 비슷한 게임이라서.. 많이 개선된 모델을 적용합니다.
대신 아직 검증하지 못한 SSB를 적용하기도 하죠.

내 직업이라하더라도 끊임 없이 요구되는 배움을 내 일과 병행하기란 쉬운 일이 아닌 것 같습니다.

바쁠 때는 바쁘다는 이유로, 한가할 때는 한 없이 게을러지는 이유로.. 더 익히고 내 것으로 만들어야할 지식에 차마 시선을 옮기지 못하는 자신을 발견하게 되니까요.

그런 면에서 이렇게 새 프로젝트에 사용해보지 않았던 기능을 적용해 보는 것이 제게 많은 도움이 되는 것 같습니다.

일과 배움을 동시에 할 수 있기 때문이겠죠? ^^