강의

멘토링

로드맵

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

hack4569님의 프로필 이미지
hack4569

작성한 질문수

스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판

CQRS의 필요성

consumer에서 에러가 발생할 경우 데이터 유실 문의

해결된 질문

작성

·

22

0

안녕하세요. kafka 관련해서 질문이 있습니다.
MessageRelay > publishEvent 에서 outbox를 삭제했는데 consumer에서 에러가 발생하면 데이터가 유실되는게 아닌가요?

퀴즈

게시판 서비스처럼 읽기 트래픽이 쓰기 트래픽보다 훨씬 높은 마이크로서비스 환경에서 CQRS 도입의 필요성이 제기되는 주된 이유 중 하나는 무엇일까요?

쓰기 서비스의 데이터 무결성을 강화하기 위해

쓰기 서비스에 집중된 부하를 분산하고 자원 낭비를 줄이기 위해

데이터 동기화 없이도 즉각적인 일관성을 보장하기 위해

마이크로서비스 간 순환 의존성을 의도적으로 만들기 위해

답변 2

0

쿠케님의 프로필 이미지
쿠케
지식공유자

hack4569님, 안녕하세요!

 

outbox 패턴은 producer의 유실을 방지하기 위한 방법입니다.

producer의 비즈니스 로직 변경과 이벤트 발행을 하나의 트랜잭션으로 묶기 위한 것이고,

consumer의 유실 방지는 별도로 챙겨져야 합니다!

이러한 부분은 consumer가 레코드에 대한 작업이 완전히 처리된 이후에 커밋하는 전략, 실패 시에 재처리 토픽에 다시 담는 전략 등을 겸할 수 있을 것 같습니다.

0

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

Kafka와 outbox 패턴 관련 질문을 주신 것 같습니다. 메시지 발행 후 Consumer에서 에러가 발생했을 때, 데이터 유실에 대한 우려가 있을 수 있습니다. 이는 Outbox 패턴에서 발생할 수 있는 중요한 문제 중 하나입니다.

해결책 및 고려사항:

  1. 오프셋 관리:

    • Consumer는 Kafka로부터 메시지를 처리한 후, 처리 완료 여부를 오프셋으로 관리합니다. 만약 에러가 발생하면 오프셋이 커밋되지 않도록 처리하여, 재시작 혹은 재처리 시 다시 동일 메시지를 수신할 수 있도록 합니다.
  2. Dead Letter Queue (DLQ):

    • 실패한 메시지를 별도의 Dead Letter Queue로 보내는 방식을 고려해볼 수 있습니다. 이는 특정 메시지가 여러 차례 실패할 경우 해당 메시지를 추적하고 나중에 별도 처리를 가능하게 해줍니다.
  3. 재처리 메커니즘:

    • Outbox에서 데이터를 삭제하기 전에, 반대작업(복구 또는 재처리)을 위한 로그를 남기거나 별도의 백업 시스템을 통해 트랜잭션 로그를 남길 수 있습니다.
  4. 확실한 전송 보장:

    • Kafka의 At-Least-Once 전송 보장 설정을 통해 메시지가 최소한 한 번은 Consumer에게 전달되도록 옵션을 설정할 수 있습니다. 이 경우 재전송은 가능하지만, 중복 처리가 될 위험이 있습니다.
  5. 모니터링 및 알람:

    • 오류 발생 시 즉시 대응할 수 있도록 모니터링 시스템 및 알람 체계를 구축하여 Consumer의 에러를 감지하고 손쉽게 디버깅 및 복구하는 것이 좋습니다.

이와 관련하여 추가적인 정보를 확인하시려면, 관련된 링크나 유사한 질문의 답변을 검토해보는 것도 좋습니다:

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

hack4569님의 프로필 이미지
hack4569

작성한 질문수

질문하기