카프카 핵심가이드 -2

2. 카프카 설치와 구성하기

1) 제일 먼저 할일

- jdk 8이상을 다운로드 하고, 주키퍼를 설치한다. 주키퍼는 카프카 배포판에 포함되어 있어서 따로 설치할 필요는 없지만 별도로 설치해도 무방하다. 

 

* 주키퍼란?

- 주키퍼는 분산환경의 코디네이터 역할을 수행한다.

- 카프카 관련해서는 메타데이터를 통합 관리해준다. 

- 주키퍼는 보통 클러스터로 구성되는데 3개 또는 5개가 적당하다. (하나가 장애가 나도 남은 2개로 active - standby가 성립되기 때문)

- 카프카의 리더 선출을 결정한다. 

 

2) 카프카 브로커 설치하기

- WSL 을 이용하는 방법

- Docker을 이용하는 방법

- 우분투에 그냥 설치하는 방법

 

3) 브로커 구성

- /usr/local/kafka/config/server.properties 에서 브로커 설정을 변경가능하다. 

- 아래 적는 내용은 모두 설정파일에 줄 수 있는 옵션과 그 설명이다.

초기설정 파일 (주석은 제거했다)

log.retention.check.interval.ms=300000

############################# Zookeeper #############################

zookeeper.connect=localhost:2181
zookeeper.connection.timeout.ms=6000

############################# Group Coordinator Settings #############################

group.initial.rebalance.delay.ms=0

 

< 핵심구성옵션 >

1. broker.id
 - 모든 카프카 브로커가 가져야하는 식별자값
 - 기본값은 0이지만 어떤 값도 가능
 - 하나의 카프카 클러스터 내에서는 고유한 값이어야한다.
 - 번호는 임의 선택 가능. 유지보수 작업중에 브로커 간에 숫자 바꾸는 것도 가능. 그러나 숫자바꾸는건 궈장하지 않음.

 

2. port
 - 카프카의 실행에 사용되는 tcp 포트
 - 기본값은 9092
 - 어떤 포트번호로도 설정가능하지만 1024보다 작은 값으로 설정한다면 카프카가 root 권한으로 시작되어야하기에 바람직하지 않다.

 

3. zookeeper.connect
- 브로커의 메타데이터를 저장하기 위한 주키퍼의 위치
- 기본값은 localhost:2181/

- [호스트이름:포트/경로] 의 형식으로 입력하면 된다. 여기서 경로는 일반적으로 chroot 경로를 사용한다.

4. log.dirs
- 카프카는 모든 메시지를 로그 세그먼트 파일에 모아서 디스크에 저장한다. 
- 여러 경로를 쉼표로 구분하여 지정가능
  > 두개이상의 경로가 지정되면 해당 브로커가 모든 경로에 파티션을 저장한다.

  > 사용빈도가 가장 적은 데이터를 교체하는 방식으로 한 파티션의 모든 로그 세그먼트를 같은 경로에 저장.
  > 브로커가 새로운 파티션을 저장할때는 가장 적은 디스크 용량을 사용하는 경로가 아닌, 가장 적은 수의 파티션을 저장한 경로를 사용한다.

 

5. num.recovery.threads.per.data.dir
- 카프카는 스레드 풀을 사용해서 로그 세그먼트를 처리한다.

- 기본적으로 로그 디렉토리당 하나의 스레드만 사용한다.

- 스레드들은 브로커의 시작과 종료시에만 사용되기 때문에 병행처리를 하도록 가능한 많은 수의 스레드를 설정하는 것이 좋다.

- log.dirs에 지정된 로그 디렉토리마다 적용된다.

 

[ 스레드 풀을 사용하는 경우 ]
1) 브로커가 정상적으로 시작될때 : 각 파티션의 로그 세그먼트 파일을 열기 위해 사용
2) 장애 발생이후 다시 시작될 때 : 각 파티션의 로그 세그먼트를 검사하고 불필요한 부분을 삭제하기 위해 사용
3) 종료될때 : 로그 세그먼트 파일을 정상적으로 닫기 위해 사용

6. auto.create.topics.enable
- 기본값은 true
- 다음의 경우, 브로커는 자동으로 토픽을 생성한다.
1) 프로듀서가 토픽에 메시지를 쓸때
2) 컨슈머가 토픽의 메시지를 읽기 시작할때
3) 클라이언트에서 토픽의 메타데이터를 요청할때

< 토픽의 기본설정>

1. per.topic 매개변수 사용
- 이전 버전의 카프카에서는 브로커 구성파일에서 토픽당 로그 보유시간, 토픽당 로그 보유 바이트, 토픽당 로그 보유 세그먼트 등을 토픽에 지정가능햇다. 그러나 지금은 (kafka 2.0) 그렇게 할 수 없으며, 관리도구를 사용해야한다.

 

2. num.partitions
- 새로운 토픽이 몇개의 파티션으로 생성되는지를 지정 (기본값 = 1)
- 자동 토픽생성이 활성화 될때(auto.create.topics.enable=true) 사용된다. 
- 파티션은 증가시킬수 있지만 감소시킬수는 없다.
- 토픽의 크기가 확장되는 방법이 파티션 -> 브로커가 추가될때 클러스터 전체에 걸쳐 메시지가 고르게 저장되도록 파티션 개수를 설정하는 것이 중요하다. 
  > 클러스터의 브로커수와 같게하거나 배수로 토픽의 파티션 개수를 설정한다. -> 이렇게하면 브로커마다 파티션이 고르게 분산될 수 있고, 저장메시지도 고르게 분산될것이다.

 

[ 파티션 개수 산정시 고려할점 ]
1) 단위 시간당 토픽의 데이터 처리량은? 예를들어, 초당 100KB 또는 1GB를 예상하는가?
2) 한 파티션의 데이터를 읽을때 목표로하는 최대 처리량은? 파티션 하나는 항상 한 컨슈머가 소비한다.
3) 하나의 파티션에 데이터를 생성하는 프로듀서당 최대 처리량도 컨슈머와 같은 방법으로 산정할 수 있다. 그러나 대개 프로듀서는 컨슈머보다 훨씬 빠르게 처리되므로 처리량을 조사하지 않아도 무방하다.
4) 키를 사용해서 파티션에 메시지를 쓰는 경우에는 향후에 파티션을 추가할때 개수 산정이 어려울 수 있다. 따라서 현재보다는 향후에 예상되는 사용방법을 기준으로 처리량을 추산하자.
5) 브로커마다 파티션 개수와 디스크 용량및 네트워크 처리속도를 고려하자.
6) 파티션 개수를 너무 많이고려하지 말자. 왜냐하면 각 파티션은 브로커의 메모리와 그 외 다른 자원을 사용하므로 리더 선정에 더 많은 시간이 소요되기 때문.
7) 위 모든 것을 고려해 파티션 개수를 너무많이 산정하지 말자. 초당 1Gb로 토픽을 읽고 쓰기 원하는데 각 컨슈머가 초당 50MB만 처리할수 있다면 (DB쓰기관련 이슈로 인해) 최소한 20개(1000/50) 의 파티션이 필요하다. 자세한 정보가 없다면 파티션 크기를 하루에 6GB미만으로 제한할것을 권한다. (왜?)

=> 결론 : 파티션 개수 나중에 바꾸려면 생각해야될게 많을 수 있으니까 처음 정할때 잘 정해야 되는데 더도 덜도 말고 컨슈머가 견딜만한 정도의 양이 한 파티션에 배정될 정도의 개수로 나눌것! (그래서 그게 몇개냐고... ㅋㅋㅋㅋㅋ)

 

 

3. log.retention.ms

- 메시지 보존 기간 설정 

- 보통 log.retention.hours로 설정하는데 이 경우, log.retention.ms 나 log.retion.minutes를 적게되면 그 값으로 오버라이딩 되니까 그냥 log.retention.ms를 쓰는 것을 권장함

4. log.retention.bytes
- 저장된 메시지들의 전체 크기를 기준으로 만기 처리
- 이 값은 모든 파티션에 적용된다.
- log.retention.ms , log.retention.bytes 둘다 설정할 경우 둘중 하나의 조건이 충족될 때 메시지가 삭제된다.

 

5. log.segement.bytes
- 앞의 메시지 보존설정은 개별 메시지가 아닌 로그 세그먼트 파일을 대상으로 처리된다.
- 메시지가 카프카 브로커에 생성될 때는 해당 파티션의 로그 세그먼트 파일끝에 추가된다. 
- 이때 log.segment.bytes 매개변수에 지정된 크기 (기본값은 1GB)가 되면 해당 로그 세그먼트 파일이 닫히고 새로운 것이 생성되어 열린다. 그리고 닫힌 로그 세그먼트 파일은 만기가 된것으로 간주한다. 따라서 로그 세그먼트의 크기를 더 작은 값으로 지정하면 더 빈번하게 파일이 닫히고 새로 생성되므로 전반적인 디스크 쓰기 효율이 감소된다.
- 만일 토픽의 데이터 저장률이 낮다면 로그 세그먼트의 크기를 조정하는 것이 중요하다. 예를 들어 하루에 100MB의 메시지만 토픽에 수록되고 log.segment.bytes의 값이 기본값으로 1GB인 경우, 하나의 로그 세그먼트를 채우는데 10일이 소요된다. 그러나 로그 세그먼트 파일은 닫혀야만 만기가 될 수 있으므로 만일 log.retention.ms가 1주일로 설정되어 있다면 로그 세그먼트에 저장된 메시지들은 17일동안 보존될것이다. 왜냐하면 마지막 메시지를 스면서 로그 세그먼트파일이 닫히는데 10일이 소요되고, 다시 보존기간인 7일이 지나야 만기가 되기 때문 (아, 마지막 로그 기준으로 만기일이 산정되는군!)
- 특정 타임스탬프 시간으로 파티션의 오프셋을 요청할 수 있는데 이경우에도 log.segment.bytes가 관여된다. 특정 시간에 해당하는 로그 세그먼트 파일을 찾기 때문. 지정된 타임스탬프 이전에 생성되고 마지막 수정시간이 해당 타임스탬프 이후인 로그 세그먼트 파일을 찾는다. 그리고 찾은 로그 세그먼트파일의 시작 오프셋과 파일 이름을 반환한다.

 

6. log.segment.ms
- 지정된 시간이 되면 로그 세그먼트 파일을 닫는다. 위의 log.segment.bytes 와 대응된다. 
- 기본적으로 이 속성은 설정되있지 않기때문에 로그 세그먼트 크기 제한으로만 닫히게 된다.
- 디스크 성능이 안좋으면 이 속성은 피하자. 다수의 로그 세그먼트가 동시에 닫히는 것에 의해 디스크 성능에 영향을 끼칠수 있기 때문.

7. message.max.bytes

- 브로커가 감당할 수 있는 하나의 메세지의 최대크기. 기본값은 1000000 (1mb)

- 프로듀서가 이 값보다 큰 메시지를 보내는 경우 프로듀서에 에러를 날린다. 당연히 컨슈머에도 이 값보다 큰 메세지를 보내지는 않는다. 만약 압축을 풀어서 보내려는데 이 값보다 커진다?? 압축해서 보내야함.

- 기본값이 클수록 네트워크 비용, 요청당 작업시간, 처리량 문제가 생기기 때문에 성능 튜닝시 고려할 요소중 하나다.