이 글을 시작으로 아파치 카프카에 대한 리뷰를 해 보려고 합니다.
꽤나 오래 된 도구이고, 워낙 방대한 자료가 많다보니
제가 필요한 정보 위주로 정리가 되어있는 점 참고 부탁드립니다.
대부분의 내용은 Apache Kafka 공식 사이트를 읽으며 작성되었으니
이점 참고하시기 바랍니다.
개념
실시간 데이터를 수집, 저장, 처리 작업에서 높은 처리량과 낮은 지연시간을 제공하기 위한 Event streaming platform.
Key capabilities
아파치 카프카의 핵심 주요 기능은 크게 3 가지 이다.
1. 다른 시스템으로 부터의 데이터의 지속 관리와 함께 이벤트 스트림의 publish, subscribe 를 수행
2. 이벤트 스트림을 원하는 만큼 신뢰성 있게 저장
3. 이벤트 스트림의 발생에 따른 처리
결론적으로 여러 시스템에서 발생하는 이벤트 스트림을 통해 pub-sub 구조를 구현할 수 있도록 하고
스트림을 저장, 처리 하는데 있어 신뢰성을 보장하는 것이 주요 기능이 되겠다.
이런 기능들은 분산 환경에서 제공되며, 고 가용성과 fault-tolerant 를 보장 그리고 유연하며 보안성이 고려되어 있다.
Kafka의 배포는 bare-metal, 가상머신, 컨테이너 그리고 on-premises로 구성 된 클라우드 까지도 배포가 가능하며
다양한 벤더에 의해 제공되는 서비스들을 이용하거나, 직접 구성한 Kafka 환경에서 사용이 가능하다.
Kafka의 동작
Kafka는 그래서 어떻게 동작하는 걸까?
Kafka는 TCP network protocol 을 이용해 서버와 클라이언트 간 지속적인 통신을 지원하는 분산 시스템이다.
앞서 언급하였지만, 베어메탈, 가상머신, 컨테이너 등 다양한 환경으로 배포가 가능한 것이 특징이다.
Server : Kafka 는 하나 또는 그 이상의 서버로 구성 된 클러스터로 동작한다. 어떤 서버는 broker로서 동작할 수 있으며, 다른 서버들은 데이터를 입/출력 하기위한 KafkaConnect를 수행하는 서버일 수도 있다. 카프카 서버는 highly scalable 하며 fault-tolerant 하고, 다른 서버들에서 장애가 발생하는 경우 작업을 지속하기 위한 takeover 를 보장한다.
Client : 카프카는 상위 레벨의 kafka Streams 라이브러리를 제공하며 클라이언트는 이를 이용하여 데이터를 읽고 쓰는 작업을 수행한다. 카프카 라이브러리는 Go, Python, C/C++ 등의 언어를 지원한다.
아주 간단히 말해서 카프카는 Server - Client 통신을 기반으로 동작하며 Client는 그 유형에 따라 Publisher가 될 수도 있고, Subscriber가 될 수도 있겠다.
주요 개념 과 용어
Event
하나의 이벤트는 "어떤 사건" 에 대한 사실을 기록한다.
카프카 에서는 비지니스 환경에서 일어나는 이런 이벤트들의 흐름을 기록하고 관리한다.
일반적으로 하나의 이벤트는 key, value, timestamp 그리고 부가적인 메타데이터 헤더를 관리한다.
아래는 카프카 Introduction 페이지에서의 이벤트 예시이다.
Here's an example event:
- Event key: "Alice"
- Event value: "Made a payment of $200 to Bob"
- Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
Producer
프로듀서는 카프카에 이벤트를 쓰는 클라이언트 어플리케이션을 의미한다.
Consumer
Consumer는 카프카로부터 이벤트를 읽어들이는 클라이언트어플리케이션을 의미한다.
카프카 구조에서 가장 중요한 부분은 producer 와 consumer간에는 서로 연결되지 않는다는 점이다. 이런 구조를 통해 producer는 consumer가 데이터를 제대로 읽었는지 확인할 필요가 없으며, 이를 바탕으로 High scalability 를 보장할 수 있다.
Topic
카프카에서 이벤트는 토픽 안에 저장된다. 단순히 말해서 하나의 토픽은 파일 시스템에서의 디렉토리(폴더)라고 볼 수 있으며, 이벤트는 폴더에 저장되는 파일이라고 볼 수 있겠다. 토픽은 서로 다른 카프카 브로커에 위치한 bucket의 개수만큼 분할되어 있으며, 이러한 데이터의 분산 배치는 카프카의 Scalability에 아주 중요한 역할을 하는데 그 이유는 클라이언트 어플리케이션이 여러 브로커로부터 데이터를 한번에 읽고 쓸 수 있도록 하기 때문이다. 새로운 이벤트가 카프카 토픽에 쓰여질 때, 이는 토픽의 파티션들 중 하나에 저장된다. 같은 이벤트 키를 가진 이벤트는 동일한 파티션에 저장되며, 카프카는 어느 consumer 가 데이터를 요청하더라도 데이터가 쓰여진 순서에 맞게 데이터를 읽을 수 있도록 보장한다.
위에 그림은 하나의 스토리지에 4개의 파트션으로 나눠 진 토픽을 보여주고 있다.
두 종류의 Producer가 데이터를 쓰고(publish)있으며, 새로운 Event는 토픽 파티션에 이벤트를 기록하고 있다.
같은 key를 가지고 있는 event는 같은 파티션에 저장되며, 경우에 따라서는 서로 다른 producer가 같은 partition에 데이터를 저장할 수도 있다.
데이터의 Falut-tolerant, High availability 를 보장하기 위해서 모든 topic은 복제가 될 수 있으며 복제(replication)은 데이터센터나 지역을 넘어서도 가능 하다. 이를 위해서 Broker 를 사용하는데, 브로크는 일반적으로 3개 수준으로 관리하며 3개의 브로커를 갖는다는 것은 데이터를 3개로 복제하여 관리하는 것을 의미한다.
카프카의 개념은 겉핥기 수준으로 알아보았으니
start from scratch 를 해보려고 합니다.
뭐라도 만들어보면서 이해하는게 가장 빠르기 때문이죠.
그럼 다음포스팅에서 뵙겠습니다.