카프카는 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 현재에는 많은 기업들이 자사의 빅데이터를 기반으로 사용자의 성향을 분석해 고객 행위를 예측하는 추천 기술에 관심을 가지면서, 빅데이터를 분석할 때 여러 스토리지와 분석 시스템에 데이터를 연결하기 위한 필수 도구로 인식되고 있다.
1. 카프카 탄생 배경
카프카는 링크드인에서 내부적인 문제를 해결하기 위해 처음 고안되었다. 이해를 위해 카프카가 개발되기 전 링크드인의 데이터 처리 시스템을 보자.
이 아키텍처는 end-to-end 연결 방식을 가지고 있기에 다음과 같은 단점이 존재한다.
- 실시간 처리 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이루어지고 통합된 전송 영역이 없기에 복잡도가 증가한다.
- 데이터 파이프라인 관리가 어렵다. 시스템에는 많은 데이터 시스템들이 들어 있지만, 개발 부서들이 각기 다른 방법으로 파이프라인을 만들고 유지했다. 때문에 추후 데이터 분석을 위해 서로 연결돼야 했을 때, 데이터 포맷이 달라서 파이프라인 확장이 어렵다. 이런 복잡성으로 인해 두 시스템 간의 데이터가 서로 달라서 데이터의 신뢰도가 낮아졌다.
위 문제들을 해결하기 위해 카프카는 메시지 전달의 중앙 플랫폼으로서 , 모든 데이터 시스템, 마이크로 서비스, 사스 서비스 등과 연결된 파이프라인을 만드는 것을 목표로 개발되었다.
결론적으로 사내에서 발생하는 모든 이벤트, 데이터 흐름을 카프카가 중앙에서 관리하게 되었다.
2. 카프카의 동작 방식과 원리
카프카는 기본적으로 메시징 서버로 동작한다. 대략적인 동작 과정은 다음과 같다.
- 프로듀서는 메시지(데이터 단위)를 토픽(메시지 저장소)에 저장한다
- 컨슈머는 원하는 토픽에서 데이터를 가져간다.
이렇게 중앙에 메시징 시스템 서버를 두고, 메시지를 publish 하고 subscribe 하는 통신을 pub/sub 모델이라 한다. Pub/Sub 모델은 다음과 같은 일반적인 네트워크 형태의 단점을 극복할 수 있다.
- 특정 개체에 장애가 발생할 경우, 메시지를 보내는 쪽에서 대기 처리 등을 개별적으로 해야 한다
- 참여하는 개체가 많아질 때마다 연결을 해주고, 데이터를 전송해야 하기에 확장성이 떨어진다
위의 일반적인 네트워크 통신에 반해 pub/sub 네트워크 통신 구조는 다음과 같다
Pub/sub 구조 통신 과정은
- 프로듀서는 메시지 데이터와 수신처 ID를 메시징 시스템에 전달한다
- 메시징 시스템의 교환기가 메시지의 수신처 ID 값을 확인하고 알맞은 큐에 전달한다.
- 컨슈머는 자신들의 큐를 모니터링하다가 큐에 메시지가 전달되면 이 값을 가져온다
위와 같은 동작 과정을 통해 다음과 같은 이점을 얻는다
- 개체 하나에 장애가 발생해도, 메시징 시스템만 살아 있다면 프로듀서가 전달한 메시지가 유실되지 않는다
- 메시징 시스템을 중심으로 연결되어 있어서 확장성이 용이하다
그럼에도 다음과 같은 단점도 존재한다
- 직접 통신을 하지 않기에 메시지가 정확하게 전달되었는지 확인하려면 보다 복잡한 코드가 필요하다
- 중간에 메시징 시스템을 거치기에 전달 속다가 빠르지 않다
기존 메시징 시스템은 메시지의 보관, 교환, 전달 과정에서 신뢰성 보장에 초점이 맞춰져 있었다. 때문에 간단한 이벤트(수 KB) 전송에만 사용이 되었다. 반면, 카프카는 이러한 성능적 단점을 극복하기 위해 다음과 같은 기능들을 컨슈머 또는 프로듀서에게 넘기고, 메시징 전달 성능에 작업량을 집중시켜서 고성능 메시징 시스템을 만들었다.
- 메시지 교환 전달의 신뢰성 관리 → 프로듀서와 컨슈머에게 전가
- 교환기 기능 → 컨슈머에게 전가
위와 같은 기존 메시징 시스템과의 차이 때문에, 카프카의 대략적인 아키텍처는 다음과 같다.
카프카 동작 과정은 다음과 같다
- 프로듀서는 새로운 메시지를 카프카로 보낸다
- 프로듀서가 보낸 메시지는 카프카에 컨슈머 큐(토픽, 카프카에선 메시지들을 토픽이라는 식별자를 이용해 토픽 단위로 저장한다)에 도착해 저장된다
- 컨슈머는 카프카 서버에 접속해 새로운 메시지를 가져간다
3. 카프카 특징
카프카는 다른 메시 큐와 같이 비동기이지만, 다른 솔루션과 다른 특징들을 몇 가지 가지고 있다.
- 프로듀서와 컨슈머의 분리
- 카프카는 pub/sub 구조를 사용하기에 전체 아키텍처의 구조가 단순해진다(위의 1. 카프카 탄생 배경 참고). 프로듀서와 컨슈머가 각자 분리되어 있어서, 어느 한쪽이 문제가 발생해도 연쇄작용이 발생할 확률이 매우 낮다.
- 멀티 프로듀서, 멀티 컨슈머
- 하나의 프로듀서와 컨슈머는 각자 한 개 이상의 토픽에 접근할 수 있다. 이런 멀티 기능 덕분에 데이터 분석, 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구를 손쉽게 충족할 수 있다.
- 디스크에 메시지 저장
- 다른 메시지 큐와의 가장 큰 차이이다. 카프카는 컨슈머가 메시지를 읽어가도 정해진 주기 동안은 데스크에 메시지를 저장한다. 따라서 트래픽 폭주, 컨슈머의 버드 등의 이유로 컨슈머의 처리가 지연되어도 컨슈머는 메시지 손실 없이 메시지를 가져갈 수 있다
- 확장성
- 카프카는 확장성이 매우 뛰어나다. 하나의 카프카 클러스터는 브로커 3대에서 시작해 서비스 중단 없이도 수십 대의 브로커로 확장할 수 있다.
- 높은 성능
- 카프카는 고성능을 유지하기 위해 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하고 있다.
4. 카프카 용어 정리
- 카프카(Kafka): 아파치 프로젝트 애플리케이션 이름이다. 클러스터 구성이 가능하고, 카프카 클러스터라 불린다.
- 브로커(Broker): 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말한다.
- 토픽(Topic): 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 이름이다.
- 파티션(Partition): 병렬처리가 가능하게 토픽을 나눌 수 있고, 많은 야의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있다.
- 프로듀서(Producer): 메시지를 생산해서 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션이다
- 컨슈머(Consumer): 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션이다.
출처 - 카프카, 데이터플랫폼의 최강자