Kafka 4.0 zk 코드 제거 가이드 요청

넵! 4버전도 준비해서 올릴 수 있도록 고려해보겠습니다~!

consume 이후 lag가 줄어들지 않음

안녕하세요. 컨슈머가 운영하고 있을 때 lag이 줄어들지 않는 이유는 다양한데요. 그 중 하나는 커밋을 하지 않아서 일 수 있습니다. 커밋주기를 확인하시기 바랍니다. 만약, 오토 커밋이라면 시간 단위로 커밋을 하기 때문에 실제 커밋 시점은 늦을 수 있습니다.

안녕하세요. 강의의 카프카 버전과 현재 시점의 카프카의 차이점 문의 드립니다.

안녕하세요. 강의 카프카 버전과 다른점을 알기 위해서는 Release note를 참고하거나 오픈소스로 공개되어 있는 apache kafka source code를 보는 것이 가장 좋습니다.release note : https://dlcdn.apache.org/kafka/4.1.1/RELEASE_NOTES.htmlgithub kafka : https://github.com/apache/kafka마이너 버전별로도 변경점이 있기 때문에 정확히 원하는 버전의 차이점을 알기 위해서는 상기 코드나 도큐먼트를 확인하시는 것이 가장 정확합니다!

멱등성 프로듀서 retries 관련 질문입니다.

안녕하세요.1. retries가 Integer.MAX_VALUE로 설정되는 이유?멱등성 보장과는 크게 관련이 없을것 같습니다. 멱등성 프로듀서가 설정되기 전인 카프카 2.3의 producer config를 보면 retries가 2147483647로 설정되어 있기 때문입니다. 예상치 못한 네트워크의 오류 등의 이슈로 데이터를 전송하지 못한 부분에 대해 지속적으로 재처리하기 위한 목적으로 이렇게 큰 값을 설정한 것으로 보입니다. 마지막으로 send() 메서드를 호출한 이후로는 내부적으로 무한 루프가 돌면서 재처리를 진행한다고 보시면 좋을 것 같아요. 2. retries를 Integer.MAX_VALUE로 설정되어도 괜찮은가요?send() 메서드를 호출한 이후에 내부적으로 무한루프가 돌면서 retry를 수행하게 됩니다. 다행히도 카프카 프로듀서에는 request.timeout.ms 옵션이 존재합니다. 이 옵션은 성공/실패를 return하기 까지 기다리는 최대 시간인데 기본값은 2분이므로, 만약 2분까지 기다리는 것(브로커의 장애, 네트워크의 장애 등)이 부담스러우시다면 이 옵션을 수정하는 것을 추천드립니다. 마지막으로 멱등성 프로듀서를 사용 여부와 관계없이 프로듀서를 스레드풀로 반드시 관리해야 하는 것은 아닙니다. 필요에 따라 그렇게 사용하셔도 되지만 필수는 아닐 것 같습니다. 다만, 개인적으로 권장하는 것은 producer code를 짜실때 send()메서드 이후 비동기(Callback)로 결과를 받을 수 있도록 짜는 것이 중요할 것 같습니다.

채팅 서비스 개발 시 주의점이 있을까요?

안녕하세요. 우선, 채팅의 경우 그 자체로도 굉장히 복잡한 비즈니스 기능들이 포함되어 있고 소셜 미디어 특성에 따라 특화된 기능이 다르기 때문에 내부 아키텍처도 각기 다른 형태로 되어 있다는 점을 염두해 두셔야 할 것 입니다. 그러므로 정답은 없고 상황에 따라 적절한 기술을 사용하는 것이 중요할 것 같습니다.1) reactor-kafka 현업 사용 여부현업에서도 종종 reactor-kafka를 사용하는 사례를 볼 수 있었습니다. 다만, 공식 apache kafka를 완벽하게 이해한 상태에서 해당 라이브러리가 가지는 특성을 잘 활용하는 것이 좋겠습니다. 채팅에 반드시 reactor-kafka를 사용하는 것이 정답은 아니지만, 오답도 아니라고 생각됩니다.2) 브로드캐스트 전달 방식채팅방을 토픽으로 사용하는 방식은 적절하지 않은것 같습니다. 토픽은 긴 기간 저장(retention을 아주 길게)도 가능하게 하지만, time기반 index만 제공할 뿐 기본 설계 사상이 삭제를 목적으로 두고 만들어진 것이기 때문입니다. 그래서 토픽은 대규모 트래픽에 대한 대응 용도로만 사용하시고 별도로 저장소를 가지는 것이 옳겠다는 생각이 듭니다.3) 채팅 이력 전달 방법채팅방의 채팅 이력은 선정하신 별도의 데이터베이스를 기반으로 클라이언트에도 데이터를 동기화하여 기본적으로 클라이언트 검색과 채팅 내역 데이터베이스 검색을 동시에 수행하는 것이 좋겠다는 생각이 듭니다. 그리고 레디스는 매우 비싼 데이터베이스 중 하나로서 속도가 중요하고 데이터 양이 적다면 고려가능하지만, 일반적인 채팅 앱에서는 주 저장소로 선택하기는 어려울 것 같다는 생각이 드네요.

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

안녕하세요. 문의사항에 답변드립니다. 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개의 클러스터에서도 충분히 운용가능한 정도라고 생각되어 집니다. 파티션이 지속해서 많아지는 경우 브로커 개수를 늘리는 방법으로 적절히 운용하실 수 있을 거라 생각됩니다만, 상황에 따라 클러스터를 새로 만들어 운용하는 것도 나쁘지 않은 방법이라고 생각됩니다.감사합니다.