What is Apache Kafka
Apache Kafka is distributed publish-subscribe messaging system.
ex) like YouTube
Publish-subscribe system에서 메시지들은 어딘가에는 저장이 되어야 합니다.
또 Publisher는 메시지를 보낼 곳이 필요하고, subscriber는 메시지를 읽어올 곳이 필요하겠죠.
Apache Kafka에서는 Broker라는 것이 이 세 가지 역할을 모두 담당합니다.
Publisher의 역할은 Producer가 하며, Producer는 Broker에 메시지를 생산합니다.
Subscriber의 역할은 Consumer가 하며, Consumer는 Broker에 있는 메시지를 소비합니다.
가장 흥미로운 점은 모든 각각의 서버들은 여러 개의 Broker를 독립적으로 실행시킬 수 있으며, 하나의 컴퓨터에서 Kafka cluster를 만들 수도 있다는 것입니다. 이것이 바로 Kafka Broker입니다.
Kafka Broker는 단순히 하드 드라이브에 파일의 형태로 메시지들을 저장하고, Producer는 그 파일들에 메시지들을 추가하고, Consumer는 그 파일들로부터 읽어올 수 있다는 것입니다. 이게 끝입니다.
다음 그림처럼, 여러개의 producer와 consumer가 있는 것도 가능합니다. Producer들은 동시에 메시지를 kafka broker에 생산해줄 수 있고, consumer들은 동시에 kafka broker로부터 메시지를 읽어올 수 있습니다.
그런데 이 그림에는 한 가지 약점이 있습니다. 바로 broker입니다.
만약 이 broker가 역할 수행에 실패하면, producer와 consumer에 역할을 수행할 것들이 아무도 없게 됩니다.
그래서 아무도 저렇게 하나의 broker로만 apache kafka를 실행시키진 않고, 이를 대신해서 broker cluster라는 것이 생기게 되었습니다.
Broker & Broker Cluster
클러스터(Cluster)는 '무리', '군집'을 뜻하며, 경제/산업 분야에서는 유사 기업, 기관들이 모여 시너지 효과를 내는 지리적 집적지(산업 클러스터)를, IT 분야에서는 여러 대의 컴퓨터가 하나의 시스템처럼 작동하는 군집(컴퓨터 클러스터)을 의미하며, 저장장치에서는 파일 저장의 논리적 단위를 뜻하는 등 맥락에 따라 다양하게 쓰이는 용어입니다.
우리는 몇 개의 서버만 가지는 cluster를 만들 수도 있고, 수천 개의 서버를 가지는 cluster를 만들 수도 있습니다. 링크드인이나 넷플릭스같은 회사들은 이렇게 거대한 Kafka cluster를 가지고 있습니다.
그림처럼 kafka cluster가 있을 때, 다수의 producer & consumer들은 cluster 내의 서로 다른 broker들과 상호작용할 수 있습니다.
즉 각 producer들은 서로 다른 broker들에 메시지를 보낼 수 있고, 각 broker들은 메시지의 일부분들을 저장할 것입니다. 이 말은 producer에서 보낸 모든 메시지들이 여러개의 서버로 퍼트려진다는 뜻입니다.
반대로, consumer들은 서로 다른 broker들에서 메시지를 읽어올 수 있습니다.
또한, 만약 kafka cluster 내의 broker 하나가 고장이 나도, 다른 broker들이 일을 대신 맡아줄 겁니다.
만약 kafka cluster 내에 수백개의 broker들이 있다면? 어떻게 서로 동기화가 될까요? 어떻게 서로 소통하고 어떻게 일이 분배될까요? -> *Zookeeper*
Quorum: 최소 서버 개수, 예를 들면 2개, 동작하는 cluster 구성을 위한. Quorum보다 적으면 서버가 다운된다! 그래서 최소 3개는 둬야 하나가 다운돼도 나머지 둘이서 잘 돌아갈 수가 있다.
Kafka Topic
모든 메시지는 순차적으로 저장되며 iterable하다.
Broker는 MQ에서 7일(168시간)이 지난 메시지를 전부 지울 수 있다. Default log retention period가 168시간이기 때문이다.
Message structure
tiemstamp: kafka broker 또는 producer가 부여한다.
offset number: Topic내의 offset number는 모두 유일 해야한다. 즉 partition 사이에서의 offset number도 유일하다.
각 메시지는 key(optional)와 value를 갖는다.
같은 key를 같는 메시지는 같은 partition으로 보내진다.
Topics and Partitions
한 topic이 여러 broker에 저장되는 이유: fault tolerance
한 토픽이 여러 파티션으로 나뉘고 여러 브로커에 결쳐있어야 한 번에 여러개 쓰고 읽기가 빨라진다.
Spreading messages across partitions
한 topic은 여러 partition으로 나뉠 수 있다. 이 partition들은 여러 broker에 걸쳐 퍼져있다. partition 내 각각의 메시지들은 고유 offset번호를 갖는다. offset 번호는 항상 0부터 시작한다.
topic 내의 메시지들은 n차례 복제될 수 있다. 그 복제본들은 서로 다른 broker에 저장된다. 그래서 하나의 broker가 고장나면 다른 broker에 있는 똑같은 메시지를 consumer에게 줄 수 있다.
Partition Leader and Followers
replication factor: partition(즉, 메시지)을 복제할 횟수
Controller and it's responsibilities
controller의 역할: partition으로 쪼개기, partition을 broker들에 분배하기, 죽은 broker 생기면 partition 재분배하기, leader partition 선출하기
broker 중 여러개의 controller가 있고, 그 중 active controller는 딱 하나이다. 이것이 Raft Leader임.
How Producers write messages to the topic
How Consumers read messages from the topic
