게시글
질문&답변
2024.04.19
KStreamJoinKTable 실행시 에러
안녕하세요! 상기 에러는 맥북에서 실행하실 때 발생할 수 있는 호환성 에러 이슈인것으로 보입니다. openJDK 1.8 버전으로 재설치 후 실행해보시겠어요?
- 0
- 2
- 69
질문&답변
2024.04.11
카프카 3버전
안녕하세요~ 제가 아는 선에서는 아직도 카프카 3을 상용환경에서 적극적으로 사용하고 있는 기업은 많지 않은 것으로 보입니다. 왜냐면 기존에 2점대 카프카 브로커를 사용하다가 3으로 넘어가기 위한 마이그레이션 작업이 쉽지 않기 때문입니다. 다만, 최근에 새로 카프카 클러스터를 구축하는 기업에서는 3버전을 도입하고 있는 것으로 알고 있습니다.
- 0
- 1
- 67
질문&답변
2024.04.11
오프셋 커밋 과정에서 장애 발생 시 카프카에서는 어떤 처리가 일어나는지 궁금합니다
안녕하세요. 자동 커밋 옵션이 실행되는 경우 레코드 처리 중간에 장애가 발생하면 마지막으로 커밋된 오프셋부터 마지막으로 처리했던 데이터까지 중복처리가 발생하게 됩니다. 이에 따라 실무환경에서도 컨슈머는 언제든 중복이 될 수 있는 가능성에 대해 염려하고 있으며, 가장 정확한 방법은 유니크 키를 가진 처리방식을 사용함으로써 데이터가 중복으로 들어오더라도 단 한번만 처리하는 idempotence 처리를 만족할 수 있게 됩니다. 말씀하신 바와 같이 레디스를 사용하는 방식도 있고 또는 rdb의 unique key 등을 활용하는 방식도 있습니다. 이외에도 upsert, WAL 방식을 예로 들 수 있겠는데요. 관련 내용을 담은 유튜브 링크를 하나 공유해드리겠습니다! https://www.youtube.com/watch?v=7_VdIFH6M6Q
- 0
- 3
- 103
질문&답변
2024.04.11
파티션 복제의 성능이슈는 없나요?
안녕하세요. 리더 파티션에 데이터가 쌓이고 나면 나머지 팔로워 파티션이 리더의 오프셋을 보고 데이터를 가져갑니다. 이런 과정 상에서 만약 카프카 프로듀서의 acks를 all로 주게되면 나머지 팔로워 파티션에 데이터가 완전히 저장되기 까지 기다립니다. 그렇기 때문에 acks=all로 프로듀서를 운영하게 되면 복제간 시간이 걸리는점 때문에 성능상 불리할 수도 있는점 참고부탁드립니다.
- 0
- 2
- 81
질문&답변
2024.04.11
온 프라미스의 서버랙, 클라우드의 리전 장애에 대비할 수 있는 카프카 설정이 무엇인가요??
카프카 브로커 실행시 broker.rack을 사용하면 복제본이 하나의 리전에 포함되지 않도록 하는 설정이 있습니다. broker.rack 옵션 보러 가기 : https://kafka.apache.org/documentation/#brokerconfigs_broker.rack
- 0
- 2
- 56
질문&답변
2024.04.11
윈도우 연산시 주의해야할 사항 + 기타 질문
안녕하세요. 문의주신 내용에 답변드립니다 스트림 간격시 커밋 간격을 윈도우간격으로 맞추는 의도는 좋습니다. 그러나 이런 셋팅으로는 정확한 이벤트의 시간에 맞춘 데이터 처리가 불가능합니다. 예를 들어 15초 간격의 텀블링 윈도우가 존재하고, 00시00시15초에 발생한 이벤트가 있다고 가정해볼게요. 이 때, 해당 이벤트는 00초~15초 윈도우 프로세싱 시간내에 해당 스트림즈 애플리케이션에 도착할 수 있을까요? 현실적으로 불가능합니다. 해당 시간에 발생한 이벤트는 아무리 빨리 네트워크를 타고 들어오더라도 15~30초 윈도우 프로세싱에 걸치게 됩니다. 이렇듯이 단순히 스트리밍 결과를 커밋 타이밍에 맞추도록 윈도우 간격과 커밋 타이밍을 맞추는 것은 의미가 없습니다. 또한 지연도 발생할 수 있구요. 그렇기 때문에 말씀하신 내용을 원하신다면 차라리 suppress() 메서드를 활용하시는 것이 좋겠습니다. suppress() 메서드 설명 : https://developer.confluent.io/patterns/stream-processing/suppressed-event-aggregator/ 2,3,4번에 대한 내용은 책에 포함된 내용이 아니고, 지금 들으시는 강의에도 포함된 내용이 아닌점 참고부탁드립니다. 감사합니다.
- 0
- 2
- 79
질문&답변
2024.03.27
데이터가 많은 브로커에서는 ISR이 유지되기 어렵나요?
안녕하세요. replication.factor가 2 이상이라면 replication lag이 반드시 존재합니다. 팔로워 파티션은 리더 파티션에 데이터가 적재된 이후에 싱크를 시작하기 때문이죠. 그렇기 때문에 초당 데이터 처리량이 많은 파이프라인에서는 실제로 ISR이 완벽하게 모든 파티션들(리더와 팔로워)이 유지 되는 경우는 거의 없는 것이 맞습니다.
- 0
- 2
- 102
질문&답변
2024.03.27
retention.byte에 대해 질문있습니다.
안녕하세요. retention.ms를 사용하지 않는 경우 말씀대로 retention.byte에 의해 좌우됩니다. retention.byte가 1GB보다 큰 2GB로 줄경우, segment file 여러개의 용량에 따라 데이터가 삭제될 수 있습니다. 그러므로, 여러 하나의 세그먼트 파일 단위가 아닌 여러 세그먼트 단위로 생각하시면 좋을것 같습니다!
- 0
- 2
- 70
질문&답변
2024.03.19
파티션 복제
안녕하세요 김민우님~ 카프카 클러스터에서 토픽의 파티션을 복제하기 위해서는 2개 이상의 브로커로 이루어진 카프카 클러스터의 운영이 필요합니다. 이를 위해서는 일반적으로 인스턴스를 각각 실행하고 각 인스턴스 서버에 카프카 브로커 애플리케이션을 실행, 운영하는 방식으로 진행됩니다. 설치 방식에 대한 설명은 제 블로그 글을 참고해주세요 AWS에 카프카 클러스터 설치하기(ec2, 3 brokers) : https://blog.voidmainvoid.net/325
- 0
- 2
- 73
질문&답변
2024.03.12
카프카 적용 시 API 를 조회 해야 된다면 어떻게 해야 되는지 궁금합니다.
안녕하세요. 컨슈머가 토픽에서 데이터를 받은 이후에 일정 처리과정 이후 DB에 쌓는 것을 문의주셨는데요. 기본적으로 프로듀서 -> 토픽 -> 컨슈머 로 파이프라인을 운영한다는 뜻은 비동기적인 처리를 지원한다는 뜻입니다. 그렇기 때문에 데이터의 양에 따라 컨슈머랙은 자연스럽게 늘어날 수 있으며 이는 비정상적인 상황이 아닙니다. 그러므로 비동기적 이벤트 처리를 원치 않으시고 즉각적인 데이터 처리를 원하신다면 프로듀서 -> 토픽 -> 컨슈머 와 같은 통신방식은 적합하지 않다고 볼 수 있습니다. 참고로, 컨슈머가 내부 큐를 가지는 것은 일반적인 컨슈머 애플리케이션 개발에 자주 쓰이는 방법은 아닙니다. 결국 데이터양이 많아지면 컨슈머 내부적으로 지연이 발생하기 때문입니다.
- 0
- 2
- 103