shutdownThread 에 대한 문의 입니다.

안녕하세요. 컨슈머의 shutdownThread는 컨슈머의 안전한 종료를 위해 명시적으로 종료 시그널을 보내고 컨슈머를 종료(close()) 시키는 것에 의의가 있습니다. 컨슈머에 장애가 발생하여 running 중인 애플리케이션이 shutdownThread럴 거치지 않고 죽는다면 데이터의 유실 또는 중복이 발생할 수 있습니다. 이 경우 장애에 대비한 대응책은 별도로 로직으로 개발하셔야 합니다.해당 강의에서는 컨슈머 그룹과 관계없이 컨슈머에 대한 종료에 대한 실습을 진행했습니다. 그래서 kill 이후에 wakeup()을 통해 안전하게 종료되는 것을 보실 수 있습니다.그리고 컨슈머그룹을 여러 인스턴스(분리된 pod)로 운영하실 때 문제 발생시 리밸런싱에 대한 로직 개발은 섹션7에 리밸런싱 부분을 참고해주시면 좋겠습니다!

zookeeper실행시 오류가 발생합니다.

안녕하세요 해당 에러는 kafka 바이너리가 관련 소스코드를 찾지 못해서 생기는 현상인것 같습니다.(사진)카프카 다운로드 페이지에서 Binary downloads에서 tgz 파일을 다운로드 받아서 다시 해보시겠어요?

커스텀 소스 커넥터에서 Thread.sleep (1000) 은 왜 하는거에요?

안녕하세요. 해당 소스코드에서 Thread.sleep(1000)은 단순히 running 환경 동작 확인을 위한 코드입니다. 로직상 없어도 되는 부분이니 참고부탁드립니다.

처리량을 늘리기 위해서 파티션을 늘리고 컨슈머를 늘려야한다고 설명하셨는데요

안녕하세요. 일반적으로 리소스의 관리 차원에서 1개 컨슈머 애플리케이션이 n개 컨슈머 스레드를 돌리는 것은 특별한 경우가 아닌 이상 하지 않습니다. 1개 컨슈머 애플리케이션에 1개 컨슈머 스레드를 돌리고, 해당 애플리케이션이 실행되는 pod를 여러개 운영(replica:5 와 같이)하는 것이 실무에서 가장 많이 사용되는 방식이라고 보면 좋을 것 같습니다다만, 앞서 말씀드렸다시피 k8s와 같이 애플리케이션의 증설(scale out)이 쉬운 상황이라면 이 방법이 일반적이겠으나, 물리장비 운영과 같이 deploy가 쉽지 않고 제한된 환경에서는 1개 서버에 여러개의 컨슈머를 운영하는 것도 방법입니다.

파티션 개수와 컨슈머 개수의 처리량 관련 질문

안녕하세요.기본적으로 프로듀서와 컨슈머는 리더 파티션과 통신합니다. 그리고 일반적으로 토픽의 '파티션 개수'라고 불리는 것은 리더 파티션의 개수라고 이해하시면 쉽습니다. 즉, 리더 파티션 개수를 늘리면 병렬적으로 통신할 수 있는 파티션 개수가 늘어나서 처리량이 늘어나는 것입니다.반면, 팔로워 파티션은 역할자체가 리더 파티션과 다릅니다. 리더 파티션에 들어온 데이터를 지속적으로 복제하고 적재하여 장애에 대비하게 되는 것이 팔로워 파티션입니다. 그렇기 때문에 팔로워 파티션은 리더 파티션이 존재하는 브로커가 아닌 다른 브로커에 저장되는 것이죠.

동영상 및 이미지 처리 관련 문의 드립니다.

안녕하세요~실시간 이미지 또는 동영상을 frame단위로 카프카로 전송하여 처리하는 방법은 일반적으로 널리 사용되는 방법은 아닌것으로 알고 있습니다. 언급해주신 구현에 대해 레퍼런스도 본적이 없습니다. 카프카는 분산 이벤트 처리 플랫폼으로서 특정 시점에 발생된 '이벤트'에 대해 처리하기 위해 담는 용도로 사용되는 것이 기본 개념입니다. 그렇다보니 frame단위로 처리되고 특정 fps로 실행되어야 하는 동영상과 같은 요구사항에서는 카프카가 적합하지는 않다고 생각되네요. 컨슈머나 카프카 스트림즈는 이러한 요구사항에 맞추어 운영될 수 없기 때문입니다.

주키퍼 없이 사용 문의 드립니다.

안녕하세요~아파치 카프카는 3.x버전부터 주키퍼가 없는 채로 운영이 가능한 kraft 모드의 카프카를 제공하고 있습니다. 3점대 초반에는 불안한 모습을 많이 보였으나 3.8.0 이후 버전에서는 꽤 안정적으로 운영되고 있으며 많은 기업에서 도입해서 사용중에 있습니다. 그러나 출시된지 얼마되지 않은지라 일부 트러블 슈팅에서 어려움이 보여서 아직까지도 주키퍼를 포함한 형태로 운영하는 경우도 종종 있는 것으로 알고 있습니다.kraft와 무관하게 카프카 오픈소스(주키퍼 포함)은 커넥트, 스트림즈와 잘 호환되며 이는 오픈소스 아파치 카프카와 함께 배포되기 때문에 문제가 없습니다. 다만, ksqldb와 같이 confluent에서 사기업이 운영하는 애플리케이션은 버전별 호환성에 대해 개별적으로 알아보시고 확인하는게 좋아보입니다.추가로 브로커 1대는 1대의 물리적 장비를 뜻하고 실제로 운영할 때는 물리적 장비 3대 이상을 운영하고 각 서버에 1개의 브로커 애플리케이션을 실행하여 운영하는 것이 일방적입니다. 또한, 권장 스펙인 메모리 32GB는 말그대로 '권장 스펙'이기 때문에 실행/운영하시는 환경의 데이터 처리량과 네트워크 가용량, 브로커의 튜닝 상황에 따라 다르게 운영하시면 됩니다. 극단적으로 데이터의 처리가 많지 않다면 8GB 물리 장비로 운영하는 경우도 있다고 볼 수있습니다.

kafka 를 띄우니 오류가 발생하고 종료합니다.

안녕하세요~ 보내주신 로그를 보니 주키퍼와 설정이 잘못되었거나 버전이 맞지 않는 것으로 보입니다.현재 다운로드, 실행한 카프카가 2.5.0이 맞는지 확인 부탁드립니다.주키퍼가 정상적으로 실행중인지 확인 부탁드립니다.

zookeeper 실행시 오류 .. 무엇을 해야 할까요?

안녕하세요~주키퍼 실행 정보에 대해서 공유해주셨는데요. 어떤 오류가 발생했는지 스크린샷 또는 로그를 남겨주시면 확인 후에 다시 답변드리겠습니다. 실행정보와 설정 파일에는 문제가 없어보이네요.

파티션 추가로 해결할 수 있지만 늘어난 파티션은 줄일 수 없지 않나요?

안녕하세요.토픽의 파티션은 늘릴 수 있지만 줄일 수 없습니다. 그렇기 때문에 데이터가 증가가 예상되거나 증가할 때는 파티션과 컨슈머를 늘리는 것이 가장 좋은 방법입니다. 파티션을 늘렷다고 해서 특별히 장애가 더 생기거나 운영상 문제가 되는 경우는 특수한 경우(파티션 개수 1만개 이상 등)를 제외하고는 거의 없습니다.그러므로 파티션을 늘린 채로 운영하는 것도 괜찮은 방법이며, 이미 이런 방식으로 많이 활용되고 있습니다.이외의 방법으로 컨슈머를 튜닝해서 데이터 처리량을 늘리는 방법도 있습니다만, 한계가 있기 때문에 보통 파티션과 컨슈머 개수를 늘려서 해결합니다.