[Kafka] 카프카 개념 정리

카프카 Kafka

https://kafka.apache.org/

Apache Kafka는 이벤트 기반 분산 시스템으로, 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합을 위해 사용하는 오픈 소스 스트리밍 플랫폼이다.

 

카프카는 여러 메세지 큐를 기반으로된 분산 시스템이므로, 수평 확장이 가능한 구조이다.

서버의 규모에 따라 브로커, 파티션, 컨슈머를 늘려가며 유연하게 확장할 수 있다.

 

또한, 배치Batch전송이 가능한데, 여기서 배치 전송은 원하는 일정 크기를 묶어서 보내고, 묶어서 받는 구조이다.

 

전송할 자료가 10개가 있다면, 10개를 모두 일일이 보내는 10개의 전송이 이루어지는 방식보다, 한 번에 받기 때문에 처리량이 훨씬 좋다.

 

 

---

 

구조

1.  프로듀서 Producer

Kafka에게 메세지를 만들어서 전송한다.

 

2. 컨슈머 Consumer

Kafka로부터 메세지를 받아서 이용한다.

 

3. 카프카 클러스터 Kafka Cluster

프로듀서와 컨슈머 사이에서 메세지 브로커 역할을 한다. 클러스터 내에 있는 브로커들은 각각 하나의 서버이다.

 

4. 주키퍼 클러스터 Zookeper Cluster  (앙상블)

카프카 클러스터를 관리한다. 카프카의 메타데이터를 갖고 있다.

 

5. 토픽 Topic

메세지를 구분하는 단위이다. 어떤 종류의 메세지인지 파악하는 용도이다. 파일 시스템의 폴더라고 생각하면 되겠다.

토픽 내에는 1개 이상의 파티션이 존재한다.

 

6. 파티션 Partition

토픽 내에 존재하며, 토픽 내에 여러 파티션이 존재할 수 있다. 메세지를 저장하는 물리적인 파일을 의미한다. 파일 시스템의 파일이라고 생각하면 되겠다.

 

 

간단히 말해서, 프로듀서가 메세지를 어느 토픽에 저장해두고, 컨슈머가 약속해놓은 해당 토픽에서 메세지를 꺼내간다고 생각하면 될 것 같다.

 

 

 

 

 

파티션 Partition

토픽 내에 존재하는 파티션은 기본적으로 append-only, 즉 추가만 가능하다. 각 메세지의 저장 위치는 오프셋offset을 기준으로 저장된다.

만약 위 사진에서 새로운 메세지가 추가되면, offset 6이 되겠다.

 

컨슈머는 메세지를 오프셋을 기준으로 읽기 시작한다. 예를 들어, 컨슈머가 오프셋 2번부터 읽는다고 하면, 2, 3, 4 ... 식으로 읽게 되겠다.

 

 

 

그렇다면 프로듀서는 토픽을 지정해서 메세지를 저장한다고 앞서 언급했는데, 어느 파티션에 저장하게 될까?

위 그림을 보면 Topic 0 의 Parition 0, 1, 2, 3 이 여러 브로커에 나뉘어서 들어가 있다.

프로듀서가 만약 Topic 0에 메세지를 넣으려고 시도할 때, 라운드 로빈Round Robin 알고리즘으로 파티션을 선택하거나, 파티션의 키Key(이는 프로듀서가 메세지를 저장할 때 토픽과 같이 전달해야 한다.)를 통해 저장할 Partition을 선택하게 된다.

 

 

 

 

 

컨슈머 Consumer

컨슈머는 컨슈머 그룹 내에 속하게 된다. 여기서 중요한 점은 한 개의 파티션은 컨슈머 그룹 내에 한 개의 컨슈머와의 연결이 가능하다.

한 파티션은 그룹 내 컨슈머들과 공유할 수 없다. 위 그림에서 보다시피, 컨슈머 그룹 A에서 컨슈머 1과 컨슈머 2는 Partition 0을 서로 공유할 수 없고, 한 컨슈머만 공유하고 있다.

 

아래 컨슈머그룹 B의 컨슈머는 Partition0, 1을 모두 공유하고 있다. 그룹 내 다른 컨슈머가 공유하고 있지 않은 상황이기 때문에 가능하다.

 

따라서, 컨슈머 그룹을 기준으로, 한 개의 컨슈머가 한 개의 파티션을 공유하고 있으므로 파티션의 메세지가 순서대로 처리되는 것을 보장할 수 있다. (한 컨슈머만 공유하고 있기 때문에.)

 

 

 

 

 

브로커 Broker

카프카의 분산처리의 성격과 확장성이 여기서 드러난다. 여러 Topic을 가지고 있는 브로커는 각각의 노드(서버)이며, 운영 중에도 확장이 가능하다. 카프카 클러스터의 리소스가 한계에 다르면, 브로커를 추가하여 확장할 수 있다.

 

 

 

---

 

복제 Replication

 

카프카는 파티션의 복제를 지원한다. 여기서 복제된 파티션을 리플리카Replica라고 부른다.

여기서 복제할 파티션의 수를 Replication Factor라고 한다. 이는 토픽을 만들면서 지정할 수 있으며, 운영 시 1~3개를 만드는 것이 일반적이라고 한다. 여기서 복제된 파티션은 다른 브로커에 저장된다.

 

 

Replication Factor 수
1 ~ 2개 : 데이터가 유실되어도 무관, 처리속도 높음
3개 : 데이터 유실이 일어나면 안 되는 경우.

 

이 복제는 서버에 장애가 생겼을 때, 장애 대응을 위해 사용된다.

 

여기서 리더Leader 역할을 하는 토픽이 읽기, 쓰기를 모두 담당하고 있다가, 서버에 장애가 발생하게 되면 팔로워Follower가 리더가 되며 프로듀서와 컨슈머는 새로운 리더를 통해 다시 메세지를 활용할 수 있게 된다.

 

이 기능을 통해 카프카는 안정성을 더욱 확보하고 있다.

 

 

---

 

카프카의 성능

 

그렇다면, 이 카프카는 왜 여러 회사에서 쓰고 있는지 알아보겠다.

 

1. 확장성 Scalability, 대규모 데이터 처리

카프카를 이용하는 이유 중 가장 큰 이유라고 생각한다.

한 장비의 용량에 한계가 왔을 땐, 브로커를 추가하거나 파티션을 추가함으로써 서버를 확장할 수 있고,

컨슈머가 느리다면, 컨슈머를 추가하거나 파티션을 추가함으로써 확장할 수 있다.

여기서 확장되는 방향은 수평적으로 확장되어 병렬적으로 처리하기 때문에, 일정 처리량의 성능을 얻을 수 있다.

 

 

 

2. 이벤트 기반 (EDA)

최근 여러 서비스들이 확장되고, 클라이언트가 많아지게 되면서 대용량 데이터 처리가 많이 요구되고 있다. 따라서, 많은 기업에서 비동기 방식으로 메세지를 전달하는 패턴이 필요했을 것이다.

 

 

 

 

3. 가용성, 내구성

카프카는 대규모 처리를 지원하면서 동시에 복제기능을 통해 높은 가용성을 가지고 있다. 또한, 프로듀서의 acks옵션을 통해 모든 메시지를 로컬 디스크에 저장할 수 있게 된다.(세그먼트Segement 라고 한다.)

따라서, 서버가 장애가 발생했더라도 남는 log파일을 통해 서버를 재가동하거나 복구할 수 있는 것이다.

 

 

 

 

 

 

 

 

오늘은 카프카에 대해서 알아봤다. 추후에는 카프카를 직접 구현하고, 운용해 보면서 포스팅 하겠다.

 

 

 

 

참고

https://teki.tistory.com/65
https://www.youtube.com/watch?v=0Ssx7jJJADI&ab_channel=%EC%B5%9C%EB%B2%94%EA%B7%A0
https://www.redhat.com/ko/topics/integration/what-is-apache-kafka
https://www.devkuma.com/docs/apache-kafka/intro/
https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matteR