6. Operations

6.1 Basic Kafka Operations

Adding and removing topics

  > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --create --topic my_topic_name
        --partitions 20 --replication-factor 3 --config x=y
  • replication-factor : 메시지를 몇 개의 서버에 복제할 것인지
  • partitions : topic이 나누어질 로그 수
    • 파티션 수는 전적으로 단일 서버에 맞아야 함
      • 20개의 파티션이면 20개 이하 서버에서 처리
    • 컨슈머의 최대 병렬 처리에 영향
  • 커맨드 라인의 설정 값은 서버 기본 값보다 우선함

Modifying topics

bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic my_topic_name
        --partitions 40
  • 데이터 분할 but 기존 데이터를 다시 파티셔닝 하지 않음. 이것을 사용하는 consumer에게 문제가 될 수 있다.
    • 데이터는 hash(key) % number_of_partition의 키로 나누어짐.
    • 데이터는 잠재적으로 추가된 파티션에 의해 셔플되지만 kafka는 이것을 재분배 하지 않음. 
  •  // add config 
 bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic my_topic_name --config x=y

 // remove config
  > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic my_topic_name --delete-config x

 // delete topic
  > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic my_topic_name

 // topic을 삭제하기 위해서는 server config를 변경해야 한다.(default: 토픽 삭제 불가능)
 delete.topic.enable=true

Graceful shutdown

카프카 클러스터의 브로커 shutdown시 graceful shutdown의 두 가지 최적화

  1. 모든 로그를 디스크에 동기화하여 다시 시작될 때 로그 복구를 수행하지 않아도 됨. 빠른 재시작.
  2. 다른 레플리카로 향하는 모든 파티션을 마이그레이션. 리더십 이동 속도가 빨라지고 각 파티션을 사용할 수없는 시간을 몇 밀리 초로 최소화 할 수 있다.
  3. 로그를 동기화하는 것은 서버가 강제 종료 (hard kill) 이외의 방법으로 중지 될 때마다 자동으로 수행되지만 제어 된 리더십 마이 그 레이션을 위해서는 특수 설정을 사용해야합니다.
controlled.shutdown.enable=true

Balancing leadership

  • 브로커가 중지되거나 충돌 할 때마다 해당 브로커의 파티션에 대한 리더십이 다른 복제본으로 전송( 읽기 및 쓰기에는 사용되지 않음)
  • 우선 복제본
    • 파티션의 복제본 목록이 1,5,9이면 노드 1은 복제본 목록의 앞부분이므로 노드 5 또는 9의 리더로 우선 사용
//복원 된 복제본에 대한 주도권을 회복
> bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot

// auto rebalancing
 auto.leader.rebalance.enable=true

Balancing Replicas Across Racks

// broker config
  broker.rack=my-rack-id

Mirroring data between clusters

  • mirroring
    • 단일 클러스터의 노드간에 발생하는 복제와 혼란을 피하기 위해 Kafka 클러스터간에 데이터를 복제하는 프로세스
    • 미러링 프로세스를 여러 개 실행하여 throughput 과 fault-tolerance 향상시킬 수 있음
  • 데이터는 원본 클러스터의 항목에서 읽히고 대상 클러스터의 같은 이름을 가진 항목에 write.
  • 하나의 topic을 미러링하는 방법
 bin/kafka-mirror-maker.sh
        --consumer.config consumer.properties
        --producer.config producer.properties --whitelist my-topic
  • --whitelist 옵션을 사용하여 주제 목록을 지정
    • Java 스타일의 정규 표현식을 사용하는 모든 정규 표현식을 허용합니다.
    • --whitelist 'A | B'
    • --whitelist '*'
    • '|'대신 ','를 사용
  • --blacklist 를 사용하여 제외 할 대상을 지정
    • 새로운 consumer 활성화 된 경우 (즉, 소비자 구성에서 bootstrap.servers가 정의 된 경우) --blacklist는 지원되지 않음
  • auto.create.topics.enable = true 구성으로 미러링을 결합하면 새 항목이 추가되는 경우에도 원본 클러스터의 모든 데이터를 자동으로 만들고 복제하는 복제 클러스터를 가질 수 있음

Checking consumer position

> bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group test
  Group           Topic                          Pid Offset          logSize         Lag             Owner
  my-group        my-topic                       0   0               0               0               test_jkreps-mn-1394154511599-60744496-0
  my-group        my-topic                       1   0               0               0               test_jkreps-mn-1394154521217-1a0be913-0

Managing Consumer Groups

그룹 메타 데이터가 ZooKeeper에 저장되어있는 경우에만 삭제할 수 있습니다. 브로커가 파티션 처리 및 재조정의 조정을 처리하는 새 consumer API를 사용할 때 해당 그룹에 대한 마지막 commit 오프셋이 만료되면 그룹이 삭제됨

http://kafka.apache.org/documentation/#basic_ops_consumer_group

Expanding your cluster

  • Kafka 클러스터에 서버 추가하기

    • 고유 한 브로커 ID를 할당하고 새 서버에서 Kafka를 시작
    • 신 서버에 자동으로 데이터 파티션이 할당되지 않으므로 파티션을 이동하지 않으면 새 항목이 만들어 질 때까지 아무런 작업도 수행되지 않음
    • 대개 클러스터에 시스템을 추가 할 때 기존 데이터를 이 시스템으로 마이그레이션 해야함

  • 데이터 마이그레이션 프로세스

    • 새로운 서버를 마이그레이션중인 파티션의 follower로 추가하고 해당 파티션의 기존 데이터를 완전히 복제

  • 파티션 재 지정 도구(partition reassignment tool)

    • 브로커간에 파티션을 이동할

    • 이상적인 파티션 분배는 모든 브로커 사이에 균일한 데이터로드 및 파티션

    • 이동해야 할 topic 또는 파티션을 직접 알아야 한다. (자동x)

    • 실행모드

      • --generate : topic list & broker list가 주어지면 지정된 topic의 모든 파티션을 새 broker로 이동시키기위한 후보 재 할당을 생성

      • --execute : 사용자가 지정한 reassignment 계획에 따라 파티션 재 지정을 시작합니다. (--reassignment-json-file 옵션 사용).

      • --verify : 마지막 --execute 중 partition list의 reassignment 상태를 확인. 성공/실패/진행중

Automatically migrating data to new machines

  • 파티션 재 지정 도구를 사용하면 현재 브로커 세트에서 일부 topic을 새로 추가 된 브로커로 이동가능
  • 일반적으로 한 번에 하나의 파티션을 이동하는 것보다 새로운 topic 을 새로운 브로커 세트로 이동하는 것이 더 쉽기 때문에 기존 클러스터를 확장하는 데 일반적으로 유용합니다. 이를 위해 사용자는 새로운 브로커 집합과 새 브로커의 대상 목록으로 이동해야하는 항목 목록을 제공해야합니다. 그런 다음이 도구는 새 브로커 집합에 주어진 주제 목록의 모든 파티션을 균등하게 분배합니다. 이 이동 중에 주제의 복제 요소는 일정하게 유지됩니다. 효과적으로 주제의 입력 목록에 대한 모든 파티션의 복제본이 이전 브로커 세트에서 새로 추가 된 브로커로 이동합니다.

http://kafka.apache.org/documentation/#basic_ops_automigrate

Custom partition assignment and migration

파티션 재 지정 도구를 사용하여 파티션의 복제본을 특정 브로커 세트로 선택적으로 이동할 수도 있습니다. 이러한 방식으로 사용될 때 사용자는 재 할당 계획을 알고 도구가 후보 재 할당을 생성 할 필요가 없다고 가정합니다. 실제로 생성 단계를 생략하고 곧바로 실행 단계로 이동합니다

예를 들어, 다음 예제는 주제 foo1의 파티션 0을 브로커 5,6으로 이동하고 주제 foo2의 파티션 1을 브로커 2,3로 이동합니다.

http://kafka.apache.org/documentation/#basic_ops_partitionassignment

Decommissioning brokers

  • 파티션 재 지정 도구에는 브로커를 폐기하기위한 재 할당 계획을 자동으로 생성 할 수 있는 기능이 없음
    • 브로커에 호스팅 된 모든 파티션의 복제본을 폐기하여 나머지 브로커로 이동하는 재 할당 계획을 수립해야합니다.
    • 재 할당을 통해 모든 복제본이 폐기 된 브로커에서 다른 브로커로 이동되지 않도록해야하므로 상대적으로 지루할 수 있습니다. 이 프로세스를 수월하게하기 위해 향후 폐업 브로커를위한 툴링 지원을 추가 할 계획입니다.

Increasing replication factor

기존 파티션의 복제 계수를 높이는 것은 쉽습니다. 커스텀 재 할당 json 파일에 여분의 복제본을 지정하고 --execute 옵션과 함께 사용하여 지정된 파티션의 복제 계수를 높이십시오.

예를 들어, 다음 예제는 주제 foo의 파티션 0의 복제 계수를 1에서 3으로 증가시킵니다. 복제 계수를 높이기 전에 브로커 5에 파티션의 유일한 복제본이 존재했습니다. 복제 계수를 높이는 과정에서 복제본을 더 추가합니다 중개인 6과 7.

첫 번째 단계는 json 파일에서 사용자 지정 재 할당 계획을 수공예품으로 보내는 것입니다.

http://kafka.apache.org/documentation/#basic_ops_increase_replication_factor

Limiting Bandwidth Usage during Data Migration

http://kafka.apache.org/documentation/#rep-throttle

Setting Quotas

http://kafka.apache.org/documentation/#quotas

Data Centers

데이터 센터에 로컬 클러스터와 상호 작용하고 클러스터간에 미러링하는 응용 프로그램 인스턴스가있는 각 데이터 센터에 로컬 Kafka 클러스터를 배포하는 것입니다 (이를 수행하는 방법은 미러 작성 도구의 설명서 참조).

이 배치 패턴을 통해 데이터 센터는 독립 엔터티 역할을 할 수 있으며 데이터 센터 간 복제를 중앙에서 관리하고 조정할 수 있습니다. 이렇게하면 각 시설이 독립적으로 작동하여 데이터 센터 간 링크를 사용할 수없는 경우에도 작동합니다.이 경우 미러링은 링크가 복원 될 때까지 뒤쳐집니다.

6.3 Kafka Configuration

Important Client Configurations

The most important old Scala producer configurations control

  • acks
  • compression
  • sync vs async production
  • batch size (for async producers)

The most important new Java producer configurations control

  • acks
  • compression
  • batch size

The most important consumer configuration is the fetch size.

All configurations are documented in theconfigurationsection.

results matching ""

    No results matching ""