Chapter 07. 카프카 운영과 모니터링

[LOG-INFO]

• Zookeeper 구성
  • 안정적인 Quorum 구성을 반드시 홀수로 구성
    • 최소 3 대
    • 권장 5 대
  • 물리 메모리 4~8GB
    • Heap: 1~2GB
    • 나머지는 OS 영역에 사용
      • OS 영역에 사용할게 뭐가 있지
  • 디스크 240GB or 480GB SSD
    • 트랜잭션이나 스냅샷 로그 저장
  • 네트워크카드 1G 이더넷 카드
    • 카프카와 메타데이터만 주고 받으니 네크워크 사용량 높지 않음
• Kafka Broker 구성
  • Quorum 방식 구성이 필요하지 않아 홀수일 필요 없음
  • 하지만 권장 replication-factor수인 3으로 구성하기 위해 최소 3대 이상 필요
  • Core 많은 CPU 권장 (고성능보단 core 수)
    • CPU 사용량 높은 편
      • 처리량을 높이기 위해 배치와 압축 많이 사용
  • 물리 메모리 최소 6GB, 권장 32~256GB
    • 카프카 Heap 메모리 6GB 이상 필요
    • 나머지 메모리는 빠른 처리를 위해 페이지 캐시로 사용
  • 디스크는 SSD, SAS, SATA, NAS 등 아무거나 사용해도 됨
    • 의외네, 무조건 SSD 사용해야할 줄 알았는데
    • 아무거나 사용해도 높은 성능을 유지하는 이유는, Kafka는 append 방식을 사용하기 때문
    • 다만 병렬처리를 위해 약 10개의 디스크 사용 권장
    • 비용과 안정성을 고려해 NAS는 비권장
  • 네트워크카드 10G 이더넷 카드
    • 브로커 한 대당 네트워크 사용량 비율이 505가 넘지 않도록 최대한 토픽을 분산해 운영
    • 디스크 장애 복구 or 신규 브로커 추가 시 대량의 데이터 이동 발생하는 것 대비
• 모니터링 시스템 구성
  • 애플리케이션 로그 분석
    • server.log: 브로커 설정 정보와 정보성 로그
    • state-change.log: 컨트롤러로부터 받은 정보
    • kafka-request.log: 클라이언드로부터 받은 정보
    • log-cleaner.log: 로그 컴팩션 동작 로그
    • controller.log: 컨트롤러 관련 로그
    • kafka-authorizer.log: 인증 관련 로그
  • Node-Exporter
    • 브로커의 하드웨어 리소스 모니터링 (CPU, Memory, Disk, Network, ...)
    • 카프카 브로커와 별도로 실행
  • JMX-Exporter를 이용한 매트릭 분석
    • per Cluster
    • TopicCount
    • PartitionCount (per cluster)
    • ActiveControllerCount
    • UnderReplicatedPartitions
    • UnderMinIsrPartitionCount
    • per Broker
    • MessageInPerSec
    • BytesInPerSec
    • BytesOutPerSec
    • RequestsPerSec
    • LeaderCount
    • PartitionCount
    • IsrShrinksPerSec
    • etc
    • RequestQueueSize
    • ResponseQueueSize
    • RequestHandlerAvgIdlePercent
    • NetworkProcessorAvgIdlePercent
    • RequestQueueTimeMs
    • LocalTimeMs
    • RemotetimeMs
    • ResponseQueueTimeMs
    • ResponseSendTimeMs

[minkukjo]

카프카 운영

• 카프카 클러스터가 워낙 안정적이긴 하지만 생각보다 고려할 사항이 많다.

주키퍼 운영

• 주키퍼는 최소 3대, 권장은 5대
• 물리 메모리는 4~8GB, 디스크 용량은 240G OR 480G SSD
• 힙 메모리 크기는 1~2GB
• 주키퍼 네트워크는 1G 이더넷 카드정도면 충분
• 주키퍼는 가급적이면 다른 랙에 설치하고, 전원 이중화나 스위치 이중화를 고려해야한다. (작금의 카카오 사태로 인해 이중화의 중요성은 더더욱 올라갔다... )
• AWS를 사용한다면 가용 영역을 2~3개 정도로 분산해서 운영하는 편이 좋다.

카프카 운영

• 카프카 서버는 반드시 홀수일 필요는 없다.
• 최소 3대의 브로커를 운영하자.
• 고성능 CPU 보다는 코어 수가 많은 CPU가 좋다.
• 메모리는 32GB ~ 256GB인데, 일반적으로 JVM 힙 사이즈가 6GB이니 이거보다는 큰 물리 메모리가 필요함.
• 최소 메모리는 32GB, 권장은 128GB OR 256 GB
• 아무래도 토픽 파티션 로그를 저장해야하니, 4TB 용량 이상의 디스크를 사용하는 편이 좋으며, 굳이 SSD를 고집할 필요는 없고 SATA를 선택해도 괜찮음.
• 카프카 네트워크 카드는 10G 이더넷 카드를 구성하는 편이 좋음.
• 브로커 한 대당 네트워크 사용률이 50%가 넘지않도록 토픽을 분산해 운영해야함.
• 주키퍼와 마찬가지도 브로커도 최대한 랙을 분산시키고, 이중화를 적용하자.

모니터링 시스템

• 브로커 서버에 접속해 /user/local/kafka/config/log4j.properties 파일의 로그 레벨 정보를 확인할 수 있다.
• log4j.logger.kafka와 log4j.logger.org.apache.kafka에 옵션을 동일하게 바꿔주자. (궁금한 점 : 근데 두 개의 차이는 뭘까?)
• JMX는 자바로 만든 애플리케이션을 모니터링하기 위한 도구. 이걸로 카프카의 매트릭 정보를 수집할 수 있다. ( 보통 프로메테우스를 사용해서 이 정보를 수집함 )
• 카프카 익스포터를 사용하면 컨슈머 LAG을 모니터링할 수 있다고 한다.
• 역시 프로메테우스 + 그라파나로 이어지는 콤보야 말로 2022년 기준 최고의 모니터링 툴이 아닐까 싶다.

[MinJunKweon]

느낀점

• 이번주는 크게 언급할 것이 없는 챕터인듯
• 주키퍼는 과반수로 지정해야하지만, 브로커는 상관없다. => Kafka 3.0+ 버전에서 주키퍼 의존성이 사라지면서 Broker를 과반수(Quorum)으로 지정해야하도록 변경됨
• 이외에는 술술 읽어 넘겼고 세부사항은 나중에 발췌독해봐야겠다..