본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://bit.ly/4hTSJNB

I. 학습 인증샷 4장 이상 포함

1. 공부시작: 날짜, 시각 다 나오도록

2. 공부 종료: 날짜 시각 다 나오도록

3. 1개 클립 수강 (강의장 목록 캡쳐, 수강화면이 보이지 않도록) 1장

4. 학습 인증샷 1장(필기 촬영이나 작업물 촬영)

II. 학습 후기 700자 이상 (공백 제외)

Kafka의 Producer  트러블 슈팅에 대한 내용이다.

요약

 Producer Metrics for Troubleshooting

• Kafka Producer의 성능을 진단하기 위해 사용하는 주요 메트릭:
  • 응답률, 요청률, 평균 요청 지연 시간, 출력 바이트 속도, I/O 비율 및 대기 비율, 레코드 재시도 및 오류율 등

일반적인 이슈

• 연결 실패
  • Can not connect to Kafka
  • 단일 Bootstrap 서버만 정의했을 수 있으며, 이 서버에 연결할 수 없음
  • Broker의 잘못 구성된 listeners 및 advertised.listeners
  • Producer(Port 포함)에서 올바른 Endpoint를 사용하고 있는가?
  • Kafka 클러스터에 보안이 적용되어 있는데,
    Credentials을 사용하거나 전혀 Credentials없이 액세스하려고 하는 경우.
• 토픽에 쓰기 실패
  • Can not write to Topic
  • Topic이 존재하지 않으며 Auto Topic Creation이 off 되어 있는 경우.
  • Topic이 ACL에 의해 보호되고, Producer에게 필요한 Authorization(권한)이 없는 경우.
• 프로듀서가 느려지는 경우
  • Producer is very slow
  • 레코드를 보낼 때마다 Producer를 다시 생성하도록 코딩한 경우(동일한 Producer 인스턴스 재사용!)
  • 최적이 아닌 Producer 구성, 특히 batch.size, linger.ms, compression.type, acks
  • Kafka 클러스터에 Quotas(할당량)이 설정되어 있습니까? 처리량이 제한될 수 있음.

일반적인 Producer 관련 문제를 해결하려면, kafkacat 도구가 매우 유용

# Kafka에서 메타데이터(모든 Topic에 대한)를 검색
$ kafkacat -L -b kafka:9092

# CSV 파일의 내용을 iot-data Topic에 기록
$ cat iot_data.csv | kafkacat -P -p -1 -b kafka:9092 -t iot-data

librdkafka 카프카 라이브러리 디버그 방법 

• c 기반의 카프카 라이브러리
• Kafka 디버깅을 위한 다양한 컨텍스트(예: 브로커 상태, 메시지 큐, 보안, 프로토콜 등)를 소개
• https://docs.confluent.io/platform/7.5/clients/librdkafka/html/md_INTRODUCTION.html
• 디버깅 세팅
  • https://docs.confluent.io/platform/7.5/clients/librdkafka/html/md_INTRODUCTION.html#debug-contexts

• 프로듀서의 일반적인 트러블 슈팅과 일반적인 이슈들
• 실제 상황에서 자주 발생할 수 있는 사례들을 다루고 있어 매우 실용적인 듯하다
• 예를 들어, 토픽에 쓰기가 실패하는 경우 권한 문제나 자동 생성 옵션이 꺼져 있는 경우가 있다는 점은 간과하기 쉬운 부분인데
  이를 미리 알고 대비할 수 있는 팁이다.
• 또한 Producer 속도가 느려지는 원인을 배치 크기나 대기 시간 설정 등으로 최적화할 수 있다는 점도 실질적인 팁으로 느껴졌습니다.
  그리고 실제로 회사 코드에서 producer를 new로 생성하는 코드가 있어서.. 뜨끔하다..
• kafkacat 도구는 처음 들어봤는데 간단한 명령어만으로 Kafka 클러스터의 메타데이터를 확인하거나 데이터를 토픽에 기록할 수 있다는 점이 훌륭하다.  이를 통해 Kafka 환경에서 빠르게 테스트하고 문제를 진단이 가능할 것이다.
• 역시 이론만이라. 사실 저런 명령어를 실제로 쳐보지 못하는게 아쉽다.
•  Kafka 클러스터에서 할당량(Quotas)이 설정되어 있을 때 어떤 방식으로 이를 확인하고 조정할 수 있는지도 필요한 것 같은데
• 또한 PDF에서는 보안 인증 문제를 다루었는데, 실제로 Kafka에서 TLS 인증서를 설정하는 과정이 어떤 단계로 이루어지는지 참고 링크라도 추가 되었으면 좋았을 듯하다.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://bit.ly/4hTSJNB

I. 학습 인증샷 4장 이상 포함

1. 공부시작: 날짜, 시각 다 나오도록

2. 공부 종료: 날짜 시각 다 나오도록

3. 1개 클립 수강 (강의장 목록 캡쳐, 수강화면이 보이지 않도록) 1장

4. 학습 인증샷 1장(필기 촬영이나 작업물 촬영)

II. 학습 후기 700자 이상 (공백 제외)

브로커 트러블슈팅 2번째 시간으로 컨트롤러 이슈에 다루고 있다.

요약

 컨트롤러

• 클러스터의 brain
• 클러스터의 하나의 Broker가 Controller 역할을 함
• Broker의 Liveness를 모니터링함
• Broker Fail 시 새로운 Leader 선출
• 새로운 Leader를 Broker들에게 전달

컨트롤러 선택

• 컨트롤플레인과 data 플레인

• ZK Mode
  
  • Controller 선택은 주키퍼 기반
  • 주키퍼에서 /controller 경로를 생성하여 승리한 브로커가 컨트롤러가 된다
  • 모든 파티션 상태는 컨트롤러에 캐시된다
  • 장애조치로 인해 이 상태는 주키퍼에 저장된다

KRaft Mode(https://images.ctfassets.net/gt6dp23g0g38/1zqOqt3czqPKtcTZBcciph/af88c9a1ebefa859cdad5ba2c6399d03/Kafka_Internals_050.png)

• 주키퍼 앙상블이 없음
• 브로커들 중에 컨트롤러 역할을 하는 브로커들의 pool을 구성
• 그 중의 하나가 active로 리더 역할

KRaft Mode는 또 2가지의 모드가 있다. (끝이 없다..;)

• Isolation Mode (control과 data를 분리)
  • 특징:
    • 각 작업이나 프로세스를 독립적으로 실행하여 서로 간섭하지 않도록 설계된 모드
  • 장점:
    • 리소스 충돌 가능성이 낮아 안정적인 운영이 가능
    • 특정 작업이 실패하더라도 다른 작업에 영향을 주지 않음
  • 단점:
    • 리소스 사용량이 증가할 수 있습니다(예: 메모리, CPU 등).
    • 설정 및 관리가 복잡할 수 있음
  • 적용 사례:
    • 고가용성이 요구되는 환경이나 특정 작업 간의 완벽한 격리가 필요한 경우.
    • 컨플루언트등의 회사에서는 운영환경에서는 이 모드만 지원
• Combined Mode
  • 특징:
    • 여러 작업이나 프로세스를 하나의 환경에서 통합적으로 실행하는 모드
    • 장점:
      • 리소스를 효율적으로 사용할 수 있음
      • 설정이 간단하며 관리가 용이
    • 단점:
      • 작업 간 간섭이 발생할 가능성 존재
      • 특정 작업의 장애가 전체 시스템에 영향을 줄 수 있음
    • 적용 사례:
      • 리소스가 제한적이거나, 격리보다는 효율성을 우선시하는 환경.
      • 컨플루언트등의 회사에서는 개발환경등으로 지원

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://bit.ly/4hTSJNB

I. 학습 인증샷 4장 이상 포함

1. 공부시작: 날짜, 시각 다 나오도록

2. 공부 종료: 날짜 시각 다 나오도록

3. 1개 클립 수강 (강의장 목록 캡쳐, 수강화면이 보이지 않도록) 1장

4. 학습 인증샷 1장(필기 촬영이나 작업물 촬영)

II. 학습 후기 700자 이상 (공백 제외)

브로커 트러블슈팅 첫시간

요약

 트러블 슈팅체크리스트

• 어떤 일이 일어나고 있나? : 정확한 이슈 사항
• 정확한 설명: 
• 타임라인: 언제 발생, 언제 시작했는지 (시작시간을 최대한 정확하게 )
• 변경사항 : 관찰된 문제의 발생직전이나 도중에 변경된 사항
  • 비난하는 것이 아니라, 되대한 빨리 근본 원인을 찾는 것
• 모니터링
• node에 대한 ssh
  • broker에 연결할 수 없는 경우 Broker에 실행된 서버나 vm에 ssh login이 가능한가?
  • 로그인할 수 없다면 클러스터 노드에 문제가 있는 것
• 로그 찾기
  • ssh로 연결할 수 있으면 broker의 로그를 찾아라
  • 디폴트 위치에서 찾을 수 없다면 Broker의 log4j.properties파일을 찾아서 정보를 얻어라
• 로그 분석
  • 문제 증상에 대한 정확한 정보를 가지고 있는 것이 좋다

일반적 트러블 슈팅 

• TLS
  • SSL 성능이 좋지 않은 이유 
  • 종종 OS 수준 문제
  • cpu부하가 너무 높다면 코어 추가 필요
• NW
  • java.io broken pipe가 Broker 로그에 보고 됨 - 심각한 네트워크
• Out Of Memory 
  • JVM에 충분한 Heap Memory를 설정하지 않은 경우
  • 각 구성 요소들의 HEAP 권장설정
    • https://docs.confluent.io/platform/current/installation/system-requirements.html

• Security
  • ex: Active Directory integration, Kerberos
  • 많은 보안 관련 문제
  • 원인 : 대부분 이해 부족
• Open File 수 제한
  • 주로 브로커 및 주키퍼 관련, 카프카 커넥트에서 발생
  • OS 수준 뿐 아니라 서비스 수준의 지정 필요

브로커의 주요한 파일들

• recovery-point-offset-checkpoint
  • 디스크에 플러시된 마지막 Offset(from-to)
• cleaner-offset-checkpoint
  • Cleaner가 청소한 마지막 Offset (Compacted Topics만 해당)
• replication-offset-checkpoint 
  • 마지막 커밋된(Committed) Offset(from-to)
• log-start-offset-checkpoint
  • 각 Topic Partition의 First/Earliest Offset
• leader-epoch-checkpoint
  • Per partition
  • epoch 와 offset이 있는 row들을 포함
  • 각 row는 가장 최근에 기록된 Leader Epoch 그리고
    Leader가 된 그 Leader의 최신 Offset에 대한 체크포인트

위 파일들은 Broker의 server.properties 파일의 log.dirs 파라미터로 지정된 각 directory 들에 존재함