Kafka 구조 및 구성 요소, Pub/Sub 모델

목차

 

 

 

1. Pub/Sub 모델

카프카는 Pub-Sub 모델이다. 여기서 Pub-sub 모델이란 무엇일까?

• Publish - Subscribe (발행/구독) 모델은 메세지를 특정 수신자에게 직접적으로 보내주는 시스템이 아니다.
• Publisher는 메시지를 topic(어떠한 집단을 말함)을 통해서 카테고리화 한다.
• 분류된 메시지를 받기 원하는 receiver는 그 해당 topic을 구독(subscribe)함으로써 메시지를 읽어 올 수 있다.
• publisher는 topic에 대한 정보만 알고 있고, 마찬가지로 subscriber도 topic만 바라본다.
• 즉, 데이터를 관리하는 Kafka 서버를 사이에 끼고 데이터를 넣는 publisher와 데이터를 읽는 subscriber는 각자의 업무만 kafka 서버를 통해 수행하므로 서로 모르는 상태이다.
• Kafka 클러스터를 중심으로 프로듀서가 데이터를 push하고 컨슈머가 데이터를 pull하는 구조
  (git hub에 push하고 pull하는 과정과 같음)

 

 

2. 디스크 순차 저장 및 처리

메세지를 메모리에 저장하는 기존 메시징 시스템과는 달리 메세지를 파일 시스템에 저장

파일 시스템에 메세지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장됨.

디스크가 순차적으로 저장되어 있으므로 디스크 I/O가 줄어들어 속도가 빠름

 

3. 구조 및 구성요소

 

 

그림에서 가운데 부분은 Kafka Broker와 Zookeeper로 구성되어 있다.

•Kafka Broker :  Kafka 서버

•Zookeeper : Kafka Cluster를 구성할 수 있도록 분산 코디네이션 시스템 역할

 

Kafka Broker와 Zookeeper로 구성되어 있는 것이 3개가 있는데, 이것들을 묶어서 Kafka Cluster라고 부른다. 

 

Kafka Broker 와 Zookeeper는 다른 서버에 설치하여 운영하는 것을 추천하는데, 이유는 만약 Zookeeper에서 시스템 오류가 발생한 경우 Kafka Broker에게 영향을 주지 않기 위해서이다.

 

Kafka의 topic은 partition이라는 단위로 쪼개어져 Kafka Cluster의 각 서버들에 분산되어 저장된다.

 

partition에는 데이터들이 순차적으로 저장되며, Kafka 서버는 해당 데이터를 설정 시간에 따라 보관한다.

(기본값 7일)

*생각해 보기

초기 클러스터는 왜 3개로 시작할까?

 

 

 

4. Kafka 를 도입한 웹 애플리케이션 아키텍처

as-is (좌) / to-be (우)

 

분산 서비스를 도입한 웹 애플리케이션의 아키텍처는 왼쪽과 같이 복잡한 모습이었다.
카프카를 도입해서 대용량, 대규모의 데이터를 빠르게 처리하고 오른쪽과 같이 복잡하고 위험한 의존성 관계를 심플하게 해결 할 수 있게 되었다.