'패캠챌린지/Kafka EcoSystem - 진행중'에 해당되는 글 26건

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

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

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

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

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

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

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

파티션 할당 전략(Partition Assignment Strategy)에 대해 대한 심화 학습이다.

요약

 파티션 할당 전략의 종류:

• RangeAssignor (기본)
• RoundRobinAssignor
• StickyAssignor
• CooperativeStickyAssignor
• 사용자 정의 Assignor

각 할당 전략의 특징:

• RangeAssignor: 토픽별로 작동하며, co-partitioning에 유리
• RoundRobinAssignor: 파티션을 균등하게 분배하지만, 재할당 시 일관성 보장 안 함
• StickyAssignor: 균형적 할당과 기존 할당 유지를 동시에 고려

각 전략의 장단점 비교 및 실제 동작 예시

• 강의 슬라이드에 단계별로 설명이 되어 있는데... 이건 너무 강의 노출인 것 같아.. 적었다 지운다.

파티션 전략에 대한 부분이다.가장 먼저 배운 RangeAssignor는 기본 인데,  토픽별로 작동한다는 게 신기하다.. 특히 'co-partitioning'이라는 개념이 있다는 걸 알게 됐는데, 같은 키를 가진 메시지들을 효율적으로 처리할 수 있다는 점이 포인트 인 것 같다. 실제로 배달 시스템 같은 곳에서 유용하게 쓰일 것 같다.

그 다음으로 배운 RoundRobinAssignor는 이름 그대로 돌아가면서 파티션을 할당하는 방식이다.. 처음에는 이게 제일 공평해 보였는데, 강의를 들으면서 아 존나 멍청했구나라는 걸 인지 했다.. 재할당이 일어날 때 기존 할당을 유지하지 않는다는 점이 단점이다.. 실제 시스템에서는 이런 변경이 성능에 영향을 줄 수 있다는 걸 알게 되고... 실력은 늘었지만..고민할 포인트는 많아졌다..

마지막으로 배운 StickyAssignor가 제일 역시 흥미롭다.. 이름처럼 '끈적끈적하게' 기존 할당을 최대한 유지하면서도 균형을 잡으려고 노력한다는 점이 좋아보인다.. 특히 실제 예시를 통해 설명해주셔서 이해하기 쉬웠다.. 특히 Consumer가 제거되었을 때 어떻게 재할당이 일어나는지 강사님이 보여주신 부분이 좋은 것 같다.

이 강의를 들으면서 가장 놀라웠던 점은 이런 심화내용의 깊은  세부적인 전략들이 실제로 시스템의 성능과 안정성에 큰 영향을 미친다는 것이다. 정말 처음에는 그냥 메시지를 주고받는 게 전부인 줄 알았는데, 이렇게 깊이 들어가보니 카프카가 얼마나 정교하게 설계된 시스템인지 알게 되는 것 같다.

여전히 실무 면에서는 궁금하다.

 예를 들어, 실제 프로덕션 환경에서는 어떤 할당 전략을 주로 사용하는지 궁금하다.
그리고 각 전략별로 성능 차이는 얼마나 날지도? 특히 대규모 시스템에서 이런 차이가 눈에 띄게 나타나는지 알고 싶다..
그래야 회사에 보고를 하고 투입을 하지

또 하나 궁금한 점은 사용자 정의 Assignor에 대한 거예요.
 강의에서는 간단히 언급만 되었는데, 실제로 어떤 경우에 사용자 정의 Assignor를 만들어 사용하는지,
 그리고 어떤 점을 고려해야 하는지 더 자세히 알고 싶어졌다. 실제 여러 예시를 보여줬으면 좋았을 것 같다...
뭐 열심히 배우다가 정 안되면 커뮤니티 질문 하면 되겠지..

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

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

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

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

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

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

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

Consumer Rebalance에 대한 심화 학습이다..

요약

• Consumer의 동작 방식:
  • Partition에서 메시지를 polling하고 offset 정보를 관리
  • 이전 기본 개념 다시 되짚어 보는 시간
• Consumer Group:
  • 동일한 group.id로 구성된 Consumer들이 하나의 그룹을 형성하여 작업량을 분할
  • 컨슈머 그룹의 컨슈머들이 작업량을 어느 정도 균등하게 분할하기에 자동으로 로드발란싱 효과가 이루어진다.
  • 동일한 토픽에서 컨슘하는 여러  컨슈머 그룹이 있을 수 있으며 각각 독립적으로 작동한다
• Partition Assignment:
  •  파티션을 컨슈머에 할당하는 전제조건 
    • 하나의 파티션은 지정된 컨슈머 그룹내의 하나의 컨슈머만 사용
    • 동일한 키를 가진 메시지는 동일한 컨슈머가 사용(파티션 수를 변경하지 않는 한)
    • 컨슈머의 파라미터중에 `partition.assignment.strategy`로 할당 방식 조정
    • 컨슈머 그룹은 그룹 코디네이터라는 프로세스에 의해 관리된다
• Consumer Group Coordination:
  •  Group Coordinator와 Group Leader의 역할을 설명한다
  • 그룹 코디네이터 선택 방법
    • 위에서 말했듯 각 컨슈머는 `group.id`로 카프카 클러스터에 자신을 등록
    • 카프카는 컨슈머 그룹을 만들고 컨슈머의 모든 offset은 컨슈머 offset topic의 하나의 파티션에 저장된다.
    • 이 파티션의 리더 브로커는 컨슈머 그룹의 그룹 코디네이터로 선택

왜  그룹 코디네이터가 직접 파티션을 할당하지 않는가?

• 카프카의 설계 원칙
  • 가능한 한 많은 계산을 클라이언트로 수행하도록
  • 브로커의 부담을 줄이는 것
  • 본연의 업무 집중

이번에는 그룹 Consumer Group Coordination에 대해 배우는게 핵심인 것 같다.
Group Coordinator와 Group Leader가 서로 협력하여 Consumer들에게 Partition을 할당하는 과정이 흥미롭다. 특히 Group Leader가 Partition 할당을 담당한다는 점을 기억하자. 그리고 카프카가 이렇게 클라이언트에게 많은 역할을 위임하는 이유가 Broker의 부담을 줄이기 위해서라는 설명도 납득이 가고 감탄한 부분이다..

Rebalancing에 대한 설명도 매우 좋았다..하지만 불필요한 Rebalancing을 피하는 조건이 너무 까다로운 것 같아 보인다.
Consumer가 그룹에 들어오거나 나가는 등의 변화가 있을 때 Rebalancing이 일어난다는 점을 인지 했고,
그리고 이 과정에서 일시적으로 메시지 처리가 중단될 수 있다는 점을 알게 되서 중요한 고민 포인트임을 인지했다..

Consumer Heartbeats 개념도 보면서 지금 업무에 어떻게 응용할 수 있는지 조금 떠올랐다.

마지막으로, 과도한 Rebalancing을 피하는 방법들을 배웠는데, 엄청 조건이 어렵다.
이 부분은 실제로 적용해보고 싶은데... 특히 Consumer Group 멤버를 고정하는 방법이나 여러 타임아웃 설정을 조정하는 방법들이 궁금하다

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

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

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

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

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

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

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

심화공부 3번째로, 기본에 찍먹했던 Replica Recovery의 심화과정이다.

요약

 Replica Recovery 과정

• 브로커 장애 시 새로운 리더 선출
• 메시지 복제 및 커밋 과정
• High Water Mark 진행
•  

acks 설정의 중요성

• acks=all 와 acks=1을 비교한다.
• 하늘과 땅차이 ㅎ
• 데이터 유실 방지를 위한 acks=all 설정이 무조건 필요해 보인다
  
  • 심화 강의에서는 지금까지 없었던 복잡한 장애 상황을 보여주는데..
    이경우에도 acks=이라면.. 복잡한 과정 및 중복이 발생하더라도 데이터 유실없이 성공한다

가용성과 내구성 관련 파라미터

• unclean.leader.election.enable
  • ISR 리스트에 없는 리플리카를 리더로 선출할지 에 대한 옵션
  • 기본값은 false
  • true로 한다면..? .. 제대로 follow하지 못한 (ISR에 끼지도 못한 ) broker를 리더로?? 무조건 데이터 유실 확정!
• min.insync.replicas
  • 최소 요구되는 ISR 개수에 대한 옵션
    • 기본값: 1
    • ISR이 min.insync.replicas보다 적게 된다면?
      • Producer가 NotEnoughReplicas 예외 수신
    • Producer에서 ask = all과 함께 사용할 때 더 강력한 보장

Replica Recovery에 대한 심화강의인데 아주 좋다. 다른데서 한번도 보지 못한 복잡한 케이스를
단순하게 설명하는데 이해가 잘된다.
기본개념시 찍먹했던 용어들도 처음에 다시 짚어주는 부분 아주 좋다.

가용성과 내구성 관련 파라미터들에 대한 설명도 매우 유익하다
 unclean.leader.election.enable, min.insync.replicas, replication.factor 등의 설정이 시스템의 안정성과 성능에 어떤 영향을 미치는지 이해할 수  있다.
acks 설정의 중요성 심화에서  acks=all과 acks=1의 차이를 비교하면서, 데이터의 안정성과 시스템의 성능 사이의 트레이드오프를 고려해야 한다는 점을 (기존에도 알았었지만)다시 한번 고민 포인트임을 인지하게 된다..그리고 실제 프로젝트에서는 어떤 기준으로 이 설정을 선택해야 할지 또 다시 고민 하는데..

슬라이드11번에서 딱! 내가 원하는 완전한 설정값이 나왔다. 아주 기뻤다.
데이터 유실을 방지하기 위한 설정과 가용성을 높이기 위한 설정의 차이첨과 함께
해당 설정이 나와서.. .이대로 테스트하면 될 것 같다.

이번 심화 과정을 통해 Replica Recovery에 대해서 더 알게 되었다. 생각했던 것보다 더 복잡한 내부 동작 원리가 존재함을 배울 수 있었다. 그리고 그동안에 나왔던 데이터유실 방지 설정과 가용성을 높이기 위한 설정값이 실제로 공개되는 부분이 너무 좋다.

하지만 역시나 저런 설정값이 어떻게 도출 되었는지는 여전히 아리송 하다..
게다가.. 만약에 네트워크 장애들로 여러 리더가 동시에 존재하게 된다면 어떻게 될까?

왜 공부를 하는데... 더 모르는게 많아질까...

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

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

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

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

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

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

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

심화 공부 2번째 시간으로 장애에 대한 깊이 있는 내용을 다루고 있다.

요약

ISR(In-Sync Replicas) 관리

• 메시지가 ISR 리스트의 모든 Replica(복제본)에서 수신되면 Commit된 것으로 간주
• Leader는, Kafka Cluster의 Controller에 의해 모니터링되는, ZooKeeper의 ISR 목록에 대한 변경 사항을 유지
• 리더 브로커가 팔로워의 동기화 상태를 모니터링하며, 지연이 발생한 팔로워를 ISR 목록에서 제거
• n개 복제본 존재 시 n-1개 장애까지 허용 가능

리더 장애시 처리 절차

• 컨트롤러가 새로운 리더 선출
• 새로 선출한 Leader 및 ISR 정보는 ZooKeeper에 기록 → 컨틀롤러 장애로부터 보호하기 위해서
• 클라이언트 메타 데이터 업데이트를 위해 모든 Broker에 전파 → 클러스터 상태 갱신

분산 시스템을 배우며 내 주의력도 분산..

• 카프카의 강의를 들으면 분산 시스템의 복잡성을 배우는 동시에 내 머리속이 복잡해지는 것 같다.
• 계속적으로 주키퍼 클러스터가 나오는데 주키퍼가 없는 모드에서는 어떻게 되는지는 왜 설명을 해주지 않는걸까
• 특히 학습인증샷에 찍은 예제가 좋은데.. 지금까지 다왔던 단순 파티션 장애가 아닌 브로커 장애를 다루고 있다.
  • 4개 브로커, 4개 파티션, 복제 계수 3 환경에서의 장애 시나리오의 예시이며
  •  장애 브로커가 포함된 파티션의 리더 재선출 과정에 대해 다루고 있는데 어렵지만 슬라이드가 좋았다 ㅋ
• 일단 팔로워가 실패하는 것은 전혀 문제가 안된다
• 리더가 실패하는 경우 리더 새선출과 ISR 갱신 , 푸쉬 , 캐싱이 이뤄지는 부분이 핵심
• 리더가 선출 될때까지 해당 파티션을 사용할 수 없게 되는 부분으로 빠른 재선출이 필요해 보인다
• 리더 선출을 담당하는 컨트롤러의 장애시 주키퍼가 컨트롤러를 뽑는다고 기본 개념 시간에 배웠었는데..
  심화시간에는 해당 부분도 나올거라고 기대했는데 해당 부분은 없는 것 같아 아쉬운 부분
• 여튼 결론은 다음과 같아 보인다(맞나..)
  • Follower가 실패하는 경우
    • Leader에 의해 ISR 리스트에서 삭제됨
    • Leader는 새로운 ISR을 사용하여 Commit함
  • Leader가 실패하는 경우
    • Controller는 Follower 중에서 새로운 Leader를 선출
    • Controller는 새 Leader와 ISR 정보를 먼저 ZooKeeper에 Push
    • 그 후  로컬 캐싱을 위해 Broker에 Push

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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처럼 데이터 센터의 물리적 구조까지 고려해서 복제본을 배치할 수 있다는 부분이 대단하다. 반대로 그 부분 까지도 고민하고 신경을 써야한다는 점에서는 짜증이 난다.
• 역시 대규모 시스템은 그냥 이뤄지지 않는다.
• 언젠가 대규모 시스템을 직접 설계하고 구현하고 싶다는 부분에서 해당 강의 수강을 시작했는데..
  사실 벌써 기가 죽은 부분도 존재한다... 좋은 기술인데 아직은 어렵고 낯설다..

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

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

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

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

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

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

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

이번에는 반대로 Consumer에 대한 주요 개념과 특징을 설명한다.

요약

Consumer 기본 개념

• Consumer는 Commit Log에서 순서대로 데이터를 읽는다.
• Consumer Offset은 Consumer가 읽은 위치를 표시하며,  `__consumer_offsets` [internal topic] 에 저장된다.

Consumer Group

• 동일한 group.id를 가진 Consumer들이 하나의 Consumer Group을 형성
• Consumer Group 내 Consumer들은 파티션을 분배하여 데이터를 컨슈밍한다.
• 다른 Consumer Group의 Consumer들은 독립적으로 작동하며, 서로 영향을 주지 않는다.

 메시지 순서와 키 사용

• 파티션이 2개 이상인 경우 전체 메시지 순서 보장이 불가능하다.
  • 컨슈머가 파티션 2개의 데이터를 처리 -> 파티션 2개의 데이터가 서로 섞이게 된다
  • 하지만 전체 메시지의 전체 순서의 보장이 필요한 케이스가 과연 얼마나 되는가?
  • 사실상 각 키 레벨의 순서 보장이 필요한 케이스가 대부분이다.
• 키를 사용하면 동일한 키를 가진 메시지가 같은 파티션에 저장되어 키 레벨의 순서 보장이 가능
• 키 선택은 작업 부하 분배에 영향을 미치므로 매우 중요하며 많은 고민이 필요하다

 Consumer Failure와 Rebalancing

• Consumer 실패 시 Consumer Group 내 다른 Consumer가 해당 파티션을 대신 처리
• 이를 통해 Consumer Group의 안정성과 가용성이 유지

주요 고려사항

• 파티션 수와 Consumer 수의 균형을 고려해야 한다
  • 카프카 시스템의 성능과 확장성에 중요한 영향을 미친다
  • 파티션이 적으면
    • 컨슈머 리소스를 충분히 활용하지 못한다
    • 메시지 처리 속도가 느려질 수 있다
  • 파티션이 너무 많으면
    • 컨슈머간 조정 오버헤드가 증가한다
    • 카프카 클러스터 안정성이 떨어진다
  • 적절한 파티션 수는 ??
    • 컨슈머 성능을 모니터링
    • 필요에 따라 조정하며 찾아야 한다
    • 운영시에 바꾸기 힘드므로 운영 전 단계에서 픽스하는게 좋다
• 키 선택 시 데이터 분배와 순서 보장을 함께 고려해서 고민 필요.
  • 동일한 키를 가진 메시지는 같은 파티션에 전달 된다 → 키 레벨의 순서를 보장
  • 키 선택이 잘못되는 경우 특정 파티션에 데이터가 몰리게 된다 → 작업 부하가 고르지 않음
  • 예시) 사용자의 id를 키로 한다면 사용자별 메시지 순서가 보장
  • 반면 특정 사용자의 활동이 많으면 해당 파티션에 부하가 집중된다
  • 따라서 데이터의 특성과 분포를 고려한 키 선택이 필요하다
• Consumer Group 설계 시 처리량과 장애 대응을 고려해야 한다
  • Consumer Group을 통해 파티션을 여러 Consumer에 분배 → 병렬 처리 가능, 높은 처리량 달성
  • 동시에 Consumer Group은 장애 발생 시 자동으로 파티션을 재분배(ReBalancing)하여 시스템의 가용성을 유지
  •  Consumer 수가 너무 많으면 → 재조정(rebalancing) 빈도가 증가 →  성능에 영향을 줄 수 있다.
  • Consumer Group 설계 시 예상 처리량, 메시지 복잡도, 그리고 장애 시나리오를 고려하여
    적절한 Consumer 수와 구성을 결정해야 한다.

아니... 너무 어렵다... 운영에 반영하기전에 고려할게 너무 많다...
언어처럼 그냥 배워서 적용할 수 있는게 아니라 굉장히 고민과 시나리오 및 테스트를 많이 해봐야 할듯 하다...

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

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

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

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

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

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

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

이번 강의는  Kafka의 핵심 구성 요소 중 Producer에 초점을 맞춰 기본 개념과 동작 원리를 설명을 하고 있다.

요약

• Producer 역할
  • Kafka Topic에 메시지(Record)를 전송하는 애플리케이션
  • Consumer와 완전히 분리되어 독립적으로 동작(Decoupling)
  • 메시지 구조는 Header, Key, Value로 구성되며 Byte Array 형식으로 저장
• Producer의 주요 컴포넌트
  • Serializer
    • 데이터를 바이트 배열로 변환(Producer 측)
    • 각 데이터 타입당 맞는 Serializer가 존재하는 듯 하다.
  • Partitioner
    • 메시지의 Key 기반으로 Topic Partition 지정
    • Key exist: `Hash(Key) % Partition 수` 방식
    • Key null: Sticky Partitioner로 처리

• 일단 외워 ㅋ
• 일단 일반적으로 아는 key-value에서는  key는 무조건 필수값이다. 하지만 카프카에서는 topic과 value가 필수값이다.
• 2.4이전에는 Key가 없으면 메시지가 라운드 로빈 방식으로 파티션에 분배되는 것으로 설명되고
  이후에는 Sticky 가 default방식이다.
•  실제 개발 환경에서 Key를 의도적으로 생략하는 경우가 있을까? 왜 key를 비울 수 있게 하는 거지?
   이러면 메시지 순서가 보장이 안되지 않나? 알면 알수록 더 모르겠다.
• 일단 나는 왠만하면 key를 써야 할 것 같다.
• Avro라는 말이 자연스럽게 나오는데 처음 듣는 말이라서 찾아보았다.
• Avro
  •  Apache Kafka에서 자주 사용되는 데이터 직렬화 시스템
  • JSON 형식으로 정의된 스키마를 사용하여 데이터를 직렬화하고 역직렬화
  • 데이터를 바이너리 형식으로 압축하여 저장하므로 네트워크 대역폭과 디스크 공간을 절약
  • 스키마 변경에 유연하게 대응할 수 있어, 데이터 구조가 변경되어도 기존 데이터와의 호환성을 유지
  • 다양한 프로그래밍 언어에서 사용 가능
  • 아직은...모르니 이정도로

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

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

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

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

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

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

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

지난 강의의 Apache Kafka의 핵심 구성 요소인 Topic, Partition, Segment에 이어서
카프카 클러스터의 핵심 구성요소인 broker와 연관된 ZooKeeper, KRaft 모드에 대한 강의이다.

요약

• Kafka Broker
  • 역할:
    • Topic과 Partition관리
    • 데이터의 Read/Write 처리
  • Broker ID와 Partition ID와 무관하다
  • Partition은 자동 분산된다
  • Bootstrap Servers
    • 클라이언트가 하나의 broker연결만 되어도 전체 카프카 클러스터의 접근이 가능하다
    • 다만 장애 대비 전체 목록의 리스트를 넘겨주는 것이 권장된다
• ZooKeeper
  • 역할
    • Broker, Topic, Partition의 메타데이터(설정, 상태) 관리.
  • 홀수 개의 서버로 구성 (최소 3대, 권장 5대).
    (위의 브로커의 숫자는 홀수개와 상관없다. 주키퍼에 한해서 홀수)
  • Quorum (강사님 발음으로 유추하건대 쿼럼이라고 읽음) 알고리즘을 통해 장애 발생 시 시스템 일관성 유지.
  • ZooKeeper 모드: Kafka 3.3 이전의 기본 구성 방식
• KRaft 모드
  • 역할
    • ZooKeeper 의존성 제거 및 Kafka 자체 메타데이터 관리.
  • 배포 및 관리 단순화.
  • 수백만 파티션 지원 확장성.
  • 안정성 및 장애 조치 성능 향상.
  •  Kafka 3.3부터 신규 클러스터에(only) 대해 Production-Ready.

신규 클러스터에 대한 Ready이다. 기존 클러스터에 대한 마이그레이션이나 Ready가 아님

• 카프카 내부 아키텍처에 대한 이해가 깊어지는 강의이다.
• 주키퍼는 예전에 개발할때 스프링 클라우드 넷플릭스를 사용할 때 서비스 디스커버리로 사용하고 있었다.
  그래서 단순히 Eureka처럼 서비스 디스커버리 역할 정도만 생각했는데 여러 노드의 동기화나 
  카프카 노드의 동기화처럼 사실 더 복잡한 내용이 있었다는 것도 처음 알게 되었음.
• 현재 스프링 클라우드는 주키퍼의 복잡성과 관리 어려움으로 인해 Eureka나 Consul 등으로 대체되는 추세이다.
  카프카도 최신 버전에서 KRaft 모드로 기존 주키퍼의 의존성을 제거하는 부분에서 동일하게 가고 있는 것 같다.
• KRaft의 "수백만 개의 파티션"이라는 구문이 충격적이다. 수백만개의 파티션까지 필요한 것일까? 
  내가 생각하지 못한 규모의 데이터에서는 그렇게 필요한 건가?? 
  카프카가 어떻게 대규모 스트리밍을 효율적으로 처리하게 되는지 파티션 개수만 봐도 아주 조금 와닿는다.
• KRaft 모드가 신규 클러스터만 적용된다는 부분이 핵심이다. 내가 카프카를 더 일찍 공부했으면 망했을지도...
  적절한 타이밍에 들어왔고 적절한 이벤트(환급챌린지)로 보게 되는데 나름 재미있게 보고 있다.
• 주키퍼에는 Quorum 알고리즘으로 합의에 도달한다고 했는데 KRaft에서는 어떻게 도달하는지 설명이 빠져있다.
  지금은 아키텍처 전체 내용이니까 빠진것이겠지? 
  강사가 부록으로 KRaft전용 동영상을 만들었다고 하니 기대해 본다.
• 강의 동영상들이 20분 안쪽이지만 많은 부분이 압축되어 있다.
  이전에도 말했지만 패캠의 박성웅 vue.js 강의처럼 공식문서만 읽는 것으로 시간 때우는게 아니다.
• 패캠 강의에는 늘 퀄리티에 실망을 많이 했었는데.. 현재 7개밖에 듣지 않았지만 만족스럽다.
  강의슬라이드도 전부 공유해 주고 슬라이드도 대충 만드는 게 아니라 깔끔해서 복습하기에도 좋다.
• 내가 패캠강의를 칭찬할 줄이야.ㅋㅋ