Apache Kafka:: 카프카

Intro::

아파치 카프카에 대해서 알아봅시다.

카프카란??

메시지 큐 Message Queue 란??

• 비동기: 임시 저장소에 저장해 두기 때문에 비동기적 처리가 가능합니다.

• 낮은 결합도: 애플리케이션 분리

• 확장성: producer 혹은 consumer 서비스를 원하는대로 확장 가능합니다.

• 탄력성: consumer가 다운되더라도 애플리케이션이 중단되는 것이 아니며 메시지는 남아있습니다.

• 보장성: 메시지 큐에 들어간 모든 메시지는 consumer 서비스에게 전달됩니다.

메시지 브로커(Message Broker)

1. 메시지 큐잉: 메시지를 큐(queue)에 저장하여 소비자가 준비될 때까지 보관합니다.

2. 메시지 전달 보장: 메시지가 손실되지 않도록 보장합니다.

3. 로드 밸런싱: 여러 소비자 간에 메시지를 고르게 분배합니다.

4. 순서 보장: 메시지가 특정 순서대로 전달되도록 보장합니다.

이벤트 브로커(Event Broker)

1. 발행/구독 모델: 이벤트를 발행자(publisher)와 구독자(subscriber) 간에 비동기적으로 전달합니다.

2. 실시간 처리: 이벤트를 실시간으로 처리하여 즉각적인 반응을 가능하게 합니다.

3. 스케일링: 많은 이벤트와 구독자를 처리할 수 있도록 확장성을 제공합니다.

차이점 요약

• 목적: 메시지 브로커는 주로 데이터를 안정적으로 전달하는 데 중점을 두고, 이벤트 브로커는 실시간 이벤트 처리에 중점을 둡니다.

• 구조: 메시지 브로커는 큐를 사용하고, 이벤트 브로커는 발행/구독 모델을 사용합니다. 또한 이벤트 브로커는 publisher가 생산한 이벤트를 이벤트 처리 후에 바로 삭제하지 않고 저장하여, 이벤트 시점이 저장되어 있어 consumer가 특정 시점부터 이벤트를 다시 consume 할 수 있는 장점이 있습니다.

• 사용 사례: 메시지 브로커는 주문 처리 시스템, 로그 수집 등에 사용되고, 이벤트 브로커는 실시간 데이터 스트리밍, 모니터링 시스템 등에 사용됩니다.

docker-compose

services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    container_name: zookeeper
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - "2181:2181"
    networks:
      - kafka-net

  kafka:
    image: confluentinc/cp-kafka:latest
    container_name: kafka
    depends_on:
      - zookeeper
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
    ports:
      - "9092:9092"
    volumes:
      - kafka-data:/var/lib/kafka/data
    networks:
      - kafka-net

volumes:
  kafka-data:

networks:
  kafka-net:
    driver: bridge

# 토픽 생성
kafka-topics --create --topic topic1 --bootstrap-server localhost:9092 --replication-factor 1
--partitions 1
# 토픽 확인
kafka-topics --describe --topic topic1 --bootstrap-server localhost:9092
# 프로듀서 실행
kafka-console-producer --topic topic1 --broker-list kafka:9092
# 컨슘어 실행
kafka-console-consumer --topic topic1 --bootstrap-server kafka:9092

스프링 + 카프카 예제

studies/Spring/spring-kafka at main · SONGS4RI/studies

Contribute to SONGS4RI/studies development by creating an account on GitHub.

https://github.com/SONGS4RI/studies/tree/main/Spring/spring-kafka

궁금한점

• groupId 가 왜 필요한 것인가??
• groupId는 Kafka 소비자 그룹을 식별하기 위해 필요합니다. 동일한 groupId를 가진 소비자들은 하나의 그룹으로 묶이며, 각 파티션을 병렬로 소비하게 됩니다.
• 이를 통해 동일한 메시지가 그룹 내 여러 소비자에게 중복 전달되지 않고, 메시지 처리의 병렬성을 확보할 수 있습니다.
• 만약 한 토픽의 메시지를 여러 애플리케이션에서 사용해야 한다면, 각 애플리케이션이 다른 groupId를 사용하여 독립적인 소비자 그룹으로 메시지를 소비하면 됩니다.

• 한 토픽에 여러 파티션일때 해당 토픽을 소모하는 그룹에 consumer가 하나이라면 어떻게 동작하는가???
• 해당 consumer가 모든 파티션의 메시지를 소비합니다.

References::

[Kafka] Docker Compose 를 이용하여 Single Broker 구성하기

데보션 (DEVOCEAN) 기술 블로그 , 개발자 커뮤니티이자 내/외부 소통과 성장 플랫폼

https://devocean.sk.com/blog/techBoardDetail.do?ID=164007

[kafka/Docker] 도커로 카프카를 띄워보고, 토픽 생성 후 메시지를 보내보자.

카프카란? 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산형 데이터 스트리밍 플랫폼이다. 즉, API로 데이터를 바로 요청을 하는 것이 아닌 미들웨어인 카프카를 둬서 프로듀서가 메시지를 생산해서 토픽으로 메시지를 보내고, 컨슈머는 토픽의 메시지를 가져와 사용하는 애플리케이션 부분이다. 따라서 연결되어 있는 토픽에 메시지(큐)가 들어오면 컨슈머는 그 메시지를 받을 수 있는 것이다. 장점) 1. 대량의 데이터를 처리 가능하고, 시스템 부하에 따라 확장이 가능하다. 2. 카프카는 실시간 데이터 처리를 위해 설계되었다. 데이터가 전송되는 즉시 프로듀서와 컨슈머가 데이터를 처리할 수 있고, 데이터의 지연 시간이 최소화되기 때문에 실시간 데이터 스트리밍이 가능하다. 3. 카프카는 메시지를 영속..

https://9hyuk9.tistory.com/92