[Kafka] 카프카, 데이터 플랫폼의 최강자 4~5장

4장 카프카 프로듀서

4.4 프로듀서 주요 옵션

• bootstrap.servers (호스트 리스트 정보)
• 카프카 클러스터는 마스터 개념이 없기 때문에 모든 서버가 클라이언트의 요청을 받을 수 있다.
• acks옵션의 수가 작으면 성능이 좋지만, 메시지 손실 가능성이 있고, 수가 크면 반대
  • acks=0
  • 설정시 프로듀서가 서버로부터 어떠한 ack도 기다리지 않기 때문에 데이터를 받았는지 보장 x, 전송 실패 결과 알 수 없어서 재요청 불가, 대신 매우 빠름
  • ack=1
  • 데이터는 기록하지만, 모든 팔로워는 확인하지 않는다. 일부 데이터 손실 가능성
  • ack=all or -1
  • 리더가 ISR 팔로워부터 데이터에 대한 ack를 기다림 하나의 팔로워가 있는 한 데이터는 손실되지 않으며, 데이터 무손실에 대해 가장 강력하게 보장
• 프로듀서가 카프카 토픽의 리더에게 메시지를 보낸 후 요청을 완료하기 전 ack(승인)의 수
• buffer.memory
  • 프로듀서가 카프카 서버로 데이터를 보내기 위해 잠시 대기할 수 있는 메모리 bytes
• compression.type
  • 프로듀서가 데이터를 압축해서 보낼 때 어떤 타입으로 아축할지
• retries
  • 전송 실패 데이터 재발송
• batch.size고가용성이 필요한 메시지는 배치 사이즈를 설정 하지 않는 것도 하나의 방법
• 파티션으로 데이터 전송시 batch size byte 단위 조정. 정의된 크기보다 큰 데이터는 배치 시도x
• lingers.ms
  • 배치형태의 메시지를 보내기 전에 추가적인 메시지들을 위해 기다리는 시간 조정
• max.request.size
  • 프로듀서가 보낼 수 있는 최대 메시지 바이트 사이즈 기본값 1MB

여러 옵션은 공식 문서 참고

 

4.5 메시지 전송 방법

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

= ack를 기다리지 않는다. -> 손실 가능성이 존재한다. -> acks = 0

 

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

= ack 확인 -> acks = 1

하지만 이 경우에도 아예 메시지 손실이 없는건 아님 -> 프로듀서에게 메시지를 받았다고 acks를 보낸 후 바로 장애 나는 경우 팔로워가 바라봐야 할 리더가 없어짐 = 메시지 손실

Logstash나 Filebeat 등에서는 acks 옵션을 기본값 1로 사용, 속도와 안정성을 어느정도 확보할 수 있어서

 

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

= acks=all + min.insync.replicas=2 (ISR 그룹 개수 유지 확인) + replication factor=3

만약 acks=all + min.insync.replicas=3 (ISR 그룹 개수 유지 확인) + replication factor=3 로 설정시 브로커 하나가 강제 종료되면 ISR 조건에 만족하지 않으면서 에러가 발생해 클러스터 전체 장애와 비슷한 상황이 되기 때문에 유의해야한다.

---

 

5장 카프카 컨슈머

5.1 컨슈머 주요 옵션

• 컨슈머의 주요 기능 : 파티션 리더로부터 메시지를 가져오기, 각 오프셋 위치로부터 로그 메시지를 수신
• 이미 가져온 메시지를 다시 가져올 수 있음, 카프카에만 있는 기능

올드 컨슈머 vs 뉴 컨슈머

• 차이점 = 주키퍼의 사용 유무
• 올드 컨슈머는 사라질 예정, 뉴 컨슈머 기준
• fetch.min.bytes
  • 한번에 가져올 수 있는 최소 데이터 사이즈, 크기가 작을 경우 대기
• fetch.max.bytes
• group.id
  • 컨슈머가 속한 그룹을 식별하는 식별자
• enable.auto.commit
  • 백그라운드에서 주기적으로 오프셋 커밋
• auto.offset.reset
  1. earliest : 가장 초기의 오프셋값
  2. latest : 가장 마지막의 오프셋값
  3. none : 이전 오프셋값을 찾지 못하면 에러
• 초기 오프셋이 없거나 현재 오프셋이 더 이상 존재하지 않은 경우 설정한 옵션값으로 reset
• auto.commmit.intervals.ms
  • 오프셋 자동 저장 시간
• request.timeout.ms
  • 요청에 대해 응답을 기다리는 최대 시간
• session.timeout.ms
  • 컨슈머와 브로커 사이의 세션 타임아웃 시간 = 브로커가 컨슈머가 살아있는것으로 판단하는 시간

5.4 파티션과 메시지 순서

• 각각 파티션별로 메시지가 저장되기 때문에 컨슈머는 프로듀서가 어떤 순서대로 메시지를 보냈는지 알 수 없다.
• 파티션을 1개로 사용하면 순서 보장이 가능하긴함

 

5.5 컨슈머 그룹

• 리밸런스 : 컨슈머의 수가 부족해 메시지를 빠르게 처리하지 못하는 경우 컨슈머를 추가해주면 소유권이 추가해준 컨슈머로 분배되게 되는것
• 리밸런스 하는 동안 일시적으로 메시지를 가져올 수 없4다.
• 하나의 파티션에는 하나의 컨슈머만 연결할 수 있다. -> 컨슈머 추가시 파티션도 같이 추가해줘야함
• 제대로 컨슘 되고있는지는 하트비트를 통해 확인할 수 있음 -> 일정 주기로 하트비트를 보낸다 -> 메시지를 잘 처리하고 있다.
• 하트비트는 컨슈머가 poll 할 때와 가져간 메시지의 오프셋을 커밋할 때 보냄
• 하트비트를 오랫동안 보내지 않으면 세션은 타임아웃되고 해당 컨슈머가 다운되었다고 판단하여 리밸런스가 발생
• 카프카 컨슘되어도 메시지가 삭제되지 않기 때문에 여러 용도로 사용 가능, 컨슈머 그룹 별로 offset 관리

5.6  커밋과 오프셋

• 컨슈머가 poll() 호출시 해당 컨슈머 그룹은 카프카에 있는 읽지 않은 메시지를 가져온다. (각각의 오프셋을 관리하기 때문에 가능)
• 메시지를 가져오고나면 가져간 메시지의 위치 정보를 기록 -> 커밋한다.
• 갑자기 컨슈머 다운되거나 컨슈머 그룹에 새로운 컨슈머가 조인한다면 리밸런스가 발생커밋된 오프셋 < 실제 처리 오프셋 : 사이의 데이터는 중복 처리
• 커밋된 오프셋 > 실제 처리 오프셋 : 데이터 누락
• 리밸런스 발생시 컨슈머는 이전 처리했던 파티션이 아닌 다른 새로운 파티션에 할당되고 해당 파티션의 가장 최근 커밋된 오프셋 부터 가져옴

 

5.6.1 자동 커밋

• 가장 많이 사용하는 커밋 방식
• enable.auto.commit=true
• auto.commit.intervals.ms 로 커밋 주기 설정
• poll 요청시마다 커밋 시간인지 아닌지 체크, 가져온다면 마지막 오프셋 커밋
• 중복이 발생 할 수 있음

5.6.2 수동 커밋

• 메시지 처리가 완료될 때까지 메시지를 가져온 것으로 간주되어서는 안 되는 경우
• DB 에 메시지 저장시 일부 메시지가 저장되기전에 컨슈머 장애 발생시 해당 메시지 손실 가능성
• DB에 메시지 저장 후 커밋을 해야 안전
• consumer.commitSync() 사용

 

5.6.3 특정 파티션 할당

• 수동으로 파티션을 할당해 메시지를 가져올 수 있지만, 컨슈머 인스턴스마다 그룹 아이디를 서로 다르게 설정해야한다.
• 동일 그룹 사용시 오프셋 정보를 공유하기 때문에 다른 컨슈머가 할당받아 메시지를 이어가져가 다른 동작을 할 수 있음

 

5.6.4 특정 오프셋부터 메시지 가져오기

• 메시지 중복 처리로 오프셋 수동 관리하는 경우
• consumer.seek() 사용