Search results for 'kafka'

  1. 2016/08/02 -- 아파치 kafka 0.10.0 offset 초기화 현상
  2. 2016/02/03 -- Apache Kafka 0.9.0.0 변경점

아파치 kafka 0.10.0 offset 초기화 현상

2016/08/02 09:18
Leave a Comment

서비 Tip&Tech ,

최근 프로젝트를 하나 진행하면서 데이터 파이프라인으로 아파치 카프카 0.10.0을 도입하였다.
기존 프로젝트에서 이미 0.8.1을 도입하여 진행한적이 있어 도입 자체는 부담이 없었고.. 0.9를 거치면서 producer, consumer API가 많이 정비되었고 0.10.0에 와서는 stream process 지원이 강화된 부분이 마음에 들어서이다.

개발 완료 후 QA를 진행하는데 특이한점이 나타났다. 카프카 토픽의 데이터가 일정주기로 다시 읽어지는 현상이 나타난 것이다. 토픽으로 새로운 데이터의 유입이 없는것과 다시 읽어지는 데이터가 과거 데이터인것을 확인하는 순간.. '머지 이건?!!'

0.8.1을 사용하는 이전 프로젝트에서는 consumer로 subscription을 하면 점검, 장애의 이유가 아니라면 브로커와 연결을 지속한 형태로 구현했는데, 이번에는 컨슈머가 짧은주기로 subscription, unsubscription을 반복하는 구성이 다른점이다.

현상만으로 보면 어떤 이유에서 컨슈머그룹의 offset 정보가 초기화 되는것 같았고 이를 토대로 코드와 카프카 설정을 몇 번을 리뷰했지만 특이사항을 찾지못하고 수일이 흘렀다. 한가지 특이사항이라면 offset이 리셋되는 주기가 일정한듯 한 현상이 보였다.

주말에 StackOverflow에서 카프카 관련주제를 검토하다가 드디어 해결의 단초를 찾았다.
결국 작성한 코드의 이슈는 아니고.. 0.9버전부터 변경된 오프셋 관리방식(0.8.x까지는 주키퍼가, 0.9부터는 카프카측에서 관리)과 새 버전 카프카 브로커  설정 기본값으로 인한 현상이었다.
키워드는 브로커 설정의 offsets.retention.minutes. 기본값이 1440분, 즉 24시간 유지라네...  0.10 문서 충분히 읽고 검토했다고 생각했는데... 이런 중요한 설정을 놓쳤을 줄은 상상도 못했다.

이와 관련한 이슈와 메일링 리스트
https://issues.apache.org/jira/browse/KAFKA-3806
https://mail-archives.apache.org/mod_mbox/kafka-dev/201606.mbox/%3CJIRA.12976894.1465398960000.46560.1465511841061@Atlassian.JIRA%3E
2016/08/02 09:18 2016/08/02 09:18
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

Apache Kafka 0.9.0.0 변경점

2016/02/03 09:53
Leave a Comment

서비 Tip&Tech ,

아파치 카프카 0.9.0.0 는 이전 버전 대비 인증, SSL레이어 추가 등 많은 변화가 있었습니다.
kafka topic 중심의 변경점은 다음과 같음.

변경
  • 더 이상 Java 1.6 지원하지않음.
  • 더 이상 Scala 2.9 지원하지 않음.
  • 1000이상의 Broker ID는 자동으로 Broker ID를 할당하기 위해 예약되어 있음. 이미 1000 이상의 Broker ID를 사용하고 있다면 Broker Configuration의 reserved.broker.max.id 값을 임계값 이상으로 설정 해야 함.
  • replica.lag.max.messages 설정은 제거되었으며, 동기화 되는 복제본 결정할 때 파티션 리더는 더 이상 후행(lag) 메시지의 수를 고려 하지 않음.
  • replica.lag.time.max.ms 설정은 마지막 복제 요청으로 경과한 시간이 아닌 복제가 마지막으로 이뤄진 시간까지를 포함. 복제는 여전히 리더로부터 패치하며  replica.lag.time.max.ms 시간내에 복제가 되지 않으면 sync가 어긋난것으로 간주.
  • log.cleaner.enable 는 true 가 기본값이 됨. 이는 cleanup.policy=compact 을 설정 시 topic은 기본적으로 compact 적용, 128MB 힙사이즈가 log.cleaner.dedupe.buffer.size 설정을 통한 clear process에게 할당. compacted topics의 사용량에 따라 log.cleaner.dedupe.buffer.size 와 다른 log.cleaner 계열의 설정을 조정해야 할 수 있음.
  • MirrorMaker는 더 이상 multiple target clusters를 지원하지 않음. 그 결과로 단일 consumer.config 설정만 허용되며, 다중 소스 클러스터를 미러링 하려면 각각의 consumer configuration의 소스 클러스터당 적어도 하나 이상의 MirrorMaker 인스턴스가 필요함.
  • org.apache.kafka.clients.tools.* 는 org.apache.kafka.tools.* 로 이관. 
  • kafka-run-class.sh 내의 JVM 성능 옵션 (KAFKA_JVM_PERFORMANCE_OPTS) 변경.
  • kafka-topics.sh 스크립트 ( kafka.admin.TopicCommand )는 이제 실행 실패 시 0이 아닌 종료 코드로 종료.
  • kafka-topics.sh 스크립트 ( kafka.admin.TopicCommand )는 이제 '.' 이나 '_' 등 topic 이름이 충돌할 수 있는 경우 경고 메세지를 출력.
  • kafka-console-producer.sh 스크립트 ( kafka.tools.ConsoleProducer )는 기본값으로 이전 생산자 대신 새 프로듀서 를 사용,  기존의 프로듀서를 사용하려면  이전버전의 producer 사용을 명시 해야 함.
  • 기본적으로 명령줄 메세지는 stderr를 통해 출력.


삭제
  • kafka-topics.sh script (kafka.admin.TopicCommand)를 통한 topic 변경 명령은 deprecate됨. 앞으로는 kafka-configs.sh script (kafka.admin.ConfigCommand)를 사용할 것.
  • 오프셋을 확인용 명령 kafka-consumer-offset-checker.sh (kafka.tools.ConsumerOffsetChecker) 역시 deprecate됨. kafka-consumer-groups.sh (kafka.admin.ConsumerGroupCommand)를 사용 할 것.
  • kafka.tools.ProducerPerformance 클래스 deprecate 됨. org.apache.kafka.tools.ProducerPerformance 클래스를 사용 할 것. kafka-producer-perf-test.sh 역시 새로운 클래스 사용으로 변경 됨.
2016/02/03 09:53 2016/02/03 09:53
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다