kafka

Kafka란? (Kafka의 구조와, 주요개념)

Kafka - Kafka란? (Kafka의 구조와, 주요개념)

Kafka - Kafka란? (Kafka의 구조와, 주요개념)

 

구성요소

2.1 Event

Event는, kafka에서 Producer와 Consumer가 데이터를 주고 받는 단위입니다. 이 글에서는 이벤트 또는 메시지로 표기하겠습니다.

 

2.2 Producer

Producer는 kafka에 이벤트를 게시(post)하는 클라이언트 어플리케이션을 의미합니다.

 

2.3 Consumer

Consumer는 이러한 Topic을 구독하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션 입니다.

 

2.4 Topic

이벤트가 쓰이는 곳입니다. Producer는 이 Topic에 이벤트를 게시합니다. 그리고 Consumer는 Topic으로 부터 이벤트를 가져와 처리합니다. Topic은 파일시스템의 폴더와 유사하며, 이벤트는 폴더안의 파일과 유사합니다.

Topic에 저장된 이벤트는 필요한 만큼 다시 읽을 수 있습니다.

 

Partition

Topic는 여러 Broker에 분산되어 저장되며, 이렇게 분산된 Topic을 Partition이라고 합니다. 어떤 이벤트가 Partition에 저장될지는 이벤트의 key(키)에 의해 정해지며, 같은 키를 가지는 이벤트는 항상 같은 Partition에 저장됩니다. Kafka는 Topic의 Partition에 지정된 Consumer가 항상 정확히 동일한 순서로 Partition의 이벤트를 읽을것을 보장합니다.

 

Kafka의 주요 개념

3.1 Producer와 Consumer의 분리

Kafka의 Producer와 Consumer는 완전 별개로 동작을 합니다. Producer는 Broker의 Topic에 메시지를 게시하기만 하면되며, Consumer는 Broker의 특정 Topic에서 메시지를 가져와 처리를 하기만 합니다. 이 덕분에 Kafka는 높은 확장성을 제공합니다. 즉, Producer 또는 Consumer를 필요에 의해 스케일 인 아웃하기에 용이한 구조입니다. 만약, Producer와 Consumer가 직접적으로 연관을 가지고 있다면, 확장 또는 축소시 이들을 모두 연결 또는 해제를 하기가 매우 번거럽고 어려웠을 것입니다.

 

3.2 Push 와 Pull 모델

kafka의 Consumer는 Pull 모델을 기반으로 메시지 처리를 진행합니다. 즉, Broker가 Consumer에게 메시지를 전달하는 것이 아닌, Consumer가 필요할때, Broker로 부터 메시지를 가져와 처리하는 형태입니다.  이러한 형태는 아래와 같은 장점이 존재합니다.

1. 다양한 소비자의 처리 형태와 속도를 고려하지 않아도 된다. 반대의 경우인 Push모델에서는, Broker가 데이터 전송 속도를 제어하기 때문에, 다양한 메시지 스트림의 소비자를 다루기가 어렵지만, Pull 모델은 Consumer가 처리 가능한 때에 메시지를 가져와 처리하기 때문에 다양한 소비자를 다루기가 쉽습니다.
2. 불필요한 지연없이 일괄처리를 통해 성능향상 도모. Push 모델의 경우에는, 요청을 즉시 보내거나, 더 많은 메시지를 한번에 처리하도록 하기 위해 Buffering을 할 수 있습니다. 하지만 이런 경우, Consumer가 현재 메시지를 처리할 수 있음에도, 대기를 해야합니다. 그렇다고 전송 지연시간을 최소로 변경하면, 한번에 하나의 메시지만을 보내도록 하는것과 같으므로 매우 비효율적입니다. pull 모델의 경우, 마지막으로 처리된 메시지 이후의 메시지를 Consumer가 처리가능한 때에 모두 가져오기 때문에, 이 문제를 해결합니다. 따라서 불필요한 지연 없이 최적의 일괄처리를 할 수 있습니다.

9912C33B5FC70CB319.png

0.07MB

 

메세지는 지정된 Topic에 전달됩니다. Topic은 다시 여러 Partition으로 나뉠 수도 있습니다. 위 그림에서 각 파티션의 한칸한칸은 로그라고 칭합니다. 또한 메시지는 로그에 순차적으로 append 됩니다. 그리고 이 메시지의 상대적인 위치를 offset이라고 칭합니다.

메시징 시스템은 Broker에서 소비된 메시지에 대한 메타데이터를 유지합니다. 즉, 메시지가 Consumer에게 전달되면 Broker는 이를 로컬에 기록하거나, 소비자의 승인을 기다립니다.

 

Commit과 Offset

Consumer의 poll()은 이전에 commit한 offset이 존재하면, 해당 offset 이후의 메시지를 읽어오게 됩니다. 또 읽어온 뒤, 마지막 offset을 commit을 합니다. 이어서 poll()이 실행되면 방금전 commit한 offset이후의 메시지를 읽어와 처리하게 됩니다.

 

 

Apache Kafka(아파치 카프카)란 무엇인가?

Apache Kafka(아파치 카프카)란 무엇인가?

Apache Kafka(아파치 카프카)란 무엇인가?

카프카 아키텍처

• 프로듀서(Producer)
  메시지를 생산하여 브로커의 토픽으로 전달하는 역할
• 브로커(Broker)
  카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 지칭
• 컨슈머(Consumer)
  브로커의 토픽으로부터 저장된 메시지를 전달받는 역할
• 주키퍼(Zookeeper)
  분산 애플리케이션 관리를 위한 코디네이션 시스템 분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이밍, 동기화 등의 서비스 수행

작동방식

• 프로듀서는 새 메시지를 카프카에 전달
• 전달된 메시지는 브로커의 토픽이라는 메시지 구분자에 저장
• 컨슈머는 구독한 토픽에 접근하여 메시지를 가져옴 (pull 방식)

기존 메시징 시스템과 다른 점

• 디스크에 메시지 저장
  기존 메시징 시스템과 가장 큰 특징 기존 메시징 시스템은 컨슈머가 메시지를 소비하면 큐에서 바로 메시지를 삭제 하지만, 카프카는 컨슈머가 메시지를 소비하더라도 디스크에 메시지를 일정기간 보관하기 때문에 메시지의 손실이 없음 (영속성)
• 멀티 프로듀서, 멀티 컨슈머
  카프카의 경우 디스크에 메시지를 저장하는 특징으로 인해, 프로듀서와 컨슈머 모두 하나 이상의 메시지를 주고 받을 수 있음
• 분산형 스트리밍 플랫폼
  단일 시스템 대비 성능이 우수하며, 시스템 확장이 용이함 일부 노드가 죽더라도 다른 노드가 해당 일을 지속 (고가용성)
• 페이지 캐시
  카프카는 잔여 메모리를 이용해 디스크 Read/Write 를 하지 않고 페이지 캐시를 통한 Read/Write으로 인해 처리속도가 매우 빠름
• 배치 전송 처리
  서버와 클라이언트 사이에서 빈번하게 발생하는 메시지 통신을 하나씩 처리할 경우 그만큼 네트워크 왕복의 오버헤드가 발생
  이로인해, 메시지를 작은 단위로 묶어 배치 처리를 함으로써 속도 향상에 큰 도움을 줌

[비교]

Kafka

• 높은 처리량 및 고성능/분산/스케일 아웃이 중요한 경우
• 가용성(장애 대응)이 높아야 하는 경우
• 메시지 전달 보장이 필수적이지 않은 경우
• 메시지 처리 순서가 보장되어야 하는 경우
• 스트리밍 데이터 처리가 필요한 경우
• 메시지 영속성이 필요한 경우

RabbitMQ

• 빠르고 쉽게 메시지 큐 시스템을 구축하고자 하는 경우 (라우팅 기능이 유연함)
• 메시지 전달 보장이 필수적인 경우
• 메시치 처리 순서가 보장되지 않아도 되는 경우
• 메시지 영속성 X

Google Pub/Sub

• Kafka와 유사한 아키텍처 (topic 개념)
• 클라우드 서비스로서 별도의 설치나 운영이 필요없음
• 메시지 처리 순서 보장이 안됨(분산형 아키텍처)
• 메시지 영속성 X (저장기간 최대 7일)

 

아파치 카프카 (Apache Kafka)란?

아파치 카프카 (Apache Kafka)란? : 네이버 블로그 (naver.com)

아파치 카프카 (Apache Kafka)란?

▶ Cluster : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합

▶ Producer : 데이터를 만들어내어 전달하는 전달자의 역할

▶ Consumer : 프로듀서에서 전달한 데이터를 브로커에 요청하여 메시지(데이터)를 소비하는 역할

▶ Broker : 생산자와 소비자와의 중재자 역할을 하는 역할

▶ Topic : 보내는 메시지를 구분하기 위한 카테고리화

▶ Partition : 토픽을 구성하는 데이터 저장소로서 수평확장이 가능한 형태

 

broker로 (아래와 같은) 클러스터를 구성할 수 있는데, broker가 되는 각각의 KafkaServer는 자신의 식별자로 broker.id를 부여받게 되며 producer로부터 생성된 메시지를 저장할 위치정보와 클러스터 메타정보를 저장 및 관리할 Zookeeper 연결정보가 지정된다