토픽 작업

  • 토픽 작업을 쉽게할 수 있는 툴은 kafka-topics.sh이다.
    • 역할: 클러스터 내 토픽 생성, 변경, 삭제, 정보 조회
    • 토픽 설정 변경은 kafka-topics.sh에서는 지원 중단 되었으니, 더 강력한 툴인 kafka-configs.sh를 사용하는 것이 좋다.
  • kafka-topics.sh를 사용하려면 --bootstrap-server 옵션에 연결 문자열과 포트를 넣어 줘야한다.
  • 이 장 전체에 걸쳐 모든 툴이 저장된 위치는 /usr/local/kafka/bin/ 디렉토리다.

새 토픽 생성하기

  • --create 명령을 사용해서 새로운 토픽을 생성할 수 있다.
  • 생성할 떄는 3개의 필 수 인수가 있다.
    • --topic: 생성하려는 토픽의 이름
    • --replication-factor: 클러스터 안에 유지되어야 할 레플리카의 개수
    • --partitions: 토픽에서 생성할 파티션의 개수
  • 토픽 이름 짓기
    • 토픽 이름에는 영문, 숫자, _, -, .를 사용할 수 있지만, .를 사용하는 것을 권장하지 않는다.
      • 이유: 카프카에서 내부적으로 사용하는 지표에서 .를 _로 변환해서 처리한느 탓에 토픽 이름에 충돌이 발생할 수 있기 때문이다.
    • 토픽 이름을 __로 시작하는 것을 권장하지 않는다.
      • 카프카 내부에서 사용되는 토픽을 생성할 때 __로 시작하는 이름을 쓰느 것이 관례이기 때문이다.
  • 클러스터에 랙 인식 레플리카 할당 설정이 되어 있을 경우, 각 파티션의 레플리카는 서로 다른 랙에 위치하게 된다.
    • 랙 인식 할당 기능을 사용하지 않으려면 --disable-rack-aware 인수를 지정해주면 된다.

토픽 목록 조회하기

  • --list 명령을 사용해서 클러스터 안의 모든 토픽을 보여준다.
    • 이떄 출력되는 결과는 한 줄에 하나의 토픽이며, 특정한 순서는 없다.
    • --exclude-internal와 함꼐 실행하면 __로 시작하는 내부 토픽은 제외하고 보여준다.

토픽 상세 내역 조회하기

  • 하나의 토픽에 대해서만 보고 싶다면 --topic 인수를 지정해주면 된다.
  • 필터링 할 몇몇 옵션을 기준으로 토픽 상세 조회를 하고싶다면 --describe 명령을 사용하면 된다. 아래는 자주 사용하는 옵션이다.
    • --topics-with-overrides: 설정 중 클러스터 기본값을 재정의한 것이 있는 토픽들을 보여준다.
    • --exclude-internal: __로 시작하는 모든 토픽들을 결과에서 제외한다.
    • --under-replicated-partitions: 1개 이상의 레플리카가 리더와 동기화되지 않고 있는 모든 파티션을 보여준다.
    • --at-min-isr-partitions: 레플리카 수(리더 포함)가 인-싱크 레플리카 최소값과 같은 모든 파티션을 보여준다. 이 토픽들은 프로듀서나 컨슈머 클라이언트가 여전히 사용할 수 있지만 중복 저장된 게 없기 때문에 작동 불능에 빠질 위험이 있다.
    • --under-min-isr-partitions: ISR 수가 쓰기 작업이 성공하기 위해 필요한 최소 레플리카 수에 미달하는 모든 파니션을 보여준다. 이 파티션들은 사실상 읽기 전용 모드라고 할 수 있고, 쓰기 작업은 불가능하다.
    • --unavailable-partitions: 리더가 없는 모든 파티션을 보여준다. 이것은 매우 심각한 상황이므로, 파티션이 오프라인 상태이며 프로듀서나 컨슈머 클라이언트가 사용 불간으하다는 것을 의미한다.

파티션 추가하기

  • 파티션 수를 증가시키는 가장 일반적인 이유는 단일 파티션에 쏟아지는 처리량을 줄임으로써 토픽을 더 많은 브로커에 대해 수평적으로 확장시키기 위해서이다.
  • --alter 명령과 --partitions 로 파팃녕르 증가시킬 수 있다.
  • 키가 있는 메시지를 갖는 토픽에 파티션을 추가하는 것으 매우 어려울 수 있다.
    • 이유: 파티션의 수가 변하면 키값에 대응되는 파티션 달라지기 때문이다.
    • 결론: 키가 포함된 메시지를 저장하는 토픽을 생성할 때는 미리 파티션의 개수를 정해 놓고, 일단 생성한 뒤에는 설정한 파티션의 수를 바꾸지 않는 것이 좋다.

파티션 개수 줄이기

  • 토픽의 파티션 개수를 줄일 수 없다.
    • 이유1: 토픽에서 파티션을 삭제한다는 것은 곧 토픽에 저장된 데이터 일부를 삭제한다는 의미인데, 클라이언트 입장에서 일관적이지 않아 보일 수 있다.
    • 이유2: 데이터에 남은 파티션에 다시 분배하는 것은 어려울 뿐 아니라 메시지의 순서를 바꾸게 된다.
  • 만약 파티션의 수를 줄여야 한다면, 토픽을 삭제하고 다시 만들거나 새로운 버전의 토픽을 생성해서 모든 쓰기 트래픽을 새 토픽으로 몰아주는 것을 권장한다.

토픽 삭제하기

  • 토픽 삭제 이유: 메시지가 하나도 없는 토픽이라 할지라도 디스크 공간이나 파일 핸들, 메모리와 같은 클러스터 자원을 잡아먹는다.
  • 토픽을 삭제하기 위해서는 클러스터 브로커의 delete.topic.enable 옵션이 true로 설정되어 있어야 한다.
    • false라면 삭제 요청은 무시되어 아무 처리가 이뤄지지 않을 것이다.
  • 토픽 삭제는 비동기적인 작업이다.
    • 상세 동작: 컨트롤러가 가능하면 빨리 브로커에 아직 계류중인 삭제 작업에 대해 통지하면, 브로커는 해당 토픽에 대한 메타데이터를 무효화한 뒤 관련된 파일을 디스크에서 지우게 된다.
  • 컨트롤러가 삭제 작업을 처리하는 방식 한계 대문에 토픽을 지울 때는 2개 이상의 토픽을 동시에 삭제하지 말고 삭제 작어 ㅂ사잉 ㅔ충분한 시간을 둘 것을 권장한다.
  • --delete 인수를 통해서 토픽을 삭제할 수 있다.
  • 삭제가 성공했는지 확인하려면 --list나 --describe 옵션을 사용해서 클러스터 내 토픽이 더 이상 존재하지 않는다는 걸 확인하면 된다.

컨슈머 그룹

  • kafka-consumer-groups.sh 툴을 사용하면 클러스터에서 토픽을 읽고 있는 컨슈머 그룹을 관리할 수 있다.
    • 역할: 그룹 상세 내역 조회, 삭제, 오피슷 정보 초기화 등

컨슈머 그룹 목록 및 상세 내역 조회하기

  • 컨슈머 그룹 목록 보기: --bootstrap-server와 --list 매개변수를 사용하면 된다.
    • kafka-consumer-groups.sh 스크립트를 사용할 경우, 컨슈머 목록에 console-consumer-{생성된 ID}로 보인다.
  • 목록에 포함된 모든 그룹에 대해서 --list 매개변수를 --describe로 바꾸고 --group 매개변수를 추가함으로써 상세한 정보를 조회할 수 있다.

컨슈머 그룹 삭제하기

  • --delete 매개변수를 사용하면 컨슈머 그룹 삭제가 가능하다.
    • 동작: 그룹이 읽고 있는 모든 노픽에 대해 저장된 모든 오프셋을 포함한 전체 그룹을 삭제한다.
  • 이 작업을 수행하려면 컨슈머 그룹 내의 모든 컨슈머들이 모두 내려간 상태여서 컨슈머 그룹에 활동중인 멤버가 없어야 한다.
    • 만약 비어 있지 않은 그룹을 삭제하려고 시도할 경우, “The group is not empty"라는 에러가 발생하고 아무 작업도 수행되지 않을 것이다.
  • --topic 매개변수에 삭제하려는 토픽의 이름을 지정함으로써 컨슈머 그룹 전체를 삭제하는 대신에 컨슈머 그룹이 읽어오고 있는 특정 토픽에 대한 오프셋만 삭제하는 것도 가능하다.

오프셋 관리

  • 컨슈머 그룹에 대한 오프셋들을 조회, 삭제, 가져오기, 저장이 가능하다.
  • 오프셋 내보내기
    • 설명: 컨슈머 그룹을 csv 파일로 내보내려면 --dry-run 옵션과 함께 --reset-offsets 매개벼누를 사용해주면 된다.
    • CSV 파일 형식: {토픽 이름},{파티션 번호},{오프셋}
    • --dry-run 없이 같은 명령을 실행하면 오프셋이 완전히 리셋되니 주의해야된다.
  • 오프셋 가져오기
    • 설명: 앞에서 설명한 내보내기 작업에서 생성된 파일을 가져와서 컨슈머그룹의 현재 오프셋을 설정하는 데 사용한다.
      • 이 기능은 대체로 현새 컨슈머 그룹의 오프셋을 내보낸 뒤, 백업을 하기 위한 복사본을 만들어 놓고, 오프셋을 원하는 값으로 바꿔서 사용하는 식으로 운용한다.
    • 오프셋 가져오기를 하기 전에 컨슈머 그룹에 속한 모든 컨슈머를 중단시키는 것이 중요하다.
      • 이유: 컨슈머 그룹이 현재 돌아가고 있는 상태에서 새 오프셋을 넣어 준다고 해서 컨슈머가 새 오프셋 값을 읽어오지는 않기 때문이다. 이 경우 컨슈머는 그냥 새 오프셋들을 덮어써 버린다.

동적 설정 변경

  • kafka-configs.sh로 토픽, 클라이언트, 브로커 등 많은 설정이 클러스터를 끄거나 재설치할 필요없이 돌아가는 와중이 동적으로 바꿀 수 있는 설정이 많다.
  • 현재 동적으로 변경이 가능한 설정의 범주는 4가지가 잇다.
    • 토픽, 브로커, 사용자, 클라이언트
  • 이러한 설정 작업을 자동화하기 위해 관리하고자 하는 설정을 밀 ㅣ형식에 맞춰 담아 놓은 파일과 --add-config-file인자를 사용할 수 있다.

토픽 설정 기본값 재정의하기

  • 토픽 설정을 변경하기 위한 명령 형식은 다음과 같다.
    • bin/kafka-configs.sh --botstrap-server localhost:9092 --alter --entity-type topics --entity-name {토픽 이름} --add-config {key}={value}[, {key}={value}...]

클라이언트와 사용자 설정 기본값 재정의하기

  • 카프카 클라이언트와 사용자의 경우, 재정의 가능한 설정은 쿼터에 관련된 것 몇 개밖에 없다.
  • 가장 일반적인 설정 두 개은 특정 클라이언트 ID에 대해 브로커별로 설정되는 프로듀서와 컨슈머 bytes/sec 속도다.

브로커 설정 기본값 재정의하기

  • 동적으로 재정의 가능한 브로커 설정은 80개가 넘는다.
  • 특별히 짚어볼 중요한 설정은 다음과 같다.
    • min.insync.replicas: 프로듀서의 acks 설정값이 all로 잡혀 있을 때 쓰기 요청에 응답이 가기 전에 쓰기가 이루어져야 하는 레플리카 수의 최소값을 결정한다.
    • unclean.leader.election.enable: 리더로 선출되었을 경우 데이터 유실이 발생하는 레플리카를 리더로 선출할 수 있게 한다. 약간의 데이터 유실이 허용되는 경우 혹은 데이터 유실을 피할 수 없어서 카프카 클러스터의설정을 잠깐 풀어주거나 해야 할 때 유용하다.
    • max.connections: 브로커에 연결할 수 있는 최대 연결 수. 좀 더 정밀한 스로틀링 바란다면 max.connections.per.ip.max.connections.per.ip.overrides를 사용할 수 있다.

재정의된 설정 상세 조회하기

  • 다른 툴들과 마찬가지로 --describe 명령을 사용하면 된다.
  • 이 툴은 재정의된 설정값을 보여줄 뿐, 클러스터 기본값을 따르는 설정은 포함하지 않는다.

재정의된 설정 삭제하기

  • 재정의된 설정을 삭제하려면 --delete-config 매개변수와 함께 --alter 명령을 사용한다.

쓰기 작업과 읽기 작업

  • 수동으로메시지를 쓰거나 샘플 메시지를 읽어와야 하는 경우, kafka-console-consumer.sh와 kafka-console-producer.sh를 사용할 수 있다.
    • 이 툴들은 자바 클라이언트 라이브러리를 살짝 감싸는 형태로 구현되었으며, 해당 작업을 수행하는 애플리케이션 전첼르 작성할 필요 없이 카프카 토픽과 상호작용할 수 있도록 해 준다.

콘솔 프로듀서

  • 메시지는 줄 단위로, 키와 밸류값은 탭 문자를 기준으로 구분된다.(탭 문자가 없으면 키값은 null이 된다)
  • 콘솔 프로듀서는 기본 시리얼라이저를 사용해서 읽어들인 데이터를 바이트 뭉치로 변환한다.
  • 콘솔 프로듀서를 사용할 떄는 어느 카프카 클러스터에 연결할지, 그 클러스터의 어느 토픽에 쓸지를 정의하는 인수 두 개를 반드시 지정해주어야 한다.
  • 쓰기 작업이 끝났다면 end-of-file(EOF) 문자를 입력해서 클라이언트를 종료시키자. 대부분의 터미널에서는 Ctrl + D로 가능하다.
  • 프로듀서 설정 옵션 사용하기
    • 프로듀서를 설정할 때 사용하는 설정을 콘솔 프로듀서에 전달하는 방법은 2가지다.
      • 방법1: --producer.config {설정파일}을 지정하는 방법
      • 방법2: 명령줄에서 1개 이상의 --producer-property {키}={값} 인수를 지정하는 방법
    • 대표적인 설정
      • --batch-size: (비동기 모드로 작동 중일 때) 하나의 배치로 전달되어야 할 메시지의 수를 지정한다.
      • --timeout: (비동기 모드로 작동 중일 때) 메시지 배치를 쓰기전에 기다리는 최대 시간을 지정ㅎㄴ다.
      • --compression-codec {압축 코덱}: 메시지를 쓸 때 사용할 압축 코덱을 지정한다. none, gzip(기본값), snappy, zstd, lz4 중 하나를 사용할 수 있다.
      • --sync: 메시지를 동기적으로 쓴다.
  • 읽기 옵션
    • 표준 입력으로 들어온 값을 읽어서 프로듀서 레코드를 생성하는 LineMessageReader 클래스 역시 옵션을 가지고 있다.
    • 콘솔 프로듀서에 --property 명령줄 옵션을 사용해서 지정 가능하다.
    • 옵션
      • ignore.error: 이 값이 false이고 parse.key가 true인 상태에서 키 구분자가 정의되어 있지 않을 경우 에외가 발생한다. 기본값은 true다.
      • parse.key: 킥값을 항상 null로 고정하고 싶다면 flase로 잡아주면 된다. 기본값은 true다.
      • key.separator: 메시지 키와 밸류를 구분할 때 사용되는 구분자로서 기본값은 탭 문자다.

콘솔 컨슈머

  • 기본적으로 키나 형식 같은 것 없이 메시지 안에 저장된 raw bytes 뭉치가 출력된다.(출력 형식은 DefaultFormatter이 결정한다)

  • 어떤 토픽으로부터 메시지를 읽어올지를 결정하는 옵션은 두 개가 있다.

    • --topic: 읽어올 토픽의 이름을 지정한다(1개).
    • --whitelist: 읽어오고자 하는 모든 토픽 이름과 매치되는 정규식을 지정한다.

  • 콘솔 컨슈머가 일단 시작되면 쉘 이스케이프 명령이 주어지기 전까지 계속해서 메시지를 읽어온다.

  • 컨슈머 설정 옵션 사용하기

    • 설정을 콘솔 컨슈머에게 전달 하는 방법 2가지
      • 방법1: --consumer.config {설정 파일}
      • 방법2: 명령줄에서 1개 이상의 --consumer-property {키}={값} 형태의 인수를 옵션으로 지정
    • 대표적인 옵션
      • --formatter {클래스 이름}: 메시지를 바이트 뭉치에서 문자열로 변환하기 위해 사용될 메시지 포매터 클래스를 지정한다. 기본값은 kafka.tools.DefaultMessageFormatter다.
      • --from-beginning: 지정된 토픽의 가장 오래된 오프셋부터 메시지를 읽어온다.
        • 이를 지정하지 않으면 가장 최근 오프셋부터 읽어온다.
      • --max-messages {정수값}: 종료되기 전에 읽어올 최대 메시지 수
      • --partition {정수값}: 지정된 ID의 파티션에서만 읽어온다.
      • --offset: 읽어오기 시작할 오프셋. earliest로 지정한 경우 맨 처음부터 latest로 지정할 경우 가장 최신값부터 읽어온다.
      • --skip-message-on-error: 메시지에 에러가 있을 경우 실행을 중단한느 게 아니라 그냥 넘억나다. 디버깅할 떄 좋다.

  • 메시지 포매터 옵션: 기본값 외에 사용 가능한 메시지 포매터는 3개다.

    • kafka.tools.LoggingMessageFormatter: 표준 출력이 아니라 로거를 사용해서 메시지를 출력한다. 각 메시지는 INFO 레벨로 출력되며, 타임스탬피, 키, 밸류를 포함한다.
    • kafka.tools.ChecksumMessageFormatter: 메시지의 체크섬만 출력한다.
    • kafka.tools.NoOpMessageFormatter: 메시지를 읽어오되 아무것도 출력하지 않는다.
    • kafka.tools.DefaultMessageFormatter 역시 --property 명령줄 옵션으로 여러 유용한 옵션을 전달할 수 있다.

  • 오프셋 토픽 읽어오기

    • 클러스터의 컨슈머 그룹별로 커밋된 오프셋을 확인해봐야 하는 경우가 있다. 이 때, 콘솔 컨슈머를 사용해서 __consumer_offsets 내부 토픽을 읽어오면 된다.
    • 이 토픽에 저장된 메시지를 열어보고 싶다면 kafka.coordinator.group.GroupMetadatamanager$OffsetsMessageFormatter 포매터 클래스를 사용하자.

파티션 관리

선호 레플리카 선출

  • 사용하는 이유: 자동 리더 밸런싱 기능이 꺼져 있을 경우, 처음 설치했을 때는 잘 균형을 이루던 것이 나중에는 엉망진차이 될 수 있다.
    • 따라서 이 설정을 켠호거나 아니면 크루즈 컨트롤과 같은 다른 오픈소스 툴을 사용해서 언제나 균형을맞추도록 해주는 것이 권장된다.
  • 만약 카프카 클러스터에 균형이 맞지 않을 경우, 선호 레플리카 선출을 실행시킬 수 있다.
    • 이 작업은 클러스터 컨트롤러로 하여금 파티션에 대해 가장 적절한 리더를 고르도록 한다.
    • 이 작업은 kafka-leader-election.sh 유틸리티를 사용해서 실행시킬 수 있다.
  • 클러스터 내 모든 선호 레플리카 선출을 시작하는 명령은 다음과 같다.
  • 특정한 파티션이나 토픽에 대해서만 선출 시작하는 것도 가능하다. --topic 옵션에 토픽 이름을, --partition 옵션에 파티션을 직접 지정해주면 된다.

파티션 레플리카 변경하기

  • 파티션의 레플리카 할당을 수동으로 변경해 줘야 하는 경우
    • 자동으로 리더 레플리카를 분산시켜 주었는데도 브로커간 부하가 불균등할 때
    • 브로커가 내려가서 파티션이 불완전 복제되고 있을 때
    • 새로 추가된 브로커에 파티션을 빠르게 분산시켜주고 싶을 때
    • 토픽의 본제 팩터를 변경해주고 싶을 경우
  • kafka-reassign-partitions.sh 를 사용해서 파티션 레플리카를 변경할 수 있다.
    • 이 툴은 2단계로 나눠서 호출해야된다.
        1. 이동 시킬 파티션 목록을 생성하는 것
        1. 생성된 안을 실행시키는 것
    1. 이동시킬 파티션 목록을 생성하기 위해서는, 우선 토픽 목록을 담은 JSON 객체를 포함하는 파일을 생성해야 된다.
    • topics.json 파일
    • --topics-to-move-json-file 옵션을 사용해서 실행하면 2가지 json 형식의 응답이 나온다.
      • 첫 번째 파일: 어떠한 이유로 재할당 작업을 롤백하고 싶을 때 파티션을 원래 위치로 되돌려 보내는 데 사용할 수 있다.
      • 두 번째 파일: 다음 단계에서 사요ㅗㅇ하는 파일인데, 아직 실해오디지 않은 파티션 이동 안을 나타낸다.
    1. 지정된 파티션 레플리카를 새로운 브로커에 재할당하는 작업을 시작한다.
    • 클러스터 컨트롤러는 일단 각 파티션의 레플리카 목록에 새롱운 레플리카를 추가하는 식으로 재할당 작업을 실행한다. (일시적으로 복제 팩터를 증가시킨다.)
      • 이때부터 새로 추가된 레플리카들은 각 파티션의 현재 리더로부터 모든 기존 메시지들을 복사해 오게 된다.
      • 디스크 안의 파티션 크기에 따라 이 작업은 엄청난 시간이 걸릴 수도 있다.
      • 복제 작업이 완료되면 컨트롤러는 복제 팩터를 원상 복구 시킴으로써 오래 된 레플리카를 레플리카 목록에서 제거한다.
    • --addition: 지정된 재할당 작업이 현재 진행중인 재할당 작업에 추가되도록 해준다. 현재 진행중인 작업들이 방해 없이 수행될 수 있도록 해줄뿐더러 새로 재할당 작업을 실행시키기 위해 기존 작업이 끝날 때까지 기다릴 필요가 없게 해준다.
    • --disable-rack-aware: 랙 인식 기능으로 인해 파티션 이동 안의 결과물이 불가능할 수도 있다. 이 플래그를 사용해서 랙 인식 기능을 끌 수 있다.
    • --throttle: 파티션 재할당은 일정하게 유지되던 메모리 페이지 캐시 사용량과 네트워크, 디스크I/O를 변화시키는 만큼 클러스터의 성능에 큰 영향을 미친다. 파티션 이동에 스로틀링을 걸어서 이 문제를 방지할 수 있다.
    1. --verify 옵션을 통해서 파티션 이동의 진행 상티를 확인할 수 있다.
  • kafka-reassign-partitions.sh 툴은 파티션의 복제 팩터를 증가시키거나 감소시킬때 사용할 수 있다.
  • 현재 진행중인 파티션 이동을 중단시키고 싶을 경우, --cancel 명령은 재할당 작업이 시작되기 전 레플리카 할당을 복구하도록 구현되어 있다.
    • 만약 작동이 정지된 브로커나 과부하가 걸린 브로커에서 레플리카를 제거하다가 취소할 경우 클러스터가 원하지 않은 상태에 빠질 수도 있다.

로그 세그먼트 덤프 뜨기

  • kafka-dump-log.sh 툴은 파티션의 로그 세그먼트들을 열어볼 때 사용하는 툴이다.
  • 이 툴을 사용하면 토픽을 컨슈머로 읽어올 필요 없이 각각의 메시지를 바로 열어볼 수 있다.
  • 이 툴은 쉼표로 구분된 로그 세그먼트 파일 목록을 인수로 받아서 메시지 요약정보 혹은 상세한 메시지 데이터를 출력한다.

레플리카 검증

  • 클러스터 전체에 걸쳐 토픽 파티션의 레플리카들이 서로 동일하다는 점을 확인하고자한다면 kafka-replica-verification.sh 툴을 사용하면 된다.
  • 이 툴은 주어진 토픽 파티션의 모든 레플리카로부터 메시지를 읽어온 뒤, 모든 레플리카가 해당 메시지를 가지고 있다는점을 확인하고, 주어진 파티션의 최대 랙 값을 출력한다.
  • 레플리카 검증 툴은 파티션 재할당 툴과 마찬가지로 클러스터에 영향을 준다.
    • 레플리카를 검증하기 위해서는 가장 오래된 오프셋에서부터모든 메시지를 읽어와야 하기 떄문이다.

기타 툴

  • kafka-acls.sh 명령줄 툴은 카프카 클라이언트에 대한 접근 제어를 관리하기 위해 사용한다.
  • 경랑화된 kafka-mirror-maker.sh 스크립트를 데이터 미러링용으로 사용할 수 있다.
  • 카프카 버전을 업그레이드하는 과정에서 호환성 문제를 확인하기 위해 사용되는 API 요소들의 서로 다른 버전을 확인하고 싶다면 kafka-breoker-api-versions.sh 툴을 사용한다.
  • 프로듀서와 컨슈머의 성능으 측정하기 위한 trogdor.sh도 있다.

안전하지 않은 작업

클러스터 컨트롤러 이전하기

  • 컨트롤러에는 일반적인 브로커 작업을 수행하는 스레드 외에도 클러스터 작업 전반을 감독하는 특별한 스레드가 하나 있다.
  • 보통 컨트롤러 선출은 주키퍼의 Ephermeral 노드를 사용해서 자동으로 이루어진다.
  • 오작동하고 있는 클러스터나 브로커를 트려블슈팅 중일 경우 컨트롤러 역할을 하는 브로커를 끄는 대신 컨트롤러 역할을 강제로 다른 브로커로 넘겨주는게 유용할 수도 있다.
  • 컨트롤러를 강제로 올기려면 주키퍼의 /admin/controller 노드를 수동으로 삭제해주면 된다.
    • 그러면 기존에 컨트롤러 역할을 맡고 있던 브로커는 컨트롤러 역할을 잃고 클러스터 안의 브로커 중 하나가 랜덤하게 새 컨트롤러가 될 것이다.

삭제될 토픽 제거하기

  • 카프카에 토픽 삭제 요청을 보내면, 해당 토픽의 모든 레플리카가 삭제되고 삭제가 완료되었다는 알림이 오면 관련 정보를 담고 있는 주키퍼 노드는 삭제된다.
  • 정상적인 상황에서는 이 작업이 매우 빠르게 실행되지만, 다음과 같은 경우에 삭제 요청이 멈출 수 있다.
      1. 요청을 하는 프로세스 입장에서 클러스터에 토픽 삭제 기능이 켜져 있는지 알 길이 없다. 따라서 삭제 기능이 꺼져 있는 클러스터의 토픽을 삭제하려고 한다.
      1. 굉장히 큰 토픽에 대한 삭제 요청이 들어왔는데, 요청이 처리되기 전에 1개 이상의 레플리카가 하드웨어 문제로 오프라인 상태가 되어서 삭제 작업이 완료되지 못한다. 따라서 컨트롤러 역시 삭제 작업이 성공했다는 응답을 보내지 못한다.
  • 이러한 멈춤 상태에서 빠져나오고 싶다면, 주키퍼에서 /admin/delete_topic/{topic} 노드를 지운다.
    • 이 주키퍼 노드를 삭제하면, 아직 완료되지 않은 삭제 요청이 삭젠된다.
    • 만약 삭제 요청이 컨트롤러에 캐시되었다가 다시 올라온다면, 주키퍼에서 노드를 지운 직후 앞에서 살펴본 것과 같이 컨트롤러 역할을 강제로 옮겨줌으로써 컨트롤러에 캐시된 요청이남지 않도록 해줘야 할 것 이다.

수동으로 토픽 삭제하기

  • 토픽 삭제 기능이 꺼져 있는 클러스터를 운영중이거나 뭔가 일반적이지 않은 상황에서 토픽을 삭제해야 하는 경우, 수동으로 클러스터에 삭제하는 것이 가능하다.
  • 클러스터 안의 브로커가 하나라도 작동 중인 상태에서는 불가능하기 때문에 클러스터 안의 브로커 전체를 다 내려야 한다.
  • 수동 토픽 삭제 과정
      1. 클러스터의 모든 브로커를 내린다.
      1. 주키퍼의 카프카 클러스터 설정 노드 아래에서 /brokers/topics/{topic}을 삭제한다. 자식 노드를 먼저 삭제해야 한다는 점에서 주의
      1. 각 브로커의 로그 디렉토리에서 토픽에 해당하는 파티션의 디렉토리를 삭제한다. {topic}-{int} 형식으로 되어있다.
      1. 모든 브로커를 재시작한다.