[Kafka] Docker로 Kafka 세팅하기 (Kraft 방식, M1 Mac)

 

 

 

M1 Mac에 docker를 사용해서 Kraft 방식의 Kafka를 세팅해보자

📌 서론

레시피아에서 긴급한 오류가 발생하면 Slack을 통해 알림이 오도록 하기위해 Kafka를 사용하기로 했다.

상용 서버에는 AWS의 MSK를 사용하고 로컬에는 docker-compose를 통해 세팅하기로 결정했고 결정에 따라 Local 맥북에 docker를 사용해서 Kafka를 세팅했다.

이번 포스트에서는 docker를 사용하여 Kafka를 세팅하는 방법을 설명하도록 하겠다.

이번 카프카 설정에서 Karl님 블로그 글의 도움을 정말 많이 받았습니다.(감사합니다.😊)

Karl님의 블로그에 들어가서 작성된 글을 따라해 보신 후 제 글도 같이 읽어보신다면 큰 도움이 될 것입니다.

Docker Compose 로 Silicon Mac에서 KRaft, Kafka Cluster 구축하기

 

1. Kafka는 Zookeeper 대신 Kraft 방식을 도입했다.

Kafka의 변화 : Zookeeper -> Kraft

• Kafka는 메타데이터 관리를 위해 전통적으로 Apache Zookeeper를 사용해왔으나, Kafka 2.8 버전부터는 Zookeeper 없이도 운영할 수 있는 Kraft(Kafka Raft) 방식을 도입했다.
  
  
• Kraft 방식은 Kafka 내부의 Raft 합의 프로토콜 구현을 활용하여, 클러스터 메타데이터 관리의 종속성과 운영 복잡성을 줄이고 확장성을 개선한다.

kafka 비교표

Raft 합의 프로토콜이란?

• Raft 합의 프로토콜은 분산 시스템에서 노드 간에 일관된 상태를 유지하기 위해 사용되는 알고리즘 중 하나다. 이 프로토콜의 목적은 네트워크 파티션, 노드 장애와 같은 분산 시스템에서 발생할 수 있는 문제 상황에서도 시스템의 일관성과 가용성을 보장하는 것이다. 참고로 이 알고리즘은 Kafka에서 만든것이 아니라 이미 존재하던 알고리즘을 적용시킨 것이다.
  
  
• Raft는 리더 선출, 로그 복제, 안전성 등을 다루는 간단하고 이해하기 쉬운 알고리즘으로 설계되었다. 시스템에서 하나의 노드가 리더로 선출되어 모든 변경 사항(예: 메타데이터 업데이트)을 관리하며, 이 변경 사항들은 리더에 의해 다른 노드(팔로워)로 복제되어 일관된 상태를 유지하게 된다.
  
  
• Kafka가 Raft 합의 프로토콜을 내부적으로 구현한 Kraft 모드를 도입함으로써, Kafka 클러스터는 더 이상 외부 시스템인 Zookeeper에 의존하지 않고 자체적으로 클러스터의 메타데이터(브로커 목록, 토픽 구성, 파티션 정보 등)를 관리할 수 있게 되었다. 이로 인해 클러스터의 설정과 운영이 단순화되고, Kafka 시스템 전체의 확장성과 가용성이 크게 개선되었다.

간단히 말해, Kraft 방식은 Kafka가 자체적으로 클러스터 상태를 관리하고 결정을 내릴 수 있게 하는 내부 Raft 구현을 통해, Zookeeper의 복잡성과 종속성을 제거하고 Kafka 클러스터의 운영을 더 단순하고 효율적으로 만들어 준 것이다.

 

2. Zookeeper대신 Kraft를 적용하여 Kafka 세팅하기

docker-compose.yml 파일을 작성했다.

• 이 구성 파일은 Kafka 클러스터를 구성하기 위해 3개의 Kafka 서비스(Kafka00Service, Kafka01Service, Kafka02Service)와 한 개의 Kafka UI 서비스(KafkaWebUiService)를 정의한다.
  
  
• 각 Kafka 서비스는 별도의 포트를 사용하며, 환경 변수를 통해 각각의 구성을 설정한다. Kafka UI 서비스는 Kafka 클러스터의 상태를 시각적으로 모니터링하기 위해 포함했다.

version: '3'

networks:
  kafka_network:

volumes:
  Kafka00:
    driver: local
  Kafka01:
    driver: local
  Kafka02:
    driver: local

services:
  Kafka00Service:
    image: bitnami/kafka:3.5.1-debian-11-r44
    restart: unless-stopped
    container_name: Kafka00Container
    ports:
      - '10000:9094'
    environment:
      - KAFKA_CFG_BROKER_ID=0
      - KAFKA_CFG_NODE_ID=0
      - KAFKA_KRAFT_CLUSTER_ID=HsDBs9l6UUmQq7Y5E6bNlw
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@Kafka00Service:9093,1@Kafka01Service:9093,2@Kafka02Service:9093
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://Kafka00Service:9092,EXTERNAL://127.0.0.1:10000
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT
      - KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR=2
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
    networks:
      - kafka_network
    volumes:
      - Kafka00:/bitnami/kafka

  Kafka01Service:
    image: bitnami/kafka:3.5.1-debian-11-r44
    restart: unless-stopped
    container_name: Kafka01Container
    ports:
      - '10001:9094'
    environment:
      - KAFKA_CFG_BROKER_ID=1
      - KAFKA_CFG_NODE_ID=1
      - KAFKA_KRAFT_CLUSTER_ID=HsDBs9l6UUmQq7Y5E6bNlw
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@Kafka00Service:9093,1@Kafka01Service:9093,2@Kafka02Service:9093
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://Kafka01Service:9092,EXTERNAL://127.0.0.1:10001
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT
      - KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR=2
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
    networks:
      - kafka_network
    volumes:
      - Kafka01:/bitnami/kafka

  Kafka02Service:
    image: bitnami/kafka:3.5.1-debian-11-r44
    restart: unless-stopped
    container_name: Kafka02Container
    ports:
      - '10002:9094'
    environment:
      - KAFKA_CFG_BROKER_ID=2
      - KAFKA_CFG_NODE_ID=2
      - KAFKA_KRAFT_CLUSTER_ID=HsDBs9l6UUmQq7Y5E6bNlw
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@Kafka00Service:9093,1@Kafka01Service:9093,2@Kafka02Service:9093
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://Kafka02Service:9092,EXTERNAL://127.0.0.1:10002
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT
      - KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=3
      - KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR=2
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
    networks:
      - kafka_network
    volumes:
      - Kafka02:/bitnami/kafka

  KafkaWebUiService:
    image: provectuslabs/kafka-ui:latest
    restart: always
    container_name: KafkaWebUiContainer
    ports:
      - '8085:8080' # 호스트의 8085 포트를 컨테이너의 8080 포트에 바인딩
    environment:
      - KAFKA_CLUSTERS_0_NAME=Local-Kraft-Cluster
      - KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092
      - DYNAMIC_CONFIG_ENABLED=true
      - KAFKA_CLUSTERS_0_AUDIT_TOPICAUDITENABLED=true
      - KAFKA_CLUSTERS_0_AUDIT_CONSOLEAUDITENABLED=true
    depends_on:
      - Kafka00Service
      - Kafka01Service
      - Kafka02Service
    networks:
      - kafka_network

3. docker-compose.yml의 네트워크, 볼륨 설정 이해하기

1. 네트워크 설정하기

• 이 구성은 kafka_network라는 이름의 네트워크를 생성하고, Docker Compose 파일에서 이 네트워크를 사용하는 서비스는 모두 이 네트워크에 연결되어 서로 통신할 수 있게 한다.
  
  
• kafka_network 네트워크를 통해 Kafka 컨테이너들이 서로 통신할 수 있게 되는 것이다. 지금처럼 추가적인 네트워크 설정이 필요하지 않은 간단한 경우나 개발 환경에서는 이 방법이 매우 유용하다.

networks: 
  kafka_network:

여기서 kafka_network: 이렇게만 하고 value가 없는데 알아서 생성되는건가?

• Docker Compose 파일에서 networks: 섹션 아래에 네트워크 이름을 지정하고 : 뒤에 아무것도 적지 않으면, Docker Compose는 그 이름을 가진 기본 네트워크를 생성한다.
  
  
• 이 기본 네트워크는 브리지(bridge) 모드로 설정되며, 이 모드는 Docker에서 가장 일반적으로 사용되는 네트워크 모드 중 하나다.
  
  

2. 볼륨 설정

• 이 부분은 세 개의 볼륨(Kafka00, Kafka01, Kafka02)을 정의하고 있다.
  
  
• 여기서 driver: local은 이 볼륨들이 로컬 파일 시스템에 저장될 것임을 의미한다. 볼륨은 컨테이너에 지속적인 데이터 저장 공간을 제공하며, 컨테이너가 삭제되거나 재시작되어도 데이터를 유지할 수 있게 한다.

volumes:
  Kafka00:
    driver: local
  Kafka01:
    driver: local
  Kafka02:
    driver: local

3. 서비스 내 볼륨 및 네트워크 사용

• 아래의 설정은 Kafka00Service라는 특정 서비스(여기서는 Kafka 컨테이너)가 사용할 네트워크와 볼륨을 지정한다.
  
  
• networks 설정으로 이 서비스가 kafka_network 네트워크에 연결되도록 지정하고, volumes 설정으로 Kafka00 볼륨을 컨테이너 내의 /bitnami/kafka 경로에 마운트하라고 지시한다. 이렇게 하면, 컨테이너 내부의 Kafka 데이터는 Kafka00 볼륨에 저장되어 컨테이너가 삭제되어도 유지될 수 있다.

services:
  Kafka00Service:
    ...
    networks:
      - kafka_network
    volumes:
      - Kafka00:/bitnami/kafka

4. docker-compose.yml의 브로커 설정 이해하기

브로커 설정 이해하기

environment:

  # 고유 식별자 설정
  - KAFKA_CFG_BROKER_ID=0
  - KAFKA_CFG_NODE_ID=0

  # 클러스터 설정 (공유 클러스터)
  - KAFKA_KRAFT_CLUSTER_ID=HsDBs9l6UUmQq7Y5E6bNlw

  # 컨트롤러 퀴럼 설정 (이 Raft 퀴럼을 구성하는 노드의 목록을 정의)
  - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@Kafka00Service:9093,1@Kafka01Service:9093,2@Kafka02Service:9093

  # 평문 통신을 허용하는지 여부를 결정하는 설정
  - ALLOW_PLAINTEXT_LISTENER=yes

  # Kafka 브로커가 자동으로 토픽을 생성할지 여부를 결정하는 설정
  - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true

  # 브로커가 사용할 리스너 설정
  - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
  - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://Kafka00Service:9092,EXTERNAL://127.0.0.1:10000  
  - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT

  # 트랜잭션, Offset, 복제 factor, ISR 설정
  - KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=3
  - KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=3
  - KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR=2

  # 브로커가 수행할 역할을 정의한다. (컨트롤러, 브로커 역할 수행)
  - KAFKA_CFG_PROCESS_ROLES=controller,broker
  - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER

 

KAFKA_CFG_BROKER_ID와 KAFKA_CFG_NODE_ID

• 각 브로커의 고유 식별자를 설정한다.
  
  

KAFKA_KRAFT_CLUSTER_ID:

• 모든 브로커가 같은 클러스터 ID를 공유해서 클러스터로 인식되도록 한다. (3개의 브로커가 동일하게 사용)
  
  

KAFKA_CFG_CONTROLLER_QUORUM_VOTERS:

• 컨트롤러 퀴럼을 구성하는 브로커의 목록을 정의한다. 이 설정은 클러스터 내의 모든 브로커가 컨트롤러 역할을 수행할 수 있음을 나타낸다. (아래에 있는 컨트롤러, 퀴럼에 대한 설명을 읽어보자)
  
  

ALLOW_PLAINTEXT_LISTENER=yes:

• 이 설정은 평문 통신을 허용하는지 여부를 결정한다. Kafka는 통신을 암호화하기 위해 SSL/TLS를 사용할 수 있지만, 이 설정을 yes로 하면 SSL/TLS 없이도 통신이 가능해진다.
  
  
• 즉, 이 옵션을 활성화하면 보안이 강화되지 않은 평문(암호화되지 않은) 연결을 통해 Kafka 브로커에 접근할 수 있게 된다. 개발 환경이나 내부 네트워크에서 테스트할 때 유용하지만, 실제 운영 환경에서는 보안을 위해 암호화된 연결을 사용하는 것이 좋다.
  
  

KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true:

• 이 설정은 Kafka 브로커가 자동으로 토픽을 생성할지 여부를 결정한다. 클라이언트가 존재하지 않는 토픽에 메시지를 보내려고 할 때, 이 설정이 true로 되어 있으면 Kafka가 자동으로 그 토픽을 생성한다.
  
  
• 이 기능은 편리할 수 있지만, 오타나 잘못된 토픽 이름으로 인한 불필요한 토픽 생성을 방지하기 위해 운영 환경에서는 비활성화하는 것이 좋을 수 있다.
  
  

KAFKA_CFG_LISTENERS와 KAFKA_CFG_ADVERTISED_LISTENERS:

• 브로커가 사용하는 리스너를 정의하고 외부에서 접근 가능한 주소를 광고한다.
  
  

KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR, KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR, KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR:

• 트랜잭션과 오프셋 관련 토픽의 복제 팩터와 최소 ISR 설정을 정의해 데이터의 내구성과 가용성을 보장한다.
  
  

KAFKA_CFG_PROCESS_ROLES:

• 브로커가 수행할 역할을 정의한다. 여기서는 모든 브로커가 컨트롤러와 브로커 역할을 모두 수행한다.
  
  

5. 컨트롤러, 퀴럼, 리스너 설정 이해하기

컨트롤러와 퀴럼이란?

• Kafka에서 컨트롤러(controller)는 클러스터의 메타데이터를 관리하고, 클러스터 내의 중요한 이벤트들을 조정하는 역할을 하는 브로커 중 하나다. 예를 들어, 파티션 리더의 선출, 브로커의 추가나 제거 같은 작업을 담당한다. 클러스터 내에서 단 하나의 브로커만이 컨트롤러 역할을 할 수 있고, 만약 현재 컨트롤러가 실패하면 다른 브로커가 새로운 컨트롤러로 선출된다.
  
  
• 컨트롤러 퀴럼(Controller Quorum)은 Kafka 2.8 버전부터 도입된 KRaft(Kafka Raft Metadata) 모드에서 사용되는 개념으로, 클러스터의 메타데이터를 관리하는 새로운 방식이다. 이 모드에서는 Zookeeper의 대체로, Kafka 자체의 Raft 프로토콜 구현을 사용해 클러스터 메타데이터를 관리한다. 여기서 "퀴럼(quorum)"은 분산 시스템에서 다수결을 의미하는 용어로, 결정을 내리기 위해 동의가 필요한 최소한의 노드 수를 말한다.
  
  
• KAFKA_CFG_CONTROLLER_QUORUM_VOTERS 설정은 이 Raft 퀴럼을 구성하는 노드의 목록을 정의한다. 이 목록에 포함된 브로커들은 클러스터의 메타데이터를 관리하는데 참여하고, 필요한 경우 컨트롤러 역할을 수행할 수 있다. 각 브로커는 브로커ID@호스트명:포트 형식으로 지정되며, 이를 통해 클러스터 내에서 메타데이터를 관리하는 데 필요한 합의를 이룰 수 있다.

요약하자면, 컨트롤러 퀴럼은 Kafka 클러스터의 메타데이터를 관리하기 위해 Raft 합의 알고리즘을 사용하는 브로커들의 그룹이다.
이 설정은 클러스터의 고가용성과 내구성을 강화하고, Zookeeper에 대한 의존성을 제거하여 Kafka 클러스터의 운영을 단순화하는 데 도움을 준다.

 

리스너 (KAFKA_CFG_LISTENERS) 설정을 이해해 보자

- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094

• KAFKA_CFG_LISTENERS 설정에서 9092, 9093, 9094 포트가 각각 다른 역할을 하고 있다.
  
  
• Kafka에서 리스너(listener)는 Kafka 브로커가 클라이언트나 다른 브로커와 통신하는데 사용하는 네트워크 인터페이스와 포트를 정의한다. 각 리스너는 Kafka 클러스터 내부 또는 외부의 클라이언트와의 통신을 위해 구성되며, 특정 역할과 관련된 트래픽을 처리한다.
  
  

PLAINTEXT://:9092:

• 이 리스너는 일반적으로 내부 클라이언트 또는 클러스터 내 다른 브로커와의 통신에 사용되는 기본 리스너다. 여기서 PLAINTEXT는 암호화되지 않은 통신을 의미하고, 9092는 이 리스너가 사용하는 포트다.
  
  

CONTROLLER://:9093:

• 이 리스너는 Kafka 클러스터의 컨트롤러 역할을 하는 브로커가 사용하는 포트다. 컨트롤러는 클러스터의 메타데이터를 관리하고, 리더 선출 같은 클러스터 수준의 작업을 조정하는 중요한 역할을 한다. 9093 포트는 이러한 컨트롤러 통신을 위해 예약되어 있다.
  
  

EXTERNAL://:9094:

• 이 리스너는 외부 클라이언트가 클러스터에 접근할 때 사용되는 포트다. EXTERNAL이라는 명칭은 클러스터 외부에서 오는 연결을 위한 것이라는 점을 강조한다. 클러스터 외부의 애플리케이션이나 서비스가 Kafka 브로커와 통신할 때 이 리스너를 통해 접근하게 된다.

지금 도커 설정을 보면 9094 포트는 이러한 외부 통신을 위해 설정된 것이고, 외부에서 접근할 수 있도록 포트 포워딩을 통해 호스트 시스템의 포트(10000, 10001, 10002)와 연결되어 있다.

 

6. docker-compose로 실행하고 확인하기

코드 작성 후 아래 명령어로 도커 컴포즈를 실행한다. (파일이 있는곳에서 명령어 실행)

docker-compose up -d

docker-compose 실행

• 실행에 성공하면 아래와 같이 로그가 나온다.

docker success

• docker-desktop에서 확인해 보니 4개의 docker 이미지가 모두 잘 올라갔다. (3개의 브로커, 1개의 kafka-ui)

docker-desktop 확인

7. docker-desktop에서 토픽을 만들고 producer, consumer를 사용해보자

1. 토픽 생성

• error-messages이라는 이름의 토픽을 생성하려면, 다음과 같은 명령어를 사용할 수 있다.
• 나는 파티션 수를 3개, replication-factor를 2로 설정했다.

kafka-topics.sh --create --topic error-messages --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092 --partitions 3 --replication-factor 2

2. Console Consumer 사용

• error-messages 토픽에서 메시지를 읽기 위해 Console Consumer를 사용할 수 있다. 이때 --from-beginning 옵션을 사용하면 토픽의 처음부터 메시지를 읽을 수 있게 된다.
• 아래의 명령어를 실행하면, error-messages 토픽으로 전송된 메시지들을 볼 수 있다.

kafka-console-consumer.sh --topic error-messages --from-beginning --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092

3. Console Producer 사용

• error-messages 토픽으로 메시지를 전송하기 위해 Console Producer를 사용할 수 있다.
• 아래의 명령어 실행 후, 터미널에 메시지를 입력하면 error-messages 토픽으로 메시지가 전송된다.

kafka-console-producer.sh --topic error-messages --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092

4. producer, consumer 명령어에 공통적으로 적는 bootstrap-server 옵션 이해하기

• Kafka00Service:9092, Kafka01Service:9092, Kafka02Service:9092 이렇게 여러 브로커의 주소를 --bootstrap-server 옵션에 명시하는 이유는 Kafka 클라이언트(프로듀서나 컨슈머)가 클러스터에 처음 연결할 때 사용하는 초기 연결 포인트를 제공하기 위함이다.
  
  
• 클라이언트는 이 주소들 중 하나에 연결하여 클러스터의 메타데이터(예: 토픽의 파티션 리더 정보 등)를 가져온다. 이 정보를 통해 클라이언트는 필요한 모든 파티션의 리더와 직접 통신할 수 있게 된다.
  
  
• 여러 브로커 주소를 명시하는 주된 이유는 고가용성을 위함이다. 단일 브로커 주소만 명시하고 그 브로커가 다운되면, 클라이언트는 Kafka 클러스터에 연결할 수 없게 된다. 하지만 여러 브로커의 주소를 명시하면, 하나의 브로커가 실패해도 다른 브로커를 통해 클러스터에 접근할 수 있으므로 클라이언트의 연결이 더욱 안정적이게 된다.
  
  
• 즉, 이러한 방식으로 여러 브로커 주소를 명시하는 것은 특정 브로커에 모두 적용되는 것이 아니라, 클라이언트가 클러스터의 메타데이터에 접근할 수 있는 더 많은 기회를 제공하는 것이다. 클라이언트는 이 메타데이터를 바탕으로 필요한 모든 통신을 수행한다.

이 명령어들을 사용하여 Kafka의 프로듀서와 컨슈머 기능을 테스트할 수 있다.
주의해야 할 점은 Kafka 클러스터와 통신하기 위해 올바른 --bootstrap-server 값을 사용해야 한다는 것이다.
여기서는 내가 서버에 띄운 Kafka00Service:9092, Kafka01Service:9092, Kafka02Service:9092를 사용했다.

 

8. 마지막으로 kafka-ui를 사용해보자

Kafka UI를 사용하려면 다음 단계대로 진행하면 된다.

1. 웹 브라우저를 연다.
2. 주소 표시줄에 http://localhost:8085 를 입력한다. (Kafka UI 서비스를 8085 포트에 바인딩했다고 가정한다.)
3. 엔터 키를 눌러 Kafka UI 웹 인터페이스에 접속한다.
   
   

Kafka UI 웹 인터페이스에서는 다음과 같은 작업을 수행할 수 있다.

• 클러스터 정보 확인: Kafka 클러스터의 전반적인 상태, 브로커 리스트, 파티션 정보 등을 볼 수 있다.
• 토픽 관리: 토픽을 생성, 삭제하거나 토픽의 상세 정보를 확인할 수 있다.
• 컨슈머 그룹 모니터링: 컨슈머 그룹의 상태와 오프셋 정보를 모니터링할 수 있다.
• 메시지 탐색: 특정 토픽의 메시지를 조회하고 내용을 확인할 수 있다.
  
  

웹페이지에 접속하면 다음과 같이 보인다.

• 이건 아직 제대로 사용해보지 못했기 때문에 사용해보고 얻은 지식을 새로운 글로 올릴 예정이다.

kafka ui

 

 

다음 포스트를 통해 SpringBoot3.1.2 버전에 Kafka를 연동시켜 보자

[Kafka] SpringBoot3.x.x에서 Kafka 연동하기

사이드 팀원 "평양냉면"님의 블로그도 방문해주세요! 좋은 글이 많습니다.

하다보니 재미있는 개발