[Infra] 데이터 인프라 - Ingestion&Transformation(Event Streaming)

🔊 해당 포스팅은 YouTube GeekNews 채널의 데이터 인프라 강의 내용에 기반해 제가 재구성하여 작성함을 알려드립니다.

 

이번 포스팅에서는 데이터 인프라 구조에서 주로 ETL 도구를 다루는 Ingestion & Transformation에 해당하는 또 다른 요소 중 하나인 Event Streaming에 대해 알아보려 한다.

 

ETL 도구 또 다른 요소인 Event Streaming을 알아보자.

 

우선 Event Streaming 이란 무엇일까? 위키백과에 따르면 정확히 Event Stream Processing이란, 이벤트 중심 정보시스템의 구축을 지원하도록 설계된 일련의 기술이라고 정의한다. 결국 실시간 스트리밍을 의미한다. 모든 데이터가 실시간 스트리밍이 필요한 것은 아니지만 금융기관이 주식의 시장 변화를 모니터링한다거나 운송차량, 농기계에 붙어있는 센서의 데이터를 실시간으로 처리해 고장 여부를 모니터링하는 것과 같이 특정 상황에 이렇게 실시간 스트리밍으로 처리되어야 하는 데이터들이 분명 존재한다. 따라서 이번 포스팅에서 소개할 Event Streaming들의 도구들은 실시간으로 데이터를 처리할 수 있는 기능들이 존재하는 도구들이다.

 

그렇다면 왜 스트리밍이 중요할까? 바로 데이터 가용성(Availability) 때문이다. 즉, 언제, 어떤 데이터를 또 누가 데이터에 접근할 수 있는지라는 문제에 대해 스트리밍은 '데이터를 추출하는 시점'부터 시간과 주체에 구애받지 않고 접근이 가능하다.

 

그런데 이전 포스팅에서 배운 Apache Spark에도 Spark Streaming 이라는 기능이 존재한다. 이것도 실시간 스트리밍 기능을 제공하는 것이 아닌가? 애석하게도 아니다. 스파크에서 제공하는 Spark Streaming 은 정확하게 Batch 기반 스트리밍이다. Batch 스트리밍이란, 일정 시간 범위 내의 데이터 포인트들만을 처리하는 것을 의미한다.(마치 머신러닝을 학습시킬 때 Mini-batch로 학습시키는 것처럼 말이다!) 따라서 이러한 한계점(?)으로 인해 데이터 하나 당 실시간으로 스트리밍하는 것이 불가능하다.

 

Apache Spark에도 스트리밍 기능이 제공은 된다! 하지만...

 

따라서 우리는 Spark가 하지 못하는 실시간 스트리밍 즉, Event Streaming을 할 수 있게 도와주는 도구들을 소개하려 한다. 하단의 자료는 데이터 웨어하우스 Batch 기반 스트리밍, 실시간 스트리밍을 비교하는 그래프이다.

 

출처: 긱뉴스 유투브 강의자료

---

Kafka의 컨셉은? Pub / Sub Messaging !

실시간 스트리밍에 매우 적합한 Apache Kafka

 

필자도 예전에 유투브의 Dev원영님께서 소개하시는 Kafka 영상을 한번 본적이 있다. 당시에는 "이게 대체 무슨 말이야..?" 싶었는데 이번에 약간의 공부를 해보고 Kafka가 어떤 기능을하고 어떤 장점이 있는지에 대해 조금은 알게 되었다. 최근에 실시간 스트리밍 기능이 필요한 많은 기업들에서 거의 표준으로 사용되고 있다고 한다. 결국 실시간으로 스트리밍이 되는 이벤트 기반 앱 개발을 가능하게 해주는 도구이자 프레임워크(또는 플랫폼)역할을 하게 된다.

 

참고로 Kafka는 Writing에 최적화된 시스템이라 불린다. 이러한 특징으로 불리게 된 계기에 대해서는 Kafka를 만든 사람이 Kafka로 이름을 지은 이유와 관련되어 있는데 관심이 있다면 강의를 들어보자! Kafka가 기술적으로 Writing 이라는 특징이 있다는 것에 대해서는 하단에서 알아본다.

 

Kafka는 Pub/Sub이라고 불리는 Publishing/Subscribing Messaging 컨셉을 갖고있다. 그러면 Kafka를 이해하기 위해서 Pub/Sub Messaging 개념을 이해해보자. 

 

출처: 긱뉴스 유투브 강의자료

 

우선 위와 같이 두 개의 프론트엔드 서버에서 사용자들의 지표(메트릭)을 수집한다고 가정해보자. 그런데 우리가 데이터 인프라 구조의 첫 번째 구성요소인 Sources를 알아볼 때 살펴보았던 것처럼 지표 데이터가 발생하는 Sources들은 위 그림처럼 2개만 있는 것이 아닌 정말 다양한 소스들로부터 지표 데이터들이 발생한다.

 

출처: 긱뉴스 유투브 강의자료

 

위 그림처럼 다양한 소스들로부터 지표 데이터가 발생하고 각 지표에 맞게 지표를 보여주는 UI 나 지표들을 분석하는 GA와 같은 서버 등으로 지표 데이터의 성격에 맞게 다른 곳으로 지표 데이터가 이동하게 된다. 그런데 위 그림에서 보는 것처럼 발생하는 지표 데이터마다 보낼 곳을 바로 1:1 매핑하게 되면 너무 많아지고 복잡해지는 문제가 발생한다.

 

출처: 긱뉴스 유투브 강의자료

 

방급 언급한 문제점을 극복하기 위해 Pub/Sub Messaging 컨셉이 도입된다. 위 그림을 예시로 살펴보자. 다양한 서버에서 지표 데이터들이 발생하고 지표 데이터들의 성격에 맞게 하나의 Pub/Sub 메시징 시스템을 만든다. 그리고  발생하는 지표 데이터들 즉, 메시징들을 Pub/Sub 시스템에 전달한다. 그리고 이 Pub/Sub 시스템을 구독(Subscribe) 하는 지표를 보여주는 UI, 지표를 분석하는 GA와 같은 서버들이 지표 데이터들(메시징)을 받아가게 된다.

 

결국 Pub/Sub 메시징 시스템의 'Pub'은 다양한 서버들로부터 메시징(지표 데이터)을 중앙 시스템으로 'Publishing' 하고 해당 중앙 시스템을 'Subscribing' 하는 여러 서버들(UI 서버, 분석 서버 등등)이 메시징(지표 데이터)을 받아가는 구조가 된다.

 

그런데, 카프카(Kafka)는 위와 같이 지표 데이터 성격에 맞게 Pub/Sub 시스템을 여러개 두는 것도 싫어(?)했다. 그래서 이 여러개의 Pub/Sub 시스템도 하나로 통합하기로 한다. 이것이 Kafka 기능의 출발점이다.

 

출처 : Kafka을 쉽게 다루도록 도와주는 Confluent

---

Kafka = 2가지 모델

Kafka는 2가지 모델을 합쳤다고 할 수 있다. 이 2가지 모델에 대해 알아보자.

1. Queuing

출처: 긱뉴스 유투브 강의자료

 

먼저 다양한 데이터를 발생시키는 Source들인 Producer들이 데이터를 발생시켜서 Queue 라는 데이터를 담을 수 있는 자료구조에 먼저 넣는다.(참고로 Queue는 먼저 들어간 데이터가 먼저 나가는 FIFO(First-In-First-Out) 구조를 따르는 자료구조를 의미한다) 그리고 큐에 넣은 데이터들을 Consumer(컨슈머)들이 단 '한 번씩'만 큐를 읽어서 처리한다.

2.Pub/Sub

출처: 긱뉴스 유투브 강의자료

 

여러가지 종류의 이벤트 데이터(지표 데이터와 동일)가 발생한다. 그런데 아까 위에서 본 것처럼 다양한 이벤트 데이터들 중에서 비슷한 성격의 데이터들이 분명 존재한다. 또한 하나의 이벤트 데이터를 두고 이를 Subscribe 하고자 하는 여러대의 서버들이 존재할 수 도 있다. 다시 말해 어떤 이벤트 데이터에 대하여 하나의 구독자(하나의 컨슈머)가 있을 수 있고 어떤 이벤트 데이터는 여러 컨슈머들로 구성되어 있는 여러 구독자가 있을 수 있다. 

 

이렇게 2가지 모델로 구성된 카프카는 정말 빠르게 데이터 처리가 가능하며 무한대로 확장이 가능하다. 또한 전달되는 이벤트 스트리밍을 내부적으로 분산처리하여 안전하게 저장하는 고가용성의 특징도 존재한다.

 

카프카는 주로 실시간, 웹, 로그 분석, 메시징, 트랜젝션 그리고 심지어 OLTP의 CDC를 스트리밍으로 받기도 한다. 그래서 앞서 이야기한 ETL 도구 뿐만 아니라 Sources 역할도 수행하는 역할까지도 가능하다.

---

Kafka의 내부 아키텍처

이번엔 Kafka의 내부적인 아키텍처를 살펴보자. 

 

Kafka의 내부 아키텍처

 

• Producer : 이벤트 데이터(지표 데이터)를 발생시키는 Sources
• Kafka broker : 일종의 서버를 의미
• Topic : Kafka broker라는 서버 내에 존재하는 테이블(데이터)
• push : Producer가 만들어내는 데이터를 Kafka broker 서버에 전송 즉, 메시징을 Publishing
• pull : Kafka broker 서버에 저장된 데이터들을 Consumer가 가져오는 즉, 메시징을 Subscribing 

 

위 그림에서 또 하나 주목할 부분은 Zookeeper Cluster이다. 그림을 잘 보면 컨슈머와 Kafka broker로부터 Zookeeper Cluster로 향하는 화살표들이 있다. Zookeeper Cluster는 우선 여러개의 Kafka broker라는 서버들 중 어떤 서버가 다운되어 있고 어떤 서버가 등록되어 동작하고 있는지 관리하는 역할을 한다. 또한 컨슈머들이 어떤 Topic을 가져갈지 등록을 하기 위한 역할도 한다.

 

그러나 최근에 Zookeeper Cluster가 Kafka broker들을 담는 Kafka Cluster들과 따로 존재하다보니 중복, 복잡도가 증가하는 문제가 발생해서 Zookeeper Cluster 의존성을 제거하기 위해 카프카 내부에서 Zookeeper Cluster를 위한 카프카를 또 형성하는 이른바 "Kafka On Kafka"로 개선하고 있다고 한다.

 

Zookeeper Cluster 의존성을 제거하기 위해 Kafka On Kafka

 

다음은 Producer들이 메시징(데이터)을 Kafka broker로 전송해 이 메시징들이 Partition(파티션)으로 저장이 된다. 이 때 파티션에 대해서 간단히 알아보자.

 

Kafka 파티션에서 데이터들이 저장된다.

 

(위 그림에서 TOPIC CLICK은 '클릭' 데이터가 담겨있는 테이블, TOPIC UPLOAD는 '업로드' 데이터가 담겨있는 테이블을 의미한다.)

파티션을 한 개로만 설정한다면 하나의 파티션에 계속적으로 스트리밍되는 데이터가 저장된다. 이러한 상황이 지속되면 속도가 매우 느려진다. 따라서 파티션을 여러개로 나누어서 각 파티션에 데이터(메세징)를 Write하게 되면서 데이터를 저장하기 때문에 속도 저하가 없어진다. 이 때 아까 문두에서 언급했던 Kafka의 "Writing 특성"이 바로 이것이다.

 

하지만 카프카의 단점이 여기에 있다. 바로 늘려버린 파티션을 줄일 수 없다는 것. 물론 파티션을 줄이기 위해 동일한 메시징(데이터)을 저장할 또 다른 Topic을 만들고 이 안의 데이터를 복사, 붙여넣기 하면 되긴 한다. 개인적인 생각이지만 이렇게 하게 되면 Topic 또한 늘어나는 문제가 발생하는 게 아닌가 싶기도 하다.

---

Kafka APIs 와 Kafka를 솔루션으로 제공해주는 도구들

다음은 Kafka가 제공하는 API들에 대해 간단하게 살펴보고 넘어가자

 

• Admin API : Topic, Kafka broker, 서버 등을 관리
• Producer API : 이벤트 데이터를 만들어내는 역할
• Consumer API : 컨슈머들이 이벤트 데이터를 읽어가도록 하는 역할
• Kafka Streams API : Producer가 만들어낸 이벤트 데이터를 가지고 스트림 프로세싱을 처리
• Kafka Connect API : 이벤트 스트리밍에다가 전송할 데이터를 갖고 있는 외부 DB나 다양한 어플리케이션과 연결해주는 역할. 즉, 이 API 개수를 증가시키면 ETL 도구의 장점이었던 소스를 늘리는 데 기여

위와 같이 이벤트 스트리밍의 뛰어난 기능을 제공하는 카프카에는 아쉬운 점이 또 하나 더 있다. 바로 설치, 실행, 다루는 게 매우 어렵다는 점이다.(고수 분들에겐 쉽겠..) 그래서 이를 고려하여 카프카를 쉽게 사용하도록 만든 몇 가지 플랫폼이자 도구들이 존재한다.

 

• Confluent : 카프카를 만든 분들이 창업한 회사이다. 직접 카프카를 창시하신 분들이라서 그런지 카프카를 쉽게 사용할 수 있도록 만들어준 솔루션 도구이다.
• Apache Pulsar : 야후에서 만든 도구로, 구성이 거의 Confluent와 비슷하다.
• AWS Kinesis : 아마존이 만든 스트리밍 플랫폼이다. 카프카가 갖고 있는 단점인 파티션을 줄일 수 없다는 점을 극복해 샤드(Kinesis에서는 카프카의 파티션을 '샤드'라고 부른다)를 늘이고 줄이는 것이 가능하다. 하지만 속도적인 측면에서 보았을 때 카프카가 Kinesis 보다 훨씬 성능이 빠르다고 한다.
• AWS MSK(Managed Streaming for Kafka): 아마존이 Kinesis를 만들었지만 성능 속도가 카프카에 비해 매우 느리다는 점을 해결하기 위해 돈만 지불하면 편하게 카프카를 관리하고 사용할 수 있도록 하는 도구이다.