부족한 개연성
7주 차의 주제는 롱 트랜잭션으로 이뤄진 비즈니스 로직에서 핵심 로직과 부가 로직을 구분하는 것이었다. 여기서 경계를 나누는데 사용된 구체적인 방법은 비동기식 이벤트였다. 이벤트는 하나의 JVM내에서 사용될 수 있는 스프링 이벤트였고, 8주차에서는 여러 서버들이 이벤트를 소비할 수 있는 구조로 확장하는게 목적이 아니였을까?
과제를 본격적으로 시작한건 수요일 저녁쯤이었다. 카프카를 사용 해야한다는 동기부여가 부족했기 때문이다. 시스템적으로 카프카를 적용할 필요도 없이 잘 동작할 수 있는 구조였으며, 요구사항도 단순했다. 오버엔지니어링이 아닌가 싶기도 했지만, 학습 목적이기 때문에 도입을 하게되었다.
솔직히 7주차에서 8주차로 넘어가는 방식이 자연스럽지 않았다. 비유하자면 개연성이 부족한 드라마나 소설이었다. 이벤트를 사용해야하는 이유를 이해했지만 그게 카프카로 이어질 필요가 있을까? 카프카를 도입함으로써 시스템의 복잡도가 높아졌다고 느껴졌는데, 커맨드 처럼 그것을 소비하는 대상과 발행 주체가 명확히 정해져있지 않아서 복잡하다고 느낀것 같다. 형용사로 표현하자면 카프카로 부터 모호함이 시스템에 도입되었다고 표현할 수 있을것 같다. 모호하고 불분명하다.
카프카가 JD에 나와있다고 사용해보는것 보다, 이 기술을 사용해서 효과적으로 우리가 정의한 비즈니스 문제를 해결할 수 있어? 라고 물어봐야할것인지. 아니면 우리의 비즈니스 문제를 무엇으로 해결할 수 있어? 를 답하면서 나오는 수많은 시도와 해결책으로 부터 상대적으로 더 나은 수단과 아키텍처로 나아가는게 중요할지 앞으로 기준을 세워봐야겠다.
학습한 내용들
카프카를 직접 설정하고 프로듀서에서 메시지를 발행하는 방법, 리스너에서 메시지를 받는 방법에 대해 고민을 할 수 있었다. 방법적인 내용을 시도해보는것은 쉽지 않았다. 그저 설정일뿐이기 때문이다. 8주차에서 중요하다고 느낀 키워드들은 다음과 같다 :
- At Most Once / At Least Once / Exactly Once
- Idempotency
"정확히 한 번(Exactly Once)를 시스템에서 보장하기 위한 구현 난이도는 매우 높다" 를 알 수 있었다. 이를 위해 적절하게 타협한 방법은 At Most Once와 At Least Once이다. 이벤트를 발행하는 쪽은 적어도 한 번을 보장하면 어쨌거나 발행은 시킬 수 있다. 적어도 한 번을 보장한 대가는 "중복"문제이고, 받는쪽에서 최대 한 번(At Most Once)를 보장하기 위해 멱등성을 고려한 해결책을 찾아야 한다. 실제로 회사에서 고민했던 문제들을 다음 아티클에서 다뤘는데 시간이 지나고 다시 읽었을때 부족함이 많은 글이었구나 하는 생각을 갖을 수 있으면 좋을것 같다.
e-HR SaaS 에서 이벤트 활용 아이디어 - Polling Adapater + Event
카프카가 정말 필요한 상황은 언제 인지를 아직은 판단할 수 없다. 내가 생각해왔던것과 다르게 아래와 같은 관점에서 사용될 수 있음을 알았기 때문이다 :
- 감사 로그 (Audit Log)
- 집계 (Metrics) : 일/월/년 집계 처리
- 캐싱 무효화
특히나 집계처리에 효과적으로 사용될 수 있다는 점이 우리 시스템에서 근태 집계, 휴가 집계 처리할때 겪는 비즈니스 문제들을 좀더 편하게 처리할 수 없을까? 하는 궁금증을 갖게 만들었다.
멘토링 피드백
- 멱등 처리 구현 및 테스트
- version, updated_at을 기준으로 최신 이벤트만 반영한다는 것은 무슨 의미인지?
- distinct 처리하라는 의미
- event 형태에 event_id, occured_at과 같은 필드가 있어야 할듯
- 같은 윈도우 내에서 중복제거하는 로직이 필요
- 이 로직을 컴포넌트, 함수로 분리했다면 유닛 테스트만으로 충분
- 컨슈머 로직은 당연히 멱등하게 작성해서 결제완료 메시지가 두건이 동시에 오는 경우 재처리 되지 않도록 한다
- version, updated_at을 기준으로 최신 이벤트만 반영한다는 것은 무슨 의미인지?
- 배치, 단건 처리 방법
- 보통 배치 리스너로 컨슈머가 처리한다.
- 모니터링은 보통 kafka-ui를 사용 중
- 실시간 담기는 메시지와 lag등 모니터링 할 수 있다
- 컨슈머 역할을 하고 있다면 컨슈머 그룹 모니털잉 주요 포인트
- 프로듀서라면 브로커 컨디션(cpu, disk, memory)을 중요하게 봄
- 보통 카프카 클러스터는 회사당 1개로 많이 운영
- 규모가 커지면 클러스터 분리를 진행하는 느낌 (aws msk)
- bytearrayserializer같은 것을 쓰면 listner에서 깔끔하게 처리 가능
- 근태 기록시 출퇴근 입력이 exactly once가 중요하면 이벤트 방식보다는 atomic하게 처리하는 것이 좋을 수도
다음 주에 고민할 점들
- 레디스의 ZSet 자료구조를 이용한 랭킹 문제를 해결하기
- 적절한 키 설계를 통해 집계를 효율적으로 다뤄보기
- 집계 윈도우 시점의 콜드 스타트 문제를 어떻게 해결할 수 있을 고민하기
분명 집계라는 단어는 e-HR에서도 휴가집계, 근태집계 처럼 사용 중인데 내부적으로 구현된 방법은 너무나 다르다. 때로는 단순하고 오래 살아남은 방법이 가장 좋은 해결책이라는것을 최근들어 느끼고 있다.
레퍼런스
- What is Apache Kafka? | Tim Berglund (2023, The ASF)
