본문 바로가기

Programming/[kafka]

[kafka] Apache kafka

1. Apache kafka란?

- kafka는 Pub-Sub 모델의 메시지 큐

 

- 빠르고 확장 가능한 작업을 위해 데이터 피드의 분산 스트리밍, 파이프 라이닝 및 재생을 위한 실시간 스트리밍 데이터를 처리하기 위한 목적으로 설계된 오픈 소스 분산형 게시-구독 메시징 플랫폼

 

- 서버 클러스터 내에서 데이터 스트림을 레코드로 유지하는 방식으로 작동하는 브로커 기반 솔루션

- 여러 데이터 센터에 분산되어 있을 수 있으면 여러 서버 인스턴스에 걸쳐 레코드 스트림(메시지)을 토픽으로 저장하여 데이터 지속성을 제공 가능

 

 

2. 기본 구조

- kafka 클러스터

  1. 메세지를 저장하는 저장소

  2. 여러개의 브로커(각각의 서버)로 구성이 됨

  3. 브로커들이 메세지를 나눠서 저장, 이중화 처리, 장애가 나면 대체 함

  4. 데이터를 이동하는데 필요한 핵심 역할을 맡음

- 주키퍼(Zookeeper) 클러스터(앙상블)

  1. kafka 클러스터 관리

  2. kafka 클러스터와 관련된 정보가 기록이 되고 관리가 됨

- 프로듀서(Producer)

  1. kafka 클러스터에 메시지를 보냄

- 브로커(Broker)

  1. kafka application이 설치되어 있는 서버 또는 노드

- 컨슈머(Consumer)

  1. kafka 클러스터에서 메시지를 읽음

 

3. Apache kafka의 개념

- 토픽(topic)

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

  2. Partition : Topic은 여러 브로커에 분산되어 저장되며, 이렇게 분산된 Topic을 Partition이라고 합니다. 어떤 이벤트가 Partition에 저장될지는 이벤트의 key에 의해 정해지며, 같은 키를 가지는 이벤트는 항상 같은 Partition에 저장됩니다.

 

- 영속성

  1. Apache kafka는 레코드/메시지가 게시될 때 지속적으로 유지하는 서버 클러스터를 유지 관리하여 작동

  2. kafka 클러스터는 구성 가능한 보존 시간 제한을 사용하여 소비에 관계없이 주어진 레코드가 지속되는 기간을 결정

  3. 레코드/메시지가 보존 시간 제한 내에 있는 동안 레코드/메시지를 사용 가능

  4. 레코드/메시지가 이 보존 시간 제한을 초과하면 레코드/메시지가 삭제되고 공간 확보

- 토픽/파티션 확장

  1. Apache kafka는 서버 클러스터로 작동하기 때문에 주어진 토픽/파티션에서 각 서버에 부하를 공유하여 토픽/파티션을 확장(이 부하 공유를 통해 각 서버는 주어진 토픽/파티션에 대한 레코드/메시지의 배포 및 영속성을 처리 가능)

  2. 개별 서버가 모든 배포 및 영속성을 처리하는 동안 모든 서버는 서버가 실패할 경우 내결함성과 고가용성을 제공하는 데이터를 복제

  3. 파티션은 파티션 리더로 선택된 한개 서버와 팔로워 역할을 하는 다른 모든 서버들로 분할 그래서 파티션 리더 인 서버는 데이터의 모든 배포 및 영속성 (읽기/쓰기)을 처리하고 팔로워 서버는 내결함성을 위한 복제 서비스를 제공

- 오프셋

  1. 파티션마다 메시지가 저장되는 위치

  2. 파티션 내에서 순차적으로 유니크하게 증가하는 숫자 형태로서 동일 파티션 내 메시지의 순서를 보장

  3. Consumer는 메시지를 가져올 때마다 오프셋 정보를 Commit함으로써 기존에 어디 위치까지 가져왔는지 알 수 있게 됨

- 리플리케이션

  1. 고가용성 및 데이터 유실을 막기 위해 replication을 수행

  2. 원본 파티션의 경우 '리더'가 되고, 복제 파티션의 경우 '팔로워'가 됨

  3. 만약 리더 파티션이 있는 브로커가 다운될 경우, 복제 파티션을 가진 브로커의 팔로워 파티션이 새로운 리더가 되어 정상적으로 프로듀서의 요청 처리

- ISR(In Sync Replica)

  1. 리더와 팔로워로 이루어진 replication 그룹

  2. replication 그룹 내 동기화 및 신뢰성 유지

  3. 팔로워는 읽기/쓰기 권한이 없고 오로지 리더로부터 데이터를 복제하기 때문에 특정 팔로워가 다운되서 replication을 못할 경우 동기화 문제 발생

  4. 이러한 문제로 인해, 문제가 감지된 팔로워는 ISR 그룹에서 추방

 

4. Apache kafka의 장점

- 고성능, 고가용성, 확장성

- 분산 처리 시스템으로서, 확장성 및 고가용성이 높음 따라서, 노드 장애에 대한 대응성이 높음

- 배치 처리가 가능해 네트워크 왕복 오버헤드를 줄일 수 있음

- 디스크 파일 시스템에 데이터를 저장함으로써 영속성을 보장

- Producer 중심적이며, 메시지 전달 보장이 optional

  > 메시지 전달 보장을 할 경우 처리속도가 느려져 kafka의 처리속도 측면의 장점이 상쇄

- 라우팅 기능이 없음

- 100k + /sec 처리 보장

5. Apache kafka가 필요한 경우

- 높은 처리량 및 고성능/분산/스케일 아웃이 중요한 경우

- 가용성(장애 대응)이 높아야 하는 경우

- 메시지 전달 보장이 필수적이지 않은 경우

- 메시지 처리 순서가 보장되어야 하는 경우

- 스트리밍 데이터 처리가 필요한 경우

- 메시지 영속성이 필요한 경우

'Programming > [kafka]' 카테고리의 다른 글

[kafka] Burrow 설치 및 설정  (0) 2022.02.14
[kafka] CMAK 설치 및 연동  (0) 2022.02.14
[kafka] kafka 모니터링 및 대시보드  (0) 2022.01.27
[kafka] 환경 구축 및 예제  (0) 2022.01.26