지난 강의의 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개밖에 듣지 않았지만 만족스럽다. 강의슬라이드도 전부 공유해 주고 슬라이드도 대충 만드는 게 아니라 깔끔해서 복습하기에도 좋다.
슬라이드가 보여주기식이 아니라 그냥 훑어만 봐도 강의 내용이 떠오를 정도로 핵심 내용이 요약이 되어있다.
II. 학습 후기700자이상 (공백 제외)
마이크로서비스 아키텍처와 이벤트 드리븐 아키텍처에 대해 설명하는 클립
처음에는 일반적으로 많이 나오는 모놀리식 애플리케이션의 복잡한 상호 의존성 문제와 개발 생산성 저하 현상을 말해주고 해당 부분을 해결하기 위해 마이크로서비스로의 전환이 필요시 되었다는 부분으로 시작한다.
사실 마이크로서비스가 개발시 서로 영향을 주지 않는 거라고 생각 했지.. 서비스별 독립적인 배포/확장 기능과 다중 프로그래밍 언어 지원 같은 장점들이 실제 운영 환경에서 어떻게 유연성을 제공하는지에 대해 모르고 있었다. 코끼리 다리를 만지면서 코끼리를 안다고 했던 자신이 부끄럽다.
마이크로서비스 구현 시 발생하는 연쇄 장애 문제와 이를 해결하기 위한 비동기 통신 방식에 대한 설명은 정말 보석과 같다. 그동안 msa관련 아티클과 동영상을 다 보았어도 이걸 이렇게 설명하는 건 보지 못했다...이렇게 좋은 강의가 패캠에서도 찬밥신세로 오타도 수정이 안되는게 안타깝다.
RabbitMQ 같은 기존 메시징 시스템의 메시지 유지 취약성과 성능 한계가 Kafka의 영속성 보장 및 고처리량 특성으로 어떻게 보완되는지 비교 분석된 부분도 좋다. 특히 주문 처리 예시를 통해 이벤트 브로커를 활용한 서비스 결합도 감소 방식을 구체적으로 이해할 수 있어 실제 적용 가능성을 가늠해볼 수 있었다.
다만 강사님이 오히려 조회성 서비스를 이렇게 비동기 커플링 하는 것이 훨씬 어렵다고 하는데서 ???? 했다. 왜 어려운 건지 이해가 안가서... 내가 너무 몰라서 못알아듣는건가 싶다...
Kafka의 압도적인 처리량(605MB/s)과 P99 지연 시간(5ms) 수치가 제시된 성능 비교 표는 기술적 우위를 입증하는 동시에, RabbitMQ가 낮은 부하 환경에서 가지는 장점도 객관적으로 보여준다. 무조건적인 낮은 부하가 보장된다면 rabbitmq를 쓰는게 더 나을 수 있겠다는 생각도 든다.
대용량 데이터 스트리밍과 실시간 분석 요구사항이 있는 시스템 설계 시에는 Kafka가 최적의 선택이자 유일의 선택인 것 같다.
강의를 보기 전에는 아무래도 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과 실시간 모니터링 구현하는 부분을 잘보고 버무리면... 보고서가 뚝딱 되지 않을까 싶음
처음 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 같은 고급 기능들의 실제 구현 사례가 궁금한데.. 강의 뒤에 나올려나?
"이벤트"는 단순히 데이터 변화나 사용자 행동(예: 결제 완료, 로그인 시도)을 의미하며 이는 내가 생각 하는 모든게 이벤트가 될 수 있음도 의미한다..
이벤트를 ‘비즈니스에서 발생하는 모든 데이터 포인트’로 정의한 부분은 실제 활용 사례(택시 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년이 다 되어가는 강의로 알고 있는데 아직까지 안고쳐진 건 패캠이 관리를 하지 않는 것인가? 아니면 이 강의 자체가 안팔린 것인가... 그렇다면 아무도 안산 이 강의를 듣는 내가 호구인 것인가....
