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

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

브로커의 장애복구 이후 처리과정에 대해서 질문드립니다.

안녕하세요. unclean.leader.election.enable=true 일때 ISR이 아닌상태에서 브로커 장애가 발생한 경우 프로듀서의 acks 옵션에 따라 두가지 방식으로 진행됩니다.1) producer acks=all 인 경우특정 브로커에 레코드를 전송을 완료하고 복제되기를 기다리다가 장애가 발생하는 경우일 것입니다. 브로커 입장에서는 해당 레코드가 복제되지 않았다는 것을 알고 있으며 프로듀서는 응답을 받지 못해 timeout이 발생하게 됩니다. 이에 따라 retry를 진행해서 레코드를 승급된 리더 파티션(이전엔 팔로워 였음)으로 전송하므로 레코드는 안전하게 재전송됩니다. 2) producer acks=1인 경우 특정 브로커에 레코드를 전송을 완료하고 장애가 발생하게 되는 경우일 것입니다. 브로커 입장에서 해당 레코드가 복제되지 않았고, 프로듀서 입장에서는 정상 전송되었다고 판단하므로 해당 레코드는 유실 시키고 다음 레코드를 프로듀서가 전송하게 됩니다.

카프카의 도입 시기를 결정하는 노하우가 더 있을까요?

안녕하세요!현재 카프카 도입을 고려하고 있으나, 적당한 상황인지 고민이신것으로 이해됩니다. 말씀하신 사항을 고려하여 문의주신 내용 답변드립니다.1) 웬만한 대기업, 대형 서비스가 아니고서야 Kafka 도입은 오버스펙일까요?아닙니다. 카프카는 분산 이벤트 스트리밍 플랫폼으로써 타 플랫폼으로는 대체 불가능한 기준으로 자리잡고 있습니다. 그만큼 카프카의 특성은 이벤트 데이터를 실시간 처리하는데 매우 특화되어 있습니다. 그렇기 때문에, 실시간 데이터를 다루고 로직상 스트림 프로세싱이 필요하다면 카프카 도입은 시간 문제라고 볼 수 있겠습니다. 또한, 카프카는 작은 규모의 클러스터를 구축하여 소규모 데이터부터 시작할 수 있으며, 브로커 스케일 아웃을 통해 추후 커질 수 있는 대규모 데이터도 커버 가능하므로 대형, 대기업이 아니더라도 사용할 수 있고, 이미 많이 사용되고 있습니다. 2) 저희 회사처럼 단일 서비스에 대한 데이터 처리와 고가용성을 확보하려고 하더라도 Kafka 도입이 의미가 있을까요? 강의에서 언급된 인스턴스 스펙보다 낮은 수준의 인스턴스에서 Kafka 를 실행하는 건 괜찮을까요?단일 서비스에 대해서 스트림 데이터를 처리하면서 안전하게 데이터를 처리하기 위해서는 카프카 도입이 적당할 것으로 보입니다. 말씀하신 사항을 보면 100MB/s, 1,000,000TPS 수준의 데이터는 결코 작지 않으며 프로세싱을 위해서는 분산 처리가 필수적인데, 이러한 상황을 고려하면 카프카의 도입은 충분히 의미가 있을 거라 생각됩니다. 그리고 인스턴스 스펙은 항상 사용하는 환경에 따라 다를 수 있기 때문에 제안하는 수준의 스펙보다 크거나/작음 보다는 다루고자 하는 데이터의 크기와 양을 내부적으로 충분히 테스트하시고 결정하면 될것 같습니다. 3) Kafka 는 어느 정도의 트래픽이 발생해야 도입이 유의미할까요?절대적인 데이터 양으로 카프카의 도입 여부를 결정하기는 어려울 것 같습니다만, 굳이 정해보자면 100TPS 이상이며 스트림 프로세싱(window, mapping, aggregation 등)이 필요하다면 카프카 도입을 고려할 것 같습니다. 4) Kafka 도입을 고려하는 시점에 대한 의사결정 요소에 어떤 것들이 있을까요? 키워드 위주로만이라도 설명해주시면 제가 한 번 조사해보도록 하겠습니다.앞서 몇번 더 설명한 것과 같이, '분산', '고가용성', '스트림 프로세싱' 이 가장 중요한 키워드 일것 같습니다. 이러한 스트림 프로세싱 플랫폼 없이는 적절한 로직 개발이 매우 어렵기 때문입니다. 배치처리 또는 마이크로 배치처리로 요구사항을 만족시킨다면 문제 없겠습니다만, 스트림 처리에 특화된 기능들(window, aggregation 등) 그리고 대규모 데이터를 안정적이고 낮은 지연(latency)로 처리하기 위해 distributed processing을 만족시키기 위해서는 카프카가 많은 부분 도와줄 것이라 생각됩니다. 감사합니다. 추가적으로 궁금한 사항 있으면 편하게 문의주세요~

min.insync.repllicas, acks옵션, 그리고 리더 파티션 승급

안녕하세요!리더 파티션 1개, 팔로워 파티션 2개가 존재할 때, 팔로워를 승급시키는 기준은 여러가지가 있습니다. ISR에 포함된 팔로워 파티션(브로커)인지, replica가 잘 되고 있는지가 가장 중요할 것 같습니다. 관련 코드는 다음과 같습니다.object PartitionLeaderElectionAlgorithms { def offlinePartitionLeaderElection(assignment: Seq[Int], isr: Seq[Int], liveReplicas: Set[Int], uncleanLeaderElectionEnabled: Boolean, controllerContext: ControllerContext): Option[Int] = { assignment.find(id => liveReplicas.contains(id) && isr.contains(id)).orElse { if (uncleanLeaderElectionEnabled) { val leaderOpt = assignment.find(liveReplicas.contains) if (leaderOpt.isDefined) controllerContext.stats.uncleanLeaderElectionRate.mark() leaderOpt } else { None } } } ... 생략상기 코드는 실제 카프카 코드로 오프라인이 발생했을 때 리더를 선정하는 코드로 질문에 대한 답이 될 것 같네요!https://github.com/apache/kafka/blob/3.8.0/core/src/main/scala/kafka/controller/PartitionStateMachine.scala

커밋 관련 질의

안녕하세요. 카프카에서 제공하는 기본 Kafka-clients 라이브러리를 사용하고 계신다면 말씀하신 상황들에서 커밋을 수행할 수 있습니다. 리스너라고 말씀하신걸 보니 스프링 카프카를 언급하신것 같은데, 만약 스프링 카프카에서 커밋을 수행하고 싶으시다면 shutdown hook에서 실행되고 있는 컨슈머 클라이언트 객체를 가져와서 커밋을 수행하셔야 합니다. 관련해서 acknowledgment 인터페이스를 참고하시면 좋을것 같습니다.https://docs.spring.io/spring-kafka/docs/current/api/org/springframework/kafka/support/Acknowledgment.html

카프카 보안

안녕하세요! AWS에서 카프카가 구축되어 있는 상태에서 연동하는 방법에 대해 문의 주셨는데요. 이것은 운영중인 환경보안 설정을 어느정도로 하느냐에 따라 다를 것 같습니다. 말씀하신 바와 같이 whitelist처럼 각 ip만 허용하는 방식은 가장 안전한 방법이지만 유연하지 못해서 운영상 어려움이 있을 것 같네요. 만약 AWS에서 운영한다면 카프카 클러스터와 컨슈머를 VPC로 함께 묶어서 운영함으로서, ip는 외부에 노출시키지 않고, 내부적으로는 통신이 원활하게 하는 방식을 채택할 것 같습니다.

특정 브로커에 파티션이 쏠리는 현상

안녕하세요! 파티션이 특정 브로커에 몰리는 현상은 여러 원인이 있을 수 있는데요. 가장 흔히 발생하는 원인 중 하나는 브로커의 개수 변경에 의한 부분입니다. 예를 들어, 브로커3대에 파티션6개의 토픽이 생성된다고 가정한다면, 다음과 같이 파티션들이 분배될 것입니다.파티션 0 -> 브로커 0파티션 1 -> 브로커 1파티션 2 -> 브로커 2파티션 3 -> 브로커 0파티션 4 -> 브로커 1파티션 5 -> 브로커 2이후에 브로커를 5개로 늘리면 해당 파티션들(리더)이 자동적으로 0부터 4까지 5개 브로커에 분배되지 않습니다. 그대로 유지되기 때문에 이런 현상이 반복되다 보면 일부 브로커에 리더 파티션 개수가 몰릴 가능성이 있습니다.그리고 리더 파티션의 쏠림 현상 여부는 브로커로부터 JMX와 같은 지표를 통해 각 브로커당 가지고 있는 리더 파티션 개수를 알아낼 수 있습니다. 상세한 모니터링 관련 부분은 아래 내용을 참고하세요https://docs.confluent.io/platform/current/kafka/monitoring.html#partitioncount

consumer 재배포시 리밸런싱 이슈

안녕하세요~컨슈머를 재배포할 경우 리밸런싱이 발생하는 것이 맞습니다. 그러나 리밸런싱이 일어나는 것은 전혀 문제되는 일이 아닐 수 있으며, 배포시에는 반드시 발생할 수 밖에 없습니다. 다만, 이 리밸런싱이 과도하게 일어나서 데이터의 지연이 발생하거나 로직상 데이터 유실이 발생하는 것이 문제가 될 수 있습니다.말씀하신 대로 컨슈머와 실제 로직을 따로 돌리는 서버를 운영할 수도 있으나, 만약에 저라면 그렇게 운영하지 않을 것 같습니다. 왜냐하면 그만큼 네트워크 비용이 발생하기 때문이고, 리밸런싱은 배포 외에는 일어나는 일이 거의 없기 때문입니다. 다만, 아키텍처상 필요에 따라 분리하는 경우도 발생할 수 있을것 같네요.

카프카 스트림즈 애플리케이션이 죽는 경우가 발생하는지

안녕하세요~카프카 스트림즈를 사용한 데이터 파이프라인 처리에 대한 질문을 남겨주셨는데, 답변드리겠습니다.혹시 이렇게 자바 코드로 작성한 스트림즈 애플리케이션이 죽는 상황이 있나요? (부하 또는 기타 문제로...)스트림즈 애플리케이션은 부하 또는 기타 문제로 인해 언제든지 죽을 수 있습니다. 제대로된 내부 로직 관리가 되지 않는 다면 대표적으로 OOM(Out of Memory)와 같은 상황으로 인해 프로세스가 종료될 가능성이 있습니다. 있을 경우 대비를 한다면 스트림즈 애플리케이션을 자바 코드가 아닌 따로 프로젝트를 만들어(WAS를 따로 생성) 운영을 해야할까요?스트림즈의 이슈 때문이 아니라 자바 로직으로 인한 장애는 프로젝트를 따로 만들더라도 여전히 장애가 발생할 수 있습니다. 다만, 말씀대로 프로젝트를 기존 로직과 분리하는 경우 장애에 대비하기 쉬워지고 리소스 관리 측면에서 더욱 유용하므로 분리하는 것을 추천드립니다. 스트림즈 애플리케이션이 죽는 경우는 어느정도의 부하(초당 몇 바이트정도인지.. 보통..)가 있어야 죽는 경우가 발생하나요? (CPU성능, 메모리 등 PC스펙이 충분하다고 할 경우에요..)CPU, 메모리 성능이 데이터 처리량에 비해 충분할 경우 죽지 않는다고 볼 수 있습니다. 다만, 잘못된 로직으로 인해 메모리가 관리가 되지 않는다면 성능과 무관하게 자바 프로세스는 죽을 수 있습니다. 만약 WAS를 따로 만들어서 운영해야 한다면, WAS를 보통 여러 개 정도 두나요? 아니면WAS를 1개만 만들고 WAS 내 스트림즈 스레드를 여러 개로 만들어서 운영하나요? 아니면 여러개 WAS에 여러개 스레드를 띄우나요?따로 스트림즈 애플리케이션을 만들어 운영할 경우 1개 애플리케이션당 스레드 개수는 1개씩 운영하는 것이 가장 효율적입니다. 다만, 파티션 개수가 많을 경우 프로세스 개수가 너무 많아질 가능성이 있으므로 상황에 따라 프로세스당 카프카 스트림즈 스레드 개수 다르게 운영하는 것이 좋습니다. WAS를 여러개 두는 경우, 1개 WAS가 죽으면 자동으로 fail over 가 되나요? 안된다면 어떻게 fail over가 되도록 구현해야 하나요?카프카 스트림즈 애플리케이션의 경우 여러개 프로세스로 돌릴 때, 일부 프로세스가 죽으면 나머지 프로세스에 리밸런싱 과정을 통해 지속적으로 데이터가 처리되도록 구현되어 있습니다.

연결 브로커 지정

안녕하세요~프로듀서가 토픽에 레코드를 전송할 때, bootstrap.servers에는 100개 브로커중 아무 브로커 2개만 적어도 됩니다. 왜냐면 최초로 통신을 할 때 meta data를 sync하게 되는데, 이 때 필요한 정보들(리더 파티션이 위치한 브로커의 ip 등)을 가져오기 때문입니다.bootstrap.servers에는 일반적으로 2개 이상 브로커 정보를 적는 것이 일반적입니다.