macOS에서 docker-compose로 Kafka 설치하기 (Zookeeper 사용 X)

macOS에서 docker-compose로 Kafka 설치하기 (Zookeeper 사용 X)

 

Kafka 카프카

 

📌 서론

스프링 부트 프로젝트에서 에러가 발생하면 Slack으로 알림을 보내기 위해서 Kafka를 사용해 보기로 했다.

 

우선 테스트 환경에서 Kafka를 실행해보기 위해서 macOS 환경에서 docker-compose로 Kafka를 설치해 봤다. 이전에 Zookeeper를 사용하던 때랑 달라진 점이 많아서 조금 헷갈리지만 그래도 최대한 할 수 있는 데까지는 정리해 봤다.

 

여전히 모르는 개념이 많기 때문에 계속 공부하면서 적용해 봐야겠다...

 

docker-compose.yml

다음 docker-compose.yml 파일은 Kafka 클러스터를 구성하기 위한 Docker 컨테이너 설정을 담고 있다. Kafka 클러스터는 3개의 Kafka 브로커와 Kafka UI를 포함한다.

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

 

 

kafka 브로커 서비스

networks

kafka_network: Kafka 서비스 간의 통신을 위한 사용자 정의 네트워크를 생성한다. 이 네트워크는 모든 Kafka 컨테이너와 Kafka UI 컨테이너 사이의 내부 통신을 가능하게 한다.

volumes

Kafka00, Kafka01, Kafka02: 각 Kafka 브로커의 데이터를 저장하기 위한 볼륨을 정의한다. local 드라이버를 사용하여 호스트 시스템의 저장소를 컨테이너에 연결한다.

 

 

Docker Compose에서 volumes 사용

 

volumes 섹션에서 정의하는 것

이 부분은 볼륨의 이름과 사용할 드라이버를 정의한다. 여기서 local 드라이버를 사용한다고 명시하면, Docker는 호스트의 로컬 파일 시스템에 데이터를 저장하는 볼륨을 생성한다. Kafka00, Kafka01, Kafka02 볼륨 이름을 정의함으로써, 이 볼륨들을 services 섹션 내에서 참조할 수 있게 된다. 이렇게 하면, 동일한 볼륨 이름을 사용하여 서비스가 데이터를 영구적으로 저장할 수 있는 공간을 지정할 수 있다.

 

서비스 안에서 volumes로 마운트 하는 것

이 부분은 실제로 해당 서비스의 컨테이너가 실행될 때, 위에서 정의한 볼륨을 컨테이너의 특정 경로에 마운트하는 작업을 지시한다. 이를 통해 컨테이너 내부에서 데이터를 읽고 쓸 수 있는 파일 시스템으로 볼륨을 사용할 수 있게 된다. 각 Kafka 서비스가 자신의 볼륨을 /bitnami/kafka 경로에 마운트함으로써, Kafka 데이터가 이 경로에 저장되고 영구적으로 유지된다.

 

다시 말하자면, Docker Compose 파일에서 volumes 섹션에 볼륨을 정의하고, 서비스 설정에서 이 볼륨을 마운트하는 방식으로 사용하는 경우, 실제 호스트 파일 시스템에 물리적인 폴더를 생성할 필요가 없다. Docker가 자동으로 해당 볼륨을 관리하고, 필요에 따라 호스트 시스템의 어딘가에 데이터를 저장하기 때문이다.

 

local 드라이버를 사용할 때 Docker는 자동으로 호스트 시스템에 데이터를 저장하는 위치를 관리하며, 이 위치는 Docker가 설치된 시스템에 따라 다를 수 있다. 볼륨 이름(예: Kafka00, Kafka01, Kafka02)을 정의함으로써, 이 이름을 사용하여 서비스 내에서 해당 볼륨을 마운트 할 수 있으며, 이 과정은 모두 Docker에 의해 내부적으로 처리된다.

 

볼륨을 마운트 하는 주된 목적 중 하나는 데이터의 영속성을 보장하는 것이다. 즉, 컨테이너가 삭제되거나 Docker가 재시작되어도 마운트된 볼륨에 저장된 데이터는 보존된다. 따라서, Kafka 데이터(예: 토픽, 메시지 등)는 볼륨에 안전하게 저장되며, Docker 컨테이너를 재시작해도 데이터는 사라지지 않는다.

 

이 방식을 사용하면, 복잡한 경로 설정이나 호스트 시스템의 특정 폴더에 직접 접근할 필요 없이, 데이터의 영속성과 관리를 Docker에 맡길 수 있다. 사용자는 단지 docker-compose.yml 파일에서 볼륨을 올바르게 정의하고 마운트하는 것만으로, 데이터 관리를 효율적으로 수행할 수 있다.

 

restart

restart는 컨테이너의 재시작 정책이다.

unless-stopped 재시작 정책은, Docker 컨테이너가 다음의 경우를 제외하고는 항상 재시작되도록 한다:

• 사용자가 명시적으로 컨테이너를 멈추게 했을 때 (예: docker stop 명령어 사용)
• Docker 자체가 멈추었을 때

즉, 이 정책은 컨테이너가 예기치 않게 종료되었을 때 (예: 프로세스 충돌) 자동으로 컨테이너를 재시작한다.

 

environment

Kafka 설정을 위한 환경 변수들. KAFKA_CFG_* 변수들은 Kafka 설정 파일에 해당하는 값을 제공한다.

 

KAFKA_CFG_BROKER_ID와 KAFKA_CFG_NODE_ID

브로커의 고유 식별자로, 클러스터 내에서 각 브로커를 구분하는 데 사용된다. 일반적으로 이 두 값은 같게 설정된다.

 

KAFKA_KRAFT_CLUSTER_ID

KAFKA_KRAFT_CLUSTER_ID는 Kafka 클러스터를 고유하게 식별하는 ID다.

KRaft 모드에서는 Zookeeper 대신 이 ID를 사용하여 클러스터의 메타데이터를 관리한다. 이 값은 UUID 형식으로 되어 있어야 하며, 클러스터 내에서 고유해야 한다. 하지만, 테스트 환경에서는 간단하게 구분만 가능하다면 임의의 값으로 설정해도 기능상의 문제는 없다.

 

KAFKA_CFG_CONTROLLER_QUORUM_VOTERS

KAFKA_CFG_CONTROLLER_QUORUM_VOTERS는 KRaft 모드에서 컨트롤러 역할을 수행할 브로커들의 목록을 정의한다.

이 설정은 <broker_id>@<host_name>:<port> 형식으로, 클러스터 내에서 메타데이터를 관리할 브로커의 ID와 해당 브로커가 수신 대기할 호스트 이름 및 포트를 지정한다. 위 예시에서는 세 개의 브로커가 각각 9093 포트를 사용하여 컨트롤러 통신을 위한 리스너를 구성하고 있음을 나타낸다.

 

컨트롤러의 역할

Kafka에서 컨트롤러는 클러스터의 메타데이터를 관리하는 중요한 역할을 한다. 주요 책임은 토픽 생성, 삭제와 같은 클러스터의 메타데이터 변경 사항을 처리하고, 파티션 리더의 선출과 같은 작업을 수행하는 것이다. KRaft 모드에서는 전통적인 Zookeeper 기반 아키텍처 대신 내부적으로 컨트롤러를 사용하여 이러한 메타데이터 관리 작업을 수행한다.

 

ALLOW_PLAINTEXT_LISTENER

이 설정은 Kafka 브로커가 암호화되지 않은 연결을 허용할지를 결정한다. yes로 설정하면, 클라이언트는 SSL/TLS 같은 보안 프로토콜 없이도 브로커에 연결할 수 있다. 이는 개발 또는 테스트 환경에서 유용할 수 있으나, 보안이 중요한 생산 환경에서는 사용을 피해야 한다.

 

KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE

이 설정은 클라이언트가 존재하지 않는 토픽을 구독하려고 할 때 Kafka가 자동으로 해당 토픽을 생성할지 여부를 결정한다. true로 설정하면, 존재하지 않는 토픽에 대한 첫 번째 요청이 발생할 때 Kafka가 자동으로 토픽을 생성한다. 이는 개발 환경에서 편리할 수 있으나, 생산 환경에서는 의도치 않은 토픽 생성을 방지하기 위해 false로 설정하는 것이 좋다.

 

KAFKA_CFG_LISTENERS

• PLAINTEXT://:9092: 이 리스너는 암호화되지 않은 연결을 위한 것으로, 9092 포트에서 클라이언트의 연결을 수신 대기한다.
• CONTROLLER://:9093: 이 리스너는 KRaft 모드에서 컨트롤러 간의 통신을 위한 것으로, 9093 포트에서 수신 대기한다.
• EXTERNAL://:9094: 이 리스너는 외부 네트워크(예: 인터넷)에서 오는 연결을 위한 것으로, 9094 포트에서 수신 대기한다. 이를 통해 클러스터 외부의 클라이언트가 Kafka 브로커에 연결할 수 있다.

 

KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP

이 설정은 각 리스너의 보안 프로토콜을 매핑한다. 이 예시에서는 모든 리스너(CONTROLLER, EXTERNAL, PLAINTEXT)가 PLAINTEXT (즉, 암호화되지 않은 연결)를 사용한다고 명시하고 있다.

 

KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR

이 설정은 Kafka 내부에서 사용하는 오프셋 토픽의 복제 팩터를 결정한다. 3으로 설정하면, 오프셋 데이터는 클러스터 내의 세 개의 다른 브로커에 복제되어 고가용성을 보장한다.

 

KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR

이 설정은 트랜잭션 상태를 추적하는 내부 토픽의 복제 팩터를 설정한다. 여기서도 3으로 설정하여, 트랜잭션 메타데이터의 고가용성을 보장한다.

 

KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR

이 설정은 트랜잭션 상태 로그에 대한 최소 In-Sync Replicas (ISR)의 수를 결정한다. 2로 설정하면, 어떤 데이터도 커밋되기 위해서는 최소한 두 개의 복제본이 동기화되어 있어야 함을 의미한다.

 

KAFKA_CFG_PROCESS_ROLES

이 설정은 해당 Kafka 인스턴스가 수행할 역할을 정의한다. controller, broker로 설정하면, 이 인스턴스는 클러스터의 컨트롤러 역할과 일반 브로커 역할을 모두 수행한다.

 

KAFKA_CFG_CONTROLLER_LISTENER_NAMES

이 설정은 컨트롤러 간 통신에 사용될 리스너의 이름을 지정한다. 여기서는 CONTROLLER 리스너가 컨트롤러 통신을 위해 사용됨을 나타낸다.

 

networks

컨테이너가 연결될 네트워크다.

volumes

데이터 저장을 위한 볼륨 마운트다.

 

 

kafka UI 서비스

Kafka UI 서비스를 설정한다.

(아직 kafka ui에 대해서는 잘 알지 못하기 때문에 해당 내용은 챗지피티의 도움을 받았다.)

 

KAFKA_CLUSTERS_0_NAME

이 환경 변수는 UI에서 표시될 Kafka 클러스터의 이름을 설정한다. 여기서는 클러스터의 이름을 Local-Kraft-Cluster로 설정했다. 이 이름은 사용자가 여러 클러스터를 구분하기 위해 UI에서 사용할 수 있는 레이블이다.

 

KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS

Kafka 클러스터와 연결하기 위한 초기 부트스트랩 서버의 목록을 정의한다. 이 설정은 Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092와 같이, Kafka 서비스의 이름과 포트 번호를 사용하여 지정된다. 이는 Kafka UI가 Kafka 클러스터에 연결하여 메타데이터를 가져오고 메시지를 조회할 수 있도록 해준다.

 

DYNAMIC_CONFIG_ENABLED

Kafka UI가 동적으로 Kafka 클러스터의 설정을 변경할 수 있는지 여부를 제어한다. true로 설정하면, Kafka UI를 통해 클러스터의 설정을 동적으로 변경할 수 있다. 이 기능은 클러스터의 구성을 실시간으로 조정할 필요가 있을 때 유용할 수 있다.

 

KAFKA_CLUSTERS_0_AUDIT_TOPICAUDITENABLED

Kafka UI에서 특정 토픽에 대한 감사 로깅(audit logging)을 활성화할지 여부를 결정한다. true로 설정하면, 감사 이벤트를 기록하는 특별한 감사 토픽에 대한 정보를 UI에서 볼 수 있다. 이는 클러스터의 사용 패턴을 모니터링하고 보안 감사를 수행하는 데 도움이 될 수 있다.

 

KAFKA_CLUSTERS_0_AUDIT_CONSOLEAUDITENABLED

감사 이벤트가 콘솔(서버 로그)에도 기록되어야 하는지 여부를 결정한다. true로 설정하면, 감사 로그가 Kafka UI 서비스의 콘솔 로그에도 출력된. 이는 문제 해결 및 모니터링 과정에서 유용할 수 있다.

 

depends_on

섹션은 Kafka UI 서비스가 시작되기 전에 Kafka00Service, Kafka01Service, Kafka02Service 서비스들이 먼저 시작되어야 함을 나타낸다. 이는 서비스 간의 의존성을 관리하여 서비스가 올바른 순서로 시작되도록 보장한다.

 

networks

networks 섹션에서는 이 서비스가 속할 네트워크를 지정한다. 여기서는 kafka_network라는 네트워크에 이 서비스를 연결하고 있다. 이는 Docker 내부 네트워킹을 통해 서비스 간의 통신을 용이하게 하며, 동일한 네트워크 내의 컨테이너들이 서로 통신할 수 있도록 한다.

 

 

zookeeper를 안 쓰는 이유

이 구성은 Kafka 2.8.0 이상에서 도입된 KRaft (Kafka Raft Metadata mode)를 사용하여 Zookeeper 없이 Kafka를 운영한다.

 

KRaft 모드는 Kafka 자체의 메타데이터를 관리하는 새로운 방식으로, 별도의 Zookeeper 클러스터 없이 Kafka 클러스터를 운영할 수 있게 해 준다. 이는 아키텍처를 단순화하고, 관리를 용이하게 하며, 성능을 개선할 수 있는 장점을 제공한다.

KAFKA_KRAFT_CLUSTER_ID 환경 변수는 이 KRaft 모드를 활성화하는 데 필요한 클러스터 ID를 설정하는 데 사용된다.

 

그럼 이제 도커 컴포즈에 대해서 간략하게 이해했으니까 바로 실행해 보자!

 

 

docker-compose 실행

다음 명령어로 docker-compose.yml 파일을 실행할 수 있다.

docker-compose up -d

 

 

컨테이너 실행 확인

도커 컨테이너가 잘 실행됐는지 확인하자.

docker-compose ps

 

위 명령어를 실행하면 현재 실행 중인 도커 컨테이너 목록이 보인다.

도커 컨테이너 목록

 

 

Kafka UI도 잘 실행되는지 확인해 보자.

docker-compose.yml 파일에서 지정한 8085 포트로 접속하면 페이지 접속도 잘 된다!

Kafka UI 접속 화면

 

 

 

카프카 토픽 생성

이제 토픽을 생성해 보자.

 

카프카 생성 명령어는 다음과 같다. (나는 kafka00Container 컨테이너 내부에서 다음 명령어를 실행했다.)

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

 

• kafka-topics.sh : 카프카 토픽을 관리하는 스크립트 파일
• --create : 새로운 토픽을 생성하는 옵션이다.
• --topic test-topic : 생성할 토픽의 이름을 test-topic으로 설정한다.
• --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092 : 카프카 클러스터에 접근하기 위한 부트스트랩 서버 목록을 설정한다. 여기서는 Kafka00Service, Kafka01Service, Kafka02Service라는 세 개의 서버에 접근하며, 각각의 서버는 9092 포트를 사용한다.
• --partitions 3 : 이 토픽을 3개의 파티션으로 나눈다.
• --replication-factor 2 : 각 파티션의 데이터를 2개의 복제본으로 유지한다.

이 명령어를 실행하면, test-topic이라는 이름의 토픽이 생성되며, 이 토픽은 3개의 파티션으로 구성되고, 각 파티션은 2개의 복제본을 가지게 된다. 이는 고가용성과 높은 처리량을 위한 설정이다.

 

나는 Docker Desktop 환경에서 진행했다.

Docker Desktop에서 컨테이너 내부로 접속하려면 다음과 같은 단계를 거치면 된다.

1. 접속을 원하는 컨테이너 이름 옆에 점 세 개를 클릭한다.

도커 데스크탑 화면

 

 

2. 점 세개를 클릭하면 나오는 메뉴에서 'Open in terminal' 메뉴를 클릭한다.

상세 메뉴

3. 그럼 해당 컨테이너 내부의 터미널 화면이 보인다!

도커 컨테이너 터미널 접속 화면

 

이제 이 화면에서 토픽 생성해 주는 명령어를 실행해 보자.

토픽 생성 명령어 실행 성공

 

보이는 화면과 같이 토픽이 잘 생성된 모습을 확인할 수 있다.

 

이제 이 토픽의 컨슈머를 생성해 보자.

 

 

Console Consumer 사용

test-topic 토픽에서 메시지를 읽기 위해 Console Consumer를 사용할 수 있다.

 

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

 

• kafka-console-consumer.sh : 카프카의 콘솔 컨슈머를 실행하는 스크립트 파일
• --topic test-topic : 이 옵션은 컨슈머가 메시지를 읽어올 토픽의 이름을 지정한다. 여기서는 test-topic이라는 토픽에서 메시지를 읽는다.
• --from-beginning : 이 옵션을 추가하면, 컨슈머가 해당 토픽의 처음부터 메시지를 읽기 시작한다. 이 옵션이 없으면 컨슈머는 새로운 메시지만 읽기 시작한다.
• --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092 : 이는 카프카 클러스터에 접근하기 위한 부트스트랩 서버의 목록을 지정한다. Kafka00Service, Kafka01Service, Kafka02Service라는 세 개의 서버에 9092 포트를 통해 접근한다.

이 명령어는 특정 토픽(test-topic)의 메시지를 처음부터 읽기 시작하여, 콘솔(터미널)에 출력한다. 이를 통해 개발자는 실시간으로 메시지를 확인하거나, 특정 조건에서 메시지를 디버깅하는 데 유용하게 사용할 수 있다.

 

우선 위에 Docker Desktop 터미널 화면에서 새로운 터미널 창을 켜주자. 'Open in external terminal' 버튼을 클릭한다.

외부 터미널 창 열기 버튼

 

그럼 이렇게 자동으로 해당 컨테이너로 접속한 상태의 터미널을 새창으로 띄워준다.

컨테이너 접속 터미널

 

이제 위 명령어를 실행하면 test-topic 토픽으로 전송된 메시지들을 볼 수 있다. (현재는 보낸 메시지가 없으니까 아무것도 안 뜨는 게 정상이다.)

카프카 메시지 컨슈머

 

 

Console Producer 사용

test-topic 토픽으로 메시지를 전송하기 위해 Console Producer를 사용할 수 있다. 다음 명령어를 실행하고 메시지를 입력하면 해당 토픽으로 메시지가 전송된다.

 

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

 

• kafka-console-producer.sh : 카프카의 콘솔 프로듀서를 실행하는 스크립트 파일
• --topic test-topic : 이 옵션은 프로듀서가 메시지를 보낼 토픽의 이름을 지정한다. 여기서는 test-topic이라는 이름의 토픽으로 메시지를 전송한다.
• --bootstrap-server Kafka00Service:9092,Kafka01Service:9092,Kafka02Service:9092 : 이 옵션은 카프카 클러스터에 접근하기 위한 부트스트랩 서버의 목록을 지정힌다. 여기서는 Kafka00Service, Kafka01Service, Kafka02Service라는 세 개의 서버를 지정하며, 각각 9092 포트를 사용하여 접근한다.

이 명령어를 실행하면, 사용자는 터미널에서 직접 메시지를 입력할 수 있는 상태가 된다. 입력한 메시지는 지정된 토픽(test-topic)으로 전송되며, 해당 토픽을 구독하고 있는 컨슈머들은 이 메시지를 받게 된다.

 

메시지 전송 명령어는 Docker Desktop에서 실행해 보자.

 

위 명령어를 치면 나오는 > 문구 뒤에 hellooooooooooo라는 메시지를 입력했다.

카프카 메시지 전송

그럼 아까 컨슈머 창으로 띄워놨던 터미널에서 해당 메시지(hellooooooooooo)를 잘 받아오는 모습을 확인할 수 있다!

카프카 메시지 수신 성공

 

 

 

 

 

참고: https://breezymind.com/silicon-mac-kafka-cluster-docker-compose/

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

 

 

 

 

 

 

다른 팀원인 "개발자의 서랍"님의 블로그도 한번 방문해 보세요! 좋은 글이 많이 있습니다 :)

개발자의 서랍