카프카 잘 알고 사용하기 - 카프카 기본 개념과 구조

 

개요

MSA 프로젝트에서 kafka를 다양한 곳에 활용 했었다. 예를 들어 대규모 쿠폰 발급 처리에 Insert DB부하를 방지하기 위해 비동기 처리를 위해 사용 했었고, 채팅 서비스의 수평적 확장을 위해 메시지 브로커로 사용했었다.

 

지금 생각 해보면 잘못된 설계라는게 머리에 스쳐가기도 한다.

 

현재 쿠폰 발급 구조는 쿠폰 서비스에 이벤트를 발행하고 카프카에서 받아 다시 쿠폰 서비스에서 소비하는 구조(순환 호출 문제)

쿠폰 서비스 (이벤트 발행) --> Kafka --> 쿠폰 서비스 (이벤트 소비 후 DB insert)

물론 이벤트를 발행 후 사용자에게 바로 '발행완료' API 응답하고, DB insert작업은 비동기로 처리하므로 API 응답 시간이 빨라지고 트래픽 증가에 더 잘 대처할 수 있게 되었지만 쿠폰 서비스가 정말 커지게 되면 아래처럼 별도의 쿠폰 발급 처리 서비스가 있어야 하지 않을까라는 생각이 들기도 한다.

쿠폰 서비스 (이벤트 발행) --> Kafka --> 쿠폰 발급 처리 서비스 (DB insert)

 

또한 카프카의 브로커를 단일 브로커로 구성하여 카프카의 장점인 리플리케이션을 활용한 고가용성을 활용하지 못했다는 점도 있다. 과거의 실수를 반복하지 않고 잘 이해하고 사용하기 위해 카프카를 탐구해보기로 결심했다.

 

카프카 기초 다지기

리플리케이션

카프카에서 리플리케이션이란 각 메시지를 여러개로 복사해 카프카 클러스터 내 브로커들에게 분산시키는 것을 말한다. 이러한 리플리케이션 덕분에 하나의 브로커가 종료되도 다른 브로커로 대체 가능하게 된다.(고가용성)

peter-overview01이라는 토픽을 리플리케이션 팩터 수 3으로 설정하면 토픽이 원본 브로커 포함 총 3개가 생성된다.(토픽이 리플리케이션되는 것이 아니라 정확히는 토픽의 파티션이 리플리케이션 되는 것.)

 

만약 리더 브로커(1)가 다운되더라도 다른 팔로워 브로커(2)가 복제본을 가지고 있어 장애 복구가 가능한 것이다.

리플리케이션 팩터 수가 많으면 좋은가?

리플리케이션 팩터 수가 증가하면 팔로워 수가 증가한다. 팔로워 수가 많다고 딱히 좋은 것은 아니다. 팔로워 수만큼 결국 브로커의 디스크 공간도 소비되고, 복제하는 시간도 걸리기 때문이다. 권장 리플리케이션 팩터 수는 3개이다.

 

파티션

하나의 토픽이 한번에 처리할 수 있는 한계를 높이기 위해 토픽하나를 병렬 처리 가능하도록 하는 것이다.

위의 peter-overview01 토픽의 파티션을 3개 구성했다면 위처럼 파티션이 3개 생성 될 것이다. 이와 같은 파티셔닝을 통해 하나의 토픽이라도 높은 처리량을 수행할 수 있다.

 

예를 들어 peter-overview01 토픽이 파티션 1개가 있을 때 한개의 프로듀서가 1초에 30개의 메시지를 보내고, 브로커의 파티션은 1초에 10개 밖에 메시지를 받지 못한다면 20개의 메시지가 남게된다.

 

이 병목현상을 해결하기 위해서 파티션 개수를 3개로 늘리면 1초에 총 30개의 메시지를 처리할 수 있게 될 것이다.

 

적절한 파티션 수 계산 하는법

각 메시지의 크기나 초당 메시지 건수 등에 따라 달라지므로 정확하게 예측하기는 어렵다. 특히 파티션의 수는 늘릴 수는 있지만 절대 줄일 수는 없다. 따라서 초기에 파티션 수를 작게 2 또는 4로 생성하고 컨슈머의 LAG을 모니터링하면서 조금씩 늘려가는 것이 좋다.

LAG(랙)
프로듀서가 보낸 메시지 수(카프카에 남아있는 메시지 수) - 컨슈머가 가져간 메시지 수
ex) 프로듀서가 5개 메시지 전송, 컨슈머에서 4개 가져가면? LAG은 5 - 4 = 1이다.
ex) 컨슈머가 모든 메시지를 가져갔다면? LAG 5 - 5 = 1이다. 

 

세그먼트

프로듀서를 이용해 보낸 메시지는 토픽의 파티션에 저장된다. 각 메시지들은 세그먼트라는 로그 파일 형태로 브로커의 로컬 디스크에 저장된다. 각 파티션은 N개의 세그먼트 파일들이 존재한다.

 

지금까지 과정 정리

1. 프로듀서는 카프카의 peter-overview01 토픽으로 메시지를 전송
2. peter-overview01 토픽은 파티션이 하나면, 프로듀서로 받은 메시지를 파티션 0의 세그먼트 로그 파일에 저장
3. 브로커의 세그먼트 로그 파일에 저장된 메시지를 컨슈머가 읽음.