본문 바로가기

개발/Backend

[kafka] Kafka란

Kafka

우리는 많은 정보들을 데이터베이스에 저장하고 있습니다. 데이터베이스에 저장되는 정보들은 대부분 유저와 같이 어떠한 것(thing)들입니다. 이런 것(thing)들은 어떠한 상태를 가지게 되는데, 이것들도 데이터베이스에서 저장되었습니다. 그러니깐 상태가 변경되는 이벤트의 발생보다는 객체 자체를 우선시 하여 생각한 것이죠.

 

그러다 객체를 먼저 생각하는 것보다 이벤트가 발생하는 것을 우선시하는 것이 낫다고 생각을 하게 되었습니다. 이벤트는 어떤 일이 일어났는지에 대한 설명과 같은 상태를 가지게 되는데요. 이벤트는 객체에 어떤 일이 일어났는지에 대한 시간의 표시입니다. 영상에서는 이런 이벤트를 데이터베이스에 저장하기에는 조금 성가시다고 표현하고 있습니다. 그래서 로그라는 구조를 이용해보기로 합니다.

로그는 이벤트가 일어난 순서대로 정렬된 것입니다. 로그에는 상태나 description과 같은 것들을 쓰는데, 생각하기도 쉬운 구조이고 스케일하기도 쉽습니다.

아파치 카프카는 위의 로그를 관리하기 위한 시스템이구요. 카프카에서는 로그 대신 topic 이라는 용어를 사용합니다.

topic은 내구성(durable) 있게 저장된 정렬된 이벤트 모음입니다. 여기서의 내구성(durable)은 디스크에 저장되어 여러 곳에 복제되어 오류가 발생하지 않게 한다는 의미입니다. topic은 몇시간과 같이 짧게도, 몇 년이나 무기한으로 길게도 데이터를 저장할 수 있습니다.

 

각각의 이벤트는 사용자가 배송지 주소를 바꾸는 것과 같은 비즈니스 단에서 발생할 수 있습니다. 이런 thing의 이벤트는 topic에 저장될 수 있고, 카프카는 우리가 이벤트를 먼저 생각한 다음 thing을 생각하게 합니다.

 

데이터베이스가 세계를 지배하던 때에는 하나의 큰 모놀리틱 서비스로 만드는 것이 대부분이었지만 한계가 발생하면서 각각의 작은 서비스로 쪼갤 수 있게 되었습니다.

각각의 작은 서비스들은 카프카 topic을 통해 소통할 수 있는데요, 카프카 topic을 consume할 수 있고, consume 한 후에는 어떤 연산이 일어난 후 또 다른 topic으로 message를 produce할 수 있습니다.

실시간 분석을 할 수 있는 새로운 서비스를 구축할 수 있고, 이벤트가 일어나는 즉시 실행하여 처리해줄 수 았습니다. 카프카는 이런 분산된 로그 항목들입니다.

 

카프카의 구성요소 및 특징

topic, partition

카프카의 topic은 partition이라는 단위로 쪼개어집니다. 이런 partition 단위로 각 서버들에 분산되어 저장됩니다. 고가용성을 위하여 복제 설정을 하는 경우에도 partition 단위로 분산되어 복제되고 partition 단위로 복구됩니다. 한번 늘린 partition은 절대 줄일 수 없기 때문에 운영 중에 늘리는 것은 충분히 고려해야 합니다. partition을 늘렸을 때 메시지는 round-robin 방식으로 쓰여집니다.

 

producer, comsumer

producer는 메시지를 만들고 topic에 메시지를 씁니다. producer는 comsumer의 존재를 알지 못합니다. comsumer는 원하는 topic을 구독하는 경우 해당 topic의 메시지를 소비할 수 있습니다. 매번 메시지를 소비할 때마다 마지막으로 소비한 위치(offset)를 기억해서 해서, 혹시라도 죽었다 살아나는 경우 마지막 위치부터 다시 읽을 수 있습니다.

 

consumer group

comsumer 그룹은 말 그대로 comsumer들의 집합입니다. 하나의 topic을 파티션별로 할당받아 메시지를 처리합니다. 따라서 메시지는 comsumer 그룹 내의 어떤 comsumer에 의해서든지 단 한번만 처리됩니다. comsumer 그룹 내 하나의 comsumer가 다운된다면 rebalance 된 상황이라 하는데 파티션 재조정을 하여 다른 comsumer가 다운된 partition의 소비를 맡아서 하게 됩니다.

partition을 늘릴 때에는 comsumer의 개수도 고려하도록 합니다. 보통은 개수를 같이 맞춰주는 것을 권장하지만 메시지가 쌓이는 속도보다 처리하는 속도가 빠르다면 partition 개수가 comsumer 개수보다 크거나 같게 해주는 것도 나쁘지 않습니다.

 

broker, zookeeper

브로커는 카프카의 서버를 의미합니다. 동일한 노드 내에서 여러 개의 broker서버를 띄울 수도 있습니다. zookeeper는 분산 메세지 큐의 정보를 관리해 주는 역할을 합니다. kafka를 띄우기 위해서는 zookeeper가 반드시 실행되어야 합니다.

 

replication

카프카에서는 replication 수를 지정하여 topic를 만들 수 있습니다. replication-factor 를 3으로 지정하면 replication 수가 3이 됩니다. 3개의 broker가 있고 3개의 topic이 있는 경우, broker 3대에서 하나의 서버만 leader가 되고 나머지 둘은 follower 가 됩니다. producer가 메세지를 쓰고, consumer가 메세지를 읽는 건 오로지 leader가 전적으로 역할을 담당합니다. 메시지의 유실이 없다는 장점은 있으나 복제를 위한 시간과 네트워크가 소비되는데, 이럴 때에는 데이터의 중요도에 따라 세부설정을 할 수 있습니다.

 

 

 

출처

- https://www.youtube.com/watch?v=FKgi3n-FyNU