Apache Kafka
탄생 배경
카프카는 비즈니스 소셜 네트워크 서비스인 링크드인(linked-in)에서 처음 개발한 기술로, 링크드인 사이트가 급속도로 성장하면서 발생한 내부 여러 이슈들을 해결하기 위해 탄생하였음
카프카 개발 전, 과거 링크드인의 기존 데이터 처리 시스템
각 애플리케이션과 DB가 end-to-end로 연결되어 있고, 요구사항이 늘어남에 따라 데이터 시스템 복잡도가 높아지면서 여러 문제가 발생하게 됨
기존 데이터 시스템의 문제점
시스템 복잡도 증가
실시간 트랜잭션 처리와 비동기 처리가 동시에 이뤄지지만, 통합된 전송 영역이 없으니 데이터 흐름을 파악하기 어렵고 시스템 관리가 어려움
특정 부분에서 장애 발생 시, 조치를 취하려면 연결되어 있는 애플리케이션을 모두 확인하며 이 때문에 조치를 취하기까지 시간이 걸림
데이터 파이프라인 관리의 어려움
각 애플리케이션과 데이터 시스템 간의 별도의 파이프라인이 존재하고, 파이프라인마다 데이터 포맷과 처리 방식이 다름
새로운 파이프라인 확장이 어려워져 확장성과 유연성이 떨어짐
시스템 간 데이터 불일치 가능성으로 신뢰도가 낮아짐
카프카를 이용한 링크드인의 데이터 처리 시스템
링크드인 개발자들이 4가지의 목표를 가지고 새로운 시스템(카프카)을 개발함
프로듀서와 컨슈머의 분리(송신자와 수신자의 분리)
메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
높은 처리량을 위한 메시지 최적화
데이터가 증가함에 따라 스케일 아웃이 가능한 시스템
카프카로 인해 얻은 결과
모든 이벤트/데이터 흐름을 중앙에서 관리
새로운 서비스 추가 시 표준 포맷으로 연결 가능하여 확장성과 신뢰성 증가
개발자는 카프카에 데이터만 전달하면 되어 각 서비스 간 연결이 아닌 비즈니스 로직에 집중 가능
카프카란?
오픈 소스 분산 이벤트 스트리밍 플랫폼으로써 데이터를 생성하는 애플리케이션과 데이터를 소비하는 애플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어 및 처리와 관리 역할을 함여러 노드와 함께 구성될 수 있어 카프카 클러스터라고도 함
서버 간의 비동기 데이터 교환을 용이하게 하고, 하루에 많은 양의 이벤트 처리가 가능하도록 함
이벤트 스트리밍데이터베이스, 센서, 모바일 장치, 클라우드 서비스, 소프트웨어 어플리케이션과 같은 이벤트 소스에서 실시간 데이터를 이벤트 스트림의 형태로 처리하거나 분석하는 것
이벤트 스트림: 시간별로 정렬된 일련의 비즈니스 이벤트(연속적인 많은 이벤트들의 흐름)
카프카는 이벤트 스트리밍으로써 중요한 세 가지 기능을 가지고 있음
이벤트 스트리밍을 지속적으로 발행(publish-write)하고 구독(subscribe-read) 함
이벤트 스트리밍을 원하는 만큼 내구성 있고 안정적으로 저장(store)함 ➜ KafkaCluster(broker)
이벤트 스트림이 발생하거나 소급되었을 때 지속적으로 처리(process)함
메시지 큐(Message Queue, MQ)
메시지 지향 미들웨어(MOM)는 비동기 메시지를 사용하는 각각의 응용 프로그램 사이의 데이터 송수신을 의미하고, 이를 구현한 시스템을
메시지 큐라고 함
카프카의 기본 구성요소
Kafka Cluster: 카프카의 브로커들의 모임으로, 카프카는 확정성과 고가용성을 위하여 브로커들이 클러스터로 구성됨Cluster: 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
Zookeeper: 분산 애플리케이션 관리를 위한 코디네이션 시스템분산 메시지 큐의 정보를 중앙에서 관리해주는 역할
Producer: 데이터를 생성하고 Kafka Cluster로 전달하는 주체데이터를 Topic에 발행하여 Broker에 전송함
Consumer: Kafka Cluster에서 데이터를 소비하는 주체Producer에서 전달한 데이터를 Broker에 요청하여 메시지(데이터)를 소비하는 역할
Consumer Group: 목적에 따라 모인 다수의 Consumer들의 그룹
Broker: 카프카 클러스터를 구성하는 서버 노드(카프카 서버)데이터를 Producer로 부터 받아 Topic에 저장하고, Consumer에게 필요한 데이터를 전달하는 중재자(Broker) 역할
Topic: 보내는 메시지를 구분하기 위해 카테고리화된 주제Producer가 메시지를 발행하는 곳이며, Consumer는 특정 Topic에서 메시지를 소비함
Topic은 1개 이상의 Partition으로 분할됨
Partition: 병렬 처리 및 고성능을 위해 Topic을 Storage에 물리적으로 나누어 데이터를 저장하는 단위특정 Topic의 데이터를 여러 Partition에 분산해서 저장하여 Scale-out이 가능함
각 Partition은 별도의 브로커에 저장될 수 있음
데이터를 효율적으로 분산하고 병렬 처리할 수 있도록 함
카프카 특징(장점)
카프카는 이벤트 스트리밍 플랫폼으로서 여러가지 역할을 할 수 있고, MQ처럼 메시지 브로커 역할을 할 수 있음
Event-Oriented
이벤트 중심의 시스템 구성
고성능
대용량 실시간 로그 처리에 특화됨
고가용성
다수의 브로커로 구성되어 장애 발생 시에도 시스템을 유지할 수 있음
확장성(Scale-out)
카프카 클러스터는 여러 대의 서버로 확장 가능하며, 수천 대의 브로커와 수십만개의 Partition으로 이루어진 대규모 클러스터를 구성할 수 있음
분산 아키텍처
컨슈머가 토픽을 구독하여 메시지를 읽는 구조
Publish-Subscribe 모델
메시지를 받기 원하는 컨슈머가 해당 토픽(topic)을 구독함으로써 메시지를 읽어 오는 구조
기존 메시징 시스템은 브로커가 컨슈머에게 메시지를 push 해주는 방식인데, 카프카는 컨슈머가 브로커로부터 메시지를 직접 가져가는 pull 방식으로 동작함
컨슈머 중심으로, 컨슈머가 자신의 처리 능력만큼의 메시지만 가져와서 최적의 성능을 낼 수 있음
브로커 중심적인 브로커 메시지와 달리 브로커의 역할이 비교적 단순해짐
메시지를 파일 시스템에 저장하여 데이터 유실을 방지
메시지를 메모리에 저장하는 기존 시스템과 달리 파일에 저장함
장애 시, 데이터 유실 복구가 가능함
메시지가 많이 쌓여도 성능이 크게 저하되지 않음
대규모 처리를 위한 batch 작업에 용이함
카프카의 단점
구성 복잡도
초기 구성이 복잡하고 기술적 이해가 필요
설정 오류의 위험성
다양한 설정 옵션으로 인해 잘못된 설정 시 오류가 발생할 수 있음
아파치 카프카는 서버의 수와 스토리지의 용량에 따라 비용이 증가할 수 있음
기본 브로커가 3개 이상 필요하기 때문에 서버 비용이 듦
Last updated