2024 KAFKA KRUG 밋업
Last updated
Last updated
11월 21일에 열린 KRU 밋업에 참석했다! 목적성은 두개였다.
첫번째, Peter님께 다음 스터디는 언제 열리는지 여쭤보려고 했구, 두번째는 방대한 Kafka 자료들을 가지고 있는 KRU에서 실무적인 활용도를 어떻게 끌어올리시고 계신지 이해해보려고 했다.
Kafka를 사용하고 있지만 오래 사용해보신 분들의 관점으로부터 역시나 배울 점들이 많았다. 이번 밋업도 참가하길 정말 잘한 판단이었다고 생각한다. 수년간 Kafka 로 안정적인 서비스를 운영하시면서 장애와 사고들이 많으셨을텐데 발표들에 잘 녹아있었다.
이번에 발표해주신 분들과 장소를 마련해주신 KRU들께 진심으로 감사한 마음을 먼저 전합니다.
동현님의 발표의 구조는 다음과 같았다.
서비스 아키텍처를 천천히 개선해온 논리적 배경 설명해주셨다.
V1에서는도메인 모델을 이용한 개발 [1]
V2 에서는 CQRS 로 읽기에 대한 성능 최적화 [2]
또, CQRS 로 쓰기의 동작 분리로 독립적인 확장구조 확보
CQRS에 대한 실행과 시행착오들을 겪으신 부분들을 정리해주셨다.
장점
보안적 사항 개선
복잡한 비즈니스 로직 구현 수월해짐
성능 최적화
독립적 확장성
병렬 처리
보안성 강화
단점
코드안에서만 구현해서 강제성이 없음
코드량 증가
결과적 일관성 문제
동기화 문제
복잡성 향상
WRITE 에는 HBase, READ에는 MongoDB를 사용하게된 기술적 배경 설명을 해주셨다. [3]
MongoDB를 READ DB로 사용하면서 바로 읽어서 사용할 수 있는 구조
여기서 중요한 점은 '쓰기는읽기에 최적한 상태로 저장하는것'이고 '읽기는 응답을 만들기 위해 조작하는 것'을 줄여야한다.
단점
WriteDB 에서 ReadDB로 싱크 맞추는데 시간이 걸리므로 정합성 이슈
아키텍처 복잡성 상승으로 유지보수 비용은 증가
개선사항
READ에 대한 SCHEDULED CACHING으로 읽기 성능 개선
높은 TPS를 감당할 수 있었다.
마지막으로, MongoDB 샤딩을 이야기하셨는데, 우리팀에서도 MongoDB 샤딩 전략이 실패해서, 롤백했던 경험이 있다. MongoDB는 실제로 운영하면서 배울 점이 많아보인다.
이후, 이벤트 소싱에 대한 기술적 설명과 성능적 고민에 대한 결과를 공유해주셨다.
쓰기에서 이벤트로 발행시켜서 빠르게 처리하도록 하고 응답시간을 축소하기 위함
이벤트 리플레이로 최종적 정합성 구현 가능하다.
WRITE시 MQ를 타고 WRITE DB에 저장하고 SCHEDULED PULL로 READ DB와 캐시에 저장
사담으로는, 정합성이 굉장히 중요한 구조에서는 Event Sourcing이 적합한지 의문이라고 하신다.
카카오의 피드형 서비스, SKT의 피드형 서비스 아키텍처 설명(적용사례)
여러개의 Push Agents 들이 있을때, 정보를 어떤 방식으로 Aggregate하셨는지 설명
읽기 최적화
읽기는 최대한 정제할 필요없는 형태로 저장 + 캐싱
쓰기 최적화
쓰기시에 정규화시에 쓰기가 엄청 쌓인 적도 있었다.
이 때문에 빠르게 이벤트만 발행시키고 컨슈머로 처리하려고 했다.
쓰기에서도 데이터 조작이 최대한 적게끔 처리도 했다.
회사에서도 유사한 구조를 가지고 있어서, 이번 년도가 지나면 scheduled caching 처리는 도입해보고싶다.
갔더니 토비님이 계셨다. 스프링과 친한 카프카에 대해서 어떤 부분들이 장점이 되는지 설명하셨었고 토비님의 견해를 들을 수 있는 시간이었다.
Jvm을 공유하는 scala, kotlin, java 와 같은 환경들과 Spring이 국제 개발시장에서는 어떤 포지션을 가지고 있고 Spring AI 같은앞으로의 진화 방향도 공유를 해주셨다.
정욱님의 발표는 카프카의 리더 선출과정에 대한 이야기 였는데 preferred leader와 replication 순서에 따라 리더 선출 과정을 직접 시각화 툴인 Felice 라는 도구를 사용해서 보여주셨다.
일차적으로, 토픽, 파티션, 리더 파티션과 리더 파티션 밸런싱으로 Kafka 리밸런싱때 어떤 리더가 선출되는지 보여주셨다.
토픽은 논리적 단위이고, 여러개의 파티션으로 구성된다고 하셨다.
파티션 복제해서 다른 브로커에도 복제본을 생성한다고 하셨고, 이 때 설정값이 replication factor 이였다.
리더 파티션은 write 와 read를 직접하는 파티션이라고 하셨다.
하나의 브로커에 리더 파티션들이 몰리게되면, 대부분의 부하가 몰리게 된다.
이 때문에, 카프카 클러스터가 리더의 분포를 감지하고 리밸런싱해주게 된다.
여기서 주의할 점은 Preferred Leader 는 토픽 구성에서 replica 목록에서 첫번째 브로커 복제본으로 선정되고, 선호하는 리더를 변경하지않아서, 리밸런싱때 알맞게 변경이 되지 않는다.
발표 과정에 있어서 직접 눈으로 트래픽을 보여주시고 설정을 보여주시면서 Traffic based Kafka Rebalancing을 할 수 있는 기능을 보여주셨다.
카프카의 리더 선출과정에 대한 메커니즘을 이해할 수 있었고 짧게 재선출시 생기는 리더 공백에 대한 생각을 나눠주셨다.
이런 옵션들로, 트래픽 기반으로 배치할 수 있게 동적으로 설정할 수 있다고 하셨다.
카프카는 사용할 때, 옵션값들이 많고 시각적으로 보여지는 정보가 모니터링 정보 밖에 없어서 이런 옵션값들이 눈에 잘 들어오지 않는다.
'Felice for Apache Kafka' 라는 제품을 통해서 어떤 메트릭이 있는지 경험해보는것도 좋을것같다.
추가적인 질문들이 이런 식으로 생겼다.
리더 공백에 대해서는 다른 시스템에서는 어떻게 처리하는지?
Traffic Throttling으로 리밸런싱동안 대역폭 제한하는 기능이 있다.
클라이언트 쪽에서 backoff 전략을 사용하고 리밸런싱 동안 잠시 Producing을 멈추는 방법도 있어보인다.
카프카가 Network 대역폭을 어떻게 사용하고 DISK I/O를 어떻게 소모하는지
kafka에서 메시지가 오고 page cache 에 저장하고 consumer에서 page cache에서 읽으려고 하다가 없으면 disk에서 읽어온다
log.flush.interval.messages, ms 라는 옵션이 있다.
동현님의 생각 흐름들을 들으면서, 앞으로 거쳐가게될 기술적 의사결정에서 도움을 많았다.
Message Queue 와 Event Sourcing을 사용할 때 고려할 부분들과 성능 최적화를 할 수 있는 포인트들을 얻을 수 있었다.
정욱님의 발표를 들으면서, 어렵게만 느껴지던 리더 선출과정을 쉽게 이해 할 수 있었다.
항상 책으로 읽는것 보다는 도전하시면서 장애를 겪으신분들로부터 많이 배우는 것 같다.
나도 이런 분들과 같은 경험을 꼭 해보고 싶지만, 단단히 기초부터 다지고 도전해봐야겠다.
KRU는 이런 귀중한 경험들을 공유해주시는 장으로 값진 경험을 전달해주는 모임이었다.
