신뢰성있는 데이터 전달

토픽, 브로커

복제팩터(가용성 <-> 하드웨어)

• 복제 매커니즘에서 중요한 옵션
• 토픽 수준에서 복제 팩터 옵션 replication.factor
• 브로커 수준에서 복제 팩터 옵션 default.relication.factor
• 복제 팩터가 N이면 N-1개의 브로커가 중단되더라도 여전히 토픽의 데이터에 신뢰성을 가짐
• 복제 팩터가 N일 경우에 최소한 N개의 브로커가 필요하고 N개의 복사본을 저장해야 하므로 N배의 디스크 공간이 필요함
• 결국 지불 가능 비용을 고려한 결정이 필요한 옵션이다

복제팩터 추가

• 기본적으로 카프카는 한 파티션의 각 리플리카들을 별개의 브로커에 둔다
• 랙을 사용하는 경우에는 랙 수준의 장애를 방지하기 위해서 아래와 같이 함
  • 다수의 랙에 브로커들을 위치시킨다
  • 브로커 구성 매개변수인 broker.rack 을 사용해 브로커의 랙 이름을 설정한다

언클린 리더 선출 문제(일관성 <-> 가용성)

• unclean.leader.election.enable : true, false
• 언클린 리더 설정을 true로 하는 것은 비동기 리플리카(리더에게 복제하지 않은)가 리더가 될 수 있게 함. 언클린 선출 이라고 함. 메시지 유실이 될 가능성이 있음
• false로 설정하면 원래 리더가 장애 후 다시 온라인이 되기를 기다린다는 의미로 가용성은 떨어진다
• 데이터 품질과 일관성이 중요하다면 false로 설정하며, 가용성이 중요한 경우(예를 들어서 실시간 클릭 정보 분석)에는 true로 설정을 한다

최소 동기화 리플리카

• min.insync.replicas 에 설정된 수 만큼이 동기화 될 때 토픽의 파티션에 쓸 수 있다.
• 위에서 설정한 값이 이하의 브로커가 살아 있는 경우. 프로듀서가 메시지를 쓸 때, NotEnoughReplicasException 예외를 받게 된다.
• 그러나 컨슈머는 계속 메시지를 읽을 수 있다.
• 위와 같은 읽기만 가능한 상황을 해결하기 위해서는 min.insync.replicas 설정된 수 만큼의 정상동작하는 브로커가 있어야 하며, 그동안 밀렸던 메시지를 처리하고 동기화가 되어야 한다.

프로듀서

• 브로커와 토픽 설정이외에 프로듀서관점에서 메시지가 유실될 수 있는 상황이 있다.
• ack에 따른 설정이다

Acks 옵션 복습

• acks=0 : 프로듀서가 네트워크로 메시지를 전송했다면 카프카가 성공적으로 쓴 것으로 간주. 단 전송하는 객체가 직렬화될 수 없거나 네트워크에 장애가 생기면 에러를 받는다

• acks=1 : 리더가 메시지를 수신하고 파티션 데이터 파일에 쓴 후(캐시에 쓴 것이지 디스크에 저장까지 기다리는 것은 아님) 확인 응답 혹은 에어를 받는다. 단 리더가 선출 중일 경우에 프로듀서는 LeaderBotAvailableException 예외를 받는다

• acks=all : 확인 응답이나 에러의 전송에 앞서서 모든 동기화 리플리카가 메시지를 받을 때까지 리더가 기다린다. min.insync.replica 와 같은 옵션으로 수(리더가 응답을 하기 전 메시지를 받을 리플리카의 수)를 정해서 조정할 수 있다

### 프로듀서 입장에서 재시도가 가능한 에러 vs 재시도가 불가능한 에러

• INVALID_CONFIG (구성이 잘못되어 발생한 에러임) : 재시도 불가능
• LEADER_NOT_AVAILABLE(브로커 리더 선출중 발생하는 에러) : 재시도 가능
• 기타 네트워크 관련에러는 재시도가 가능한 에러로 본다
• 재전송관련해서는 브로커에 중복 저장되는 경우가 발생할 수 있음에 유의한다.
  • 정상 저장이 된 후 네트워크 문제로 프로듀서에 응답이 전달되지 못한경우.
  • 프로듀서에서 재전송하게 될 가능성이 있다

프로듀서가 반드시 처리해주어야 하는 에러

• 메시지 크기, 인증 에러 등 카프카가 제동하는 재시도에서 벗어난 브로커 에러
• 직렬화 중에 발생하는 에러
• 재전송에 따른 메모리(재전송 시도 중에 메시지 저장으로 메모리 full) 에러

컨슈머

group.id

• 각 컨슈머는 해당 토픽의 일부 파티션을 분담한다.

auto.offset.reset

• earliest, latest(default) 로 값으 주면, 이 옵션은 예를 들어서 컨슈머가 처음 시작할 때, 해당 파티션에서 처음부터 데이터를 가져올지 아니면 앞으로 커밋되는 데이터를 가져올 지 결정하는 옵션이다

enable.auto.commit

• 컨슈머의 오프셋 커밋 을 자동으로 할 지 결정하는 옵션으로, true 일 때 문제가 발생 할 부분은 중복되는 메시지에 대한 처리를 제어할 수 없다는 문제가 있다. (컨슈머가 일부 메시지를 처리하고 중단되면, 이 시점에는 컨슈머가 데이터를 가져갔으므로 데이터 처리는 이루어졌으나 오프셋 커밋은 날리지 못한 상태. 그룹으로 묶여 있다면 다른 컨슈머가 다시한번 수행하는 가능성이 있음)

auto.commit.interval.ms

• enable.auto.commit 이 true 일 때 auto.commit.interval.ms 에 시간을 설정하여 자동으로 오프셋을 커밋하는 시간 간격을 제어할 수 있음. 간격이 짧으면 메시지 중복은 줄어들 것이나 성능과 트레이드 오프임을 명시한다