Kafka Consumer 성능과 고려 요소들

목차

[Consumer 관련 용어들]

• Log end Offset: 파티션에 추가된 최신 데이터. producer가 현재 쓰고 있는 위치. 아직은 consumer가 액세스 할 수 없음
• High Watermark: 데이터가 모든 Replica에 복제됨. 사용가능한 오프셋 위치
• Current Position: consumer instance 개별적으로 관리하는 것. 현재 처리 중인 오프셋 위치
• Last Committed Offset: __consumer_offsets 토픽에 저장된 마지막 위치.

[Conusmer 주요 파라미터들]

• fetch.min.bytes: 최소 fetch 용량. 1이면 즉시 불러온다.
• fetch.wait.max.ms: fetch 최대 대기시간.
• max.partition.fetch.bytes: 파티션 당 최대 얼마나 fetch할 것인지 설정.
• max.poll.records: polling한 번에 읽어올 메시지 수
• max.poll.interval.ms: 다음 번 polling interval (Default: 5분. polling 후 5분 내에 다음번 polling이 없으면 timeout 오류 발생)
• heartbeat.interval.ms: healthcheck 주기 (기본값: 3초)
• session.timeout.ms: healthceck가 최종적으로 실패했다고 판단하는 시간 (기본값: 10초. 통상적으로 heartbeat interval의 3배로 설정)

 

[Consumer의 성능을 위해 고려할 사항들]

Consumer Group Rebalancing

새로운 컨슈머가 그룹에 합류하거나 탈퇴할 때 마다 발생한다.

"stop-the-world"를 유발하므로 최소한의 리밸런싱이 발생하도록 조절하는 것이 중요하다.

timeout으로 의도치 않은 리밸런싱이 지속적으로 발생할 수 있으니 heartbeat, polling interval을 적절히 조절하는 것이 중요함.

현재 비즈니스에 맞는 파티션 할당 전략을 사용하는 것을 고려한다.

참조: https://jaemni.tistory.com/entry/Consumer-Assignment-Strategies

Consumer Assignment Strategies

 

End-to-End 시간과 Produce 시간

Producer의 지연시간은 ack를 받을 때 까지의 시간이며 End-to-End 시간은 Consumer가 fetch를 끝낼때 까지의 시간을 의미한다.

High Watermark는 producer가 acks=1이라고해서 전진이 빨라지는 것은 아니다.왜냐면 High Watermark는 Replication이 끝난 후 전진하기 때문이다.

즉, acks=1로 설정한다고해서 end-to-end latency가 개선되지는 않는다.

 

Commit

• Auto-Commit:자동으로 일정 주기마다 커밋해준다. polling을 하기전에 그 전에 처리한 메시지를 커밋하게 된다. (0~5번 오프셋을 처리했더라도 5번을 커밋하지 0,1,2,3,4 다 커밋하는 방식이 아님)
• Manual-Commit: 정확한 커밋을 위해 매번 커밋할 경우 성능에 악영향을 줄 수 있다.

메시지마다 커밋을 하면 성능에 악영향을 줄 수 있으니 "at least once" semantics로 커밋하는 것이 좋다. (ex: Auto-Commit)

 

Consumer Lag

메시지 생산보다 소비가 느리다는 뜻.

제대로 병렬처리를 하고 있는지 (적절한 파티션 수?), 메시지 당 처리시간이 너무 길지 않은지 확인한다.

 

Multi-Region Cluster : Follower Fetching

카프카 클러스터가 IDC1, IDC2의 노드들을 묶어서 구성한 "stretched cluster" 일 경우 적용할 필요가 있는 옵션이다.

IDC2에 있는 Consumer가 IDC1에 있는 Leader에 접근하려면 IDC를 넘나드는 Network Latency가 추가로 소모된다.

 

Kafka에서는 Follower Fetching이라는 기능을 제공한다.

동일 IDC에 있는 복제본을 읽어 처리할 수 있도록 하는 기능이다.

 

이를 활성화하려면 Broker, Consumer 양쪽에서 설정을 해줘야 한다.

# Kafka.server.properties
broker.rack=<region1>
replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector

# Consumer
client.rack=<region1> (broker.rack과 동일한 값)

 

[Consumer 주요 메트릭과 성능]

사실 Consumer의 성능 개선은 거의 필요없는 수준이라고 한다.

Producer와 Kafka Cluster가 잘 세팅되어 있으면 Consumer는 기본값 정도로도 잘 동작한다.

다만 max.poll.records와 heartbeat 같은 리밸런싱이 발생할 만한 요소들에 대해 모니터링하고, fetch.min.bytes를 통해 배치처리를 늘려보는 방식으로 개선하는 방법이 있을 수 있다.

 

주요 메트릭

Metric	Meaning	MBean
fetch-latency-avg	fetch 시간 -> 이슈 시 브로커 체크	kafka.consumer:type=consumer-fetch-manager-metrics,cliend-id=([-.w]+)
fetch-size-avg	fetch된 평균 바이트 수	kafka.consumer:type=consumer-fetch-manager-metrics,cliend-id=([-.w]+)
commit-latency-avg	커밋 소요시간 -> 이슈 시 브로커 체크	kafka.consumer:type=consumer-fetch-coordinator-metrics,cliend-id=([-.w]+)
rebalance-latency-total	리밸런싱에 소요된 전체 시간	kafka.consumer:type=consumer-fetch-coordinator-metrics,cliend-id=([-.\w]+)
fetch-throttle-time-avg	스로틀링을 걸은 상태에서 소요시간 (ms)	kafka.consumer:type=consumer-fetch-manager-metrics,cliend-id=([-.w]+)