프로그래밍 해볼까

컨슈머가 poll() 을 호출할 때마다 컨슈머 그룹은 카프카에서 저장되어 있는 읽지 않은 메시지를 가져옴 컨슈머 그룹의 컨슈머들은 가각의 파티션에 자신이 가져간 메시지의 위치 정보(offset) 을 기록 각 파티션에 대해 현재 위치를 업데이트 하는 동작을 commit 각 컨슈머 그룹별로 offset 정보를 저장하기 위한 저장소 별도로 사용 0.9 이전 버전은 zookeeper 에 저장 이후 버전은 카프카 내에 별도의 토픽을 만들어서 저장 → __consumer_offsets 컨슈머가 갑자기 다운 또는 새로운 컨슈머가 조인한다면 → 컨슈머 그룹 내에서 rebalance 발생 리벨런스 후 각각의 컨슈머는 이전에 처리했던 토픽의 파티션이 아닌 다른 새로운 파티션에 할당 → d컨슈머는 새로운 파티션에 대해 가장..

토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능 하지만 무조건 파티션 수를 늘려주는 것이 좋을까? → 파티션 수의 변경은 신중하게 결정 장점 높은 처리량 : 파티션은 카프카에서 병렬 처리르 지원하도록 구성하는 방안 하드웨어 자원을 최대한 활용 가능 이슈 파일 핸들러 낭비 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게됨 파티션의 수가 많을수록 파일 핸들 수 역시 많아 지게 되어 리소스 낭비 발생 장애 복구 시간 증가 프로듀서 메모리 증가 토픽의 적절한 파티션 수는? 하나의 파티션에 두개의 컨슈머 연결은 불가능 (하지만 1개의 컨슈머가 같은 토픽의 다른 2개의 파티션 연결은 가능) Java 코드에서 consumer.assign 으로 파티션설정시 array 로 설정하기 때문에 n개의 파티션으..

고려사항 디스크 처리량과 용량 메모리 네트워크 CPU 디스크 처리량 Producer 성능에는 브로커 디스크의 처리량(throuthput)이 가장 큰 영향을 줌 메시지 생성 시 서버의 로컬 스토리지에 저장되고, 메시지가 커밋되었다는 것을 최소한 한 브로커가 확인해줄 때까지 Producer 는 대기 따라서 디스크에 빨리 쓸수록 Producer 대기시간 감소 메모리 Consumer가 읽는 파티션의 메시지는 시스템 메모리의 페이지 캐시에 최적화되어 저장 따라서 브로커가 디스크로부터 메시지를 다시 읽어야 하는 것보다 더 빨리 처리될 수 있음 페이지 캐시로 사용되는 메모리가 많을수록 Consumer 성능 증가 서버에 다른 애플리케이션과 함께 실행하면 페이지 캐시를 공유하게 되어 Cosumer 성능 저하되므로 권장하..

kafka version 2.11 - 카프카 성능 테스트 정리 - Kafka 에서 제공하는 테스트용 스크립트 이용 - path : kafka/bin - kafka-producer-perf-test.sh - kafka-consumer-perf-test.sh - 위 스크립트를 옵션 없이 실행 시 아래와 같이 사용법 및 옵션 확인 가능 테스트용 토픽을 생성해서 테스트 진행 default 설정으로 사용시 최대 전송 가능한 record-size = 1MB (1048588 bytes) 1MB 이상 전송 시 카프카 설정 수정 후 재시작 server.properties → message.max.bytes producer.properties → max.request.size consumer.properties → max..