카프카란?

1. Pub / Sub 메시징 시스템

 

• Pub / Sub 구조로 이루어진 비동기 메세지 전송 방식
• Publisher / Producer 에서 메세지 시스템에 메세지를 보내 저장하면 Subscriber / Consumer 에서 메세지 데이터를 받는다.
• 저장된 메세지는 수신자가 정해져있지 않다.
• 구독을 신청한 수신자만이 정해진 메세지를 받을 수 있다.
• 수신자도 누가 발행자가 누군지 모른다. 

 

* 일반 네트워크 통신으로 메시지를 보낼 경우 문제점

 

• N:N 연결로 클라이언트가 많아지면 느려질수 있고 이를 대응하기 위해 확장성이 떨어진다.
• 특정 클라이언트가 갑작스럽게 서버가 다운되어 사라지면 메세지를 받지 못하여 메세지가 유실될 수 있다.

 

* Pub / Sub 구조의 네트워크 통신 

 

• Publisher 가 Subscriber에게 직접 전달하는 것이 아닌 수신처 ID 를 포함하여 메시지 시스템에 전달한다.
• 메세지 교환기가 수신처 ID 값을 통해 Subscriber의 큐에 전달한다.
• Subscriber 는 자신의 큐를 계속 관찰하다가 있으면 메세지를 회수한다.

장점

1. 수신자가 받을 수 없는 상황이 되어도 메세지가 유실되지 않는다.
2. 메세지 시스템으로 연결되어 있어 확장성에 용이하다.

단점

1. 중간에 한번 거치기 때문에 속도 측면에서 느릴 수 있다.

 

2. 카프카란

• Producer , Broker , Consumer , Zookeeper로 이루어져 있다.
• 프로듀서 (Producer) : 메세지를 브로커의 토픽으로 전달.
• 브로커 (Broker) : 카프카 어플리케이션에 설치되어있는 서버 또는 노드를 말한다.
• 컨슈머 (Consumer) : 브로커에 토픽이름으로 저장된 메세지를 가져가는 서버 또는 어플리케이션. 
• 주키퍼(ZooKeeper) : 분산 애플리케이션을 위한 코디네이션 시스템. 분산 애플리케이션이 안정적인 서비스를 할 수 있도록 분산되어 있는 각 애플리케이션의 정보를 중앙에 집중함. 컨슈머와 통신 혹은 카프카와 직접 통신하면서 구성 관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공 

 

작동 순서

1. 프로듀서는 생성된 메세지를 카프카에 전달
2. 전달된 메세지는 브로커의 토픽이라는 메세지 구분자에 저장.
3. 컨슈머가 토픽에 접근해서 메세지를 가져온다.

 

기본 메세징 시스템과 다른 점

• 위에서 설명했던 기본 메세징 시스템은 큐에 있던 메세지를 컨슈머가 소비하면 큐에서 바로 삭제를 해버린다. 하지만 카프카는 컨슈머가 메세지를 소비하더라도 디스크에 메세지를 일정기간 보관해서 메세지 손실이 없다.

 

3. 카프카 데이터 모델

 

카프카는 토픽과 파티션이라는 데이터 모델이 존재한다.

 

토픽

• 메세지를 논리적으로 묶은 개념 (DB 테이블이라 생각하면 된다.)
• 프로듀서가 메세지를 보내면 토픽에 메세지가 저장된다고 생각하면 된다.

 

파티션

• 토픽을 구성하는 데이터 저장소이고 메시지가 저장되는 위치이다.

 

• 여러개의 프로듀서에서 한개의 파티션으로 메세지를 보내면 병목현상이 생기고 메세지의 순서를 보장할 수 없다.
• 파티션을 여러개로 늘리고 수에 맞춰 프로듀서도 늘려서 파티션하나당 하나의 프로듀서 메세지를 받으면 엄청 빠르겠지.

파티션은 많을 수록 좋은가?

• 파일 핸들러의 낭비가 존재
  • 각 파티션은 브로커의 디렉토리와 매핑되고 저장되는 데이터마다 2개의 파일(인덱스, 실제 파일)이 있기 때문에 너무 많은 파일 핸들이 생길 경우 리소스 낭비가 생김
• 장애 복구 시간이 증가할 수 있음
  • 카프카는 리플리케이션(Replication)을 지원하고, 이를 통해 지속적으로 리더 파티션을 팔로워 파티션으로 리플리케이션을 하게됨
  • 하지만 파티션 수가 너무 많을 경우 리플리케이션 수행이 느려져 장애복구시간이 증가할 수 있음
• 추후 파티션 수를 줄이는 것이 불가능
  • 카프카에서 파티션 수를 늘리는 것은 아무때나 가능하지만 파티션 수를 줄이는 방법은 제공하지 않음. 만약 줄이고 싶다면 토픽 자체를 삭제하는 것 말고는 방법이 없음

 

오프셋 : 파티션마다 메세지가 저장되는 위치

 

리플리케이션 

 

 

• 리플리케이션을 수행하는 이유 : 고가용성 및 데이터 유실을 막기 위해 replication 을 수행
• 원본이 리더 파티션이 되고 복제가 팔로우 파티션이 된다.
• 리더 파티션 브로커가 다운되면 팔로우파티션이 새로운 리더가 되어 정상적으로 프로듀서의 요청을 처리한다.

 

 

참고 블로그

1. https://velog.io/@jaehyeong/Apache-Kafka%EC%95%84%ED%8C%8C%EC%B9%98-%EC%B9%B4%ED%94%84%EC%B9%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

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

https://twofootdog.tistory.com/86

아파치 카프카(Apache Kafka) 정의 및 특징

https://cornswrold.tistory.com/523

[Kafka] 주키퍼(zookeeper)란 무엇인가?