Tagged: ElasticSearch

ElasticSearch Multi Instance 설치.

ElasticSearch 도 Tomcat 과 같이 Multi Instance 설치를 지원한다. 이는 ES_HOME의 쉘 환경 변수를 지정함으로써 실현된다. Tomcat 의 경우에는 CATALINA_HOME, CATALINA_BASE 였다. 대신 ElasticSearch 에서는 ES_BASE 가 없다.

ENV 변수

ElasticSearch 에서 사용하는 환경변수는 다음과 같다.

  • ES_HOME: elasticsearch 바이너리 설치 위치.
  • ES_PATH_CONF: elasticsearch 설정파일이 있는 디렉토리 위치.
  • ES_TMPDIR: elasticsearch 임시 디렉토리

위 두 변수를 가지고 MultiInstance 구성을 할 수있다.

ES_HOME 설치

ES_HOME 설치는 elasticsearch 의 바이너리를 압축해제함으로써 끝이 난다.

/opt 디렉토리에 압축을 해제한 후에 심볼릭링크를 걸어준다.

ES_BASE 생성

ES_BASE 는 ElasticSearch 에서 공식적으로 지원하는 변수는 아니다. 하지만 Tomcat 의 CATALINA_BASE 처럼 CATALINA_HOME 을 기반으로 구성되는 Instance 의 위치를 나타내고자 내가 사용하는 변수다.

여기서 ES_BASE 는 /home/systemv/masternode1 으로 하도록 하겠다.

이제 ES_BASE 디렉토리를 생성해 준다.

conf 디렉토리만 복사해 온다.

그리고 conf 디렉토리에서 elasticsearch.yml, jvm.options 파일을 편집해준다.

elasticsearch.yml

주요한 설정은 디렉토리 설정이다.

jvm.options

여기서는 gc 로그 디렉토리 위치를 ‘/home/systemv/masternode1/logs’ 로 변경해준다. 그리고 -Djava.io.tmpdir=${ES_TMPDIR} 로 지정해 준다.

ES_BASE 실행

실행은 다음과 같이 환경변수를 지정함으로써 실행시킬 수 있다.

위와같이 하면 ES_BASE 를 기반으로 ElasticSearch 가 동작하게 된다.

ElasticSearch 의 패키지 하나만 가지고 여러개를 동시에 실행시킬 수 있다는 장점이 있다.

 

ElasticSearch 6.4.x 노리(Nori) 형태소 분석기

ElasticSearch 는 루신을 기반으로 하는 전문 텍스트 검색 엔진이다. ElasticSearch 는 어떤 문장에 대해서 이를 분해한다. 문제는 ElasticSearch 가 외국에서 만든거라서 영어를 기반으로한 문장에 대해서는 분해하고 분석해준다. 하지만 그외에 대해서는 공백을 기반으로 문장을 분석한다.

여기서 문장에 대해서 좀 더 생각을 해봐야 한다. 문장을 분석할때에는 약간의 지식이 필요하다. 예를들어 다음과 같은게 있다고 하자.

고양이는 귀엽다

ElasticSearch 가 이 문장을 분석하면 ‘고양이는’, ‘귀엽다’ 로 분해한다. 하지만 이 문장에는 ‘고양이’ 라는 명사가 있고 ‘는’ 이라는 조사, ‘귀엽다’ 라는 동사가 존재한다. (정확한지는 나도 잘 모르겠다.)

이렇게 ElasticSearch 가 한글을 분석할 수 있도록하기 위해서는 한글이 이해시킬 수 있는 일종의 분석엔진 같은 것이 필요하게 되는데 이것이 바로 ‘한글 형태소 분석기’ 라고 한다. 몇가지 한글 형태소 분석기 엔진이 존재한다.

  • 아리랑
  • 은전한잎
  • 노리(nori)

ElasticSearch 를 제작하는 Elastic 사에서는 한글 형태소 분석기 Nori(노리) 를 내놓았다. 최신버전에 잘 설치되며 잘 동작한다.

설치

설치는 플러그인 설치로 끝난다.

설치할때는 마스터 노드, 데이터 노드에 설치를 해야 한다.

인덱스 분석에 노리 추가

ElasticSearch 는 알고 있겠지만 Index 단위로 데이터를 다룬다. Index 에는 데이터를 담기위한 그릇을 정의해야 하는데, 이것이 바로 Mapping 이다. 이 매핑에는 각 필드(Field)에 대한 데이터 타입을 정의하는데, 여기서 Index 에 대한 형태소 분석기로서 노리(Nori) 를 지정해줘야 한다. 기사를 인데싱하는 매핑에 예를 들면 다음과 같다.

analysis 에서 tokenizer 에 nori_tokenizer 를 지정하고 analyzer 에 이것을 korean 으로 지정한다.

이렇게 매핑(Mapping) 을 정의하고 다음과 같이 한글 데이터를 입력해준다.

 

테스트

먼저 인덱스 검색대신 문장에 대한 분석을 어떻게 하는지에 대해서 살펴보자.

위 내용을 보면 기본 형태소 분석기를 이용해 ‘고양이 냐옹냐옹’ 을 분석한 결과다. 공백을 기준으로만 한글을 분석했음을 알 수 있다. 그렇다면 설치한 노리 한글 형태소 분석기는 어떤 결과를 보여줄까?

기본 형태소 분석기와는 다르게 한글에 대한 형태소 분석의 결과를 보여준다. ‘고양이’가 명사임을 인식하고 있다.

한글 형태소 분석은 이런것이다. 조사와 합쳐진 명사만을 검색어로 입력하더라도 검색 결과를 보여준다.

ElasticSearch Nodes

ElasticSearch 는 노드(node) 로 불리운다. Node 는 ElasticSearch 의 독립된 인스턴스다. 그런데, 이 Node 에는 역할이 있으며 어떻게 Node 에 역할을 부여하는지에 해서 알아본다.

Node Type

Master Node

마스터 노드(Master Node) 는 ElasticSearch 의 클러스터(Cluster) 전체를 총괄하는 역할을 맡는다. ElasticSearch 는 분산검색엔진이며 각 노드들은 특정한 일을 하기 위한 하나의 그룹내의 멤버들로 관리되는데 이렇게 ‘하나의 그룹’ 을 클러스터라고 한다.

클러스터내에 노드들의 상태를 점검하고 이들의 유기적인 통제를 해야할 필요가 있는데, 이러한 역할을 하는 것이 바로 마스터 노드이다.

ElasticSearch 의 공식 문서에 보면 ‘Master Eligible Node’ 라는 말이 나온다. ‘마스터를 수행할만한 노드’ 정도로 해석되는데, 쉽게말하면 ‘마스터 후보군’ 이다. 이는 마스터 후보군이 존재하며 여기서 단 하나의 마스터가 선출되어 동장하고 만일 선출된 마스터가 장애를 겪는다면 마스터 후보군중에서 다른 마스터를 선출하게 된다.

Data Node

ElasticSearch 클러스터에서 실질적인 데이터를 저장하고 데이터 관련 연산을(Search, Aggregation 등) 수행하는 노드다.

샤드(Shard) 라는 개념이 바로 이 노드에 존재한다.

Ingest Node

파이프라인 스트림(Pipeline Stream) 이라고 한다. 문서를 인덱싱하기 전에 문서를 변형하는 역할을 수행 한다. 만일 각 노드에 대한 모니터링 기능을 켜게되면 반드시 Ingest Node 가 필요하게 된다.

Coordinating Node

코디네이팅 노드는 외부의 요청을 받아서 내부의 마스터 노드에 전달해준다. 벌크 인덱싱, 검색단계 줄이기등의 역할을 수행하기도 한다.

하나의 노드가 여러개의 역할을 중복해서 수행 가능하다. 그래서 개발을 위한 ElasticSearch 는 오직 하나의 노드만으로 모든 것을 할 수 있다.

 

Communication with Nodes

ElasticSearch 내에 노드들끼리는 TCP 통신을 기반으로 한다. 외부에 검색 쿼리(Query) 요청은 Http 통신을 기반으로 한다.

이제 여기서 생각을 해보자. 코디네이텅 노드의 역할을 분리해서 별도로 운영해야하느냐 하는 문제이다. 만일 코디네이텅 노드가 없을 경우에는 마스터 노드가 검색쿼리 요청을 받아야 하는 상황이 된다.

ElasticSearch 아키텍쳐1
ElasticSearch 아키텍쳐1

하지만 만일 코디네이팅 노드가 추가 된다면 다음과 같다.

ElasticSearch 아키텍쳐2
ElasticSearch 아키텍쳐2

뭘 하던간에 동작하는데에는 아무런 문제가 없지만 첫번재 아키텍쳐에서는 ELB 가 마스터 노드의 상태를 체크하고 잘못된 마스터 노드에 대해 제외를 시켜줘야 한다.

두번째 아키텍쳐에서는 ELB가 마스터 노드를 직접 제어하는 대신에 코디네이팅 노드를 제어한다.

유연성 측면에서 봤을때는 두번째 아키텍쳐가 더 좋아보이지만 그렇다고 딱히 아키텍쳐1번도 유연성에 문제가 있어보이지는 않는다.

Kibana 를 포함한 전체 아키텍쳐

Kibana 를 포함한 전체 아키텍쳐
Kibana 를 포함한 전체 아키텍쳐

Kibana 를 운영하기 위해서는 Ingest 노드가 필요하게 된다. 코디네이팅 노드를 포함하면 적어도 8개, Kibana 를 포함하면 9개 노드가 필요하게 된다.

ElasticSearch 시스템 설정

ElasticSearch 를 실행하기 위해서는 기본적으로 리눅스 시스템의 설정을 변경해줄 필요가 있다. 이는 ElasticSearch 문서에도 아주 잘 나와 있다.

Max Open File

리눅스 시스템은 사용자별로 최대 파일 오픈 개수를 제한 하고 있다. 이를 늘려주기 위해서는 /etc/security/limits.conf 파일에서 늘려줄 수 있다.

맨 앞에 문자열은 시스템 계정이며 맨 뒤에 숫자는 오픈가능한 최대치 값이다. ElasticSearch 에서는 65536 값을 권장하고 있다.

파일에 저장하고 계정을 재로그인하면 바로 적용된다.

Memlock 해제.

Memory Lock 에 대해서 무제한으로 해제를 해줘야 한다.

이것 역시 /etc/security/limits.conf 파일에 다음과 같이 설정하면 된다.

Virtual Memory

ElasticSearch 를 문제 없이 운영하기 위해서는 이를 조정해 줄 필요가 있다. 이는 리눅스 커널 파라메터값으로 재부팅 없이 조정이 가능하다.

시스템이 재부팅 되면 이 값을 다시 설정해줘야 함으로 이를 /etc/sysctl.conf 파일에 저장한다.

이렇게 파일에 저장한 후에 다음과 같이 하면 적용된다.

적용하기 위해서는 root 계정이 있어야 한다.