아파치 카프카(Apache Kafka)에 대해 알아봅니다. 카프카는 2011년 LinkedIn에서 파편화된 데이터 수집 및 분배를 고려하여 만든 아키텍처입니다.
데이터를 생성하고 적재하기 위해서는 Source Application(데이터 생성)과 Target Application(최종 적재)을 연결해야 하는데, 초기에는 Source Application에서 Target Application으로 단방향 통신을 함으로써 운영했지만, 아키텍처가 복잡해지고 Application의 개수가 많아지면서 많은 문제가 발생했습니다. 일부 Target Application에 장애가 생기면, 해당 Application을 바라보고 있는 Source Applicatoin들에도 영향을 끼칠 수 있었습니다.
아파치 카프카(Apache Kafka)
이러한 문제를 해결하기 위해 LinkedIn의 데이터 팀은 신규 시스템을 개발했고, 그 결과물이 아래 그림과 같은 형태입니다. 데이터를 한 곳에 모아 처리할 수 있도록 파이프라인을 중앙 집중화 했다고 할 수 있습니다.
카프카의 내부 구조 (Message Queue 구조와 유사)
Kafka의 내부는 FIFO(First In First Out)방식으로 되어있습니다. 즉, Queue와 같은 자료구조를 사용한다고 볼 수 있죠. 프로듀서가 보내는 Data는 토픽의 파티션에 전달되고, 컨슈머는 특정 파티션을 구독하여 순차적으로 데이터를 가져가는 구조입니다. 여기서 가장 큰 특징은, 컨슈머가 특정 파티션의 데이터를 가져가도 파티션에 존재하는 데이터는 사라지지 않는다는 것입니다.
- 토픽: 구분하고자 하는 데이터의 집합으로, RDBMS의 테이블과 같은 개념으로 볼 수 있습니다.
- 파티션: 토픽을 분할하여 저장하는 구조입니다. 물리적으로 데이터를 저장하며, 토픽의 메시지들은 해당 파티션에 순서대로 추가됩니다.
- 프로듀서: 데이터를 토픽으로 보내는 클라이언트입니다.
- 컨슈머: 토픽에서 데이터를 소비하고 처리하는 클라이언트입니다.
- 커밋: 컨슈머가 파티션에 있는 데이터를 어디까지 읽었는지에 대한 기록입니다.
- 브로커: 카프카 클러스터를 구성하는 서버로, 데이터를 분산 저장하고 클라이언트 간에 데이터 전달을 중재하는 역할을 합니다.
Kafka 사용 시 강점
1. 높은 처리량
대량의 데이터를 배치로 묶어, 최소한의 네트워크 비용으로 최대의 효율을 기대할 수 있습니다. 또한 동일 목적의 데이터를 여러 파티션에 분배하고 병렬 처리할 수 있습니다.
2. 확장성
데이터의 유입량을 정확히 예측하기는 어렵습니다. Kafka는 브로커 개수를 가변적으로 변경, 즉 Scale-in / Scale-out이 가능합니다. 클러스터의 무중단 운영을 지원하므로 커머스, 은행 같은 비즈니스 모델에서도 안정적인 운영이 가능합니다.
3. 영속성
데이터를 생성한 프로그램이 종료되더라도 사라지지 않습니다. 다른 메시징 플랫폼과 다르게 전송 받은 데이터를 메모리에 저장하지 않고, 파일 시스템에 저장합니다.
메모리의 경우, OS가 성능 향상을 위해 페이지 캐시(Page Cache) 메모리 영역을 생성하는데, 한 번 읽은 파일 내용을 저장시켰다가 재사용 하는 시스템이기 때문에, 영속성과 대규모 데이터 처리량을 모두 보장받을 수 있는 것입니다.
- 브로커에 장애가 발생하여 급작스럽게 종료되어도, 프로세스를 재시작하여 다시 안전하게 처리할 수 있습니다.
4. 고가용성
프로듀서에게 전송 받은 데이터를 여러 브로커에 복제(Replication)하기 때문에, 일부 브로커에 장애가 발생해도 지속적인 처리가 가능합니다.
마치며
카프카가 무엇인지와 역사, 그리고 특징들에 대해 알아보았습니다. 커머스, 금융 도메인 특성상 무중단 운영이 반드시 필요하며 Kafka는 이러한 니즈를 다방면으로 채워주고 있음을 확인했습니다. 다음 시간 부터는 카프카 브로커와 클러스터, 그리고 주키퍼 등의 기본 개념에 대해 알아보겠습니다.
답글 남기기