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

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

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

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

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

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

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

심화 첫시간이다. 기본개념에서 짚었던 프로듀서 컴포넌트의 동작방식과 배치 처리, 캐시등에 대해 상세히 설명하고 있다.

요약

Producer ACKS 설정: 0,1 all(-1)

• 프로듀서는 어떻게 카프카가 메시지를 잘 받았는지 알 수 있을까? 에 대한 궁금증이 해결되는 부분이다.
• `acks=0`:
  • 아예 ack가 없음
  • 빠른 전송이 우선이지만 메시지 유실 가능성이 존재한다.
  • 즉, 메시지 손실이 다소 있더라도 빠른 전송이 필요한 경우 사용(이런 경우가 필요할까..ㄷㄷ)
• `acks=1`(기본값):
  • 리더 브로커 확인 후 응답.
  • 리더가 프로듀서에 응답후에, 팔로워가 복제하기전에 리더 장애 시 데이터가 유실된다
  • At most once : 최대 한 번 보장
•  `acks=all`
  • all, -1 모두 동일
  • 메시지가 모든 Replica에 커밋되면 ack를 보냄
  • 모든 복제본 저장 확인하므로 리더 장애시에도 데이터 데이터 안전성 최대
  • 대기 시간이 더 길고 특정 실패 사례에서 반복되는 데이터 발생 가능성
  • At least onece : 최소 한 번  보장

Producer  Batch처리

• 메시지를 모아서 한 번에 전송
• RPC(Remote Procedure Call)수를 줄인다 
• Broker가 처리하는 작업이 줄어들기 때문에 더 처리량이 올라간다.
• 배치 처리 옵션
  • `linger.ms`:
    • 메시지가 함께 배치 처리 될 때까지 대기시간
    • 기본값: 0ms   → 즉시 전송
  • `batch.size`:
    • 보내기 전 배치  최대 크기
    • 기본값: 16KB
  • 일반적인 설정
    • `linger.ms`: 100
    • `batch.size`: 1000000(백만) → 97.77kb ≈ 100kb

메시지 순서 보장

• 가장 관심이 있던 부분이기도 하다.. rabbitmq에서 메시지 순서를 보장하면 완전 처리량이 떨어지기 때문에
• 진행중(in-flight: 네트워크중, bulk에서 묶이고 있는 중)에 여러 요청을 retry → 순서가 변경될 수 있음
• ex:
  • 기본값 `max.in.flight.requests=5` 상태 → batch0~ batch4까지 나감
  • batch0이 실패했지만 batch1이 성공하는 경우 batch1이 먼저 commit log에 추가 되어 순서가 달라짐
  •  
• `enable.idempotence=true` 설정 (강의에 는 실패부분만 있어서 인터넷 검색 겁나게 함)
  
  • Idempotence(멱등성)
  • 프로듀서가 동일한 메시지를 여러번 전송하더라도
    브로커에 해당 메시지가  정확히 한 번만 저장되도록 보장.
  • 중복메시지 방지와, 메세지 순서 보장 
  • 하나의 배치가 실패하면?
    • 같은 파티션으로 들어오는 후속 배치들도 `OutOfOrderSequenceException`과 함께 실패
  • 동작방식
    • 브로커에 고유한 PID 할당
    • 메시지 전송시 순차적 SeqNo
    • 브로커는 각 파티션별로 PID+SeqNo를 Trace → 중복 메시지 거부
  • 재시도 안정성 높음:
    • 네트워크 장애, 브로커 장애가 발생해도 안전하게 재시도 및 중복 없는 데이터 처리
  • 단점
    • 브로커가 PID+SeqNo Trace 및 관리 → 추가적 오버헤드
    • 고성능시 처리량 감소, 지연시간 증가
    • 세션 제한 : 단일 프로듀서 세션내 보장
      
      • 프로듀서가 재시작 되면 새로운 PID가 할당 → 이전 세션의 멱등성이 유지되지 않음
      • 해결법 : Kafka 트랜잭션 기능을 추가적으로 사용(이런 것도 있네...)

Page Cahe

• 메시지는 파티션에 기록되고 파티션은 Log Segment File로 구성된다.
• 성능을 위해 Log Sementsms OS Page Cache에 기록된다
  • OS Page Cache
    • OS에서 Disk I/O를 최적하기 위해 사용되는 영역
    • 파일 읽을 때 캐시에 저장 → 동일 파일 접근시 디스크 대신 메모리에서 읽음 → 속도 향상
    • 쓰기 → 메모리 캐시에 저장 → 배치로 delayed write 
  • 카프카 관점
    • 카프카 브로커가 로그 세그먼트 파일을 i/o 할때 캐시를 통해 디스크 접근 없이 메모리 에서 빠르게 처리
    • 카프카는 로그를 순차적으로 씀 → 배치 디스크 write에서 쓰기 성능 대폭 향상
    • 캐시로 IO가 전체적으로 최소화
    • 주기적 Flush → 데이터 지속성 확보
  • Zero Copy → 고성능
    • 네트워크 버퍼에서 Page Cache로 CPU개입과 User Space 복사 없이 직접 카피
    • 엄청난 처리량, Broker Heap 메모리 절약

2주차..

• 2주차 에 기본개념을 끝내고 심화 1강...
• 파도파도 새로운 것이 엄청 나온다...
• Zero Copy가 정확히 어떤 방식으로 동작하는지 더 자세한 예시가 있었으면 좋았을텐데.. 내가 이해한게 맞는지 모르겠다.
• 기본값이 아닌 일반적인 설정값을 제시해줘서 너무 감사했다..
• 배치 처리 관련 파라미터(linger.ms, batch.size)에 대해 기본값 만 나와있고, 실제로는 해보면서 바꿔가야한다고 했는데..
  실무에서 어떻게 최적화하는지 나중에는 알려주겠지?? 사실 나는 이게 필요한데..마음이 급하다.
  예를 들어서 Iot기기에서 초당 수만 건의 micro메시지를 보낼때와, 커다란 배치 처리의 대용량 로그 파일 전송때 완전 다를 거 같은데
  극단적인 케이스때의 값을 알려주면 도움이 될거 같은데..이건 삽질을 해야 할까?
• 아직까지는 계속 개념 공부라... 넘어야 할 산이 많고, 따라가기도 힘들다.
• 환급챌린지는 단순하게 똭 결과가 나오는 강의가 좋은데.. 너무 어려운 걸 선택했다..
  후회해도 늦었지만..
• 그래도 돈이 무서워서 열심히 하게 되고 있다... 늘 말하듯 강의 질은 좋은 편이다.(패캠답지않게;)

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

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

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

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

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

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

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

이번 강의는 지난 번의 Replicationrhk 연관된 ISR에 대한 내용이다.. (아마도.. 너무 어렵다..)

요약 (앞 강의랑 연관이 되서 개념 정리부터 ..)

Partition Replication 구조

• Leader Partition: 모든 읽기 쓰기 작업 처리
• Follower Partition:  Leader의 Data를 비동기적으로 복제
• ISR
  • In-Sync Replicas
  • 장애 복구를 위해 리더와 팔로워 파티션이 동기화된 상태를 유지하는 메커니즘
  • High Water Mark 까지 동기화가 완료된 Replication Group
  • Leader 장애시 새로운 Leader를 선출하는데 사용
  • 고가용성을 보장

ISR 옵션

• `replica.lag.max.messages`
  • 해당 옵션의 수까지의 차이가 벌어지지 않은 Follower와 Leader를 ISR로
  • 문제점 : 메시지 유입량이 갑자기 늘어날 때
    
    • 예시 : 평상시 초당 3메세지 이하의 부하에 옵션은 5일때
    • 갑자기 초당 10메세지 이상인 경우 Follower는 Peek에 의한 잠깐 지연이 있을 뿐 정상 작동
    • 하지만 Peek에 이한 지연으로 5이상 차이가 나면 OSR로 잘못 판단하게 되어버림
    • 운영중에 불필요한 에러 발생과 그로 인해 불필요한 Retry가 유발된다
• `replica.lag.time.max.ms`
  • 사실상 유일한 옵션
  • 기본값 10초
  • Follower가 Leader로 Fetch 요청을 보내는 인터벌을 체크하고 Follower의 지연 시간을 판단한다.
  • 기본값인 경우 Follower가 Leader로 Fetch 요청을 10초(10000ms)내에만 요청하면 정상으로 판단
  • 벗어나면 ISR에서 제외 → OSR(Out-of-Sync Replica) 상태 전환
  • 컨트롤러가 주키퍼를 통해 ISR 목록 실시간 갱신

컨트롤러(Controller)

• 카프카 클러스터의 브로커 중 하나가 컨트롤러가 된다
• 컨트롤러는 ZooKeeper를 통해 Broker Liveness(죽었는지 살았는지)를 모니터링 한다.
  (그럼 4.2 부터 쓰는 ZooKeeper를 안쓰는 모드에서는 어떻게 하지?
• 컨트롤러나는 리더와 Replica 정보를 클러스터 내의 다른 브로커에게 전달
• 컨트롤러는 ZooKeeper에 Replicas 정보를 유지한 다음
  더 빠른 엑세스를 위해 클러스터의 모든 브로커들에게 동일한 정보를 캐시함
• 컨트롤러가 리더 장애시 Leader Election 수행
• 컨트롤러가 장애가 난다면?
  • 다른 Active 브로커중에서 재선출
  • ZooKeeper가 하게 됨
    

• Message Commit 과정
  • 프로듀서가 리더에 메시지 전송(Log End Offset 증가
  • 팔로워의 Fetcher 스레드가 주기적으로 데이터 가져옴
  • 모든 ISR 구성원이 메시지 수신 시 High Water Mark 이동
  • 커밋된 메시지만 컨슈머가 읽을 수 있음
• 어제 후기 쓸때 딱 궁금해한 ... 그럼 Leader는 어떻게 뽑는가에 대한 답변이다.
• 개념이 생각보다 어렵다...
• 어제는..DB Replica의 개념에서 그냥 복제본을 더 여러개 만드는 정도로 이해했었는데.. 너무 단순하게 생각...
• 실제로는 리더와 팔로워 간의 실시간 동기화 상태를 추적하고 장애 시 빠르게 대응하는 정교한 원리가 숨어있다.
• 특히 메시지 랙의 문제점과  그 해결책으로 `replica.lag.time.max.ms` 설정을 통해
  네트워크 지연을 유연하게 처리하는 부분이 들어온다.
• 강사님이 천천히 설명을 해주는데 진짜 머리에 안들어온다.
  진짜 강의 공유자료인 슬라이드의  그림이 없었다면..아직도 이해를 못했을 듯
• 강의 슬라이드에서 커밋 메시지 과정은 정말 하나하나 슬라이드를 나눠주셔서
  커밋된 메시지와 아직 복제 중인 메시지를 시각적으로 구분하는 방식이 머릿속에 잘 정리되더라.
• 컨슈머가 항상 안전한 데이터만 읽을 수 있도록 보장하는 메커니즘이 녹아 있다.
• 카프카가 복잡한 문제들을 해결하는 것을 알게 되고 학습하게 된건 좋은데 계속 분산 시스템의 복잡성을 더 느끼게 된다.
• 지금 이해 단계인데 따라가기가 버겁다... 과연 내가 따라갈 수 있을 것인가...

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

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

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

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

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

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

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

이번 강의는 Apache Kafka의 복제(Replication) 메커니즘에 대해 설명하고 있다.. (점점 어렵다... 이게 기초인가..)

요약

Broker 장애 대비 방법 : Replication

• Partition을 복제하여 다른 Broker에 복제본(Replicas)을 만들어 장애에 대비한다.
• 이 부분은 DB Replication과 유사한 부분이 있어서 이해가 쉬웠다.

Leader and Follower

• 각 Partition에는 Leader와 Follower가 존재한다.
• DB Replication의 Master-slave와 비슷(절대 같지 않다. 그냥 개념으로써 이해하자)
• Producer는 Leader에만 쓰고 Consumer는 Leader에서만 읽는다..
• Leader에 장애가 발생하면 Follower 중 새로운 Leader를 선출한다.
• Producer와 Consumer는 새로운 Leader에서 계속 작업을 진행한다.

Partition Leader에 대한 자동 분산(Auto Leader Rebalancing)

• 하나의 Broker에 Leader가 몰린다면? → 리더 불균형(Leader Imbalance)
  • 해당 Broker에 모든 프로듀서와 컨슈머가 붙게 된다
    위에서 말했듯이 Producer와 Consumer는 Leader에서만 작업하기 때문.
     → 해당 Broker는 부하 집중된 Hot SPOT이 되어버림
  • 나머지 장비들은 ? 노는 장비가들이 되어버림
• Auto Leader Rebalancing 
  • Partition Leader를 자동으로 분산
  • 특정 Broker에 부하가 집중되는 것을 막아 Hot Spot을 방지
  • 주요 옵션
    
    • `auto.leader.rebalance.enable`: 자동 분산 활성화 옵션[기본값 : enable]
    • `leader.imbalance.check.interval.seconds`: 리밸런싱 체크 주기 설정→ Leader Imbalance 체크 [기본값 300초]
    • `leader.imbalance.per.broker.percentage`:
      • 브로커별 허용 가능한 불균형 비율을 지정
      • 이를 초과하면 자동으로 리밸런싱이 트리거
      • 기본값 : 10
      • Leader Imbalance가 10%를 넘어가면 리밸런싱 작업 시작

Rack Awareness

• 복제본을 다른 Rack에 분산 → Rack 장애 대비
• Broker의 묶음이므로 Rack이 될 수 있지만 AZ(Avaliable Zone)으로 장애 대비를 할 수도 있다.
• 동일한 Rack 혹은 AZ의 Broker에 동일한 "rack name" 지정
• 복제본(Replica-?leader/Follower)는 최대한 Rack 혹은 AZ간에 균형을 유지하며 장애를 대비한다

그동안엔 학습후기에 요약을 적으면서 다시 정리가 되었는데..오늘은 정리를 해도 안들어온다..

• 카프카 복제 메커니즘에 대한 개요 소개  혹은 찍먹 정도인데.. 개념이 아리송하다.. 
• 카프카가 장애에 대비하는 부분은 DB 레플리카와 비슷한 부분이 있어서 그런식으로 이해했다.
• 데이터가 복제되면 저장공간이 더 많이 필요하고 follower에서 읽어가는 부분에서 네트워크 트래픽도 선형적으로 증가할 거 같은데
  이것은 어떻게 대응하는 걸까? 어떻게 최적화하지..? 계속 고민만 생긴다.
• 장애가 발생했을 때 새로운 Leader를 선출할때 어떤 기준에서 선출하는지는 아직 설명되지 않았다.
• 자동 분산[Rebalance]도 신기하다. 이게 Default라는 게 대단..이 값들은 이 기본값들을 그대로 써도 되는지도 궁금하다.
• Rack Awareness라는 개념도 대단하다. 마치 AWS나 Azure의 AZ처럼 데이터 센터의 물리적 구조까지 고려해서 복제본을 배치할 수 있다는 부분이 대단하다. 반대로 그 부분 까지도 고민하고 신경을 써야한다는 점에서는 짜증이 난다.
• 역시 대규모 시스템은 그냥 이뤄지지 않는다.
• 언젠가 대규모 시스템을 직접 설계하고 구현하고 싶다는 부분에서 해당 강의 수강을 시작했는데..
  사실 벌써 기가 죽은 부분도 존재한다... 좋은 기술인데 아직은 어렵고 낯설다..