<Kafka> 0. 카프카 기초 알아보기

출처&참고 : https://product.kyobobook.co.kr/detail/S000201464167

카프카 핵심 가이드 | 그웬 샤피라 - 교보문고

- 카프카를 최근까지 도메인 특성상 사용 할 일이 없었는데 적용해야하는 업무가 생겼고 마침 스터디도 진행하게 되어서 공부하게 되었다.

- 살짝 보면서 단순히 메세지큐 같지 않을까라는 생각이 들었는데 생각보다 다양한 기술적인 부분들이 카프카 내에 존재하는게 많이 느껴졌다.

 

가. 카프카 기본용어 정리

 a. 뭐가 많네..

  - 카프카 관련된 기초 용어들 한번쯤 들어본 그것..! 들이 많아서 좀 헷갈리는 부분이 있는것 같아서 한번 정리해보려고 한다.  

  - 6분짜리 영상인데 영어고 자막이 없긴 하지만 예시를 바탕으로 잘 정리 되어있는것 같아서 책읽기 전에 보면 좋을것 같다.!   

Kafka 6분 정리!

 

 b. 메세지 Message

  - 카프카에서 전송되는 데이터의 기본단위를 메세지라고 부른다 

  - ex) 축구 경기에서 발생하는 각각의 이벤트 정보 (점수, 득점한 선수 목록 등등)  

 

 c. 토픽 Topic

  - 카프카에서 전송되는 메세지들의 분류된 집합, 카테고리를 토픽이라고 부른다.

     => 비슷한 개념으로 파일시스템의 폴더, 관계형 데이터베이스의 테이블

  - ex) 축구 경기 스코어 모음 토픽, 득점한 선수 모음 토픽 

 

 d. 파티션 partition 

  -  하나의 토픽은 여러개로 나누어질수 있는데 이 나눠진 각각을 파티션이라고 부른다.

       => 토픽 하나에 너무 많은 메세지가 발행되면 느려질 수 있는데 이렇게 파티션으로 분리하면 병렬처리가 가능하기 때문에 고성능을 제공한다.

  -  ex) 득점한 선수 토픽 => | 파티션0 : 첫번째 경기 득점자 모음 | 파티션1 : 두번째 경기 득점자 모음 | 파티션2 : 세번째 경기 득점자 모음 |

 

 e. 프로듀서 producer

  -  메세지를 발행하는 역할을 주체이다. 파티셔너를 사용해서 발행한 메세지를 저장할 특정 파티션을 지정할 수도 있다. 

      => 발행/구독 시스템에서의 publisher or writer 역할과 비슷하다. 

 

 f. 컨슈머  consumer 

  -  프로듀서가 발생한 메세지를 읽는 역할을 한다. 1개 이상의 토픽을 구독해서 여기에 저장된 메세지들을 각 파티션에 쓰인 순서대로 읽어온다.

      => 발행/구독 시스템에서의 subscriber or reader 역할과 비슷하다. 

  -  파티션내의 순서는 오프셋(지속적으로 증가하는 정수값)이라는 flag를 통해 관리되는데 이를 기록하는 역할은 컨슈머가 진행한다. 

      => 동일 파티션 내에서는 순서보장이 가능하지만 전체 토픽으로 봤을때 순서보장은 되지 않는다. 

  - 컨슈머는 파티션에 대해 소유권을 가지고 있으며 하나의 컨슈머가 여러개 파티션의 소유권을 가지고 있을 수도 있다.

 

 g. 컨슈머그룹  consumer group

  -  토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 이루어진 집합을 컨슈머그룹이라고 부른다.

      => 컨슈머그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다. 

  -  특정 컨슈머에서 장애가 발생하더라도 그룹 안에 다른 컨슈머가 소유권을 재할당 받고 이어서 데이터를 읽어 올 수 있다.

 

 h. 브로커 broker와 클러스터 cluster

  -  하나의 카프카 서버를 브로커라고 부르며 프로듀서로부터 메세지를 전달받아 오프셋을 할당하고 저장소에 쓰는 역할을 한다.

      => 하나의 브로커는 초당 수천개의 파티션과 수백만개의 메세지를 쉽게 처리 할 수 있다.

  -  카프카 클러스터는 여러 개의 브로커로 이루어져 있으며 메세지들을 안정적으로 관리하는 역할을 한다.

      => 클러스터 내에 하나의 브로커가 클러스터의 컨트롤러 역할을 한다. 컨트롤러는 파티션을 브로커에 할당하거나 브로커들에 대한 관리를 담당한다.

  -  각 파티션들은 클러스터 내의 하나의 브로커가 담당하며 이 브로커를 파티션 리더라고 부른다.

      => 여기서 추가로 복제한 파티션을 리더가 아닌 다른 여러 브로커들이 관리할 수 있는데 이 브로커들을 팔로워라고 부른다.

      => 이 복제 replication 기능은 파티션의 메세지를 중복 저장함으로써 리더 브로커에 장애가 발생했을때 팔로워 중 하나가 리더 역할을 이어 받는다.

  -  다수의 데이터센터에서 서비스 하기위한 다중 클러스터를 운용 할수도 있다. 각 클러스터는 미러메이커를 이용해 데이터를 동기화 한다.

      => ex) 유럽 축구리그 클러스터, 한국 축구리그 클러스터 or DR 이중화를 위한 클러스터

 

나.  발행/구독 아키텍쳐

 a. 발행/구독 시스템 구성 

  -  발행/구독 시스템의 가장 기본적인 형태는 데이터 전송자가 수신자에게 직접 보내지 않는다는 점이 특징이다.

      => 직접 보내지 않기 때문에 중간에서 이를 조율해주는 브로커가 존재한다. 일반적으로 Queue를 활용한다.

 

 b. 예시 아키텍쳐

  - 커머스 서비스와 뉴스플랫폼 서비스를 제공한다고 했을때 사용자들이 어느 페이지에 들어가고 어느 버튼을 자주 클릭하는지와 같은 지표를 모니터링해서

    서비스를 고도화하고 싶을 수 있다. 이때 공통 인터페이스를 만들어서 지표 시스템을 구성하면 위와 같이 간단하게 구성할 수 있다.

 

 c. 확장된다면..?

  -  단순히 Front와 Backend 서버를 분리하고 로그 분석 시스템도 추가 한다면 위와 같이 간단한 아키텍쳐에도 의존성이 복잡해질수 있다.

      => 서비스가 추가될수록 수신자 입장에서는 그만큼 추적하기가 어려워 질 수 있고 부하발생 확률도 늘어날 수 있을 것으로 보인다. 

 

 d. 중간 역할을 하는 서버를 추가

P/S == Publisher/Subscriber

  - 모든 어플리케이션으로부터 직접 수신자 서버에 연결하지 않고 중간 역할을 하는 서버를 추가했다.

     => 중간서버에 문제가 발생하여도 수신자 서버는 지속적으로 서비스 할 수 있고 발행자 서버에 대한 의존성도 없앨 수가 있다..!

  - 여기서의 문제점은 지표분석, 로그분석과 같이 다른 역할을 하는 끝단 시스템이 계속해서 추가되는 경우 중간서버도 추가되기 때문에

     매번 버그도 한계도 제각각인 다수의 큐 시스템을 유지관리 해야하는 문제점이 발생한다. 

     => 이러한 경우에 비즈니스가 확장에 따라 일반화된 유형의 데이터를 발행하고 구독할수 있는 중앙 집중화된 시스템인 kafka가 요구될 수 있다..!

 

다. 카프카의 주요 장점

 a. 고가용성

  -  다중 프로듀서, 다중 컨슈머, 다중 클러스터 및 복제 기능을 제공하고 있어 SPOF를 방지하여 일부 장애가 발생하더라도 중단없는 서비스 제공이 가능하다.

 

 b. 확장성

  -  파티션과 브로커 이용하여 데이터를 분산해서 저장하며 각 파티션을 여러 브로커에 할당해 병렬처리가 가능하다.

  -  파티션이나 브로커의 개수를 제한 없이 확장할수 있어 데이터양이나 서비스규모가 커지더라도 가용성에 영향을 주지않고 클러스터를 쉽게 확장할 수 있다.

 

 c. 내구성 

  -  디스크 기반으로 데이터를 저장/관리하기 때문에 시스템 장애나 재시작이 발생하여도 안전하게 데이터를 보존 할 수 있다.

      => 이는 컨슈머들이 항상 실시간으로 데이터를 읽어올 필요는 없다는 의미이기도 하다.

  -  복제 기능 및 분산 저장을 활용하기 때문에 데이터 손실없이 안정적인 메세지 전달을 보장한다.

  -  추가로 ack를 이용해 프로듀서와 브로커 간의 통신을 통해 안전하게 저장되었는지 확인을 진행한다.(복제 포함)