Kafka - Githubissues

https://github.com/onlybooks/kafka

카프카의 특징

멀티 프로듀서, 멀티 컨슈머

카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조
디스크에 메세지 저장
- 카프카는 컨슈머가 메세지를 읽어가더라도 정해져 있는 보관 주기 동안 디스크에 메세지를 저장해둡니다.
  확장성
- 하나의 카프카 클러스터는 3대의 브로커로 시작해 수십 대의 브로커로 확장 가능하다. 확장작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다. (책 6장)
  높은 성능

카프카 용어 정리

카프카 : 아파치 프로젝트 애플리케이션 이름. 클러스터 구성이 가능하며, 카프카 클러스터라고 부름
브로커: 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말함
토픽: 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용.
파티션: 병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메세지 처리를 위해 파티션의 수를 늘려줄 수 있다.
프로듀서: 메세지를 생산. 브로커의 토픽이름으로 보내는 서버
컨슈머: 브로커의 토픽이름으로 저장된 메세지를 가져가는 서버

주키퍼

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

https://zookeeper.apache.org/doc/current/zookeeperOver.html

분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은후 상태정보 등을 주고받게된다.

상태 정보들은 주키퍼의 지노드(znode)라 불리는 곳에 키-값 형태로 저장하고 지노드에 키-값이 저장된 것을 이용하여 애플리케이션들은 서로 데이터를 주고받게된다. 지노드는 데이터를 저장하는 공간, 일반컴퓨터 파일이나 폴더개념 이라고 보면된다. 지노드에 저장하는 데이터 크키는 byte, 킬로바이트 매우 작음

주키퍼는 과반수로 유지되어야 서비스 가능하다. 주키퍼 앙상블 5대로 구성했을때 2대 노드까지 다운되더라도 (과반수는 3) 살아있는 노드의 수가 과반수이므로 끊김없는 서비스가 가능하다.

카프카 디자인

분산시스템
페이지 캐시
배치 전송 처리
- 작은 메세지들을 한꺼번에 묶어서 한번에 보내게 되어 네트워크 왕복을 줄이게된다.

카프카 데이터 모델

토픽을 메일주소라고 이해하면 쉽다

적절한 파티션 수?

프로듀서 입장에서 4개의 프로듀서를 통해 각각 초당 10개의 메세지를 카프카 토픽으로 보낸다고 하면, 카프카의 토픽에서 초당 40개의 메세지 를 받아줘야한다. 토픽에서 파티션을 1로 했을 때 초당 10개의 메세지만 받아준다면 파티션을 4로 늘려서 목표 처리량을 처리할 수 있도록 변경해야한다. 하지만 카프카에서는 컨슈머도 있기 때문에 컨슈머 입장에서 8개의 컨슈머를 통해 초당 5개의 메시지를 카프카 토픽에서 가져올 수 있다고 하면 토픽의 파티션 수는 컨슈머와 동일하게 8개로 맞추어 컨슈머마다 각각 파티션에 접근 할 수 있게 해야한다.

	서버수	서버당 메세지 전송 수	합계	필요 파티션 수
프로듀서	4	10 메세지 / 초	40 메세지/ 초	4
컨슈머	8	5 메세지 / 초	40 메세지 / 초	8

오프셋과 메세지 순서

카프카에서는 각 파티션마다 메세지가 저장되는 위치를 오프셋이라고 부른다. 오프셋은 파티션 내에 유일하고 순차적으로 증가하는 숫자 형태로 되어있다. https://kafka.apache.org/documentation/#intro_topics

토픽을 총 3개의 파티션으로 나눈 그림이다. 쓰기의 의미는 프로듀서가 메세지를 보내면 메세지가 각 파티션 별로 분산되어 저장하는 상태를 나타낸다. 파티션에는 프로듀서가 전송한 메세지가 저장되어있다. 저장된 위치를 유니크하고 순차적인 숫자 형태인 0,1,2같은 형태로 나타내고있다. 이러한 숫자는 파티션마다 유니크한 값을 가지며 카프카에서 이를 오프셋이라고 부른다. 오프셋은 하나의 파티션 내에서만 유일한 숫자이다.

카프카 리플리케이션

리플리케이션 팩터 기본값은 1로 설정되어있으며, default.replication.factor 값 수정가능하다.

$ vi /usr/local/kafka/config/server.properties
$ cat /usr/local/kafka/config/server.log

카프카의 리플리케이션은 토픽이 아니라, 토픽을 이루는 각각의 파티션을 리플리케이션하는 것.

ex) peter라는 토픽 리플리케이션 팩터2, 파티션 1

$ /usr/local/kafka/bin/kafka-topics.sh \ --zookeeper peter-zk001:2181,peter-zk002:2181,peter-zk003:2181/peter-kafak \
--topic peter --partition 1, --replication-factor 2 --create 
$ /usr/local/kafka/bin/kafka-topics.sh \ --zookeeper peter-zk001:2181,peter-zk002:2181,peter-zk003:2181/peter-kafak \
--topic peter --describe

ISR

브로커에 장애가 일어나면 리더와 팔로워 선출과정과 동기화작업을 진행하게됨

$ vi /usr/local/kafka/config/server.properties

unclean.leader.election.enable 항목을 찾아 false 이면 메세지 손질이 일어나지않게 장애가 나더라도 기존 리더가 살아나도록 기다리는방법 true 이면 메세지 손실이 일어나더라도 빠른복구를 위해 팔로워를 리더로 선출함

주키퍼 지노드

주키퍼의 CLI 에 접근하는 방법은 zkCli.sh를 실행하면 된다.

$ /usr/local/zookeeper/bin/zkCli.sh
$ ls /peter-kafka/brokers/topics/peter-topic <- 토픽정보들을 확인할 수 있다.

Mvitimin / Microservices_study

Kafka #11