Transaction Outbox Pattern

---

---

Transaction Outbox Pattern이란?

Transaciton Outbox Pattern은 외부 요청을 DB의 Transaction이 성공하면 성공시키는 걸 보장하기 위해 Outbox Table을 두고 Transaction 내에서 Outbox Table에 외부 요청의 요청 정보를 담고, 다른 요소가 비동기적으로 이 Outbox Table을 주기적으로 Polling 하면서 외부 요청을 하는 형식의 소프트웨어 디자인 패턴입니다.

쉽게 말해 다음과 같은 상황을 가정하겠습니다.

1. Business Logic 처리
2. 결과 DB TABLE 1에 저장
3. 결과 DB TABLE 2에 저장
4. Kafka에 이벤트 발행

1, 2, 3의 경우 Transaction으로 묶으면 원자성 (Atomicity)을 DB 단위에서 보장해 줍니다. 하지만 1, 2, 3은 성공 했는데 4가 실패하면 어떨까요? 일단 4의 Kafka는 DB Transaction으로 묶을 수도 없을뿐더러, 논리적인 단위로 묶는다고 해도 (Spring의 @Transactional 같은) 여러 가지 문제가 생깁니다.

1. 외부 요청 성공 시까지 DB Connection을 Pool에 반환하지 않는 문제
2. 대부분의 Business Logic이 성공 했는데 메시지 발행이 실패했다고 전체가 Rollback 되는 게 맞나
3. 등등...

이 경우 Transaction Outbox Pattern을 사용하면 4번에서 실제 Kafka에 메세지를 발행하는 게 아니라 Outbox Table 역할을 하는 DB TABLE 3에 메시지를 발행해야 한다는 사실을 기록하고, 다른 Thread나 MS들이 이 TABLE을 주기적으로 Polling 하면서 실제 메시지를 발행할 수 있습니다.

 

이걸 Cloud 인프라를 활용해서 구현하는 방법은 AWS의 문서에서 상당히 잘 설명하고 있어 참고하시는 걸 추천 드립니다.

트랜잭션 아웃박스 패턴 - AWS 권장 가이드

---

Global Transaction (2 Phase Commit)과의 차이와 장단점

DB 외의 여러 종류의 IO가 있을 때 거론되는 또 다른 패턴이 Global Transaction입니다. Global Transaction에서는 모든 IO가 자신이 한 동작을 Rollback 할 수 있는 Transaction을 제공하고, 논리적으로 같은 Transaction으로 묶어 원자성 (Atomicity)을 보장합니다. 

구조는 훨씬 더 깔끔하지만 아쉽게도 Rollback Transaction을 제공하는 IO 끼리만 쓸 수 있다는 치명적인 단점이 있습니다.

---

현실적으로 필요할까?

제 생각에는 필요할 때가 분명 있지만 대부분의 상황에서는 과합니다. (많은 소프트웨어 디자인 패턴에 공통되는 답변이네요)

Transaction Outbox Pattern의 구조는 굉장히 복잡성이 높습니다. 반면 대부분의 상황에서는 외부 IO가 조금 실패해도 치명적인 영향이 없습니다. 특히 Kafka 같은 고가용성의 IO를 이용한다면 IO가 실패했을 때 차라리 에러 로그를 남기고 수동으로 처리하는 게 공수가 덜 들지 않을까 싶을 정도입니다.

실제로 저도 현업에서 Transaction Outbox Pattern이 적용된 코드를 본 적이 한 번도 없고, 해당 패턴을 적용하려 했으나 너무 복잡하여 겉어 냈는데 그 후로도 문제없이 동작했다는 얘기를 풍문으로 들었을 뿐입니다.

---