안녕하세요. 엔지엠소프트웨어입니다. 요즘~ 서비스를 제공하는 회사 또는 제가 몸담고 있는 반도체 공정 자동화쪽에서 카프카(Kafka)를 많이 사용하고 있습니다. 물론, 장비 회사들도 많이 쓰고 있는거 같습니다. 근래 몇번의 프로젝트가 전부 카프카를 이용해서 메세지를 주고 받는 방식으로 개발되었기 때문입니다. 그전에는 ActiveMQ나 TibRV를 많이 사용했었습니다. 그래서, 카프카가 무엇인지에 대해 좀 더 깊이있게 학습하기 위해 몇회에 걸쳐서 알아보려고 합니다^^; 사실, 저도 잘 모르는게 많거든요!

 

 

개발자 입장에서 이정도는 알고 사용해야 여러가지 문제 또는 장애 발생시 대처할 수 있기 때문에 이 부분을 중점적으로 알아보도록 하겠습니다. 우선, 카프카 홈페이지에 들어가보면 이벤트 스트리밍을 처리하기 위한 플랫폼 정도로 자기 자신을 설명하고 있습니다.

아파치 카프카
Fortune 100대 기업 중 80% 이상이 Kafka를 신뢰하고 사용합니다.
Apache Kafka는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해
수천 개의 회사에서 사용하는 오픈 소스 분산 이벤트 스트리밍 플랫폼입니다.

 

 

스트리밍? 제가 알기론 스트리밍은 주로 음악이나 동영상들의 멀티미디어를 실시간으로 전송하고 재생하는 방식으로 알고 있는데요. 저는 메세지로만 사용해봐서 그런지 와닿는 설명은 아닌거 같습니다. 우선은 메세지를 처리하는 방법에 대해 알아보고, 나중에 여유가 된다면 멀티미디어 스트리밍도 테스트를 한번 해보도록 하겠습니다. 아무튼, 포춘 100대 기업의 80프로가 카프카를 사용하고 있다고하니 성능이나 안정성은 이미 검증된거라고 생각해도 되겠네요. 카프카를 사용하려면 크게 4가지의 구성 요소가 필요합니다.

 

 

위 그림에서 알 수 있듯이 주키퍼(Zookeeper)와 카프카 브로커(Kafka Broker), 프로듀서(Producer), 컨슈머(Consumer)가 필요합니다. 첫번째로 카프카 브로커는 카프카 클러스터안에 여러개가 포함됩니다. 그리고 카프카 클러스터는 주키퍼 클러스터에 여러개가 포함됩니다. 그래서, 카프카 클러스터에 메세지를 저장하는 브로커가 여러개 있다고 생각하시면 됩니다. 브로커의 역할은 메세지들을 나눠서 저장하고, 이중화 및 장애에 대한 대처도 처리합니다. 이런 브로커들이 모여있는 카프카 클러스터를 관리하는 주키퍼 클러스터가 필요합니다. 주키퍼 클러스터가 모이면 주키퍼 앙상블(Ensemble)이라고 부릅니다. 주키퍼에 대한 설명이 아니므로 이 부분은 나중에 따로 알아보기로 하구요. 우선, 이정도로만 알고 넘어갑시다.

 

 

프로듀서는 카프카 클러스터에 메세지를 보내는 역할을 합니다. 반대로 컨슈머는 카프카 클러스터에서 메세지를 가져오는 역할을 합니다. 쉽게 생각해서 우리가 컴퓨터에 설치된 카카오톡으로 메세지를 작성하고 보내면 카카오 회사의 서버에 메세지를 보내는겁니다. 그리고, 카카오 서버가 같은 대화방에 있는 사람들에게 메세지를 보내는데요. 여기서 내 컴퓨터의 카카오톡이 프로듀서(물론, 컨슈머가 될수도 있습니다.)가 되고 카카오 메세지 서버는 카프카 클러스터가 됩니다. 대화방의 다른 모든 사람들은 컨슈머가 되는거구요.

 

카프카에서 메세지를 저장하는 단위는 토픽입니다. 토픽(Topic)은 브로커 안에서 여러개가 만들어질 수 있고, 토픽은 파티션으로 여러개를 만들 수 있습니다. 토픽은 메세지를 처리하기 위한 논리적인 기능을 수행하고, 파티션은 메세지가 저장되어 있는 물리적인 파일입니다. 토픽은 폴더의 개념과 비슷합니다. 토픽에 여러개의 메세지가 저장되는것과 같습니다. 브로커는 이를 관리하는 중개인입니다.

 

 

자~ 그러면, 토픽을 왜 여러개 만들어서 사용할까요? 다른 미들웨어와 비교해보면 그 용도를 쉽게 이해할 수 있을겁니다. 가령 ActiveMQ나 TibRV는 메세지에 Header 정보를 추가해서 보내거나 받을 수 있습니다. 그래서, 해더 내용에 따라 메세지 종류를 분류해서 여러가지 동작에 맞게 처리할 수 있습니다. 물론, ActiveMQ도 토픽 방식으로 메세지를 주고 받을 수 있기 때문에 어떻게 사용해야 하는지는 상황에 따라 달라집니다. 하지만, 카프카는 Header로 처리할 수 없기 때문에 처리단위 또는 기능별로 토픽을 만들어서 메세지를 주고 받도록 설계해야 합니다. 메뉴 소개 토픽, 주문 토픽등과 같이 메세지 기능 또는 속성에 따라 알맞게 생성하는게 좋습니다. 그래서, 프로듀서는 메세지를 어떤 토픽에 저장해야 하는지를 알려줘야 합니다. 그리고, 컨슈머는 어떤 토픽에서 메세지를 받을지 선택해야 합니다.

 

토픽안에 파티션은 1개 이상 만들 수 있습니다. 파티션은 실제 메세지가 저장되는 물리적인 파일을 말하는데요. 파티션은 추가만 가능(Append Only) 합니다. 그리고, 각 메세지가 저장되는 위치를 오프셋(Offset)이라고 부릅니다. 아래 그림에서 보면 프로듀서가 메세지를 보냅니다. 그러면, TOPIC 1의 첫번째 파티션에 0번째 메세지가 기록됩니다. 컨슈머는 오프셋 기준으로 순서대로 메세지를 가져옵니다. 메세지를 가져왔다고해서 삭제되는건 아닙니다. (설정에서 일정 시간이 경과한 후 삭제하도록 할 수 있음)

 

 

프로듀서가 메세지를 보낼 때 토픽을 정해야 한다고 말했는데요. 그러면, 어러개의 파티션으로 이루어진 토픽 안에서 어디에 저장되는지 알 수 있을까요? 프로듀서가 메세지를 보낼 때 키를 지정할 수 있습니다. 키가 있으면 키의 해쉬값이 같은 메세지가 있는 파티션에 메세지를 저장해줍니다. 이 의미는 여러개의 브로커에 같은 토픽이 있는 경우 메세지를 순차적으로 처리할 수 있다는 뜻이됩니다. 같은 키를 가진 메세지는 같은 파티션에 저장되기 때문인데요. 위 그림에서도 설명하고 있듯이 파티션은 순서를 보장하기 때문입니다. 컨슈머는 컨슈머 그룹에 속하게 됩니다. 컨슈머가 카프카 브로커에 연결할 때 나는 어떤 그룹에 속한다고 지정할 수 있습니다. 그리고, 파티션은 하나의 그룹에 하나의 컨슈머에만 연결할 수 있습니다. 아래 그림처럼 파티션을 여러 컨슈머가 연결하려면 그룹을 분리해야 합니다.

 

 

하나의 파티션이 하나의 컨슈머 그룹에만 연결할 수 있기 때문에 컨슈머 그룹안에서는 하나의 메세지가 순서대로 처리되는것을 보장할 수 있게됩니다. 한개의 파티션이 한개의 컨슈머만 연결할 수 있다는 제약은 컨슈머 그룹안에서만 적용되기 때문에 위 그림과 같이 한개의 파티션이 여러개의 그룹에 공유될 수 있습니다. 이 부분이 처음에 이해하기가 어려울 수 있습니다. 서비스를 개발할 때 잘 고려해야 하는 사항이기 때문에 꼭~ 이해하고 넘어가야 합니다. 우선, 카프카 테스트에 대한 내용을 읽어보시면 여기까지의 내용이 어느정도 이해가 갈수도 있습니다.

[ 윈도우에서 카프카 설치 및 테스트 ]

 

 

카프카의 성능은 기존에 사용하던 메세지 버스 또는 미들웨어들보다 뛰어나다고 합니다. 그래서, 급속도로 업계에 퍼진건데요. 엄청나게 비싼 TibRV보다 안전하고 빠를지는 모르겠지만, 무료인데다가 오픈소스라서 단순 비교는 불가능할거 같습니다. 카프카는 파티션 파일에 대해 OS 페이지 캐시를 사용합니다. 그래서, 파티션에 대해 파일 IO를 메모리에서 처리하기 때문에 속도가 빠릅니다. 그리고, 메세지를 읽고 쓰는데 제로 카피(Zero Copy)를 사용합니다. 일반적인 메세지(파일) 전송은 운영체제의 디스크에서 파일을 읽고 네트워크 소켓으로 데이타를 반복적으로 전송합니다. 보통, 전송 단위를 바이트로 1024로 쪼개서 보내니까요.

while (reader.ReadToEnd()) {
  byte[] buffer = new byte[1024];
  read(file, buffer, len);
  send(socket, buffer, len);
}

 

이 동작은 버퍼를 할당 받고, 디스크에서 파일을 버퍼로 읽어들여서 다시 소켓으로 전송하는 아주 간단한 방법입니다. 1024byte 이상의 데이타를 처리하기 위해 while문을 사용합니다. 아무튼, 프로그램에서 버퍼를 만들고, 운영체제가 데이타를 읽는 버퍼를 다시 만듭니다. 그리고, 소켓 버퍼로 보내고 실제 네트워크로 전송하기 위한 장비 버퍼에 다시 복사됩니다. 이렇게 보면 4개의 동일한 데이타를 각각 버퍼에 담고 지우는 과정이 수행되는데요. 이게 작은 파일의 경우 성능을 향상시키는 용도로 사용되지만, 파일이 커지면 병목 현상이 발생될 수 있습니다. 이런 메모리 컨텍스트 스위칭을 줄이는 방법이 제로 카피입니다.

 

 

컨슈머 추적을 위해 브로커가 하는일이 비교적 단순합니다. 페세지 필터, 메세지 재전송과 같은 일은 하지 않습니다. 이런 관리 측면의 일들은 프로듀서 또는 컨슈머가 직접 처리해야 합니다. 브로커는 컨슈머와 파티션 간 매핑만 관리하는 단순한 역할만 하므로 브로커에서 노드가 걸리는 일을 최소화할 수 있었습니다. 그리고, 메세지를 배치성으로 묶어서 보낼 수 있고 묶어서 받을 수 있습니다. 프로듀서는 일정 크기만큼 메세지를 모아서 전송이 가능합니다. 컨슈머 또한 최소 크기만큼 메세지를 모아서 받을 수 있죠. 사실, 메세지가 누락없이 실시간으로 처리되어야 하는 업종에서 사용할만한 기능은 아닙니다. 하지만, 멀티미디어와 같은 서비스쪽에서는 괜찮은 퍼포먼스를 낼 수 있습니다.

 

카프카는 장애가 발생했을 때 대처하기 위해 리플리카(Replica)를 사용합니다. 리플리카는 파티션의 복제본입니다. 파티션을 생성할 때 복제본을 2로 지정하면 동일한 데이타를 가진 파티션이 다른 브로커에 생성되게 합니다. 원본은 리더가 되고 복제본 2개는 팔로워가 됩니다. 메세지는 리더만 처리하고, 팔로워는 리더로부터 복제합니다. 그래서, 리더가 속한 브로커에 장애가 발생하면 다른 팔로워가 자동으로 리더가 됩니다.

 

 

여기까지 카프카에 대해 간단하게 알아봤습니다. 이제 프로듀서와 컨슈머를 어떻게 만들고, 메세지를 보내고 받는지 테스트만 해보면 됩니다. 윈도우에서 카프카를 테스트하기 위한 환경 구성과 실제 코드를 작성한 글이 아래에 있으니 한번쯤은 테스트를 해보시길 추천드립니다.

[ 윈도우에서 카프카 설치 및 테스트 ]

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천0 비추천0