kaiwind7
commented
3 years ago 4. 카프카 상세 개념 설명
4.1 토픽과 파티션
4.1.1 적정 파티션 개수
토픽 생성 시 파티션 개수 고려 사항
- 데이터 처리량
- 메시지 키 사용 여부
- 브로커, 컨슈머 영향도
데이처 처리 속도를 올리는 방법
- 컨슈머의 처리량을 늘리는 것
- 컨슈머를 추가해서 병렬처리량을 늘리는것
프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 * 파티션 개수
컨슈머 데이터 처리량 -> 운영 중인 카프카에서 더미 데이터로 테스트를 해보는 것?
컨슈머 데이터 처리량을 구하고 난 뒤 프로듀서가 보내는 데이터 양을 하루, 시간, 분 단위로 쪼개 예측
메세지 키 사용 여부
4.1.2 토픽 정리 정책(cleanup.policy)
- delete
- compact
토픽 삭제 정책(delete policy)
시간 또는 용량
토픽 압축 정책 (compoct policy)
메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
4.1.3 ISR(In-Sync-Replicas)
ISR : 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태
4.2 카프카 프로듀서
4.2.1 acks 옵션
0 - 프로듀서가 리더 파티션으로 데이터를 전송했을 떄 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다.
1 - 프로듀서는 보낸 데이터가 리더 파티션에만 정상적으로 적재되었는지 확인.
all or -1 - 프로듀서는 보낸 데이터가 리더 파티션과 팔로워 파티션에 모두 정상적으로 적재 되었는지 확인.
토픽 단위로 설정 가능한 min.insync.replicas 옵션값에 따라 데이터의 안정성이 달라짐
4.2.2 멱등성(idempotence) 프로듀서
멱등성 - 여러 번 연산을 수행하더라도 동일한 결과를 나타내는 것을 뜻
동일한 데이터를 여러번 전송하더라도 카프카 클러스터에 단 한 번만 저장됨을 의미
프로듀서가 보내는 데이터의 중복 적재를 막기 위해 0.110 이후 버전 부터는 프로듀서에서 enable.idempotence옵션을 사용하여 ㅈㅇ확히 한번 전달을 지원
4.2.3 트랜잭션(transaction) 프로듀서
다수의 파티션에 데이터를 저장할 경우 모든 데이터에 대해 동일한 원자성을 만족시키기 위해 사용.
원자성을 만족시킨다는 의미는 다수의 데이터를 동일 트랜잭션으로 묶음으로써 전체 데이터를 처리하거나 전체 데이터를 처리하지 않도록 하는 것을 의미
enavle.idempotence 를 true 설정하고 transactional.id를 임의의 String값 설정
4.3 카프카 컨슈머
4.3.1 멀티 스레드 컨슈머
카프카의 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려 운영할 수 있다.
파티션을 여러개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋은 방법이다.
- 멀티 원커 스레드 전략 컨슈머 스레드는 1개만 실행하고 데이터 처리를 담당하는 워커 스레드를 여러개 실행하는 방법
- 컨슈머 멀티 스레드 전략 컨슈머 인스턴스에서 poll() 메서드를 호출하는 스레드를 여러 개 띄워서 사용
4.3.2 컨슈머 랙
토픽의 최신 오프셋(LOG-END-OFFSET)과 컨슈머 오프셋(CURRENT-OFFSET) 간의 차이다.
컨슈머가 정상 동작하는지 확인할 수 있기 떄문에 컨슈머 애플리케이션을 운영한다면 필수적으로 모니터링해야 하는 지표.
컨슈머 랙을 모니터링하는 것은 카프카를 통한 데이터 파이프라인을 운영하는 데에 핵심적인 역할을 한다.
컨슈머 랙을 모니터링함으로써 컨슈머의 장애를 확인할 수 있고 파티션 개수를 정하는 데에 참고할 수 있다.
- 카프카명령어 사용
- 컨슈머 애플리케이션에서 metrics() 메서드를 사용
- 외부모니터링 툴 사용
카프카 명령어를 사용하여 컨슈머 랙 조회
kafka-consumer-groups.sh 사용
./kafka-consumer-groups.sh --bootstrap-server my-kafka:9092 --group my-group --describe
컨슈머 metrics() 메서드를 사용하여 컨슈머 랙 조회
문제점
- 컨슈머가 정상 동작할 경우에만 확인 가능
- 모든 컨슈머 애플리케이션에 컨슈머 랙 모니터링 코드를 중복 작성
외부 모니터링 틀을 사용하여 컨슈머 렉 조회
데이터독, 컨플루언트 컨트롤 센터와 같은 카프카 클러스터 종합 모니터링 툴 사용
4.3.2.1 카프카 버로우
링크드인에서 공개한 오픈소스 컨슈머 랙 체크 툴. 버로우를 카프카 클러스터와 연동하면 REST API 를 통해 컨슈머 그룹별 컨슈머 랙을 조회할 수 있다.
컨슈머 랙 평가 -> 버로우에서 컨슈머 랙의 상태를 표현하는 것
컨슈머 랙 모니터링 아키텍쳐
4.3.3 컨슈머 배포 프로세스
- 중단 배포 - 컨슈머 어플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식
- 무중단 배포 - 컨슈머의 준단이 불가능한 애플리케이션의 신규 로직 배포가 필요할 경우에는 무중단 배포가 필요.
4.4 스프링 카프카
스프링 프레임워크에서 효과적으로 사용할 수 있도록 만들어진 라이브러리.
4.4.1 스프링 카프카 프로듀서
카프카 템플릿(Kafka Template) 클래스 사용하여 전송
카프카 템플릿은 프로듀서 패고리(ProducerFactory) 클래스를 통해 생성
기본 카프카 템플릿
기본 프로듀서 팩토리를 통해 생성된 카프카 템플릿을 사용. 기본 카프카 템플릿을 사용할 떄는 application.yaml에 프로듀서 옵션을 넣고 상용할 수 있음.
커스텀 카프카 템플릿
프로듀서 팩토리를 통해 만든 카프카 템플릿 객체를 빈으로 등록하여 사용. 프로듀서에 필요한 각종 옵션을 선언하여 사용할 수 있으며 한 스프링 카프카 애플리케이션 내부에 다양한 종류의 카프카 프로듀서 인스턴스를 생성하고 싶다면 이방식을 사용.
4.4.2 스프링 카프카 컨슈머
기존 컨슈머를 2개의 타입으로 나누고 커밋을 7가지로 나누어 세분화.
기본 리스너 컨테이너
기본 리스너 컨테이너 팩토리를 통해 생성된 리스너 컨테이너를 사용.
커스텀 리스너 컨테이너
서로 다른 설정을 가진 2개 이상의 리스너를 구현하거나 리밸런스 리스너를 구현하기 위해서는 커스텀 리스너 컨테이너를 사용.
완료 목표