Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- spring event
- docker
- branch 전략
- 수신자 대상 다르게
- 숫자 블록
- 디버깅
- 객체지향패러다임
- 쿠키
- 셀러리
- 백준
- 좋은 코드 나쁜 코드
- 검색어 추천
- 트랜잭샨
- 누적합
- 결제서비스
- gRPC
- 깊게 생각해보기
- 코드 계약
- piplining
- 알람 시스템
- 이분탐색
- AWS
- 구현
- 카카오
- 레디스 동시성
- BFS
- 완전탐색
- 프로그래머스
- prg 패턴
- jwt 표준
Archives
- Today
- Total
코딩관계론
메시지 발행과 데이터베이스의 트랜잭션을 어떻게 원자적으로 처리할까? (Transactional Outbox Pattern) 본문
개발/Hot-Stock
메시지 발행과 데이터베이스의 트랜잭션을 어떻게 원자적으로 처리할까? (Transactional Outbox Pattern)
개발자_티모 2024. 9. 10. 00:25반응형
의도
Transactional Outbox Pattern의 주요 의도는 데이터 일관성과 메시지 전송의 신뢰성을 동시에 보장하는 것입니다. 일반적으로, 메시지 브로커에 메시지를 전송하는 과정에서 데이터베이스 트랜잭션 실패가 발생하면 메시지 전송의 일관성이 깨질 수 있습니다. 이를 방지하기 위해 Transactional Outbox Pattern은 데이터베이스 내에 outbox 테이블을 별도로 생성하고, 트랜잭션 내에서 메시지를 기록함으로써 트랜잭션이 성공할 때만 메시지가 발행되도록 설계합니다.
이 패턴은 메시지 브로커(Kafka 등)로의 전송 보장을 목표로 하며, 메시지가 적어도 한 번 이상(at-least once) 전송되었는지 확인할 수 있는 구조를 제공합니다. 트랜잭션 내에서 데이터베이스와 메시지 전송을 하나로 묶어 일관성을 유지하는 것이 핵심입니다.
목적
Transactional Outbox Pattern은 다음과 같은 목적을 가지고 있습니다:
- 데이터 일관성 유지: 트랜잭션 내에서 데이터베이스 상태 변경과 메시지 발생을 묶어 일관성을 유지.
- 메시지 전송 보장: 메시지가 적어도 한 번 이상 성공적으로 전송될 수 있도록 설계.
- 시스템 안정성 확보: 데이터베이스와 메시지 브로커 사이의 신뢰성을 보장하여 장애 시에도 메시지 유실 방지.
고려 사항
Transactional Outbox Pattern을 설계하고 구현할 때 고려해야 할 몇 가지 사항이 있습니다:
- 추가 프로세스(Message Relay) 구현: Outbox 테이블에 기록된 메시지를 브로커에 발행하는 별도의 프로세스가 필요합니다. 이 프로세스는 주기적으로 Polling 방식 또는 이벤트 기반 트리거 방식을 사용해 메시지를 전송할 수 있습니다.
- 중복 메시지 처리: 이벤트 처리 서비스에서 중복된 메시지나 이벤트가 발생할 수 있으므로, 소비하는 서비스는 멱등성을 보장하는 로직을 가져야 합니다. 이를 위해 처리된 메시지의 고유 ID를 추적하여 중복된 메시지가 재처리되지 않도록 해야 합니다. 데이터베이스에 이미 처리된 메시지 ID를 기록하거나, Kafka의 Offset 등을 활용하여 메시지 중복을 방지할 수 있습니다.
시스템 구조 흐름
- Order 생성 트랜잭션:
- 애플리케이션이 트랜잭션을 시작하고, Order 테이블에 새로운 주문을 삽입합니다.
- 같은 트랜잭션 안에서 Outbox 테이블에 메시지를 기록합니다. 이 메시지는 나중에 이벤트를 발행하는 데 사용됩니다.
- 메시지 발행 준비:
- 트랜잭션이 성공적으로 커밋되면, Outbox 테이블에 기록된 메시지는 나중에 메시지 브로커(Kafka 등)로 발행할 수 있도록 저장됩니다.
- Message Replay:
- 별도의 프로세스 또는 서비스가 Outbox 테이블을 주기적으로 폴링하거나 이벤트 기반으로 트리거되어, 새로운 메시지가 있는지 확인합니다.
- 새로운 메시지가 있으면, 메시지를 발행하는 로직을 실행하여 Kafka 등의 메시지 브로커로 이벤트를 발행합니다.
- 메시지 발행:
- Outbox 테이블의 메시지를 처리하여, Kafka 등의 메시지 브로커로 이벤트를 발행합니다.
- 메시지 발행이 성공적으로 완료되면, Outbox 테이블에서 해당 메시지를 삭제하거나, 상태를 업데이트하여 더 이상 발행할 필요가 없음을 표시합니다.
구현 패턴
Transactional Outbox Pattern에서 Message Relay를 구현하는 방법에는 두 가지 주요 패턴이 있습니다:
1. 폴링 발행기 패턴 (Polling Publisher Pattern)
- 장점: 구현이 상대적으로 간단합니다. Outbox 테이블을 주기적으로 폴링하여 새로운 메시지가 있는지 확인하고, 메시지를 전송합니다.
- 단점: 지속적으로 테이블을 조회하기 때문에 데이터베이스에 부하를 줄 수 있습니다.
2. 트랜잭션 로그 테일링 패턴 (Transaction Log Tailing Pattern)
- 장점: 트랜잭션 로그를 모니터링하여 실시간으로 변경 사항을 감지합니다. 데이터베이스 부하가 적고, 처리 속도가 빠릅니다.
- 단점: 구현 복잡도가 높으며, 트랜잭션 로그에 접근할 수 있는 추가적인 기술이 필요합니다.
[참고자료]
https://microservices.io/patterns/data/transactional-outbox.html
반응형
'개발 > Hot-Stock' 카테고리의 다른 글
중복 뉴스 제거 (3) | 2024.12.09 |
---|---|
Virtual Thread를 사용한 크롤링 성능 80% 향상 (1) | 2024.09.16 |
결제서비스 - 결제 승인 시스템 구조와 Retry 전략[#52] (0) | 2024.09.03 |
결제서비스 - Checkout 서비스 구현 [#50] (0) | 2024.09.03 |
결제 서비스 개발기 (0) | 2024.09.02 |