DataRailroad

Apache Kafka란?

1. Kafka를 이해하기 위한 시작점

오늘날처럼 데이터가 폭발적으로 생성되는 시대에는, 실시간으로 데이터를 수집하고 처리할 수 있는 시스템이 필수입니다. 바로 이 역할을 수행하는 것이 Apache Kafka입니다.

Kafka는 분산형 스트리밍 플랫폼입니다. 간단히 말하면, 다양한 시스템이나 서비스들이 데이터를 주고받을 때 그 중간에서 데이터를 안전하게 전달하고 저장해주는 중개자 역할을 합니다. 특히 초당 수백만 건의 메시지를 처리할 수 있을 정도로 높은 처리량을 자랑합니다.

Kafka는 LinkedIn에서 내부 로그 처리 시스템으로 시작했으며, 이후 오픈소스로 공개되었고, 현재는 전 세계 수많은 기업에서 사용되고 있습니다.

2. Kafka는 왜 필요한가?

Kafka가 없던 시절을 생각해봅시다. 예를 들어, A라는 서비스에서 생성된 데이터를 B, C, D 시스템이 각각 받아야 한다고 가정해보죠. A가 B, C, D 각각에 데이터를 직접 전달하려면 다음과 같은 문제가 발생합니다.

• 연결이 복잡해짐: A는 세 시스템에 모두 연결해야 하며, 시스템이 늘어날수록 더 복잡해집니다.
• 오류에 취약함: 만약 C 시스템이 잠시 다운되면 A는 데이터를 어떻게 처리해야 할까요?
• 확장에 한계가 있음: 시스템이 많아질수록 성능이 떨어지고, 유지보수가 어려워집니다.

Kafka는 이런 문제들을 해결해줍니다. 데이터는 A에서 Kafka에 한 번만 보내면 되고, B, C, D는 Kafka에서 데이터를 받아가면 됩니다. 즉, 생산자(Producer)와 소비자(Consumer)를 완전히 분리할 수 있게 되는 것이죠.

3. Kafka의 기본 구성 요소

Kafka를 구성하는 핵심 개념은 아래와 같습니다.

1) Producer

데이터를 Kafka로 보내는 주체입니다. 예를 들어, 웹 서버에서 사용자 행동 로그를 Kafka로 전송하는 것이 이에 해당합니다.

2) Consumer

Kafka에서 데이터를 가져가는 주체입니다. 예를 들어, 분석 시스템이 Kafka에서 사용자 로그를 수신해 분석하는 식이죠.

3) Broker

Kafka 서버입니다. 데이터가 이곳에 저장되고, Producer와 Consumer는 이 Broker를 통해 데이터를 주고받습니다. Kafka는 일반적으로 여러 대의 Broker로 구성되어 있으며, 이들로 클러스터를 구성합니다.

4) Topic

Kafka에서 데이터는 Topic이라는 단위로 구분됩니다. Topic은 일종의 카테고리라고 생각하면 됩니다. 예를 들어, “user-login”이라는 Topic에는 로그인 로그만 모이게 할 수 있습니다.

5) Partition

Topic은 하나 이상의 Partition으로 나뉘어 저장됩니다. 각 Partition은 독립적으로 동작하며, 덕분에 Kafka는 병렬로 데이터를 처리할 수 있고, 성능이 매우 뛰어납니다.

4. Kafka는 어떻게 작동하나?

Kafka의 데이터 흐름을 간단히 정리해보면 아래와 같습니다.

1. Producer가 특정 Topic으로 데이터를 전송합니다.
2. Kafka는 이 데이터를 해당 Topic의 Partition에 저장합니다.
3. Consumer는 원하는 Topic을 구독(subscribe)하여 데이터를 가져갑니다.
4. Consumer는 자신이 어디까지 읽었는지를 Kafka에 알려주고, 그 이후부터 계속 데이터를 읽습니다.

중요한 점은, Kafka는 데이터를 일정 기간 동안 저장해준다는 점입니다. 일반적인 메시지 큐와는 달리, Kafka는 소비자가 데이터를 읽었는지 여부에 상관없이 데이터를 일정 기간 유지합니다(기본 7일). 이를 통해 같은 데이터를 여러 소비자가 서로 독립적으로 읽을 수 있게 됩니다.

5. Kafka의 강점과 활용 사례

Kafka는 다음과 같은 장점이 있습니다.

• 높은 처리량: 초당 수백만 건의 메시지를 처리할 수 있습니다.
• 확장성: Partition을 늘리면 성능을 선형적으로 확장할 수 있습니다.
• 내결함성: 복제(replication) 구조로 구성되어 장애에 강합니다.
• 유연한 통합: 다양한 시스템과 손쉽게 연동할 수 있는 커넥터(Connector) 생태계를 갖추고 있습니다.

실무에서 Kafka는 어디에 쓰일까?

• 로그 수집 시스템: 수천 대의 서버에서 쏟아지는 로그를 Kafka로 수집해 ELK(Elasticsearch, Logstash, Kibana)로 분석.
• 실시간 분석: 사용자 행동 데이터를 Kafka로 전송하고, 실시간 분석 플랫폼(예: Apache Flink)에서 분석.
• 모니터링 시스템: 마이크로서비스 아키텍처에서 서비스 간 상태 정보를 Kafka로 전송하여 모니터링 대시보드에 표시.
• 이벤트 기반 시스템: 주문, 결제, 배송 같은 비즈니스 이벤트를 Kafka를 통해 연결.

카프카 커넥트 역활

• 소스 시스템의 데이터를 카프카 커넥트를 통해 카프카로 전송합니다.
• 카프카에 저장된 데이터는 카프카 커넥트를 통해 싱크 시스템으로 전송합니다.
• 카프카 커넥트가 데이터 전송 처리하는 역할을 담당합니다.

카프카 커넥트 기본 용어

• 커넥터(connector): 외부 시스템과 카프카 커넥트 런타임 간의 인터페이스 역할, 태스크들을 관리하며, 소스 커넥터와 싱크 커넥터로 구분
• 태스크(task): 실제 카프카와 시스템 사이에서 데이터를 가져오거나 보내는 작업을 처리
• 워커(worker): 커넥터 및 태스크를 실행하는 프로세스
• 컨버터(converter): 커넥터와 데이터를 보내거나 받는 시스템 간의 데이터 포맷 간에 레코드를 시리얼라이즈 또는 디시리얼라이즈 처리
• 트랜스폼(transform): 레코드를 보내거나 받을 때 레코드를 간단한 로직으로 변환

카프카 커넥트 동작

• 다양한 종류의 커넥터가 존재합니다.
• 커넥터들은 Confluent Hub에서 확인 가능합니다.

카프카 커넥트 동작 예시

데이터베이스에서 지속적으로 생성되는 데이터를 HDFS로 전송해야 하는 상황입니다. 이 작업은 두 단계로 나누어 진행됩니다.

1. 데이터베이스 → Kafka
2. Kafka → HDFS

1 단계: 데이터베이스에서 Kafka로 데이터 전송

첫 번째 단계에서는 Kafka Connect의 JDBC 커넥터를 활용할 수 있습니다. JDBC 커넥터는 소스 데이터베이스에서 변경 데이터를 추출하여 Kafka로 전송하는 역할을 합니다.

아래 그림과 같이, 커넥터를 생성하기 위해 필요한 설정 값을 입력한 후 REST API를 호출하면, 커넥터가 즉시 생성됩니다.

JDBC 커넥터는 내부적으로 데이터를 수집하는 **태스크(Task)**를 실행하며, 이 태스크들은 커넥터가 관리합니다.
필요에 따라 tasks.max 옵션을 설정하여 실행할 태스크의 수를 조절할 수 있습니다.

2 단계: Kafka에서 HDFS로 데이터 전송

두 번째 단계에서는 Kafka Connect의 HDFS 커넥터를 사용합니다. HDFS 커넥터는 Kafka에 저장된 데이터를 HDFS로 전송하는 역할을 합니다.

JDBC 커넥터와 마찬가지로, HDFS 커넥터에 필요한 설정 값을 입력한 후 REST API를 호출하면 커넥터가 생성되며, Kafka 토픽의 데이터를 HDFS에 저장하기 시작합니다.

Kafka Zero Copy: 데이터 전송 효율을 극대화하다

최근 데이터 스트리밍 시장에서 Kafka의 인기가 높아짐에 따라, 그 내부 기술에 대한 관심도 커지고 있습니다. 오늘은 Kafka의 핵심 성능 최적화 기법 중 하나인 Zero Copy에 대해 이야기해보고자 합니다.

Zero Copy, 그게 뭐야?

우리가 보통 데이터를 전송할 때는 CPU가 여러 번 데이터를 복사하는 과정을 거치게 됩니다. 이 과정은 특히 대용량 데이터를 처리할 때 큰 부담이 될 수 있죠. Zero Copy는 이런 복사 과정을 최소화하여, 데이터를 직접 네트워크나 디스크로 전송하는 기술입니다. 이렇게 하면 CPU의 부담이 줄어들고, 전체적인 시스템 성능이 향상됩니다.

Kafka에서 Zero Copy가 어떻게 활용될까?

Kafka는 대용량의 메시지를 빠르게 처리해야 하는 특성이 있습니다. 그래서 Kafka는 디스크에 저장된 데이터를 클라이언트에게 전송할 때, 커널의 sendfile 시스템 콜을 이용해 데이터를 복사하지 않고 바로 전송합니다. 이러한 접근 방식 덕분에 Kafka는 CPU 사용을 크게 줄이고, 데이터 처리량을 극대화할 수 있었습니다.

Kafka Zero Copy (sendfile 사용) 방식

       +----------+
       |   Disk   |
       +----------+
            │
            │  sendfile (커널 내 직접 전송)
            ▼
   +---------------------+
   |  Kernel (sendfile)  |
   +---------------------+
            │
            ▼
       +-----------+
       |  Network  |
       +-----------+

이 방식에서는 데이터가 디스크에서 바로 커널 내부의 네트워크 스택으로 전송되므로, 사용자 공간으로의 불필요한 데이터 복사가 발생하지 않습니다.

Zero Copy 미사용 방식 (일반적인 데이터 전송 절차)

       +----------+
       |   Disk   |
       +----------+
            │
            │  데이터 읽기
            ▼
       +--------------+
       |  User Space  |  (버퍼에 복사)
       +--------------+
            │
            │  데이터 쓰기
            ▼
   +--------------+
   | Kernel Space |  (또 한 번 복사)
   +--------------+
            │
            ▼
       +-----------+
       |  Network  |
       +-----------+

이 경우, 데이터는 디스크에서 먼저 사용자 공간으로 복사되고, 다시 커널 공간으로 복사되어 네트워크로 전송되므로 불필요한 메모리 복사 오버헤드가 발생하게 됩니다.

왜 Zero Copy가 중요한가?

• 빠른 처리 속도: 데이터 복사 오버헤드를 줄여, 많은 양의 데이터를 신속하게 처리할 수 있습니다.
• 짧은 응답 시간: 데이터 전송 과정에서 불필요한 지연이 없어, 실시간 처리에 유리합니다.
• 효율적인 시스템 운영: CPU 리소스를 효율적으로 사용하여 다른 작업에도 충분한 자원을 할당할 수 있습니다.

Kafka vs RabbitMQ – 어떤 메시지 시스템이 내 서비스에 적합할까?

메시지 브로커와 이벤트 스트리밍 플랫폼은 분산 시스템의 핵심 요소로 자리 잡고 있습니다. RabbitMQ와 Kafka는 시장에서 많이 사용되는 두 가지 솔루션으로, 서로 다른 설계 철학과 강점을 가지고 있습니다. 이 글에서는 두 시스템의 주요 특징과 차이점을 비교해 보겠습니다.

1. 아키텍처와 기본 개념

RabbitMQ

• 메시지 큐 기반: RabbitMQ는 AMQP(Advanced Message Queuing Protocol)를 기반으로 동작하며, 생산자(producer)가 메시지를 보내면, 브로커가 이를 큐에 저장하고 소비자(consumer)가 메시지를 받아 처리하는 구조입니다.
• 라우팅과 토폴로지: 다양한 교환기(exchange)와 큐(queue)를 사용해 복잡한 라우팅 로직을 구성할 수 있습니다. 토픽, 라우팅 키, 헤더 등 다양한 라우팅 방식을 지원합니다.
• Push 모델: RabbitMQ는 기본적으로 생산자가 메시지를 큐에 넣으면, 브로커가 이를 소비자에게 푸시(push)하는 형태로 전달합니다.

Kafka

• 로그 기반의 분산 스트리밍 플랫폼: Kafka는 메시지를 지속적 로그에 기록하는 방식으로, 데이터를 토픽(topic)에 저장하고, 각 토픽은 여러 파티션(partition)으로 나뉩니다.
• Pull 모델: 소비자는 필요한 시점에 데이터를 요청(pull)하는 방식으로 메시지를 가져옵니다. 이로 인해 소비자 측에서 처리 속도에 맞게 데이터를 읽어들일 수 있습니다.
• 높은 처리량과 확장성: 분산 환경에서 수평 확장이 용이하며, 대규모 스트리밍 데이터를 처리하는 데 최적화되어 있습니다.

2. 성능 및 확장성

RabbitMQ

• 낮은 지연 시간: 일반적으로 작은 메시지 단위의 처리에서는 매우 빠른 응답 속도를 보입니다.
• 유연한 확장: 클러스터 구성이 가능하지만, 수평 확장 측면에서는 Kafka만큼 강력하지는 않습니다.
• 메시지 보증: 메시지의 신뢰성과 순서를 보장하기 위한 다양한 옵션(예, 메시지 영속성, ACK 처리 등)을 제공합니다.

Kafka

• 높은 처리량: 초당 수백만 건의 메시지 처리도 가능하며, 대용량 로그와 스트리밍 데이터 처리에 특화되어 있습니다.
• 수평 확장성: 클러스터를 구성해 브로커 수를 늘리면 처리량이 비례하여 증가합니다.
• 내결함성: 메시지가 디스크에 기록되고, 파티션별 복제(replicas) 설정을 통해 데이터 손실에 대비할 수 있습니다.

3. 데이터 일관성과 내구성

RabbitMQ

• 메시지 영속성: 디스크에 메시지를 저장함으로써 서버 장애 시에도 데이터를 복원할 수 있습니다. 단, 설정에 따라 성능과 내구성 간의 trade-off가 발생할 수 있습니다.
• ACK 기반 전송: 소비자가 메시지를 확실하게 처리했음을 ACK 신호로 알려야 하므로, 중복 처리나 메시지 손실을 최소화할 수 있습니다.

Kafka

• 로그 보존 정책: Kafka는 메시지를 오랜 기간 보관할 수 있으며, 소비자가 언제든지 특정 오프셋(offset)부터 데이터를 읽을 수 있습니다.
• 내구성과 복제: 각 파티션에 대해 다수의 복제본을 관리하여, 일부 노드에 장애가 발생해도 데이터 일관성을 유지할 수 있습니다.
• 최종 일관성: 소비자들이 데이터를 개별적으로 관리하기 때문에, 완벽한 실시간 순서를 보장하기보다는 최종적으로 일관된 상태를 유지하는 데 중점을 둡니다.

4. 사용 사례와 선택 기준

RabbitMQ가 적합한 경우

• 복잡한 라우팅 로직: 다양한 라우팅 규칙과 큐를 이용해 메시지를 분배해야 할 때.
• 즉각적인 알림 및 작업 분배: 작업 큐나 이벤트 알림 시스템에서 낮은 지연 시간을 필요로 할 때.
• 소규모에서 중규모 시스템: 규모가 크지 않은 환경에서 복잡한 메시지 전송 패턴을 구현할 때.

Kafka가 적합한 경우

• 대규모 데이터 스트리밍: 로그 수집, 실시간 데이터 처리, 분석 등에 있어 대량의 데이터를 빠르게 처리할 때.
• 내구성 및 확장성: 데이터의 내구성을 유지하면서, 시스템 확장을 통해 높은 처리량을 필요로 할 때.
• 분산 처리 및 이벤트 소싱: 마이크로서비스 아키텍처에서 이벤트 소싱, 스트림 처리 패턴을 구현할 때.

5. 결론

RabbitMQ와 Kafka는 각각의 장점이 뚜렷하며, 시스템의 요구 사항에 따라 선택해야 합니다.

• RabbitMQ는 복잡한 메시지 라우팅과 낮은 지연 시간의 처리가 필요할 때 유리하며, 전통적인 메시지 큐 패턴에 익숙한 환경에서 강점을 보입니다.
• Kafka는 높은 처리량, 확장성, 그리고 로그 기반 데이터 저장이 핵심인 환경에 적합하며, 실시간 분석과 스트리밍 데이터 처리에서 우수한 성능을 발휘합니다.

서비스의 규모, 메시지 처리 패턴, 데이터 내구성 요구 사항 등을 고려하여 두 시스템 중 적합한 솔루션을 선택하면, 보다 안정적이고 효율적인 메시징 인프라를 구축할 수 있습니다.

[Apache Kafka]kubernetes + helm 통해 Apache Kafka 설치 방법

*helm 이 설치되어 있습니다.

Strimzi Operator 설치

# 앞에 $ 부분은 뻈습니다.

# 1. namespace 생성
kubectl create namespace kafka

# 2. repo 생성
helm repo add strimzi https://strimzi.io/charts/
helm show values strimzi/strimzi-kafka-operator

# operator 설치
helm install kafka-operator strimzi/strimzi-kafka-operator --version 0.38.0 --namespace kafka

# 배포된 리소스 확인
kubectl get deploy,pod -n kafka

# operator가 지원하는 kafka 버젼 확인
kubectl describe deploy -n kafka | grep KAFKA_IMAGES: -A3

Kafka cluster 설치

*kafka 설치 전에 Strimzi 버젼 별로 설치 가능한 kafka를 확인해야 합니다. 아래 주소를 통해 확인합니다.

https://strimzi.io/downloads/

# Kafka cluster YAML 파일 다운로드
curl -s -O https://raw.githubusercontent.com/gasida/DOIK/main/strimzi/kafka-1.yaml

# kafka 배포
kubectl apply -f kafka-1.yaml -n kafka

# 배포된 리소스 확인
kubectl get all -n kafka

kafka-lag-exporter

kafka-lag-exporter 설치 및 실행

*여러 방법으로 실행하는 방법이 있는데 Java 방식으로 설치 및 실행했습니다. 다른 방식은 처음 사람이 하기에는 어려울 수 있습니다.

1. https://github.com/seglo/kafka-lag-exporter/releases 페이지에서 zip 형태를 다운로드 받습니다. Source code는 example 파일 사용을 위해 다운로드 받습니다.
2. java를 설치하거나, java version이 8이면 최신 버젼으로 업데이트 해줍니다.
   1. 8 버젼이면 아래와 같은 에러가 발생합니다.
   2. ‘java.lang.UnsupportedClassVersionError: ch/qos/logback/classic/spi/LogbackServiceProvider has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0’
3. Source code에 example 폴더에 application.conf 파일을 kafka-lag-exporter 폴더로 이동해줍니다.
4. pplication.conf 파일 내용을 수정해줍니다.
5. 아래 명령어를 실행해줍니다.

$ ./bin/kafka-lag-exporter -Dconfig.file=/Users/jsh/kafka/kafka-lag-exporter/application.conf

이제 Kafka는 안녕~

요약

WarpStream이라는 S3 위에 구축된 Kafka 프로토콜 호환 데이터 스트리밍 플랫폼이 나와 이제 Kafka는 사라질꺼라는 WarpStream 뉴스입니다. 

뉴스 요약 내용은 아래와 같습니다.

WarpStream는 S3 바로 위에 구축된 Kafka 프로토콜 호환 데이터 스트리밍 플랫폼입니다. 하나의 상태 없는 Go 이진 파일로 제공되므로 관리해야 할 로컬 디스크나 리밸런싱할 브로커, 운영해야 할 ZooKeeper가 없습니다. WarpStream은 데이터가 직접 S3로 스트리밍되므로 클라우드에서 Kafka보다 5-10배 저렴합니다. 이는 규모 있는 Kafka 배포의 인프라 비용의 80% 이상이 될 수 있는 지역 간 네트워킹을 사용하지 않기 때문입니다."

[출처]

https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka