4.3 카프카 컨슈머
멀티 스레드 컨슈머
토픽의 파티션은 1개 이상으로 이뤄져 있으며 1개의 파티션은 1개의 컨슈머가 할당되어 데이터를 처리하게 됩니다.
파티션을 여러 개로 운영하는 경우 데이터 병렬처리를 위해 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋습니다.
그러므로 n개의 스레드를 가진 1개의 프로세스를 운영하거나 1개의 스레드를 가진 프로세스를 n개 운영하는 방법이 있습니다.
멀티코어 CPI를 가진 가상/물리 서버 환경에서 멀티 컨슈머 스레드를 운영하여 제한된 리소스 내에서 최상의 성능을 발휘할 수 있기 때문에 컨슈머를 멀티 스레드로 활용하는 방식은 크게 두 가지로 나뉩니다.
컨슈머 스레드는 1개만 실행하고 데이터 처리를 담당하는 워크 스레드를 여러 개 실행하는 방법인 멀티 워커 스레드 전략
컨슈머 인스턴스에서 poll 메서드를 호출하는 스레드를 여러 개 띄워서 사용하는 컨슈머 멀티 스레드 전략
스레드를 사용함으로써 데이터 처리가 끝나지 않았음에도 불구하고 커밋을 하기 때문에 리밸런싱, 컨슈머 장애 시 데이터 유실 발생
스레드 처리 시간이 각각 다르기 때문에 레코드 순서가 뒤바뀌는 현상이 발생
따라서 레코드 처리에 있어 중복이 발생하거나 데이터 역전현상이 발생해도 되며 매우 빠른 처리 속도가 필요한 데이터 처리에 적합합니다.
참고 : https://backtony.github.io/kafka/2022-03-12-kafka-4/
- 카프카 컨슈머 멀티 스레드 전략
컨슈머 인스턴스에서 poll() 메서드를 호출하는 스레드를 여러개 사용
하나의 파티션은 동일 컨슈머 중 최대 1개까지 할당된다.
하나의 컨슈머는 여러 파티션에 할당될 수 있다.
토픽의 파티션 개수만큼 컨슈머 스레드를 운영하면, 하나의 프로세스에서 모든 파티션을 커버할 수 있음
여기서 주의할점은 구독하고자 하는 토픽의 파티션 개수만큼만 컨슈머 스레드를 운영해야 함.
컨슈머 스레드가 파티션 개수보다 많아지면 할당할 파티션 개수가 더는 없으므로, 파티션에 할당되지 못한 컨슈머 스레드는 데이터 처리를 하지 않게 된다.
4.3.2 컨슈머 랙
컨슈머 랙은 토픽의 최신 오프셋(LOG-END-OFFSET)과 컨슈머 오프셋(CURRENT-OFFSET)간의 차이다.
프로듀서는 계속해서 새로운 데이터를 파티션에 저장하고 컨슈머는 자신이 처리할 수 있는 만큼 데이터를 가져간다.
컨슈머 랙은 컨슈머가 정상 동작하는지 여부를 확인할 수 있기 때문에 컨슈머 어플리케이션을 운영한다면 필수적으로 모니터링 해야 하는 지표
프로듀서의 데이터 양이 일정함에도 불구하고 컨슈머의 장애로 인해 랙이 증가할 수 있다.
참고 : https://velog.io/@tnqlsdl1300/consumerLag
명령어, 메소드를 통한 랙 모니터링은 비효율적이다.
- 컨슈머 랙 모니터링
컨슈머 랙 모니터링 아키텍쳐
버로우를 통해 컨슈머 랙을 모니터링할 때는 컨슈머 랙을 개별적으로 모니터링 할 수 있는 별개의 저장소와 대시보드를 사용하는 것이 효과적.
컨슈머랙 모니터링을 위해 사용할 수 있는 저장소와 대시보드는 다양하지만 빠르게, 무료로 설치할 수 있는 아키텍쳐를 제안
컨슈머 랙 모니터링 아키텍처 준비물
버로우 : REST API를 통해 컨슈머 랙을 조회하는 오픈 소스 어플리케이션
텔레그래프 : 데이터 수집 및 전달에 특화된 툴, 버로우를 조회하여 데이터를 엘라스틱 서치에 전달
엘라스틱 서치 : 컨슈머 랙 정보를 담는 저장소
그라파나: 엘라스틱서치의 정보를 시각화하고 특정 조건에 따라 슬랙 알람을 보낼 수 있는 웹 대시보드 툴
참고 : https://m.blog.naver.com/mu-ze/222242514741
4.3.3 컨슈머 배포 프로세스
- 중단 배포
컨슈머 애플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식이다. 이 방법은 한정된 서버 자원을 운영하는 기업에 적합
배포 시점의 오프셋을 로깅하여 롤백하는데 용이
- 무중단 배포
1) 블루/그린
이전 버전 애플리케이션과 신규 버전 애플리케이션을 동시에 띄어놓고 트래픽을 전환하는 방식이다.
티션 개수와 컨슈머 개수를 동일하게 실행하는 애플리케이션을 운영할때 유용하다.
신규 버전을 유휴상태로 대기시키고, 이전 버전을 중단하여 리밸런싱한다.
-> 리밸런싱이 한번만 발생하여 많은 수의 파티션을 운영하는 경우 짧은 리밸런싱 시간을 가져감
블루/그린 배포는 파티션 개수, 컨슈머 개수가 동일한 경우에 사용할 수 있다.
2) 롤링 배포
블루/그린 배포의 인스턴스 할당과 반환으로 인한 리소스 낭비를 줄이면서 무중단 배포를 할 수 있다.
파티션 개수가 인스턴스 개수와 같거나, 그보다 많아야 한다.
3) 카나리 배포
카나리 배포를 사용하면 많은 데이터 중 일부분을 신규 버전의 애플리케이션에 먼저 배포함으로써 이슈가 없는지 사전에 탐지할 수 있다.
100개의 파티션으로 운영하는 토픽이 있을 경우 1개 파티션에 컨슈머를 따로 배정하여 일부 데이터에 대해 신규 버전의 애플리케이션이 우선적으로 처리하는 방식으로 테스트할 수 있다.
카나리 배포로 사전 테스트가 완료되면 나머지 99개 파티션에 할당된 컨슈머는 롤링 또는 블루/그린 배포를 수행하여 무중단 배포가 가능하다.
참고 : https://devfunny.tistory.com/797
4.4 스프링 카프카
- 스프링 카프카 프로듀서
스프링 카프카 프로듀서는 카프카 템플릿(Kafka Template) 클래스를 사용하고 이는 프로듀서 팩토리(ProducerFactory) 클래스를 통해 생성합니다.
사용하는 방법은 두 가지가 있습니다.
스프링 카프카에서 제공하는 기본 카프카 템플릿 사용
직접 사용자가 카프카 템플릿을 프로듀서 팩토리로 생성해서 사용
- 스프링 카프카 컨슈머
스프링 카프카의 컨슈머는 기존 컨슈머를 크게 2개의 타입으로 나누고 커밋을 7가지로 나누어 세분화했습니다.
리스너 타입에 따라 한번 호출하는 메서드에서 처리하는 레코드의 개수가 달라집니다.
레코드 리스너(MessageListener) : 단 1개의 레코드 처리
Record 인스턴스 단위 프로세싱, 오토 커밋 또는 컨슈머 컨테이너의 AckMode를 사용하는 경우
디폴트 값
배치 리스너(BatchMessageListener) : 기존 카프카 클라이언트의 poll 메서드로 리턴받은 ConsumerRecords 처럼 한 번에 여러 개의 레코드를 처리
Records 인스턴스 단위로 프로세싱, 오토 커밋 또는 컨슈머 컨테이너의 AckMode를 사용하는 경우
스프링 카프카 컨슈머의 기본 리스너 타입은 레코드 리스너이고 아래와 같이 파생된 여러 형태가 있습니다.
AcknowledgingMessageListener
Record 인스턴스 단위 프로세싱, 매뉴얼 커밋을 사용하는 경우
ConsumerAwareMessageListener
Record 인스턴스 단위 프로세싱, 컨슈머 객체를 활용하고 싶은 경우
AcknowledgingConsumerAwareMessageListener
Record 인스턴스 단위 프로세싱, 매뉴얼 커밋을 사용하고 컨슈머 객체를 활용하고 싶은 경우
BatchAcknowledgingMessageListener
Records 인스턴스 단위 프로세싱, 매뉴얼 커밋을 사용하는 경우
BatchConsumerAwareMessageListener
Records 인스턴스 단위로 프로세싱, 컨슈머 객체를 활용하고 싶은 경우
BatchAcknowledgingConsumerAwareMessageListener
Records 인스턴스 단위로 프로세싱, 매뉴얼 커밋을 사용하고 컨슈머 객체를 활용하고 싶은 경우
메뉴얼 커밋을 사용할 경우에는 Acknowledging이 붙은 리스너를 사용하고, Kafka Cosumer 인스턴스에 직접 접근하여 컨트롤하고 싶다면 ConsumerAware가 붙은 리스너를 사용하면 됩니다.
스프링 카프카에서는 커밋이라고 부르지 않고 AckMode라고 부릅니다.
