Kafka Operations(Post Deployment)

프로덕션 환경에서 클러스터를 배포 한 후에는 클러스터를 좋은 상태로 유지할 수있는 몇 가지 도구와 모범 사례가 있다.
이 섹션에서는 설정을 동적으로 구성하고, 로깅 수준을 조정하고, 파티션 재 할당 및 Topic을 삭제하는 방법에 대해 설명한다.

1. Tweaking configs dynamically

대다수의 Kafka 설정은 정적이며 설정 파일을 통해 구성된다. 그러나 토픽 별로 조정할 수있는 몇 가지 설정이 있다. 이 설정은 broker를 다시 시작할 필요없이 kafka-topics 도구를 사용하여 동적으로 변경할 수 있다. 이 도구를 사용하여 변경하면 각 변경 사항이 지속되고 broker가 다시 시작되더라도 유지된다.

unclean.leader.election.enable

상태가 불명확한 지도자 선출이 가능함을 나타낸다. 리더가 모든 비동기 복제본을 사용할 수 없을 때, 비동기식이 아닌 복제본으로 리더를 이동하여 데이터 손실을 초래할 수 있다.

Type: boolean
Default : true
Importance: High

min.insync.replicas

만일 비동기 복제본의 수가 이 숫자 아래로 떨어졌을 때 쓰기 수용을 멈춘다.

Type: int
Default : 1
Importance: High

max.message.bytes

메세지 크기의 최대

Type: int
Default : Integer.MAX_VALUE
Importance: medium

cleanup.policy

이전 세그먼트를 삭제할지 중복 제거할지에 대한 설정.

Type: string
Default : delete
Importance: medium

flush.messages

flush 되기 전에 로그에 기록 할 수있는 메시지 수

Type: long
Default : Long.MAX_VALUE
Importance: medium

flush.ms

flush 되기 전에 로그가 dirty data(commit 되지 않은 data)를 가질 수있는 시간

Type: long
Default : Long.MAX_VALUE
Importance: medium

segment.bytes

Type: int
Default : 1048576
Importance: low

segment.ms

Type: long
Default : Long.MAX_VALUE
Importance: low

retention.bytes

로그가 사용할 수있는 대략적인 총 바이트 수

Type: long
Default : Long.MAX_VALUE
Importance: low

retention.ms

Type: long
Default : Long.MAX_VALUE
Importance: low

segment.jitter.ms

Type: long
Default : 0L
Importance: low

segment.bytes

Type: long
Default : 1048576
Importance: low

2. Logging

Kafka는 여러 로그를 출력한다. 로그의 위치는 패키징 형식에 따라 다르며 rpm/debian에서 kafka_logs_dir는 /var/log/kafka에 위치하고, archive 형식에서는 $base_dir/logs에 위치한다. 기본 로깅 레벨은 INFO 이다.

디버깅을 할때, 특히 ISR 을 실패한 복제본이 있을 경우 로깅 수준을 DEBUG로 높이는 것이 좋다. 서버 로그는 logs/server.log에 있다. log4j.properties 파일을 수정하고 노드를 다시 시작할 수 있지만, 불필요한 작동 중지 시간을 야기한다.

1. Controller

Kafka는 cluster에서 한 broker를 controller로 선출한다. controller는 cluster의 관리를 맡으며 broker 장애, 리더 선출, 토픽 삭제와 같은 이벤트 처리를 담당한다. controller 로그는 server 로그와 분리되어 logs/controller.log에 위치한다.

2. State Change Log

controller는 Kafka cluster의 모든 리소스를 관리하는데 이는 topic, partition, broker와 replica를 포함한다. controller에 의해 변경된 리소스에 관한 로그는 logs/state-change.log에 위치한다. 이는 트러블슈팅 목적으로 매우 유용하며 이 로그의 기본 로깅 레벨은 TRACE 이다.

3. Request logging

Kafka는 broker로부터의 모든 요청을 로깅 할 수 있는 기능을 가지고 있다. 이는 produce와 consume 요청 뿐만 아니라 controller가 broker에 하는 요청, metadata 요청도 포함한다.

DEBUG 레벨이 가능하다면 모든 요청이 수행되는 대기 시간 정보도 포함될 수 있으며, 우리는 이를 통해 병목이 어디에 위치하는지 관찰할 수있다. TRACE 레벨로 실행한다면 모든 요청의 내용 또한 로깅 가능하다.

하지만 어마무시한 로그 양으로 인해 cluster의 성능에 영향을 미칠 수 있기 때문에 TRACE 로 설정하는 것은 추천하지는 않는다.

3. Admin operations

1. Adding topics

수동으로 topic을 추가할지, 존재하지 않는 topic에 대해 처음으로 게시 요청이 들어오면 자동으로 topic을 생성할지 선택할 수 있다. 만일 자동 생성으로 설정한다면 topic 설정들에 대한 기본값을 조정하길 원할텐데, topic 도구를 사용해서 topic을 추가하거나 변경할 수있다.

$ bin/kafka-topics --zookeeper zk_host:port/chroot --create --topic my_topic_name \   
   --partitions 20 --replication-factor 3 --config x=y

replication-factor는 각 메시지들을 서버들에 얼마나 복제해둘 것인지를 제어한다. replication-factor를 2또는 3으로 설정할 것을 추천하는데 data consumption을 방해하지 않으면서 머신들을 바운스할 수 있기 때문이다.

partition 수는 topic에 얼마나 많은 수의 로그를 샤딩할 것인가를 제어한다. partition 수는 매우 영향력 있는데 먼저 각 파티션은 전적으로 단일 서버에서도 적합해야한다. 마지막으로 partition 수는 consumer의 병렬 처리에 영향을 준다.

명령 행에 추가 된 구성은 서버의 기본 설정보다 우선한다.

2. Modifying topics

topic 도구를 이용해서 topic의 partitioning 또는 설정정보를 변경할 수 있다.

$ bin/kafka-topics --zookeeper zk_host:port/chroot --alter --topic my_topic_name \  
   --partitions 40

파티션은 데이터를 의미론적으로 분할하는 것이며, 파티션을 추가해도 기존 데이터의 파티션이 변경되지 않으므로 consumer가 해당 파티션을 사용하는 경우 consumer를 방해 할 수 있다. 즉 데이터가 해시 (키) % number_of_partitions로 파티션 된 경우, 파티션은 파티션을 추가하여 임의로 셔플되지만 Kafka는 데이터를 자동으로 재배포하지 않는다.

설정 추가하기 :

$ bin/kafka-topics --zookeeper zk_host:port/chroot --alter --topic my_topic_name --config x=y

설정 제거하기 :

$ bin/kafka-topics --zookeeper zk_host:port/chroot --alter --topic my_topic_name \  
   --deleteConfig x

Kafka는 토픽 당 파티션 수 줄이는 기능은 현재 지원하지 않는다.

3. Deleting topics

$ bin/kafka-topics --zookeeper zk_host:port/chroot --delete --topic my_topic_name

4. Graceful shutdown

Kafka 클러스터는 자동으로 broker 종료나 장애를 감지하고 partition을 위한 새로운 리더를 선출한다. 이는 유지 보수 혹은 구성 변경의 목적으로 의도적으로 중단된 경우, 서버에 장애가 발생한 경우 등에 발생하며 Kafka는 단지 kill 시키는 것외에 정상적으로 작동을 중지하는 메카니즘을 지원한다. 서버가 정상적으로 중지되면 다음과 같은 두 가지 최적화가 이루어진다.

모든 로그를 디스크에 동기화하여 다시 시작할 때 로그 복구를 수행하지 않아도 된다. 로그 복구에는 시간이 걸리기 때문에 재시작 속도가 빨라진다.
서버가 종료되기 전에 모든 파티션을 마이그레이션 해준다. 이에 따라 leadership 전송 속도가 빨라지고, 각 파티션의 비가용시간이 최소화 된다.

로그 동기화는 서버가 강제 종료되는 경우 이외의 방법으로 중지될 때마다 자동으로 수행되지만 controlled leadership의 경우에는 특수 설정을 이용해서 마이그레이션 해야한다.

controlled.shutdown.enable=true

broker에 호스팅 된 모든 파티션에 복제본이 있는 경우(복제 인수가 1보다 크고 복제본 중 하나 이상이 활성 상태인 경우)에만 제어 종료가 성공하며
마지막 복제본을 종료하면 해당 Topic 파티션을 사용할 수 없다.

5. Scaling the Cluster

Kafka cluster에 서버를 추가하는 것은 매우 쉽다. 그냥 고유한 broker id를 지정하고 새로운 서버의 Kafka를 실행하기만 하면 된다. 그러나 새로운 서버에는 자동으로 데이터 파티션이 할당되지 않는다. 그래서 파티션을 이동시키지 않으면 새로운 토픽을 만들때까지 아무런 작업을 하지 않는다. 즉 서버를 새로 추가한 아무런 보람도 없는 셈이다. 따라서 보통 클러스터에 새로운 머신을 추가할 때 기존 데이터들이 추가된 머신에 마이그레이션 되야 하는데, 데이터 마이그레이션의 또다른 일반적인 이유는 broker를 폐기하고 클러스터 전체에서 데이터의 균형을 조정하기 위함이다. (불균형이되는 경우)

데이터 마이그레이션의 절차는 수동으로 시작되지만 완전히 자동화되어있다. Kafka는 파티션을 이동할 때, 마이그레이션 할 partition의 follower로서 목적 머신에 새로운 복제본을 추가한다. 새 복제본은 복제할 수 있고 완전히 복제되면 동기화 상태로 표시된다. 그런 다음 존재하고 있던 복제본 중 하나가 삭제되며 이동이 완료된다.

Confluent Enterprise 에는 Confluent-rebalancer 도구가 포함되어 있고, Confluent Open Source에는 kafka-reassign-partitions 도구가 포함되어 있다.

Confluent Enterprise의 이점 :

데이터 이동 최소화
cluster 와 topic 레벨에서 데이터 균형 유지
broker간 디스크 사용량 조정
broker 폐기 지원
내려간 broker로부터 파티션 이동 가능

open source partition reassignment 도구는 exclusive한 3가지 모드로 실행 가능하다.

--generate :
이 모드에서는 Topic과 broker 목록이 주어지면 새로운 broker에게 지정된 Topic의 모든 파티션을 이동시키기 위해서 후보를 재지정 한다. 이 옵션은 Topic 목록과 대상 broker가 있는 경우 파티션 재 지정 계획을 생성하는 편리한 방법을 제공한다.
--execute :
이 모드에서는 사용자가 지정한 재할당 계획에 따라 파티션 재할당을 시작한다. (–reassignmnet-json-file 옵션 사용) 관리자가 작성하거나 -generate 옵션을 사용하여 제공된 계획에 따라 재할당을 할 수 있다.
--verify :
이 모드에서는 마지막 –execute 동안 재할당된 모든 파티션의 상태를 확인한다. 상태는 성공적으로 완료, 실패, 진행 중 일 수 있다.

파티션 재할당 도구에는 broker를 폐기하기위한 재할당 계획을 자동으로 생성할 수 있는 기능은 없다. 따라서 관리자는 broker에 배치된 모든 파티션의 복제본을 폐기하여 나머지 broker로 이동하는 재할당 계획을 수립해야한다.

6. Increasing replication factor

복제 인수를 높이려면 kafka-reassign-partitions 도구를 사용하면 된다. 사용자 지정 재할당 json 파일에 추가 복제본을 지정하고, –execute 옵션과 함께 사용하여 지정된 파티션의 복제 인수를 늘린다. 예를 들어, 다음 예제는 Topic foo의 파티션 0의 복제 인수를 1에서 3으로 증가시킨다. 복제 인수를 높이기 전에 broker 5에 파티션의 유일한 복제본이 존재했고, 복제 인수를 높이는 과정을 통해 broker 6과 7 복제본이 더 추가됐다.

첫 번째 단계는 사용자 지정 재할당 계획을 json 파일로 가져 오는 것이다. :

$ cat increase-replication-factor.json  
{"version":1,  
 "partitions":[  
    {"topic":"foo",  
     "partition":0,  
     "replicas":[5,6,7]  
    }  
  ]  
}

두 번째 단계는 –execute 옵션과 함께 json 파일을 사용하여 재 할당 프로세스를 시작하는 것이다. :

$ bin/kafka-reassign-partitions --zookeeper localhost:2181 --reassignment-json-file    increase-replication-factor.json --execute  
  
Current partition replica assignment  
  
{"version":1,  
 "partitions":[  
    {"topic":"foo",  
     "partition":0,  
     "replicas":[5]  
    }  
  ]  
}  
  
Save this to use as the ``--reassignment-json-file`` option during rollback  
  
Successfully started reassignment of partitions  
{"version":1,  
 "partitions":[  
    {"topic":"foo",   
     "partition":0,  
     "replicas":[5,6,7]  
    }  
  ]  
}

–verify 옵션을 도구와 함께 사용하여 파티션 재할당 상태를 확인할 수 있다. increase-replication-factor.json (–execute 옵션과 함께 사용)은 –verify 옵션과 함께 사용해야한다.

$ bin/kafka-reassign-partitions --zookeeper localhost:2181 --reassignment-json-file increase-replication-factor.json --verify  

Reassignment of partition [foo,0] completed successfully

kafka-topics 도구를 사용하여 복제 인수의 증가를 확인할 수도 있다.

$ bin/kafka-topics --zookeeper localhost:2181 --topic foo --describe  
Topic:foo    PartitionCount:1        ReplicationFactor:3     Configs:  
Topic: foo   Partition: 0    Leader: 5       Replicas: 5,6,7 Isr: 5,6,7

7. Limiting Bandwidth Usage during Data Migration

Kafka를 머신에서 머신으로 복제본을 이동하는데 사용되는 대역폭의 상한선을 설정하여 복제 트래픽의 쓰로틀링을 적용할 수 있다. 이는 cluster를 재조정하거나 새 broker를 부트스트랩하거나 추가, 제거할 때 유용하다. 데이터 집약적인 작업이 사용자에게 미칠 영향을 제한하기 때문이다.

쓰로틀을 작동시키는데 사용할 수 있는 세가지 인터페이스가 있다. 가장 간단하고 안전한 방법은 confluent-rebalancer 또는 kafka-reassign-partitions를 호출할 때 쓰로틀을 적용하는 것이지만 kafka-configs를 사용하여 쓰로틀 값을 직접보고 변경할 수도 있다. 예를 들어, 아래 명령을 사용하여 rebalancing을 하면 파티션을 50MB/s 이하로 옮길 수 있다.

$ bin/kafka-reassign-partitions --zookeeper myhost:2181--execute  
  --reassignment-json-file bigger-cluster.json —throttle 50000000

이 스크립트를 실행하면 throttle engage를 확인할 수 있다. :

…  
The throttle limit was set to 50000000 B/s  
Successfully started reassignment of partitions.

쓰로틀을 변경하려는 경우 rebalancing 중에 처리량을 늘리면 속도가 빨라지므로 execute 명령을 다시 실행하여 동일한 reassignment-json-file을 전달하면 된다.

$ bin/kafka-reassign-partitions --zookeeper localhost:2181  --execute
  --reassignment-json-file bigger-cluster.json --throttle 700000000
There is an existing assignment running.
The throttle limit was set to 700000000 B/s

rebalancing이 완료되면 관리자는 –verify 옵션을 사용하여 rebalancing 상태를 확인 할 수 있다. rebalancing이 완료되고 –verify가 실행되면 쓰로틀이 제거된다. 관리자가 –verify 옵션을 사용하여 rebalancing이 완료되면 적기에 쓰로틀을 제거하는 것이 중요하다. 그렇지않으면 복제 트래픽이 제한될 수 있다.

–verify 옵션이 실행되고 rebalancing이 완료되면 스크립트가 쓰로틀이 제거되었는지 확인한다.

$ bin/kafka-reassign-partitions --zookeeper localhost:2181  --verify
  --reassignment-json-file bigger-cluster.json
Status of partition reassignment:
Reassignment of partition [my-topic,1] completed successfully
Reassignment of partition [mytopic,0] completed successfully
Throttle was removed.

관리자는 kafka-configs를 사용하여 구성된 설정의 타당성을 검사 할 수도 있다. 쓰로틀 관련 설정은 두 가지가 있다. 쓰로틀 값 자체, 이것은 broker 레벨에서 동적 설정이다.

leader.replication.throttled.rate   
follower.replication.throttled.rate

또한 throttled replicas에 대한 설정이 있다.

leader.replication.throttled.replicas
follower.replication.throttled.replicas

Topic별로 구성되며 4개의 모든 설정 값은 kafka-reassign-partitions 에 의해 자동으로 할당된다.

쓰로틀 메커니즘은 각 broker의 replication.throttled.replicas 목록에 있는 파티션의 송수신 속도를 측정해 작동한다. 이 속도는 replication.throttled.rate 설정과 비교하여 쓰로틀을 적용할지 결정한다. 쓰로틀 메커니즘에 의해 사용되는 쓰로틀 복제 비율은 JMX 메트릭에 기록되며 외부에서 모니터링 가능하다.

MBean:kafka.server:type=LeaderReplication,name=byte-rate  
MBean:kafka.server:type=FollowerReplication,name=byte-rate

throttle limit 설정을 보기 위해서는 :

$ bin/kafka-configs --describe --zookeeper localhost:2181 --entity-type brokers  
Configs for brokers '2' are leader.replication.throttled.rate=1000000,follower.replication.throttled.rate=1000000  
Configs for brokers '1' are leader.replication.throttled.rate=1000000,follower.replication.throttled.rate=1000000

복제 프로토콜의 leader 및 follower 쪽 모두에 적용된 쓰로틀을 보여준다. 기본적으로 양쪽에 동일한 쓰로틀 처리량 값이 지정된다.
쓰로틀 복제본의 목록은 다음과 같이 볼 수 있다. :

$ bin/kafka-configs --describe --zookeeper localhost:2181 --entity-type topics
Configs for topic ‘my-topic' are leader.replication.throttled.replicas=1:102,0:101,follower.replication.throttled.replicas=1:101,0:102

여기서는 leader 쓰로틀이 broker 102의 partition 1, broker 101의 partition 0에 적용되는 것을 볼 수 있다. 마찬가지로 follower 쓰로틀은 broker 101의 partition 1, broker 102의 partition 0에 적용되었다.

기본적으로 kafka-reassign-partitions는 leader가 될 수도 있는 rebalance 전에 존재했던 모든 복제본에 leader 쓰로틀을 적용한다. 이동할 모든 목적지에 follower 쓰로틀을 적용한다. 따라서 broker 101, 102에 복제본이 있는 partition이 102, 103으로 재조정되면 해당 partition의 leader 쓰로틀은 101, 102에 적용되고 follower 쓰로틀은 103에만 적용된다.

필요한 경우, kafka-configs의 –alter를 사용하여 쓰로틀 구성을 수동으로 변경할 수도 있다.

아래는 특히 쓰로틀 복제를 사용할 때 주의를 기울여야 할 것들이다.

1. Throttle Removal :

confluent-rebalancer –finish 또는 kafka-reassign-partitions -verify를 실행하여 reassign이 완료되면 쓰로틀을 제 시간에 제거해야한다.

2. Ensuring Progress :

쓰로틀이 너무 낮게 설정된 경우 요청되는 쓰기 속도와 비교하여 복제가 진행되지 않을 수도 있다. 이 현상은 다음과 같은 경우에 일어난다.

max(BytesInPerSec) > throttle

여기서 BytesInPerSec은 각 broker가 producer를 처리하는 량을 모니터하는 메트릭이다. 관리자는 메트릭을 사용하여 rebalancing 중에 복제가 진행 중인지 여부를 모니터링 할 수 있다.

kafka.server:type=FetcherLagMetrics,name=ConsumerLag,clientId=([-.\w]+),topic=([-.\w]+),partition=([0-9]+)

지연은 복제 중에 지속적으로 감소해야한다. 이 메트릭이 줄어들지 않으면 관리자는 위에서 설명한대로 쓰로틀 처리량을 늘려야한다.

3. Avoiding long delays during replication :

쓰로틀 처리량은 충분히 커야한다. 보수적이지만 가장 좋은 방법은 #brokers MB/s보다 높은 쓰로틀을 유지하는 것이다. #brokers란 cluster의 broker 수를 의미한다.

낮은 쓰로틀을 사용하려는 관리자는 relation에 따라 복제에 사용되는 응답 사이즈를 조정할 수 있다.

Worst-Case-Delay = replica.fetch.response.max.bytes x #brokers / throttle

관리자는 쓰로틀과 replica.fetch.response.max.bytes를 지연시간이 replica.lag.time.max.ms 또는 outer throttle window(replication.quota.window.size.seconds x replication.quota.window.num 또는 replica.socket.timeout.ms)보다 크지않게 적절하게 조절해야한다.

기본으로 replica.fetch.response.max.bytes는 10MB이고, 지연시간은 10초 이하여야 하며, 이는 쓰로틀을 #brokers MB/s 이하로 유지하는 최상의 규칙으로 이어진다.

5개의 노드가 있다고 가정해볼 때, 클러스터 전체에 쓰로틀을 10MB/s 설정하고 새로운 broker를 추가한다. 부트스트랩 broker는 다른 5개의 broker로부터 복제될 것이고 요청 사이즈는 10MB일 것이다. 최악의 페이로드의 경우에 50MB이다. 이러한 경우에 부트스트랩 broker에서 follower 쓰로틀은 50MB/ 10MB/s = 5s에 대한 요청으로 후속 복제 요청을 지연할 수 있고, 이는 허용 가능한 범주에 속해있다. 그러나 쓰로틀을 1MB /s로 설정하게 되면 최악의 지연 시간은 50초가 될 수 있으며 이는 치명적이다.

8. Balancing Replicas Across Racks

랙 인식 기능은 서로 다른 랙에 동일한 파티션의 복제본을 분산시킨다. 이는 kafka가 broker 장애에 대비하여 랙 장애를 처리할 수 있도록 보장함으로써 랙의 모든 broker가 장애 시 데이터 손실 위험을 제한하기 위함이다. 이 기능은 EC2의 가용 영역과 같은 다른 broker 그룹에도 적용될 수 있다.

broker config에 다음과 같은 프로퍼티를 추가하여 특정 랙에 속하도록 지정할수 있다.

broker.rack=my-rack-id

Topic이 생성되거나 변경, 복제본이 재배포 될때, 랙 제약 조건이 적용되어 복제본이 가능한 많은 랙으로 분리된다.

broker에 복제본을 할당하는 알고리즘을 사용하면 broker가 랙에 분산되는 방식에 관계없이 broker당 leader의 수를 일정하게 유지할 수 있다. 그리고 이는 균형잡힌 처리량을 보장하게 된다. 그러나 만일 랙에 broker 수가 서로 다른 경우에 복제본 할당은 균등하지 않다. 더 적은 수의 broker가 있는 랙은 더 많은 복제본을 가져온다. 더 많은 저장소를 사용하고 복제에 더 많은 자원을 투입하게 된다. 따라서 랙 당 동일한 수의 broker를 구성하는 것이 좋다.

9. Enforcing Client Quotas

0.9에서 시작하게되면 Kafka cluster는 produce 및 fetch 요청에 할당량을 강제할 수 있는 기능이 있다. 할당량이란 기본적으로 클라이언트 ID당 정의된 byte 속도 임계값이다. 클라이언트 ID는 요청하는 애플리케이션을 논리적으로 식별한다. 따라서 하나의 클라이언트 ID는 여러개의 producer와 consumer에 걸쳐있을 수 있으며 할당량은 모두 단일 개체로 적용된다. 만일 클라이언트 ID가 test-client이고 produce 할당량이 10MB/sec이라 하면 같은 ID를 가진 모든 instance에 걸쳐 공유된다.

할당량은 매우 많은 양의 데이터를 게시하고 구독받는 producer와 consumer로부터 broker를 보호한다. 특히 큰 멀티테넌시 클러스터에서 중요한데 실제로 kafka를 서비스 할당량으로 사용할 경우 계약에 따라 API 한도를 적용할 수 있다.

각 고유 클라이언트 ID는 클러스터로부터 고정으로 설정된 할당량을 수신한다. (quota.producer.default, quota.consumer.default) 이 할당량은 기본적으로 broker당으로 정의 된다. 각 클라이언트는 쓰로틀되기 전에 broker당 최대 X bytes/sec로 public/fetch가 가능하다.

broker가 할당량 위반을 감지하면 오류를 반환하지 않는다. 오히려 할당량을 초과하는 클라이언트의 속도를 줄이려고 시도한다. broker는 할당량 위반 클라이언트가 가져올 수 있는 필요한 지연 시간을 계산하고, 이 접근 방식은 할당량 위반을 클라이언트 측에서 투명하게 유지한다. 또한 클라이언트 구현에 관계없이 할당량이 적용되도록 특별한 백오프 및 재시도를 구현하지 않아도 된다. 클라이언트 및 broker의 JMX 메트릭은 클라이언트가 쓰로틀되는 시기를 나타낼 수 있다.

클라이언트 바이트 속도는 할당량 위반을 빠르게 감지하고 수정하기 위해 여러개의 윈도우에 대해서 측정된다. 일반적으로 큰 윈도우를 사용하면 트래픽이 급격하게 커지며 사용자 환경 측면에서는 그리 오래걸리지 않는다.

더 높거나 낮은 할당량이 필요하면 클라이언트 ID의 기본 할당량을 무시할 수 있다. 이 메커니즘은 topic별 로그 구성 재정의와 비슷하다.

기본적으로 각 클라이언트 ID는 무제한으로 할당량을 받는다. 다음 구성은 producer 및 consumer 클라이언트 ID당 기본 할당량을 10MB/sec로 설정한 것이다.

quota.producer.default=10485760
quota.consumer.default=10485760

각 클라이언트에 대해 맞춤 할당량을 설정할 수도 있다. :

$ bin/kafka-configs  --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048' --entity-name clientA --entity-type clients
Updated config for clientId: "clientA".

특정 클라이언트의 할당량을 정하는 방법이다. :

$ bin/kafka-configs  --zookeeper localhost:2181 --describe --entity-name clientA --entity-type clients
Configs for clients:clientA are producer_byte_rate=1024,consumer_byte_rate=2048

4. Software Updates

5. Backup and Restoration

가장 좋은 방법은 클러스터를 미러링하는 것이다.

위 글은 confluent의 문서를 바탕으로 작성되었습니다.

Sori-Nori

28살 컴맹 개발자의 성장 로그.

Kafka Operations(Post Deployment)

1. Tweaking configs dynamically

unclean.leader.election.enable

min.insync.replicas

max.message.bytes

cleanup.policy

flush.messages

flush.ms

segment.bytes

segment.ms

retention.bytes

retention.ms

segment.jitter.ms

segment.bytes

2. Logging

1. Controller

2. State Change Log

3. Request logging

3. Admin operations

1. Adding topics

2. Modifying topics

3. Deleting topics

4. Graceful shutdown

5. Scaling the Cluster

6. Increasing replication factor

7. Limiting Bandwidth Usage during Data Migration

1. Throttle Removal :

2. Ensuring Progress :

3. Avoiding long delays during replication :

8. Balancing Replicas Across Racks

9. Enforcing Client Quotas

4. Software Updates

5. Backup and Restoration