My data lab

• 컨트롤러 선정
• 브로커 메타 데이터
• 토픽 메타데이터
• 클라이언트 할당^quota 정보

컨트롤러 선정

컨트롤러 - 파티션 관리를 책임지는 브로커로 파티션 관리 범위는 아래와 같다.

• 리더 선정
• 토픽 생성
• 파티션 생성
• 복제본 관리

하나의 노드 또는 서버가 꺼지면 컨트롤러는 팔로워 중에서 파티션 리더를 선정한다.

카프카는 컨트롤러를 선정하기 위해 주키퍼의 메타데이터 정보를 활용한다.

주키퍼는 현재의 컨트롤러에 장애가 나면 새로운 컨트롤러가 선정되는 것을 보장한다.

브로커 메타데이터

주키퍼는 카프카 클러스터의 일부인 각 브로커에 대해 상태정보를 기록한다. 클러스터 내에서 각 브로커의 모든 메타데이터를 기록한다.

프로듀서와 컨슈머는 주키퍼와의 상호 작용으로 브로커의 상태 정보를 얻는다.

토픽 메타 데이터

주키퍼는 파티션수, 특정한 설정 파라미터 등의 토픽 메타데이터를 기록한다.

클라이언트 할당 정보

할당량은 카프카 토픽의 메시지를 읽고 쓰는 클라이언트에 대한 바이트 비율의 임계 값을 제한하며, 모든 정보와 상태는 주키퍼가 관리한다.

카프카 토픽 ACLs

카프카는 내장된 인증모듈(ACL, Access Control List)을 가지고 있다.

이러한 ACLs는 사용자 역할과 관련된 토픽에 대해 읽기와 쓰기 권한 종류를 결정한다. 카프카는 ACLs를 저장하는데 주키퍼를 사용한다.

파티션 규칙(default partitioner)

• key가 있는경우 :  key를 hash하여 특정 파티션으로 보냄. 키와 파티션간의 mapping은 topic의 파티션 개수가 변경되지 않는경우 유지됨.
• key가 없는 경우 : 임의로 사용가능한 파티션으로 보낸다. 파티션간의 균형을 맞추는데는 Round Robin 알고리즘을 사용

파티션 개수의 산정방법

파티션 개수를 산정할 때 고려할 점은 다음과 같다

• 단위시간당 토픽의 처리량(throughput). 예를 들어, 초당 100KB 또는 1GB를 예상 하는가?
• 한 파티션의 데이터를 읽을 때 목표로 하는 최대 처리량은? 파티션 하나는 항상 한 컨슈머가 소비한다._{(컨슈머 그룹을 사용하지 않을 때도 컨슈머는 항상 해당 파티션의 모든 메시지를 읽어야 하기 때문)}  따라서 처리 속도가 느린 컨슈머가 피티션을 읽어서 그 데이터를 데이터베이스에 쓸 때 데이터를 쓰는 스레드마다 초당 50MB 까지만 처리할 수 있다면 파티션을 소비하는 최대 처리량이 초당 50MB로 제한 된는것을 염두해야 한다.
• 하나의 파티션에 데이터를 생성하는 프로듀서당 최대 처리량도 컨슈머와 같은 방법으로 산정할 수 있다. 그러나 대개 프로듀서는 컨슈머보다 훨씬 빠르게 처리되므로 처리량을 조사하지 않아도 무방.
• 키^key를 사용해서 파티션에 메시지를 쓰는 경우에는 향후에 파티션을 추가할 때 개수 산정이 어려울 수 있다. 따라서 현재보다는 향후에 예상되는 사용 방법을 기준으로 처리량을 추산하자.
• 브로커마다 파티션 개수와 디스크 용량 및 네트워크 처리속도를 고려하자.
• 파티션 개수를 너무 많이 고려하지 말자. 각 파티션은 브러커의 메모리와 그 외 다른 자원을 사용하므로 리더선정에 더 많은 시간이 소요되기 때문.

이 모든 것을 고려할 때 파티션 개수를 너무 많이 산정하지 않아야 한다. 토픽의 목표 처리량과 컨슈머의 예상 처리량에 관한 추정치가 있다면, 목표 처리량을 컨슈머 예상 처리량으로 나누는 방법으로 파티션 개수를 산출할 수 있다. 예를 들어 초당 1GB로 토픽을 읽고 쓰기 원하는데 각 컨슈머가 초당 50MB만 처리할 수 있다면 최소한 20개(1000/50)의 파티션이 필요하다는 것을 알 수 있다. 이 경우 20개의 컨슈머가 토픽을 읽으므로 초당 1GB의 목표 처리량을 성취할 수 있다. 그러나 만일 이러한 자세한 정보가 없다면 디스크에 보존하는 파티션 크기를 하루에 6GB미만으로 제한할 것을 권함.

ref: https://stackoverflow.com/questions/40369238/which-directory-does-apache-kafka-store-the-data-in-broker-nodes

ambari 기준으로 kafka 관련된 로그는 2군데에 저장 된다.

log.dirs : 메세지 보관을 위한 오프셋을 포함한 로그이다.

/var/log/kafka : kafka 자체 로그이며 kafka.env 파일에서 설정 할 수 있다.

1. Topic 에 관한 로그 는 아래 정책으로 log.dirs 경로(server.properties 파일에 설정) 에 저장된다.

로그의 잘려진 segment 는 상응하는 index 파일과 같이 저장된다.  그 파일 내임은 Base offset 을 표현하기도 한다.

이것을 설명하자면 log 파일 이저장되는 구조를 이해 해야하는데, 

log 파일은 실제메세지를 strucuted message format 으로 저장한다.  each message 는 처음 64 비트에 증가된 offset 을 포함한다.

그러므로 이파일에서 특정 오프셋의 메세지를 찾는것은 log 파일이 커질 수록 무거워진다.

또한 메세지를 공급하기 위해서는 브로커는 가장 나중의 offset 을 기억하고 메세지를 정확하게 받아들이기 위해 진행 시킨다.

그러므로 로그파일의 offset 기억하기 위해 index 파일이 존재한다. 

index 파일은 아래와 같은 항목을 저장한다.

1. 4 Bytes: Relative Offset
2. 4 Bytes: Physical Position

이때 파일내임은 base offset 을 표현한다. index 파일은 로그파일의 index.interval.bytes 의 단위마다 index 파일을 새로 쓴다.(default 4096)

2. kafka 서버자체의 로그 (INFO / ERROR / WARN 등) 은 kafka_env.sh 안에 로그 경로가 지정되어있다.

주로내용은 자바 info 로 채워지는데 이 또한 시간이 지나면 일주일에1~2G 정도 용량이 찬다.

log4j 설정을 이용해 로그양을 줄일 수 있다.  2번 은 말그대로 log 이다.