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

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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가 최적의 선택이자 유일의 선택인 것 같다.

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

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

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

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

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

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

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

• 강의를 보기 전에는 아무래도 activemq나 rabbitmq같은  ‘메시징 시스템’이라는 개념으로 와닿았었음.
• 데이터 파이프라인과 실시간 분석 사례들을 보니 이건 완전히 새로운 영역임.
• 카프카가 단순한 데이터 전달 도구가 아닌 전사적 데이터 플랫폼을 구성할 수 있다는 새로운 사실!
  SIEM 최적화, AI/ML 분석, 하이브리드 클라우드 통합등은 mq레벨이 아님 
• 스트리밍 ETL이  기존 ETL 시스템과 어떻게 차이가 나는지 궁금한데, 해당부분은 설명 안함.
  나중에 하겠지?
• 커넥터 보고 와 했음..지금 회사의 전자 세금계산서에서도  커넥터용 프로그램 만드는데 시간이 다 가고 있음.
  강사님은 네트워크 트래픽, 방화벽 로그, RDBMS 데이터 등 이기종 시스템 간 실시간 연동이 3-6개월의 개발 기간 없이 가능하다고 하셨는데 우리 회사는 2년이 지났고 아직도 오류 범벅임. 2.0을 새로 만들고 QA중인데 그것도 오류 범벅 ㅜㅜ
• 특히 우리 회사도 엘라스틱 개열과 spulnk 개열이 따로 놀고 있음. 해당 부분을  Confluent Platform의 커넥터로 바로 통합할 수 있다는 부분은... 아 이거 보고서 써야지라고 생각함. ㅋ
•  
• ksqlDB라는  것을 처음 들었음
  • 스트리밍 DB라는 개념에  충격 받음
  • SQL 문법으로 스트림 처리가 가능하다는 부분에서 더 충격 받음. SQL을 쓴다는 점에서 러닝커브도 낮아진 부분에 관심있음.
  • ksqlDB가 스트리밍이면 트랜잭션은 어떻게 처리 되는지 존나 궁금하고 gpt에게 물어보면 알려주겠지만
    강의에서 나올테니 걍 참음
  • 스트리밍시 장애가 나면 어떻게 데이터 일관성을 맞추는거지?? 이걸 모르면 설계를 못할 거 같음.. 

여튼  카프카가 단순한 기술 도구를 넘어 데이터 인프라의 중추 역할을 수행한다는 점을 체계적으로 이해할 수 있었음

특히 회사에서 클라우드네이티브화를 신경 쓰는 만큼 강의를 보면서  특히 스트리밍 ETL과 실시간 모니터링 구현하는 부분을
잘보고 버무리면... 보고서가 뚝딱 되지 않을까 싶음

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

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

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

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

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

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

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

• 인프라 비용: Confluent Cloud 사용시 연 190만 달러 절감
• 다운타임 감소: 99.95% SLA로 운영 리스크 최소화
• 운영 효율화: 완전 관리형 서비스로 인력 투입 47% 감소[1][2]
• 처음 Apache Kafka의 라이선스 체계를 접했을 때는 오픈소스와 기업판의 차이가 단순히 '유료/무료' 구분인 줄 알았;
• 강의의 설명으로  Confluent Community License 같은 중간 단계가 존재하며, 각 라이선스별로 제공 기능과 지원 범위가 체계적으로 분류되어 있다는 사실을 새롭게 이해.
•  특히 커넥터와 스키마 레지스트리 같은 핵심 컴포넌트가 라이선스 유형에 따라 달리 제공된다는 부분은 아예 몰랐던 부분.
• Confluent와 DIY OSS 운영 방식을 비교한 표가 엄청 도움이 됨
  현재 회사에서도 해당 부분 검토하는 부분이어서 실무와 회의 의견 발표시 도움이 될 것 같음.
• 클러스터 확장 시 Confluent의 자동화 도구가 개발자의 수고를 얼마나 덜어줄 수 있는지 구체적으로 파악할 수 있음
  ..하지만 윗사람들에 대해 비용에 대해서 어떻게 설득을해야 할지는 아직 미지수..
• Health+ 서비스 같은 선제적 모니터링 기능은 사실 말로만으로는 잘 와닿지 않는데 강의 후반가면 이해되겠지.
• G사의 TCO 사례에서는 단순 기술 비교를 넘어 비용 절감 효과를 정량화한 데이터가 특히 유용
  연간 190만 달러라는 구체적인 수치가 Confluent 도입의 경제적 타당성을 잘 설명해주었습니다.
  하지만 회사에서 이걸 근거로 들려면 G사가 정확히 어떤 회사인지를 알아야하는데... 쩝..
•  Apache v2.0과 Confluent Community License의 차이점을 명확히 구분해서 정리해야 보고서를 만들 수 있을 듯.
• 이 자료에 언급된 Tiered Storage와 Multi-Region Clusters 같은 고급 기능들의 실제 구현 사례가 궁금한데..
  강의 뒤에 나올려나?

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

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

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

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

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

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

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

1. 카프카의 핵심은 실시간 이벤트 처리

카프카의 핵심은 실시간 이벤트 처리인 것 같다.

"이벤트"는 단순히 데이터 변화나 사용자 행동(예: 결제 완료, 로그인 시도)을 의미하며 이는 내가 생각 하는 모든게 이벤트가 될 수 있음도 의미한다..

 이벤트를 ‘비즈니스에서 발생하는 모든 데이터 포인트’로 정의한 부분은 실제 활용 사례(택시 GPS 추적, 금융 거래 감시 등)와 연결지어서 설명하는 예시는 아주 괜찮다.

예전에는 데이터베이스나 API로만 처리하던 것을 카프카는 스트림 형태로 관리해 더 유연하고 빠르게 만든다는 점이 인상적이다.

2. 카프카의 특징: 왜 다른 도구보다 특별할까?

• 메시지 분리:
  • 프로듀서(생산자)와 컨슈머(소비자)가 서로 독립적으로 작동한다는 점이 신기했다
  • 예를 들어, 결제 시스템에서 데이터를 보내는 쪽과 분석하는 쪽이 서로 영향을 주지 않는다는 점!
• 디스크 저장:
  • 메시지를 메모리가 아닌 디스크에 저장해 데이터 손실을 막는다는 건 큰 장점.
  • "실시간"이면서도 안전하다는 게 요샌 이렇게 당연한건가? 나만 놀랍나?
• 확장성:
  • 클러스터로 서버를 추가하면 트래픽이 폭발해도 대응할 수 있다는 설명을 듣고,
    왜 Netflix나 Uber 같은 대기업이 카프카를 쓰는지 알 것 같음.
  • 특히 강사님이 실제 해봤다던 2천만건은 상상도 못했던 부분인데.. 국내에서 가능한가 그게
  • 특히 계속 브로커를 쌓으면 선형적인 증가가 이뤄진다는 것도 너무 신기하다.

3. 탄생 배경: 링크드인의 고민에서 시작된 혁신

• 카프카가 LinkedIn에서 탄생했다는 사실이 흥미롭다.
  내 생각에 링크드인은 사람인의 그냥 사람 많은 버전처럼 느껴지는데..
  그안에서 이전의 기술 스택으로 담지 못한 트래픽과 이벤트가 발생했다는 것이.. 놀랍다
• 내가 생각한건 수백만 수천만 정도였는데..
• LinkedIn에서 하루 4.5조 개 이벤트 처리라는 실제 사례를 통해 카프카의 확장성을 체감할 수 있었다
• 일반 수준의 장비  3대로 초당 200만 건 쓰기 처리가 가능하다는 벤치마크는 충격적이다.
  이래서 카프카 카프카 하는건가
• 다른 메시징 시스템 대비 월등한 성능
•  RabbitMQ와의 비교 표에서 처리량(605MB/s vs 38MB/s)과 지연 시간(5ms vs 1ms)을 수치화한 부분이 특히 도움이 되는 것 같다. 회사에서 현재 rabbitmq를 쓰고 있어서 회사내 경영진 설득에도 이 그래프가 도움이 될 것 같다.

4. 실제 사례: 카프카는 어디에 쓰일까?

• 실시간 추천 시스템: 사용자의 클릭이나 검색 이력을 즉시 분석해 추천하는 기술.
• 금융 사기 감지: 계좌 이상 거래를 실시간으로 탐지해 알림을 보내는 경우.
• IoT 센서 데이터 수집: 공장 기계나 자동차의 센서 데이터를 모아 분석하는 데 활용.
  이런 예시들을 보니 카프카가 "데이터의 고속도로" 역할을 한다는 표현이 와닿는다.

5. RabbitMQ vs 카프카

강사님이 비교해준 비교 표를 보며 깨달은 점은 목적이 다르다는 것.

• RabbitMQ: 주문 접수 후 이메일 발송처럼 작업을 순차적으로 처리해야 할 때 적합.
• 카프카: 실시간으로 유입되는 데이터(예: SNS 댓글, 주식 시세)를 병렬 처리해야 할 때 강점을 발휘.
  
  

6. 요약

• 실시간 시대의 필수 도구: 스마트폰, IoT 기기가 보편화되며 순간적인 데이터 처리 수요가 급증했고, 카프카는 이를 효율적으로 해결.
• 데이터 파이프라인의 혁신: 기존에는 데이터를 모아서 일괄 처리(Batch)했지만, 카프카는 스트리밍으로 접근해 지연 시간을 줄임.

느낀 점

• 아직은 알지 못하지만 이후강의도 기대된다
• 오랜만에 필기하느라 아이패드도 애썼고 내 손도 애썼다.
• 솔직히 이걸 50일 넘게 할 수 있을지는 아직도 자신이 없다.
• 그래도 vue.js 환급 챌린지보단 나은 거 같다. 그땐 강의 자체가 병신이어서...

• 가프카 돞아보기라는 오타는 챕터 뿐 아니라 강의 화면에도 나온다.
  이게 나온지 1년이 다 되어가는 강의로 알고 있는데 아직까지 안고쳐진 건
  패캠이 관리를 하지 않는 것인가? 아니면 이 강의 자체가 안팔린 것인가...
  그렇다면 아무도 안산 이 강의를 듣는 내가 호구인 것인가....
• 돞아보기라는 게 있는 말인줄 몰랐음...ㅠㅠ 내가 바보였음..