[kafka] 카프카 프로듀서 주요 옵션 및 전송방법

프로듀서 주요 옵션

bootstrap.servers

카프카 클러스터에 연결하기 위한 호스트와 포트정보로 구성된 리스트
호스트 이름:포트, 호스트 이름: 포트
kafka01:9092,kafka02:9092

acks

프로듀서가 카프카 토픽의 리더에게 메시지를 보낸 후 요청을 완료하기 전 ack(승인) 수.
해당 옵션의 수가 작으면 성능이 좋지만, 메시지 손실 가능성이 있고, 반대로 수가 크면 성능이 좋지 않지만 메시지 손실 가능성도 줄어들거나 없어짐

• acks=0
  프로듀서는 서버로부터 어떠한 ack도 기다리지 않음. 전송 실패에 대한 결과, 재요청 설정이 적용되지 않음. 빠르게 메시지를 보낼 수 있어 높은 치리량을 얻을 수 있음
• acks=1
  리더는 데이터를 기록하지만, 모든 팔로워는 확인하지 않음. 이 경우 일부 데이터의 손실이 발생할 수 있음
• acks=all 또는 -1
  ISR의 팔로워로부터 데이터에 대한 ack를 기다림.

buffer.memory

프로듀서가 카프카 서버로 데이터를 보내기 위해 잠시 대기(배치 전송이나 딜레이 등)할 수 있는 전체 메모리 바이트

compression.type

프로듀서가 데이터를 보낼 때 어떤 타입으로 압축할 것인지 정함 (none, gzipe, snappy ..)

retries

일시적인 오류로 인해 전송에 실패한 데이터를 다시 보내는 횟수

batch.size

동일 파티션으로 보내는 여러 데이터를 함께 배치로 보내려고 시도(클라/서버 양쪽 성능 측면에서 도움이 됨)
정의된 크기보다 큰 데이터는 배치를 시도하지 않음
배치를 보내기 전 클라이언트 장애가 발생하면 배치 내에 있던 메시지는 전달되지 않음.
고가용성이 필요하다면 배치 사이즈를 주지 않는 것도 하나의 방법(클라 장애발생 시 배치 내에 있던 메시지 전달 x)

max.request.size

프로듀서가 보낼 수 있는 최대 메시지 바이트 사이즈 (default 1MB)

그 외 옵션은 https://kafka.apache.org/documentation/#producerconfigs 참고

메시지 전송 방법

acks 옵션 설정 방법에 따라 달라짐

• 메시지 손실 여부
• 메시지 전송 속도 및 처리량

메시지 손실 가능성이 높지만 빠른 전송이 필요한 경우

프로듀서가 카프카 서버 응답을 기다리지 않는 경우(acks=0)

• 일반적인 환경에서 메시지 유실 없음
• 브로커가 다운되는 장애 등의 경우에만 메시지 손실 가능성이 높음

메시지 손실 가능성이 적고 적당한 속도의 전송이 필요한 경우

메시지를 보낸 후 보낸 메시지에 대한 응답 확인(akcs=1)

• 응답을 기다리는 시간만큼 속도가 약간 떨어짐 (보내는 행동 + 응답을 받는 행동)
• 간혹 손실 가능성이 있음(예외적으로)
  1. 리더가 메시지를 받고 acks를 보내자마자 다운됨(팔로워들이 리더의 메시지를 받기 전)
  2. 팔로워중 하나가 리더로 승격하고, 기존 팔로워들은 처음 리더의 메시지를 받을 수 없게됨

특별한 경우가 아니라면 속도와 안전성을 확보할 수 있는 acks=1로 사용하는 방법을 추천
리더 선출 작업 등이 일어났다고 해서 무조건 메시지 손실이 발생하는 것은 아님 (아주아주 예외적...)

전송 속도는 느리지만 메시지 손실이 없어야 하는 경우

리더 뿐만 아니라 팔로워까지 메시지를 받았는지 확인(acks=all)

• 브로커의 설정(min.insync.replicas)에 따라 작동방식이 약간 다름

위에서 브로커의 설정(min.insync.replicas)에 따라 동작방식이 조금씩 다르다고 했는데
acks=all경우는 최소 리플리케이션 팩터(min.insync.replicas)설정에 따른 동작방식을 살펴보아야 한다.
3대의 브로커가 존재하고, 토픽의 리플리케이션 팩터 옵션이 3이라고 가정하자

프로듀서 acks=all, 브로커 min.insync.replicas=1

acks=1과 동일하게 동작

프로듀서 acks=all, 브로커 min.insync.replicas=2

(1) - 리더에게 메시지 전달
(2) - 리더는 메시지를 받은 후 저장. 브로커1에 있는 팔로워는 변경사항이나 새로 받은 메시지가 없는지를 리더로부터 주기적으로 확인하면서, 새로운 메시지가 전송된 것을 확인하면 리더로부터 메시지를 가져와 저장
(3) - min.insync.replicas가 2로 설정되어 있기 때문에 acks를 보내기 전 최소 2개의 리플리케이션을 유지하는지 확인
(4) - 프로듀서가 전송한 메시지에 대해 acks를 프로듀서에게 보냄

아파치 카프카 문서에서는 acks=all, min.insync.replacs=2, replication factor=3 을 권장함

프로듀서 acks=all, 브로커 min.insync.replicas=3

정상적인 시나리오만 보면 강력한 방법이라는 생각이 들지만, 브로커 하나가 중지됬을 때 시나리오를 생각해 봐야 한다.

정상적인 시나리오
(1) - 프로듀서가 토픽의 리더에게 메시지 전송
(2) - 리더1 + 팔로워2 총 3 곳에서 모두 메시지를 받고, 리더는 프로듀서에게 메시지를 잘 받았다는 acks를 보냄

하지만, 팔로워 브로커를 강제 종료시키게되면 ISR에는 리더1, 팔로워1 총 2개만 남게되기 때문에 옵션으로 설정한 최소 리플리케이션 팩터 수(3개)를 충족시키지 못해 에러가 발생한다.
즉, 카프카 하나의 브로커만 다운되도 전체 장애와 비슷한 상황이 발생하게 되는 것이다. 따라서 리플리케이션 팩터가 3일 경우 min.insync.replicas=2로 설정하는 것이 권장된다.