카프카 설치 및 실습
mac을 기준으로 작성하였으며, 1 broker, 1 topic 이라는 아주 기본적인 로컬 환경으로 구성해서 테스트 하였다.
1. 설치 및 실행
아래 사이트에서 Binary downloads에 있는 파일을 다운 받고, 다운로드 받은 파일은 적절한 위치에 압축을 풀어준다.
https://kafka.apache.org/downloads
tar -xzf kafka_2.11-2.3.0.tgz
Kafka는 zookeeper 위에서 돌아가므로 zookeeper를 먼저 실행한다.
bin/zookeeper-server-start.sh config/zookeeper.properties
다음은 kafka를 실행한다.
bin/kafka-server-start.sh config/server.properties
아래와 같이 카프카와 주키퍼가 정상적으로 실행되었는지 port 확인을 통해서 확인한다. (LISTEN 인지 확인)
lsof -i :9092
lsof -i :2181
2. Topic 생성하기
localhost:9092 카프카 서버에 quickstart-events란 토픽을 생성한다.
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic quickstart-events
- create : 새로운 토픽을 만들 때 사용하는 옵션
- replication-factor : partition 복제본 개수
- 옵션을 사용하지 않으면 기본값을 사용한다.
- 기본값은 server.properties 파일에서 default.replication.factor 항목으로 설정 가능하다.
- partitions : Topic이 생성되거나 변경될 때의 Partition 수
- 이 옵션을 사용하지 않으면, 기본값을 사용한다.
- 기본 값은 server.properties 파일에서 num.partitons 항목으로 설정 가능하다.
- topic : create, alter, describe, delete 옵션에 사용할 토픽 이름
현재 만들어져 있는 토픽은 아래와 같이 확인 가능하다.
bin/kafka-topics.sh --list --bootstrap-server localhost:9092
특정 토픽의 설정은 아래와 같이 확인 할 수 있다.
bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092
3. Consumer, Producer 실행하기
콘솔에서 Producer와 Consumer를 실행하여 실시간으로 토픽에 event를 추가하고
받을 수 있다.
터미널을 분할로 띄워서 진행해본다.
Consumer를 실행한다.
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic quickstart-events
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic quickstart-events --from-beginning
--from-beginning 옵션을 뒤에 추가하면 토픽에 있는 모든 레코드를 확인 할수 있다.
Producer를 실행한다.
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic quickstart-events
4. 파티션 수에 따른 메시지 순서에 대한 이해
이번 내용은 카프카를 이해하는데 한참 걸렸던 메시지 순서에 대한 내용을 살펴보자.
메시지 순서에 대한 이해를 위해 파티션 수를 4개 생성하여 메시지 순서를 확인해보자.
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 4 --topic quickstart-events
이해하기 쉽게 문자가 아닌 1부터 8까지 숫자로 메시지를 보내보고 순서를 확인해보자.
1,2,3,4,5,6,7,8 순서대로 Producer로 메시지를 전송하게 되면 예상과는 다르게
순서대로 숫자를 가져오지 못한다.
이를 이해하기 위해 파티션 갯수 1인 경우를 살펴보자.
위 그림은 파티션에 데이터 1, 2가 순서대로 들어갔고, 컨슈머를 이용해서 해당 파티션의 첫번째 데이터인 1을 가져왔다.
다음으로, 파티션에는 데이터 3, 4가 순서대로 들어갔고, 컨슈머는 파티션의 이후 데이터인 2, 3을 가져왔다. 이후 컨슈머가 가져오는 데이터는 4라는 것을 예상할 수 있다.
위의 예제에서 알 수 있듯이 하나의 파티션에 대해서 데이터의 순서를 보장한다. 만약 토픽에
대해 모든 데이터의 순서를 보장 받고 싶다면, 토픽을 생성할 때 파티션의 수는 1로 생성하면 된다.
그럼 이제 파티션의 수가 1이 아닌 4인 경우를 살펴보자.
위의 예제는 토픽의 파티션이 4개이고, 각각의 파티션 마다 첫번째 데이터가 1,2,3 하나씩 데이터가 들어갔다.
컨슈머는 각각의 파티션으로부터 데이터를 하나씩을 가져오게 되고, 순서는 1,3,2 순으로 가져왔다.
컨슈머는 각각의 파티션에서 첫번째 데이터를 가져올 뿐이지 순서를 맞춰서 가져오지는 않는다.
아래 그림을 통해 더 진행해보자.
이후 해당 토픽에 데이터 4,5,6이 들어오고, 그 데이터는 파티션 4의 첫번째,
파티션 2와 3의 두번째에 들어왔다.
컨슈머는 이후 데이터 즉 4,5,6 에 대해서도 가져오게 된다. 하지만 역시
순서대로 가져오지 않는다.
메시지를 가져오는 순서에 대해 파티션 2번으로
추가 설명해보면, 2번 파티션의 첫번째 데이터가 2, 두번째 데이터가 5이다.
이런 경우에 파티션 2는 앞서 설명한것 처럼 파티션 1인 경우와 동일하게
두번째 데이터 5가 첫번째 데이터 2 앞으로 올 수 없다.
마찬가지로 6도 3보다 앞에 올 수 없다.
즉, 파티션이 4개를 사용하는 경우에는 전체 순서는 보장을 못하지만
각각의 파티션에 담긴 메시지 순서는 보장한다.
파티션 2번의 5는 2보다 뒤에 온다.
파티션 3번의 6은 3보다 뒤에 온다.
앞의 내용을 정리해보자.
카프카는 각각의 파티션에 대해서만 순서를 보장한다. 그래서,
위의 천번째 예제에서 살펴본 것처럼 1개의 파티션인 경우에는 프로듀서가
보낸 순서대로 가져올 수 있지만, 파티션이 4개인 경우에는 프로듀서가
보낸 순서대로 메시지를 가져올수 없었다.
Kafkacat
카프카를 사용하는 개발자라면 로컬 혹은 서버에서 브로커와 직접 통신하여 테스트 해야 하는 경우가 있다. 이 때 명령어 한 줄로 편리하게 쓸 수 있는 도구인 Kafkacat을 사용 할 수 있다.
개발 단계에서 처음 토픽을 생성하고 메시지를 발행했을 때, 토픽에 전송된 메시지를 Consume 하지 않으면 정상적으로 값이 들어갔는지 확인 할 수 없다. 이때 메시지를 전송하고 토픽에 있는 메시지를 확인할 때 유용하다.
설치
설치하는 방법은 여러 방식이 있지만 여기서는 mac 기준으로 설치하면 아래와 같이 가능하다.
brew install kafkacat
사용 방법
사용방법은 아래와 같다.
kcat -b localhost:9092 -t new_topic -G [group_name] -p [partition_num] [-P|-C]
- -b : 카프카 브로커 주소 목록
- -t : 토픽
- -p : 파티션
- -P : 프로듀서 모드로 실행. 기본 파티션은 0이다.
- -C : 컨슈머 모드로 실행. -P, -C가 생략될 경우 기본 컨슈머 모드로 실행한다.
- -G : 컨슈머 그룹
먼저 kafka의 정보를 확인해 보자. -L 을 이용하면 메타데이터 정보를 확인 할 수 있다.
kcat -L -b localhost:9092
Output
$ kcat -L -b localhost:9092
Metadata for all topics (from broker 0: localhost:9092/0):
1 brokers:
broker 0 at localhost:9092 (controller)
1 topics:
topic "quickstart-events" with 1 partitions:
partition 0, leader 0, replicas: 0, isrs: 0
위와 같이 1개의 broker 서버와 1개의 토픽이 있는 걸 확인 할 수 있다.
또한, 토픽에 대해서 컨슈머와 프로듀서를 테스트 및 모니터링 할 수 있다.
파티션을 명시하지 않으면 모든 파티션으로 부터 메시지를 읽는다.
kcat -b localhost:9092 -t quickstart-events -C
Output
아래와 같이 몇번 파티션으로 부터 메시지를 읽었는지와
각 파티션에서의 offset을 확인 할 수 있다.
$ kcat -b localhost:9092 -t quickstart-events -C
hi
% Reached end of topic new_topic [0] at offset 4
success
토픽에 대한 메타정보도 아래와 같이 확인 해보자.
kcat -b localhost:9092 -L -t quickstart-events
다음은 메시지를 전송하는 예시이다. text.txt파일에 데이터를 저장하고 이 데이터를 토픽으로 전송한다.
kcat -b $BROKERS -t $TOPIC -P -l ~/dev/text.txt
카프카 인증
카프카 인증을 처리하는 방식은 ssl 방식과 sasl 방식으로 크게 2가지 방식이 있다.
ssl 방식을 적용할 경우 클라이언트에서 메시지가 암호화되어 전달된다. 이 암호화된 메시지는 브로커에서 다시 복호화가 되는데, 이때 CPU 부하가 발생하게 된다. 메시지 암호화가 필수적인 파이프라인이라면 인증과 함께 고려해 볼수 있다.
sasl(Simple Authentication and Security Layer)은 어플리케이션 프로토콜로 부터
인증 처리를 위한 별도의 층(Layer)를 분리하고, 그 층에서 인증을
처리하는 방식이다.
그리고 기본적으로 메시지 암호화를 하지 않기 때문에 추가적인 부하가 발생하지 않는다.(추가로 SSL을 적용 할 수 있다)
카프카 연결시 id/pw를 묻는 절차가 추가 된 버전이라고 보면 되며, 클라이언트와 카프카가 처음 연결 할 때 인증을 위한 단계(Layer)를 거친 후에 메시지 요청을 실행하게 된다. 따라서 처음에 인증을 거치면 이후에 어플리케이션 단에서 인증을 처리하지 않아도 된다.
위 그림에서 볼 수 있는 것 처럼 sasl 프레임워크는 다양한 메커니즘으로 인증을 처리할 수 있다. 카프카에서 기본적으로 제공하는 sasl 메커니즘은 다음 4가지가 있다.
- PLAIN : 문자열 아이디/패스워드를 이용한 인증
- SCRAM : Salt 등을 이용한 SCRAM 방식을 이용한 인증
- OAUTHBEARER : OAuth2 방식을 이용한 인증
- GSSAPI : Kerberos를 이용한 인증
sasl 인증을 해야 하는 경우 아래와 같이 인증방식과 id, pw를 추가로 입력하면 된다.
kcat -b $BROKERS -C -X security.protocol=SASL_PLAINTEXT -X sasl.mechanisms=SCRAM-SHA-256 -X sasl.username=$USERNAME -X sasl.password=$PASSWORD -t $TOPIC
Reference
https://always-kimkim.tistory.com/entry/kafka101-security
https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-%EC%B2%98%EC%9D%8C-%EC%A0%91%ED%95%98%EB%8A%94-kafka/
https://ooeunz.tistory.com/117
https://soft.plusblog.co.kr/30
https://github.com/edenhill/kafkacat
https://kafka.apache.org/documentation/#quickstart