[Kafka] 카프카란 무엇인가

실무 프로젝트에서 MSA 아키텍처를 활용하여 진행되고 있다.

비동기방식으로 Apache Kafka를 채택하여 개발을 하고 있는데 Kafka를 단순히 메시지를 주고 받고 DTO에 매핑하여 DB에 저장이 아닌 Kafka에 대해 좀 자세히 알고 싶어 카프카 책을 구입했고 이를 정리하고자 한다.

 

https://digital.kyobobook.co.kr/digital/ebook/ebookDetail.ink?selectedLargeCategory=001&barcode=4801196203727&orderClick=LEH&Kc= 

카프카, 데이터 플랫폼의 최강자

블로그의 정리한 내용은 그 책의 일부분을 정리한 것이며 자세한 사항은 책을 구입해서 읽어보기를 권장한다.

 

1-1 카프카 탄생 배경

카프카는 인맥 소셜 네트워크 서비스인 링크드인에서 처음 출발했다. 처음에는 고객 DB, 스플렁크로 시작하다가 서비스가 점차 커지면서 데이터가 더 다양해졌다.

 

이에 따라 문제가 발생하였는데

• 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송 영역이 없으니 복잡도가 증가한다.
• 데이터 파이프라인 관리의 어려움
  (개발자나 개발부서는 각각의 데이터 파이프라인을 만들고 유지했지만 시간이 지나면서 데이터 파이프라인들은 통합 데이터 분석을 위해 연결되어야 했다. 복잡성으로 인한 두 시스템 간의 데이터가 서로 달라져 신뢰도가 낮아지게 되었다.)

이 복잡도를 해결하기 위해 링크드인 내부 개발자가 새로운 팀을 구성하여 문제를 해결하고 다음과 같은 4가지의 목표를 가지고 시스템을 개발했는데 이것이 바로 카프카이다.

• 프로듀서와 컨슈머의 분리 (송신자와 수신자의 분리)
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화
• 데이터가 증가함에 따라 스케일 아웃이 가능한 시스템

카프카를 이용한 링크드인의 데이터 처리 시스템 https://www.confluient.io/blog/stream-data-platform-1

 

해당 그림을 보면 여러 앱/서비스에서 데이터 변경시에는 카프카로 데이터를 전달하고 실시간 스트림으로 처리해서 데이터 웨어하우스에 저장된 정보들을 변경한다.

그리고 그 변경 사항을 모니터링하고 관리하는 시스템과의 연계를 통해 문제를 해결 해 내었다.

 

 

 

1.2 카프카의 동작 방식과 원리

가프카는 기본적으로 메시징 서버로 동작한다.

메시징 서버, 시스템이라고 하는 것은 보내는 측(퍼블리셔, 프로듀서)과 가져가는 측(서비스크라이버, 컨슈머)이 원하는 토픽에서 데이터를 가져가게 되는 구조이다.

중앙에 메시징 시스템 서버를 두고 메시지를 보내고 받는 형태의 통신을 Pub/Sub 모델이라고 한다.

 

네트워크 통신 간단 설명

Pub/Sub 모델은 프로듀서가 메시지를 컨슈머에게 직접 전달하는 것이 아니라 중간의 메시징 시스템에 전달한다. 이 때 메시지 데이터와 수신처ID를 포함시키고 메시징 시스템의 교환기가 메시지 수신처 ID값을 확인한 다음 컨슈머들의 큐에 전달한다.

 

컨슈머들은 자신들의 큐를 모니터링 하고 있다가 큐에 메시지가 전달되면 이 값을 가져간다. 

(Spring Framwork에서는 컨슈머 메서드를 Bean 등록해서 모니터링한다.)

 

1. 프로듀서는 새로운 메시지를 카프라로 보낸다.
2. 프로듀서가 보낸 메시지는 카프카에 컨슈머 큐에 도착해 저장된다.
3. 컨슈머는 카프카 서버에 접속하여 새로운 메시지를 가져간다.

 

1.3 카프라의 특징

1.3.1) 프로듀서와 컨슈머의 분리

카프카는 메시징 전송 방식 중 메시지를 보 내는 역할과 받는 역할이 완벽하게 분리된 Pub/Sub 방식을 적용했다.

 

각갖의 역할이 분리되면서 어느 한쪽 시스템에서 문제가 발생하더라도 연쇄작용으로 문제가 발생할 확률은 낮으며 추가 웹서버가 생성되더라도 카프카로만 보내면 되기 때문에 부담을 줄일 수 있다.

 

1.3.2) 멀티 프로듀서, 멀티 컨슈머

 

하나의 메시지만을 발행하고 하나의 메시지만 구독할 수 있는 것이 아니라 하나의 프로듀서가 여러개의 토픽을 생성할 수 있고 하나의 컨슈머가 여러개의 토픽을 받을 수 있다.

그 이유는 카프카는 중앙 집중형 구조로 구성되어 있기 때문이다.

 

카프카 구조

 

1.3.3) 디스크에 메시지 저장

기존의 메시징 시스템은 컨뮤머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제하지만 카프카는 컨슈머가 메시지를 읽어 가더라도 정해져 있는 보관 주기 동안 디스크에 메시지를 저장해준다.

 

한쪽이 어떤이유에서 컨슈머 처리가 늦어지더라도 카프카의 디스크에 단전하게 보관 되기 때문에 메시지 손실 없이 메시지를 가져 갈 수 있다.

 

1.3.4) 확장성

하나의 카프카 클러스터는 3대의 브로커 (중간 메시지 관리 시스템)로 시작해 수십 대의 브로커로 확장가능하며 서비스의 중단 없이 온라인 상태에서의 작업이 가능하다.

 

1.3.5) 높은 성능

링크드인은 2015년 8월 기준 1조 개의 메시지를 생성하고 카프카를 이용해 하루에 1페타바이트 이상의 데이터를 처리했다.

 

1.4 카프카의 확장과 발전

2000년대 등장했던 서비스기반 아키텍처의 핵심 구성요소 중 하나인 엔터프라이즈 서비스 버스(ESB)를 쉽게 구현할 수 있다. 컨슈머와 프로듀서간 연결해주는 중간 데이터 전달 중계자의 개념이다.

 

ESB 예시 https://ko.wikipedia.org/wiki/%EC%97%94%ED%84%B0%ED%94%84%EB%9D%BC%EC%9D%B4%EC%A6%88_%EC%84%9C%EB%B9%84%EC%8A%A4_%EB%B2%84%EC%8A%A4

 

 

해당 구성 이미지는 카프라와 매우 유사하며 중간 데이터 버스 역할만 하는 것이 아닌 3rd Party와 추가 연동을 통해 빅데이터 분석 및 이벤트 연결을 할 수 있다. 즉 빅데이터 분석과 머신러닝 플랫폼을 만드는데 중요한 요소를 하고 있다.

 

---

더 나아가 카프카 홈페이지 따르면 카프카를 이렇게 정의하고 있다.

Apache Kafka® is an event streaming platform. (카프카는 이벤트 스트리밍 플랫폼이다.) 

 

카프카는 이벤트 스트리밍 플랫폼으로써 중요한 세가지의 기능을 가지고 있다고 소개한다.

1. To publish (write) and subscribe to (read) streams of events, including continuous import/export of your data from other systems.
2. To store streams of events durably and reliably for as long as you want.
3. To process streams of events as they occur or retrospectively.

 

1. 다른 시스템으로부터 너의 데이터를 지속적으로 주고/받고를 포함한 이벤트의 쓰기와 읽기를 하는 것

2. 사용자가 원하는 동안 지속적이고 안정적으로 이벤트 스트림을 저장하는 것

3. 이벤트가 발생하거나 소급 되었을 때 지속적으로 처리하는 것

 

또한 기존의 하드웨어 서버 뿐만 아니라 가상 머신, 컨테이너 그리고 클라우드에서 관리 및 활용되는 등 다양한 인프라 환경에서도 사용할 수 있다.

 

즉 서비스 경량화와 서비스별 분산을 위해 최근 실무에서 많이 사용되고 있는 MSA(MicroService Architecture)에도 잘 맞아 떨어진다고 생각하며 특히 넷플릭스 처럼 3rd Party와의 연동은 앞으로 카프카가 더 다양하게 활용할 수 있다고 생각한다.

 

https://www.confluent.io/blog/how-kafka-is-used-by-netflix/

 

(지금 실무에서 하고 있는 프로젝트 또한 Kafka를 사용하고 있다.)

 

 

1.5 정리

1장은 아파치 카프카에 대해 언급 및 간단한 소개를 진행하고 2장부터 카프카 설치를 진행해보고 실습하려고 한다.

 

끝.

 

---

Reference)

1. Kafka Page

https://kafka.apache.org/intro

Apache Kafka

 

2. confluent

https://www.confluent.io/

Confluent: Data in Motion