정의
여러 대의 분산 서버에서 대량의 데이터를 처리하는 분산 메시징 시스템
특징
- 스케일 아웃 구성
메시지를 중계하는 브로커를 여러 대 구성할 수 있으며, 브로커 수를 증가함으로써 클러스터 전체의 처리량을 증가 - 데이터의 디스크 영속화
브로커에서 수신한 메시지는 디스크에 기록되어 영속화됨.
디스크 용량에 따라 장기간의 과거 데이터를 저장, 재취득이 가능 - 연계할 수 있는 제품 존재
프로듀서/컨슈머를 구현하기 위한 API가 제공되어 이를 구현하는 OSS가 많이 존재 - 메시지의 도달 보증
ACK와 Offset Commit 방식으로 메시지가 제대로 송수신되었음을 확인하고 실패 시 재시도를 허용
구성요소
Producer
메시지 생산자이며 브로커에 메시지를 보내는 애플리케이션
Broker
메시지 수집/전달하는 서비스
Consumer
브로커에서 메시지를 취득하는 애플리케이션
Message
카프카에서 다루는 데이터의 최소 단위
카프카가 중계하는 로그의 한 줄 한줄과 센서 데이터 등이 이에 해당
메시지는 key 와 value를 갖게 되며 나중에 언급할 메시지 전송할 때 파티셔닝에 이용
Topic
메시지를 토픽별로 관리하는 스토리지.
브로커에 배치되어 관리.
프로듀서와 컨슈머는 특정 토픽을 지정하여 메시지를 송수신함으로써 단일 카프카 클러스터에서 여러 종류의 메시지를 중계
동작원리
Producer 동작 원리
Producer는 메시지를 생성하고 Kafka 브로커에 전송하는 역할
- 메시지를 전송할 때 특정 Topic을 지정
- Partitioner를 이용해 메시지를 어떤 Partition에 저장할지 결정
- Key가 있는 경우: 같은 Key 값의 메시지는 같은 Partition으로 전달
- Key가 없는 경우: Round Robin 방식으로 균등 분배 - Producer가 메시지를 보내면 Acknowledge(ACK) 응답을 받아 메시지 전송 성공 여부 확인
- acks=0: 전송 후 확인 안 함 (빠르지만 데이터 유실 가능)
- acks=1: Leader Partition에서 저장 후 확인
- acks=all: 모든 복제본 저장 후 확인 (가장 안전하지만 속도 저하)
Broker 동작 원리
Kafka 클러스터는 여러 개의 Broker(서버)로 구성
-
토픽과 파티션 관리
- 하나의 Topic은 여러 개의 Partition으로 구성됨
- 특정 Partition의 메시지는 Leader Broker가 관리하고, 다른 Broker들이 복제(Replica)하여 백업함
- Partition 개수가 많을수록 병렬 처리 성능이 향상됨
-
리더와 팔로워(Leader-Follower) 구조
- 각 Partition은 Leader Broker가 관리하고, 다른 Broker는 Follower로 동작
- Leader가 장애가 나면 Follower 중 하나가 새로운 Leader로 승격됨 -
메시지 보관 및 로그 관리
- 메시지는 로그(Log) 형태로 저장되며, 설정된 보관 시간(예: 7일)이 지나면 삭제됨
- Consumer가 메시지를 읽어도 데이터는 사라지지 않음
Consumer 동작 원리
Consumer는 Kafka에서 메시지를 가져가서 처리하는 역할
-
Consumer Group을 사용한 병렬 처리
- 여러 개의 Consumer가 같은 Topic을 읽을 때, Consumer Group을 사용하면 Partition을 자동으로 분배함
- 한 Partition은 하나의 Consumer에게만 할당됨 -
Offset을 이용한 메시지 읽기 관리
- Kafka는 Consumer의 읽은 위치를 Offset으로 저장함
- Offset을 관리하여, 특정 지점부터 다시 읽을 수도 있음
- 자동 커밋을 활성화하면 일정 주기마다 Offset이 자동 저장됨
Zookeeper 역할 및 동작 원리
Zookeeper는 Kafka 클러스터를 관리하는 역할
- 브로커 상태 모니터링
- Kafka 클러스터의 Broker를 감시하고 장애 감지 시 새로운 Leader를 선출 - Offset 및 메타데이터 관리
- Consumer의 Offset 정보를 저장하여, Consumer가 어디까지 읽었는지 추적 가능 - Leader 선출
- Partition의 Leader-Follower 구조에서 Leader가 다운되면 새로운 Leader를 자동으로 선출
장단점
✅ 장점
-
고성능 (High Throughput)
분산 구조와 배치 처리 방식으로 초당 수백만 건 이상의 메시지를 처리 가능 -
확장성 (Scalability)
브로커와 파티션을 추가하여 쉽게 성능을 확장할 수 있음 -
내결함성 (Fault Tolerance)
데이터 복제를 통해 장애 발생 시에도 데이터 유실 없이 운영 가능 -
유연한 데이터 처리
실시간 스트리밍뿐만 아니라 배치 처리도 가능.
Apache Flink, Spark 등과 연동하여 데이터 분석 및 실시간 모니터링 가능
❌ 단점
-
초기 설정 및 운영 복잡성
클러스터 구성 및 Zookeeper 설정이 복잡하며, 운영에 대한 이해가 필요함 -
메시지 순서 보장 어려움
같은 파티션 내에서는 순서가 보장되지만, 여러 파티션을 사용할 경우 순서가 보장되지 않을 수 있음 -
소규모 시스템에 부적합
대규모 분산 환경에서 최적화된 아키텍처이므로, 작은 규모의 시스템에서는 과도한 리소스 사용이 발생할 수 있음
활용 사례
- 데이터 허브
여러 시스템 사이에서 데이터를 상호 교환 - 로그수집
BI 도구를 이용한 리포팅과 인공지능 분석을 위해 여러 서버에서 생성된 로그를 수집하고 축적할 곳에 연결 - 웹 활동 분석
실시간 대시보드와 이상 탐지/부정 검출 등 웹에서의 사용자 활동을 실시간으로 파악 - 사물인터넷
센서 등 다양한 디바이스에서 보낸 데이터를 수신해서 처리한 후 디바이스에 송신 - 이벤트 소싱
데이터에 대한 일련의 이벤트를 순차적으로 기록하고 CQRS 방식으로 대량의 이벤트를 유연하게 처리
※ CQRS(Command Query Responsibility Segregation)는 읽기 및 쓰기 아키텍처를 분리하여 취급하는 개념참고
실전 아파치 카프카
