Apache Kafka란

• 분산 스트리밍 플랫폼
• 상위 계층의 메시지 브로커
  • 내부적으로는 그 자체로 분산시스템
  • 메시지들을 관리하기 위해 여러 개의 브로커들을 사용

 

Apache Kafka vs. RabbitMQ

아파치 카프카

• 장점
  • 대규모 실시간 데이터 처리에 적합한 분산 메시징 시스템
  • 초당 수백만 개의 메시지를 처리할 수 있는 고성능을 가지고 있음
  • 데이터의 보존성을 보장하기 위해 데이터를 디스크에 저장함
  • 브로커를 추가하여 확장이 가능하며, 다양한 클라이언트 라이브러리를 제공함
  • 대규모 로그 처리, 이벤트 스트리밍, 실시간 스트리밍 등 다양한 분야에서 사용됨
• 단점
  • 복잡한 설정과 운영이 필요하며, 초기 구성 시간이 오래 걸림
  • 복잡한 메시지 패턴을 지원하지 않음
  • 메시지에 대한 응답 시간이 길어질 수 있음

RabbitMQ

• 장점
  • 높은 신뢰성과 다양한 메시지 패턴 지원이 필요한 경우에 적합한 메시지 브로커 시스템
  • 다양한 프로토콜 지원(AMQP, STOMP, MQTT 등)
  • 메시지 라우팅, 메시지 필터링, TTL(Time-to-Live) 등 다양한 메시지 패턴을 지원함
  • 확장이 용이하며, 다양한 클라이언트 라이브러리를 제공함
  • 대규모 메시지 처리, 비동기 메시지 처리, 웹 어플리케이션 등 다양한 분야에서 사용됨
• 단점
  • 카프카보다 처리 속도가 느리고, 처리량이 작음
  • 메모리 사용량이 많아질 수 있음
  • 복잡한 라우팅 설정이 필요할 경우, 설정이 복잡해질 수 있음

따라서, 아파치 카프카는 대규모의 실시간 데이터 처리에 적합한 분산 메시징 시스템이며, RabbitMQ는 다양한 메시지 패턴을 지원하고 높은 신뢰성이 필요한 경우에 적합

 

 

1. Producer side 추상화 계층

1-1. Record

• 카프카에서 발행하는 메시지는 Record 안으로 들어간다.
• key, value, timestamp로 구성된다.

 

1-2. Topic

• 메시지나 이벤트의 묶음
• 퍼블리셔는 모든 토픽에 레코드를 발생할 수 있다.
• 토픽별로 파티션 크기를 설정할 수 있다.

1. 사용자의 요청을 토픽으로 관리할 수 있다.
2. 오류와 예외도 토픽으로 관리할 수 있다. → 모니터링

 

1-3. Partitioning

• Partition
  • 레코드의 배열 형태
  • 각 토픽은 여러 개의 파티션으로 분할될 수 있다.
  • 각 파티션은 offset이 순차적으로 정렬하도록 구성된다.
  • 토픽 전체의 메시지들은 별도로 정렬되지 않는다.
  • 레코드가 추가될 파티션은 레코드 키의 해시값으로 결정된다.
• Log
  • 파티션을 실제로 저장한 물리적 파일

 

토픽 분할 → 수평 확장이 가능하다.

⇒ 파티션이 많아질수록 더 높은 병렬성과 성능을 가질 수 있다.

 

서로 순서가 중요하지 않은 메시지들은 다른 파티션으로 들어간다.

같은 사용자의 구매 메시지처럼 순서가 필요한 경우에는 사용자 ID를 key로 설정하여 같은 파티션으로 들어가서 순서를 보장받도록 한다.

 

2. Consumer side 소비 방식

2-1. Consumer Group

컨슈머는 컨슈머 그룹에 소속되어야 한다.

토픽을 구독하면 각 메시지는 컨슈머 그룹의 개별 인스턴스로 전달된다.

 

2-2. 분산 큐

• 메시지 처리가 복잡할 경우 사용
• 토픽으로 들어온 메시지가 그룹에서 로드밸런싱 되어 특정 인스턴스에게 배정된다.

 

2-2. Pub/Sub system

컨슈머와 그룹을 1:1로 유지시킨다.

• 모든 메시지들이 모든 컨슈머에게 전달된다.

 

3. 카프카의 분산 시스템

3-1. 메시지 브로커

하나의 인스턴스가 메시지 브로커를 수행한다면 단일 장애 지점이 된다.

따라서 카프카는 토픽을 여러개의 파티션으로 나눈다.

분리된 메시지 브로커에 파티션을 배정해서 토픽을 분산시킨다.

⇒ 파티션 안에서만 순서를 보장받을 수 있다.

(확장성을 위해서 토픽 전체의 순서 보장은 포기한다)

• 토픽의 파티션 개수 ~= 카프카 토픽(메시지 브로커)를 위한 병렬 유닛의 최대 개수
• 브로커를 수평확장해서 메시지를 로드밸런싱할 수 있다.
• 많은 컨슈머가 동일한 토픽에서 병렬적으로 메시지를 소비할 수 있다.

 

3-2. 카프카의 내결함성 (fault tolerance)

브로커 인스턴스 한 개에 오류가 생기면, 관련된 파티션의 레코드 전체를 잃을 수 있다.

• RF; Replication factor(복제 횟수)
  • 토픽의 각 파티션이 RF개의 복제본을 갖게 되며, 각각 브로커에 할당된다.
  • 하나의 브로커는 파티션 리더
  • : 데이터를 적극적으로 복제한다.
  • 나머지 브로커(RF - 1)는 팔로워가 된다.
  • : 리더에 오류가 발생하면 자동적으로 리더와 교대할 수 있다.
  • 토픽 별로 다르게 설정할 수 있다.

 

• 예시
  • 메시지 브로커가 4개가 있고, RF = 2일 때
  • 각 파티션은 2개의 브로커로 복제된다. (1 = 리더, 1 = 팔로워)
  • 리더로 동작하는 브로커에 의해서만 r/w가 수행되며, 팔로워는 동기화 상태를 유지하며 항상 리더가 될 수 있도록 준비한다.

 

• 주키퍼
  • 카프카는 주키퍼를 레지스트리로 사용하여 Z노드와 워처 같은 기술을 사용한다.
  • 이를 통해 모니터링, 오류 감지를 한다.

 

3-3. Data Persistence

• 컨슈머가 메시지를 소비한 뒤에도 레코드는 파티션 안에 일정 기간 남아있는다.
• ⇒ 메시지 처리 도중 문제가 생겨도 다시 시도할 수 있다.

 

참조

https://www.udemy.com/course/java-distributed-system/