본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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개밖에 듣지 않았지만 만족스럽다.
  강의슬라이드도 전부 공유해 주고 슬라이드도 대충 만드는 게 아니라 깔끔해서 복습하기에도 좋다.
• 내가 패캠강의를 칭찬할 줄이야.ㅋㅋ

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

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

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

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

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

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

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

이번 강의는 Apache Kafka의 핵심 구성 요소인 Topic, Partition, Segment를 설명한다.
갑자기 이론이야기 하다가 스펙나오니까 머리가 터질려고 해서 계속 구간반복하면서 이해했다...;

Topic, Partition, Segment 요약

• Topic:
  • 메시지의 논리적 그룹
  • 카프카 클러스터 내에서 고유한 이름으로 식별된다.
• Partition:
  • Topic을 분할한 물리적 단위
  • 불변성(Immutable), 추가 전용(Append-Only) 특성을 가진다.
  • 여러 Partition을 사용해 처리량(Throughput)을 확장이 가능하다.
• Segment:
  • Partition을 구성하는 실제 파일
    • 기본 정책
      • log.segment.bytes(기본 1GB)
      • log.roll.hours(기본 168시간)
      • 위 조건에 따라  새로운 파일로 롤링
      • 168시간이 지나면 1G가 안채워졌어도 새로운 파일로 롤링된다
• Offset:
  • Partition 내에서 메시지의 고유 위치
  • Consumer Lag(LOG-END-OFFSET과 CURRENT-OFFSET 차이)을 모니터링하는 데 사용.

"Producer와 Consumer는 서로를 알지 못하며, 독립적으로 동작한다.
Consumer Group 내 Consumer들은 협력해 메시지를 분산 처리한다."

• 기존 강의에선 이론이나 아키텍처(msa, eda)등이 나오다가 갑자기 스펙이 나와서 그런지 용어가 눈에 안들어옴.
• 왜 파티션이 필요한거지? 아직 강의 초반이라서 그런지 아직도 잘 모르겠다.
  파티션을 분할하면 컨슈머가 병렬로 메시지를 처리할 수 있어서 성능이 향상된다는 부분만 기억하고 패스;;
• 컨슈머 그룹도 중요한 개념인듯 하다
  • 같은 그룹 내 Consumer들이 Partition을 나눠 처리한다는 것이 효율적인 듯 하다
• 파티션 개수가 굉장히 중요한 것 같다.
  • 강사가 말하는 특히 운영상에 있어서 가능하면 변경하지 말라는 것은 처음에 신중하게 결정하고 픽스하라는 것이다
  • 그러면 이 개수는 어떻게 결정해야 할까?
  • 너무 많으면 관리가 복잡해질 것이고, 적으면 병렬성 장점을 얻지 못할 것 같다. 뭔가 이전 강의처럼 확실한 정의가 있으면 좋겠다.
  • 구간 단위로 이 구간이면 이 파티션수 이렇게...
• 세그먼트 개념도 절반정도 알아들음
  • 기본 정책에 의해 오래된 세그먼트대신 긴규 세그먼트 대체하는 부분은 이해했다.
  • 정책이나 장비의 여유 공간에 따라서= 오래된 세그먼트를 삭제하거나 압축할 수 있을 것 같다.
  • 그럼 세그먼트 파일 (그것도 active)이 손상되면 복구는 어떻게 되는거지?
• 결론
  • 기본개념 절반 알아들었지만 고민은 더 커진다..
  • 회사에 건의할지에 대해서는 운영단계의 저런 고려사항들을 더 알게 된 후로 미루자.