[아파치 카프카 애플리케이션 프로그래밍 with 자바] 4-3장 카프카 컨슈머

카프카 컨슈머

멀티 스레드 컨슈머

• 파티션을 여러 개 운영하는 경우, 데이터를 병렬 처리하기 위해서는 파티션, 컨슈머 개수를 동일하게 맞춰야 한다.
• 토픽의 파티션은 1개 이상으로 이루어짐
• 1개의 파티션은 1개 컨슈머가 할당되어 데이터 처리
  • 파티션 개수가 n개라면, 동일 컨슈머 그룹으로 묶인 컨슈머 스레드를 최대 n개 운영 가능
    • n개의 스레드를 가진 1개의 프로세스를 운영
    • 1개의 스레드를 가진 프로세스를 n개 운영

• 어떤 방식으로 운영할지는 개발자의 선택
• 공식적으로 지원하는 라이브러리인 자바는 멀티 스레드를 지원하므로, 자바 애플리케이션을 개발한다면, 멀티 스레드로 동작하는 멀티 스레드를 개발하고 적용하면 좋다.

멀티 스레드 컨슈머 운영 중 고려 사항

• 하나의 컨슈머 스레드에서 예외 상황 (OOM 등등) 이 터질 경우, 프로세스 자체가 종료 -> 다른 컨슈머에 영향을 준다.
  • 컨슈머 스레드가 비정상적으로 종료될 경우, 데이터 처리에서 중복 또는 유실 발생 가능
• 각 컨슈머 스레드 간 영향을 미치지 않도록 Thread-Safe 하게 적용하자.
• 이 외에도 다양함. 가장 효율적인 컨슈머를 운영하려면 멀티 스레드로 동작하는 멀티 컨슈머 스레드 애플리케이션을 안정적으로 지속 운영 가능하게 개발하면 된다.

컨슈머를 멀티 스레드로 활용하는 방식

• 멀티 워커 스레드 전략
  • 컨슈머 스레드는 1개만 실행
  • 데이터 처리를 담당하는 워커 스레드 (Worker Thread) 를 여러 개 실행
• 컨슈머 멀티 스레드 전략
  • 컨슈머 인스턴스에서 poll() 함수를 호출하는 스레드를 여러 개 띄어서 사용

• 멀티 스레드 사용 시 각기 다른 레코드들의 데이터 처리 동시에 가능함. -> 시간이 절약 된다.
• 멀티 스레드를 생성하는 ExecutorService 라는 자바 라이브러리 사용 시 레코드를 병렬 처리하는 스레드를 효율적 생성 및 관리 가능.

• 하나의 파티션은 동일 컨슈머 중 최대 1개까지 할당, 하나의 컨슈머는 여러 파티션에 할당 가능
• 이 특징을 이용하려면 1개의 애플리케이션에 구독하고자 하는 토픽 파티션 개수만큼 컨슈머 스레드 개수를 늘려서 운영하는 것.
• 컨슈머 스레드를 늘려서 운영 시, 각 스레드에 각 파티션이 할당 됨, 파티션의 레코드들을 병렬 처리 가능
• 구독하고자 하는 토픽의 파티션 개수만큼만 컨슈머 스레드를 운영해야함 -> 주의 해야함
  • 컨슈머 스레드가 파티션 개수보다 많아짐
  • 할당할 파티션 개수가 모자람
  • 파티션에 할당되지 못한 컨슈머 스레드는 데이터 처리 안하고 놀게 됨.

컨슈머 랙

• 토픽의 최신 오프셋 (LOG-END-OFFSET) 과 컨슈머 오프셋 (CURRENT-OFFSET) 간의 차이
• 컨슈머가 정상 동작하는지 여부 확인 가능, 애플리케이션 운영 시 필수적으로 모니터링 해야 하는 지표.

• 컨슈머 랙은 컨슈머 그룹, 토픽, 파티션 별로 생성됨
• 1개의 토픽에 3개 파티션, 1개의 컨슈머 그룹이 토픽을 구독 후 데이터를 가져가면 컨슈머 랙은 총 3개

• 프로듀서가 보내는 데이터 양이 컨슈머 데이터 처리량보다 크다면 컨슈머 랙은 늘어남
• 적다면, 컨슈머 랙은 줄어들고 최소 값은 0 -> 지연이 없음을 뜻함.
• 컨슈머 랙을 모니터링하면서 컨슈머의 장애를 확인 및 파티션의 개수를 정하는 데 참고 가능

컨슈머 랙 확인 방법

• 카프카 명령어 사용
  • 단점 : 일회성에 그침, 지표를 지속적으로 기록하고 모니터링 하기엔 좀 아쉽다.
• 컨슈머 애플리케이션에서 metrics() 메서드 사용
  • 단점 :
    • 컨슈머가 정상 동작할 경우 확인 가능
    • 모든 컨슈머 애플리케이션에 컨슈머 랙 모니터링 코드를 중복해서 작성해야함.
    • 컨슈머 랙을 모니터링 하는 코드를 추가할 수 없는 Third Party 애플리케이션의 컨슈머 랙 모니터링이 불가함.
• 외부 모니터링 툴 사용
  • Datadog, Confluent Control Center 와 같은 카프카 클러스터 종합 모니터링 툴을 사용하는 방식과 컨슈머 랙 모니터링만을 위한 툴인 Burrow 사용 가능
  • 모니터링 툴들은 클러스터와 연동되어 컨슈머의 데이터 처리와 별개로 지표를 수집하기 때문에 데이터를 활용하는 프로듀서나 컨슈머의 동작에 영향을 미치지 않음

컨슈머 랙 모니터링 아키텍처

• 일반적으로 Burrow 를 통해 컨슈머 랙을 모니터링 시, 이미 지나간 컨슈머 랙을 개별적으로 모니터링 하고 싶다.
  • 별개의 저장소와 대시보드를 사용해보자.

컨슈머 배포 프로세스

중단 배포

• 컨슈머 애플리케이션을 완전히 종료 후 개선된 코드를 가진 애플리케이션을 배포하는 방식

• 한정된 서버 자원을 운영하는 기업에 적합

• 장점

  • 새로운 로직이 적용된 신규 애플리케이션의 실행 전후를 명확하게 특정 오프셋 지점으로 나눌 수 있음.
  • 신규 배포한 애플리케이션에 이슈가 발생해서 롤백할 때 유용함.
    • 롤백을 통해 애플리케이션으로 원복하고, 데이터를 재처리하기 위해 기본 앱이 처리 완료했던 오프셋으로 재지정하면 되기 때문.

• 중단 배포는 컨슈머 애플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식이다.

• 이 방법은 한정된 서버 자원을 운영하는 기업에 적합하다.

• 중단 배포를 사용할 경우 새로운 로직이 적용된 신규 애플리케이션의 실행 전후를 명확하게 특정 오프셋 지점으로 나눌 수 있다는 점이 장점이다.

• 이러한 특징은 신규 배포한 애플리케이션에 이슈가 발생해서 롤백할 때 유용하다.

• 롤백을 통해 기존 애플리케이션으로 원복하고 데이터를 재처리하기 위해 기존 애플리케이션이 처리 완료했던 오프셋으로 재지정하면 되기 때문이다.

무중단 배포

• 무중단 배포는 인스턴스의 발급과 반환이 다소 유연한 가상 서버를 사용하는 경우에 유용하다.
• 무중단 배포는 3가지 방법이 있다.

• 블루/그린
• 이전 버전 애플리케이션과 신규 버전 애플리케이션을 동시에 띄워놓고 트래픽을 전환하는 방법이다.
• 이 방식은 파티션 개수와 컨슈머 개수를 동일하게 실행하는 애플리케이션을 운영할 때 유용하다.
  • 신규 버전 애플리케이션을 배포하고 동일 컨슈머 그룹으로 파티션을 구독하도록 실행하면 신규 버전 애플리케이션의 컨슈머들은 파티션을 할당 받지 못하고 유휴 상태(idle)로 기다릴 수 있기 때문이다. (여차하면 다시 돌리면된다)
  • 블루/그린 배포는 리밸런스가 한 번만 발생하기 때문에 많은 수의 파티션을 운영하는 경우에도 짧은 리밸런스 시간으로 배포를 수행할 수 있다.
• 롤링
• 인스턴스 할당과 반환으로 인한 리소스 낭비를 줄이면서 무중단 배포를 할 수 있다.
• 2개의 인스턴스 중 1개의 인스턴스를 신규 버전으로 실행하고 모니터링한 이후에 나머지 1개의 인스턴스를 신규 버전으로 배포하여 롤링 업그레이드를 진행할 수 있다.
• 파티션 개수가 많을수록 리밸런스 시간도 길어지므로 파티션 개수가 많지 않은 경우에 효과적인 방법이다.
• 카나리(canary)
  • 일부분을 신규 버전의 애플리케이션에 먼저 배포함으로써 이슈가 없는지 확인 후 나머지를 배포하는 방식
  • 사전 배포한 애플리케이션의 테스트가 완료되면 나머지 배포해야할 대상들은 롤링 또는 블루/그린 방식중 한가지로 배포하면 된다.