본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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의 블로그

,