트랜잭셔널 아웃박스 패턴이란?

[sangjun121]

한 트랜잭션 내에서 도메인 로직이 수행되고 외부 시스템에 이벤트를 온전히 보낼 수 없다면, 전체 시스템의 정합성이 깨질 수 있습니다. 그래서 외부 이벤트 발행 작업 또한 트랜잭션의 원자성을 보장해야합니다.

오늘 주제를 딥다이브한다기 보다 현재 진행하는 외부 API 연결 과제를 떠올리며, 외부 서비스 연결 혹은 외부로 이벤트를 발행하는 경우 고려할 수 있는 트랜잭션 원자성 보장에 대해 고민해보는 시간이 되었으면 좋겠습니다. 스터디의 취지에 맞게 아래 블로그를 가볍게 훑어보고 이런 개념이 있구나, 이런 정합성 문제를 고려할 필요가 있겠구나 고민해보는 것으로 넘어가도 충분할 것 같습니다.

질문

1. 트랜잭셔널 메시징이란?
2. 트랜잭셔널 아웃박스 패턴이란?

트랜잭셔널 아웃박스 패턴의 실제 구현 사례 (29CM)

[softmoca]

트랜잭셔널 메시징은 데이터베이스의 상태 변경과 메시지 발행을 하나의 논리적 작업으로 다뤄, 둘 중 하나만 성공해서 시스템 간 정합성이 깨지는 문제를 방지하는 방식입니다.
일반적인 DB 트랜잭션만으로는 외부 메시지 브로커나 API 호출까지 함께 원자적으로 묶을 수 없기 때문에 트랜잭셔널 아웃박스 패턴을 사용할 수 있습니다.

이 패턴은 도메인 데이터를 변경하는 트랜잭션 안에서 발행할 이벤트를 별도의 Outbox 테이블에도 함께 저장하고, 트랜잭션이 커밋된 이후 별도의 발행기가 Outbox를 조회해 외부 시스템으로 메시지를 전달합니다.
이를 통해 도메인 변경과 이벤트 저장은 원자적으로 보장할 수 있지만, 메시지가 중복 발행될 가능성은 있으므로 소비자의 멱등성 처리와 발행 상태 관리, 재시도 전략이 함께 필요합니다.

[koreaioi]

Outbox Pattern

DB 상태 변경과 메세지 발행의 불일치를 줄이기 위한 패턴.

트랜잭션 내부에서, DB상태 변경 + 메세지 발행을 함께 처리하지 않는다.
트랜잭션 내부에서, DB상태 변경 + DB에 이벤트 정보 저장을 함께 처리한다.

그리고 폴링이나 CDC방식으로 DB에 저장된 이벤트 정보를 브로커에 Publish한다.
브로커에 Publish할 때, 중복으로 발행할 수 있기 때문에, Consumer는 멱등성 처리가 필요

정확히 한 번이 아니라, 적어도 한 번을 위한 패턴

---

[haeyoon1]

트렌잭셔널 메시징은 비즈니스 로직의 성공과, 그에 따라 발생하는 메시지/이벤트 발생을 하나의 트랜잭션으로 정합성있게 처리하고자하는 방식입니다.
예를 들어 비즈니스 로직 발생 -> Kafka에서 이벤트를 발행 해야하는 작업이 있을 때
비즈니스 로직 발생 -> Kafka에서 이벤트 발행 실패!!가 발생하지 않도록하자 는 개념입니다.

트랜잭셔널 아웃박스 패턴은 아래와 같은 흐름을 거칩니다.

1. 도메인 로직 수행
2. 같은 DB 트랜잭션 안에서 outbox 테이블에 이벤트 저장⭐️ (<-도메인 변경 + outbox 저장을 하나의 트랜잭션으로 묶었다는 점이 중요)
3. 트랜잭션 커밋
4. 별도 프로세스가 outbox 데이터를 읽어 외부 시스템에 이벤트 발행 (<- 저장하는 작업과 외부로 보내는 작업 분리)
5. 발행 성공 시 상태 변경

이벤트 발행 정보를 DB에 남겨두지 않았다면, 실패한 이벤트를 다시 발행 수 없지만,
outbox 테이블에 이벤트가 남아 있다면, 나중에 배치나 메시지 릴레이가 다시 읽어서 재발행할 수 있습니다.

결과적으로 위와같이 정합성을 맞추는 방식을 eventual consistency(최종적 일관성)라고 볼 수 있습니다.

[Uechann]

DB 업데이트와 메시지 발행을 하나의 로컬 트랜잭션으로 묶기 위해,
발행할 메시지를 같은 DB의 outbox 테이블에 함께 저장하고,
별도 프로세스가 그걸 읽어 브로커로 보내는 패턴이다.

트랜잭셔널 메시징이란?

서비스 로직 실행과 그 이후의 이벤트 발행을 원자적으로 함께 실행하는 것이다.

하나의 명령은 보통 DB의 애그리거트를 생성/수정/삭제 하면서 동시에 메시지 브로커로 메시지, 이벤트를 보내야 하는데, 이둘이 모두 성공하거나 모두 실패하도록 보장하는 것이 트랜잭셔널 메시징이다.

이걸 구현하는 방법이 2가지가 있다.

• 트랜잭셔널 아웃박스 패턴
• CDC (change Data Capture)

트랜잭셔널 아웃박스 패턴이란?

메시지를 보내는 서비스가, 비즈니스 엔티티를 갱신하는 그 트랜잭션의 일부로서
메시지를 먼저 DB에 저장하고, 별도의 프로세스가 그 메시지를 메시지 브로커로 발행하는 방식이다.

즉, 메시지를 외부로 보내는 행위를 트랜잭션에 넣는게 아니라 메시지를 보내겠다는 기록 을 같은 DB에 넣어서 원자성을 확보한다는 것이다.

---

어떻게 동작하나?

트랜잭션 안에서 outbox에 기록하고
→ 트랜잭션 밖의 릴레이가 읽어서 발행하고
→ 발행 완료 표시를 한다.

• Sender (메시지를 보내는 서비스)
• Database (비즈니스 엔티티와 outbox를 저장)
• message outbox (관계형이면 테이블, NoSQL이면 레코드 속성)
• Message relay (outbox의 메시지를 브로커로 보냄)

Message Relay 두가지 구현

• Polling Publisher: 릴레이가 outbox 테이블을 주기적으로 폴링해서 미발행 행을 읽어 발행.
  구현이 단순하지만 폴링 주기/부하 트레이드오프가 있다.
• Transaction Log Tailing: DB 트랜잭션 로그(MySQL binlog 등)를 추적해 발행.
  이게 CDC 방식이다.

즉 outbox vs CDC는 배타적이라기보다,
아웃박스 테이블을 두되 그 테이블을 비우는 릴레이를 폴링으로 짤지
CDC로 tailing할지의 선택으로 볼 수 있다.