Chapter 2. 카프카 설치

[kmg28801]

카프카와 주키퍼

• 프로듀서 : 카프카와 통신하면서 메시지를 보내는 역할
• 컨슈머 : 카프카와 통신하면서 메시지를 가져오는 역할
• 현재까지의 카프카 버전에서는 오프셋 정보를 주키퍼와 카프카 양쪽에 저장하지만, 향후 주키퍼에 오프셋을 저장하는 기능은 곧 사라질 예정
• 주키퍼는 컨슈머와 통신하는 역할 외에도, 카프카와 직접 통신을 하면서, 카프카의 메타데이터 정보를 주키퍼에 저장하고, 카프카의 상태관리 등의 목적으로 주키퍼를 활용한다.

주키퍼

• 주키퍼는 분산 애플리케이션을 위한 코디네이션 시스템
  • 분산 애플리케이션이 안정적인 서비스를 할 수 있도록 분산되어 있는 각 애플리케이션의 정보를 중앙에 집중하고 구성 관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공

• 주키퍼는 위 그림과 같이 서버 여러 대를 클러스터로 구성하고, 분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보등을 주고 받는다.
• 상태 정보들은 주키퍼의 지노드(znode)라 불리는 곳에 키-값 형태로 저장된다.
• 지노드에 키-값이 저장된 것을 이용해 분산 애플리케이션들은 서로 데이터를 주고 받는다.
• 주키퍼에서 사용되는 지노드는 데이터를 저장하기 위한 공간 이름으로, 일반 컴퓨터의 파일이나 폴더 개념

• 일반적으로 지노드에 저장하는 데이터 크기는 바이트에서 킬로바이트 수준

• 지노드는 우리가 알고 있는 일반적인 디렉토리와 비슷한 형태로서 자식노드를 가지고 있는 계층형 구조로 구성

  

• 주키퍼의 각 지노드는 데이터 변경 등에 대한 유효성 검사 등을 위해 버전 번호를 관리

• 지노드의 데이터가 변경될 때마다 지노드의 버전 번호가 증가

• 저장용으로 설계된 일반적인 파일 시스템과 달리 주키퍼에 저장되는 데이터는 모두 메모리에 저장되어, 처리량이 매우 크고 속도 또한 빠름

• 주키퍼는 좀 더 신뢰성 있는 서비스를 위해 클러스터라는 호스트 세트를 구성

• 클러스터로 구성되어 있는 주키퍼는 과반수 방식에 따라 살아 있는 노드 수가 과반수 이상 유지된다면, 지속적인 서비스가 가능

  

• 리눅스에서 zookeeper 설치를 위해 아래 명령어 순으로 진행 (AWS EC2 ubuntu 22.4에서 진행)

• root 접속 : sudo su

• apt-get update

• jdk 설치 : apt-get install openjdk-8-jdk

• zookeeper 설치 : wget http://archive.apache.org/dist/zookeeper/zookeeper-3.4.10/zookeeper-3.4.10.tar.gz

• 압축해제 : tar zxf zookeeper-3.4.10.tar.gz

• 심볼릭 링크 생성 : ln -s zookeeper-3.4.10 zookeeper

• 주키퍼는 애플리케이션에서 별도의 데이터 디렉토리를 사용하며, 이 디렉토리에는 지노드의 복사본인 스냅샷과 트랜잭션 로그들이 저장됨

  • 지노드에 변경사항이 발생하면, 이러한 변경사항은 트랜잭션 로그에 추가됨
  • 로그가 어느 정도 커지면, 현재 모든 지노드의 상태 스냅샷이 파일시슽넴에 저장
  • 이 스냅샷은 모든 이전 로그들을 대체하는 중요한 디렉토리이므로, 설치 경로와는 다른 경로로 설정하는 것이 좋다. 교재에서는 /data 경로로 설정

• data 디렉토리 생성 : mkdir -p /data

• 클러스터 내 주키퍼 노드를 구분하기 위한 ID 생성 : echo 1 > /data/myid

• 주키퍼 환경설정 파일 생성 : vi /usr/local/zookeeper/conf/zoo.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data
clientPort=2181
server.1=taejoong-zk001:2888:3888
server.2=taejoong-zk002:2888:3888
server.3=taejoong-zk003:2888:3888

• tickTime : 주키퍼가 사용하는 시간에 대한 기본 측정 단위(ms)

• initLimit : 팔로워가 리더와 초기에 연결하는 시간에 대한 타임 아웃 tick의 수

• syncLimit : 팔로워가 리더와 동기화 하는 시간에 대한 타임 아웃 tick의 수(주키퍼에 저장된 데이터가 크면 수를 늘려야 함)

• dataDir : 주키퍼의 트랜잭션 로그와 스냅샷이 저장되는 데이터 저장 경로

• clientPort : 주키퍼 사용 TCP 포트

• server.x : 주키퍼 클러스터 구성을 위한 서버 설정이며, server.myid 형식으로 사용

• 리눅스 서버를 운영하거나 애플리케이션 서비스를 운영하는 경우, 여러 종류의 프로세스들을 관리하는 방법이 필요한데, 서버가 리부팅된 경우 어떤 프로세스는 자동으로 시작되어야 하고, 어떤 프로세스는 관리자가 수동으로 시작해야 하는 경우가 있다.

• 이런 상황을 효율적으로 관리하기 위한 방법으로 여러 프로세스들을 systemd에 등록해 운영 가능하다.

• 주키퍼를 systemd에 등록하려면 먼저, 주키퍼용 systemd 파일을 생성해야 하고, 교재에서는 zookeeper-server.service라는 파일명으로 생성

• vi /etc/systemd/system/zookeeper-server.service

[Unit]
Description=zookeeper-server
After=network.target

[Service]
Type=forking
User=root
Group=root
SyslogIdentifier=zookeeper-server
WorkingDirectory=/usr/local/zookeeper
Restart=always
RestartSec=0s
ExecStart=/usr/local/zookeeper/bin/zkServer.sh start
ExecStop=/usr/local/zookeeper/bin/zkServer.sh stop

• [Unit] : 일반적인 옵션을 나타내며, 가장 많이 사용하는 옵션은 실행 순서를 조정하는 After, Before
  • Description = 해당 유닛에 대한 상세한 설명을 나타내며, 이 내용은 systemctl status 명령어에 표시
  • After : 유닛이 시작되는 순서를 조정하며 After에 지정된 유닛이 실행된 이후 시작
  • Before : 유닛이 시작되는 순서를 조정하며 Before에 지정된 유닛 이전에 실행
• [Service] : 서비스 실행과 관련된 옵션
  • Type : ExecStart에 영향을 주는 유닛 프로세스가 시작되며, simple, forking, oneshot, idle 등이 존재
  • SyslogIdentifier : syslog에서 구분하기 위한 이름
  • WorkingDirectory : 실행된 프로세스의 작업 디렉토리를 설정, 만약 설정하지 않으면 root의 디렉토리이거나 user로 실행되면 user의 홈 디렉토리가 설정
  • Restart : 이 옵션을 always로 설정한 경우 systemctl 명령어로 인한 중지를 제외하고, 프로세스가 종료된 후 ㅜ재시작
  • RestartSec : 이 옵션은 Restart 옵션과 연결되어 몇 초에 실행할지를 정함
  • ExecStart : 서비스가 시작될 때 실행할 명령어 또는 스크립트 설정
  • ExecStop : 서비스가 정지될 때 실행할 명령어 또는 스크립트 설정

리눅스 운영체제에서 systemd는 서비스를 시작, 중지, 관리등을 조정하기 위한 것.

• systemd 파일 신규 생성하거나 수정 후에는 반드시 systemd 재시작 필요 systemctl daemon-reload
• 주키퍼 시작 : systemctl start zookeeper-server.service
• 주키퍼 서비스를 서버가 부팅할 때 자동으로 실행되도록 허용 : systemctl enable zookeeper-server.service

root@ip-172-31-33-187:/usr/local# systemctl status zookeeper-server.service
● zookeeper-server.service - zookeeper-server
     Loaded: loaded (/etc/systemd/system/zookeeper-server.service; static)
     Active: active (running) since Sun 2023-04-16 06:16:07 UTC; 15min ago
   Main PID: 5112 (java)
      Tasks: 16 (limit: 1141)
     Memory: 30.2M
        CPU: 1.940s
     CGroup: /system.slice/zookeeper-server.service
             └─5112 java -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,CONSOLE -cp "/usr/local/zookeeper/bin/../build/classes:>

Apr 16 06:16:06 ip-172-31-33-187 systemd[1]: Starting zookeeper-server...
Apr 16 06:16:06 ip-172-31-33-187 zookeeper-server[5104]: ZooKeeper JMX enabled by default
Apr 16 06:16:06 ip-172-31-33-187 zookeeper-server[5104]: Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg
Apr 16 06:16:07 ip-172-31-33-187 zookeeper-server[5104]: Starting zookeeper ... STARTED
Apr 16 06:16:07 ip-172-31-33-187 systemd[1]: Started zookeeper-server.

카프카

• 카프카 클러스터는 주키퍼 클러스터와는 달리, 홀수 운영 구성이 필요 없지만, 그래도 브로커 수를 홀수로 구성하는 것이 좋다.

  주키퍼를 사용하는 자바 애플리케이션 주의 사항 : 주키퍼로 노드를 관리하는 애플리케이션들은 임시 노드를 이용해 애플리케이션의 호스트를 등록하고, 애플리케이션과 통신이 끊어지면 임시 노드에서 해당 호스트를 삭제하게 된다. 자바 기반의 애플리케이션들은 Full GC가 발생할때, 애플리케이션이 일시적으로 멈춤 상태에 빠지는데, 자바 애플리케이션의 주키퍼 세션 타임아웃 설정을 너무 짧게 설정하면 Full GC로 인해 노드가 다운된 것으로 판단해 의도치 않은 동작을 하게 될 가능성이 높으므로, 자바 애플리케이션의 GC 타임을 주기적으로 체크하는게 필요

• 카프카 설치 : wget https://archive.apache.org/dist/kafka/1.0.0/kafka_2.11-1.0.0.tgz

• 압축 해제 : tar zxf kafka_2.11-1.0.0.tgz

• 심볼릭 링크 생성 : ln -s kafka_2.11-1.0.0 kafka

• 카프카는 일반 메시지 큐 서비스들과 달리 컨슈머가 메시지를 가져가더라도 데이터를 임시로 보관

• mkdir -p /data1

• mkdir -p /data2

• 카프카 클러스터의 환경 설정을 위 이미지와 같이 하면 안되는 이유
  • 주키퍼 클러스터 내 3대의 서버들은 모두 동일한 정보를 가지고 있는데, 카프카의 환경설정 파일에서 주키퍼 정보 입력시 3대 중 임의의 하나만 입력한 경우
  • 임의의 하나의 주키퍼 서버가 다운되는 즉시, 카프카는 주키퍼 앙상블과 통신이 되지 않기 때문에, 카프카까지 장애 상황으로 이어진다.
  • zookeeper.connect=peter-zk001:2181,peter-zk002:2181,peter-zk003:2181와 같이 앙상블 내 모든 서버 이름과 포트정보를 입력하면, 주키퍼 지노드의 최상위 경로를 사용하게 된다.
  • 이렇게 최상위 경로를 사용하게 되면, 하나의 주키퍼 앙상블 세트와 하나의 애플리케이션만 사용 가능
  • 서로 다른 애플리케이션에서 동일한 지노드를 사용하게 될 경우 데이터 충돌 발생 가능성이 존재한다.
  • 위와 같은 설정으로 사용해도 되지만, 주키퍼의 최상위 경로를 사용하는 것이 아니라 지노드를 구분해서 사용해 하나의 주키퍼 앙상블 세트를 여러 개의 애플리케이션에서 공용으로 사용할 수도 있음
  • zookeeper.connect=peter-zk001:2181,peter-zk002:2181,peter-zk003:2181/peter-kafka01

카프카 브로커 서버들은 주키퍼 서버와 통신이 되어야 하는데, 방화벽으로 포트 접근이 제한된 환경에서는 주키퍼와 통신 이상 유무 확인이 필요 리눅스에서 nc(TCP, UDP를 이용해 네트워크 연결에 읽고 쓰는 네트워킹 테스트 도구)로 확인 가능하다. nc -v IP주소 Port번호 nc -v peter-zk001 2181

• 카프카 환경 설정 파일 편집 : vi /usr/local/kafka/config/server.properties

• broker.id=1

• log.dirs=/data1,data2

• zookeeper.connect=localhost:2181,172.31.47.252:2181,172.31.33.124:2181/taejoong-kafka

• 카프카 주요 옵션

  • broker.id : 브로커를 구분하기 위한 ID
  • delete.topic.enable : 토픽 삭제 기능을 on/off
  • default.replication.factor : 리플리케이션 팩터 옵션을 주지 않았을 경우의 기본값
  • min.insync.replicas : 최소 리플리케이션 팩터
  • auto.create.topics.enable : 존재하지 않는 토픽으로 퍼블리셔가 메시지를 보냈을 때 자동으로 토픽 생성
  • offsets.topic.num.partitions : offsets 토픽의 파티션 수
  • offsets.topic.replication.factor : offsets 토픽의 리플리케이션 팩터
  • compression.type : 토픽의 최종 압축형태. gzip, snappy, lz4
  • log.dirs : 로그가 저장되는 위치
  • num.partitions : 파티션 수 옵션을 주지 않았을 경우 기본값
  • log.retention.hours : 저장된 로그의 보관 주기
  • log.segment.bytes : 저장되는 로그 파일 하나의 크기
  • log.retention.check.interval.ms : 로그 보관주기 체크 시간
  • message.max.bytes : 카프카에서 허용하는 가장 큰 메시지 크기
  • zookeeper.connect : 주키퍼 접속 정보
  • zookeeper.session.timeout.ms : 브로커와 주키퍼 수ㅏ이의 최대 연결 대기 시간. 해당 시간 동안 주키퍼와 연결 되지 않으면 타임아웃 발생
  • unclean.leader.election.enable : ISR 그룹에 포함되지 않은 마지막 리플리카를 리더로 인정
  • log.flush.interval.ms : 메시지가 디스크로 플러시되기 전 메모리에 유지하는 시간
  • log.flush.interval.messages : 메시지가 디스크로 플러시되기 전 누적 메시지 수

• 교재대로 3개 서버로 하려고했지만, EC2 t2.micro에서는 메모리가 부족해 OOM이 발생함

• 맥 기준으로 아래 링크를 바탕으로 진행하면 정상적으로 topic producing, consuming 정상 진행되는 것을 확인 https://velog.io/@kimview/MacOS-kafka-%EC%84%A4%EC%B9%98