'2025/03'에 해당되는 글 19건

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

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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년이 다 되어가는 강의로 알고 있는데 아직까지 안고쳐진 건
  패캠이 관리를 하지 않는 것인가? 아니면 이 강의 자체가 안팔린 것인가...
  그렇다면 아무도 안산 이 강의를 듣는 내가 호구인 것인가....
• 돞아보기라는 게 있는 말인줄 몰랐음...ㅠㅠ 내가 바보였음..