🧠 이번 주에 새로 배운 것
- 카프카의 정의를 새롭게 배웠습니다. 단순 고성능 메시지 큐가 아닌 분산 로그 저장소 이며, 로그가 쌓이는 거대한 시스템에 가깝습니다.
- 카프카 컴포넌트 구성 요소를 학습하였습니다. 컨슈머 그룹과 파티션의 관계, 리밸런싱, 카프카 렉 등 새로운 용어들을 알게 되었습니다. 이론적 학습 단계라 아직은 와닿지 않지만, 꾸준히 학습해가며 내것으로 체화시켜야 겠습니다.
- 카프카의 핵심은 메시지를 잃지 않고 단 한번만 처리되게 보장하는 것입니다. producer는 최소 1번의 메시지 발행을, consumer는 정확히 한번만 처리하는 책임을 가지고 있습니다.
- 실무에서 카프카 도입이 트래픽과는 크게 연관이 없다는 것입니다. 중요한건 기능 동작과 팀원의 숙련도 입니다. '장시간 실행되는 복잡한 작업', '팀원의 카프카 숙련도가 떨어지는 경우는 카프카를 사용하기엔 이르지 않나 싶습니다.
💭 이런 고민이 있었어요
- 카프카 발행하는 ecommerce-api에서 스케줄러 가동시 동시성 문제 예방을 위해 shedlock을 적용해야 할까 고민하였습니다. 이벤트 발행 속도를 높이기 위한 방안으로 인스턴스를 늘려야 하나? 고민에서 출발하였습니다. 이번 과제에서 구현하진 않았지만 단일 인스턴스에 병렬 스레드를 적용해서 처리량을 높이는게 간단하다고 생각하였습니다.
- 토픽을 이벤트 별로 상세하게 분리할까 고민을 하였습니다. consumer에서 이벤트를 받아서 필터링 하는 책임은 불필요하다고 판단했했습니다. 또한, '특정 이벤트만 급증'하는 경우가 충분히 있을 수 있기에 이벤트를 '주문 완료', '주문 취소', '좋아요 등록', '좋아요 취소'와 같이 분리하였습니다.
💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트
- 현재 회사에서 카프카가 아닌 gcp pub/sub 모델을 사용하고 있습니다. 카프카는 아니지만 전반적인 메시지 큐 개념은 비슷하여 카프카의 핵심 원칙인 '메시지를 잃지 않고 단 한번만 처리되게 보장하는 것'를 보장할 수 있도록 리팩터링할 예정입니다.
🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것
- consumer에서 DLQ를 구현하지 못했습니다. 실패를 어떻게 처리할 건지 좀더 고민이 필요할 것 같습니다.