Apache Kafka (아파치 카프카)

카프카(Kafka)는 분산형 메시지 시스템으로, 소스 애플리케이션과 타겟 애플리케이션 간의 데이터 교환을 효과적으로 관리하는 중간 메시지 브로커 역할을 수행합니다. 카프카를 통해 두 애플리케이션이 직접 통신하지 않고도 안전하게 데이터를 전달하고 처리할 수 있습니다.

소스 애플리케이션과 타겟 애플리케이션에서 카프카의 역할

소스 애플리케이션(Kafka Producer)과 카프카:
- 소스 애플리케이션은 데이터를 직접 타겟으로 보내지 않고, **카프카에 메시지를 게시(Publish)**합니다.
- 카프카는 이 데이터를 **토픽(Topic)**이라는 논리적인 저장 공간에 저장합니다.
- 이로써 소스 애플리케이션은 데이터 전송에만 집중할 수 있고, 타겟 애플리케이션의 상태와 상관없이 데이터를 안전하게 보관할 수 있습니다.
타겟 애플리케이션(Kafka Consumer)과 카프카:
- 타겟 애플리케이션은 **카프카의 토픽에서 데이터를 구독(Subscribe)**하여 필요한 데이터를 수신합니다.
- 카프카에 저장된 메시지를 컨슈머(Consumer) 역할을 통해 읽어와 데이터 처리를 수행합니다.
- 타겟 애플리케이션이 데이터를 수신하기 위해 소스 애플리케이션을 직접 호출할 필요가 없어, 애플리케이션 간의 의존성을 줄여줍니다.

카프카를 이용한 소스와 타겟 애플리케이션의 예시 흐름

데이터 게시 (Source Application → Kafka):
- 소스 애플리케이션이 데이터를 생성하고 카프카의 특정 토픽에 게시합니다.
- 예를 들어, orders라는 토픽에 주문 데이터를 게시하여 여러 애플리케이션이 이 데이터를 사용할 수 있도록 합니다.
데이터 수신 및 처리 (Kafka → Target Application):
- 타겟 애플리케이션은 orders 토픽을 구독하여 새로운 주문 데이터를 실시간으로 수신하고 처리합니다.
- 카프카는 여러 타겟 애플리케이션이 동일한 토픽을 구독할 수 있도록 지원하여, 데이터의 복수 소비가 가능합니다.

토픽(Topic)과 AMQP(Advanced Message Queuing Protocol)은 메시지 전송에 있어 중요한 개념으로, 서로 다른 통신 방식을 제공하는 요소입니다.

토픽(Topic)

토픽은 메시지 브로커에서 특정 종류의 데이터를 구분하기 위한 논리적인 채널입니다. 여러 애플리케이션이 하나의 토픽을 구독(Subscribe)하고, 소스 애플리케이션이 특정 토픽에 데이터를 게시(Publish)할 수 있습니다.

예시: 뉴스 애플리케이션에서 "sports"라는 토픽을 생성하고, 스포츠 뉴스가 있을 때 이 토픽에 데이터를 게시합니다. 스포츠 뉴스에 관심 있는 애플리케이션이나 사용자는 "sports" 토픽을 구독하여 스포츠 관련 정보를 실시간으로 받을 수 있습니다.
**카프카(Kafka)**에서 주로 사용하는 방식으로, 퍼블리시-서브스크라이브(Publish-Subscribe) 모델의 핵심입니다. 여러 소비자(Consumer)가 한 토픽을 구독하여 동일한 메시지를 받을 수 있습니다.

카프카(Kafka)의 토픽(Topic)은 메시지를 카테고리별로 구분하는 논리적 단위입니다. 카프카에서 데이터를 주고받기 위한 기본 단위로, 각 토픽에 저장된 메시지는 특정 목적이나 관심사를 기준으로 분류됩니다. 예를 들어, 주문 정보, 트랜잭션 데이터, 로그 데이터 등의 데이터를 각각의 토픽에 나누어 처리할 수 있습니다.

카프카 토픽의 주요 개념

퍼블리시/서브스크라이브 모델
- 토픽은 메시지의 발행(Publish)과 구독(Subscribe)이 이루어지는 장소입니다.
- 프로듀서(Producer)는 데이터를 특정 토픽에 발행하고, 컨슈머(Consumer)는 이를 구독하여 데이터를 수신합니다.
- 이 방식으로 데이터 생산자와 소비자가 서로 독립적으로 운영될 수 있습니다.
파티션(Partition)
- 토픽은 여러 개의 파티션으로 나뉘어 데이터를 저장합니다. 각 파티션은 메시지를 순차적으로 기록하며, 특정 시점의 데이터 오프셋(offset)을 기준으로 관리됩니다.
- 파티션 덕분에 카프카는 대량의 데이터를 병렬로 처리할 수 있으며, 이를 통해 처리 성능과 확장성을 높입니다.
- 예를 들어, order라는 토픽이 3개의 파티션으로 나뉘어 있으면, 주문 데이터가 세 개의 파티션에 분산되어 저장됩니다.
- 카프카에서 파티션은 추가할 수 있지만, 줄이거나 삭제할 수는 없습니다.
- 새로운 파티션을 추가하면 새로 들어오는 데이터만 새로운 파티션에 분산됩니다.
오프셋(Offset)
- 파티션 내의 각 메시지에는 고유한 오프셋이 부여됩니다. 오프셋은 메시지가 파티션에 기록된 순서를 나타내며, 이를 통해 컨슈머는 자신이 마지막으로 처리한 위치를 기록하고 추적할 수 있습니다.
- 예를 들어, 컨슈머가 order 토픽의 3번 파티션에서 오프셋 100까지 처리했다면, 이후에는 101번 오프셋부터 처리를 이어갈 수 있습니다.
내구성 및 데이터 보존
- 카프카는 기본적으로 데이터를 디스크에 저장하며, 데이터 보존 기간을 설정할 수 있습니다.
- 설정된 보존 기간 동안 토픽의 데이터는 삭제되지 않고 유지되므로, 컨슈머는 필요한 시점에 동일한 메시지를 다시 처리할 수 있습니다.

카프카 토픽의 활용 예

카프카 토픽은 대규모 이벤트 스트리밍과 실시간 데이터 처리에 주로 사용됩니다. 예를 들어, 전자상거래 시스템에서는 다음과 같은 방식으로 토픽을 운영할 수 있습니다.

user_activity 토픽: 사용자의 웹사이트 방문, 클릭 이벤트 등을 수집합니다.
order 토픽: 주문 정보를 저장하며, 결제 시스템, 재고 관리 시스템과 같은 여러 애플리케이션이 구독하여 데이터를 처리합니다.
payment 토픽: 결제 상태를 기록하며, 재무 관리 시스템이나 알림 서비스에서 구독하여 결제 관련 정보를 확인합니다.

AMQP (Advanced Message Queuing Protocol)

AMQP는 표준 메시징 프로토콜로, 주로 RabbitMQ와 같은 메시지 브로커에서 사용됩니다. AMQP는 다음과 같은 방식으로 메시지를 전달합니다.

프로듀서가 특정 **익스체인지(Exchange)**에 메시지를 전송합니다.
익스체인지는 메시지를 **큐(Queue)**에 라우팅합니다. 이때 큐는 라우팅 키(Routing Key) 등을 사용하여 목적지 큐를 결정합니다.
컨슈머는 큐를 통해 메시지를 수신합니다.

AMQP는 큐에 메시지를 쌓고 처리하는 방식으로 P2P(포인트 투 포인트) 구조와 퍼블리시-서브스크라이브구조를 모두 지원합니다.

주요 개념:
- Exchange: 메시지를 특정 큐로 라우팅하는 중간 역할. direct, topic, fanout, headers와 같은 다양한 종류의 익스체인지가 있습니다.
- Queue: 메시지가 쌓이는 공간이며, 여러 컨슈머가 메시지를 가져가면서 처리합니다.

카프카와 AMQP의 차이

메시지 보존 방식: 카프카는 메시지를 디스크에 보존하여, 컨슈머가 동일한 메시지를 여러 번 처리할 수 있게 합니다. 반면, AMQP에서는 메시지를 처리 후 큐에서 삭제하는 방식이 일반적입니다.
사용 목적:
- 카프카는 로그 수집, 이벤트 스트리밍과 같은 실시간 데이터 파이프라인에 적합합니다.
- AMQP는 작업 대기열이나 비동기 메시지 처리와 같은 단일 큐 기반의 메시지 처리에 적합합니다.

이처럼 카프카의 토픽과 AMQP는 각자의 목적에 따라 적합한 방식을 선택하여 메시지를 전송하고 처리하는 데 사용됩니다.

카프카 프로듀서의 주요 기능과 특징

메시지 전송
- 프로듀서는 데이터를 JSON, 문자열 등 다양한 포맷으로 메시지로 변환하여 전송합니다. 각 메시지는 토픽과 파티션을 지정해 보낼 수 있습니다.
파티션 선택
- 프로듀서는 메시지를 보낼 때 파티션을 선택할 수 있습니다. 기본적으로 라운드 로빈 방식으로 파티션에 분배하거나, 특정 키를 기준으로 해시(hash) 기반 파티션 배정을 수행하여 메시지가 특정 파티션에 들어가도록 설정할 수도 있습니다. 이를 통해 데이터의 순서와 일관성을 유지할 수 있습니다.
복제와 내구성
- 카프카는 데이터의 내구성을 보장하기 위해 복제(replication) 기능을 제공합니다. 프로듀서는 전송할 데이터가 일정한 복제 정책에 따라 저장되도록 설정할 수 있습니다.
- 데이터 전송 성공 여부는 acks 설정으로 제어할 수 있으며, 이 설정에 따라 데이터의 내구성과 성능 간의 균형을 조절할 수 있습니다.
  - acks=0: 전송 성공 여부를 확인하지 않음.
  - acks=1: 리더 파티션에 도달하면 성공으로 간주.
  - acks=all: 모든 복제본에 저장될 때까지 대기, 가장 높은 내구성 보장.
데이터 압축
- 프로듀서는 전송 효율성을 위해 데이터 압축 방식을 설정할 수 있습니다. gzip, snappy, lz4, zstd등 다양한 압축 알고리즘을 지원하여 네트워크 대역폭 사용을 줄이고 전송 속도를 높일 수 있습니다.
비동기 전송
- 카프카 프로듀서는 일반적으로 비동기 방식으로 메시지를 전송합니다. 이를 통해 메시지를 보내는 속도가 빨라지고 지연 시간이 줄어듭니다. 프로듀서는 전송할 메시지를 모아 배치로 전송할 수 있어, 전송 성능을 더욱 높일 수 있습니다.

카프카 프로듀서의 기본 동작 예시

프로듀서는 데이터를 생성하고 이를 특정 토픽으로 전송합니다.
카프카 브로커는 프로듀서로부터 데이터를 받아 해당 토픽의 파티션에 저장합니다.
**소비자(Consumer)**는 이 데이터를 읽어 필요한 처리를 수행합니다.

예시 코드 (Java Kafka Producer)

다음은 Java에서 카프카 프로듀서를 사용하여 메시지를 전송하는 간단한 예시입니다:

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;

public class SimpleKafkaProducer {
    public static void main(String[] args) {
        // Kafka 프로듀서 설정
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092"); // 카프카 브로커 주소
        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

        // 프로듀서 생성
        KafkaProducer<String, String> producer = new KafkaProducer<>(props);

        // 메시지 전송
        String topicName = "example-topic";
        for (int i = 0; i < 10; i++) {
            String message = "Message " + i;
            producer.send(new ProducerRecord<>(topicName, Integer.toString(i), message));
        }

        // 프로듀서 종료
        producer.close();
    }
}

이 예제에서는 카프카의 localhost:9092 브로커에 연결해 "example-topic" 토픽으로 메시지를 전송합니다.

key가 null인 경우

라운드 로빈 방식으로 파티션에 데이터가 분배됩니다. 프로듀서는 특정 파티션에 고정하지 않고, 균등하게 각 파티션에 메시지를 순차적으로 저장하게 됩니다. 이 경우, 메시지가 어느 파티션에 저장될지는 매 전송마다 변경될 수 있습니다.

key 개수가 파티션 개수와 동일한 경우

각 고유한 key 값이 특정 파티션에만 고정되어 저장됩니다.
카프카는 key의 해시값을 사용하여 파티션을 결정하기 때문에, 같은 key는 항상 동일한 파티션으로 매핑됩니다. 이 방식으로 key 개수가 파티션 개수와 같다면, 각 파티션이 하나의 key와 매칭되어 각 파티션이 특정 key의 메시지들만 받게 됩니다.

Kafka의 데이터 안전성과 가용성을 유지하기 위해, Kafka 브로커, Replication, ISR은 중요한 개념입니다. 각 용어가 어떤 역할을 하는지 설명하겠습니다.

1. Kafka Broker

Kafka 브로커는 Kafka 클러스터 내에서 데이터의 전송, 저장, 관리를 담당하는 노드입니다. Kafka 클러스터에는 여러 브로커가 존재할 수 있으며, 이 브로커들은 협력하여 대규모 데이터의 스트리밍과 내결함성을 유지합니다.

브로커의 주요 역할
- 프로듀서가 보낸 메시지를 특정 토픽의 파티션에 저장합니다.
- 파티션 리더로서, 각 파티션의 읽기 및 쓰기 요청을 처리합니다.
- 클러스터 내 다른 브로커들과 상태를 공유하고, ZooKeeper 또는 Kafka의 KRaft 모드를 통해 클러스터의 리더 선출을 관리합니다.
- 오프셋 관리와 삭제 정책을 통해 데이터의 보관 및 삭제를 자동으로 관리합니다.

2. Replication (복제)

Kafka는 데이터 안전성을 위해 토픽의 파티션 데이터를 여러 브로커에 복제합니다. 이때, 각 파티션에는 리더와 팔로워가 있으며, 복제본의 수는 클러스터 설정에 따라 결정됩니다.

리더(Leader): 특정 파티션의 주요 읽기/쓰기 작업을 처리합니다. 프로듀서와 컨슈머는 기본적으로 리더와 상호작용하며, 팔로워는 리더로부터 데이터를 동기화합니다.
팔로워(Follower): 리더의 데이터를 복제하는 역할을 합니다. 리더에 장애가 발생할 경우, 팔로워 중 하나가 자동으로 새로운 리더로 선출되어 데이터 연속성을 유지할 수 있습니다.
복제 인수(Replication Factor): 각 파티션에 대해 유지할 복제본의 수를 의미합니다. 예를 들어, 복제 인수가 3이면 해당 파티션의 데이터가 3개의 브로커에 복제되어 저장됩니다.

복제를 통해 Kafka는 고가용성과 데이터 내구성을 보장합니다. 한 브로커에 문제가 생겨도 다른 브로커가 데이터를 유지하고 있으므로 서비스 중단을 방지할 수 있습니다.

Replication Factor = 0

설명: 레플리케이션이 없는 경우입니다.
특징: 파티션의 데이터가 단일 브로커에만 저장되기 때문에, 만약 브로커가 다운되면 데이터가 손실될 수 있습니다. 이는 내구성 측면에서 매우 위험하며, Kafka에서는 실제로 허용되지 않습니다.
적용 상황: Kafka에서는 레플리케이션 팩터가 최소 1 이상이어야 하므로, 일반적으로 사용되지 않습니다.

Replication Factor = 1

설명: 각 파티션의 데이터가 단일 브로커에만 저장되는 상황을 의미합니다.
특징: 브로커 하나만 파티션의 데이터를 저장하므로 해당 브로커가 장애가 발생하면 데이터 접근이 불가능해지고, 데이터 유실 가능성이 존재합니다.
적용 상황: 높은 내구성이 필요하지 않거나, 테스트 환경처럼 일부 데이터 손실이 허용 가능한 경우에 사용할 수 있습니다. 일반적인 프로덕션 환경에서는 권장되지 않습니다.

Replication Factor = 2 이상 (예: 2, 3)

설명: 각 파티션이 여러 브로커에 복제됩니다.
특징: 레플리케이션 팩터가 2 이상이면 한 개 이상의 복제본이 다른 브로커에 저장되므로, 한 브로커가 다운되어도 다른 브로커의 복제본을 통해 데이터에 접근할 수 있습니다. 예를 들어, 레플리케이션 팩터가 2인 경우 하나의 복제본이 추가로 저장되며, 레플리케이션 팩터가 3인 경우 두 개의 복제본이 다른 브로커에 저장됩니다.
적용 상황: 높은 내구성과 가용성이 요구되는 프로덕션 환경에서 주로 사용되며, 권장되는 설정입니다.

3. ISR (In-Sync Replicas)

ISR(In-Sync Replicas)은 현재 리더와 완벽하게 동기화된 팔로워의 집합을 의미합니다. 리더와 동기화 상태를 유지하는 복제본들로 구성되어 있으며, Kafka는 ISR 목록에 있는 복제본이 리더를 대신할 수 있는 상태임을 확인합니다.

ISR의 구성: 리더와 팔로워는 지속적으로 동기화를 수행하여 ISR에 포함됩니다. 이때, 지정된 시간 내에 리더와 동기화하지 못하는 팔로워는 ISR에서 제외됩니다.
ISR의 역할: 리더에 장애가 발생했을 때, ISR에 있는 팔로워 중 하나가 새로운 리더로 선출됩니다. 이를 통해 Kafka는 내결함성을 유지할 수 있습니다.
동기화 기준: ISR에 포함되려면, 특정 시간 내에 리더의 데이터와 일치해야 하며, 이 기준은 min.insync.replicas 설정에 따라 조정할 수 있습니다.

ISR은 데이터의 일관성과 가용성을 높이기 위한 중요한 메커니즘으로, ISR이 없는 복제본은 리더로서 신뢰할 수 없기 때문에 리더 선출에서 제외됩니다.

Kafka에서 ack (Acknowledgment) 설정은 프로듀서가 메시지를 브로커로 전송할 때, 전송 성공 여부를 확인하는 방식에 영향을 줍니다. 이 설정은 메시지 전송의 내구성과 지연 시간에 중요한 역할을 하며, 주로 acks 파라미터로 설정됩니다. 주요 값으로는 0, 1, all이 있습니다.

1. acks = 0

설명: 프로듀서가 메시지를 브로커로 전송한 후 브로커의 응답을 기다리지 않음을 의미합니다.
특징: 이 설정에서는 브로커의 응답을 기다리지 않기 때문에 전송 속도는 가장 빠르지만 데이터의 신뢰성은 낮습니다. 만약 전송 중 장애가 발생해도 프로듀서는 이를 알 수 없으므로 데이터가 유실될 가능성이 있습니다.
적용 상황: 빠른 전송이 필요하고 약간의 데이터 손실이 허용되는 경우 (예: 로그 데이터, 임시 데이터 등).

2. acks = 1

설명: 프로듀서는 메시지를 리더 브로커에 전송하고, 리더로부터 수신 확인(ack)를 받으면 전송 성공으로 간주합니다.
특징: 메시지가 리더 브로커에 기록되면 바로 응답을 받기 때문에 성능과 내구성 간 균형을 잡은 설정입니다. 그러나 리더가 기록하고 팔로워에 복제되기 전(파티션의 Replication 만들기전 오류발생)에 장애가 발생하면 데이터가 유실될 가능성이 있습니다.
적용 상황: 데이터 전송 속도가 중요하면서도 일부 데이터 손실이 허용되는 경우. 예를 들어, 웹 로그와 같은 이벤트 스트리밍.

3. acks = all (또는 -1)

설명: 메시지가 리더와 모든 ISR(In-Sync Replicas) 팔로워에 기록될 때까지 프로듀서가 응답을 기다립니다.
특징: 최고 수준의 내구성을 제공하며, ISR의 모든 브로커에 메시지가 기록된 후 응답을 받기 때문에 데이터 손실 위험이 가장 낮습니다. 다만, 모든 복제본이 기록될 때까지 대기하므로 지연 시간이 길어질 수 있습니다.
적용 상황: 데이터 내구성이 매우 중요한 금융 데이터, 주문 정보, 사용자 트랜잭션 등.

고가용성(High Availability, HA)는 시스템이나 애플리케이션이 장애가 발생하더라도 지속적으로 운영될 수 있도록 설계된 상태를 의미합니다. 즉, 고가용성은 서비스 중단 없이 계속해서 안정적으로 동작할 수 있는 능력을 뜻하며, 대규모 분산 시스템에서는 매우 중요한 목표 중 하나입니다.

Kafka에서 고가용성을 달성하는 주요 방법은 데이터 레플리케이션과 클러스터 구성입니다.

Kafka에서의 고가용성 요소

데이터 레플리케이션(Replication)
- Kafka에서는 레플리케이션 팩터를 설정하여 데이터의 복제본을 여러 브로커에 저장합니다.
- 각 파티션의 리더가 다운되면 팔로워 복제본 중 하나가 자동으로 새로운 리더로 승격되어 데이터 접근을 지속할 수 있습니다.
- 최소한 2 이상의 레플리케이션 팩터를 설정하면 한 브로커가 고장나도 다른 복제본이 남아 있어 데이터 유실 없이 연속적인 서비스가 가능합니다.
ISR(In-Sync Replicas)
- Kafka는 고가용성을 위해 ISR(In-Sync Replicas) 목록을 유지합니다. 이 목록에는 리더와 동일한 데이터를 보유하고 있는 팔로워가 포함됩니다.
- 레플리케이션 팩터가 2 이상일 때, ISR 목록의 복제본이 충분히 많으면 장애가 발생해도 지속적으로 데이터를 읽고 쓸 수 있어 고가용성을 유지할 수 있습니다.
다중 브로커 클러스터 구성
- 여러 개의 브로커로 구성된 클러스터는 브로커 하나에 문제가 생겨도 다른 브로커들이 서비스 요청을 처리할 수 있어 시스템의 가용성이 향상됩니다.
- 클러스터에 있는 모든 브로커는 데이터의 특정 파티션을 리더 또는 팔로워로 유지하므로 장애 시 다른 브로커가 이를 이어받아 서비스 연속성을 보장할 수 있습니다.
토픽과 파티션 분산
- Kafka는 토픽을 파티션으로 분할해 저장하므로 동시에 여러 브로커가 데이터를 처리하게 되어, 고가용성과 더불어 확장성도 확보할 수 있습니다.
- 파티션을 여러 브로커에 분산하면 특정 브로커 장애가 전체 서비스에 미치는 영향을 줄일 수 있습니다.
Ack 설정
- 프로듀서가 데이터를 전송할 때 acknowledgment (ack) 옵션을 통해 안정성 수준을 설정할 수 있습니다. 예를 들어, acks=all을 사용하면 리더뿐만 아니라 ISR 목록의 모든 팔로워에 데이터가 쓰여야 응답이 오므로, 데이터 손실 없이 안정적으로 데이터가 저장되도록 합니다.

고가용성의 중요성

고가용성은 Kafka뿐 아니라 모든 분산 시스템에서 필수적입니다. 고가용성을 통해 장애 시에도 시스템이 신속하게 복구되고 서비스 중단 없이 운영될 수 있습니다. 특히 Kafka는 실시간 데이터 스트림 처리를 주로 다루므로, 고가용성은 데이터 유실 방지와 안정적인 데이터 전송을 위해 매우 중요합니다.

Kafka Consumer는 Kafka 브로커에 저장된 데이터를 읽어오는 역할을 합니다. 컨슈머는 주로 실시간 데이터 처리를 위해 사용되며, 데이터를 가져와 분석, 처리, 알림, 저장 등의 다양한 후속 작업을 수행할 수 있도록 돕습니다.

Kafka Consumer 주요 개념

컨슈머 그룹(Consumer Group)
- 컨슈머 그룹은 여러 컨슈머가 하나의 그룹으로 동작하여 토픽의 파티션을 나누어 읽도록 합니다.
- 각 파티션은 한 번에 하나의 컨슈머에게만 할당되므로, 컨슈머가 여러 개여도 중복 읽기 없이 병렬로 데이터 처리가 가능합니다. Kafka의 컨슈머 개수는 파티션 개수와 같거나 작아야 합니다.
- 컨슈머 그룹 ID로 구분되며, 동일한 그룹 ID를 가진 컨슈머들은 같은 컨슈머 그룹으로 묶여 토픽의 데이터 처리를 협력하게 됩니다.
오프셋(Offset) 관리
- 오프셋은 Kafka에서 데이터 위치를 나타내는 값으로, 컨슈머는 오프셋을 통해 현재 어디까지 데이터를 읽었는지 기록합니다.
- 오프셋 관리를 통해 다음에 읽을 위치를 추적할 수 있으며, 컨슈머가 중단된 이후에도 정확히 중단된 위치부터 데이터를 읽을 수 있도록 합니다.
- Kafka는 기본적으로 Kafka 브로커에 오프셋을 저장하며, 컨슈머가 이 정보를 통해 데이터 중복이나 손실 없이 처리할 수 있습니다.
파티션 할당
- Kafka는 각 컨슈머 그룹 내 컨슈머에게 파티션을 할당해 병렬로 데이터를 처리하도록 합니다.
- 파티션 할당 방식은 크게 Range, RoundRobin, Sticky, Cooperative Sticky 등의 전략이 있습니다.
- 자동 할당 방식도 지원하며, 컨슈머 그룹의 구성원에 변화가 생기면 리밸런스(rebalance) 과정을 거쳐 자동으로 파티션이 재분배됩니다.
데이터 처리 방식 (Pull-based)
- Kafka 컨슈머는 데이터를 Pull 방식으로 가져옵니다. 즉, 컨슈머가 직접 브로커에 요청하여 데이터를 가져옵니다.
- 이는 데이터를 가져오는 속도를 컨슈머가 조절할 수 있게 하여 시스템 부하를 관리하고 안정성을 높일 수 있습니다.
Commit 모드
- 컨슈머는 데이터 처리가 완료된 후 오프셋을 **커밋(commit)**하여 처리 완료 상태를 기록합니다.
- **자동 커밋(auto commit)**과 **수동 커밋(manual commit)**이 있으며, 자동 커밋은 주기적으로 오프셋을 저장하고, 수동 커밋은 컨슈머가 직접 명령을 내려야 오프셋이 저장됩니다.
- 수동 커밋을 통해 특정 오프셋에서부터 재처리를 하거나, 장애 발생 시 복구 지점을 유연하게 설정할 수 있습니다.

Kafka Consumer의 장점

확장성: 컨슈머를 여러 개 추가해도, 파티션 수에 맞춰 할당되어 병렬 처리가 가능하여 데이터 처리 속도가 향상됩니다.
실시간 처리: 실시간으로 브로커에 쌓이는 데이터를 빠르게 읽어와 후속 처리를 이어갈 수 있습니다.
장애 복구: 컨슈머가 실패해도 같은 컨슈머 그룹의 다른 컨슈머가 파티션을 이어받아 처리할 수 있어 안정적입니다.

Kafka Consumer의 예시

로그 분석 시스템: Kafka 컨슈머가 실시간으로 서버 로그를 읽고, 이를 분석해 실시간으로 대시보드에 보여주거나, 이상 패턴을 탐지하여 경고를 보냅니다.
데이터 파이프라인: 여러 시스템 간 데이터를 연결하는 파이프라인에서 Kafka 컨슈머가 데이터를 읽어 다른 시스템으로 전달해 줍니다.
알림 서비스: 특정 이벤트가 발생할 때 Kafka 컨슈머가 이를 감지하고 사용자에게 알림을 보내는 서비스입니다.

서로 다른 여러개의 컨슈머 그룹이 동일한 토픽에서 데이터를 가져갈 수 있다.

Kafka에서 Lag(지연)은 컨슈머가 파티션의 최신 메시지를 소비하지 못하고 뒤처져 있는 상태를 의미합니다. 간단히 말해, Kafka 파티션에 남아 있는 아직 읽히지 않은 메시지의 수라고 할 수 있습니다.

Kafka Lag의 작동 방식

Lag 발생: 컨슈머가 메시지를 읽어들이는 속도가 프로듀서가 메시지를 생성하는 속도보다 느리면, 파티션에 처리되지 않은 메시지가 쌓입니다. 이 쌓인 메시지가 Lag입니다.
오프셋을 기준으로 계산: Kafka는 각 메시지에 오프셋(고유 번호)을 부여합니다. 컨슈머의 오프셋 위치와 파티션의 최신 오프셋 위치 차이가 곧 Lag입니다.

Lag 확인의 중요성

시스템 성능: Lag이 쌓이면 시스템이 컨슈머의 속도보다 많은 메시지를 생성하고 있다는 신호입니다. 이는 컨슈머의 성능을 최적화하거나 추가 컨슈머를 도입해야 할 필요가 있음을 의미할 수 있습니다.
실시간 처리 보장: 실시간 데이터 처리가 중요한 경우, Lag을 최소화하여 최신 데이터를 빠르게 처리하는 것이 중요합니다.

예시

만약 컨슈머가 마지막으로 읽은 오프셋이 100이고, 파티션의 최신 오프셋이 150이라면, Lag은 50이 됩니다. 이는 컨슈머가 파티션의 최신 메시지를 따라잡기 위해 50개의 메시지를 더 읽어야 한다는 의미입니다.

Kafka에서 Lag은 여러 개 존재할 수 있다. 각 컨슈머 그룹과 파티션에 따라 서로 다른 Lag이 발생할 수 있습니다.

Kafka에서 여러 Lag이 발생하는 이유

여러 컨슈머 그룹: Kafka는 동일한 토픽을 여러 컨슈머 그룹이 동시에 읽도록 설계되어 있습니다. 각 컨슈머 그룹은 개별적으로 Lag을 관리합니다. 예를 들어, 두 개의 컨슈머 그룹이 하나의 토픽을 소비하고 있다면, 각 그룹마다 Lag이 개별적으로 계산됩니다.
여러 파티션: 하나의 토픽에 여러 파티션이 존재할 경우, 각 파티션에 Lag이 개별적으로 계산됩니다. 따라서, 특정 컨슈머가 어떤 파티션에서 최신 오프셋을 따라잡지 못하면, 그 파티션에 대한 Lag이 발생하게 됩니다.
다양한 처리 속도: 각 컨슈머의 처리 속도가 다를 수 있어, 동일한 파티션을 읽는 컨슈머라도 각기 다른 Lag을 가질 수 있습니다.
파티션 재배정: 새로운 컨슈머가 추가되거나 제거되면, Kafka는 파티션을 재할당하는 과정을 거칩니다. 이때 Lag이 변화할 수 있으며, 새로운 컨슈머가 할당된 파티션을 따라잡기 전까지 Lag이 증가할 수 있습니다.

예시

만약 토픽에 파티션이 3개 있고, 두 개의 컨슈머 그룹이 있다고 가정하면, 각 파티션마다 두 개의 Lag 값이 생성될 수 있습니다. 즉, 총 6개의 Lag이 발생할 수 있습니다.

Burrow는 Kafka의 Lag 모니터링 도구 중 하나입니다. LinkedIn에서 개발한 오픈 소스 프로젝트로, Kafka 클러스터의 컨슈머 그룹 Lag 상태를 모니터링하고 알림을 제공합니다. 주로 컨슈머 지연을 감지하여 성능 저하를 방지하고, 클러스터의 전반적인 건강 상태를 유지하는 데 사용됩니다.

Burrow의 주요 기능

Lag 모니터링: Kafka 컨슈머 그룹의 오프셋을 주기적으로 체크하여 Lag(지연)을 실시간으로 모니터링합니다.
알림 시스템: 특정 임계치 이상의 Lag이 발생하면 알림을 보내도록 설정할 수 있어, 컨슈머 성능 문제를 조기에 발견할 수 있습니다.
클러스터 상태 평가: Burrow는 Lag 데이터 외에도 클러스터의 전체 상태를 평가하여 장애를 조기 감지할 수 있도록 도와줍니다.
HTTP API 제공: Burrow는 HTTP API를 통해 Lag 상태에 관한 정보를 외부 시스템에서 쉽게 접근할 수 있도록 합니다.

Burrow 사용 예시

지속적인 모니터링: Burrow는 Kafka 클러스터의 Lag을 지속적으로 추적하며, 클러스터 내 특정 컨슈머 그룹이 메시지를 제때 처리하지 못할 때 이를 알립니다.
DevOps 통합: Burrow에서 제공하는 HTTP API를 활용해 DevOps 툴과 연동하면 Slack, 이메일, PagerDuty 등으로 알림을 받아 즉각적인 대응을 할 수 있습니다.

Burrow를 사용하는 핵심 3가지

멀티 Kafka 클러스터 지원: Burrow는 하나의 인스턴스로 여러 Kafka 클러스터를 동시에 모니터링할 수 있습니다. 즉, 여러 클러스터의 컨슈머 그룹 상태와 Lag을 한 번에 추적 가능하여 대규모 환경에서도 유용합니다.
슬라이딩 윈도우 기반 상태 확인: Burrow는 슬라이딩 윈도우 방식을 사용하여 특정 시간 동안의 Lag 변화량을 기준으로 컨슈머 그룹의 상태를 "에러", "워닝", "오케이"로 평가합니다. 이 방식은 일시적인 지연과 지속적인 지연을 구분하는 데 유리하여, 일시적인 트래픽 폭주로 인한 문제를 잘못 판단하지 않도록 돕습니다.
HTTP API 제공: Burrow는 HTTP API를 통해 외부 시스템에서 Lag 데이터에 접근할 수 있게 해줍니다. 이 API를 활용해 다양한 DevOps 툴과 통합할 수 있어, 알림을 설정하거나 상태 데이터를 가져와 시각화 대시보드에 표시하는 등의 활용이 가능합니다.

'Apache Kafka' 카테고리의 다른 글

Apache kafka (0)	2024.11.08
Activemq artemis 관련 (0)	2024.11.08
Apache Kafka와 ActiveMQ (0)	2024.11.08
Zookeeper, KRaft (Kafka Raft) (1)	2024.11.07

자기개발 블로그