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

안녕하세요~실시간 이미지 또는 동영상을 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만개 이상 등)를 제외하고는 거의 없습니다.그러므로 파티션을 늘린 채로 운영하는 것도 괜찮은 방법이며, 이미 이런 방식으로 많이 활용되고 있습니다.이외의 방법으로 컨슈머를 튜닝해서 데이터 처리량을 늘리는 방법도 있습니다만, 한계가 있기 때문에 보통 파티션과 컨슈머 개수를 늘려서 해결합니다.

카프카 2.8.2 버전과 많이 차이가 있을까요??.

안녕하세요.강의를 들을때 사용하는 현재 2.5.0 버전도 현재 현역으로 많이 활용되고 있습니다. 2.8.2로 올라가면서 많은 부분 발전되었고 패치가 되었으나 버전 호환이 잘 되는 마이너 버전 업그레이드이기 때문에 너무 걱정하지 않으셔도 됩니다. 말씀하신 바와 같이 2.5.0을 듣고 release note를 공부하시면서 2.8.x버전의 차이점을 공부하는 방식은 카프카의 생태계와 발전 방향을 이해하는데 매우 좋은 방법이라 말씀드릴 수 있습니다.

카프카 컨슈머와 커넥트에 대해 질문 드립니다.

안녕하세요~카프카 싱크 커넥터는 컨슈머의 구현체이므로 결과적으로 비슷한 동작을 하는 것은 맞습니다. 하지만, 분명 다른점이 있습니다. 아래는 그 예시입니다.카프카 싱크 커넥터는 commit을 직접 수행할 수 없음컨슈머는 commit을 직접 수행할 수 있고 다양한 commit 옵션이 있음컨슈머는 리밸런스 리스너를 등록할 수 있음카프카 커넥트는 stateless 처리만 가능카프카 커넥트는 분산 프로세스로 운영되고 내부 스레드로 여러개의 싱크 커넥터를 실행할 수 있음많은 DB업체에서는 카프카와 DB연동을 위한 커스텀 커넥터를 오픈소스로 제공하고 있음위와 같은 사유로 인해, 카프카와 DATABASE와 연동시 카프카 커넥트를 사용하는 것이 좋고 일반적으로 많이 사용되는 방식이라고 말씀드릴 수 있습니다. 일반적으로 우리가 데이터베이스와 연동하는 사용 형태를 보면 테이블이 1개만 끝나는게 아니라 10개 100개 이상으로 늘어날 수 있고 해당 동작은 유사할 수 있습니다. 이런 경우 매번 컨슈머 애플리케이션을 배포하는 것이 아니라 카프카 커넥트를 사용하여 파이프라인을 반복적으로 만들면 더욱 유지보수가 편리하게 될 수 있습니다.반면, 컨슈머를 개발해야할 때도 있겠습니다. 컨슈머는 내부적으로 다양한 커밋 타이밍을 처리할 수 있고 리밸런스 리스너를 통해 stateful처리를 할 때 유용하게 활용할 수 있습니다. 이러한 동작은 커넥트에서는 구현할 수 없습니다. 그러므로 이런 특징이 필요할때는 불가피하게 컨슈머를 개발해야할 것 입니다.결과적으로, 단발적인 배포+stateful처리+ 커밋타이밍 조절 등의 특징이 있을 경우에는 컨슈머를 개발하시고 / 반복적인 배포+stateless처리+database와 연동 등의 특징이 있을 때는 커넥트를 구성하여 운용하시는 것이 좋겠습니다.카프카 커넥트를 활용한 개발 사례에 대해서 아래 링크를 확인해보시면 더욱 이해하시기 좋을것 같습니다.https://tech.kakao.com/posts/506

Kafka 서버에서 Kafka만 실행하는 게 일반적인가요?

안녕하세요. 모든 서버가 그러하듯이 하나의 서버에는 여러 애플리케이션을 띄워서 사용하는 경우도 종종 있습니다. 그런데 문제는 이렇게 하나의 장비에 여러 애플리케이션이 실행되면 해당 애플리케이션의 부하와 미래 리소스를 예측하기 어려워지는 부분이 있습니다. 예를 들어 네트워크 사용량같은 것을 분리하여 보기 어렵기 때문에 리소스 확인 및 분석이 어려울 것입니다. 물론, 아주 작은 애플리케이션(로그 수집 등)이 함께 돌아가는데는 문제 없을 것입니다.그러므로, 일반적인 상용환경에서는 장비의 일관성 그리고 리소스의 확인, 유지보수의 편의성을 위해 각각 별도의 서버 장비로 발주하여 실행하는 것이 좋은 방법이라 말씀드릴 수 있ㅅ브니다.

카프카 스트림즈와 커넥트 활용 사례가 더 궁금합니다.

안녕하세요! 답변드립니다.카프카 스트림즈의 경우 스트림즈DSL을 통해 Window, aggregate와 같은 Stateful처리를 지원하고 있습니다. stateful 처리의 특징은 이전 레코드를 참고한다는 점인데요. 이런 특징으로 인해 카프카 스트림즈는 stateful처리에 강점을 가지고 있습니다. 물론, stateless처리도 지원합니다!반면, 카프카 커넥트의 경우 각각의 레코드에 대해 단일 처리를 할 수 있으며 별도의 statful처리를 위한 메서드를 제공하고 있지 않습니다. 그렇기 때문에 일반적으로 Stateless처리를 수행하면서도 반복적인 파이프라인을 생성할 때 효과적입니다. 그리고 커넥트의 경우 커스텀 커넥터(오픈소스)를 통해서 다양한 카프카DATABASE 파이프라인을 사용할 수 있기 때문에 일반적으로 이기종 데이터베이스와 연동하는데 활용하는 것이 일반적이라 볼 수 있습니다.결과적으로 카프카 스트림즈는 반복된 애플리케이션이 아닌 단일 애플리케이션으로써 window, aggregate와 같은 stateful처리에 적합합니다. 반면, 카프카 커넥트는 반복적인 파이프라인을 운영할 때 필요하다고 볼 수 있습니다.

kafka retention 관련하여 질문드립니다.

안녕하세요!문의주신 내용 답변드립니다.세그먼트의 마지막 레코드가 전송된 이후, 말씀하신 바와 같이 저장되지 마자 삭제되는 상황이 발생할 가능성은 적습니다. 왜냐면, 액티브 세그먼트가 아닌 세그먼트로 변경된 시점을 기준으로 retention.ms가 지나면 삭제되기 때문입니다. retention.ms가 극도로 작다면 말씀하신바와 같이 적재와 함께 삭제될 수 있지만, 일반적으로 24hour 이상으로 설정되는 이상 적재와 함께 삭제되지는 않습니다. 그리고 말씀하신바와 같이 장애가 발생했을 때 메시지를 확인하고 싶은 니즈가 있다면 retention.ms를 충분히 길게 설정하시는 것을 추천드립니다.추가로 레코드 단위로 retention은 일반적인 스트림 상황에서 적용할 수 없습니다. kafka-streams에서 materialized view로 활용할 경우에만 key에 null을 넣는 경우도 있지만, 특수하게 사용하는 부분입니다.