Messaging

서비스에서 데이터를 변화시킴에 따라, 두가지 액션이 일어납니다.

이 두 액션은 한 트랜잭션 내에서 Atomic하게 처리되지 않으면 애플리케이션 안정성이 떨어집니다.

하지만 메시지 브로커는 DB 트랜잭션을 함께 사용할 수 없습니다. 그렇다면 데이터 변화와 메시지 발행을 확실하게 보장하려면 어떻게 해야하느냐.

Transactional Outbox Pattern

기존 서비스 Outbox 역할을 하는 테이블을 생성하고, 상태를 변화시키는 트랜잭션의 일부로 OutBox 테이블에 메시지를 Insert 시키는 것입니다. 이렇게 하면 하나의 DB 트랜잭션 내에서 Atomicity 는 보장이 됩니다.

Outbox 테이블은 메시지 발행을 위한 대기큐 역할을 하고,

메시지 릴레이 컴포넌트가 이 Outbox 테이블을 읽어서 실제 메시지 브로커로 발행을 시키는 역할을 합니다.

이 메시지 릴레이 컴포넌트는 2가지 방법으로 구현할 수 있습니다.

릴레이 컴포넌트가 주기적으로 Outbox 테이블을 Select 하여 이벤트 발행 후 해당 row를 삭제하는 것입니다.

폴링 비용 발생

DB의 저수준 Transaction log 를 Tailing 하는 방법입니다. ex) mysql binlog, oracle redolog 등

Outbox 테이블에 데이터가 기록되면 트랜잭션로그에 남게 되고, 로그를 읽어 들이는 모듈이 실제 메시지 브로커로 발행을 합니다.

저수준 API를 활용하여 직접 개발해도 되고, 관련 툴도 많습니다

참고 자료