인사. 안녕하세요 데이터 엔지니어링 팀에 오성민이라고 합니다. 이번에 테크씨오피 발표를 하라고 해서 무엇을 할까 생각하다가, 지난주에 팀에서 발표한 아파치 카프카에 대해서 간략하게 소개하는 것으로 되었습니다. 카프카에 대해서 소개해드릴건데요. 카프카를 이미 알고 계시거나, 사용해보신분 ? 이번 주제는 정말 카프카를 모르시는 분을 위한 발표 , 감안해 주세요 지난주말 팀내에서 발표를 했는데, 왜 그러는지 모르겠지만, 너무 재미 없어 하더라;; 제가 발표를 너무 못하면 중간 중간 도와주세요. 시작합니다.

카프카 정의 카프카는 메시징 시스템인데, 영속적이고 분산, 분할, 복제되는 메시징 시스템입니다. 이런거 너무 많아서;;; 저 한줄만 읽어도 뭔지 다 아실것 같아요.

링크드인에서 이런거 할려고 그러니까 데이터 흐름을 한곳으로 하려고 만든 시스템 입니다.

보시는 그림 처럼 카프카는 프로듀서, 컨슈머, 브로커 로 구성되있구요 메시지를 생성하는 프로세스를 프로듀서 라고 합니다. 또한 메시지를 사용하는 프로세스를 컨슈머라고 불러요. 이들을 만날 수 있게 메시지를 관리하는 클러스터 서버를 브로커 라고 합니다. 카프카는 높은 성능과 다양한 언어를 지원하기 위해, 클라이언트와 서버 사이 통신은 TCP 프로토콜을 이용한다고 해요.

또한 카프카는 로그에 관한 것입니다. 물론 이런 로그는 아니구요.

카프카 브로커는 FIFO 형태의 토픽이라는 카테고리를 가지고 있고, 그 안에 로그라고 불리는 프로듀서가 생성한 메시지를 흘려보내게 됩니다. 토픽은 MQ 의 queue 와 비슷한 모습을 하고 있어요. 보시는 것 처럼 각 로그는 0, 1, 2 등의 자신의 고유한 식별 자인, 숫자로된 인덱스를 가지고 있는데, 카프카에서는 이를 오프셋 이라고 부르고, 각각의 컨슈머 별 오프셋을 관리하게 됩니다 또한 로그는 컨슈머가 소비하던 소비하지 않던, 메시지를 삭제하지 않고, 설정한 시간 또는 데이터 사이즈에 도달 할 때까지 유지합니다.

각 토픽에 대해서, 카프카는 로그를 파티션하여 관리할 수 있습니다. 기본 적으로 토픽은 반드시 1개 이상의 파티션(Partitions)을 가지고, 하나의 브로커나 다수의 브로커에 분산 배치될 수 있다. 토픽을 다수의 파티션에 나누어 여러 브로커에 분산 배치할 경우 , 프로듀서가 토픽을 통해 메시지를 보내면 여러 브로커를 통해 분산 전송할 수 있고, 이를 통해 메시지 전송에 따른 부하를 분산시킬 수 있습니다. 이때 파티션의 개수에 대한 제약은 없다고 합니다.

다시 처음 카프카 정의로 돌아 와서 각 단어에 대해 카프카가 제공하는 기능을 하나씩 얘기해 볼께요.

카푸카는 퍼시스턴트를 제공하기 위해서 파일 시스템에 로그를 저장합니다. 보시는 것은 토픽의 파티션 안에 로그가 저장된 모습 입니다. log = 데이터 - 메시지 index = 오프셋

카프카가 로그를 파일에 쓰면서도 빠른 이유에 대해서 간략하게 설명해드릴건데요,  먼저  위의  Default  IO  라  적은  그림은,  일반적인  file  IO  를  나타낸  겁니다.    DMA  –  Direct  memory  Access  CPU  관여없이  메인  메모리로  데이터를  보낼  수  있다.  

반면에, 아래 그림은 OS의 페이지 캐싱과, Direct Buffer 를 통한 파일 IO를 나타낸 건데요,

OS 의 페이지 캐싱은 다들 아시겠지만,

OS 는 남는 주 메모리에, 가능한 많은 파일을 미리 캐싱해서, 실제 요청이 왔을떄, 파일을 읽어 들이는 시간을 최소화 하는 기법이죠,

파일을 미리 올려놓고, 힛트되기를 기도하고 있는거죠...

위 두 방식에서 성능상 중요한 차이점은, read() 함수 호출이 없이, 직접 매핑된 주 메모리를 참조하는 것입니다.

이러면,

1.  read () 함수에 의한 블락이 해소되고,

2.  두번의 복사 시간이 한번으로 줄게됩니다.

카프카는 JVM의 위에 만들어졌고, 아래 그림처럼 데이터 복사가 아닌 메모리를 직접 참조합니다.

실제 카프카가 돌아가는 머신의 메모리 사용을 조회해본 결과입니다. 많은 양이 캐시되어 있는걸 볼수 있어요.

또한,    카프카는  fileChannel을  이용해  메모리의  데이터를  어플리케이션으로  복사해는  방식이  아니라,  소켓으로  바로  넘겨  버리는  식으로  성능을  높이고  있습니다.    이런  방식은  다들  아시듯이,      

1. 자바 오브젝트의 메모리 오버헤드는 매우 높고, 종종 저장된 데이터의 크기보다

더 크게 부풀리는 단점,

2. 그리고 자바 가비지 콜랙션은 힙 안의 데이터가 증가 할 수록, 점점더 다루기 어

렵고, 느려지는데,

이런 문제점을 보완하게 됩니다.

다음은  분산에  대해서  말씀드릴게요.    각  로그의  파티션은  내  결함성을  위해  설정한  서버의  숫자만큼  복제되고,    각  파티션은  카프카  클러스터에  분산되  저장됩니다.    분산되어  저장된  파티션은  리더  역할을  하는  하나의  서버와,    0개  이상의  팔로워  서버를  갖는다.    팔로워가  리더를  복제를  하는  동안,  리더는  파티션을  위한  모든  읽기와  쓰기  요청을  처리한다.    만약  리더가  실패하면,  팔로워중  하나는  자동적으로  새로운  리더가  될것이고,    이런  동작을  관리하기  위해  주키퍼를  사용하고  있습니다.  

앞서 말씀 드린대로 카프카는 복제(Replication)기능을 제공합니다. 복제는 파티션 단위로 처리한다. 예를들어 복제 계수를 3으로 설정할 경우 1개의 리더, 2개의 팔로워로 구성된다. 이때 복제 계수는 브로커 개수 이상으로 설정할 수 없습니다. 당연히 한 서버에 동일한 파일 저장 할 필요가 없지요. 그리고 카프카의 현재 버전에서는 사용자의 모든 요청은 리더 파티션이 담당한다. 따라서 카프카의 복제는 가용성을 높일 뿐, 성능에는 영향을 주지 않는다.

카프카는 메시징 시스템이라 말씀드렸는데, 어떤 방식으로 동작하는지 간략히 말씀드리리

겠습니다.

Producers

프로듀서는 데이터를 특정 토픽으로 전송하고,

토픽안의 어떤 파티션에 메시지를 전송할 것인지 결정합니다.

메지시가 브로커에 분배되는 방법 대해서 생성자가 결정 하는 것이구요

카프카에는 partitioner 라는 인터페이스가 있어서, 개발자가 추가적으로 구현할 수 도 있

을 것으로 생각됩니다. 그리고,브로커로 메시지를 보낼때 싱크/ 어싱크 기법을 제공합니다.

컨슈머는

컨슈머는심플 컨슈머 API와 ,

하이-레벨 컨슈머API 이렇게 두가지로 나뉜다.

두 방식 모두 컨슈머 자신이 읽은 위치(오프셋)을

브로커가 아닌 컨슈머가 직접 관리합니다.

먼저, 하이레벨 컨슈머 API에 대해 설명 드리겠습니다.

하이레벨 컨슈머 API는

컨슈머 그룹과, 컨슈머로 구성되어 있습니다.

개별 컨슈머들은 하나의 컨슈머 그룹에 포함됩니다.

아래 그림을 보시면, group 1 과 2가 있고, 각각에 자신만의 컨슈머가 속해 있습니다.

이 때 컨슈머 그룹명은 카프카 클러스터 내에서 유일한 이름을 가져야하고,

하이-레벨 컨슈머 API 는 그룹의 유일한 이름으로 자신의 오프셋을 주키퍼에 저장 관리합니다.

앞전에서 로그의 인덱스를 오프셋이라 말씀드렸는데, 사실 오프셋은 각각의 컨슈머가 데이터를 읽

은 위치가 되는 것입니다.

하이레벨 컨슈머 API는 파티션의 수에 많은 영향이 있는데,

이유는 파티션의 수에 따라 컨슈머의 수가 제한되기 때문입니다.

로그는 파티션을 구독하는 모든 컨슈머 그룹으로 흘러갑니다.

심플 컨슈머 API 는 보시는 것처럼 로그를 가져오고 보내고 하는 기능 이 전부 입니다. 개발 자가 알아서 개발해서 쓰는 것이므로.. 아무런 제약이 없습니다. 하지만 직접 byte 를 쪼개고, 컨슈머의 오프셋을 관리하고, 병렬처리를 해결해야 하기 때무\문에 개발하기 어렵다는 ;;;;

이렇게 해서 설명 드렸듯, 카프카는 지속적이고 분산, 분할, 복제되는 메시징 시스템입니다.

카프카가 보장하는 것은 다음과 같아요. 프로듀서서가 특정 토필 파티션에 전송한 데이이터는 보내지진 순서대로 저장 됩니다. 컨슈머는 메시시지가 파티션의 로그에 저장된 순서대로 메시지를 처리합니다. 토픽을 복제 했다면 복제한 숫자 만큼 메시시지를 잃지 않고 장애를 견딜수 있다. 메시지가 단한번 소비 되는것을 보장합니다. 카프카가 제공하는 순서에 대한 보장에 대해 한가지 생각해야 할 것은 카프카의 순서는 파티션에 대해서만 보장된다는 것입니다. 각각의 컨슈머가 각 파티션을 처리 하기때문에, 파티션으로 분산된 데이터들의 순서는 보장할 수 없는것입니다.

       Kafka has stronger ordering guarantees than a traditional messaging system, too. 카프카는 전통적인 메시지 시스템 보다 강한 순서를 보장한다. A traditional queue retains messages in-order on the server, and if multiple consumers consume from the

queue then the server hands out messages in the order they are stored.

카프카 스파웃의 수는 카프카 파티션 수보다 크면 안된다는 얘길 하고 있다.

NSA 에서 공개한 데이터 모니터링 기술로, 데이터의 흐름을 관리 할 수 있다. 이 세가지를 카프카와 연동하는 것을 시연해 드릴건데요. 플럼을 통한 하나의 프로듀서와 니피와 스톰을 이용한 두개의 컨슈머가 존재하는 구조 입니다. 말씀드린대로, 카프카는 특정 컨슈머가 데이터를 소비했다 해도 바로 삭제하지 않기 때문에, 엠큐의 익스체인지를 통한 큐 복제 같은 복제 작업 없이도 동일한 데이터를 사용할 수 있는 것을 보여 드리기위해, 구성해 보았습니다.