토픽과 파티션
적정 파티션 개수
- 데이터 처리량
- 메시지 키 사용 여부
- 브로커, 컨슈머 영향도
데이터 처리 속도를 올리는 방법
- 컨슈머의 처리량을 늘리는 법
컨슈머 서버 사양 스케일 업, GC 튜닝
- 파티션을 추가하고 컨슈머를 추가해서 병렬처리량을 늘리는 법
프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 * 파티션 개수
파티션을 늘리지 않고 컨슈머를 늘릴 경우
idle or block
대안방법
- poll 메서드의 타임아웃 설정
- idle 한 상태가 포착되면 해당 컨슈머는 다른 반복적인 수행을 하면서 대기
- 컨슈머 인스턴스를 확장하기보다는 별도의 스레드를 통해서 수행
1개 파티션 = 1개 컨슈머
- 병렬처리와 확장성 -> 각 파티션은 별도의 스트림
- 가용성과 내결함성 - > 장애 발생 시 데이터 손실 방지, 오프셋 관리
- 이벤트 순서 보장
메시키 사용 여부
데이터 처리 순서 연관
토픽 정리 정책
cleanup.policy
토픽의 데이터는 시간 또는 용량에 따라 삭제 규칙을 적용할 수 있다.
데이터가 삭제되지 않고 남았으면 오프셋에 따라 지난 데이터를 가져올 수 있다.
cleanup.policy 옵션은 2가지 삭제 정책을 제공한다.
1. delete 데이터의 완전 삭제
2. compact 동일 메시지 키의 가장 오래된 데이터 삭제
토픽 삭제 정책
토픽의 데이터를 삭제할 때는 세그먼트 단위로 삭제를 진행.
세그먼트는 여러 조각으로 나뉘는데 semgnet.bytes 옵션으로 1개의 세그먼트 크기를 설정할 수 있다. segment.bytes 크기보다 커질 경우에는 기존에 적재하던 세그먼트 파일을 닫고 새로운 세그먼트를 열어서 데이터를 저장.
액티브 세그먼트 : 데이터를 저장하기 위해 사용중인 세그먼트
retention.ms : 토픽의 데이터를 유지하는 기간
retention.bytes: 토픽의 최대 데이터 크기 제어
토픽 압축 정책
메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
min.cleanable.dirty.ratio: 데이터의 압축 시작 지점 (비율)
액티브 세그먼트를 제외한 세그먼트에 남아 있는 데이터의 tail 영역의 레코드 개수, head영역의 레코드 개수의 비율
clean log : tail 영역의 레코드들. 압축이 완료되어 중복된 메시지 키가 없다.
dirty log : head 영역의 레코드. 중복된 메시지 키를 가진 레코드들이 있다.
dirty ratio : 더티 영역의 메시지 개수 / 압축 대상 세그먼트에 남아있는 데이터의 총 레코드 수(dirty + clean)
ISR
리더 파티션과 팔로워 파티션이 모두 싱크된 상태.
팔로워 파티션이 리더 파티션으로부터 데이터를 복제하는 데에 시간이 걸린다.
replica.lag.time.max.ms: 팔로워 파티션이 데이터를 복제하는지 확인하는 주기.
ISR 그룹게서 제외한다. -> 리더 파티션 후보 그룹
unclean.leader.election.enable
ISR 그룹이 아닌 파티션을 선출하게 할 것인지에 대한 옵션값.
카프카 프로듀서
acks 옵션
acks : 0, 1, all
복제 개수 1 : acks 옵션에 따른 성능 변화 없음.
acks : 0
프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다.
데이터 전송 실패 유무를 확인하지 않는다. -> 굉장히 빠르다.
acks : 1
데이터가 리더 파티션에만 정상적으로 적재되었는지 확인한다.
min.insync.replicas 를 설정할 때는 복제 개수도 함께 고려
브로커의 개수 > min.insync.replicas
멱등성 프로듀서
트랜잭션 프로듀서
다수의 데이터를 동일 트랜잭션으로 묶어 전체 데이터를 처리하거나 전체 데이터를 처리하지 않도록 한다.
enable.idempotence : true
transactional.id : random String
isloation.level : read_committed
프로듀서와 컨슈머는 트랜잭션으로 처리 완료된 데이터만 쓰고 읽게 된다.
트랜잭션의 시작과 끝을 표현하기 위해 트랜잭션 레코드를 한 개 더 보낸다.
레코드의 특성은 가지고 있어서 파티션에 저장되어 오프셋을 한 개 차지한다.
카프카 컨슈머
멀티 스레드 컨슈머
카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있다.
파티션을 여러 개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 파티션 개수를 동일하게 맞추는 것.
카프카 컨슈머 멀티 워커 스레드 전략
브로커로부터 전달받은 레코드들을 병렬로 처리한다면 1개의 컨슈머 스레드로 받은 데이터들을 더욱 향상된 속도로 처리할 수 있다.
ExecutorService 자바 라이브러리를 사용하면 레코드를 병렬처리하는 스레드를 효율적으로 생성하고 관리할 수 있다.
주의사항
- 스레드를 사용하기 때문에 데이터 처리가 끝나지 않았음에도 불구하고 커밋을 하기 때문에 리밸런싱, 컨슈머 장애 시에 데이터 유실이 발생
- 레코드 처리의 역전현상.
카프카 컨슈머 멀티 스레드 전략
하나의 파티션은 동일 컨슈머 중 최대 1개까지 할당된다.
컨슈머 스레드를 늘려 각 스레드 각 파티션을 할당한다.
컨슈머 랙
토픽의 최신 오프셋과 컨슈머 오프셋 간의 차이.
컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성.
bin/kafka-consumer-groups.sh --bootstrap-server kafka:9092 --group
my-group --describe