Outbox 패턴 도입이유

Question

안녕하세요 강의 잘 듣고 있습니다. 강의를 듣다가 Outbox 패턴을 도입하는 이유가 이해되지 않아 질문드립니다. 기존에는 DB에 payout을 저장한 뒤 블록체인 RPC 호출이 실패하면 HTTP 오류를 반환하지만, DB에는 payout이 남아 있는 문제가 있다고 설명해 주셨는데요. 그런데 이 문제가 메시징 큐와 Outbox 패턴을 도입하는 것과 어떤 관계가 있는지 궁금합니다. 외부 RPC 호출로 인해 HTTP 오류가 발생하는 문제라면, DB에 payout을 저장하고 커밋한 뒤 202 응답을 반환하고, 별도 워커가 DB에서 데이터를 조회해 송금을 처리할 수도 있을 것 같습니다. 제가 이해한 Outbox 패턴은 DB 저장과 메시징 큐에 이벤트를 발행하는 과정에서 발생할 수 있는 유실 문제를 해결하기 위한 패턴입니다. 그렇다면 먼저 메시징 큐를 사용해야 하는 이유가 있고, 그다음 DB와 큐 사이의 일관성을 위해 Outbox 패턴을 도입하는 흐름이어야 할 것 같은데요. 강의에서 설명하신 RPC 호출 실패 문제를 해결하기 위해 왜 메시징 큐가 필요한 건지 궁금합니다.

Hong · Answer

안녕하세요 배고프면근손실님!! 질문 남겨주셔서 감사합니다. 질문해주신 부분은 정확하게 짚으신거에요. 절대 틀린말이 아니라고 생각합니다. 지금 결국 DB를 저장하고 나서 RPC 실패 시 HTTP 오류가 나는데, Payout만 남는다. 이 문제를 해결하기 위한 핵심은 메시징 큐가 아니라 결국 체인 호출을 HTTP 요청과 분리하는거죠. 말하신것처럼 커밋 후 202 돌려주고, 워커가 DB에서 처리하고자 하는 데이터를 꺼내서 처리하는 구조도 일반적으로 사용 가능해요. 이런 케이스에 대해서는 DB 테이블 자체가 작업 목록 역할을 하기 떄문에, DB와 큐 사이의 유실문제도 생기지는 않겠죠. OutBox도 맞는 말입니다. 결국 이중쓰기를 풀기위한 패턴이라, 큐를 쓰기로 했다는 전제가 먼저 있어야하는거죠. 제가 여기서 Redis(BullMQ)를 사용한 이유는 뭐 여러가지가 있겠지만 크게 나열해보자면 다음과같아요. 재시도, 백오프, DLQ와 같은 작업 처리 기능을 직접 만들지 않고 쓰기 위해서 워커가 DB를 계속 폴링하지 않게 하고 싶어서 어느정도의 학습 목적 - DB와 브로커 사이의 이중쓰기, 적어도 한 번 전달같은 문제가 실무에서는 되게 흔하다보니깐 Kafka, SQS, RAbbitMQ를 쓰는 실무에서 그대로 적용이 가능하다고 생각해서. 물론 이 패턴을 FOR UPDATE SKIP LOCKED같은 패턴으로도 풀 수 있어요. OutBox라는것은 구현하는 방식에 따라서 여러가지 구조로 구성은 가능하기 떄문이죠. 혹시 질문에 대한 답이 되셨을까요?? 추가적인 질문이 있다면 편하게 알려주세요!! 요즘 날씨가 많이 추워요 감기 조심하시고 감사합니다!