카프카(Apache Kafka)

카프카(Apache Kafka)란?

---

Apache Kafka는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션을 지원하는 강력한 도구로써, 오픈 소스 분산 이벤트 스트리밍 플랫폼(distributed event streaming platform)이다. 

 

* 스트리밍 분석(Streaming Analytics): 스트리밍 분석은 실시간으로 데이터 스트림을 분석하는 과정이다. 데이터 스트림은 연속적으로 생산되는 데이터로, 예를 들어 소셜 미디어 피드, 온라인 거래, 센서 데이터 등이 있다. 스트리밍 분석으로 기업이나 조직은 실시간으로 정보를 얻고, 즉각적인 의사결정을 내릴 수 있으며, 이상 징후를 감지하거나 기회를 식별할 수 있다.

 

* 미션 크리티컬 애플리케이션 (Mission Critical Application): 미션 크리티컬 애플리케이션은 조직의 운영에 있어서 중대한 중요도를 지닌 시스템이나 애플리케이션을 의미한다. 이러한 애플리케이션은 실패하거나 다운되면 비즈니스 운영에 심각한 영향을 미치게 된다. 예를 들어, 금융 서비스의 거래 시스템, 병원 의료 기록 시스템, 전자상거래 플랫폼 등이 있다.

 

* 분산 이벤트 스트리밍 (Distributed Event Streaming): 분산 이벤트 스트리밍은 대규모의 데이터를 실시간으로 처리하고, 여러 시스템이나 애플리케이션 간에 이벤트(데이터의 변화나 활동을 나타내는 메시지)를 전송하는 아키텍처이다. 이는 데이터를 생성하는 소스로부터 실시간으로 데이터를 수집, 저장, 처리, 분석하여 다른 시스템이나 애플리케이션으로 전달할 수 있다.

 

즉, Kafka는 여러 시스템이나 애플리케이션 간에서 데이터가 생성되는 소스로부터 실시간으로 데이터를 수집, 저장, 처리, 분석하고 이를 바탕으로 다른 시스템이나 애플리케이션에 이벤트(데이터의 변화나 활동을 나타내는 메시지)를 전달하는 분산 이벤트 스트리밍 플랫폼이다.

 

카프카의 탄생 배경

---

비즈니스 소셜 네트워크 서비스인 링크드인(linked-in)에서 개발했다.

 

이는 Kafka 개발 전 링크드인의 데이터 처리 시스템이다.

각 애플리케이션과 DB가 end-to-end로 연결되어 있고, 각각의 데이터 소스로부터 데이터를 수집, 처리, 저장하는 별도의 데이터 파이프라인을 구축해야 했다.(파이프라인의 파편화) 이로 인해 링크드인은 대규모 데이터를 처리하는 과정에서 다음과 같은 문제에 직면했다.

 

• 시스템 복잡성 증가
  1. 데이터 흐름의 통합 관리 부재로 인해 시스템 간 데이터 흐름 파악이 어려웠으며, 이로 인해 시스템 관리가 복잡해졌다.
  2. 장애 발생 시, 복구에 필요한 조치 시간이 증가했는데, 이는 연결된 애플리케이션을 일일히 확인해야 했기 때문이다.
  3. 하드웨어 교체나 소프트웨어 업그레이드 시, 관리 포인트와 작업 시간의 증가 문제가 있었다. 이는 업그레이드 과정에서 발생할 수 있는 사이드 이펙트를 확인해야 했기 때문이다.
• 데이터 파이프라인 관리의 어려움
  1. 각 애플리케이션과 데이터 시스템 간에는 별도의 데이터 파이프라인이 존재했으며, 각 데이터 파이프라인마다 데이터 포맷과 처리 방식이 달랐다.
  2. 새로운 파이프라인의 확장성과 유연성이 떨어지면서, 시스템 확장에 큰 어려움을 겪었다.
  3. 데이터 포맷과 처리 과정의 불일치로 인해 데이터의 신뢰성이 감소했다.

 

이러한 문제들을 해결하기 위해 새로운 시스템의 개발 필요성이 높아졌고, 다음과 같은 목표를 가지고 새로운 시스템을 개발했다.

모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하며, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 만들자!

 

 

이렇게 모든 이벤트/데이터의 흐름을 중앙에서 관리하는 Kafka를 개발하게 되었다.

 

이는 Kafka를 적용한 후 링크드인의 데이터 처리 시스템이다.

이 플랫폼은 데이터 흐름을 중앙에서 효율적으로 관리할 수 있는 기능을 제공함으로써, 링크드인의 여러 데이터 처리 및 관리 문제를 해결했다.

 

• 중앙집중식 데이터 흐름 관리: Kafka는 모든 이벤트와 데이터 흐름을 중앙에서 관리할 수 있게 함으로써, 시스템 관리와 복잡성을 대폭 줄여주었다. 이로 인해 시스템 간 데이터 흐름을 쉽게 파악하고, 관리할 수 있게 되었다.
• 확장성과 신뢰성 증가: 새로운 서비스나 시스템이 추가될 때, Kafka가 제공하는 표준 포맷으로 쉽게 연결할 수 있게 된다. 따라서 시스템의 확장성과 데이터 신뢰성이 크게 향상되었다.
• 비즈니스 로직에 집중 가능: 개발자들은 각 서비스 연결 구조에 대한 부담 없이, 비즈니스 로직 개발에 더 집중할 수 있게 되었다.

 

카프카 동작 방식

---

Kafka는 Pub-Sub 모델의 메세지 큐 형태로 동작한다.

 

Pub-Sub 모델

Pub-Sub 모델은 메시징 패턴의 한 형태로, 메시지를 발행하는 주체(Publisher)와 메시지를 수신하는 주체(Subscriber) 사이에서 메시지를 비동기적으로 교환하는 방식이다. 

 

• Publisher: 메시지를 생성하고 발행하는 주체. 메시지를 특정 구독자에게 직접 보내지 않고 대신, 메시지를 Topic이라는 분류에 따라 발행한다.
• Subscriber: 하나 이상의 토픽을 구독하고, 해당 토픽에 메시지가 발행될 때마다 그 메시지를 수신한다. 관심 있는 메시지 유형을 선택함으로써, 필요한 메시지만을 받을 수 있다.
• Message Broker 또는 Event Bus: Publisher로부터 메시지를 받아 해당 토픽을 구독하는 모든 Subscriber에게 메시지를 전달하는 중개자 역할을 한다. 메시지의 라우팅, 메시지 큐 관리, 메시지 배달 보장 등을 담당한다.

Pub-Sub 모델은 Apache Kafka, RabbitMQ, Google Colud Pub/Sub 등 다양한 기술이 이 모델을 구현하여 제공하고 있다.

 

메시지 큐 (Message Queue, MQ)

메시지 큐는 메시지 기반의 미들웨어로, 애플리케이션, 시스템, 서비스 간에 메시지를 비동기적으로 교환하기 위한 순차적인 저장소이다. 메시지 큐는 메시지를 보내는 측(Producer)과 받는 측(Consumer)사이에서 메시지를 일시적으로 보관하는 역할을 하며, 소비자가 준비되었을 때 메시지를 처리할 수 있도록 한다.

❓ Pub-Sub 모델과 메시지 큐 사용
Pub-Sub 모델에서 메시지 큐를 사용하지 않는 경우도 있다. 예를 들어, 실시간 채팅 어플리케이션 또는 실시간 데이터 스트리밍 서비스에서는 메시지를 즉시 소비자에게 전달하는 것이 중요할 수 있으며, 이 경우 메시지 큐를 사용하여 메시지를 일시적으로 저장하는 대신, 메시지가 발행되면 즉시 구독자에게 전달된다.

 

 

Kafka는 Pub-Sub 모델을 활용하지만, 전통적인 메시지 큐 시스템과는 몇 가지 차이점이 있다.

여기서 언급된 "전통적인 큐 시스템" 은 일반적으로 메시지 브로커(Message Broker)의 한 형태로 분류된다. 반면, Kafka는 이벤트 브로커(Event Broker) 또는 이벤트 스트리밍 플랫폼(Event Streaming Platform)으로 더 자주 언급된다. 이 두 용어는 각각 시스템이 데이터를 처리하고 관리하는 방식의 차이를 반영한다.

 

• 메시지 브로커(Message Broker): 메시지 브로커는 메시지를 전달하는 중간자 역할을 하며, 메시지 생산자(Producer)와 메시지 소비자(Consumer) 사이에서 메시지를 중개한다. 주로 Point-to-Point 또는 Publish-Subscribe 메시징 패턴을 지원한다. 메시지 브로커는 메시지 큐잉, 메시지 라우팅, 메시지 변환 등의 기능을 제공하여, 복잡한 시스템 간의 통합과 메시징 통신을 용이하게 한다. RabbitMQ, ActiveMQ 등이 메시지 브로커의 예이다.
• 이벤트 브로커(Event Broker): 이벤트 브로커는 이벤트 또는 메시지를 처리하는 데 더 넓은 범위의 기능을 제공하는 시스템이다. 이벤트 스트리밍, 이벤트 저장, 이벤트 처리와 분석 등을 지원한다. Kafka는 이러한 이벤트 브로커의 한 예로, 높은 처리량의 이벤트 스트리밍, 데이터의 내구성 보장, 실시간 데이터 처리 및 분석 기능을 제공한다.

 

메시지 브로커는 주로 애플리케이션 간의 메시지 전달과 시스템 통합에 초점을 맞추며, 이벤트 브로커는 데이터 스트리밍, 실시간 데이터 처리, 이벤트 주도 아키텍처(EDA) 등 좀 더 광범위한 데이터 처리 패턴을 지원한다. 메시지 브로커는 일반적으로 메시지가 소비되면 큐에서 제거하는 반면, 이벤트 브로커는 데이터를 장기간 저장하고, 이벤트 순서를 유지하며, 여러 소비자가 같은 데이터를 독립적으로 소비할 수 있도록 한다.

 

Kafka 동작 방식 및 구성 요소

Event: Kafka에서 producer와 consumer가 데이터를 주고 받는 단위로, 메세지이다.

Producer: Kafka에 이벤트를 게시(post, pop) 하는 클라이언트 애플리케이션

Consumer: Topic을 구독하고 이로부터 이벤트를 받아(pull) 처리하는 클라이언트 애플리케이션

Topic: 이벤트가 모이는 곳. producer은 topic에 이벤트를 게시하고 consumer은 topic을 구독해 이로부터 이벤트를 가져와 처리한다.

Partition: Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 topic을 partition이라고 한다.

Zookeeper: 분산 메시지의 큐의 정보를 관리한다.

 

1. Producer은 전달하고자 하는 이벤트를 Topic을 통해 카테고리화한다.
2. Consumer은 원하는 Topic을 구독(Subscribe) 함으로써 메시지를 읽어온다.
3. Producer과 Consumer은 오로지 Topic 정보만 알 뿐, 서로에 대해 알지 못한다.
4. Kafka는 Broker들이 하나의 클러스터로 구성되어 동작하도록 설계한다.
5. 클러스터 내, Broker에 대한 분산처리는 Zookeeper가 담당한다.

❓ 왜 하나의 Topic이 여러 개의 Broker에 분산되어 저장될까
이유는 확장성, 처리량 증가, 고가용성을 달성하기 위함이다. 이러한 설계는 Kafka가 대량의 데이터를 효율적으로 처리하고 관리할 수 있게 해주며, 대규모 분산 시스템에서 신뢰성과 성능을 보장한다.

- 확장성: 하나의 토픽을 여러 브로커와 파티션에 분산시키므로, 클라이언트 요청과 데이터 처리 부하를 여러 서버에 균등하게 분배할 수 있다. 이는 전체 시스템의 처리량을 증가시키고, 단일 지점에 대한 부하 집중을 방지한다. 
- 처리량 증가: 데이터를 파티션에 분산시키고 여러 브로커가 처리하도록 함으로써, Kafka 클러스터는 더 많은 메시지를 빠르게 처리할 수 있다. 이는 실시간 데이터 처리와 스트리밍 애플리케이션에서 특히 중요하다.
- 고가용성: 파티션은 클러스터 내의 여러 브로커에 복제될 수 있으며, 이는 데이터 손실 위험을 줄이고 시스템의 가용성을 높인다. 브로커가 실패하더라도, 복제된 파티션을 통해 데이터에 계속 액세스 할 수 있다. 이를 통해 데이터 손실 없이 시스템을 운영할 수 있다.

❓ Consumer Group의 존재 이유
하나의 토픽의 데이터를 여러 컨슈머가 분할하여 처리할 수 있고, Consumer Group 내의 각 컨슈머는 토픽의 파티션 중 일부를 할당받아 처리한다. 이를 통해 메시지 처리 부하를 컨슈머들 사이에 균등하게 분산시킬 수 있으며, 특정 컨슈머에 부하가 집중되는 것을 방지한다. 만약 Group 내에서 한 컨슈머가 실패하거나 오프라인 상태가 되면, Kafka는 해당 컨슈머가 처리하던 파티션을 그룹 내의 다른 컨슈머에게 자동으로 재할당한다. 이는 시스템의 내구성을 강화하고, 메시지 처리의 연속성을 보장한다.

❓ Zookeeper의 다중 인스턴스 이유
Zookeeper은 Kafka 클러스터 내의 Broker와 Consumer Group의 상태를 조율하는 데 사용된다. Zookeeper의 다중 인스턴스를 사용하는 이유는 다음과 같다.
만약 한 서버가 실패하더라도, 다른 서버가 그 역할을 대신해 클러스터의 운영을 지속할 수 있고, Zookeeper은 분산 시스템에서 합의 알고리즘을 통해 상태 정보를 신뢰성 있게 관리한다. 다중 인스턴스를 사용함으로써, 분산 환경에서의 동기화 및 상태 관리를 효과적으로 수행할 수 있다.

 

Kafka 2.8.0 버전부터는 Zookeeper 없이 Kafka를 운영할 수 있는 KRaft 모드가 도입되었다. 이는 Kafka 자체의 메타데이터 관리 기능을 통해 클러스터를 운영할 수 있게 하여, Zookeeper에 대한 의존성을 줄이는 방향으로 발전하고 있다. 물론 여전히 많은 환경에서는 Zookeeper와 함께 Kafka가 사용되고 있다.