outbox patten 구현해보기- (1)

Overview

이벤트기반 환경에서 DB상태변경과 함께 이벤트를 발생시켜야하는 경우가 있습니다.

 

예를들어 쇼핑몰에서 주문, 상품, 알림 서비스로 나누어져 있다고 생각했을 때, 주문이 완료되면 상품 재고가 감소되고 판매자에게 알림이 전송되어야 한다는 요구사항이 있다고 가정해 보겠습니다.

 

주문이 완료되면 ‘주문완료됨’이라는 메시지 발행과 함께 상품 , 알림 서비스는 ‘주문완료됨’ 이라는 이벤트를 구독하여 비즈니스 로직을 처리할 수 있을 것입니다.

 

모놀리틱 환경이라면 이벤트 구독으로 처리하지 않고, 로직을 트랜잭션으로 묶여 ACID를 보장받을 수 있겠지만,

이벤트기반 환경에서 주문서비스 주문로직이 이 완료된 후 메시지를 발행한다면 생각 할 점이 있습니다.

 

데이터의 일관성을 위해서는 트랜잭션이 커밋될 때 메시지가 pub되어야 하고, 커밋되지 않는다면 메시지가 pub되지 않아야 합니다.

하지만 트랜잭션 커밋과 메시지 pub의 시점을 고민해 보면 위 요구사항을 맞출수 없는 경우가 생깁니다.

두가지 케이스를 나누어서 생각해 보겠습니다.

1. Transaction 안에서 메시지를 pub한다. 이 경우 메시지만 pub되고 트랜잭션이 실패하는 케이스가 생길 수 있으므로 데이터 일관성이 깨집니다. 이유로는 DB 쿼리를 날리는 시점에 실패하거나, 비즈니스 로직에서 예외가 발생하는 등 여러 이유로 실패 하는 경우가 생길 수 있습니다.
2. Transaction 밖에서 성공시 메시지를 pub한다. 비즈니스 로직은 성공하여 트랜잭션은 commit되었지만, 메시지 pub에 실패하는 경우가 생길 수 있습니다. 그렇게 되면 이 메시지를 sub하는 서비스들은 메시지를 놓치게 됩니다. 결국 이 경우도 데이터 일관성이 깨집니다. 

이 경우를 회피하기 위해서 최소 한번(At least one)보낼 수 있는 방법 중 하나인 Transactional outbox pattern에 대해서 소개해 보려고 합니다.

outbox pattern을 구현하기 위해서 Polling publisher, Transaction log tailing 두 가지 방법이 있습니다. 

Polling publisher pattern

https://krishnakrmahto.com/transactional-messaging-in-microservices

 

RDBMS를 사용하는 애플리케이션에서 outbox테이블을 주기적으로 polling하여 메시지를 발행하는 방법입니다.

순서)

1. 비즈니스 로직을 수행한다.
2. outbox table에 이벤트 메시지를 insert한다.
3. 1,2번 과정을 트랜잭션안에서 수행한다.
4. Message Relay는 주기적으로 outbox table을 polling하여 메시지를 pub한다.
5. 메시지 pub가 성공하면, outbox table을 삭제한다.

 

코드가 길어서 다음 포스팅에서 계속하겠습니다.

https://hoony-devblog.tistory.com/63

outbox patten 구현해보기- (2)