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

learnlearn님, 안녕하세요!

질문 주신 내용은 꼭 정답이 있다기 보단, 팀과 시스템에서 어떤 식으로 운영하고 싶은지에 따라서 정책을 달리할 수 있을 것 같습니다.

실무에서도 단순하게 삭제 방식을 취해도 되고, 발행 완료 상태로 업데이트 한다거나 별도의 테이블에 한동안 관리할 수도 있습니다.

어떠한 방법을 취하든 크게 상관은 없겠지만,

발행 완료된 이벤트에 대해서도 저장하고 있다면 추후 이벤트 추적 등에 유리한 측면은 분명 있습니다.

문제 상황 발생 시에 특정 기간 동안의 이벤트를 리플레이 할 수도 있고, 어떠한 이벤트가 언제 발행되었는지 추적해볼 수도 있습니다.(이러한 관점에 대해서는 이벤트 소싱이라는 개념이 있습니다.)

다만, 이러한 필요성이 딱히 안보인다면, 발행 완료 이벤트에 대해 직접 관리하고 별도 삭제 태스크도 만들어야하는 복잡성이 생기긴 합니다.

결국 삭제 여부나 주기도 팀과 시스템에서 정한 정책에 따라서 달리할 수 있는 것이고, 별도 배치나 스케줄러에서 수행될 수 있습니다.

안녕하세요, 인프런 AI 인턴입니다. learnlearn님.

Transactional Outbox 패턴은 데이터 일관성을 보장하면서 메시지 전송을 처리하기 위한 중요한 패턴입니다. 이에 대한 두 가지 질문에 대해 설명드리겠습니다.

첫 번째 질문: “Outbox 테이블에 Insert -> Kafka send 후 Outbox 상태 Update” VS “Delete”

강의에서 설명된 대로 Outbox 테이블에서 이벤트가 Kafka로 성공적으로 전송된 후 해당 레코드를 삭제하는 방식이 일반적입니다. 이 방법은 Outbox 테이블의 크기를 관리하기 쉽고, 처리된 이벤트가 Outbox에 더는 남아있지 않기 때문에 데이터 일관성을 유지하기에 용이합니다. 그러나 경우에 따라서 업데이트 방식을 사용할 수도 있습니다:

• 업데이트 방식 사용: 일부 시스템에서는 메시지가 성공적으로 전송된 경우 상태를 업데이트(예: SENT)하여 명확하게 구분하고 이를 기반으로 추가적인 로깅이나 모니터링을 수행하기도 합니다. 이 방식의 장점은 누가 언제 무엇을 처리했는지를 명확하게 추적할 수 있다는 점입니다.
  

두 번째 질문: 파티셔닝 및 주기적 삭제

Outbox 테이블이 시간이 지남에 따라 커질 경우, 관리가 필요합니다. 이를 위한 방법으로 파티셔닝과 주기적인 삭제를 사용할 수 있습니다.

• 파티셔닝: Outbox 테이블을 날짜 기반의 파티셔닝으로 구성하여 최신 데이터가 저장되는 파티션만 조회하거나 삭제 및 보관 처리가 가능합니다. 이렇게 하면 테이블의 성능에 미치는 영향을 최소화할 수 있습니다.

• 주기적인 삭제: Outbox 레코드가 일정 기간 동안 보관된 후 주기적으로 삭제되도록 스케줄링 작업(cron jobs)이 설정될 수 있습니다.

관련하여 추가적인 접근방식이나 설계 방법에 대해 궁금하신 점이 있다면 아래 유사한 질문 내용을 살펴보실 수 있습니다:

• Best Practices for Managing Outbox Tables in Large Scale Systems (게시글 제목)
  

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