[Kafka] 아파치 카프카 애플리케이션 2장

카프카 시작해보기

 

대부분의 것은 책을 참조하길 바람. 기억하고 싶은 것 위주로 넣었음

 

주키퍼, 카프카 브로커 실행

카프카 바이너리 패키지를 다운로드 (링크: https://kafka.apache.org/downloads)

 

카프카 브로커 힙 메모리 설정

• 카프카 브로커를 실행하기 위해 힙 메모리 설정이 필요함
• 브로커는 레코드의 내용은 페이지 캐시로 시스템 메모리를 사용하고 나머지 객체들을 힙 메모리에 저장하여 사용
• 힙 메모리는 5GB 이상으로 설정하지 않음
• 카프카 패키지 기본 설정으로 브로커 1GB, 주키퍼 512MB로 설정되어있음
• KAFKA_HEAP_OPTS 를 exports하여 사용하면 힙 메모리 조정 가능
  • export KAFKA_HEAP_OPTS ="-Xmx400m -Xms400m"
    • 브로커 메모리를 400MB로 만드는 것
  • echo $KAFKA_HEAP_OPTS
• 주키퍼 메모리 조정 방법
  • zookeeper-env.sh 내부 JVMFLAGS="-Xmx200m -Xms200m"로 관리
• 계속 사용하기 위해서는 ~/.bashrc 파일에 넣으면 됨

 

주키퍼 실행

• 분산 코디네이션 서비스를 제공하는 주키퍼는 카프카의 클러스터 설정 리더 정보, 컨트롤러 정보를 담고 있어 카프카를 실행하는 데에 필요한 필수 애플리케이션임
  • 1대만 실행하는 주키퍼 "quick-and-dirty single node"
  • 테스트 목적으로만 쓰자.

카프카 브로커 실행 및 로그 확인

• -daemon 옵션과 함께 카프카 브로커를 백그라운드 모드로 실행 가능
• tail 명령어를 통해 로그 확인 가능

---

카프카 커맨드 라인 툴

kafka-topics.sh

• 토픽 관련된 명령 실행 가능
• 토픽 = 카프카에서 데이터를 구분하는 가장 기본적인 개념
  • = RDBMS의 테이블과 유사
• 카프카 클러스터에 토픽은 여러 개 존재할 수 있음
• 토픽에는 파티션이 존재함
  • 파티션의 개수는 최소 1개부터 시작
  • 파티션 = 토픽을 구성하는 데에 아주 중요한 요소다.
  • 파티션을 통해 한 번에 처리할 수 있는 데이터양을 늘릴 수 있고
    토픽 내부에서도 파티션을 통해 데이터의 종류를 나누어 처리할 수 있음

토픽 생성

• 토픽 생성 (내 책 69p - 원본 책 46p 참조) (그 중 내가 흥미로운 것들만 기록)
  • --create (토픽 생성 명령)
  • --partitions (파티션 개수)
  • --replication-factor (복제 개수)
    • 2라면 1개의 복제본을 사용하겠다는 뜻
    • 1이라면 복제본 사용안한다는 뜻
  • --config retention.ms=172800000 (토픽 데이터 유지 기간 옵션)

토픽 리스트 조회

• --list

토픽 상세 조회

• --describe
  • 파티션 개수, 브로커 번호, 리더가 어디에 존재 (ex. Leader 0 -> 0번 브로커에 위치)

토픽 옵션 수정

• kafka-topics.sh -> 파티션 개수 변경
• kafka-configs.sh -> 리텐션 기간 변경
• --alter
• 파티션 수는 늘릴 수 있지만 줄일 수는 없음

 

kafka-console-producer.sh

• 토픽에 넣는 데이터 = 레코드
  • 메시지 키와 메시지 값으로 이루어짐
• UTF-8 기반 Byte로 변환 & ByteArraySerializer로만 직렬화됨
• String이 아닌 타입으로는 직렬화하여 전송할 수 없음
• 다른 타입으로 직렬화하고 싶으면 애플리케이션 직접 개발해야 함
• parse.key=true로 하면 key 설정 가능, key.separator 로 구분자 설정
  • 구분자 설정 안하면 tab임 \t
• 메시지 키가 null인 경우, 파티션 전송 시 레코드 배치 단위로 라운드로빈으로 전송함
• 메시지 키가 존재하는 경우에는 키의 해시값을 ㅈ가성해 존재하는 파티션 중 한 개에 할당됨
• 메시지 키가 동일하면 동일한 파티션으로 전송됨
  • 프로듀서에 설정된 파티셔너에 의해 이런 메시지 키와 파티션 할당이 결정
• 커스텀 파티셔너의 경우에는 파티션 할당이 다르게 동작할 수도 있음

메시지 키를 가진 레코드의 경우 파티션이 추가되면 파티션과 메시지 키의 일관성이 보장되지 않음
이전 메시지 키가 파티션 0번에 들어갔었다면 파티션 늘린 뒤에는 파티션 0번으로 간다는 보장이 없음
파티션 추가하더라도 메시지 키의 일관성을 보장하고 싶다면 커스텀 파티셔너를 만들어야 함

 

kafka-console-consumer.sh

• --from-beginning 옵션을 주면 토픽에 저장된 가장 처음 데이터부터 출력
• --property 메시지 키와 메시지 값을 보고 싶을 때
• --group 옵션으로 컨슈머 그룹을 생성함
  • 컨슈머 그룹은 1개 이상의 컨슈머로 이루어져 있음
  • 이 컨슈머 그룹을 통해 가져간 토픽의 메시지는 가지간 메시지에 대해 커밋을 한다.
  • 커밋이란 컨슈머가 특정 레코드까지 처리 완료했다고 레코드의 오프셋 번호를 카프카 브로커에 저장하는 것
  • 커밋 정보는 __consumer_offsets 이름의 내부 토픽에 저장됨
• 토픽에 넣은 순서대로 가져가는 것은 아님 해당 명령어로 하면 모든 파티션으로부터 동일한 중요도로 데이터를 가져가기 때문
• 순서 보장하고 싶으면 파티션 1개로 구성된 토픽을 만드는 것
• 한 개의 파티션에서는 데이터 순서를 보장하기 때문



kafka-consumer-groups.sh

• 컨슈머 그룹은 따로 생성하는 명령 안 날리고 컨슈머 동작할 때 그룹 이름 지정하면 새로 생성됨
• --list 컨슈머 그룹 리스트 확인
• --describe 컨슈머 그룹 상세 확인
• 컨슈머 그룹 중복이나 랙 확인에 사용됨

 

kafka-verifiable-producer.sh &kafka-verifiable-consumer.sh

• kafka-verifiable 로 시작하는 2개의 스크립트를 사용하면 String 타입 메시지 값을 코드 없이 주고 받을 수 있음
• 카프카 클러스터 설치 완료 이후에 토픽에 데이터를 전송해 통신 테스트를 할 때 유리
• kafka-verifiable-consumer.sh 로 전송한 데이터 확인가능

 

kafka-delete-records.sh

• 이미 적재된 토픽의 데이터를 지우는 방법
• 가장 오래된 데이터부터 특정 시점 오프셋까지 삭제가능
• 삭제하고자 하는 데이터에 대한 정보를 파일로 저장해서 사용해야 함