Kafka의 탄생 배경과 특징들에 대해 알아보겠다. 또, 기업들에선 어떻게 Kafka를 도입했는지 알아보겠다.
Kafka 의 탄생 배경
카프카는 다들 잘 알고 있는 미국의 소셜 네트워크 서비스인 링크드인 에서 처음 출발한 기술로서, 링크드인 사이트가 급속도로 성장할 때 발생하는 내부 이슈들을 해결하기 위해 탄생되었다.
링크드인에서 Kafka를 도입하기 전에는 아래의 아키텍처를 가지고 서비스되었다.
위의 그림을 보면 카프카를 사용하기 전에는, 각각의 서비스들이 높은 결합도를 가지며 내부적으로 통신하고 있다. 처음에는 고객DB, 스플렁크 정도로 시작하다가 서비스가 커지면서 자연스럽게 데이터 스토어가 분화된다.
많은 사용자의 요청에도 빠른 응답을 하기 위해 미들웨어로 키/값 스토리지(ex. Redis)에도 사용자 요청 데이터를 넣게 된다고 가정해본다. 서버에서는 사용자 요청 데이터를 특정 객체로 만들고 직렬화(Serialization)해서 키/값 스토리지에 저장한다.
그리고 비즈니스 분석을 하는 데 고객 요청 데이터가 필요하고, 기존에 데이터베이스, 메시지 큐, 키/값에 넣었던 것 중 하나의 포맷을 사용하려고 한다면, 대부분의 데이터 웨어하우스는 다양한 포맷의 데이터를 지원하지 못하므로 데이터베이스 컬럼에 맞춰서 CSV 포맷으로 변경해야 한다. 즉, 데이터를 주기적으로 CSV 포맷으로 변형시켜(Transform), 데이터 웨어하우스에 넣는 작업을 하는 앱을 또 만들고 운영해야 한다.
- 데이터 웨어하우스에서 여러 포맷의 데이터를 지원하지만, 데이터 통합과 일관성을 유지하는 것이 중요하므로, 모든 데이터 형식을 지원하는 것이 어렵다는 의미이다.
- 대부분의 데이터 웨어하우스는 ETL(Extract, Transform, Load) 과정을 통해 데이터가 저장된다. 즉, 데이터를 변형시켜 일관된 포맷으로 저장한다.
데이터 웨어하우스란?
데이터 웨어하우스는 보다 정보에 입각한 의사 결정을 내릴 수 있도록 분석 가능한 정보의 중앙 리포지토리이다. 데이터 웨어하우스는 다양한 소스(트랜잭션 시스템, 관계형 데이터베이스 등등) 에서 수집된 데이터를 통합하여 일관성 있는 형식으로 저장하며, 이를 기반으로 다양한 분석 작업을 수행할 수 있다. 또한 데이터 웨어하우스는 대량의 데이터를 처리하기 위한 최적화된 구조를 가지고 있으며, 데이터 검색 및 분석 작업에 최적화되어 있다.
다시 본론으로 돌아가서 정리해보자면, 여러 개의 서비스들이 각각의 방식으로 메시지를 주고받으며 통신하고 있다. 즉, 여러 개의 서비스들이 높은 결합도 를 가지고 운영되고 있다.
이런 방식을 엔드투엔드(end-to-end) 연결 방식의 아키텍처라고 하는데, 이 방식에는 문제점들이 존재한다.
엔드투엔드(end-to-end) 연결 방식의 아키텍처
End-to-end (E2E) 연결 방식은 네트워크에서 데이터를 전송하는 방식 중 하나이다. 이 방식은 데이터가 출발지에서 목적지까지 직접적으로 이동하는 것을 의미한다.
이 방식에서는 데이터를 전달하는 모든 단계에서 중간 노드들이 개입되지 않고, 데이터의 처리와 전송은 출발지와 목적지에서만 이루어진다. 즉, 데이터의 전송 경로상에 있는 모든 노드가 단순히 데이터를 전달하고, 데이터를 처리하지 않는다.
통합된 전송 영역이 없어서 복잡도 증가
실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송 영역이 없어서 복잡도가 증가한다. 즉 각각의 통신 방법으로 여러 서비스들이 통신하기에 관리하는 데에도 많은 문제가 생기고, 이 모든 통신 방법들을 유지보수하기에 굉장히 힘들어진다.
따라서 서버 증설, 하드웨어 증설, 운영체제 업그레이드 등의 작업에서도 많은 준비 시간이 필요해진다.
데이터 파이프라인 관리의 어려움
실시간 트랜잭션 데이터베이스, 아파치 하둡, 모니터링 시스템, 키-값 저장소 등 많은 데이터 시스템들이 있는데, 이 시스템에 저장된 동일한 데이터를 개발 부서들이 각기 다른 방법으로 파이프라인을 만들고 유지하게 된다. 처음에는 간편하더라도, 나중에는 통합 데이터 분석을 위해 서로 연결되어야 하는 일들이 필연적으로 발생한다.
여러 개의 데이터 파이프라인은 각각 데이터 포맷과 처리하는 방법들이 달라서 데이터 파이프라인을 확장하기 어려웠고, 이러한 데이터 파이프라인들을 조정하고 운영하는 것은 엄청난 노력이 필요해진다.
이런 문제들을 해결하기 위해 Kafka 가 만들어졌다. Kafka의 주요 목적은 다음과 같았다.
- 프로듀서와 컨슈머 분리
- 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
- 높은 처리량을 위한 메시지 최적화
- 데이터가 증가함에 따라, 스케일 아웃이 가능한 시스템
카프카를 적용한 링크드인 서비스 아키텍처
링크드인에서 카프카를 도입하고 나서의 아키텍처는 다음과 같다.
사내에서 발생하는 모든 이벤트/데이터의 흐름을 중앙에서 관리하는 카프카를 적용한 결과는 굉장히 직관적으로 바뀌었다!
카프카를 적용했을 때의 이점에 대해 정리해보자.
- 카프카가 전사 데이터 파이프라인으로 동작하기 때문에 모든 데이터 스토어와 서비스에서 발생하는 데이터/이벤트가 카프카를 중심으로 연결되어 있다.
- 새로운 데이터 스토어가 들어와도 서로 카프카가 제공하는 표준 포맷으로 연결되어 있어서 데이터를 주고받는데 부담이 없다.
- 이전에는 할 수 없었던 다양한 분석이 가능해진다.
카프카의 동작 원리
메시지를 보내는 측을 퍼블리셔(Publisher) 혹은 프로듀서(Producer) 라고 하고, 메시지를 가져가는 쪽을 서브스크라이버(Subscriber) 혹은 컨슈머(Consumer) 라고 한다.
프로듀서가 메시지를 보내면 카프카에서는 토픽이라는 메시지 저장소를 이용해 메시지를 저장하고, 컨슈머에서는 원하는 토픽에서 메시지를 가져간다.
중앙에 메시징 시스템 서버를 두고, 이렇게 메시지를 보내고 받는 형태의 통신을 펍/섭 모델(Pub/Sub model) 이라고 한다.
Pub/Sub 모델이란?
일반적 형태의 통신(
엔드투엔드 연결방식)은 통신에 참여하는 개체가 많아질수록 서로 일일이 연결을 하고 데이터를 전송하기에 확장성이 좋지 않다.
하지만,Pub/Sub 모델은 프로듀서가 메시지를 중간의 메시징 시스템에 전달함으로써 확장성이 용이해지는 장점을 가진다.
하지만Pub/Sub 모델은 네트워크를 타고 메시징 시스템에 메시지가 전송되기에 기존의 일반적인 통신방법(엔드투엔드)에 비해 많이 느려지고, 보내는 데이터의 양을 축소시켜야 했다. 즉,Pub/Sub모델에는 속도와 용량 측면에서의 단점이 존재한다. 그래서Pub/Sub 모델은 대규모 데이터를 메시징 시스템을 통해 전달하기 보다는 간단한 이벤트를 서로 전송하는데 주로 사용된다.
카프카는 기존 Pub/Sub 모델의 "속도와 용량의 문제" 를 해결하기 위해, 카프카는 프로듀서와 컨슈머가 직접 메시지 교환 전달의 신뢰성 관리를 하게 하고, 부하가 많이 걸리는 교환기 기능도 직접하지 않아 메시징 전달에만 집중할 수 있어 성능 향상을 꾀하였다. 또한 카프카 역시 비동기 시스템으로 컨슈머는 프로슈머와 관계없이 데이터를 가져가고, 프로듀서 또한 컨슈머와 관계없이 데이터를 생산한다.
카프카의 특징
기존 메시징 시스템과 차별화되는 특징들 에 대해 알아본다.
프로듀서와 컨슈머의 분리
링크드인에서 메트릭 수집 방식을 폴링방식으로 구현된 시스템을 사용하면 메트릭 수집이나 처리 시간이 늦어지는 문제점이 있었다.
폴링 방식?
폴링(Polling) 방식은 시스템에서 정기적으로 특정한 주기로 데이터를 수집하는 방법입니다. 예를 들어, 메트릭 수집 시스템에서는 정해진 시간 간격으로 서버나 어플리케이션의 상태를 확인하고 데이터를 수집합니다.
아래의 코드 예시와 같다.while(true) { if (요청 없을 시) { sleep(1000); continue; } // 로직 // 응답 }
그래서 카프카는 메시징 전송 방식 중 메시지를 보내는 역할과 받는 역할이 완벽하게 분리된 펍/섭 방식을 적용했다. 카프카를 이용하면 구조가 단순해지고, 서비스 서버들은 모니터링이나 분석 시스템 등의 상태와 상관없이 카프카로 메시지를 보내는 역할만 함으로써 각자의 역할이 분리되는 장점을 가진다. 또한 서버 추가에 대한 부담도 줄일 수 있다.
멀티 프로듀서, 멀티 컨슈머
카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조로 되었다. 하나의 프로듀서가 하나 이상의 토픽으로 메세지를 보낼 수 있고, 하나의 컨슈머가 하나 이상의 토픽으로부터 메시지를 가져올 수 있다.
이렇기에 카프카는 중앙집중형 구조로 구성할 수 있다.
디스크에 메시지 저장
카프카가 기존의 메시징 시스템과 가장 다른 특징 중 하나는 바로 디스크에 메시지를 저장하고 유지하는 것이다.
- 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽으면 큐에서 메시지를 삭제한다.
- 하지만, 카프카는 컨슈머가 메시지를 읽어가더라도 정해져 있는 보관주기동안 디스크에 메시지를 저장해둔다.
메시지가 디스크에 저장되어 있기 때문에, 메시지 손실 없이 작업이 가능하다.
확장성 용이
하나의 카프카 클러스터는 3대의 브로커로 시작해 수십대의 브로커로 확장 가능하다. 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다.
높은 성능
카프카는 고성능을 유지하기 위해 카프카는 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하고 있다.
- ex) 파티셔너에서는 프로듀서에서 온 메시지들을 모을 수 있는 만큼 모아서, 배치 처리를 해줌으로써 성능을 높였다.
카프카의 확장과 발전
카프카가 등장하면서 서비스 기반 아키텍처(SOA, Service Oriented Architecture)의 핵심 구성요소 중 하나인 엔터프라이즈 서비스 버스(ESB, Enterprise Service Bus)를 쉽게 구현할 수 있게 되었다.
또한, 카프카 스트림즈를 통해 스트림 처리 앱을 개발할 수 있게 되고, KSQL을 통해 SQL 기반으로 데이터를 실시간으로 분석할 수 있게 되었다.
스트림이란?
스트림(stream)은 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 수많은 방식에서 쓰인다. 예시로는, 영상, 음성과 같이 작은 조각들이 하나의 줄기를 이루며 전송되는 데이터 열을 의미한다.
일반적으로 스트림 데이터는 배치 처리(batch processing)와 달리 실시간으로 처리되며, 데이터가 생성되는 즉시 처리됩니다. 이는 대규모 데이터의 처리와 분석, 실시간 모니터링 등 다양한 분야에서 중요한 역할을 한다.
카프카 스트림즈에서 스트림은 카프카 토픽(topic)에서 생성된 데이터의 연속적인 흐름을 나타낸다. 이러한 스트림 데이터를 처리하고 변환하여 새로운 스트림 데이터를 생성하거나 외부 시스템으로 전달할 수 있다. 이를 통해 실시간으로 데이터를 처리하고 원하는 결과를 도출할 수 있다.
Reference
카프카, 데이터 플랫폼의 최강자
https://www.confluent.io/blog/event-streaming-platform-1/
https://www.sap.com/korea/insights/what-is-a-data-warehouse.html
https://enlqn1010.tistory.com/32
