카프카의 기본 구성
카프카는 고성능 분산 이벤트 스트리밍 플랫폼으로,
대용량 실시간 데이터 파이프라인을 구축하는 데 사용됩니다.
프로듀서(Producer)
- 카프카에 메시지를 발행하는 애플리케이션입니다. 프로듀서는 토픽에 메시지를 발행하며, 필요에 따라 특정 파티션으로 메시지를 전송할 수 있습니다.
브로커(Broker)
- 카프카 서버로, 프로듀서로부터 메시지를 수신하고 저장하며, 컨슈머가 메시지를 가져갈 수 있도록 합니다. 여러 브로커가 클러스터를 구성하여 고가용성을 제공합니다.
주키퍼(ZooKeeper)
- 카프카 클러스터의 메타데이터를 관리하고, 브로커의 상태를 감시하며, 리더 선출 등의 작업을 담당합니다. (최신 버전에서는 주키퍼 의존성이 제거되고 있습니다.)
컨슈머(Consumer)
- 카프카로부터 메시지를 구독하고 처리하는 애플리케이션입니다. 컨슈머는 특정 토픽을 구독하고, 파티션으로부터 메시지를 가져옵니다.
토픽은 여러 파티션으로 나뉘며, 각 파티션은 여러 브로커에 분산됩니다. 리플리케이션 팩터에 따라 각 파티션의 복제본이 여러 브로커에 저장됩니다.
리플리케이션(Replication)
- 리플리케이션은 데이터의 복제본을 여러 브로커에 분산 저장하여 내결함성을 제공합니다. 각 파티션에는 리더와 팔로워가 있으며, 프로듀서와 컨슈머는 리더와 통신합니다.
파티션(Partition)
- 토픽은 여러 파티션으로 나뉘어 병렬 처리를 가능하게 합니다. 각 파티션은 정렬된 변경 불가능한 메시지 시퀀스로, 고유한 오프셋을 가집니다.
세그먼트(Segment)
- 파티션은 여러 세그먼트 파일로 구성되며, 세그먼트는 실제 디스크에 저장되는 물리적 파일입니다.
- 토픽은 논리적 개념으로, 여러 파티션으로 구성됩니다.
- 파티션은 메시지의 병렬 처리를 가능하게 하며, 토픽의 처리량을 증가시킵니다.
- 파티션은 물리적으로 여러 세그먼트 파일로 구성됩니다. 세그먼트는 일정 크기에 도달하면 새로운 세그먼트가 생성되고, 오래된 세그먼트는 보존 정책에 따라 삭제됩니다.
- 토픽은 파티션으로 나뉘고, 파티션은 세그먼트로 구성됩니다. 이러한 계층 구조는 카프카의 확장성과 성능을 향상시킵니다.
간단 실습 AWS
- AWS EC2 zk용 3대, kafka 3대, ansible 배포용 1대 구성
-
Producer 에서 카프카의 토픽으로 메시지 전송 First message
-
Consumer에서 메시지 확인
카프카의 핵심 특징
분산 시스템
- 카프카는 여러 브로커로 구성된 분산 시스템으로, 단일 장애점 없이 고가용성을 제공합니다. 분산 아키텍처를 통해 대규모 데이터를 처리하고 저장할 수 있습니다.
페이지 캐시
- 카프카는 운영체제의 페이지 캐시를 활용하여 디스크 I/O를 최소화합니다. 이를 통해 메모리 사용량을 줄이면서도 빠른 읽기/쓰기 성능을 제공합니다.
배치 전송 처리
- 카프카는 메시지를 개별적으로 처리하지 않고 배치로 처리하여 네트워크 오버헤드를 줄이고 처리량을 증가시킵니다. 프로듀서와 컨슈머 모두 배치 처리를 통해 효율성을 높입니다.
압축 전송
- 카프카는 메시지 압축을 지원하여 네트워크 대역폭 사용을 줄이고 저장 공간을 절약합니다. Gzip, Snappy, LZ4, ZSTD 등 다양한 압축 알고리즘을 지원합니다.
고가용성 보장 - 리더 팔로워
- 카프카는 각 파티션에 대해 리더와 팔로워를 지정하여 고가용성을 보장합니다.
- 리더는 읽기와 쓰기를 모두 담당하고, 팔로워는 리더의 데이터를 복제합니다.
- 리더에 장애가 발생하면 팔로워 중 하나가 새로운 리더로 선출됩니다.
주키퍼 의존성
- 주키퍼는 카프카 클러스터의 메타데이터를 관리하고, 브로커의 상태를 감시하며, 리더 선출 등의 작업을 담당합니다. 최신 버전의 카프카에서는 주키퍼 의존성을 제거하고 자체 메타데이터 관리 시스템(KRaft)으로 전환하고 있습니다.
- 컨슈머 그룹은 같은 토픽을 구독하는 여러 컨슈머의 집합입니다.
- 각 파티션은 하나의 컨슈머 그룹 내에서 하나의 컨슈머에게만 할당됩니다.
- 이를 통해 부하 분산과 병렬 처리가 가능해집니다.
- 컨슈머 그룹을 통해 메시지 처리의 확장성을 확보할 수 있으며, 장애 발생 시 자동으로 파티션을 재분배합니다.
프로듀서와 컨슈머의 동기/비동기 처리 선택 가이드
프로듀서
1. 비동기 전송을 선택해야 하는 경우
- 높은 처리량이 최우선 요구사항일 때
- 일부 메시지 손실이 허용되는 경우
- 배치 처리 최적화가 필요한 경우
2. 동기 전송을 선택해야 하는 경우
- 모든 메시지의 전송 확인이 중요한 경우
- 메시지 순서가 중요한 경우
- 트랜잭션 처리와 같이 정확성이 중요한 경우
컨슈머
1. 비동기 커밋을 선택해야 하는 경우
- 높은 처리량이 필요한 경우
- 중복 처리가 허용되는 경우
- 커밋 오버헤드를 최소화하고자 할 때
2. 동기 커밋을 선택해야 하는 경우
- 정확한 오프셋 관리가 중요한 경우
- 중복 처리를 최대한 방지하고자 하는 경우
- 장애 복구 시 일관성이 중요한 경우
일반적인 처리는 비동기로 하고, 종료 시점이나 특정 중요 지점에서는 동기 처리를 사용하는 방식의 하이브리드 접근 방식을 취한다고 한다.
