본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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)이 손상되면 복구는 어떻게 되는거지?
• 결론
  • 기본개념 절반 알아들었지만 고민은 더 커진다..
  • 회사에 건의할지에 대해서는 운영단계의 저런 고려사항들을 더 알게 된 후로 미루자.

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

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

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

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

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

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

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

Data Mesh

• 강사님 정의:
  • 기존 DW(Data Warehouse), DL(Data Lake)에서 중앙집중적으로 관리 되었던 분석 데이터들을 탈중앙해서 관리하는 데이터 아키텍처 패턴
• 굼금해서 찾아본 내용
  • 데이터 메시는 분산된 데이터 아키텍처이다
  • 2019년 Zhamak Dehghani가 제안
  • 모놀리식 데이터 레이크/웨어하우스의 문제점(데이터 병목, 유연성 부족 등)을 해결하기 위해 등장
  • 전통적 접근과 달리 "데이터 생산자와 소비자를 직접 연결해 실시간 협업을 촉진"하는 것이 특징

4가지 핵심 원칙 심층 분석

1. 도메인 중심의 탈중앙화: Domain-driven Decentralization
   1. 도메인 주도 분산 소유권 : 데이터는 특정 도메인이 소유한다(Data ownership by domain)
   2. 도메인 전문가가 자체 데이터를 소유/관리하며 중앙 팀의 의존도를 낮춘다
   3. 데이터 접근도 역시 분산됨
   4. 조직 구조 개편 필요
   5. 데이터 아피프라인보다 도메인 경계 정의 우선이 중요
2. 데이터를 제품으로 관리: Data as a product
   1. 데이터는 그것을 게시하는 각 팀에 따라서 제품으로 간주된다.
   2. 일류제품(고객에 제공하는 제품 수준)으로서의 데이터(Data as a First-class Product)
   3. 검색 가능, 신뢰성 보장, 문서화가 완비 되어 있어야 한다
   4. 강의 예시에선 카프카 스트림을 활용한 데이터 전파 매커니즘으로 기술 구현 구체화
      
      > 강의에서는 밑의 3, 4에 대한 설명은 없어서 인터넷으로 찾아 봄
3. 셀프 서비스 데이터 플랫폼: Self-serve Data Platform
   1. 데이터는 어디서나 셀프 서비스가 가능해야 한다. (Data available everywhere, selfserve)
   2. 중앙팀은 표준화 된 도구 (예: 카프카 커넥트)를 제공한다.
   3. 도메인 팀은 이를 조립해서 사용한다.
   4. 데이터 카탈로그와 거버넌스 자동화의 연계가 필요하다 : (이것은 솔직히 무슨말인지 모르겠다..아직..)
4. 연합 거버넌스: Federated Governance
   1. 데이터는 (어디에 있든) 통제하에 잘 관리되어야 한다(Data governed wherever it is)
   2. 강의에서 언급하진 않지만 중앙정책과 지역적 실행의 균형을 유지하는 매커니즘이 핵심인듯 하다.

서비스 메시 내의 노드간의 연결: 카프카 기반의 데이터 스트리밍이 제일 적합하고 자연스럽다

• 카프카가 실시간 스트리밍, 확장성, 불변성 감사 추적 측면에서 데이터 메시 구현에 적합하다
• 특히 이벤트 기반 아키텍처와 마이크로서비스 패턴이 결합될 때 시너지가 발생한다

Mesh is a logical view, not physical!
메시는 물리적이 아닌 논리적 뷰이다.

Data Streaming이 Data Mesh에 적합한 이유

1. Streams are real-time, low latency: 데이터를 즉시 전파한다(pub/sub)
2. Streams are highly scalable: 오늘날의 방대한 데이터량을 처리
3. Streams are stored, replayable: 실시간 및 과거 데이터를 모두 캡처
4. Streams are immutable: Audit 가능한 레코드 소스
5. Streams are addressable, discoverable, ...: 메시 데이터에 대한 주요 기준을 충족
6. Streams are popular for Microservices: 데이터 메시 적용에 쉽다.

강사님이 알려주신 참고 사이트 : developer.confluent.io

• 카프카와 데이터 스트림에 대한 모든 것이 공짜
• 데이터 스트리밍 패턴 50개가 넘음
• 퀵스타트, 튜토리얼 전부 포함
• 괜히 들어갔음.. 할거 존나많음.ㅠ

1주 느낌

• 21년에 했던 VUE.JS 강의 환급 때와 비교가 안되게 좋음..
• 머 더 깐깐하게 준비하는 거 같은데 그것도 그냥 날마다 하면 문제가 안되고...
• 박영웅 강사의.. 진짜 내가 이걸 내가 내돈 주고 사서 내시간 쓰면서 듣고 있나...
  했던 강의와는 다른 것 같다 .(아직까지는..)
• 아이패드 좋다 ㅎ

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

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

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

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

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

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

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

• 마이크로서비스 아키텍처와 이벤트 드리븐 아키텍처에 대해 설명하는 클립
  
  
• 처음에는 일반적으로 많이 나오는  모놀리식 애플리케이션의 복잡한 상호 의존성 문제와 개발 생산성 저하 현상을 말해주고 해당 부분을 해결하기 위해 마이크로서비스로의 전환이 필요시 되었다는 부분으로 시작한다.
  
  
• 사실 마이크로서비스가 개발시 서로 영향을 주지 않는 거라고 생각 했지.. 서비스별 독립적인 배포/확장 기능과 다중 프로그래밍 언어 지원 같은 장점들이 실제 운영 환경에서 어떻게 유연성을 제공하는지에 대해 모르고 있었다. 코끼리 다리를 만지면서 코끼리를 안다고 했던 자신이 부끄럽다.
  
  
• 마이크로서비스 구현 시 발생하는 연쇄 장애 문제와 이를 해결하기 위한 비동기 통신 방식에 대한 설명은 정말 보석과 같다. 그동안 msa관련 아티클과 동영상을 다 보았어도 이걸 이렇게 설명하는 건 보지 못했다... 이렇게 좋은 강의가 패캠에서도 찬밥신세로 오타도 수정이 안되는게 안타깝다.
  
  
• RabbitMQ 같은 기존 메시징 시스템의 메시지 유지 취약성과 성능 한계가 Kafka의 영속성 보장 및 고처리량 특성으로 어떻게 보완되는지 비교 분석된 부분도 좋다. 특히  주문 처리 예시를 통해 이벤트 브로커를 활용한 서비스 결합도 감소 방식을 구체적으로 이해할 수 있어 실제 적용 가능성을 가늠해볼 수 있었다. 
  
  
• 다만 강사님이 오히려 조회성 서비스를 이렇게 비동기 커플링 하는 것이 훨씬 어렵다고 하는데서 ???? 했다.
  왜 어려운 건지 이해가 안가서... 내가 너무 몰라서 못알아듣는건가 싶다...
  
  
• Kafka의 압도적인 처리량(605MB/s)과 P99 지연 시간(5ms) 수치가 제시된 성능 비교 표는 기술적 우위를 입증하는 동시에, RabbitMQ가 낮은 부하 환경에서 가지는 장점도 객관적으로 보여준다. 무조건적인 낮은 부하가 보장된다면 rabbitmq를 쓰는게 더 나을 수 있겠다는 생각도 든다.
  
  
• 대용량 데이터 스트리밍과 실시간 분석 요구사항이 있는 시스템 설계 시에는  Kafka가 최적의 선택이자 유일의 선택인 것 같다.