'2025/03/16'에 해당되는 글 1건

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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메시지를 보낼때와, 커다란 배치 처리의 대용량 로그 파일 전송때 완전 다를 거 같은데
  극단적인 케이스때의 값을 알려주면 도움이 될거 같은데..이건 삽질을 해야 할까?
• 아직까지는 계속 개념 공부라... 넘어야 할 산이 많고, 따라가기도 힘들다.
• 환급챌린지는 단순하게 똭 결과가 나오는 강의가 좋은데.. 너무 어려운 걸 선택했다..
  후회해도 늦었지만..
• 그래도 돈이 무서워서 열심히 하게 되고 있다... 늘 말하듯 강의 질은 좋은 편이다.(패캠답지않게;)