본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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 들에 존재함

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

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

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

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

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

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

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

ZooKeeper 트러블 슈팅 이다.

요약

 ZooKeeper

• 분산 어플리케이션을 제공하기 위한 인프라 서비스의 필수 구성 요소
• 일반적으로 클러스전체에서 동기화 되어야 하는 구성, 클러스터 리더십, 이름 지정, 및 기타 메타 데이터를 추적하는 일 담당
• 카프카 클러스터의 메타데이터 관리, 컨트롤러 선출, 액세스 제어 등 핵심 기능을 담당하는 분산 코디네이터
• 카프카의 안정성은 ZooKeeper 구성에 직접적으로 영향을 받는다 
• KIP-500 kafka에서 주키퍼가 제거될 예정이지만, 과거 버전에서는 여전히 사용되고 있음

주요 기능

• 토픽 구성 정보 저장
• 브로커 클러스터 멤버십 추적
• 파티션 리더 선출 및 ISR(동기화 복제본) 관리
• 동적 브로커 설정 값 유지

구성시 핵심 고려사항

• 다른 모든 서비스를 동기화 상태로 유지하는 서비스. 따라서
  Latency(대기 시간)이 짧아야 한다.
• 하드웨어 고려사항
  • 많은 하드웨어 리소스를 필요하지 않음
  • 전용 리소스를 제공하는 것이 중요하다.
    • ZK Quorum(쿼럼)의 각 멤버를 위한 전용 서버
    • dataLogDir에 의해 지정된 트랜잭션 로그 디렉터리용 전용 디스크
      • 3개의 전용 드라이브(루트 파일 시스템용, 스냅샷용, 트랜잭션 로그용)로 ZK 서버를 프로비저닝
      • 스냅샷 및 트랜잭션 로그를 SSD에 저장하는 것을 권장
    • 서로 다른 Rack(랙)에 ZK 서버를 구성 권장
      • 동시에 Crash되는 것을 방지하기 위함
    • swappiness를 최소로 낮추거나 비활성화
      • 커널 버전에 따라 다름
      • 최신 Linux 커널에서는 vm.swappiness를 1로 설정하는 것을 권장
    • 충분한 Physical Memory - 통상 8 GB 이상
    • Kafka에 사용된 것과 동일한 JVM 옵션 설정으로 JVM을 조정함
      • 예외: 대부분의 사용 사례에는 1GB의 Heap 사이즈 권장
      • Heap 사용량을 모니터링하여 Garbage Collection으로 인해 지연이 발생하지 않는지 확인(중요)

주키퍼 튜닝 최적화 가이드

• 네트워크:
  • 정적 IP 사용
    • 현재 주키퍼 클라이언트(카프카 포함)가 ip주소를 다시 확인할 수 없음
    • 서버ip 주소가 변경될 수 있는 경우 주키퍼 서버를 호스팅해서는 안된다.
  • 모든 클라이언트가 전체 ZK 서버 연결 가능해야 함
    
    • 연결 끊김으로 인한 디버깅을 피하기 위해 - 디버깅이 엄청 힘들다.
• 하드웨어: 전용 서버, SSD 사용, 물리적 메모리 8GB 이상
• 서비스 구성:
  • 홀수 개의 서버(권장 5대): 3대면 1개의 장애밖에 못버팀
  • JVM 힙 1GB 설정

복구 불구능한 ZK 인스턴스의 장애 복구 프로세스

• 리더 ZK 데이터 백업
• 동일한 myid 파일, 동일 구성으로 새 서버 준비
• 순차적 롤링 재시작 수행
• 만약에!!! ip가 변경되면?!?!?
  • 새 zk 서버 인스턴스에 대한 연결을 다시 확인해야 함
  • 완전히 복구하려면 클러스터의 모든 주키퍼 서버를 순차적으로 다시 시작해야 함
  • 그러니 ip가 변경되지 않도록 하자
• `zk_synced_followers` 값으로 동기화 상태 확인

실습이 필요하다...

• 트러블 슈팅인데.. ㅠ
• 리더 팔로워 상태를 확인하는 명령어가 나오는데..실행을 해볼수가 없구나..
• 실제 스왑 메모리 설정을 권장대로 했을때 실제로 개선이 되는지도 실습해보고  싶은데.. 슬라이드로만 볼 수 있다.
• 트랜잭션 로그와 스냅샷을 분리해서 3개의 전용 디스크를 사용하는 부분이 눈에 띄인다.
• 쿼럼 5대 구성인데.. 이것도 실습에서 실제로 2대를 중지했다가 복구하는 과정에서 클러스터 상태를 봐야는데..
  ...일단은 이론이니 찍먹하자..
• 쿠버네티스의 분산 코디네이터(예: etcd)를 카프카와 함께 사용할 수 있는지도 궁금하다.
• KIP-500으로 ZooKeeper가 제거되면  이 트러블 슈팅 파트는 의미가 없는것인가?

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

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

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

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

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

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

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

새로운 챕터인 트러블 슈팅에서 첫시간으로 카프카 모니터링에 대해 말한다.

요약

 JMX Metrics 모니터링

• Kafka 브로커와 주키퍼는 JMX를 통해 시스템 메트릭을 제공
• 원격 모니터링을 위해선 `KAFKA_JMX_OPTS` 환경 변수 설정 필요\
• 도커 환경에서는 포트 설정과 함께 `confluentinc/cp-zookeeper` 이미지 사용
• 권장 모니터링 도구: Grafana, Datadog, CloudWatch
• https://docs.confluent.io/platform/current/kafka/monitoring.html

주키퍼 모니터링

• https://zookeeper.apache.org/doc/current/zookeeperAdmin.html
•  Four Letter Words 명령어(`stat`, `mntr` 등)로 기본 상태 확인 가능
• `echo mntr | nc localhost 2181` 명령어 실행 시 연결 수/대기 요청 등 실시간 지표 획득
• 주요 메트릭: zk_outstanding_requests, zk_avg_latency, zk_num_alive_connections[1]
• 2
• 3

브로커 시스템 메트릭

• CPU 사용량
• 메모리 사용량
• 사용 가능한 디스크 공간
• DISK IO
• 네트워크 IO
• open된 파일 핸들러들 등 
• https://docs.confluent.io/platform/current/kafka/monitoring.html
• 알림
  • 60% 이상  알림 권장
    • 디스크 60% 이상 등

프로듀서/컨슈머 모니터링

• 프로듀서:
  • request-rate: 초당 전송된 평균 req 수
  • request-latency-avg:  평균 latency(req 대기시간, ms)
  • outgoing-byte-rate: 초당 평균 outgoing/incoming bytes
• 컨슈머:
  • records-lag-max: 해당 모든 파티션의 Record 수 측면의 최대 Lag
  • bytes-consumed-rate: 초당 소비된 바이트
  • fetch-rate: 초당 컨슈머가 브로커에게 가져오는 req 수

---

갑자기 바뀌는 챕터...

• 갑자기 트러블 슈팅과 최적화 챕터가 나온다.. (이건 브록이나 후편에 나와야 하지 않을까?)
• 일단 카프카 모니터링 첫 걸음 시간이다.
• JMX 설정방법과 주키퍼의 모니터링 방법이 나온다.
  (이런건 실제 서버에서 따라 쳐야 익힐텐데....계속 이론만 나오고 있다..)
• 도커의 JMX 설정 예시도 구체적으로 나오긴 하지만..실제 해당 부분은 본인이 해봐야 하는 가보다.
• 여러 메트릭 종류를 설명해준다. 다만 실제 운영 환경에서는 어떤 기준을 위험 수준으로 판단해야 하는지 그런게 없다.
• 슬라이드는 60% 디스크 사용 alert이라고 나오는데.. 60% alert는 너무 과한게 아닌가 싶다.
• 운영에 있어서 특히 어떤 메트릭을 우선순위로 모니터링해야하는지도 알려주면 좋았을텐데.
• 그리고 내가 알기로는 JMX외에 모니터링을 위한 오픈소스 연계도 많은 것으로 알고 있는데 강의에서 다루지 않는다.
  어작 기초라서 그런가?
• 빨리 실습환경에서 실제 모니터링과 메트릭 시각화 하는 단계가 오면 좋겠다.
  이론만 22일이 넘게 보고 있으니