주키퍼(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월에 시작했으며 모바일 산업..
본 포스팅에는 형태소 분석기등을 이용하여 검색을 하는 고급적인 부분들을 제외한 검색방법을 다뤄보는 포스팅이다. 이전 포스팅에서 주식에 관련된 정보를 stock이라는 인덱스에 넣어보긴 했었으나, 삼성전자에 대한 레코드만 넣었기 때문에 포스팅의 편의를 위하여 최근에 말도 많고 탈도 많은 방탄소년단의 빅히트와 블랙핑크의 와이지엔터테인먼트(YG) 주식 정보를 포함하여 총 3건의 레코드를 stock 인덱스에 추가한 후 검색을 하는 형태를 진행하고자 한다. 포스팅에 사용된 레코드 정보 PUT /stock/_doc/1 { "stockId" : "1", "stockNm" : "삼성전자", "stockType" : "보통주", "stockCd" : "005930", "trade" : "KOSPI", "current" :..
엘라스틱서치의 장점 중 하나는 바로 스키마리스(Schemaless)가 가능하다는 점이다. 이로 인해서 DB를 설계가 편리해지고 개발하는 과정에서 힘든 부분을 상쇄할 수 있다. 하지만 스키마리스는 양날의 검이 될 수 있는데 원치 않는 스키마로 인해서 색인이 이상하게 될 경우, 검색에 문제가 있거나 퍼포먼스 측면에서 떨어질 수 있다. 개발을 진행중에는 스키마를 등록하지 않고 진행할 수 있겠지만, 데이터 설계가 끝날 즈음에는 스키마를 등록하여 데이터 구조를 고정시키고 원하는 형태의 검색이 가능하게 만들어야 될 것이다. Schemaless 케이스 우선 스키마리스의 문제부터 파악해보도록 한다. 다음과 같이 주식에 관련된 데이터를 검색엔진에 넣었다고 가정을 해본다. PUT /stock/_doc/1 { "stockI..
마스터 노드(Master Node) - 클러스터를 관리하는 노드로 인덱스를 생성, 삭제하는 등 클러스터와 관련된 전반적인 작업을 담당하는 노드 - 가장 성능이 좋고 네트워크 속도가 빠르며 지연이 없는 노드를 선정해서 사용 - 다수의 노드를 설정할 수 있지만 하나의 노드만 선출되어 동작 설치폴더/config/elasticsearch.yml 에서 아래 내용 추가 node.master: true node.data: false node.ingest: false search.remote.connect: true 데이터 노드(Data Node) - 실질적인 데이터를 저장하며 검색과 통계 같은 데이터 관련 작업 수행 - 마스터와 분리해서 구성하는 것을 추천하며 컴퓨터 리소스를 많이 소모하기 때문에 모니터링 필요 설치..
PUT과 POST를 비교하여 데이터를 저장하는 것을 한적이 있는데 이번에는 PUT과 POST를 활용하여 데이터를 갱신(update)하는 것을 실습해본다. 해당 포스팅의 내용은 키바나를 연결하여 console 창에 테스트를 진행하며, 만약 사용하는 방법을 모르고 있다면 [키바나] 설치 및 엘라스틱서치 연동 위의 내용을 확인하여, 우선 키바나를 설치하고 콘솔창을 활용하는 법을 익히도록 하자 PUT 명령어로 갱신 PUT로 데이터를 갱신하는 방법은 다음과 같다. PUT /// { 내용... } PUT으로 데이터를 입력해보았으면 위 내용이 입력하는 방법과 동일한 것을 알 수 있을 것이다. PUT은 데이터가 있으면 UPDATE로 수정을 하고, 없을 경우 INSERT를 실행하는 즉 INSERT_OR_UPDATE 명령..
엘라스틱서치(Elastic search)에서 매우 쉽게 데이터를 가져오는 방법으로 GET 명령어를 활용하는 방법이 있다. 예를 들어, 내가 어떤 레코드들의 데이터 ID를 알고 있다고 가정을 해보자. PUT으로 데이터를 저장하였다면, 아이디를 애시당초 입력을 하기 때문에 GET으로 데이터를 가지고 오는데 전혀 문제가 없을 것이다. GET으로 가져오기 GET /// GET 명령어는 PUT과 사용법이 동일하다. 다만 PUT은 입력할 데이터를 추가로 적지만, GET은 인덱스, 타입, 아이디까지만 입력하면 된다. { "_index" : "article", "_type" : "_doc", "_id" : "2", "_version" : 1, "_seq_no" : 1, "_primary_term" : 1, "found..