4장 카프카 상세 개념 설명

들어가면서

카프카 프로듀서와 컨슈머를 똑똑하게 사용하기 위한 팁들과 매커니즘을 공부하고 정리한 글입니다.
책에서 중요하게 생각한 내용을 정리한 내용이고 자세한 내용은 도서를 참고해주세요!!

토픽 운영시 고려사항

1. 적정 파티션 개수

토픽의 파티션의 개수는 성능과 연관이 깊다. 그래서 적절한 파티션의 개수를 설정하는 것이 중요하다.

토픽 생성 시 파티션 개수 고려사항

• 데이터 처리량
• 메시지 키 사용 여부
• 브로커, 컨슈머 영향도

데이터 처리량을 고려한 파티션 개수

파티션의 개수를 정할 때는 데이터의 처리량이 얼마나 많은지에 따라서 결정해야한다.
파티션의 개수가 많을 수록 병렬적으로 처리할 컨슈머를 사용할 수 있기 때문이다.

프로듀서의 처리량이 컨슈머의 처리량과 파티션의 수를 곱한 것 보다 작게 해야 데이터 처리가 밀리지 않는다.

메시지 키 사용 여부

메시지 키 사용 여부가 중요한 것은 데이터의 순서가 중요한 경우이다. 같은 키를 가진 레코드는 동일한 파티션에서 처리된다.
하지만 운영 중간에 파티션을 증가시키면 같은 키를 가진 레코드가 다른 파티션으로 배정이 될 가능성이 있다.
이는 순간적으로 데이터의 순서를 보장하지 못해서 의도한 대로 동작하지 않을 가능성이 있다.

따라서 순서가 중요한 데이터 스트림에는 파티션의 개수를 변경을 고려하여 넉넉하게 파티션을 배정해야한다.
그것이 아니라면 증가되는 파티션 수의 변화에도 파티션 전략이 순서를 보장하도록 커스텀 파티션을 개발해야한다.

브로커, 컨슈머 영향도

파티션은 브로커 서버의 파일 시스템을 사용한다. 파티션이 늘어나면 관리하는 파일의 수가 늘어난다.
그런데 운영체제에서는 하나의 프로세스가 열 수 있는 파일의 최대 개수를 제한한다.
따라서 무조건적으로 파티션을 증가시키면 오류가 발생할 가능성이 있다.
파티션을 늘리기 전에 브로커의 자원이 충분한지 확인하고 확장해야한다. 부족하면 브로커를 추가 설치해야하기 때문이다.

2. 토픽 정리 정책 - cleanup.policy

토픽의 데이터를 정리하지 않으면 데이터가 시간에 비례해서 계속해서 쌓인다.
스토리지를 효과적으로 사용하기 위해서는 계속 쌓기만 하는 것은 비효율적이다.
스토리지의 공간을 효율적으로 사용하기 위해서 토픽 정리 정책을 적용할 수 있다.

세그먼트 : 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위로 크기는 설정된 값을 따른다.

엑티브 세그먼트 : 데이터를 저장하기 위해 사용 중인 세그먼트

토픽 삭제 정책

cleanup.policy=delete

특정 임계점에 이르면 파일을 삭제하는 정책이다.
데이터를 저장하는 기간을 설정(retention.ms)하여 그 기간이 넘어가면 삭제하거나
데이터의 최대 크기(retention.bytes)를 제한하여 초과하면 삭제하거나 하는 식으로 사용할 수 있다.

토픽 압축 정책

cleanup.policy=compact

데이터를 압축해서 저장하는 것이 아니다.
메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책이다.
삭제하는 대상은 엑티브 세그먼트를 제외한 나머지 세그먼트들이다.

압축하는 주기는 min.cleanable.dirty.ratio 옵션 값에 따른다.
이 옵션은 더티 비율을 나타내는 것인데 더티 비율은 클린 레코드 수 / (클린 레코드 수 + 더티 레코드 수) 로 계산된다.
클린 레코드는 이미 압축된 레코드를 말하고 더티 레코드는 아직 한번도 압축이 되지 않은 레코드를 말한다.

KTable 구조로 사용되는 데이터 스트림에 적합한 정책이다.

3. ISR (In-Sync-Replicas)

ISR : 리더 파티션과 팔로워 파티션이 모두 동기화된 상태

리더 파티션에서는 팔로우 파티션은 replicas.lag.time.max.ms 설정 값의 주기로 확인하여 데이터가 복제되었는지 확인한다.
이 때 팔로우 파티션에서 데이터를 복제하지 않으면 ISR 그룹에서 제외시킨다.

만약 데이터 유실이 발생하더라도 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶다면 ISR이 아닌 팔로우 파티션을 리더로 선출이 가능한다.
그때, unclean.leader.election.enable옵션을 true로 설정하면 된다.

프로듀서 옵션과 활용

1. acks 옵션

1. acks=0

• 프로듀서가 리더 파티션으로 데이터를 전송하였을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 것
• 가장 빠른 성능
• 가장 높은 데이터 유실 가능성

2. acks=1

• 리더 파티션에 정상적으로 적재되었는지 확인하는 옵션
• 중간 성능
• 적재된 파티션의 브로커의 장애로 인한 데이터 유실 가능성

3. acks=all or -1

• 리더 파티션과 팔로워 파티션에 모두 정상적으로 적재되었는지 확인하는 옵션
• 가장 안전한 옵션
• 느린 성능
• min.insync.replicas

프로듀서가 리더 파티션에 데이터가 적재되었는지 확인하기 위한 최소 ISR그룹의 파티션 개수 설정
2이상으로 설정해야 의미가 있다.
카프카의 고가용성을 위해서 절대로 브로커 개수와 동일한 숫자로 설정하면 안된다.

 

2. 멱등성 프로듀서 (idempotence)

동일한 데이터를 여러 번 전송하더라도 카프카 클러스터에 단 한 번만 저장됨을 보장하는 프로듀서이다.
enable.idempotence 옵션(default:false)을 true로 설정하여 정확히 한번 전달(exactly once delivery)을 지원한다.

3. 트랜잭션 프로듀서 (transaction)

다수의 파티션에 데이터를 저장할 경우 모든 데이터에 대해 동일한 원자성을 만족시키기 위해서 사용된다.
enable.idempotence를 true로 설정하고 transaction.id를 임의의 String 값으로 정의하면 된다.
트랜잭션 프로듀서를 사용하면 원자성을 보장하기 위해서 데이터를 전송한 후에는 트랜잭션 레코드를 전송하여 트랜잭션의 끝을 알린다.

컨슈머 처리량 전략

컨슈머의 처리량을 늘리는 방법은 두가지가 있다. 하나는 파티션의 개수를 늘려서 컨슈머의 수를 병렬적으로 늘리는 것이고
다른 하나는 컨슈머의 처리 프로세스(쓰레드)를 늘려서 성능을 높이는 방식이다.

1. 다중 쓰레드를 통한 처리량 증가 전략(멀티 워커 쓰레드 전략)

하나의 파티션에 데이터를 가져올 수 있는 기능을 수행하는 쓰레드는 하나밖에 수행할 수 없기 때문에 그냥 쓰레드를 여러개 할당하는 것은 안된다.
데이터를 가져오는 부분은 하나의 쓰레드가 담당하고 이를 처리하는 처리기능을 다중 쓰레드로 분산시켜서 처리량을 늘리는 것이 가능하다.
하지만 이 방법은 비동기적으로 처리되어서 데이터의 중복 및 유실의 가능성이 있음을 유의해야한다.
또한 순서가 중요한 데이터 스트림에서는 순서를 보장하지 않기 때문에 이 전략을 지양해야한다.

2. 병렬적 확장을 통한 처리량 증가

하나의 파티션에 하나의 컨슈머를 할당하여 파티션의 개수 만큼 컨슈머를 수평적으로 확장할 수 있다.
그래서 확장을 위해서 이 최대치까지 컨슈머 프로세스(쓰레드)를 증가시켜서 처리량을 증가시키는 전략이다.

컨슈머 랙(LAG)

컨슈머 랙은 토픽의 최신 오프셋과 컨슈머 오프셋간의 차이이다.
컨슈머의 동작상태를 나타내는 지표이기 때문에 모니터링이 요구되는 지표이기도 하다.

랙은 컨슈머의 데이터 처리가 프로듀서의 처리량보다 적으면 증가하고 그 차이가 클 수록 빠르게 증가한다.
이 차이와 추세를 통해서 컨슈머의 장애를 파악하고 처리량을 늘려야하는지를 판단할 수 있다.

모니터링 방법

1. 카프카 명령어 (shell script)
   일회성이고 상태를 추적하기 어려워서 테스트용으로 적합

ex)

./kafka-consumer-groups.sh --bootstrap-server kafka_ip:9092 --group group-name --describe

2. 컨슈머 어플리케이션 metric() 메서드
   컨슈머의 상태에 의존적이기 때문에 컨슈머의 장애가 모니터링 시스템으로 전파됨
   모든 컨슈머 애플리케이션에 모니터링 로직을 중복해서 작성해야함.
   카프카의 서드 파티 애플리케이션에는 적용할 수 없는 한계가 있음
3. 외부 모니터링 툴 (버로우)

사실상 권장하는 방법으로 앞선 방법의 단점을 해소할 수 있는 방법

Reference

도서 : 아파치 카프카 애플리케이션 프로그래밍 with 자바