카프카(Kafka)에서는 다양한 언어로 데이터를 주고 받는 기능을 제공하는데 본 포스팅은 파이썬(Python)으로 구현하는 프로듀서(producer)/컨슈머(consumer) 즉 데이터를 보내고 받는 방법을 설명한다. 파이썬으로 카프카를 호출하는 방법이 대표적으로 2가지 방법이 존재하는 것 같다. 하나는 카프카를 만든 제이 크렙스(Jay Kreps)가 만든 회사인 confluent가 제공하는 라이브러리이고, 다른 하나는 kafka-python이라는 라이브러리를 사용하는 방법이다. 후자인 kafka-python을 범용적으로 많이 사용하는데 성능은 컨플루언트의 라이브러리가 더 좋다. 후자를 사용하는 이유는 단하나 confluent는 c로 만든 라이브러리를 호출하여 사용하는 방식이라 별도의 설치과정이 존재하기..
주키퍼(ZooKeeper) 카프카(Kafka)는 분산 어플리케이션이기 때문에 이를 통제해주는 별도의 솔루션이 필요하다. 그래서 카프카를 독립적으로 설치하지 않고 필수적으로 주키퍼(Zookeeper)라는 하둡 진영의 분산 코디네이터를 설치하게 되는데 카프카 역시 아파치 프로젝트에 속해있기 때문이다. 주키퍼 설치프로세스 설치경로 : https://zookeeper.apache.org/releases.html 위 사이트에서 Apache ZooKeeper 3.6.2(asc, sha512)를 클릭하면 다운로드 사이트로 이동하게 되며 압축파일을 받고 아래와 같은 프로세스를 진행하도록 한다. 1. 원하는 폴더에 압축 파일을 옮긴 후, Command(cmd) 창을 열고 해당 위치로 가서 tar -xvf [주키퍼파일]을..
카프카에서는 파티션 단위로 분산처리를 수행한다. 이 분산 처리를 할 때 핵심적인 기능이 바로 복제(Replication)이라 볼 수 있다. 분산 처리를 할 때에는 모든 브로커에 데이터를 동일하게 보내는 것이 아니라 Master -> Slave 방향으로 데이터를 복제하는 것처럼 카프카는 리더가 팔로워에 복제를 수행하게 된다. 한마디로 Master는 Leader가 되고, Slave는 Follower로 되는 것과 같다. 위 그림처럼, 프로듀서는 리더에게 메시지(Message)를 전송하게 되고, 리더는 자신을 바라보는 팔로워에게 데이터를 복제한다. 그런데 위 그림으로만 보면 마치 복제를 할 때 토픽단위로 하는 것처럼 보이지만 사실 내부는 그리 단순하지 않는 것이 함정이다. 복제(replication) 방식 위 ..
토픽(Topic) 카프카(Kafka)는 데이터를 최종적으로 토픽(Topic)이라는 곳에 저장을 하며 데이터를 구분하기 위한 분류값 혹은 구분된 저장소라 이해하면 된다. 아파트에 있는 호별로 만들어진 우편함이라든지 이메일 주소라든지 이런 데이터를 받을 수 있는 값도 역시 카프카 관점에서는 토픽이라 볼 수 있다. 카프카는 데이터를 주고 받을 때 지정된 토픽으로 주고 받게 되며, 토픽을 어떻게 설계할 것인지가 핵심이 될 수도 있다. 파티션(Partition) 카프카의 저장소명을 토픽이라 한다면 파티션은 저장소 안에 분리되어진 공간이다. 파티션의 목적은 데이터를 더 많이 더 빨리 보내고 처리할 수 있는 것을 위해서 만들어진 것으로 파티션이 없다면 마치 1차선으로 된 도로를 달리는 것과 같지만, 파티션을 늘리고 ..
카프카(Kafka)에서는 페이지 캐시 기능을 써서 매우 높은 처리 속도를 가지고 있다. 페이지 캐시 기능은 OS에서 사용하는 페이지 캐시와 동일한 것이며, 메모리(RAM) 영역에 어플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리를 캐시로 전환하여 디스크 접근을 최소화해 I/O 성능을 향상시키는 메모리 영역이다. 카프카는 페이지 캐시를 적극적으로 사용하고 있기 때문에 서버에 디스크를 SSD로 구성하지 않아도 되며, 페이지 캐시를 사용하기 위해서 잔여 메모리를 쓰기 때문에 카프카 서버에 다른 어플리케이션을 함께 실행하는 것을 권장하지 않는다. JVM 힙사이즈 카프카는 JVM에서 돌아가기 때문에 메모리 할당 영역을 자바처럼 설정할 수 있다. 메모리 설정 방법은 KAFKA_HEAP_OPTS=-Xmx, X..
카프카(Kafka)의 분산 시스템이라고 포스팅 주제를 적긴 했으나 해당 내용은 빅데이터를 어느 정도 알고 공부했던 사람이면 사실 본인들이 알고 있는 지식에서 별 차이가 없다는 것을 잘 알고 있을 것이다. 카프카를 쓰는 이유가 빅데이터를 쓰던 사람이 카프카를 쓰는 것이 아닌 단일 시스템 혹은 분산이긴 하지만 빅데이터 플랫폼과 같이 flexible하고 scale out하지 않는 시스템에서 넘어온 케이스가 많을테니 말이다. 일단 본 포스팅에서는 카프카의 분산 시스템의 장점을 3가지 꼽을려고 한다. 카프카의 장점일수도 있지만 이는 분산 시스템 기반의 수많은 빅데이터 플랫폼의 장점이기도 하니 어찌보면 빅데이터 분산 시스템의 장점으로 이해해도 다를 바 없을 것이다. 높은 성능, 처리량(Throutput) 카프카의 ..
카프카(Apache Kafka)를 만든 링크드인(Linkedin)은 초창기 Point to Point 구조를 사용하다가 모든 요구사항을 충족시키기 위한 카프카를 만들게 되면서 Pub/Sub 모델을 채용하게 된다. Pub/Sub(펍섭) 모델은 Publish와 Subscribe를 의미하며 그림으로 설명하자면 아래와 같다. 우측의 펍섭 구조를 보면 사실 그냥 중앙에 서버가 있고 통신을 하는 것처럼 보이며 사실 틀린말이 아니다. 카프카가 전송해주는 발신자와 수신자를 연결하는 것은 같기 때문이다. 하지만 펍섭의 모델은 우측의 모형처럼 통신이 양방향이 아니라 단방향으로 이루어지며 한가지 추가적인 기능이 존재한다. 발신자(Publish) 발신을 하는 역할을 하는 사람은 카프카에게 전송만하게 되고 수신자가 누구인지 알..
카프카(Kafka)는 세계적인 소셜 구인구직 플랫폼인 링크드인에서 만든 스칼라로 개발한 메세지 프로젝트이다. 이 내부 시스템은 2011년 아파치(Apache) 공식 오픈소스로 공개되었으며 현재 엄청나게 많은 업체들이 이 시스템을 사용중에 있다. 해외뿐만 아니라 국내 유수의 IT업체들도 카프카를 사용중에 있다. 우선 IT 양대 산맥인 네이버(Naver)와 카카오(Kakao) 역시 이 시스템을 사용중에 있으며 카프카 홈페이지 첫화면을 보면 포츈(Fortune) 100개의 기업 중 카프카를 사용하는 기업이 80%라고 할 정도로 자체적인 메시지 시스템이 구축되지 않는 이상 카프카를 기본적으로 사용한다 봐도 무방할 정도다. 링크드인의 히스토리 링크드인(Linkedin)은 2002년 12월에 시작했으며 모바일 산업..
