1. Kafka 컨셉
- Apache Kafka는 대용량 실시간 데이터 스트리밍을 위한 분산 이벤트 스트리밍 플랫폼입니다. 단순한 메시지 큐를 넘어
데이터 파이프라인의 중심축 역할을 합니다.
• 구성 요소
- 토픽(Topic): 메시지를 분류하는 논리적 채널. 복수의 파티션으로 구성
- 파티션(Partition): 토픽을 물리적으로 분할한 단위. 순서 보장과 병렬 처리의 기반
- 브로커(Broker): 메시지를 저장하고 서빙하는 서버. 여러 대로 클러스터 구성
- 프로듀서(Producer): 토픽에 메시지를 발행하는 클라이언트
- 컨슈머(Consumer): 토픽에서 메시지를 구독하는 클라이언트
- 컨슈머 그룹(Consumer Group): 동일 토픽을 병렬로 처리하는 컨슈머 집합
- Kafka는 메시지를 소비해도 즉시 삭제하지 않고 디스크에 유지합니다. 이를 통해 여러 컨슈머가 독립적으로 같은 데이터를
다른 시점에 소비할 수 있습니다.
2. Kafka 컨셉이 주는 이점
- Kafka의 설계 철학은 프로듀서와 컨슈머를 완전히 분리하는 것입니다. 이 분리 구조가 시스템 전반에 실질적인 이점을 제공합니다.
• 주요 이점
- 고처리량: 디스크 순차 쓰기와 배치 처리로 단일 클러스터에서 수백만 메시지/초 처리 가능
- 내결함성: 파티션 복제(Replication)로 브로커 장애 시에도 데이터 유실 없이 서비스 지속
- 확장성: 브로커와 파티션을 추가하는 것만으로 수평 확장 가능, 서비스 중단 불필요
- 데이터 재처리: 오프셋 기반 관리로 특정 시점 데이터를 다시 소비하거나 재처리 가능
- 느슨한 결합: 프로듀서와 컨슈머가 서로를 모르는 구조로 독립적인 개발·배포·장애 격리
- 이러한 이점으로 인해 Kafka는 실시간 로그 수집, IoT 센서 데이터 파이프라인, 이벤트 기반 마이크로서비스 아키텍처 등 다양한 영역에서
표준 인프라로 자리잡았습니다.
3. 클라이언트에게 데이터를 제공하는 방법
- Kafka는 별도의 REST API나 웹 인터페이스를 기본 제공하지 않습니다. 프로듀서와 컨슈머 모두 Kafka가 공식 지원하는 클라이언트
라이브러리를 통해 데이터를 주고받습니다.
• 클라이언트 라이브러리 구조
- Kafka는 TCP 기반의 자체 프로토콜로 통신하며, 클라이언트 라이브러리가 이 프로토콜을 구현
- Java(공식), Python(confluent-kafka), Go, .NET 등 주요 언어별 라이브러리 제공
- 라이브러리가 브로커 연결·재연결, 메타데이터 갱신, 파티션 할당 등을 내부적으로 처리
• 클라이언트 라이프사이클
- 초기화: bootstrap.servers로 브로커에 연결, 클러스터 메타데이터(토픽·파티션·리더 정보) 자동 수집
- 프로듀서: 내부 버퍼에 메시지 축적 → 배치 단위로 브로커 전송 → 전송 결과 콜백 수신
- 컨슈머: 컨슈머 그룹 참여 → 파티션 할당(리밸런싱) → poll() 루프로 메시지 수신 → 오프셋 커밋
- 종료: 버퍼 비우기(flush) → 컨슈머 그룹 탈퇴 → 연결 정리
• 라이브러리가 처리하는 것들
- 브로커 장애 시 자동 재연결 및 리더 전환 감지
- 메시지 배치·압축으로 네트워크 효율 최적화
- At-Least-Once 보장을 위한 재전송 및 멱등성 처리
- 컨슈머 그룹 리밸런싱 프로토콜 자동 수행
- 이처럼 클라이언트 라이브러리의 구현 방식(배치 크기, flush 시점, 커밋 전략 등)은 Kafka 클러스터 전체 성능에
지대한 영향을 미치게 되므로 적절한 설정과 구현 패턴을 사전에 정의하고 개발 가이드라인으로 공유하는 것이 중요합니다.
4. RabbitMQ와의 핵심 차이점
- RabbitMQ와 Kafka는 모두 메시지 브로커이지만 설계 철학이 근본적으로 다릅니다. 사용 목적에 따라 선택 기준이 달라집니다.
• 핵심 차이
- 메시지 보존: RabbitMQ는 컨슈머가 소비하면 메시지를 삭제 / Kafka는 보존 기간 동안 유지하여 재처리 가능
- 소비 방식: RabbitMQ는 Push 방식으로 브로커가 컨슈머에게 전달 / Kafka는 Pull 방식으로 컨슈머가 직접 가져감
- 처리량: RabbitMQ는 수만 메시지/초 수준 / Kafka는 수백만 메시지/초 수준으로 규모가 다름
- 순서 보장: RabbitMQ는 단일 큐 내 순서만 보장 / Kafka는 파티션 단위 순서를 엄격히 보장
- 컨슈머 독립성: RabbitMQ는 메시지를 특정 컨슈머에게 라우팅 / Kafka는 컨슈머 그룹별로 독립적인 오프셋 관리
• 선택 기준
- RabbitMQ : 작업 큐, 복잡한 라우팅 규칙, 즉각적인 처리가 필요한 RPC 패턴
- Kafka : 대용량 이벤트 스트리밍, 로그 수집, 데이터 파이프라인, 재처리가 필요한 시스템
- SNMP 데이터 파이프라인처럼 대량의 폴링 데이터를 수집하고 여러 컨슈머(DB 저장, 알림, 모니터링)가 동일 데이터를 각자의 속도로
소비해야 하는 구조에서는 Kafka가 명확한 선택입니다.
⭐발표자 : 이경훈님
1. Kafka 컨셉
- Apache Kafka는 대용량 실시간 데이터 스트리밍을 위한 분산 이벤트 스트리밍 플랫폼입니다. 단순한 메시지 큐를 넘어
데이터 파이프라인의 중심축 역할을 합니다.
• 구성 요소
- 토픽(Topic): 메시지를 분류하는 논리적 채널. 복수의 파티션으로 구성
- 파티션(Partition): 토픽을 물리적으로 분할한 단위. 순서 보장과 병렬 처리의 기반
- 브로커(Broker): 메시지를 저장하고 서빙하는 서버. 여러 대로 클러스터 구성
- 프로듀서(Producer): 토픽에 메시지를 발행하는 클라이언트
- 컨슈머(Consumer): 토픽에서 메시지를 구독하는 클라이언트
- 컨슈머 그룹(Consumer Group): 동일 토픽을 병렬로 처리하는 컨슈머 집합
- Kafka는 메시지를 소비해도 즉시 삭제하지 않고 디스크에 유지합니다. 이를 통해 여러 컨슈머가 독립적으로 같은 데이터를
다른 시점에 소비할 수 있습니다.
2. Kafka 컨셉이 주는 이점
- Kafka의 설계 철학은 프로듀서와 컨슈머를 완전히 분리하는 것입니다. 이 분리 구조가 시스템 전반에 실질적인 이점을 제공합니다.
• 주요 이점
- 고처리량: 디스크 순차 쓰기와 배치 처리로 단일 클러스터에서 수백만 메시지/초 처리 가능
- 내결함성: 파티션 복제(Replication)로 브로커 장애 시에도 데이터 유실 없이 서비스 지속
- 확장성: 브로커와 파티션을 추가하는 것만으로 수평 확장 가능, 서비스 중단 불필요
- 데이터 재처리: 오프셋 기반 관리로 특정 시점 데이터를 다시 소비하거나 재처리 가능
- 느슨한 결합: 프로듀서와 컨슈머가 서로를 모르는 구조로 독립적인 개발·배포·장애 격리
- 이러한 이점으로 인해 Kafka는 실시간 로그 수집, IoT 센서 데이터 파이프라인, 이벤트 기반 마이크로서비스 아키텍처 등 다양한 영역에서
표준 인프라로 자리잡았습니다.
3. 클라이언트에게 데이터를 제공하는 방법
- Kafka는 별도의 REST API나 웹 인터페이스를 기본 제공하지 않습니다. 프로듀서와 컨슈머 모두 Kafka가 공식 지원하는 클라이언트
라이브러리를 통해 데이터를 주고받습니다.
• 클라이언트 라이브러리 구조
- Kafka는 TCP 기반의 자체 프로토콜로 통신하며, 클라이언트 라이브러리가 이 프로토콜을 구현
- Java(공식), Python(confluent-kafka), Go, .NET 등 주요 언어별 라이브러리 제공
- 라이브러리가 브로커 연결·재연결, 메타데이터 갱신, 파티션 할당 등을 내부적으로 처리
• 클라이언트 라이프사이클
- 초기화: bootstrap.servers로 브로커에 연결, 클러스터 메타데이터(토픽·파티션·리더 정보) 자동 수집
- 프로듀서: 내부 버퍼에 메시지 축적 → 배치 단위로 브로커 전송 → 전송 결과 콜백 수신
- 컨슈머: 컨슈머 그룹 참여 → 파티션 할당(리밸런싱) → poll() 루프로 메시지 수신 → 오프셋 커밋
- 종료: 버퍼 비우기(flush) → 컨슈머 그룹 탈퇴 → 연결 정리
• 라이브러리가 처리하는 것들
- 브로커 장애 시 자동 재연결 및 리더 전환 감지
- 메시지 배치·압축으로 네트워크 효율 최적화
- At-Least-Once 보장을 위한 재전송 및 멱등성 처리
- 컨슈머 그룹 리밸런싱 프로토콜 자동 수행
- 이처럼 클라이언트 라이브러리의 구현 방식(배치 크기, flush 시점, 커밋 전략 등)은 Kafka 클러스터 전체 성능에
지대한 영향을 미치게 되므로 적절한 설정과 구현 패턴을 사전에 정의하고 개발 가이드라인으로 공유하는 것이 중요합니다.
4. RabbitMQ와의 핵심 차이점
- RabbitMQ와 Kafka는 모두 메시지 브로커이지만 설계 철학이 근본적으로 다릅니다. 사용 목적에 따라 선택 기준이 달라집니다.
• 핵심 차이
- 메시지 보존: RabbitMQ는 컨슈머가 소비하면 메시지를 삭제 / Kafka는 보존 기간 동안 유지하여 재처리 가능
- 소비 방식: RabbitMQ는 Push 방식으로 브로커가 컨슈머에게 전달 / Kafka는 Pull 방식으로 컨슈머가 직접 가져감
- 처리량: RabbitMQ는 수만 메시지/초 수준 / Kafka는 수백만 메시지/초 수준으로 규모가 다름
- 순서 보장: RabbitMQ는 단일 큐 내 순서만 보장 / Kafka는 파티션 단위 순서를 엄격히 보장
- 컨슈머 독립성: RabbitMQ는 메시지를 특정 컨슈머에게 라우팅 / Kafka는 컨슈머 그룹별로 독립적인 오프셋 관리
• 선택 기준
- RabbitMQ : 작업 큐, 복잡한 라우팅 규칙, 즉각적인 처리가 필요한 RPC 패턴
- Kafka : 대용량 이벤트 스트리밍, 로그 수집, 데이터 파이프라인, 재처리가 필요한 시스템
- SNMP 데이터 파이프라인처럼 대량의 폴링 데이터를 수집하고 여러 컨슈머(DB 저장, 알림, 모니터링)가 동일 데이터를 각자의 속도로
소비해야 하는 구조에서는 Kafka가 명확한 선택입니다.
⭐발표자 : 이경훈님