컨슈머 랙

컨슈머 마지막 커밋 오프셋과 토픽의 마지막 오프셋 차이.

컨슈머 랙을 모니터링 하는것은 중료. 컨슈머 랙이 크다는 것은 서비스 처리가 느리다는 의미.

컨슈머 랙은 컨슈머의 상태를 나타내는 지표. 컨슈머 랙의 최대값은 컨슈머 인스턴스를 통해 직접 확인할 수 있음.

consumer.metrics()를 통해 확인할 수 있는 지표.

• record-lag-max : 토픽의 파티션 중 최대 랙
• fetch-size-avg : 1번 polling 하여 가져올 때 레코드 byte 평균.
• fetch-rate : 1초 동안 레코드 가져오는 회수

컨슈머 랙을 직접 수집할 수 있지만 좋은 방법은 아니다. 인스턴스가 죽어 버리면 확인할 수 없다.

• 

컨슈머랙 수집 하느 것은 외부 모니터링 프로그램을 사용해야 한다.

컨슈머 인스턴스를 통한 컨슈머 랙 수집의 문제점

컨슈머 인스턴스 장애가 발생하면 지표 수집 불가능
구현하는 컨슈머마다 지표를 수집하는 로직 개발 필요
컨슈머 랙 최대값(records-lag-max)만 알 수 있음

• 토픽에 파티션은 n개가 있을 수 있음.
• 최대값을 제외한 나머지 파티션의 컨슈머 랙은 알 수 없음.

파티션 별로 컨슈머 랙을 알고 싶을 수 도 있다.

컨슈머 랙 모니터링

• 외부 모니터링 사용이 권고된다.
• Confluent Platform, Datadog, Kafka Burrow(Open source)
• 카프카 버로우
  • 링크드인에서 오픈소스로 제공하는 컨슈머 랙 체크 툴
  • 버로우 실행 시 Kafka, Zookeeper 정보를 통해 랙 정보 자체 수집
  • 슬라이딩 윈도우를 통한 컨슈머 상태 정의(OK, ERROR:polling 멈춤, WARNING:polling 수행 하지만 랙이 계속 증가)

모니터링 툴

컨슈머 랙이 많이 발생하는 경우

• 컨슈머가 제대로 처리 못함.
• 프로듀서가 값자기 데이터를 많이 전달함.
• 네트워크 상태 불량.

다각적인 모니터링 필요. 각각의 파이프라인마다 확인이 필요. 로그 잘 기록. 파티션과 컨슈머의 스케일 아웃 고려.

트래픽 증가시 스케일 아웃을 자동으로 할 수 있는 방법 ?

카프카 파티션은 늘리는 것은 가능 하지만 줄이는 것은 불가

파티션 갯수 3 -> 2 안됨. 할려면 토픽 삭제해야함.

파티션이 늘어나면 리밸런싱 시간도 증가한다. EC2도 스케일업은 되지만 스케일다운은 안되는 경우 있음.