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


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

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

공부 시작

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

공부 종료

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

clip 4-5

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

실제로 회사 레거시 코드에서 프로듀서를 다시 생성하는 코드가 있다.. 그것도 500만건 세금 계산서에 대해서 한건씩 처리를 하면서 500만개를 새로 만들고 있었다. 물론 지금은 고쳐진 상태다.


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 카프카 라이브러리 디버그 방법 

 

librdkafka: Introduction to librdkafka - the Apache Kafka C/C++ client library

librdkafka is a high performance C implementation of the Apache Kafka client, providing a reliable and performant client for production use. librdkafka also provides a native C++ interface. Table of Contents Performance librdkafka is a multi-threaded libra

docs.confluent.io

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

감동맨

rkaehdaos의 블로그

,

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

 


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

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

공부 시작

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

공부 종료

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

clip 4-4

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

존나 복잡함.. 밑 학습 후기의 다이어그램으로 볼것.


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

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

요약

 컨트롤러

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

컨트롤러 선택

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

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

주키퍼 모드에서는 주키퍼 앙상블과 broker중의 하나가 컨트롤러로 정의되서 앙상블의 리더와 통신한다.

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

KRaft Mode

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

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

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

감동맨

rkaehdaos의 블로그

,

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

 


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

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

공부 시작

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

공부 종료

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

clip 4-3

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

회사에서 큰 개발 서버 2대정도에 여러 vm을 쓰고 있는데 그위에서 테스트는 어려울 듯하다. 쿠버네티스 온프레미스를 개발용으로 설치를 고려해야 할듯


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

브로커 트러블슈팅 첫시간

요약

 트러블 슈팅체크리스트

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

일반적 트러블 슈팅 

 

Confluent Platform System Requirements | Confluent Documentation

The following table lists machine recommendations are for installing individual Confluent Platform components. Confluent Platform supports both ARM64 and X86 hardware architecture. ARM64 is supported in Confluent Platform 7.6.0 and later. Note that the rec

docs.confluent.io

  • 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 들에 존재함

 

블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip 4-2

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

swappiness가 뭔지부터 설명해면 좋을텐데.. 내가 너무 모르는걸까.. 결국 열심히 인터넷 검색으로 정리..


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가 제거되면  이 트러블 슈팅 파트는 의미가 없는것인가?
블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip 4-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

브로커 시스템 메트릭

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

  • 프로듀서:
    • 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일이 넘게 보고 있으니
블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip

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

그러니까 어떻게 세팅하냐고요 id를.... 예시라도 보여줘요.


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

카프카의 Exactly Once Semantics(EOS) 2번째 강의로 아키텍처와 설정 방법을 단계별로 설명한다.

요약

 트랜잭션 핵심 개념

  • 트랜잭션 코디네이터
    • 프로듀서에게 할당되어 PID 관리 및 트랜잭션 상태 추적
    • 컨슈머 그룹 코디네이터와 비슷하게 할당되는 듯
    • 브로커 내의 트랜젹선 코디네이터 스레드
  • 트랜잭션 로그
    • 새롭게 도입된 internal kafkaesque topic
    • consumer offset topic과 유사함
    • 모든 트랜잭션의 영구적이고 복제된 record를 저장하는 트랜잭션 코디네이터의 상태저장소
    •  
  • Transactional ID
    • 프로듀서를 고유하게 식별하기 위해 사용
    • 동일한 ID를 가진 프로듀서의 다른 인스턴스들은 
      이전 인스턴스에 의해 만들어진 모든 트랜잭션에 대해서
      재개 또는 중단할 수 있음
    • 기본값 : 7일

트랜잭션 처리 5단계

  • `initTransactions()`로 코디네이터 탐색
  • PID 획득 및 Epoch 증가(Zombie 프로듀서 방지)
  • Topic Partition 등록(`AddPartitionsToTxnRequest`)
  • 메시지 전송과 오프셋 커밋 동기화(`sendOffsetsToTransaction`)
  • 최종 커밋/중단 표시(`WriteTxnMarkerRequest`)

혼란의 멀티버스...

  • 카프카 트랜잭션 개념을 어제 1번째 시간에 봤을때는 메시징 전송에 롤백이 된다고! 하고 신기해했다.
  • 오늘 설명을 보면서.. 어렵다...  또
  • `transactional.id` 의 예시가 없어서 이해가 어렵다.
    • 테이블에서는 default가 없다고 나오지만 해당 부분이 비어있으면 프로듀서는 Idempotent Delivery만으로 제한된다
    • 그러면 해당 값이 세팅이 되어야 하는데.. 실제 운영환경이나 예시가 전혀 없다..
  • 컨슈머 부분에서도 또 충격인데
    • `isolation.level=read_committed`로 설정하면 커밋된 메시지만 읽는다는 부분은 어제 인지 했다.
    • 컨슈머가 중복해서 데이터 처리하는 것에 보장하지 않는다!~!!
    • 따라서 컨슈머 중복 처리는 따로 로직을 작성해야 한다(Idempotent Consumer)
    • 즉 중복처리 방지를 위한 별도의 멱등성 로직을 작성해야 한다는 것
    • 카프카가 자동으로 해주지 않나? 라고 생각했는데.. 컨슈머 오프셋을 수동으로 관리를 해야 한다는 내용이
      공유자료 pdf에 나와있다.
    • ...실제 프로젝트에서는 어떻게 구현해야 하지..
  • 트랜잭션 데이터 플로우를 보면 숨이 턱 막힌다.

처음 봤을때 숨이 턱..

  • 다만 강의  슬라이드는 위의  그 복잡한 처리 프로세스를 하나 하나씩 설명해서
    그나마 보면서 간신히 흐름은 알 수 있었다.
블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

 

클립20 .. EOS

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

AMO -> ALO -> EOS


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

 Exactly Once Semantics(EOS)에 대한 설명이다. 2개로 나누어져 있는 것 같다.

요약

 Delivery Semantics

  • 최대 한번(At-Most-Once)
    •  메시지 전송 실패 시 재시도하지 않음
    • 데이터 유실 가능성 존재
  • 최소 한번(At-Least-Once)
    • ack가 시간 초과되거나 오류 수신시 메시지가 토픽에 기록되지 않는다고 가정하고
      메시지 전송을 다시 시도할 수 있음
    •  ACK 미수신 시 재전송으로 인한 중복 데이터 발생 가능성 존재
  • 정확히 한번(Exactly-Once)
    •   중복과 유실을 동시에 방지**

EOS 구현 핵심 요소

  • Idempotent Producer
    • `enable.idempotence=true` 설정으로 메시지 고유 식별(Producer ID + Sequence Number)
    • 브로커는 중복 메시지 감지 시 DUP 응답으로 중복 저장 방지
  • Transaction
    • `transactional.id` 설정과 트랜잭션 API 사용
    • Consumer는 `isolation.level=read_committed`로 커밋된 메시지만 수신
  • 주요 사용 사례
    • 금융 거래(송금/결제)
    • 광고 조회수 기반 과금
    • 서비스 간 정산 데이터 전송

와 벽느낀다...

  • Apache Kafka의 Exactly Once Semantics의 기본 설명인데.. 존나 어려움
  • PDF자료는 너무 좋다 는 3가지 방법에 대해 모두 설명하고 있어서 개념은 이해했다.
  • Idempotent Producer와 Transaction의 조합인데... 여기서부터 어렵다
    • Kafka의 Idempotent Producer는 메시지가 중복으로 처리되는 것을 방지하여
       “정확히 한 번만” 메시지를 브로커에 기록하도록 보장하는 기능이다.
      • 각 프로듀서는 고유한 Producer ID (PID)를 부여받고
      • 메시지마다 순차적으로 증가하는 Sequence Number가 포함된다.
      • 브로커는 PID와 Sequence Number를 기반으로 메시지를 추적하며 중복된 메시지를 무시한다
    • Kafka에서 트랜잭션은 여러 메시지를 하나의 작업 단위로 묶어 원자적(Atomic)으로 처리하는 DB 트랜잭션과 비슷한 개념이다.
      • Producer는 `transactional.id`를 설정하여 고유한 트랜잭션을 식별한다..
      • 프로듀서는 Transaction API를 사용해서 개발한다. (현재는 개념 설명이라서 그런지 구체적인 API는 설명하지 않고 있다.)
      • 컨슈머는  `isolation.level`를 `read_committed`(커밋된 메시지만 읽음)으로 설정한다.
  • ACK를 못받으면?
    • 프로듀서는 재시도를 수행한다 
    • `enable.idempotence=true` 설정하지 않으면 브로커의 중복 수신이 되어버렸을 것.
    • `enable.idempotence=true` 설정하였으므로 브로커가 체크하여 메시지가 중복된 것을 확인한다
    • 메시지를 저장하지 않는다(파티션 기록 x)
    • 프로듀서에게 DUP Response를 리턴한다.
블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip 19

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

신난다. 성능 값이다.


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

카프카의 로그 관리에 대한 심화 강의이다. 

요약

 로그 정리 정책 (Log Cleanup Policy)

  • Log는 Consume되어도 지우지 않음
    • 많은 Consumer들이 서로 다른 시간에 Log 데이터를 Consume 할 수 있기 때문에
  • Broker 혹은 Topic 단위로 Cleanup 정책을 설정함
  • log.cleanup.policy 파라미터
    • delete
    • compact
    • delete,compact: 2개 동시 사용
  • 현재 Active Segment의 Log는 cleanup 대상이 아님!

삭제 정리 정책 (Delete Cleanup Policy) : Log Segment 삭제 정책

  • Log Cleaner Thread가 Segment File을 삭제
  • log.cleanup.policy 파라미터
    • delete
  • log.retention.ms : log 보관 주기 (기본값 : 7 일)
  • log.retention.check.interval.ms : log segment를 체크하는 주기 (기본값 : 5 분)
  • segment 파일에 저장된 가장 최신의 메시지가 log.retention.ms 보다 오래된 segment 를 삭제

Topic 메시지 모두 삭제 하는 방법 : retension.ms 활용 : 운영환경에서는 권장하지 않음

  1. Producer와 Consumer를 모두 shutdown
  2. 명령어를 사용하여 해당 Topic의 retention.ms를 0으로 셋
  3. Cleanup Thread 가 동작할 동안 대기 (기본값 5분 마다 동작)
  4. 메시지 삭제 확인 후, 원래 설정으로 원복
주의) 절대 Log File을 직접 삭제하면 안된다. 카프카 깨짐

압축 정리 정책 (Compact Cleanup Policy)

  • 주어진 키의 최신 값만 유지하는 정책
  • 파티션별로 특정 키의 최신 값만 유지하며 압축
  • 시스템 오류 후 상태 복원에 유용
  • 동일한 Key를 가진 메시지가 다른 Partition에 있는 경우
    • 동일한 Key를 가진 여러 메시지가 여전히 있을 수 있음
    • 중복 제거용 기술이 아님

로그 압축 (Log Compaction)

Log Compaction

  • 키가 있는 메시지에 대해서만 작동
  • 압축이 없는 경우 Consumer가 각 키의 최신상태에 도달하기 위해서는 항상 전체 Log를 읽어야 한다.
  • 로그 압축을 사용하면 오래된 데이터를 읽지 않아 최종 상태에 빠르게 도달 가능

Tombstone 메시지: Log Compaction시 특정 Key 데이터 삭제

  • 목적
    • 논리적 삭제 표시
      • 키는 있지만 값이 null인 메시지로 구성
      • 특정 키에 대한 레코드의 논리적 삭제를 나타낸다.
    • 로그 압축 지원
      • 압축된 토픽에서 이전 값들을 실제로 삭제하는데 사용
      • 로그 압축시 특정 키의 데이터를 삭제하는 매커니즘 제공
      • Compaction 사용시에 Key로 K를 가지는 메시지를 지우려면
        • 동일한 Key(K)에 null value를 가지는 메시지를 Topic으로 보내면 됨
  • Consumer는 해당 메시지가 지워지기 전에(기본 1 day), 해당\메시지를 consume할 수 있음
  • 메시지를 지우기 전 보관 기간(기본 1 day)은 log.cleaner.delete.retention.ms 로 조정

log라 함은 tomcat의 log, rabbitmq의 log로.. 에러만 처리하고 압축 보관 및 지워야하는 대상으로 여기게 된다.
하지만 절대 직접 지우면 안된다는 말에 ..순간 다시 개념이 떠올랐다.
카프카의 로그는 단순한 에러메시지나 시스템 기록이 아닌 실제로 메시지 자체를 의미한다는 것을...

 로그가 소비되어도 바로 삭제되지 않는다는 것!
여러 소비자가 서로 다른 시간에 로그 데이터를 소비할 수 있기 때문이라고 한다.
이런 특성 때문에 카프카가 다양한 시스템에서 유연하게 사용될 수 있다는 걸 깨달았다.
하지만 그러기 때문에 더더욱 삭제 정리 정책과 압축 정리가 중요해 보인다.


삭제 정책은 단순히 오래된 로그를 지우는 반면, 압축 정책은 각 키의 최신 값만 유지한다는 점이 인상적이다.
특히 압축 정책이 시스템 오류 후 상태를 복원하는 데 유용하다는 설명을 들으면서,
실제 업무에서 어떻게 활용될 수 있을지 상상해보게 되었다. 다만 실제 운영 이슈에서 버그 재현시에는
전체 메시지가 전부 있어야 완전하게 버그 재현이 가능하지 않을까 싶은데..

로그 압축의 동작 원리를 설명하는 부분에서는 조금 햇갈렸다..
Tail과 Head 영역, Cleaner Point 등의 개념이 처음에는 복잡해 보였지만,
강사님이 자세히 설명해주고 그림을 자세히 살펴보니 조금씩 이해가 되기 시작했다.
역시 만족스럽다.

Tombstone 메시지라는 개념도 처음 들어보는 개념이다.
압축 정책을 사용할 때 특정 키의 데이터를 삭제하는 방법이라고 한다..
실제로 null 값을 가진 메시지를 보내서 데이터를 삭제한다는 아이디어는 그 어디서도 볼 수 없는 부분이다.

혹시 몰라서 인터넷을 뒤져보니까.강의처럼 로그 압축 시나리오에서 압축된 토픽에서 오래된 레코드 제거하고 최신상태 유지할때 사용되는
부분이 있었다. 하지만 더 많은 부분은 분산시스템 동기화나 상태기반 어플리케이션의 특정 키 존재 관리에서 사용하는 등 쓰임새가 다양했다. 해당 부분을 설명안하는 것은 아직 필요가 없으니까 안한 것이었다.. 괜히 검색해서.. 더 머리가 복잡해졌다.

실무에서 사용가능한 성능튜닝에 사용할 값들이 (위 필기에서 나온 것처럼) 나오긴 했다. 하지만
어떤 좀더 사용사례들에 대한 여러 값들과 정책 설정 규칙을 알려주면 좋겠다.

그리고 아무래도 위의 내용은 나중 실습 때 실제로 적용해보고 내용을 봐야 내 것이 되지 않을까 싶다.

블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip18

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


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

Apache Kafka의 로그 파일 시스템에 대한 심화학습이다.

처음에는 기본개념에서 배웠던 카프카의 기본 구조에 대한 리바이벌 및 상세라.. 요약할 필요가 없어보인다...
처음에는 토픽 파티션 세그먼트의 개념에 대해 다시 설명한다.

이후 로그 세그 먼트 파일의 물리적인 방식에 대해 설명하면서 실제로 어떻게 저장하는지 설명한다.
브로커의 server.properties 파일에서 log.dirs 파라미터로 저장 위치를 지정할 수 있다는 점, 그리고 여러 디렉토리를 지정할 수 있다는 점이 포인트이고 comma로 구분한다는 것도 기억할만하다. 각 토믹과 파티션은 log.dirs 아래에 하위 디렉토리로 구성되는 부분이다.

파티션 디렉토리의 로그 파일들의 파일명에도 의미가 있다. 파일명은 각 offset의 시작 값을 가지고  있다.
따라서 각 파일들 명만 봐도 이 파일이 어느 offset에서 어디까지의 데이터를 저장하고 관리하는지를 알 수 있다.

파티션 디렉토리 안에 있는 여러 종류의 파일들도 처음 알게 되었다.
확장자 혹은 파일명으로 구분 되는 거 같은데 최소 4가지 타입이다.

  1. Log Segment File – 메시지와 metadata를 저장(가장 중요)
    1. 해당 세그 먼트 파일의 저장된 첫번째 메시지의 offset이 파일명
  2. Index File – 각 메시지의 Offset을 Log Segment 파일의 Byte 위치에 매핑(인덱스)
  3. Time-based Index File – 각 메시지의 timestamp를 기반으로 메시지를 검색하는 데 사용(시간 기반 인덱스)
  4. Leader Epoch Checkpoint File – Leader Epoch과 관련 Offset 정보를 저장(리더 교체 및 시대 바뀜 정보와 당시 offset)


기본 시간에 배웠던 로그 세그먼트 파일의 롤링 전략에 대해 조금 더 자세히 설명한다.
 log.segment.bytes나 log.roll.ms 같은 파라미터들을 통해 새로운 세그먼트 파일을 만드는 기준을 설정할 수 있다는 점의 복습과 함께
새로운 부분 (인덱스 파일 사이즈도 롤링 대상이 될 수 있다는 부분 등)도 인상적이다.
여전히 실무에서 필요한....이런 설정들이 실제로 시스템의 성능과 관리에 어떤 영향을 미치는지는 알려주지 않는다.

체크포인트 파일이라는 처음 배우는 부분도 나온다.
각 Broker에는 2개의 체크 포인트 파일이 존재하며, 둘다 logs.dirs 디렉토리에 위치한다.

  1. replication-offset-checkpoint
    1. 마지막으로 커밋된 메시지의 ID인 High Water Mark
    2. 우리가 계속 Replica 장애에서 보았던 그 High Water Mark가 저장된 곳이다
    3. 시작시 Follower가 이를 사용하여 Commit되지 않은 메시지를 Truncate
  2. recovery-point-offset-checkpoint
    1. 데이터가 디스크로 Flush된 지점
    2. 복구 중 Broker는 이 시점 이후의 메시지가 손실되었는지 여부를 확인

심화인데 실무 예시가 없어서... 계속 목마르다.

예를 들어, 실제 대규모 시스템에서는 로그 세그먼트 파일의 크기를 어떻게 설정하는 것이 좋은가? 너무 작게 설정하면 파일이 너무 많아질 것 같고, 너무 크게 설정하면 관리가 어려울 것 같은데, 이런 trade-off를 어떻게 결정하는가?
계속 테스트하면 알 수 있겠지만. 그래도 맨땅에 해딩안하려고 비싼 돈 주고 강의 보는 건데... 좀 알려줘.. ㅠㅠ


또 하나 궁금한 점은, Kafka의 이런 로그 파일 구조가 다른 메시징 시스템과 비교해서 어떤 장단점이 있는지에 대해서다.
적어도 시간 기반 인덱스는 장점이 확 있어 보이지만... 다른 부분에 대한 부분은 설명이 조금 부족해 보인다.

블로그 이미지

감동맨

rkaehdaos의 블로그

,

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


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

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

공부 시작

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

공부 종료

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

clip 17

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

컨슈머가 자신의 파티션중 어느 것이 다른 곳으로 재할당 되는지 알지 못한 부분을 Rebalanceing을 2번 수행해서 해결하였다. 와


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

지난 시간에 배웠던 여러 방식중에 Sticky 에 대해 더 집중적으로 공부하는 파트이다.

요약

 Consumer Rebalancing Process : 시간 흐름에 따른 Consumer Rebalance 과정

  • Consumer들이 JoinGroup 요청을 Group Coordinator 에 보내면서 리밸런싱이 시작
  • JoinGroup의 응답이 Consumer들에 전송되고(Group Leader는 Consumer들 정보를 수신)
  • 모든 구성원은 Broker에 SyncGroup 요청을 보낸다
    • Group Leader는 각 Consumer의 Partition 할당을 계산한다
    • 계산 결과를 Group Coordinator에게 전송한다
  • Broker는 SyncGroup 응답에서 각 Consumer별 Partion 할당을 보낸다.

Eager Rebalancing 프로토콜:  오랫동안 사용되었던 방식 →최대한 단순하게 유지하기 위해 만들어짐

  • 각 구성원은 JoinGroup 요청을 보내고 재조정에 참여하기 전에 소유한 모든 Partition을 취소해야 함
  • 안전면에서는 좋지만 그룹의 구성원이 재조정 기간 동안 작업을 수행할 수 없는 단점
  • "Stop-the-World"프로토콜

Incremental Cooperative Rebalancing Protocol

  • 이전 Eager Rebalancing 프로토콜 보다 발전한 방식
  • Revoke 할 Partition만 Revoke 하면 되지 않는가!!!
  • 이상적인 Consumer Rebalancing 프로토콜
  • 문제점 : Consumer는 자신의 파티션중 어느 것이 다른 곳으로 재할당되어야 하는지 알지 못함
  •  

Cooperative Sticky Assignor

  • Incremental Cooperative Rebalancing Protocol의 문제점 해결 : Rebalancing 2번 수행
    • JoinGroup 요청을 보내면서 시작하지만, 소유한 모든 Partition을 보유하고, 그 정보를 Group Coordinator에게 보냄
    • Group Leader는 원하는 대로 Consumer에 Partition을 할당하지만, 소유권을 이전하는 Partition들만 취소함
    • Partition을 취소한 구성원은 그룹에 ReJoin하여 취소된 Partition을 할당할 수 있도록 두 번째 재조정을 트리거
  • Basic Cooperative Rebalancing Protocol:  Apache Kafka 2.4 에서 도입
  • Incremental Cooperative Rebalancing Protocol: Apache Kafka 2.5 에서 도입
    • 빈번하게 Rebalancing되는 상황이거나
    • 스케일 인/아웃으로 인한 다운타임이 우려가 된다면,
    •  최신 버전의 Kafka(2.5 이상)기반으로 사용하는 것을 권장


Eager Rebalancing 프로토콜에 대해 배웠을 때는 좀 당황 스러웠다. 설명이 가장 단순하고 안전한 방식이라고 하는데 ... 모든 파티션을 취소하고 다시 할당한다니,  비효율의 끝판왕이 아닌가? 싶었다.
"Stop-the-World" 문제 때문에 실제 운영 환경에서는 문제가 될 수 있다는 걸 보고 걍 머리속에 지워버렸다..

바로 뒤의  Incremental Cooperative Rebalancing Protocol을 배웠을 때 정말 이거다 싶었다
필요한 파티션만 Revoke한다~ 얼마나 효율적인가.

Incremental Cooperative Rebalancing Protocol

하지만 위의 요약내용대로..  치명적인 이슈가 있었고 그걸 해결한 것이 오늘 주제인 Cooperative Sticky Assignor인 것이다.

처음에는 리밸런싱 2개로 위 치명적인 이슈가 해결된다는게 무슨 소린지 이해가 안되었는데.. 
강사님이 설명을 너무 잘해주셔ㅓㅆ다..  특히 위 필기 캡처에 잠깐 나온
Consumer A, B, C의 예시는 정말 좋은 예시이다.

또한 놀라웠던 부분은 Kafka가 계속해서 발전하고 있다는 것이다.
Apache Kafka 2.4, 2.5 버전에서 이런 새로운 기능들이 추가되었다는 걸 보고,
기술이 얼마나 빠르게 발전하는지 실감했고, 사실 지금은 얼마나 좋은 기능이 나왔을지 또 걱정도 된다..

늘 그렇지만 실무적 궁금증은 늘 목마르다.
Cooperative Sticky Assignor를 사용할 때 실제로 성능이 얼마나 향상되는지 수치로 나오면 좋을텐데..
 그리고 이런 복잡한 리밸런싱 과정에서 발생할 수 있는 에러 상황은 어떻게 처리하는지도 알려주었으면 좋겠는데..

그래도 전체적으로 봤을때  이 강의는  나에게  큰 도움을 주고 있다.
다 돌아다녀도 이렇게 깊은 내용을 이렇게 좋은 예제로 설명하는 것은 처음이다. 
늘 말했지만 패캠 강의답지 않게... 정말 잘만든 강의 같다...
물론 어렵지만.... ㅋ

계속 따라가다보면... 뭔가 배울 수 있을 듯

블로그 이미지

감동맨

rkaehdaos의 블로그

,