[Consumer] 클릭 로그 이벤트 적재

[Mia-jeong]

1. 스펙

• DB

  • bulk insert
  • MongoDB

• 적재데이터 설계

2. 정책

1) row ttl (로그이벤트 적재 유효기간 기준 정하기)

• mongodb (https://www.mongodb.com/docs/manual/core/index-ttl/)
• 혹은 파티너셔닝 후 S3에 업데이트

3. 구현

1) 이벤트 컨슈밍

2) 중복 이벤트 확인

graph TD
    A[Consumer] --> |message duplication checker| B{중복 메시지 확인 통과}
    B -->|Yes| D[등록]
    B -->|No| F[실패]

• db에 message Id를 unique키로 건 후 중복 확인

[americanomin]

중복 체크하는 이유는 뭔가요? message id는 어떤 기준으로 만드나요?

토이 프로젝트이긴 하지만, 좀 요상한 절차인 것 같아서 어떤 아이디어였는지 궁금해요~

[Mia-jeong]

중복 체크하는 이유는 뭔가요? message id는 어떤 기준으로 만드나요?

토이 프로젝트이긴 하지만, 좀 요상한 절차인 것 같아서 어떤 아이디어였는지 궁금해요~

1) 중복체크 이유 카프카 특성상 중복메시지가 컨슈밍 될 수 있어서 데이터 정합성을 맞추기 위해 중복 컨슈밍 체크를 하려고 했습니다 : ) 이벤트 통신시 컨슈밍 쪽에서 가장 중요한건 중복메시지체크 여부라 생각해서요!

예를들어 SQS의 FIFO QUEUE와 같이 중복메시지 제거 기능이 카프카에는 없는걸로 알고있어 메시지 아이디를 Unique한 아이디로 인덱스를 걸어놓고 중복 메시지 체크하는 로직으로 처리해 보려고 했습니다. : )

로그 같은경우에도 모든 메시지를 컨슈밍하는것보다 중복메시지는 거르는게 좋을거라 생각햇는데 불필요한 설계 일까요? (궁금)

2) 메시지 아이디 메시지 아이디 같은 경우 SQS와 같이 고유 메세지 아이디를 제공하지 않는다면 보내는쪽에서 UUID로 보내야할 것 같아요!

[americanomin]

그러네여. 생각해보니 이벤트 발행할 때 랜덤키 만들어 넣는걸 깜빡했네여