충분히 큰 파티션 생성시 궁금증이 존재합니다.

안녕하세요. 문의사항에 답변드립니다. 1.충분히 큰 파티션 산정여기서 말하는 충분히 큰 파티션이란, 우리가 활용하고 있는 해당 토픽의 프로듀서, 컨슈머의 처리량을 측정하여 산정하시면 됩니다. 예를 들어 해당 토픽으로 보내는 프로듀서의 최대 전송양이 100개/초 이고 컨슈머의 처리량이 100개/초 라면 파티션 개수를 2개로 둘 수 있죠. 이런 경우, 컨슈머를 2개로 할당하여 프로듀서가 레코드를 보내는양이 최대 2배까지 늘어나더라도 대응이 가능합니다. 그렇기 때문에 구현하고자 하는 서비스의 방향성과 미래에 늘어날 데이터양/성능 등을 종합적으로 고려하시는 것이 좋습니다. 2.Spring Application Consumer 구현시 어떤 구조로 구독하면 좋을지?이것은 어떻게 운용하는지에 따라 다릅니다. Spring application에서 consumer는 concurrency를 조절하여 하나의 애플리케이션에서 여러 컨슈머 스레드로 운영할 수 있습니다. 그렇기 때문에 파티션개수 4개일 경우, concurrency=2인 컨슈머 2개로 운영하는 방법도 있고, 또는 concurrency=1인 컨슈머를 4개 운영하는 방법도 있겠습니다. 혹은 concurrency=1인 컨슈머를 2개만 운영하는 경우도 틀린 방법은 아닙니다. 그렇기 때문에 배포하시는 환경과 spring application이 하는 역할 등을 종합적으로 고려하셔야 할것 같습니다.

KTable 키가 없는 레코드 처리

안녕하세요.KTable에서 메시지 키(message key)가 없는 레코드는 무시하고 구체화된 뷰(Materialized View)로 만들어지게 됩니다.

컨슈머 테스트 코드 작성

안녕하세요.카프카 컨슈머의 poll() 메서드 호출을 위해 while(true)를 사용하는 것은 상용환경에서도 흔히 사용하는 방식입니다. 그리고 참고로 wakeup()메서드를 호출하면 poll()메서드에서 wakeupException을 발생시키기 때문에 보통 while(true) 앞뒤로 try-catch문을 작성하여 리소스를 정리하거나 마무리를 합니다. 아래는 관련 코드이므로 참고하시기 바랍니다. try { while (true) { ConsumerRecords records = consumer.poll(Duration.ofMillis(100)); records.forEach(record -> { System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value()); }); } } catch (WakeupException e) { // wakeup() 호출 시 이 예외 발생 (정상 종료 용도) System.out.println("WakeupException caught. Exiting..."); } finally { consumer.close(); System.out.println("Consumer closed."); }그리고 테스트의 경우 크게 두가지 부분으로 나누면 좋겠습니다. 통합 테스트와 단위 테스트입니다. 통합 테스트의 경우 cbt kafka cluster를 운영하면서 cbt consumer를 올리고 레코드를 전달하여 테스트할 수 있습니다. 그리고 통합 테스트가 완료되면 prod kafka cluster와 연동되는 prod consumer를 새로운 버전으로 배포하는 것이 일반적입니다. 그리고 단위 테스트의 경우 poll() 내부에서 개별 레코드를 처리하는 구문을 메서드 또는 클래스로 빼서 mock 처리 같은 것을 통해 테스트하시면 좋을것 같습니다.

리밸런스 onPartitionRevoked이 필요한 상황

안녕하세요. 답변드립니다.1) '마지막으로 처리한 레코드를 기준으로 커밋'수동 커밋 종류에 따라 poll()이 이전에 호출되더라도 커밋이 되지 않을 때가 있습니다. 예를 들자면 일장 시간마다 수동 커밋을 하는 구문을 작성한 것이 있을 수 있습니다.이런 경우, 리밸런싱이 발생할때 마지막으로 처리한 record의 offset을 기준으로 commit을 수행하지 않으면 예상치 못한 결과가 발생할 수 있습니다.그러므로, onPartitionRevoked()에서 그런한 상황에 처할 경우 커밋을 하는 로직을 해당 리스너에서 구현하는 것이 좋다는 의미입니다.2) 오토커밋에서 언제 필요할지?컨슈머는 할당된 파티션을 기준으로 데이터를 처리하게 됩니다. 상황에 따라 onPartitionRevoked()에 컨슈머 처리에 따른 리소스의 할당 및 해제가 필요할 수 있습니다.예를 들어, consumer가 받은 record의 partition번호에 따라 {partition 번호}.txt 에 데이터를 저장하는 컨슈머 애플리케이션이 있다고 가정했을 때, 해당 파티션이 컨슈머에서 해제될 경우 리스너에서 file write flush & io close 와 같은 조치가 필요할 수 있습니다.

카프카 클러스터에서 감당 가능한 파티션(레플리카) 수 문의

안녕하세요. 카프카 클러스터의 적합한 파티션 개수는 리소스(cpu, memory, network, disk 등) 상황에 따라 달라집니다. 그렇기 때문에 단순히 1브로커당 x개의 파티션이 할당 가능하다고 하는 것은 아주 대략적인 추세일 뿐 정답이 아닙니다. 알려주신 파티션 개수 총 18,000개인 경우에 대해서 적절한 컴퓨팅 리소스 상황이라면 1개의 클러스터에서도 충분히 운용가능한 정도라고 생각되어 집니다. 파티션이 지속해서 많아지는 경우 브로커 개수를 늘리는 방법으로 적절히 운용하실 수 있을 거라 생각됩니다만, 상황에 따라 클러스터를 새로 만들어 운용하는 것도 나쁘지 않은 방법이라고 생각됩니다.감사합니다.

reset offset 질문

안녕하세요. 특정 파티션 1개에 대해서만 오프셋을 reset하시려면 다음과 같이 실행하시면 됩니다.// 대상 토픽 : test // 컨슈머 그룹 : my-group // 대상 파티션 : 3 $ bin/kafka-consumer-groups.sh \ --bootstrap-server localhost:9092 \ --group my-group \ --topic test:3 \ --reset-offsets \ --to-earliest \ --execute

KStreamJoinKTable 실행시 오류

안녕하세요.보내주신 로그에 따르면 정확한 원인을 찾기 어렵습니다.사용된 자바 코드build.gradle로그 전체실행시 사용한 JDK 버전을 공유해주시면 다시 한번 확인 후 답변드리겠습니다~

auto.commit.interval.ms 옵션 관련 질문 드립니다.

안녕하세요, auto.commit.interval.ms 를 지정한다는 뜻은 auto commit을 수행한다는 뜻이며, 어떠한 사유로 인해 서버가 부득이하게 종료되는 경우에는 커밋 누락으로 중복 처리 문제가 발생할 수 있습니다.

파티션, 컨슈머 그룹, 컨슈머 관련 질문

안녕하세요~ 답변드리겠습니다 1-1. 하나의 파티션은 컨슈머 그룹에 묶인 컨슈머에 대해서 여러개가 할당될 수 없습니다. 즉, '동일 컨슈머 그룹' 일 경우에 대해서 할당이 안되는 것이 맞습니다. 서로 다른 컨슈머 그룹에 대해서는 별개로 동작합니다! 1-2. 컨슈머 그룹별로 파티션별로 다른 commit이 완료된 오프셋을 가집니다. 예를 들어 파티션이 3개인 토픽에 hdfs-group과 elasticsearch-group 이라는 각각의 컨슈머 그룹이 붙어 데이터를 처리한다고 했을 때, hdfs-group은 각 파티션에 해당하는 커밋된 오프셋이 3개 존재하고 elasticsearch-group에도 마찬가지로 각 파티션에 해당하는 커밋되 오프셋이 3개 존재할 수 있습니다. 서로 다른 컨슈머 그룹의 오프셋은 영향을 미치지 않는다는점 참고부탁드립니다. 2.하나의 컨슈머가 여러 토픽을 구독하는 경우는 실무 기준으로 흔하지는 않은것 같습니다. 스키마가 비슷하고 동시에 처리되어야 할 경우와 같이 특수한 경우에 여러 토픽을 구독할 상황이 있을 수는 있습니다.감사합니다!

java, kotlin

안녕하세요!강의에서 나온 주요 개념은 kafka-clients 공식 아파치 라이브러리 기준입니다. 이 라이브러리는 java로 작성되어 있기 때문에 kotlin에서도 동일하게 사용가능합니다! 감사합니다.