카프카 운영 가이드

1. 필수 카프카 명령어

카프카에서 기본적으로 제공해주는 명령어들이 있으며, 해당 명령어의 리스트는 설치 경로의 bin 디렉토리에서 확인할 수 있다.

토픽 생성

토픽을 생성하기 위해 카프카에서 제공해주는 명령어는 kafka-topics.sh 이다. 토픽을 생성할 때, 줄 수 있는 추가적인 옵션은 아래와 같다.
- –zookeeper : 주키퍼 정보를 입력한다.
- –replication-factor : 리플리케이션 팩터 수
- –partitions : 파티션 수
- –topic : 토픽 이름을 입력
- –create

kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 3 --topic {토픽 이름}

토픽 리스트 확인

kafka-topics.sh 명령어를 통해서 카프카 클러스터에 생성된 토픽 리스트를 확인할 수 있다. 추가 옵션은 아래와 같다.
- –zookeeper : 주키퍼 정보를 입력한다.
- –list

토픽 상세 보기

kafka-topics.sh 명령어를 통해서 토픽의 대한 상세 구성 정보를 확인할 수 있다. 추가적인 옵션은 아래와 같아.
- –zookeeper : 주키퍼 정보를 입력한다.
- –topics : 상세 정보를 알고 싶은 토픽 이름을 입력
- –describe
토픽 이름, 파티션 수, 리플리케이션 팩터 수에 대한 정보를 보여준다. 또한 각 파티션 별로 리더 브로커, ISR 등에 대한 정보를 보여준다.

토픽 설정 변경

kafka-configs.sh 명령어를 통해서 토픽의 설정을 추가하거나, 삭제할 수 있다. 토픽 설정을 추가하려면 아래와 같은 옵션을 추가적으로 주면 된다.
- –zookeeper : 주키퍼 정보를 입력한다.
- –alter
- –entity-type : 토픽 설정을 변경하려는 경우는 topics를 추가
- –entity-name : 설정을 변경하려는 토픽의 이름을 추가
- –add-config : 추가하려는 설정을 key=value 형식으로 추가
만약에 토픽의 추가 옵션을 삭제하고 싶은 경우에는 –add-config 대신 –delete-config를 추가하고, 삭제할 옵션을 입력

토픽의 파티션 수 변경

한 가지 주의할 점을 꼽자면, 카프카에서는 토픽의 파티션 수는 증가만 가능하고, 감소는 불가능하다.
처음 토픽을 생성할 때 파티션 수를 처리량에 대해 미리 확인한 후 신중하게 결정해 적용해야한다.
토픽의 파티션 수를 변경하기 위한 명령어는 kafka-topics.sh이다. 추가 옵션은 아래와 같다.
- –zookeeper : 주키퍼 정보를 추가한다.
- –alter
- –topic : 옵션을 변경하려는 토픽의 이름
- –partitions : 늘려주고 싶은 파티션 수를 입력

키를 이용해 메시지를 전송하고 가져오는 형태로 운영하고 있다면, 파티션 수를 변경할 때 주의해야 한다.

토픽의 리플리케이션 팩터 변경

리플리케이션 팩터를 변경하려면 json 형식의 파일을 만들어야한다.

{
    "version": 1,
    "partitions" : [
        { "topic": "peter-topic", "partition": 0, "replicas": [1, 2] },
        { "topic": "peter-topic", "partition": 1, "replicas": [2, 3] }
    ]
}

위의 json 파일의 내용을 보면 peter-topic의 0번 파티션의 replicas는 [1, 2]로 되어있다. 즉 파티션 0의 복제 수는 2이며, 앞에 있는 숫자가 리더를 의미하기 때문에 리더는 브로커 1이고, 리플리카는 브로커 2라는 의미이다.

주의해야 할 점은, replicas의 첫번째 숫자를 현재 상태의 토픽 파티션 정보를 확인한 후 각 파티션의 현재 리더 정보와 일치하도록 설정해 파티션의 리더가 변경되지 않게 해야 한다. 리더가 변경되지 않기 때문에 토픽의 리플리케이션 팩터를 변경해도 프로듀서와 컨슈머에 영향을 주지 않는다.

컨슈머 그룹 리스트 확인

카프카 토픽 기반의 뉴 컨슈머 그룹을 확인하려면 추가 옵션으로 –bootstrap-server와 브로커 리스트를 입력해야 한다. 컨슈머 그룹 리스트를 보기 위한 명령어는 kafka-consumer-groups.sh이며, 추가 옵션으로는 아래와 같다.
- –bootstrap-server : 브로커 리스트를 입력한다.
- –list

컨슈머 그룹 상태와 오프셋 확인

kafka-consumer-groups.sh 명령어를 사용하면 컨슈머 그룹 현재 상태를 확인할 수 있다. 추가 옵션은 아래와 같다.
- –bootstrap-server : 브로커 리스트를 입력
- –group : 컨슈머 그룹 입력
- –describe
위 명령어를 통해 현재 활성화된 멤버의 정보, 현재 오프셋, 마지막 오프셋, LAG 정보 등을 확인할 수 있다.

LAG은 현재 토픽의 저장된 메시지와 컨슈머가 가져간 메시지의 차이를 뜻한다. LAG 숫자가 높다는 것은 해당 토픽 또는 컨슈머가 읽어가지 못한 메시지가 많이 있다는 의미이다. 따라서 만약 LAG이 계속 증가하는 상황이라면 컨슈머 처리가 늦어지고 있는 것이기 때문에 컨슈머나 파티션 수를 늘려서 대응을 해야 하며, 특정 파티션에만 LAG가 증가한다면 해당 파티션에 연결된 컨슈머에 이상이 없는지를 확인해야 한다.

2. 주키퍼 스케일 아웃

3대로 주키퍼 클러스터를 구성한 경우 과반수 법칙에 따라 최대 1대의 노드 장애까지는 지속적인 서비스가 가능하다. 5대로 구성하는 경우에는 최대 2대의 노드 장애까지 지속적인 서비스가 가능하다.
사용량이 적은 상태에서는 5대로 운영하는 것보다는 최초 3대로 운영하다가 요청수가 늘어나는 경우 추가 증설하는 방법을 추천한다.
새로운 노드를 추가하는 경우, 기존에 구성된 주키퍼 서버에 추가된 서버 정보를 zoo.cfg에 추가하고 난 다음, 적용을 위해 주키퍼 1대씩 재시작하는 작업을 진행해야 한다. 재시작 작업에 별다른 순서가 있는것은 아니지만, 리더가 변경되면서 문제가 발생할 수도 있기 때문에, 주키퍼 앙상블의 리더는 가장 마지막에 작업하는 것을 권장한다.
zkServer.sh status 명령어를 통해 현재 주키퍼가 리더인지 팔로워인지 알 수 있다.
- Mode: follower => 팔로워
- Mode: leader => 리더
재시작 이후에는 현재 주키퍼 앙상블이 잘 동작하고 있는지 확인해야 한다. 앙상블이 잘 동작하고 있다는 것은 리더와 팔로워들이 동기화가 잘 진행되고 있다는 의미이다. 리더를 찾아 아래의 명령어를 실행하면 리더와 팔로워가 동기화를 잘 하고 있는지 알 수 있다
- echo mntr | nc localhost 2181 | grep zk_synced_followers
- 만약 클러스터가 5대로 구성되어 있다면, 위 명령어의 실행 결과가 4(팔로워 수)가 나와야 한다.

3. 카프카 스케일 아웃

카프카를 스케일 아웃하는 방법은, 새롭게 추가하는 서버의 카프카 설정 파일에서 broker.id 부분만 다른 서버와 겹치지 않게 추가한 후 실행하면 카프카 클러스터에 간단하게 추가된다.
클러스터에 브로커가 새로 추가되어도 파티션 재배치는 자동으로 하지 않기 때문에 추가된 브로커에는 토픽과 파티션이 없는 상태가 된다. 새로 추가한 브로커에도 리소스를 분산시키기 위해서는 파티션 분산 작업을 해야 한다.

{
	"version": 1,
    "partitions": [
        {"topic": "peter5", "partition":0, "replicas":[2, 1]},
        {"topic": "peter5", "partition":1, "replicas":[3, 2]},
        {"topic": "peter5", "partition":2, "replicas":[4, 3]},
        {"topic": "peter5", "partition":3, "replicas":[5, 4]},
        {"topic": "peter5", "partition":4, "replicas":[1, 5]}
    ]
}

파티션 분산 작업을 위한 명령어는 kafka-reassign-partitions.sh이며, 추가하는 옵션으로 –zookeeper 옵션에 주키퍼 정보를 추가하고, –reassignment-json-file 옵션에 미리 만들어둔 json 형식의 파일 경로와 파일명을 입력한 다음, –execute를 실해하면 된다.
신규 브로커를 추가한 후 토픽이 파티션을 분산시키는 작업을 해주어야만 새로운 브로커도 같은 클러스터로서 역할을 할 수 있게 된다.

토픽의 데이터사이즈가 큰 경우 파티션을 분산시키는 작업이 브로커에 무리를 줄 수도 있다. 파티션 분산 작업을 안전하게 하려면 첫 번째, 토픽의 사용량이 가장 적은 시간에 수행하는 방법을 추천하고, 두 번째로는 토픽의 보관 주기를 줄여서 임시로 사이즈를 축소시킨 후 작업하는 방법을 추천한다.

4. 카프카 매니저

카프카 운영 툴인 카프카 매니저는 야후에서 오픈 소스로 공개했다. 카프카 매니저는 운영과 관련된 많은 기능과 클러스터의 상태를 한눈에 알아볼 수 있어서 카프카 운영자들에게 매우 인기가 높은 툴이다.
카프카 매니저에서 클러스터를 등록할 때, Enable JMX Polling 항목을 체크하면 카프카 매니저를 이용해 현재 클러스터의 메시지 유입 상태 등의 추가 정보를 확인할 수 있다.
카프카 매니저를 통해 브로커의 현재 상태, 토픽 생성, 전체 토픽 리스트 확인 등의 작업을 할 수 있다. 그외에도 아래와 같은 작업을 할 수 있다.
- Preferred Replica Election : 브로커 다운이 발생하거나 브로커 점검 등으로 인해 파티션의 리더가 변경될 수 있다. 장애가 발생한 브로커가 정상화 되고 난 후 수동으로 파티션의 리더를 원복할 수 있다.
- Reassign Partitions : 토픽의 파티션 변경 작업을 할 때 사용하는 메뉴이다.
- Consumers : 컨슈머 리스트을 확인할 수 있다.

5. 카프카 운영에 대한 Q&A

Q : 디스크 사용량이 높아요!
A : log.retention.hour 옵션을 줄이는 방법을 추천한다.
Q : 디스크를 추가하려면 어떻게 해야 하나요?
A : 브로커 옵션 설정에서 log.dirs 옵션에 추가된 디스크 경로를 추가한 후 브로커를 재시작하면 된다.
Q : OS 점검을 하려면 어떻게 해야 하나요?
A : 클러스터에서 브로커 1대를 제외한 후 OS 점검을 진행하면 된다. 이 때 리더가 변경되면서 일부 커넥션 에러 등은 발생할 수 있다.
Q : 주키퍼 앙상블 상태 정보를 확인하고 싶은데 어떻게 해야 하나요?
A : mntr을 이용하면 주키퍼 앙상블의 현재 상태 정보등을 확인할 수 있다. 자세한 내용은 주키퍼 문서를 참고하길 바란다.
Q : 주키퍼 앙상블 전체의 상태정보를 볼 수 있는 간단한 툴은 없나요?
A : zktop이라는 툴을 사용하면 된다. CLI 상태에서 한눈에 주키퍼 앙상블 상태를 확인할 수 있다.
Q : 카프카 버전 업그레이드는 어떻게 하나요?
A : 한 대씩 내렸다가 올리는 롤링 업그레이드 방식이 있다.
Q : 롤링 업그레이드는 어떻게 하나요?
A : 브로커 한 대씩 새 버전을 설치한 후 카프카 환경설정 파일인 server.properties에 다음과 같은 코드 두 줄을 추가한 후 재시작한다. 더욱 자세한 내용은 아파치 도큐먼트의 업그레이드 부분을 참고하길 바란다.

inter.broker.protocol.version=현재 카프카 버전
log.message.format.version=현재 카프카 버전

Q : 카프카 버전 업그레이드할 때 주의해야 할 사항은 없나요?
A : 릴리즈 노트를 확인해 기존 버전의 환경설정 값이 변경되는 경우가 있는지 확인한다. 또한 업그레이드 이후 메시지 전송과 수신 또는 연결 등의 문제가 발생할 수 있으니, 클라이언트 버전 호환성도 체크하는 것이 좋다.
Q : 카프카 버전을 업그레이드할 때 주키퍼도 함께 버전 업그레이드를 해야 하나요?
A : 안해도 된다.
Q : 보통 자바 힙 사이즈는 물리 메모리의 절반 정도로 잡는데, 카프카는 어떻게 설정하는 것이 좋나요?
A : 카프카의 경우 힙 사이즈는 5~6GB 정도로만 설정하고 남아 있는 메모리는 페이지 캐시로 사용하기를 권장한다.