카프카(kafka)란?
Kafka는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산형 데이터 스트리밍 플랫폼이다. 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었다. 간단히 말해 A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이터를 동시에 이동할 수 있다.
Kafka는 전통적인 엔터프라이즈 메시징 시스템의 대안이다. 하루에 1조 4천억 건의 메시지를 처리하기 위해 LinkedIn이 개발한 내부 시스템으로 시작했으나, 현재 이는 다양한 기업의 요구 사항을 지원하는 애플리케이션을 갖춘 오픈소스 데이터 스트리밍 솔루션이 되었다.
카프카 탄생의 배경
2011년, '링크드인 (LinkedIn)’에서는 파편화된 데이터 수집 및 분배 아키텍처를 운영하는데에 큰 어려움을 겪었다. 데이터를 생성하고 적재하기 위해서는 소스 애플리케이션과 타깃 애플리케이션을 연결해야한다. 초기 운영 시에는 단방향 통신을 통해 소스 애플리케이션에서 타깃 애플리케이션으로 연동하는 소스코드를 작성했고 아키텍처가 복잡하지 않았으므로 운영이 힘들지 않았지만, 시간이 지날수록 거대해지는 아키텍처에 따라 소스 애플리케이션과 타깃 애플리케이션의 개수가 점점 많아지면서 문제가 생겼다. 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작했다.
이를 해결하기 위해 링크드인 데이터팀에서는 기존에 나와있던 각종 상용 데이터 프레임워크와 오픈소스를 아키텍처에 녹여내어 데이터 파이프라인의 파편화를 개선하려고 했다. 다양한 메시징 플랫폼과 ETL(Extract Transform Load) 툴을 적용하여 아키텍처를 변경하려고 노력했지만 파편화된 데이터 파이프라인의 복잡도를 낮춰주는 아키텍처가 되지는 못했다.
결국, 링크드인의 데이터팀은 신규 시스템을 만들기로 결정했고 그 결과물이 바로 아파치 카프카(Apache Kafka)다. 링크드인의 내부 데이터 흐름을 개선하기 위해 개발한 카프카는 매우 훌륭하게 동작했다. 카프카는 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아 처리할 수 있도록 중앙집중화했다.
카프카를 구성하는 주요 요소
- 주키퍼(ZooKeeper): 카프카의 중요한 메타데이터 관리 및 브로커의 정상상태 점검을 담당
- 카프카(Kafka) 또는 카프카 클러스터(Kafka cluster): 아파치 프로젝트 애플리케이션 이름으로, 여러 대의 브로커를 구성한 클러스터를 의미
- 브로커(broker): 카프카 애플리케이션이 설치된 서버 또는 노드
- 프로듀서(producer): 카프카로 메시지를 보내는 역할을 하는 클라이언트를 총칭
- 컨슈머(consumer): 카프카에서 메세지를 꺼내가는 역할을 하는 클라이언트를 총칭
- 토픽(topic): 카프카는 메세지 피드들을 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유함
- 파티션(partition): 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것을 의미
- 세그먼트(segment): 프로듀서가 전송한 실제 메세지가 브로커의 로컬 디스크에 저장되는 파일을 의미
- 메세지(message) / 레코드(record): 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각을 의미
카프카의 핵심 개념과 특징
분산 시스템
카프카는 분산 시스템으로 최초 구성한 클러스터의 리소스가 한계치에 도달해 더욱 높은 메세지 처리량이 필요한 경우, 브로커를 추가하는 방식으로 확장할 수 있다. 이러한 분산 시스템은 높은 성능을 보여준다는 장점 외에도 하나의 서버나 노드에 장애가 발생할 경우에 다른 서버나 노드가 대신 처리하여 장애 대응에 효과적인 점과 부하가 높아짐에 따라 시스템 확장 시에도 용이하다.
페이지 캐시
페이지 캐시는 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용한다. 이렇게 페이지 캐시를 이용하면 디스크에 대한 접근이 줄어들어 성능을 높일 수 있다. 카프카는 높은 처리량을 얻기 위해 페이지 캐시 방법을 이용한다.
배치 전송 처리
카프카는 배치 전송 처리를 지원한다. 카프카 브로커가 프로듀서, 컨슈머와 메세지를 주고 받을 때, 단건으로 처리하는 것이 아니라 배치 단위로 묶어서 처리한다면 네트워크 오버헤드를 줄일 수 있고 장기적으로는 더욱 빠르고 효율적으로 처리할 수 있다. 따라서 지연없이 실시간으로 처리해야하는 메세지가 아닌 경우 배치 단위로 처리하는 것을 카프카에서는 권장한다.
압축 전송
카프카는 메세지 전송 시 좀 더 성능이 높은 압축 전송을 사용하는 것을 권장한다. 압축만으로도 네트워크 대역폭이나 회선 비용 등을 줄일 수 있고, 배치 전송과 결합하여 사용한다면 더욱 높은 효과를 얻게 된다.
고가용성 보장
카프카는 고가용성을 보장하기 위해 리플리케이션 기능을 제공한다. 따라서 하나의 서버나 노드가 다운되어도 다른 서버나 노드가 역할을 대신하여 안정적인 서비스가 가능하다. 카프카 리플리케이션 기능은 토픽 자체를 복제하는 것이 아니라 토픽의 파티션을 복제한다. 토픽을 생성할 때 리플레케이션 팩터 수를 지정할 수 있고, 원본과 리플리케이션을 각각 리더, 팔로워로 구분한다.
카프카에서는 리플리케이션 팩터 수를 3(리더 1, 팔로워 2)으로 구성하도록 권장한다. 팔로워 수에 따라 브로커와 디스크의 공간이 사용되기 때문에 많다고 좋은 것은 아니다. 리더는 프로듀서와 컨슈머로부터의 읽기와 쓰기 요청을 처리하며, 팔로워는 오직 리더로부터 리플리케이션하게 된다.
참고
https://www.redhat.com/ko/topics/integration/what-is-apache-kafka
실전 카프카 개발부터 운영까지(고승범)
아파치 카프카 애플리케이션 프로그래밍 with 자바(최원영)
