DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

카프카 상태 모니터링 및 알림을 위한 효과적인 전략

이 글은 Apache Kafka 클러스터를 효과적으로 모니터링하고 알림을 설정하는 포괄적인 가이드를 제공합니다. 컨슈머 랙, 복제 부족 파티션, 브로커 리소스 사용률과 같은 중요한 지표를 추적하는 방법을 배웁니다. Prometheus와 Grafana 같은 도구를 사용한 실용적인 전략과 가동 중단을 방지하고 이벤트 스트리밍 플랫폼의 상태를 보장하기 위한 사전 예방적 알림 설정에 대한 필수 팁을 알아보세요.

카프카 상태 모니터링 및 알림을 위한 효과적인 전략

카프카 장애는 사후에 분석해보면 대부분 명확한 원인이 있습니다. 브로커 디스크가 가득 차거나, 컨슈머 그룹이 뒤처지거나, 토픽의 리더십이 깔끔하게 전환되지 않거나, 컨트롤러가 플래핑(flapping)을 시작하거나, 네트워크 경로가 느려져 클라이언트가 타임아웃되는 경우 등이죠. 중요한 것은 무해한 일시적 급증(spike)마다 사람들을 호출하지 않으면서도 이러한 신호를 조기에 포착하는 것입니다.

좋은 카프카 모니터링은 몇 가지 핵심 상태 질문으로 시작합니다: 브로커가 요청을 처리할 수 있는가? 파티션이 리더를 선출할 수 있는가? 복제본이 따라잡혀 있는가? 컨슈머가 충분히 빠르게 처리하고 있는가? 클러스터의 CPU, 메모리, 네트워크, 디스크가 부족하지 않은가? 아래 지표들은 이러한 질문에 답을 주기 때문에 유용합니다.

카프카 모니터링이 중요한 이유

카프카의 분산 아키텍처는 잠재적인 여러 장애 지점과 성능 저하 요인을 만듭니다. 이러한 잠재적 문제와 이를 모니터링하는 방법을 이해하는 것은 건강한 클러스터를 유지하는 데 핵심입니다:

  • 데이터 지연(Latency): 높은 컨슈머 랙(consumer lag)은 컨슈머가 프로듀서 속도를 따라가지 못하고 있음을 나타내며, 이는 데이터 부실(stale data)로 이어져 다운스트림 애플리케이션에 영향을 줄 수 있습니다.
  • 리소스 사용률: 브로커의 CPU, 메모리 또는 디스크 공간 부족은 성능 저하, 응답 없음, 심지어 브로커 충돌로 이어질 수 있습니다.
  • 파티션 불균형: 브로커 간 파티션 분포가 고르지 않으면 일부 브로커는 과부하되고 다른 브로커는 활용도가 낮아져 처리량과 가용성에 영향을 줄 수 있습니다.
  • 브로커 가용성: 브로커 장애는 적절히 처리되지 않으면 데이터를 사용할 수 없게 만들거나 손실시킬 수 있습니다. 내결함성을 위해 브로커 상태 모니터링은 가장 중요합니다.
  • 네트워크 문제: 브로커 간 또는 클라이언트-브로커 간 네트워크 분할이나 높은 지연 시간은 클러스터 성능과 안정성에 심각한 영향을 줄 수 있습니다.

모니터링해야 할 주요 카프카 지표

효과적인 모니터링은 올바른 지표를 추적하는 데 달려 있습니다. 이러한 지표는 크게 브로커 수준, 토픽 수준, 클라이언트 수준 지표로 분류할 수 있습니다.

브로커 수준 지표

이 지표들은 개별 카프카 브로커의 상태와 성능에 대한 통찰력을 제공합니다.

  • 요청 지표(Request Metrics):

    • kafka.network.RequestMetrics.RequestsPerSec (수신 요청 비율)
    • kafka.network.RequestMetrics.TotalTimeMs (요청 처리에 소요된 총 시간)
    • kafka.network.RequestMetrics.ResponseQueueTimeMs (응답 큐에서 보낸 시간)
    • kafka.network.RequestMetrics.LocalTimeMs (브로커에서 보낸 시간)
    • kafka.network.RequestMetrics.RemoteTimeMs (다른 브로커와 통신하는 데 보낸 시간)
    • kafka.network.RequestMetrics.TotalBytesInPerSec & TotalBytesOutPerSec (네트워크 처리량)

  • 로그 지표(Log Metrics):

    • kafka.log.Log.Size (디스크의 로그 세그먼트 크기)
    • kafka.log.Log.N.MessagesPerSec (로그 세그먼트에 기록되는 메시지 비율)
    • kafka.log.Log.N.BytesPerSec (로그 세그먼트에 기록되는 바이트 비율)
    • kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs (로그 세그먼트 플러시 비율 및 시간)

  • 컨트롤러 지표(Controller Metrics): (리더 선출 및 파티션 관리에 중요)

    • kafka.controller.Controller.ControllerStateChangesPerSec
    • kafka.controller.Controller.LeaderChangesPerSec

  • JVM 지표: (브로커 리소스 사용량 이해에 필수)

    • kafka.server:type=jvm,name=HeapMemoryUsage
    • kafka.server:type=jvm,name=NonHeapMemoryUsage
    • kafka.server:type=jvm,name=GarbageCollection
    • kafka.server:type=jvm,name=Threads

토픽 수준 지표

이 지표들은 특정 카프카 토픽의 성능과 상태에 초점을 맞춥니다.

  • 복제 부족 파티션(Under-replicated Partitions):

    • kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions (원하는 수보다 복제본이 적은 파티션 수)
    • 이 지표에 대한 알림은 데이터 내구성과 가용성에 매우 중요합니다.

  • 오프라인 파티션(Offline Partitions):

    • kafka.cluster.PartitionState.OfflinePartitionsCount (사용할 수 없는 파티션 수)
    • 높은 수치는 파티션 리더십 또는 브로커 가용성에 심각한 문제가 있음을 나타냅니다.

  • 리더 선출 비율(Leader Election Rate):

    • kafka.controller.Controller.LeaderChangesPerSec (리더 재선출 비율)
    • 급증은 불안정성 또는 브로커 장애를 나타낼 수 있습니다.

컨슈머 그룹 지표

이 지표들은 컨슈머 랙과 애플리케이션의 처리 속도를 이해하는 데 중요합니다.

  • 컨슈머 랙(Consumer Lag): 이는 종종 직접적인 카프카 지표가 아니라, 토픽에 생성된 최신 오프셋과 그룹이 소비한 최신 오프셋을 비교하여 계산됩니다. 모니터링 도구는 일반적으로 이 계산을 제공합니다.

    • 중요 알림: 높은 컨슈머 랙(예: 정의된 임계값을 일정 기간 초과)은 컨슈머가 뒤처지고 있음을 나타냅니다.

  • 가져오기 요청 지표(Fetch Request Metrics, 컨슈머 관점):

    • kafka.consumer.Fetcher.MaxLag
    • kafka.consumer.Fetcher.MinFetchWaitMs
    • kafka.consumer.Fetcher.MaxFetchWaitMs

모니터링 솔루션 구현

카프카를 모니터링하는 데 사용할 수 있는 여러 도구와 접근 방식이 있습니다. 선택은 기존 인프라와 운영 요구 사항에 따라 달라지는 경우가 많습니다.

JMX와 Prometheus

카프카 브로커는 JMX(Java Management Extensions)를 통해 풍부한 지표를 노출합니다. Prometheus와 같은 도구는 jmx_exporter와 같은 어댑터를 사용하여 이러한 JMX 지표를 스크랩할 수 있습니다.

  1. JMX 활성화: 카프카는 일반적으로 기본적으로 JMX가 활성화되어 있습니다. JMX 포트에 접근 가능한지 확인하십시오.
  2. jmx_exporter 구성: jmx_exporter를 다운로드하고 구성하여 카프카 JMX 지표를 Prometheus 호환 형식으로 노출합니다. 스크랩할 MBean을 지정하는 구성 YAML 파일이 필요합니다. jmx_exporter 구성 예시 (카프카 JMX용): jmx_exporter/example_configs/kafka-2-0-0.yml (일반적으로 jmx_exporter 저장소에서 찾을 수 있음)
  3. Prometheus 구성: Prometheus 구성에 카프카 브로커와 함께 실행 중인 jmx_exporter가 노출하는 엔드포인트를 스크랩할 대상을 추가합니다.
    scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['<kafka-broker-ip>:9404'] # jmx_exporter 기본 포트
  4. Grafana로 시각화: Grafana를 사용하여 이러한 Prometheus 지표를 표시하는 대시보드를 구축합니다. 사전 구축된 카프카 대시보드는 Grafana Labs에서 쉽게 찾을 수 있습니다.

카프카 전용 모니터링 도구

  • Kafka Manager (이전 Yahoo Kafka Manager): 카프카 클러스터 관리를 위한 인기 있는 웹 기반 도구입니다. 브로커 상태, 토픽 검사, 컨슈머 랙 모니터링 및 파티션 관리를 제공합니다.
  • CMAK (Cluster Manager for Apache Kafka): Kafka Manager의 포크로, 적극적으로 유지 관리되며 유사한 기능을 제공합니다.
  • Lenses.io / Confluent Control Center: 고급 카프카 모니터링, 관리 및 데이터 시각화 기능을 제공하는 상용 제품입니다.
  • 오픈 소스 카프카 모니터링 스택: 카프카 로그와 함께 ELK 스택(Elasticsearch, Logstash, Kibana) 또는 시계열 데이터용 TICK 스택(Telegraf, InfluxDB, Chronograf, Kapacitor)과 같은 조합입니다.

효과적인 알림 설정

지표가 수집되면 다음 단계는 중요한 조건에 대한 알림을 구성하는 것입니다. 알림 전략은 애플리케이션 가용성, 데이터 무결성 또는 성능에 직접적인 영향을 미치는 문제에 초점을 맞춰야 합니다.

구성해야 할 중요 알림:

  • 복제 부족 파티션 > 0: 잠재적인 데이터 손실 또는 사용 불가능을 나타내는 우선순위가 높은 알림입니다. 즉시 조사가 필요합니다.
  • 오프라인 파티션 수 > 0: 복제 부족 파티션과 유사하게, 완전히 사용할 수 없는 파티션을 의미합니다.
  • 높은 컨슈머 랙: 부실 데이터에 대한 애플리케이션의 허용 오차를 기반으로 임계값을 정의합니다. 특정 기간(예: 5분) 동안 랙이 이 임계값을 초과하면 알림을 보냅니다. PromQL 예시 (Prometheus/Grafana 개념):
    avg_over_time(kafka_consumergroup_lag_max{group="your-consumer-group"}[5m]) > 1000
    참고: 정확한 지표 이름과 랙 계산 방식은 모니터링 설정(예: Kafka 자체 지표, kafka-exporter 또는 클라이언트 측 지표 사용)에 따라 달라집니다.
  • 브로커 CPU/메모리/디스크 사용량: 사용률이 미리 정의된 임계값(예: CPU/메모리 80%, 디스크 90%)을 초과하면 알림을 보냅니다. 디스크 공간은 카프카에서 특히 중요합니다.
  • 높은 요청 지연 시간: RequestMetrics.TotalTimeMs 또는 특정 요청 유형(예: Produce, Fetch)의 지속적인 증가에 대해 알림을 보냅니다.
  • 브로커 재시작/사용 불가: 카프카 브로커에 연결할 수 없거나 지표 보고를 중단할 때 알림을 설정합니다.
  • 리더 선출 비율 급증: 불안정성을 나타낼 수 있는 비정상적으로 높은 리더 선출 비율에 대해 알림을 보냅니다.

알림 도구 통합

Prometheus 설정은 Alertmanager와 같은 알림 관리자와 통합될 수 있습니다. Alertmanager는 중복 제거, 그룹화 및 이메일, Slack, PagerDuty 등 다양한 알림 채널로의 알림 라우팅을 처리합니다.

  • Alertmanager 구성 예시 (alertmanager.yml):
    route:
  group_by: ['alertname', 'cluster', 'service']
  receiver: 'default-receiver'
  routes:
    - receiver: 'critical-ops'
      match_re:
        severity: 'critical'
      continue: true

receivers:
  - name: 'default-receiver'
    slack_configs:
      - channel: '#kafka-alerts'

  - name: 'critical-ops'
    slack_configs:
      - channel: '#kafka-critical'
    pagerduty_configs:
      - service_key: '<your-pagerduty-key>'

카프카 모니터링 및 알림 모범 사례

  • 기준선(Baselines) 설정: 카프카 클러스터의 정상적인 운영 동작을 이해합니다. 이는 의미 있는 알림 임계값을 설정하고 이상 징후를 식별하는 데 도움이 됩니다.
  • 알림 계층화: 즉각적인 조치가 필요한 중요 알림과 검토가 필요하지만 긴급 대응이 필요하지 않은 정보성 알림을 구분합니다.
  • 작업 자동화: 일반적인 문제(예: 디스크 공간 경고)의 경우 안전한 경우 자동화된 수정 단계를 고려합니다.
  • 메타데이터 레이어 모니터링: 구형 카프카 클러스터는 일반적으로 ZooKeeper에 의존하는 반면, 최신 배포는 KRaft 모드를 사용할 수 있습니다. 클러스터가 실제로 사용하는 메타데이터 쿼럼(quorum)을 모니터링하십시오.
  • 네트워크 모니터링: 브로커와 클라이언트 간의 네트워크 연결 및 지연 시간이 허용 가능한 범위 내에 있는지 확인합니다.
  • 대시보드 정기적 검토: 알림에만 의존하지 마십시오. 모니터링 대시보드를 정기적으로 검토하여 알림이 트리거되기 전에 추세와 잠재적 문제를 발견하십시오.
  • 알림 테스트: 알림 시스템을 주기적으로 테스트하여 알림이 올바르게 전송되고 적절한 사람에게 도달하는지 확인합니다.

독자가 조치를 취할 수 있는 증상에 대한 알림

카프카는 많은 지표를 노출하므로 인상적이지만 인시던트 중에 도움이 되지 않는 대시보드를 쉽게 구축할 수 있습니다. 명확한 운영자 조치가 있는 알림부터 시작하십시오.

UnderReplicatedPartitions > 0은 실행 가능한 알림입니다. 이는 하나 이상의 파티션에 예상보다 동기화된 복제본(In-Sync Replica)이 적다는 것을 의미하기 때문입니다. 첫 번째 확인 사항은 브로커 상태, 그 다음 디스크, 네트워크, 복제본 페처 랙(fetcher lag)입니다. 롤링 재시작 중에 빠르게 해결되면 예상된 현상일 수 있습니다. 0이 아닌 상태로 유지되면 내구성 및 가용성 위험으로 취급하십시오.

OfflinePartitionsCount > 0은 더 긴급합니다. 활성 리더가 없는 파티션은 정상적인 프로듀스 또는 페치 트래픽을 제공할 수 없습니다. 이 알림에는 클러스터 및 브로커 컨텍스트가 포함되어야 하며, 프로덕션 클러스터의 경우 페이지를 호출해야 합니다.

컨슈머 랙은 중요하지만 미묘한 차이가 필요합니다. 10,000개의 레코드 랙은 우선순위가 낮은 야간 배치 토픽에서는 무해할 수 있지만 사기 탐지 파이프라인에서는 심각할 수 있습니다. 컨슈머 그룹의 목적에 상대적인 랙에 대해 알림을 보내십시오: 지속적인 랙, 컨슈머가 복구할 수 있는 것보다 빠르게 증가하는 랙, 또는 도구가 계산할 수 있는 경우 예상 지연 시간.

디스크 알림은 카프카가 쓸 공간이 없어지기 전에 발생해야 합니다. 카프카 브로커는 설계상 디스크 집약적인 시스템이며, 디스크가 가득 차면 연쇄적인 문제를 일으킬 수 있습니다. 디스크 사용량 알림을 로그 디렉터리 컨텍스트와 함께 제공하여 당직자가 문제가 하나의 브로커, 하나의 마운트, 또는 클러스터 전체의 보존 정책 문제인지 확인할 수 있도록 하십시오.

실용적인 대시보드 레이아웃

유용한 카프카 대시보드는 일반적으로 여러 계층으로 구성됩니다. 첫 번째 행은 클러스터가 트래픽을 제공하고 있는지 여부를 답해야 합니다: 브로커 수, 오프라인 파티션, 복제 부족 파티션, 컨트롤러 변경, 요청 지연 시간, 프로듀스/페치 오류율.

다음 행은 처리량과 압력을 보여주어야 합니다: 바이트 인, 바이트 아웃, 프로듀스 요청, 페치 요청, 네트워크 프로세서 유휴, 요청 핸들러 유휴, CPU, 메모리, 디스크 사용량, 디스크 I/O. 이러한 패널은 지연 시간 급증이 실제 리소스 제약과 일치하는지 확인하는 데 도움이 됩니다.

세 번째 행은 복제에 초점을 맞춰야 합니다: 복제본 페처 랙, 동기화된 복제본 축소/확장 이벤트, 리더 선출 비율, 브로커별 파티션 분포. 하나의 브로커가 나머지보다 훨씬 더 많은 리더 또는 핫 파티션을 가지고 있다면, 클러스터는 전반적으로 건강해 보일 수 있지만 한 노드는 과부하 상태일 수 있습니다.

네 번째 행은 컨슈머에 초점을 맞춰야 합니다: 그룹 및 토픽별 랙, 초당 소비된 레코드 수, 가능한 경우 리밸런스 비율, 애플리케이션 계측의 컨슈머 오류 지표. 브로커 지표만으로는 컨슈머가 메시지를 가져온 후 느린 데이터베이스 쓰기 내부에서 멈춰 있는지 알 수 없습니다.

명령줄 확인이 여전히 도움이 되는 경우

대시보드가 있더라도 카프카 명령줄 도구는 클러스터가 믿고 있는 것을 확인하는 데 유용합니다.

토픽 파티션 상태 확인:

kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic orders

리더가 누락된 파티션, ISR에 없는 복제본 또는 고르지 않은 리더 배치를 찾으십시오.

컨슈머 랙 확인:

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --describe \
  --group billing-worker

출력은 "전체 그룹이 뒤처져 있는지"와 "하나의 파티션이 멈춰 있는지"를 구분하는 데 도움이 됩니다. 하나의 파티션이 멈춘 경우는 종종 포이즌 메시지, 핫 키 또는 비정상적인 단일 컨슈머 인스턴스를 가리킵니다.

클라이언트가 이상하게 동작할 때 브로커 API 버전 확인:

kafka-broker-api-versions.sh --bootstrap-server broker1:9092

버전 불일치는 상태 인시던트의 가장 흔한 원인은 아니지만, 업그레이드 또는 혼합 버전 롤아웃 후 클라이언트 동작을 설명할 수 있습니다.

시끄러운 카프카 알림 피하기

시끄러운 알림은 일반적으로 다른 클러스터에서 복사된 임계값에서 비롯됩니다. 카프카 워크로드는 보편적인 숫자에 비해 너무 다양합니다. 결제 스트림, 메트릭 수집기(firehose), 배치 가져오기 토픽은 각각 지연 시간 허용 오차, 처리량, 파티션 수 및 보존 기대치가 다릅니다.

자연스럽게 급증할 수 있는 알림에는 지속 시간 창(sustained windows)을 사용하십시오. 예를 들어, 컨슈머 랙은 페이지를 호출하기 전에 몇 분 동안 임계값을 초과해야 할 수 있습니다. 프로덕션의 복제 부족 파티션은 더 짧은 창이 적합할 수 있습니다. 브로커 다운 알림은 계획된 유지보수를 고려해야 하지만, 실제 장애가 눈에 띄지 않을 정도로 공격적으로 숨겨져서는 안 됩니다.

모든 페이지에는 소유자가 있어야 합니다. 브로커 디스크 가득 참은 플랫폼 또는 운영 팀에 속합니다. billing-worker의 컨슈머 랙은 애플리케이션 팀에 속할 수 있습니다. 모든 카프카 알림이 소유권 없이 하나의 채널로 라우팅된다면 사람들은 그것들을 무시하는 법을 배울 것입니다.

메타데이터 레이어 및 버전 차이

많은 기존 카프카 클러스터는 여전히 ZooKeeper를 사용하며, 이러한 클러스터는 ZooKeeper 모니터링이 필요합니다: 쿼럼 상태, 지연 시간, 디스크, JVM 상태 및 연결 수. KRaft 모드를 사용하는 카프카 클러스터는 대신 컨트롤러 쿼럼에 대한 모니터링이 필요합니다. 운영 개념은 동일합니다: 메타데이터 레이어가 비정상이면 브로커 상태는 처음에는 관련 없어 보이는 방식으로 저하될 수 있습니다.

모든 카프카 클러스터가 ZooKeeper에 의존한다는 오래된 지침에 주의하십시오. 그것은 수년 동안 사실이었지만, 최신 카프카 배포에서는 사용하지 않을 수 있습니다. 런북은 실제로 운영 중인 클러스터와 일치해야 합니다.

완벽한 대시보드보다 런북이 더 중요합니다.

런북이 없는 알림은 당직자를 추측하게 만듭니다. 각 중요 알림에 대해 첫 번째 확인 사항, 일반적인 원인 및 에스컬레이션 경로를 작성하십시오. 복제 부족 파티션의 경우 런북은 다음과 같이 말할 수 있습니다: 브로커 연결 가능성 확인, 디스크 사용량 검사, 네트워크 오류 검사, 최근 배포 또는 재시작 확인, 영향을 받는 토픽 식별, 유지보수 일시 중지 여부 결정.

컨슈머 랙의 경우 런북은 다음과 같이 말할 수 있습니다: 랙이 모든 파티션인지 하나의 파티션인지 식별, 컨슈머 배포 상태 확인, 최근 애플리케이션 오류 확인, 다운스트림 종속성 검사, 리밸런스 확인. 단일 파티션이 멈춘 경우 현재 오프셋을 찾고 오프셋을 무작정 건너뛰기보다 내부 도구를 사용하여 메시지를 안전하게 검사하십시오.

좋은 모니터링이 인시던트를 제거하지는 않습니다. 처음 몇 가지 결정을 더 빠르고 덜 감정적으로 만들 뿐입니다.

카프카 상태 모니터링은 모든 지표가 운영 질문에 연결될 때 효과적입니다. 파티션을 사용할 수 있습니까? 복제본이 따라잡혔습니까? 컨슈머가 속도를 유지하고 있습니까? 브로커 리소스가 부족합니까? 컨트롤러 또는 메타데이터 서비스가 안정적입니까? 이러한 질문을 중심으로 대시보드와 알림을 구축한 다음, 다른 사람의 기본값 대신 자체 워크로드에 맞게 임계값을 조정하십시오.