[kafka] kafka config 설정

목적

아래 프로젝트에 kafka를 붙이고자 할 때 어떻게 설정할지 공유하고자 한다.

1. 1시간에 한번 실행. 사용자 상호작용 로깅이 아닌 원본 데이터를 가공한 데이터.
2. 실시간으로 실행. 원본 데이터는 mysql에 저장되어있음.

브로커

replication.factor

데이터 유실 방지를 위해 3으로 적용

unclean.leader.election.enable

ISR이 아닌 OSR을 가지고 있는 broker를 leader로 선출할 수 있도록 설정하는 옵션.

true일 경우, 브로커가 모두 down 되었다가 OSR 상태의 브로커만 up 되었을 때,

데이터는 일부 유실하더라도 서비스할 수 있다.

false일 경우, 데이터는 유실하지 않으나,  producer, consumer의 요청을 받을 수 없어 서비스 불가하다.

보통 두가지 방식으로 서비스를 지속할 수 있는 설계를 구축한다.

1. 의도적인 유실
2. 데이터 중요도가 낮은 경우 true를 통해 서비스는 지속하되, 유실의 가능성을 열어둔다.
3. kafka 클러스터 이중화
4. 클러스터를 2개로 둠으로써, 한 클러스터가 down되었을 경우, producer가 fail over로 또 다른 클러스터에 데이터를 보낼 수 있도록 조치를 취한다.

문제

• true로 설정한 후 all down 되었음을 몰랐을 경우, CS가 들어왔을 때 데이터가 유실되었음을 인지하고, 재처리를 수행하거나, full sync 배치를 실행할 것이다.
• 그러나 true로 설정해 놓고 all down된 상태임을 인지한다면(slack 채널 노티를 통해), fail over로써 재실행하거나 배치를 자동적으로 돌린다면 되지 않을까?
• 클러스터 이중화를 하기엔 데이터 중요도는 높으나 원본 데이터가 있으므로 그럴 필요는 없을 거 같다.

auto.leader.rebalance.enable

클러스터 단위에서 리더 파티션을 자동 리밸런싱 하도록 도와줌.

우선 클러스터 서버들의 성능도 동일하고, 새로운 브로커가 추가될 계획은 아직까지 없으므로 true로 설정.

브로커의 백그라운드 스레드가 일정한 간격으로 리더의 위치를 파악.

필요할 경우 리더 리밸런싱을 통해 리더의 위치가 알맞게 배분된다.

이 경우, 초기 설정한 파티션 리더인 브로커와 리밸런싱을 통해 선출된 리더가 다를 경우,

preferred leader = false가 된다.

💡 preferred leader?

설정을 통해 미리 지정된 리더 파티션을 preferred leader라 부른다.

즉, json 파일에서 replicas: 속성에서 가장 첫번째 브로커에 위치한 복제 파티션이 리더 역할을 담당.

// 파티션 설정 파일 예시 (json 파일)
{
	"version":1,
  	"partitions":[
     	{"topic":"test-topic", "partition":0, "replicas":[1,2,3]},
     	{"topic":"test-topic", "partition":1, "replicas":[2,1,3]},
     	{"topic":"test-topic", "partition":2, "replicas":[3,1,2]} 
 	]
 }

유의 사항

auto.leader.rebalance.enable 옵션을 true로 설정했을 경우, 문제점이 있다.

• topic 중, 어떤 건 데이터 양이 많고, 어떤 건 데이터 양이 상대적으로 적은 상태에서, 새로운 브로커가 온라인 상태가 된 경우이다.

1. auto rebalance를 통해 해당 브로커는 많은 데이터를 가진 topic의 파티션의 리더로 선출되었다.(unclean.leader.election.enable 은 true이므로)
2. 따라서 해당 브로커는 많은 데이터가 포함된 topic에 대한 복제를 따라잡고 있던 도중, producer/consumer는 해당 브로커에게 요청을 하여 읽기/쓰기 시간이 초과되었다.

이런 경우는 리더 선출을 false로 해놓고 수동으로 리더를 선출하여, 새로 온라인된 브로커가 리더로 선출되지 않도록 해야 한다.

• 또한 카프카 클러스터를 이루는 서버들의 성능이 모두 동일하지 않을 경우, 성능이 나쁜 브로커가 리더로 선출되지 않도록 수동설정 해야 한다.

min.insync.replicas

acks를 all로 설정하지 않는 경우, 해당 수치는 필요하지 않겠지만, 우선 2로 설정.

프로젝트 특성 상 급격하게 TPS가 상승할 확률이 낮으며, 또한 클러스터 내 브로커 2개가 동시에 down될 확률이 낮다고 하니.. 2로 설정.

replica.lag.time.max.ms

ISR 그룹의 리더는 팔로워들이 주기적으로 데이터를 확인하고 있는지 확인.

해당 값만큼 확인 후 요청이 오지 않는다면, 리더는 해당 팔로워의 이상을 감지하고 ISR그룹에서 해당 팔로워를 추방시킴.

ISR에서 추방당한 팔로워는 추방과 동시에 ISR그룹에서의 리더 자격도 박탈당한다.