Kafka 2

공부한 개념을 한 문장씩 쭉 세워본다.

 

카프카 브로커는 카프카를 이용하는 모든 Application 과 데이터를 주고받기 위해 사용하는 주체이다.

우리가 개념적으로 카프카라 생각하는 그것.

 

하나의 서버에는 한 개의 카프카 브로커 프로세스가 실행된다.

 

카프카는 보통 데이터를 안전하게 보관하고 처리하기 위해

3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영한다.

 

클러스터 형태의 카프카의 브로커들은...

Producer 가 보낸 데이터를 안전하게 분산 저장하고 복제하는 역할을 수행한다.

따라서, 급작스런 브로커의 장애에도 안전하게 사용할 수 있다.

 

카프카 클러스터를 실행하기 위해서는 주키퍼가 필요하다.

카프카 3.0 부터는 주키퍼가 없어도 클러스터 형태로 운용할 수 있게 되었다.

 

하나의 주키퍼 앙상블로 여러 클러스터를 운용할 수 있다.

하나의 주키퍼 앙상블로 하나의 클러스터를 운용하면 리소스 낭비일 수 있다.

 

 

브로커의 역할 - 컨트롤러

클러스터의 다수 브로커 중 한 대가 컨트롤러 역할을 수행한다.

컨트롤러 역할을 수행하는 브로커는 다른 브로커들의 상태를 체크한다.

 

어떤 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배한다.

 

컨트롤러 역할을 하는 브로커가 클러스터에서 빠지는 경우 다른 브로커가 컨트롤러 역할을 한다.

 

 

브로커의 역할 - 데이터 삭제

컨슈머가 토픽에서 데이터를 가져가더라도 해당 데이터는 삭제되지 않는다. (컨슈머 오프셋이 변경됨)

컨슈머나 프로듀서가 데이터 삭제를 임의로 요청할 수 없다.

브로커가 자체적으로 데이터를 삭제할 수 있다.

삭제 단위는 로그 세그먼트 라는 파일 단위로 이루어진다.

로그 세그먼트는 레코드 단위가 아니다. 따라서 선별해서 삭제 불가능하다.

삭제 기준은 일정시간이 지나거나 용량 임계치에 따라 삭제 된다. (+ 알파, 추후 설명)

 

 

브로커의 역할 - 컨슈머 오프셋 저장

토픽과 컨슈머 그룹은 1:1 이다.

컨슈머 그룹의 어떤 컨슈머가 매핑된 특정 파티션으로부터 데이터를 가져가면

어느 오프셋(레코드 단위)까지 가져갔는지를 기록한다.

 

기록하는 행위를 커밋이라고 부른다.

 

기록은 __consumer_offsets 라는 토픽에 저장한다.

__consumer_offsets 토픽은 internal 토픽으로 카프카가 자동으로 생성하고 알아서 관리해준다.

 

오프셋이 기록된 것을 바탕으로 컨슈머는 다음 레코드를 가져갈 수 있다.

 

 

브로커의 역할 - 그룹 코디네이터

코디네이터는 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할을 한다.

 

어떤 컨슈머가 컨슈머 그룹에서 빠지게되면 매칭되지 않은 파티션이 생기게 된다.

이때, 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당해준다.

이를 리밸런스 라고 부른다.

 

위 상황에서 하나의 컨슈머가 여러 파티션이랑 매칭된 상태가 존재함을 알 수 있다.

 

 

브로커의 역할 - 데이터 저장

config/server.properties 의 log.dir 옵션은 인입된 데이터를 어느 디렉토리 경로에 저장할 지를 정하는 옵션이다.

 

디렉토리가 정해졌으면 카프카는 해당 경로 하위에 토픽과 파티션 번호의 조합으로 하위 디렉토리를 만든다.

해당 하위 디렉토리에는 실제 데이터와 메타데이터가 저장된다.

.log 에는 메시지(레코드)와 메타데이터가 저장된다.

.index 에는 메시지의 오프셋을 인덱싱한 정보를 저장한다.

.timeindex 에는 메시지에 포함된 timestamp 값을 기준으로 인덱싱한 정보가 담겨있다.

 

 

.log 는 실제 데이터가 저장되는데

오프셋(레코드) 단위의 데이터들이 순차적으로 적재된다.

.log 파일의 이름은 적재된 오프셋의 가장 빠른 번호가 사용된다.

 

 

데이터 삭제 - cleanup.policy = delete

.log 파일 하나하나는 세그먼트라고 불리는 단위이다.

 

log.segment.bytes 옵션은 세그먼트의 최대 크기가 지정된다. (기본값 1GB)

log.roll.ms(hours) 옵션은 세그먼트가 생성된 이후 다음 세그먼트가 생성되는 시간 주기이다. (기본값 7일)

 

가장 최신의 세그먼트 파일(쓰기가 이루어지고 있는 파일)은 액티브 세그먼트라고 불린다.

 

액티브 세그먼트는 브로커가 삭제할 대상에서 제외된다.

 

retention.ms(minutes, hours) 옵션은 세그먼트를 유지할 최대 기간이다. (기본값 7일)

retention.bytes 옵션은 파티션당 로그(세그먼트)들 총합 적재 최대 용량이다. (기본값 없음)

log.retention.check.interval.ms 옵션은 세그먼트가 삭제될 대상이 맞는지 확인하는 주기이다. (기본 값 5분)

 

브로커는 하나의 카프카 물리 서버이므로 제한된 디스크 용량을 가지고 있다.

서버의 스팩과 데이터 성격에 따라 삭제 관련 옵션을 잘 설정해주어야 한다.

 

카프카는 데이터를 삭제할 때, 세그먼트 단위로 삭제를 하며 이는 브로커가 권한을 가지고 있다.

이미 적재된 데이터(레코드 단위로)는 수정과 삭제가 불가능하다.

 

그래서 프로듀서, 컨슈머등 외부 클라이언트에서 이를 제어할 수 없기 때문에..

외부 클라이언트가 카프카의 데이터를 사용할 때는 데이터를 검증하는 습관을 가져야한다.

 

 

데이터 삭제 - cleanup.policy = compact

토픽 압축 정책이라 불리며,

하나의 로그(세그먼트)에서 동일한 키를 기준으로 최신 레코드만 남기고 나머지는 삭제하는 정책이다.

 

하나의 로그에는 offset, key, value 컬럼으로 데이터가 적재된다고 생각하자.

 

토픽 압축 정책에서는.. 로그들을 분류한다.

전체 로그를 봤을 때 클린 레코드 영역(테일 영역), 더티 레코드 영역(헤드 영역), 액티브 로그 로 나뉜다.

 

클린 레코드 영역에 있는 로그들은 토픽 압축 정책을 수행한 로그들이다.

더티 레코드 영역에 있는 로그들은 토픽 압축 정책을 아직 수행하지 않은 로그들이다.

 

min.cleanable.dirty.ratio 옵션은..

클린 레코드 영역과 더티 레코드 영역에 존재하는 로그의 갯수 비율을 정하고

비율이 되면 토픽 압축 정책을 수행한다.

예를 들어 옵션 값이 0.9 이면...

클린 : 더티 = 1 : 9 가 되는 순간 더티 영역의 로그들을 모두 토픽 압축 정책을 수행한다.

 

 

브로커의 역할 - 복제(Replication)

카프카에 인입된 데이터는 복제가 됨으로써 장애 허용 시스템(fault tolerant system)으로 동작할 수 있다.

클러스터 형태의 카프카에서 브로커 중 일부에 장애가 발생하더라도 ...

다른 브로커에 복제가 되어있다면 데이터 유실 걱정이 없을 것이고 서비스 중단 없이 지속적인 서비스가 가능하다.

 

카프카의 데이터 복제는 파티션 단위로 이루어진다.

 

토픽 생성 시점에 파티션의 복제 개수(replication factor)를 설정한다.

설정하지 않으면 브로커의 설정 값을 따라간다.

최솟값은 1(복제 없음)이고 최댓값은 브로커 개수만큼 설정 가능하다.

실무 환경에서는 데이터의 성격에 따라 다르지만 보통 2~3 으로 둔다.

브로커의 개수는 늘어나거나 줄어들거나 할 수 있음을 생각하자.

 

데이터 복제 개념으로 파티션은 리더파티션, 팔로워파티션으로 구분할 수 있다.

지금까지 우리가 생각하던 파티션은 리더파티션으로 프로듀서, 컨슈머 와 직접 통신을 하는 파티션이다.

팔로워파티션은 리더파티션의 데이터를 복제만 수행한다.

 

위 그림은 브로커가 총 3개인 상태에서 토픽 1 에 파티션을 2개 두고..

replication factor 를 3으로 둔 상황이다.

 

팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이가 나면

리더 파티션으로 부터 데이터를 가지고 와서(비동기) 자신의 파티션에 저장한다.

 

브로커가 장애가 발생하면 해당 브로커에 있는 리더 파티션은 사용할 수 없다.

그래서 다른 브로커에 존재하는 팔로워 파티션 중 하나가 리더 파티션 지위를 이어받는다.(승급)

 

리더 파티션만 외부 클라이언트와 통신을 할 수 있는데..

그렇다면.. 브로커를 늘리는게 무슨 의미가 있을까에 대해 생각해보자.

브로커가 많으면 그만큼 많은 브로커에 리더 파티션이 분배되므로

단일 브로커 입장에서 처리량 부담이 줄어들게 됨에 의미가 있는 것이다.

 

ISR(In-Sync Replicas) 은 리더 파티션과 팔로워 파티션의 오프셋 차이가 없는 상태로..

데이터가 모두 싱크가 된 상태를 말한다.

 

ISR 은 리더 파티션 그 자체도 포함하는 개념이다.

Replication factor 가 1 인 상황 (리더 파티션만 존재) 에서도 ISR 이 리더 파티션 하나로 존재하는 것이다.

 

리더 파티션의 데이터를 모두 복제하지 못한 상태인데 리더 파티션이 있는 브로커에 장애가 난 상황에서..

팔로워 파티션이 리더 파티션으로 승급 되어버리면 데이터의 유실이 발생한다.

 

unclean.leader.election.enable 옵션은 토픽 단위로 설정 가능한 옵션이다.

해당 옵션 값을 true 로 하면, 데이터 유실을 감수하겠다는 의미 이다.

해당 옵션 값을 false 로 하면, 해당 브로커가 복구될 때 까지 중단된다. 데이터의 유실이 없을 것이다.

해당 옵션은 데이터의 성격에 따라 잘 설정하자.