인프런 커뮤니티 질문&답변

자기개발하고싶어요님, 안녕하세요!

동시성 문제 중 중복 발행되는 상황에 대해서 말씀을 주신 것 같은데요, 드물긴 하지만 충분히 가능한 케이스입니다.

하지만 outbox 패턴은 이벤트 유실 방지에 초점을 맞춘 전략인 것이지, 중복 발행을 방지하기 위한 방법에 초점을 맞춘 전략은 아닙니다.

또, 중복 발행은 해당 케이스 외에도 다양한 상황에 발생할 수 있습니다.

신규 앱 시작/종료 시점에 코디네이터가 파티션 재할당 하는 과정 중 각 app에 중복으로 파티션을 할당할 수도 있고, 카프카에 정상 발행되었는데 DB 장애로 outbox 삭제 처리가 안될 수도 있습니다.

중복 발행은 별도로 해결되어야 하는 문제입니다. 중복 발행 외에도 순서 변경에 대한 문제가 나타날 수 있는 것이고요.

해결 방법은 다양합니다.

컨슈머를 멱등하게 만들 수도 있고, 컨슈머에서 이벤트를 저장해뒀다가 충분히 다 왔을 시점에 다시 폴링해서 저리할 수도 있는 등..

반드시 1회만 처리를 보장하는 것은 쉬운 문제는 아니기 때문에, 다른 우회책 또는 정말 필요한지에 대해서도 고민해봐도 좋을 것 같습니다.

이전에도 다른 수강생 분이 유사한 질문을 주신 내역이 있어서 참고해보셔도 좋을 것 같네요!

https://inf.run/Q5ocT

https://inf.run/P8MvR

안녕하세요, 인프런 AI 인턴입니다. 자기개발하고싶어요님.

메시지 보내주신 그림을 보니, MessageRelay 시스템에서 Outbox 패턴을 사용하는 부분에 대해 동시성 이슈가 있을 수 있겠다는 고민이시군요. 이 시스템은 데이터 일관성을 보장하기 위해 Outbox 패턴과 함께 스케줄러를 사용하여 데이터베이스의 Outbox 테이블에 저장된 레코드를 읽어 Kafka로 전달하는 구조로 보입니다.

동시성 이슈 가능성에 대한 분석

1. TransactionListener와 DB 저장 시점

   • Transaction Listener에서 커밋 전에 데이터베이스 Outbox에 이벤트를 저장하게 됩니다. 만약 트랜잭션이 커밋되지 않은 상태에서 스케줄러가 해당 데이터를 읽기 시작한다면 문제가 발생할 수 있습니다.
     

2. 스케줄러 동작

   • 스케줄러가 데이터베이스의 Outbox를 주기적으로 조회하여 Kafka로 이벤트를 전송합니다. 이 시점에서 트랜잭션이 완료되지 않았거나, 이미 처리된 데이터를 중복 처리할 가능성이 존재할 수 있습니다.
     

3. 카프카 전송

   • 이러한 이벤트가 Kafka로 전송될 때 중복 전송될 수 있는 가능성이 존재한다면, 이는 일관성 문제를 초래할 수 있습니다.
     

해결 방안

• 트랜잭션 관리 철저

  • 트랜잭션 관리에 있어서 스케줄러가 데이터베이스를 조회하기 전 반드시 트랜잭션이 완료되었는지 확인하는 메커니즘을 도입할 수 있습니다.
    

• 데이터 상태 플래그 사용

  • Outbox 테이블에 ‘처리 상태’ 플래그를 두어, 처리 중이거나 이미 처리된 이벤트를 구분할 수 있도록 합니다.
    

• 스케줄러 컨캐런시 조정

  • 스케줄러의 주기 및 동시성 수준을 조절하여 이러한 문제를 최소화할 수 있습니다.
    

이러한 해결책을 통해 현재 시스템에서 발생할 수 있는 동시성 문제를 완화할 수 있을 것입니다. 관련하여 더 많은 정보와 예시는 다음의 게시글에서 참고하실 수 있습니다:

• Managing Concurrency in Outbox Pattern Systems
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.