티스토리 뷰
[Apache Kafka] 멀티스레드 컨슈머 | 버로우 | 컨슈머 랙 모니터링 | 섹션 6 | 스터디 7주차
YouJungJang 2024. 6. 13. 21:58*본 포스팅은 인프런 [데브원영]님의 아파치 카프카 프로그래밍 강의 섹션 6을 수강하고 이를 참고해 작성했습니다.
멀티스레드 컨슈머 애플리케이션
카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있다. 보통 컨슈머와 스레드를 일대일 대응시킨다.
컨슈머 그룹 A: 특정 프로세스에 장애가 발생해도 프로세스가 모두 분리되어 있으므로 서로 영향을 주지 않아 격리 처리가 가능( 더 자주 쓰인다)
컨슈머 그룹 B: 스케일 업 방식으로 고사양의 물리 장비라면 좋은 방식. 하나의 프로세스로만 이뤄지므로 배포 과정이 단순하다는 장점이 있지만 장애 발생 시 모두 마비된다는 단점이 있다.
컨슈머 랙
컨슈머 랙은 파티션의 최신 오프셋과 컨슈머 오프셋 간의 차이로 컨슈머의 정상 동작 여부를 확인할 수 있기 때문에 필수적으로 모니터링해야 하는 지표이다.
- 컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성된다. ex) 한 개의 토픽에 3개의 파티션이 있고 1개의 컨슈머 그룹이 토픽을 구독하여 데이터를 가져가면 컨슈머 랙은 총 3개이다.
- 프로듀서가 보내는 데이터 양 > 컨슈머 데이터 처리량 -> 컨슈머 랙 증가
- 프로듀서가 보내는 데이터 양 < 컨슈머 데이터 처리량 -> 컨슈머 랙 감소 ( 최솟값은 0으로 지연 없음을 의미)
예시 사진에서 좌측은 컨슈머 랙 3, 우측은 컨슈머 랙 0
컨슈머 랙 모니터링
컨슈머 랙 모니터링으로 통해 컨슈머의 장애를 확인하고, 파티션 개수를 정할 수 있다.
1. 처리량 이슈: 프로듀서의 데이터양이 늘어난 경우
파티션 개수와 컨슈머 개수를 2개로 늘려 컨슈머의 데이터 처리량을 2배로 늘리기
2. 파티션 이슈: 컨슈머의 장애로 인해 컨슈머 랙이 증가하는 경우
프로듀서가 보내는 데이터 양은 동일한테 랙이 증가하는 경우 컨슈머에 이슈가 발생했음을 추측 가능
컨슈머 랙을 모니터링하는 방법 3가지
1. 카프카 명령어 사용
kafka-consumer-groups.sh 명령어를 사용해 특정 컨슈머 그룹의 상태를 확인할 수 있다.
But, 명령어를 사용하는 방식은 일회성에 그치고, 지표를 지속적으로 기록, 모니터링하기에는 부족하다. (주로 테스트용 카프카에서 사용된다)
2. metrics() 메서드 사용
해당 메서드를 사용해 컨슈머 랙 지표를 확인할 수 있다. 하지만 다음과 같이 세 가지 문제점이 있다.
[1] 컨슈머가 실행하므로 컨슈머에 장애가 발생하는 경우 더 이상 랙을 모니터링할 수 없다.
[2] 모든 컨슈머 애플리케이션에 모니터링 코드를 중복해 저장해야 한다.
[3] 카프카 서드 파티 애플리케이션의 컨슈머 랙 모니터링 불가
3. 외부 모니터링 툴 사용
데이터 독, 컨플루언트 컨트롤 센터와 같은 카프카 클러스터 종합 모니터링 툴을 사용하면 다양한 지표를 모니터링하기에 적합하다.
카프카 버로우
RestAPI를 사용해 컨슈머 그룹별로 랙을 확인할 수 있다. 다수의 카프카 클러스터를 동시에 연결하여 랙을 확인한다.
가장 큰 장점: 컨슈머와 파티션의 상태를 단순히 컨슈머 랙의 임계치로 나타내지 않았다는 점!
프로듀서가 데이터를 보내면 일시적으로 임계치가 넘어갈 수 있으므로 단순 임계치 만으로 알람 받는 것은 무의미
-> 버로우는 임계치가 아닌 슬라이딩 윈도로 계산해 문제가 생긴 파티션과 컨슈머의 상태를 표현한다.
[1] 정상인 경우
프로듀서가 지속적으로 데이터를 추가하면서 때때로 랙이 증가하지만 다시 0으로 줄어드는 것 = 컨슈머의 정상 동작을 의미
[2] 컨슈머 처리량 이슈
프로듀서의 최신 오프셋을 컨슈머가 따라가지 못하는 추이. 컨슈머 랙이 지속적으로 증가하는데 이는 컨슈머의 처리량이 프로듀서의 전송량에 비해 적기 때문이다. 이 경우 파티션은 OK, 컨슈머는 Warning 상태 -> 파티션 개수와 컨슈머 개수를 늘리면 해결 가능
[3] 컨슈머 이슈
컨슈머 오프셋이 멈추고 랙이 증가하는 모습. 컨슈머가 데이터를 더는 가져가지 않는 것으로 이는 비정상 동작을 의미한다 -> 알람 받고 즉각 조치 필요