Transaction OutBox Pattern
결제 승인이 성공한 후, 결제 완료를 위해 결제 승인 이벤트 메시지를 발행해보자.
결제 승인 메시지 발행이 필요한 이유
상품 결제 프로세스 진행시 PSP 로부터 결제 승인이 성공으로 처리된 이후 2가지 프로세스가 필요합니다.
- 정산 프로세스
- 결제 내역을 장부에 기록
이 2가지 작업이 완료되어야 비로써 최종 결제 상품 등록이 완료 될 것 입니다.
2가지 프로세스 경우는 고객이 프론트 클라이언트 입장에서는 처리를 완료 할때까지 굳이 기다릴 필요는 없습니다.
그러니깐 결제 승인 처리 완료 그리고 결제 상태 업데이트를 진행 동시에 비동기 논블러킹 방식으로 2가지 프로세스를 진행 해야 합니다.
그래서 2가지 프로세스를 메시지 발행 통해 책임을 부여 할 예정입니다.
여기서 왜 이벤트 메시지 발행으로 처리 하는가?
이벤트 메시지 발행 통해 책임을 부여하는 이유에 대해 말씀드리려고 합니다. 보통 결제 승인 처리 이후 결제 상태 업데이트를 최종적으로 완료 한 뒤에
Wallet Service 서버로 직접 비동기로 호출 하면 되지 않는가 생각 할 수 있습니다. 이렇게 처리를 해도 괜찮지만 이벤트 메시지를 사용한 것에 대해
결제 API 서버가 직접 Wallet Service 서버를 알아야 하는데 있어서 그렇습니다.
결합도가 높아져서 그런데 SQS 를 이용해서 메시지를 전달하게 된다면 느슨한 결합이 되고 장기적으로 볼때 메시지 수신에 대한 문제가 발생시 관리 하는데 있어서 수월하기 때문입니다.
즉 예를들어 강하게 결합으로 인해 마침 Wallet Service 서버가 문제가 발생시 Wallet Service 서버로 호출을 못하는 경우 일반적으로 그 상태에서 중단되지만
SQS 로 느슨하게 결합하게 된다면 Wallet Service 서버가 문제가 생기더라도 다시 복구 할때까지 SQS 에 있는 메시지 큐에 메시지를 가져가지 않을테니
신뢰성 보장하기 위함 이라고 생각 하면 될듯 합니다.
다시 본론으로 넘어가서 여기서 메시지 발행에 있어서
- 결제 승인 하기
- 결제 승인 결과에 따른 결제 상태 업데이트
- 메시지 발행
- 메시지 발행 후 메시지 발송 상태 업데이트
이 4가지 중 하나라도 Exception 이 발생시 모두 롤백이 일어나야 합니다. 즉 1번, 2번은 성공 했지만
3번 메시지 발행 이후에 있어서 4번 프로세스에서 Exception 이 발생되었으면 1번 경우는 멱등성 원리로 해결 할 수 있지만
2번 경우는 DB Transaction 원리를 이용해서 롤백이 정상적으로 처리 되어야 합니다.
데이터베이스에 업데이트와 동시에 메시지를 안전하게 전송하는 방법으로 Transactional Outbox Pattern 방법이 있습니다.
Transactional Outbox Pattern 경우 메시지 큐에 발행할 이벤트 메시지를 트랜잭션에 포함시켜 함께 저장하는 방식 입니다.
이렇게 저장한 이후에 Message Relay 는 주기적으로 메시지를 읽어서 메시지 큐에 전송 합니다.
이 방법은 데이터베이스 트랜잭션을 이용해서 결제 상태 반영과 이벤트를 일관되게 반영할 수 있는 방법 입니다.
Copyright 201- syh8088. 무단 전재 및 재배포 금지. 출처 표기 시 인용 가능.
