[WIL] 카프카와 이벤트

🧠 이번 주에 새로 배운 것

• 카프카란 무엇일까?
  • 분산 메세지 스트리밍 플랫폼
  • 디스크에 Log를 지속적으로 Append
  • Consumer는 각자의 Offset을 통해 메세지를 읽음
• 카프카를 사용하는 이유?
  • 이벤트 물리적 저장 + 다른 사람과 주고받기 위함
  • 고가용성
    • 여러 브로커를 두어 브로커 장애 시에도 다른 브로커가 대체
      • 메세지가 들어올 때 분산 저장
        • 교체 시점의 부하가 줄어든다.
    • 파일 I/O 기반의 영속성
  • 확장성
    • 브로커, 파티션의 수평 확장으로 처리량 증가
  • 범용성
    • 메세징, 로그 수집, 이벤트 소싱 등 사용 가능
• 토픽은 하나의 터널, 파티션은 터널 내 차선으로 비유할 수 있다.
• Broker
  • 카프카 서버 단위
  • Producer의 메세지를 받아 Offset 지정 후 디스크에 저장
  • Consumer의 파티션 Read에 응답해 디스크의 메세지 전송
• Producer
  • 메세지를 특정 Topic에 생성
• Consumer
  • 1개 이상의 토픽을 구독하여 메세지를 순서대로 읽음
  • 메세지를 읽을 때마다 파티션 별로 offset을 유지해 읽는 메세지 위치 추적
• Reblancing
  • 특정 Consumer로부터 다른 Consumer로 파티션의 소유권 이전

💭 이런 고민이 있었어요

• Producer는 어떻게든 메세지를 발행해야 한다 = At Least Once
  • 트랜잭셔널 아웃박스 패턴 + CDC/스케쥴러 를 통한 보장
  • acks=all 을 통해 모든 브로커에게 ack를 받아야 발행되도록 한다.
• Consumer는 어떻게든 한 번만 처리해야 한다 = At Most Once
  • 이벤트에 대한 멱등 처리가 필요
  • 소비한 이벤트에 대한 정보를 관리한다 ⇒ DB/Redis
• 배치 리스너와 단건 리스너의 사용처
  • 단건 → 메세지 건 별로 에러 처리
  • 배치 리스너 → 한 건이 처리 불가능일 경우, 전체로 핸들링해야 함
  • 주문/결제 같은 케이스는 각 건에 대한 처리가 예민하므로 단건이 더 적합

🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것

• 하나의 도메인에 대해 다른 토픽으로 상태가 관리된다면, 일관성이 깨질 수 있다.
  • Consumer의 lag으로 인해 처리 순서가 달라질 경우, 마지막 상태를 보장할 수 없다.
• concurrency 옵션을 통해 병렬 처리 할 수 있는 케이스라면 적극 활용하자.
• Parallel Consumer를 사용하는 것과 concurrency를 통해 병렬 처리하는 것 각각 주의할 점 확인해보자.
• @JsonTypeInfo를 통해 특정 필드를 기준으로 Jackson 파싱을 고려해보자.