Category: ElasticSearch

Elasticsearch 보안 – 인증서

Elasticsearch 가 버전이 높아짐에 따라 인증서에 대한 이해가 필요하게 되었다. 사실 이 인증서가 필요한 이유가 Elastic 에서 배포하는 X-Pack 중에 Security 플러그인 때문인데, 이 Security 를 활성화 하게 되면 TCP, HTTP 통신을 TLS 통신을 하도록 강제하고 있다.

문제는 Elasticsearch 자바 기반이며, 따라서 생성하는 파일이 여느 다른 인증서와는 다른 면도 있다. ‘다른 면도 있다’ 라고 표현한 이유는 일반적인 PEM 형식의 보안키와 인증서를 모두 지원하지만 여전히 자바 세계에서만 통용되는 방법을 여전히 고수하고 있기 때문이다.

keystore 파일

최신 버전의 Elasticsearch 7 을 설치하게 되면 /etc/elasticsearch/elasticsearch.keystore 파일 하나만 생성되게 된다.

이 파일은 key/value 형식으로 계정 정보가 들어가 있다. 이 내용을 적는 이유는 Java Keystore 파일과는 다르다는 것을 말하기 위함이다. Elasticsearch 을 설치하고 나서 Security 를 활성한 후에 계정에 대한 패스워드를 작성하는 절차를 밟는다.

계정에 대한 패스워드를 자동 생성하도록 한 것인데, 이렇게 생성된 내용들은 elasticsearch.keystore 파일에 key/value 형식으로 저장된다.

이렇게 저장된 key 값들은 elasticsearch-keystore 명령어를 통해서 볼 수 있다.

PKCS#12(확장자 p12) 파일

확장자가 p12 파일을 보게 된다. 이 파일은 PKCS#12 형식의 파일인데, 인증서와 개인키를 포함한 형태의 데이터 파일이다. Elasticsearch 7 에서는 루트 인증서(CA 인증서) 와 서버 인증서를 다음과 같이 제작해 사용 한다.

elastic-stack-ca.p12 은 CA 인증서 인데, openssl 을 이용해서 PKCS12 파일을 읽어볼 수 있다.

패스워드를 입력하지 않았기 때문에 패스워드 입력 문구에서는 그냥 Enter 를 치면 된다. 그러면 위와같이 Private Key, Certificate 내용이 나온다. Certificate 부분을 따로 때어내서 파일로 저장하고 Openssl 명령어를 이용해 인증서를 읽으면 다음과 같다.

CA:TRUE 라고 명백하게 나오고 있다.

그러면 CA 인증서를 가지고 만들어진 /usr/share/elasticsearch/elastic-certificates.p12 파일도 내용을 확인해 보자.

위 내용을 보면, Private Key 1개, Certificate 2개 로 나온다. 이건 인증서 체인 파일인게 분명하다. Certificate 부분만 따로 때어서 보면 다음과 같다.

확인 결과, 하나는 인증서이고 하나는 CA 인증서인 것으로 확인된다. 그러니까 elastic-certificate.p12 파일은 Private Key, CA 인증서, 서버 인증서 이렇게 3가지를 모두 가지는 파일이다.

PEM 형식 파일

Elasticsearch 에서는 PEM 형식의 파일도 함께 지원 한다. PEM 형식은 가장 흔하게, 널리 사용되는 인증서 파일 포맷 형식이다. elasticsearch-certutil 명령어를 이용해서 작성할 수 있다.

위와같이 zip 파일 형태로 생성된다. 압축을 해제하면 다음과 같이 파일이 생성된다.

ca 디렉토리가 생성되는데, 보면 Private Key 파일과 CA 파일이 별도로 생성된 것을 알 수 있다.

이렇게 작성된 파일을 가지고 서버 인증서를 다음과 같이 생성할 수 있다.

역시나 압축된 형태의 파일로 출력이 된다. 압축을 해제해 보자.

instance.crt 인증서 파일의 내용을 살펴보자

서버 인증서임을 알수 있다.

인증서 활용

PKCS#12 형식과 PEM 형식의 인증서를 활용하는 방법은 다르다.

PKCS#12 형식은 다음과 같이 설정 한다.

PEM 형식은 다음과 같다.

SAN 인증서

지금까지 설명한 방법으로 인증서를 작성할 경우에 한가지 문제가 있을 수 있다. 이 인증서들은 SAN 인증서가 아니기 때문에 모든 도메인에서 통용될 수 있다. 앞에 인증서 내용을 보면 SAN 이 없다. 하지만 SAN 인증서라야만 하는 보안성을 요구된다면 SAN 인증서를 만들어 사용해야 한다.

SAN 인증서를 작성할때에 주의 사항은 Elasticsearch Stack 에서 사용할 모든 도메인, 혹은 IP 주소를 기재해야 한다. 그렇지 않으면 절대로 통신을 할 수가 없게 된다.

먼저, CA 인증서가 필요하다. 이 CA 인증서는 앞에 PEM 형식의 CA 인증서를 만들고 압축을 해제해 놓는다. 그리고 다음과 같이 instance.yml 파일을 작성한다.

이 파일에서 ip, dns 항목이 보이는데, 둘 중 하나만 있어도 된다. 어짜피 인증서에서 SAN 항목에서 IP Address, DNS 둘중하나가 들어가 있고 매칭이되면 인증서를 쓸 수 있다.

이제 다음과 같이 인증서를 작성해 생성한다.

정상적으로 생성이 되었을 것이다. 압축을 해제해 보자

instance.yml 파일에서 이름부분이 디렉토리로 생성되면서 각각 인증서와 key 값이 생성되어 있다. 이 인증서들은 SAN 부분이 instance.yml 에 따라서 하나의 IP, 하나의 DNS 만 들어가 있다.

SAN 이 뭔지를 안다면 굳이 이렇게 다 분리할 필요는 없다는 생각을 하게 된다. 멀티도메인 인증서를 사용하면 도메인에 *.systemv.local 처럼 생성하면 될 것이고, 그러면 하나의 인증서를 가지고 여러곳에서 함께 사용이 가능해 진다. 위 예제에서는 각각의 용도에 맞게 딱 1개의 도메인과 IP 에 한해서 허용하도록 작성되었을 뿐이다.

PEM 형식의 Key 는 PKCS#12 형식으로 사용해야할 때가 있다. 이때는 다음과 같이 openssl 명령어를 이용해서 변환할 수 있다.

Nginx 로그를 위한 Logstash Pipeline 설정하기

Logstash 를 이용해 로그를 프로세싱 해보자. Logstash 에 대한 기초적인 설정은 다음글에서 확인 가능하다.

또, 이 글은 Elastic 홈페이지에 내용을 기반으로 한다.

filebeat 설정 및 기동

먼저 파일 filebeat 설정을 다음과 한다.

Elastic 홈페이지에는 간단하게 설정하도록 나오지만 여기서는 몇가지 설정을 추가 하였다. tags 를 설정하였고 fields 도 추가 하였다. 다음과 같이 시작 한다.

logstash Nginx pipeline 설정

먼저 filebeat 으로부터 메시지가 잘 들어오는지 디버깅을 먼저 해보자. 다음과 같이 간단하게 설정을 해본다.

INPUT 에는 filebeat 으로부터 전송을 받기 위한 port 를 지정해준다. OUTPUT 에는 디버깅을 위한 화면출력을 설정해 준다.

테스트

filebeat 의 로그 파일에 한 줄 넣어준다.

이렇게 하고 난 후에 logstash 의 출력 로그를 보면 다음과 같이 나온다.

여기서 보아야 할 것은 filebeat 에서 설정한 tags 와 field 다. 이것이 logstash 로 전송될때에 그대로 전송이 된다. message 에는 log 파일에 내용을 담고 있는데 이것을, 이제 필드별로 구별을 해야 한다. 이를 위해서는 로그의 형식을 알아야 한다.

Nginx 로그 형식

Nginx 의 로그 형식은 nginx 설정 파일에 log_format 에 기록되어 있다.

이 형식은 필요에 따라서 변경 될 수 있다. 이 형식을 알아야 한다.

Logstash FILTER pipeline 설정

이제 Nginx Pipeline 에 FILTER 를 설정해야 한다. 일 FILTER 는 들어오는 메시지를 가공처리해주는데, grok 을 이용한다. 메시지를 가공처리하는데 미리 정의된 형식도 지원한다. 다음과 같이 해보자.

filebeat 는 한번 읽은 로그는 다시 읽지 않는다. filebeat 는 중지 시키고, 데이터 디렉토리에 registry 디렉토리를 삭제 한다.

이렇게 하면 파일을 다시 읽는다. 하지만 결과는 필드로 구분되지 않았다. 이것은 미리 정의된 FILTER 가 적용되지 않았음을 의미 한다.

FILTER 의 적용은 grok 을 사용하는데, 이것을 매번 해보는건 힘들다. 그래서 온라인으로 테스트를 할 수 있도록 도와주는 사이트가 있다.

여기에서 샘플데이터를 넣은 후에 패턴을 grok 패턴으로 적용하면 결과를 보여준다. 이 패턴을 이용하면 된다.

grok 의 사용법은 %{SYNTAX:SEMANTIC} 형식인데, SYNTAX 는 패턴이다. SEMANTIC 는 그 패턴을 담는 변수라고 보면 된다. 그런데, 이 패턴은 미리 정의되어 있는데, 다음에서 확인 가능하다.

Nginx 형식에 맞는 grok 패턴을 다음과 같이 입력 해줬다.

이렇게 한 후에 로그를 전송하면 다음과 같이 잘 파싱된다.

Elasticsearch 보안

Elasticsearch 가 버전이 높아지면서 보안이 강화 됐다. 더군다나 Security 플러그인을 활성화할 경우에 각종 Rules와 Roles 들이 생성된다. 뭔가를 하기 위해서는 인증을 거쳐야 한다는 뜻이다.

Logstash 는 최종적으로 Elasticsearch 로 데이터를 보내야 한다. 이에 대한 보안 설정이 필요한데, 이에 대한 자세한 설명은 다음에 잘 나와 있다.

CA 인증서 설정

Elasticsearch 8.1 을 설치할때에 CA 인증서가 config/certs 디렉토리에 생성 되었다. RPM 으로 설치하였을 경우에 /etc/elasticsearch/certs 디렉토리인데, 여기에 http_ca.crt 파일로 존재 한다. 이것을 Logstash 에 OUTPUT 필터에서 사용해야 한다.

Logstash 를 위한 자격증명 만들기

자격증명을 만들기 위해서는 권한을 부여한 역할(Role) 를 만들어야 한다. Kibana 를 설치했다면 Management > Roles 에서 생성할 수 있다. 다음과 같이 만든다.

  • Role 이름: logstash_writer
  • Cluster Privileges: manage_index_templates, monitor, manage_ilm
  • Indices Name: nginx-access-*
  • Indices Privileges: write, create, create_index, manage, manage_ilm
Logstash 를 위한 Role 생성

이것은 다음과 같이 curl 을 이용할 수도 있다. 먼저 Role 을 위한 JSON 파일을 작성한다.

그리고 이제 다음과 같이 curl 명령어를 작성해 실행하면 된다.

이제 사용자를 만들어야 한다. 사용자를 만들때에는 패스워드도 함께 생성하고 앞에서 만든 logstash_writer 롤을 할당해 준다.

Logstash 를 위한 계정생성

역시 이것도 다음과 같이 JSON 형식으로 생성이 가능하다.

logstash OUTPUT 파이프라인 설정

이제 Logstash 의 OUTPUT 파이프라인을 설정해야 한다. 다음과 같다.

결론

logstash OUTPUT 파이프라인 설정이 되면 logstash 와 filebeat 을 재시작 하고 nginx 로그를 넣게 되면 이제 Elasticsearch 에 nginx-access-날짜 로 인덱스가 생성되면서 데이터가 적재된다.

Logstash 살펴보기

ELK 스택에서 로그를 프로세싱하고 저장소에 실시간으로 적재해주는 프로그램인 Logstash 에 대해서 살펴본다.

자바 프로그램

Logstash 는 자바 프로그램이다. 그래서 Java Runtime 이 필요하다. 그런데, Logstash 에는 Java Runtime 이 내장되어 있어서 별도로 설치하지 않아도 된다.

하지만 이 자바 때문에 프로그램이 무겁다.

Logstash 정의

다음과 같이 정의가 머리속에 담아 두기 좋다.

실시간 파이프라인(Pipeline) 기능을 가진 데이터 수집 엔진을 가진 오픈 소스 소프트웨어다.

파이프라인(Pipeline)

Logstash 는 파이프라인(Pipeline) 형식으로 데이터를 처리 한다.

INPUTS 은 데이터를 입력받는 부분에 대한 설정이다. OUTPUTS 은 어디로 데이터를 보낼 것인지 하는 부분인데, 대부분 데이터 저장소를 지정한다. FILTERS 부분은 입력받은 데이터를 가공처리하는 부분을 말하는데, Logstash 의 핵심부분이라고 할 수 있다.

logstash 플러그인

logstash 는 자체 플러그인을 가지고 있다. 이 플러그인을 활용하면 미리 설정된 FILTERS 에 맞게 로그를 처리하고 OUTPUT 을 해준다.

logstash 를 설치했다면 다음과 같이 지원되는 리스트를 확인해 볼 수 있다.

OUTPUT 플러그인 중에 Elasticsearch 를 설치해 보자.

logstash.yml

이 파일은 Logstash 실행을 제어하기 위한 것이다. 파이프라인 세팅, 설정 파일 위치 지정, 로깅 옵션등을 지정할 수 있다. 이 파일에 적은 옵션은 커맨드 라인으로 지정해도 된다.

주요한 설정은 다음과 같다.

logstash.yml 파일에 pipeline 관련 설정도 있다. 이것 때문에 헷깔리는 사람들이 많은데, 여기서 pipeline 설정을 하지 않아도 된다. 각각의 pipeline 설정은 pipeline.yml 에서 설정하는데, 여기서 설정하지 않은 값은 logstash.yml 파일에서 읽어 들인다. 쉽게 말해서 Default 값을 지정하는 것이라고 보면 된다.

pipeline.yml

pipeline 에 대한 설정을 하는 것이다. 대략 다음과 같다.

path.config 에서 디렉토리에 .conf 확장자 파일을 모두 읽어 들이도록 한다.

-f 옵션 없이 실행

보통 -f 옵션을 주고 실행하는 이유는 pipeline 설정파일을 지정하기 위해서다. 하지만 logstash.yml 과 pipeline.yml 파일을 작성했다면 -f 옵션 없이 실행할 수 있다.

위에 두가지 설정을 한 이유다.

로그 저장과 트래킹

로그(log) 는 각종 시스템과 소프트웨어 프로그램의 정보를 담고 있다. 한 사람이 하나의 시스템, 하나의 소프트웨어 프로그램을 다루거나 관리를 한다면 별 문제가 없겠지만 요즘 처럼 분산형 시스템과 소프트웨어를 사용하는 시대에 로그를 하나씩 다 들여다 본다는 건 불가능이다.

거기다 로그를 본다는 것도 여간 쉬운일이 아니다. 매우 지루하고 많은 시간을 허비해야 하는데, 수 많은 로그속에서 내가 필요로하는 정보를 찾기란 매우 어렵다.

그래서 이것을 손쉽게 처리할 수 있도록 도와주는 프로그램 그룹이 만들어졌는데, 다음과 같은 것이다.

Splunk

스플렁크(Splunk) 는 사용 소프트웨어다. 대량으로 로그를 저장하고 분석하도록 해주는 소프트웨어를 판매하는 회사다. 상용제품이다 보니까 이 제품을 익히는게 중요하다. Splunk Search Processing Language, 줄여서 SPL 을 이용해서 로그에서 필요한 정보를 뽑아 낼 수 있다.

ELK(Elasticsearch, Logstash, Kibana)

Elastic 제품군이다. 엘라스틱서치(Elasticsearch) 검색 소프트웨어로 유명한 Elastic 에서 만드는 것인데, 로그스태쉬(Logstash) 는 실시간으로 로그를 전달 받아서 처리하고 이것을 엘라스틱서치에 저장한다. 키바나(Kibana) 는 엘라스틱서치에 저장한 로그들을 특저한 쿼리를 이용해 시각화 해준다.

로그스태쉬(Logstasch) 대신 플로언트디(FluentD) 를 사용하기도 한다. 로그스태쉬로그스태쉬(Logstasch)보다 메모리를 덜 먹으면서도 가용성이 좋다.

로그 처리를 위한 ELK 를 스택(Stack) 이라고 명명하고 ELK Stack, EFK Stack 이라고 부른다.

ELK stack components

TICK(Telegraf, InfluxDB, Chronograf, Kapacitor)

InfluxDB 와 Telegraf 로 유명한 InfluxData 에서 만든 것이다. Kapacitor 는 ELK 에서 로그스태쉬에 해당한다. Chronograf 는 ELK 의 키바나에 해당된다.

개인적으로 Telegraf, InfluxDB, Grafana 를 이용한 시스템 모니터링은 여러번 사용해본 경험이 있다. InfluxDB 는 마치 RDBMS 처럼 SQL 문을 이용해서 데이터를 조회할 수 있다.

ElasticSearch RPM 패키지 설치 Security

ElasticSearch 를 RPM 패키지로 설치할 경우에 Security 설정을 어떻게 해야하는지에 대해서 다룬다. Security 설정은 X-Pack 을 활성화 하기 위함이며 이를 위해서는 인증서 관련 문제를 해결해야 한다.

사례

일단, 엘라스틱 서치는 대부분 3대로 구성한다. 대부분 호스트를 다음과 같이 정할 것이다.

  • es-01
  • es-02
  • es-03

이때, es-01 서버에서 다음과 같은 작업을 해야 한다.

es-01 서버에서 인증서 작업

X-Pack 을 활성화하기 위해서는 보안을 활성화해야 하는데, 보안을 활성화할 경우에 각 노드별로 SSL 통신을 하게된다. 이때 인증서가 필요한데, 인증서 작업을 해야 한다.

중요한 것은 인증서를 한 곳에서 해야하고 모두 서버에 배포를 해야 한다. 여기서는 es-01 서버에서 하는 것으로 가정한다.

뭐라 뭐라 나오지만 중요한건 위 두줄인데, 그냥 Enter 만 두번 쳐주면 된다. 이렇게 하면 /usr/share/elasticsearch 디렉토리에 ‘elastic-stack-ca.p12’ 파일이 생성된다.

그리고 이제 루트 인증서를 가지고 인증서를 다음과 같이 만든다.

역시 뭐라뭐라 나오는데, Enter 만 세번 쳐준다. 이렇게하면 /usr/share/elasticsearch 디렉토리에 ‘elastic-certificates.p12’ 파일이 생성된다.

위 과정으로 인해서 2개의 파일 ‘elastic-stack-ca.p12’, ‘elastic-certificates.p12’ 파일이 생성된다.

이 두개의 파일을 이제 3개의 엘라스틱서버 모두에 /etc/elasticsearch 디렉토리로 복사해 준다. 그리고 다음과 같이 소유권과 퍼미션을 변경해 준다.

설정

이제 3대 서버 모두에 ‘elastic-stack-ca.p12’, ‘elastic-certificates.p12’ 두개 파일이 /etc/elasticsearch 디렉토리에 있을 것이다. 모두 es-01 에서 만든 같은 파일이다.

이제 각 서버의 /etc/elasticsearch/elasticsearch.yml 파일 맨 마지막에 다음과 같이 설정을 해준다.

이게 es-01 서버부터 시작을 해준다. 그러면 잘 될 것이다.

패스워드 생성

마지막으로 엘라스틱서치에 인증이 필요한 계정에 패스워드를 생성해 준다.

Kibana 에서는 username 이 kibana 계정과 위에서 생성한 패스워드를 입력해 준다.

ElasticSearch 7.13 설치

ElasticSearch 7.13 으로 넘어오면서 변화가 있었다. 그중에는 Node Type 이 없어지고 이제는 Node Role 로 바뀌었다. 6.4 에서 다양하게 있었던 Node Type 은 비교적 대거 정리가 된 느낌이다.

Node Role

Node Role 은 ElasticSearch 7.13 의 설정 파일인 elasticsearch.yml 파일에서 정의하도록 되어 있는데, 여기에 정의할 수 있는 목록은 다음과 같다.

  • master
  • data
  • data_content
  • data_hot
  • data_warm
  • data_cold
  • data_frozen
  • ingest
  • ml
  • remote_cluster_client
  • transform

필요한 것이 master, data 정도라고 보면 된다. 하나의 노드에 다양한 Role 를 부여할 수 있다. 형식은 다음과 같다.

roles 지정을 하지 않을 경우에 위에 나열한 모든 roles 을 수행할 수 있다.

Single-node

ElasticSearch 는 다중 노드를 필요로 한다. 이것은 강제 사항으로 적어도 2개 이상을 필요하게 된다. 하지만 개발을 위해서라면 하나가지고 할 수 있어야 하는데, 이럴때는 다음과 같이 해준다.

Node

Master 노드는 CRUD 를 담당 한다. 적어도 2개 이상의 노드를 반드시 필요로 한다.

노드가 여러개 일경우에 이들이 서로 알아볼 수 있도록 통신을 해야 하는데, 다음의 설정으로 포트를 지정할 수 있다.

  • transport.profiles.default.port
  • transport.port

순서대로 체킹을 하게 된다. 별도로 지정하지 않으면 기본 포트를 가지고 서로 찾게 된다. 기본 포트는 9300 이다.

ES_ 환경변수

ElasticSearch 7.13 에서도 ES_ 환경변수는 존재한다. 이를 이용하면 하나의 ElasticSearch 패키지를 가지고 여러개의 ES 를 생성할 수 있다.

설치 계획

설치 계획은 다음과 같다.

  • Master Node: 3 개
  • Data Node: 2 개

Master 설치

설치는 ElasticSearch 멀티 인스턴스를 이용한다. 각각의 인스턴스 디렉토리명은 다음과 같다.

  • es-master-1, es-master-2, es-master-3

먼저 es-master-1 생성해 보자. 디렉토리를 생성한다.

설정은 config 디렉토리에 elasticsearch.yml 을 다음과 같이 편집한다.

포트를 달리하면서 es-master-2, es-master-3 도 세팅을 해준다.

Data 노드 설치

es-master-1 을 복사해서 es-data-1, es-data-2 두개를 만든다. es-data-1 의 설정은 다음과 같다.

startup.sh, shutdown.sh 스크립트

startup.sh 스크립트는 다음과 같다.

shutdown.sh 스크립트는 다음과 같다.

위 스크립트를 각 인스턴스 bin 디렉토리에 넣고 경로를 수정해서 실행하면 된다.

ElasticSearch 7.13 기반 책 리뷰

오래전에 “시작하세요! 엘라스틱서치” 라는 책을 구매해 본적이 있다. 지금도 소장하고 있는데, 엘라스틱서치에 대한 기본적인 개념을 익히는데 손색이 없는 책이라 평가하고 싶다. 단, 내가 볼때에 엘라스틱서치에 버전이 6.4 이다 보니 없어져버린 기능들은, 예를들어 펫싯, 볼 필요가 없었다.

오늘은 최신의 ElasticSearch 7.13 버전에서 이 책에 내용을 한번 살펴보고자 한다. 엘라스틱서치는 버전이 올라감에 따라 변경된 부분이 상당히 많아진다는 점을 생각해보면 꽤 도움이 될법한 내용들이라 생각한다.

엘라스틱서치의 데이터 구조 – 타입(Type) 없어짐

엘라스틱서치의 데이터 구조를 설명에서 인덱스(Index), 타입(Type), 도큐먼트(Document) 단위로 이루어진다고 설명했다. 하지만 엘라스틱서치 7.x 로 버전이 높아짐에 따라 타입은 이제 없다. 이에 대해서 엘라스틱서치 개발사에서 다음과 같은 페이지를 제공해 설명해 주고 있다.

위 문서를 보면 예를들어서 타입이 뭔지 설명하고 있으며 왜 없앴는지 타입을 이용했던 방법의 대안은 무엇인지 상세히 설명해 주고 있다.

그런데, 과연 타입(Type) 은 없어졌을까?

PUT 메소드 대신 POST 그리고 Content-Type 지정

책에 다음과 같은 예제가 나온다.

하지만 위와 같이 오류가 발생한다.

다음과 같이 Header 에 json 컨텐츠 타입을 지정해 줘야 한다.

앞서 매핑 타입이 없어졌다고 했지만 데이터를 입력하면 잘 들어 간다. GET 메소드를 이용한 조회도 잘 된다. 하지만 이것은 한가지 트릭과 같은데, 매핑에는 타입이 안나온다.

매핑 결과를 보면 타입(Type) 이 안나온다.

hotels 매핑 오류

책에는 hotels 인덱스 생성을 위해서 매핑(Mapping) 을 먼저 작성해 주는데 다음과 같다.

“Root mapping definition has unsupported parameters” 위와같이 오류가 발생 한다. 타입이 문제가 되는 경우라고 볼 수 있다. 위 내용을 수정하면 다음과 같다.

  • 매핑 타입 제거
  • string 타입을 제거하고 text 로 대체
  • not_analyzed 를 false 로 대체
  • dateOptionalTime 을 date_optional_time 으로 변경

성공적으로 생성 됐다.

Bulk 데이터 임포트

대량의 데이터를 엘라스틱서치에 입력할때에는 벌크(Bulk) api 를 이용한다. 매핑의 타입이 없기 때문에 타입을 제거해야 한다.

그리고 벌크 API 를 이용할때에는 다음과 같은 Content-Type 을 입력해줘야 한다.

위와같이 application/x-ndjson 을 지정해 줘야 한다.

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) 을 정의하고 다음과 같이 한글 데이터를 입력해준다.

 

테스트

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

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

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

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