적정 파티션 개수 설정하기
토픽의 파티션 개수는 카프카의 성능과 관련이 있다. 토픽 최처 생성 시 파티션의 개수를 정하는 데에 고려해야 할 점은 3가지가 있다.
- 데이터 처리량
- 메시지 키 사용 여부
- 브로커, 컨슈머 영향도
데이터 처리량 늘리기
파티션의 개수가 많아질수록 매핑되는 컨슈머의 개수가 늘어나기 때문에 효율이 좋지못하다. 그러므로 해당 토픽에 필요한 데이터 처리량을 측정하는 것이 중요하다. 대표적으로 방법은 2가지가 존재한다.
- 컨슈머의 처리량을 늘리는 것
- 컨슈머가 실행되는 서버의 사양을 스케일 업 또는 GC 튜닝
- 단점으로는 일정 수준 이상 처리량을 올리는 것이 매우 어려움
- 파티션 개수를 늘리고 컨슈머를 추가
- 프로듀서가 보내는 데이터양과 컨슈머의 데이터 처리량을 계산해서 파티션 개수를 정한다.
- 더미 데이터로 테스트를 해보는 것이 좋음
토픽 정리 정책
토픽의 데이터는 시간 또는 용량에 따라 삭제 규칙을 적용할 수 있다. 또한 삭제를 원치 않는다면 클러스터가 살아있는 한 토픽의 데이터를 삭제하지 않도록 설정할 수 있다.
카프카의 cleanup.policy는 2가지 정책을 제공한다.
토픽 삭제 정책 (delete policy)
토픽의 cleanup.policy가 delete로 설정되어 있는 상태이며 명시적으로 토픽의 데이터를 삭제하는 것을 뜻한다. 토픽의 데이터를 삭제할 때 세그먼트 단위로 삭제를 진행한다. 세그먼트 단위는 segment.bytes 옵션으로 1개의 세그먼트 단위 크기를 설정할 수 있다.
토픽 압축 정책 (compact policy)
여기서 말하는 압축이란 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 말한다. 메시지 키를 기반으로 데이터를 처리할 경우 유용한데, 이유는 데이터의 흐름이 아닌 가장 마지막으로 업데이트된 메시지 키의 데이터가 중용할 경우 가장 최신의 데이터를 제외한 나머지 데이터를 삭제할 수 있기 때문이다. 압축 시점은 min.cleanable.dirty.ration의 옵션값에 따른다.
프로듀서
카프카에 데이터를 저장하는 첫 단계로, 카프카 클러스터는 3대 이상의 브로커로 이루어져 잇어서 일부 브로커에 이슈가 생기더라도 데이터의 유실을 막을 수 있다. 또한 데이터의 유실을 막기 위해 프로듀서에서 제공하는 다양한 옵션을 함께 사용해야 한다.
acks 옵션
acks 옵션은 0, 1, all(-1)의 값을 가질 수 있으며 이 옵션을 통해 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다.
acks 0 : 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 뜻이다, 프로듀서에는 데이터의 전송이 실패했을 때 재시도를 할 수 있는 retries 옵션을 설정할 수 있는데 acks 0이면 실패햇는지 알 수 없기에 성공한다는 가정을 하고 해야한다.
acks 1 : 프로듀서는 보낸 데이터가 리더 파티션에만 정상적으로 적재되었는지 확인한다. 만약 리더 파티션에 정상적으로 적재되지 않았따면 리더 파티션에 적재될 때까지 재시도를 한다. 하지만 데이터의 유실 위험성은 여전히 존재한다.
acks all(-1) : 프로듀서는 보낸 데이터가 리더 파티션과 팔로워 파티션에 모두 정상적으로 적재되었는지 확인한다. 속도가 느린다는 단점이 있지만 일부 브로커에 장애가 발생하더라도 프로듀서는 안전하게 데이터를 전송하고 저장할 수 있음을 보장한다.
멱등성 프로듀서
멱등성이란 여러 번 연산을 수행하더라도 동일한 결과를 나타내는 것을 뜻한다. 이러한 의미에서 멱등성 프로듀서는 동일한 데이터를 여러 번 전송하더라도 카프카 클러스터에 단 한번만 저장됨을 의미한다.
멱등ㅅ성 프로듀서를 사용하기 위해서는 enable.idempoteence를 true로 설정하면 정확히 한번 적재하는 로직이 성립되기 위해 프로듀서의 일부 옵션들이 강제로 설정된다.
트랜잭션 프로듀서
카프카의 트랜잭션 프로듀서는 다수의 파티션에 데이터를 저장할 경우 모든 데이터에 대해 동일한 원자성을 만족시키기 위해 사용된다. Db의 원자성과 같이 다수의 데이터를 동일 트랜잭션으로 묶음으로써 전체 데이터를 처리하거나 전체 데이터를 처리하지 않도록 하는 것이다. 트랜잭션 프로듀서를 사용하기 위해서는 enable.idempotence = true, transational.id를 임의의 String 값으로 정의하고 컨슈머의 isolation.level을 read_committed로 정의 하면 된다.
카프카 컨슈머
카프카에 적재된 데이터를 처리하며, 컨슈머를 통해 데이터를 카프카 클러스터로부터 가져가고 처리해야 한다.
멀티 스레드 컨슈머
카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있는데 파티션을 여러 개로 운영하는 경우 데이터를 병렬처리하기 위해 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋은 방법이다. 멀티 스레드 컨슈머를 하기 위해서는 고려할 점이 많지만 스레드로 동작하는 멀티 컨슈머 스레드 애플리케이션이 안정적으로 개발된다면 효율적으로 컨슈머를 운영할 수 있다.
컨슈머 멀티 스레드 활용하는 방법 2가지
- 멀티 워커 스레드 전략
컨슈머 스레드는 1개만 실행하고 데이터 처리를 담당하는 워커 스레드를 여러개 실행하는 방법
멀티 워커 스레드를 사용할 때는 리밸런싱, 컨슈머 장애 시에 데이터 유실이 발생할 수 있다는 점이고 레코드 처리의 역전현상이 생길 수 있기 때문에 순서 처리가 중요한 경우 순서가 역전되지 않도록 주의해야 한다.
- 컨슈머 멀티 스레드 전략
컨슈머 인스턴스에서 poll() 메서드를 호출하는 스레드를 여러 개 띄워서 사용하는 방법이다. 하나의 파티션은 동일 컨슈머 중 최대 1개까지 할당이 된다. 그리고 하나의 컨슈머는 여러 파티션에 할당될 수 있다.
컨슈머 랙
컨슈머 랙은 토픽의 최신 오프셋과 컨슈머 오프셋 간의 차이다. 컨슈머 랙은 컨슈머가 정상 동작하는 여부를 확인할 수 있기 때문에 컨슈머 애플리케이션을 운영한다면 필수적으로 모니터링해야 하는 지표이다.
컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성된다. 만약 1개의 토픽에 3개의 파티션이 있고 1개의 컨슈머 그룹이 토픽을 구독하여 데이터를 가져가면 컨슈머 랙은 총 3개가 된다.
bin/kafka-consumer-groups.sh --bootstrap-server 카프카이름:9092 --g
roup 컨슈머그룹 --describe위 명령어를 통하여 컨슈머 랙의 확인할 수 있다.
컨슈머 metrics() 메서드를 사용하여 컨슈머 랙 조회
컨슈머 애플리케이션에서 KafkaConsumer 인스턴스의 metrics() 메서드를 활용하여 컨슈머 랙 지표를 확인할 수 있다. 인스턴스가 제공하는 컨슈머 랙 관련 모니터링 지표는 3가지로 records-lag-max, records-lag, records-lag-avg가 있다.
하지만 metrics를 이용하는 방법에는 3가지 문제점이 있다.
- 컨슈머가 정상 동작할 경우에만 확인할 수 있다.
- 모든 컨슈머 애플리케이션에 컨슈머 랙 모니터링 코드를 중복해서 작성해야 한다.
- 컨슈머 랙을 모니터링하는 코드를 추가할 수 없는 카프카 서드 파티 애플리케이션의 컨슈머 랙 모니터링이 불가능하다.
외부 모니터링 툴을 사용하여 컨슈머 랙 조회
컨슈머 랙을 조회하기 위한 최선의 방법은 외부 모니터링 툴을 사용하는 것이다. 데이터 독, 컨플루언트 컨트롤 센터와 같은 카프카 클러스터 종합 모니터링 툴을 사용하면 카프카 운영에 필요한 다양한 지표를 모니터링 할 수 있다. 또한 컨슈머 랙 모니터링만을 위한 툴로는 버로우가 있다.
카프카 버로우
버로우는 다수의 카프카 클러스터를 동시에 연결하여 컨슈머 랙을 확인할 수 있다. 하지만 단점으로는 모니터링을 위해 컨슈머 랙 지표를 수집, 적재, 알람 설정을 하고 싶다면 별도의 저장소와 대시보드를 구축해야 한다. 버로우에서는 컨슈머와 파티션의 상태를 단순히 컨슈머 랙의 임계치로 나타내지 않는다는 것이다. 임계치가 아닌 슬라이딩 윈도우 계산을 통해 문제가 생긴 파티션과 컨슈머의 상태를 표현한다.
컨슈머 배포 프로세스
카프카 컨슈머 애플리케이션 운영 시 로직 변경으로 인한 배포를 하는 방법은 크게 2가지가 있다.
중단 배포와 무중단 배포이다. 만약 짧은 시간 동안 중단이 되어 지연이 발생하더라도 서비스 운영에 이슈가 없다면 중단 배포를 사용하면 되고, 중단이 발생하면 서비스에 영향이 클 경우는 무중단 배포를 수행하면 된다.
- 중단 배포
중단 배포는 컨슈머 애플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식이다. 한정된 서버 자원을 운영하는 경우 중단 배포가 더 적합하다. 신뢰성 있는 배포 시스템을 가진 기업에서 중단 배포를 사용하는 것을 추천한다. 중단 배포의 장점은 새로운 로직이 적용된 신규 애플리케이션의 실행 전후를 명확하게 특정 오프셋 지점으로 나눌 수 있다는 장점이 있다. (이슈가 발생해서 롤백할 때 유용하다.)
- 무중단 배포
컨슈머의 중단이 불가능한 애플리케이션의 신규 로직 배포가 필요할 경우에는 무중단 배포가 필요하다. 인스턴스의 발급과 반환이 다소 유연한 가상 서버를 사용하는 경우에 유용하다. 무중단 배포는 3가지 방법으로 블루/그린, 롤링, 카나리 배포가 있다.
블루/그린 배포
이전 버전 애플리케이션과 신규 버전 애플리케이션을 동시에 띄워놓고 트래픽을 전환하는 방법이다.
이 방법은 파티션 개수와 컨슈머 개수를 동일하게 실행하는 애플리케이션을 운영할 때 유용하다.
롤링 배포
블루/그린 배포의 인스턴스 할당과 반환으로 인한 리소스 낭비를 줄이면서 무중단 배포를 수행할 수 있다. 롤링 배포의 중요한 점은 파티션 개수가 인스턴스 개수와 같거나, 그보다 많아야 한다는 점이다.
카나리 배포
많은 데이터 중 일부분을 신규 버전의 애플리케이션에 먼저 배포함으로써 이슈가 없는지 사전에 탐지하는 배포 기법이다. 카나리 배포로 사전 테스트가 완료되면 나머지 파티션에 할당된 컨슈머는 롤링 또는 블루/그린 배포를 수행하여 무중단 배포를 진행한다.
