Kafka 정리

카프카 브로커, 클러스터, 주키퍼

• 브로커 : 일반적으로 '카프카'라고 불리는 서버를 말하며 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하며 offset 관리 등 중요 역할을 담당
• 클러스터 : 카프카 브로커 서버 1대로도 사용 가능하지만 데이터를 안전하게 보관하고 처리하기 위해 3대 이상의 브로커 서버를 1개로 묵어서 운영하는데 이것이 클러스터이다.
• 주키퍼 : 분산 애플리케이션을 위한 코디네이션 시스템으로 컨슈머 클라이언트와 카프카 클러스터에 관한 메타데이터를 저장한다.

 

데이터 저장, 전송

카프카는 큐시스템으로 프로듀서로부터 데이터를 전달받으면 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 순서대로 저장하고 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 순서대로 전달한다.
프로듀서로부터 전달된 데이터는 파일 시스템에 저장된다.

데이터 전송

 

[config/server.properties]

log.dirs=/kafka/data

[root@server1] cd /kafka/data
[root@server1 data]# ls
__consumer_offsets-0   __consumer_offsets-25  __consumer_offsets-41        meta.properties
__consumer_offsets-1   __consumer_offsets-26  __consumer_offsets-42        recovery-point-offset-checkpoint
__consumer_offsets-10  __consumer_offsets-27  __consumer_offsets-43        replication-offset-checkpoint
__consumer_offsets-11  __consumer_offsets-28  __consumer_offsets-44        test-topic-0
__consumer_offsets-12  __consumer_offsets-29  __consumer_offsets-45        
__consumer_offsets-13  __consumer_offsets-3   __consumer_offsets-46        
__consumer_offsets-14  __consumer_offsets-30  __consumer_offsets-47        
__consumer_offsets-15  __consumer_offsets-31  __consumer_offsets-48        
__consumer_offsets-16  __consumer_offsets-32  __consumer_offsets-49        
__consumer_offsets-17  __consumer_offsets-33  __consumer_offsets-5         
__consumer_offsets-18  __consumer_offsets-34  __consumer_offsets-6         
__consumer_offsets-19  __consumer_offsets-35  __consumer_offsets-7         
__consumer_offsets-2   __consumer_offsets-36  __consumer_offsets-8         
__consumer_offsets-20  __consumer_offsets-37  __consumer_offsets-9         
__consumer_offsets-21  __consumer_offsets-38  cleaner-offset-checkpoint    
__consumer_offsets-22  __consumer_offsets-39  log-start-offset-checkpoint
__consumer_offsets-23  __consumer_offsets-4   
__consumer_offsets-24  __consumer_offsets-40  
[root@server1 data]# cd test-topic-0
[root@server1 test-topic-0]# ls
00000000000000000000.index  00000000000000000000.log  00000000000000000000.timeindex  leader-epoch-checkpoint

• *.index : 메시지의 오프셋을 인덱싱한 정보를 담은 파일
• *.timeindex : 메시지의 포함된 timestamp값을 기준으로 인덱싱한 정보가 담겨져 있다.( * 카프카 0.10.0.0 버전 이후로 메시지에는 timestamp값이 포함된다. timestamp값은 브로커가 적재한 데이터를 삭제하거나 압축하는데 사용 )

카프카는 메모리나 데이터베이스에 저장하지 않아 따로 캐시메모리를 구현하여 사용하지 않는다. 파일 시스템에 저장하기 때문에 파일 입출력으로 인해 속도 이슈가 발생할 수도 있지 않을까란 생각이 들 수도 있지만 카프카에서는 페이지 캐시(page cache)를 사용하여 디스크 입출력 속도를 높여 이 문제를 해결하였다. 

페이지 캐시

OS에서 파일 입출력의 성능 향상을 위해 만들어 놓은 메모리 영역을 뜻한다. 한번 읽은 파일의 내용은 메모리의 페이지 캐시 영역에 저장시켜 동일한 파일의 접근이 일어나면 디스크에서 읽지 않고 메모리에서 직접 읽는 방식이다.

 

데이터 복제, 싱크

데이터 복제(replication)는 카프카를 장애 허용 시스템으로 동작하도록 하는 원동력이다. 복제의 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함이다.

카프카의 데이터 복제는 파티션 단위로 이루어 진다. 토픽을 생성할 때 파티션의 복제 개수(replication factor)도 같이 설정되는데 직접 옵션을 선택하지 않으면 브로커에 설정된 옵션값을 따라간다. 복제 개수의 최소값은 1(복제 없음)이고 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다.

 

• 장점 : 데이터를 안전하게 사용할 수 있다
• 단점 : 복제 개수 만큼의 저장 용량이 증가한다.

 

운영 시에 데이터 종류마다 다른 복제 개수를 설정하여 운영을 하는 경우가 많은데, 데이터가 일부 유실되어도 무관하고 데이터 처리 속도가 중요하다면 1 또는 2로 설정한다.

금융정보와 같이 데이터 유실이 일어나면 안 되는 경우 브로커 갯수로 맞추어 유실을 방지한다.

 

컨트롤러(controller)

클러스터의 다수 브로커 중 한 대가 컨트롤러 역할을 한다. 컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배한다.
카프카는 지속적으로 데이터를 처리해야 하므로 브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요하다. 만약 컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 한다.

 

데이터 삭제

카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않는다. 
또한, 컨슈머나 프로듀서가 데이터 삭제를 요청할 수도 없다. 오직 브로커만이 데이터를 삭제할 수 있다. 데이터 삭제는 파일 단위로 이루어지는데 이 단위를 '로그 세그먼트(log segment)' 라고 부른다.
이 세그먼트에는 다수의 데이터가 들어 있어서 일반적인 데이터베이스처럼 특정 데이터를 선별해서 삭제가 불가능하다. 세그먼트는 데이터가 쌓이는 동안 열려있으며 카프카 브로커에 log.segement.bytes 또는 log.segment.ms 옵션에 값이 설정되면 세그먼트 파일이 닫힌다.

log.segement.bytes 기본값

# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824

기본적으로는 1GB용량에 도달했을 때 닫히며 간격을 줄이고 싶다면 작은 용량으로 설정하면 된다. 그러나 너무 작은 용량으로 설정해 자주 여닫는 경우에는 부하가 발생할 수 있으므로 주의해야 한다.
닫힌 세그먼트 파일은 log.retention.bytes 또는 log.retention.ms 옵션에 설정값이 넘으면 삭제된다. 닫힌 세그먼트 파일을 체크하는 간격은 log.retention.check.interval.ms 에 따른다.

# The minimum age of a log file to be eligible for deletion due to age
log.retention.hours=168 // 7일# A size-based retention policy for logs. Segments are pruned from the log unless the remaining
# segments drop below log.retention.bytes. Functions independently of log.retention.hours.
#log.retention.bytes=1073741824 // 1gb. 해당옵션은 주석이 되어있는걸 보니 log.retention.hours옵션에 설정 된 7일 이후에 데이터가 삭제 되는 것으로 보인다.
 
# The interval at which log segments are checked to see if they can be deleted according
# to the retention policies
log.retention.check.interval.ms=300000 // default 5분

 

컨슈머 오프셋 저장

컨슈머 그룹은 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋한다.
커밋한 오프셋은 __consumer_offsets 토픽에 저장하며 여기에 저장된 오프셋을 토대로 컨슈머 그룹은 다음 레코드를 가져가서 처리한다.

 

코디네이터(coordinator)

클러스터의 다수 브로커 중 한 대는 코디네이터의 역할을 수행한다.

 

코디네이터가 하는 역할

• 컨슈머 그룹 상태 체크
• 파티션을 컨슈머와 매칭되도록 분배(리밸런스)

 

카프카 클러스터를 운영할 때 주키퍼가 하는 역할은 무엇?

→ 카프카의 메타데이터를 관리하는데 사용 된다.

 

주키퍼 앙상블

주키퍼의 클러스터를 앙상블(ensemble)이라고 한다.

 

[주키퍼 앙상블, 카프카 클러스터 기본 구성]

기본 구성

아래와 같이 클러스터를 여러 개로 운영하는데 한 개의 주키퍼에 다수의 클러스터를 연결해서 사용할 수도 있다고 한다.

 

[3개의 카프카 클러스터를 1대의 주키퍼 앙상블에 연동]

멀티 구성

 

주키퍼에서 다수의 카프카 클러스터를 사용하는 방법

주키퍼의 서로 다른 znode에 카프카 클러스터들을 설정하면 된다.

znode란 주키퍼에서 사용하는 데이터 저장 단위이다. 마치 파일 시스템처럼 znode 간에 계층 구조를 가진다. 1개의 znode에는 n개의 하위 znode가 존재하고 계속해서 tree 구조로 znode가 존재할 수 있다.

2개 이상의 카프카 클러스터를 구축할 때는 root znode(최상위 znode)가 아닌 한 단계 아래의 znode를 카프카 브로커 옵션으로 지정하도록 한다. 각기 다른 하위 znode로 설정된 서로 다른 카프카 클러스터는 각 클러스터의 데이터에 영향을 미치지 않고 정상 작동한다.

 

주키퍼 옵션 정의 예제

• 파이프라인용 카프카 클러스터 : zookeeper.connect=localhost:2181/pipeline
• 실시간 추천용 카프카 클러스터 : zookeeper.connect = localhost:2181/recommend