공부/컴퓨터

일래스틱 스택 6 입문(Learning Elastic Stack 6.0) - 일래스틱서치, 로그스태시, 키바나, 엑스팩 활용 가이드

찬 2018. 11. 27. 23:26

이것저것

공부하기

데이터를 많이 모아 보려고 하고 있다.
데이터를 모으는것은 그냥 모으면 되지만, 이것들을 어떻게 활용 할 것인가에 대한 고민...
- 데이터를 "처리"하는 부분
- 데이터를 "분석"하는 부분
- 데이터를 "활용"하는 부분
으로 나뉘어 질텐데, 우선 텍스트를 쉽게 분석? 할 수 있는 엘라스틱 스택에 대해서 공부 하기로.

읽기

우선 이 책은 초보자를 위한 책은 아님이 확실하다.
엘라스틱 서치의 많은 것을 알려 주기는 하지만, 설명이 장황하고, 구체적이다. 초보가 보기에는 정보가 너무 많아, 너무 어렵게 느껴 질 것으로 판단된다.
이 글에서는, 책의 순서가 뒤죽 박죽이 될 수도 있겠다.

02장 일래스틱서치 시작하기

ubuntu 에서 apt로 elasticsearch를 설치하면, 9200 포트에 접근이 되지 않는 경우가 있다.
- /etc/elasticsearch/elasticsearch.yml 파일에서 network.host 부분을 0.0.0.0으로 변경해 준다.
p57 kibana에서 REST API 호출하기
- GET /라고 입력한 뒤, 초록색 삼각형()을 누르면 해당 쿼리가 실행된다고 한다.
- 더 쉬운 방법이 있다. 실행하고 싶은 쿼리가 있는 곳으로 커서을 옮긴 뒤, Ctrl + Enter를 입력하면, 커서가 있는 위치의 명령이 수행된다. 이걸 쓰도록 하자.
- kibana Dev Tools 에서 쿼리를 입력하는 도중 문제가 있으면, 에러 표시()를 해 주므로, 쉽게 사용할 수 있다.
  - 아래는 json의 key 부분인 params를 "로 감싸지 않아서, 문제가 있다고 알려줌.
  - 단, 모든 에러를 모두 찾아주는건 아니니깐.. 그건 어쩔 수 없음. ㅋ.
엘라스틱 서치에서 REST API의 동작이 ... 뭔가 .. 좀 이해하기 어렵다.
- 보통 POST는 "추가/생성"의 의미를 가지고, PUT은 "수정(혹은 생성?)"의 의미를 가지는데, 이책의 예제들을 보면, 그게 좀 모호하다.
  - POST
    - id 지정 없이 데이터를 추가하고 싶은 경우(서버가 알아서 id를 할당)
    - id 가 있고, 데이터를 수정하고 싶은 경우 (응???)
  - PUT
    - 인덱스를 새로 만들고 싶은 경우
    - id를 지정해서 도큐먼트(데이터)를 추가하고 싶은 경우
p60 가운데 그림
- 노드 이라고 되어 있는데, 아마도 인덱스가 되어야 할 것이다.
- 실제 노드에 대한 설명은 64, 64 페이지에 나온다.
p78 가운데 업데이트 API 예제
- POST /catalog/product/1/_update { 에서 마지막 {를 빼야 한다.
- 다음줄에 {가 또 나오기 때문이다.
- Kibana에서 입력할 때도 _update뒤에 {가 있으면, 아래와 같이 에러가 발생한다.
p 82 인덱스의 매핑을 지정하기 위해서 mappings를 사용하는 부분.
- mappings로 되어 있어서, 여러개의 type을 넣어 보고 싶어서 시도 했으나, 한개의 인덱스에 여러개의 type을 넣으니 에러가 발생했다. 이상하다, 분명히 인터넷에 여러개의 type을 넣는 예제( [Elasticsearch] Multi types into Index. )도 있는데 말이다.
- 근데 왜 mappings일까?
  - 한국 엘라스틱에서 올린 글( 미처 못 다한 이야기들 - Elastic{ON} Tour Seoul )에서 이유를 찾을 수 있다.
    - 타입(Type) : 엘라스틱 서치 6.0부터는 타입이 하나로 제한됩니다. 단, 5.x에서 만들어진 인덱스는 6.0으로 업그레이드 했을 때도 그대로 여러 타입을 사용할 수 있습니다.
  - 즉, 이전에는 mappings가 정확한 의미를 잘 표현한 것이고, 6.x에서 달라졌으나, 그 이름을 그대로 활용하는 상태라고 이해된다. 그냥 mapping이라고 하나 추가해도 될 듯 한데...
p83 기존 인덱스에 타입 매핑 생성
- 인덱스를 생성한 후에도 인덱스 타입을 추가할 수 있다.라는 말이 있는데, 이게 상황에 따라 다르다.
- 이전 페이지인 p 82 에서 이미 catalog에 대해서 my_type이라는 타입을 만들어 두었다.
- 위에 설명한 mappings에 대한 설명을 적용하면, 한개의 인덱스에서는 두개의 타입을 넣을 수 없다. 그러므로 이미 my_type이라는 타입을 넣어 두었으므로, p 83에서 추가하려고하는 catalog 타입을 넣으려고 하면, 아래와 같이 에러가 발생한다.
- 그러므로, 정확한 설명은 인덱스를 생성하고, 타입을 추가하지 않은 경우, 나중에 타입을 추가할 수 있다. 라고 되어야 한다. 이를 모두 자세히 나열하면 아래와 같은 것이다.
  - DELETE /catalog로 먼저 생성해둔 catalog 인덱스를 삭제
  - PUT /catalog로 인덱스만 생성
  - PUT /catalog/_mapping/category { ... }로 category 라는 타입을 추가하면서 mappings까지 설정
  - GET /catalog/_mapping/을 통해서 category라는 타입과 mappings가 잘 설정 되었는지 확인.
- 일반적으로 mapping을 만들때, 전문검색(full text search)할 대상의 type을 text 로 주게 된다. 예를들면 뉴스의 내용은 전문검색이 필요하므로 type을 text로 설정해야 할 것이다.
p88 JSON 응답 형식 부분
- 기본적으로 모든 요청에 대한 응답은 형식이 없다. .. 어떠한 형식도 지정되지 않는다. 부분의 번역이 언뜻 이해하기 어렵다.
- 단 한줄로 json응답이 오면 응답 형식이 없는 상태이고, 엔터와 탭으로, 예쁘게 json 응답이 오는것을 응답 형식이 있는 상태라고 해석하고 있다.
- 아마도, "포맷(format)"을 "형식"이라고 번역했지 않을까 생각해 본다.
- 기술 서적이라면(적어도, 이정도의 고난이도?? 기술을 다루는 책이라면.. 모든것을 번역할 필요가 있을지 의문이다... )
- 책에서는 ?pretty=true를 사용했지만, 단순히 ?pretty만 사용해도 json 형태의 응답이 예쁘게 출력 된다.
- 또한 JSON 형식 뿐만 아니라, yaml 형태로 출력 할 수도 있다. ?format=yaml를 이용해서 쿼리를 날리면 된다.
p90 GET /_search의 결과물 부분
- 책에서는 나오지 않지만, 실제로 쿼리를 실행하면, 우리가 만든 category 뿐만 아니라, 우리가 만들지 않은 .kibana_1이라는 인덱스를 발견할 수 있다.
- 이건 말 그대로 kibana용 인덱스이다. 언제 이런게 만들어졌나고?
- kibana를 최초로 실행시키면 아래의 로그를 볼 수 있다.

03장 유사도 검색

이후 부터 용어라는 말이 나오는데, 영어로는 term이다. ( 사실 이미 p73 등에서 등장한 말이다.) 역색인시 사용하는 key 정도로 이해하고 우선 넘어 가면 될 듯 하다. ( key는 일래스틱 서치와 같이, 여러개의 단어로 이루어져 있을 수도 있을것 같다. - 정확하지 않음.)
p94 전문검색 이라는 용어가 나오는데, 全文검색이다. 영어로는 Full Text Search
텍스트 분석기는 아래의 3가지 과정은 순차적으로 거친다
1. 문자 필터(Character filters) : 0개 이상 - 문자열 치환 등 문자열 처리
2. 토크나이저(Tokenizer) : 정확히 1개 - 문자열을 쪼개주는 역할, 역색인 만들때 사용
3. 토큰 필터(Token filters) : 0개 이상 - 쪼개진 문자열을 다시 처리하는 역할, 각 토큰으로 들어온 문자열을 소문자로 바꾸거나, 불용어(The, a, an, is ...)를 없애주는 등의 처리 가능
토크나이저(Tokenizer)는 문자열을 잘라주는 역할인데, 표준분석기, 언어분석기, 공백분석기 등이 있다.
이 중에서 제일 재미난건 언어 분석기인데, 사실상 이 놈의 핵심인것 같다.
재수좋게도, 2018년 8월 24일에 엘라스틱에서 공식 한국어 분석 플러그인 '노리'를 만들었다. 아싸!!
- 용량이 작다.
- 속도가 빠르다.
- 공식지원이니 설치가 편하다.
설치하는 방법과 간단한 사용방법은 Elasticsearch 6.4 기본 한글 형태소 분석기 노리 (nori) 설명 및 사전 추가하기를 방문해서 확인해 보자.
REST api로는 아래와 같이 호출해 보면, 아래와 같이 주요 단어를 잘 뽑아 주는것을 확인해 볼 수 있다.
뉴스 관련 데이터로 몇가지 테스트를 해 보았다.
- 뉴스의 카테고리는 category라는 이름으로 그냥 text로 만들었고, title과 contents는 "nori" 분석기를 달도록 설정했다.
- 이후 news/article type에 30여개의 document를 추가 했다.
- 뉴스 데이터 category에 "경제"를 넣어 두고, 검색할때 "category" : "경제" 를 검색하면 아래와 같이 잘 찾아 진다.
- 하지만 "category" : "경제적"을 검색하면 제대로 찾아 지지 않는다.
- 이제 contents에도 똑같이 경제를 검색해 보자. "경제"라는 글자가 contents에 있는 경우에는 당연히 잘 검색 된다.
- 이제 contents에 경제적을 검색해 보자. "nori" 분석기가 잘 동작했다면, "경제적"이라는 전체 단어가 아니라, "경제"라는 단어만 있어도 잘 검색해 줄 것이다. 아래 결과를 보면 "경제"가 들어간 결과 뿐만 아니라, 경제를도 잘 검색 된다는것을 알 수 있다. 즉, 분석기가 글자를 잘 분석해서 역색인 했다는것을 알 수 있다.

구조화된 데이터 검색

반면, 비슷것을 찾아주는게 아니라 정확하게 색인 된 것만 찾으려면 term 을 사용해서 찾으면 된다.
- match를 사용하는 위의 예제에서는 경제적을 검색어로 써도 경제를 찾거나, 경제를을 찾아준다.하지만 정확하게 색인된 것만 찾으려면 term을 사용하자
- term을 사용해서 경제적을 찾으며 아무것도 찾아지지 않는다는것을 알 수 있다.
- 그렇다면 contents에 실제로 있는 경제를이라는 검색어를 term을 사용해서 검색하면 어떻게 될까? 아래와 같이 검색 되지 않는다.
- term은 색인된 것만을 검색한다. nori 분석기에서는 경제를을 색인한것이 아니라, 경제만 색인 했기 때문에 term을 사용했을때 경제를이라는 검색어로는 찾아지지 않는것으로 보인다.
- term을 사용하여 경제를 찾으면 제대로 찾아 지는것을 알 수 있다.
title이나 contents 필드는 text 타입으로 설정해 두었다. 그러므로 match로 검색을 하면 nori 분석기를 통해서 비슷한 것도 찾아 준다. 하지만 만약 category 필드와 같이 keyword 타입으로 설정해 두었다면, nori 분석기등을 통하지 않고 "정확한 것"만 검색하도록 된다.

전문 텍스트 검색

match검색시 검색어에 오타가 있을 경우를 대비한 fuzziness값을 줄 수도 있다.
- fuzziness에 1, 2 등의 값을 주면, 몇 글자가 틀려도 알아서 찾아 준다.
- 예를 들어 경조라고 잘못 검색어를 입력해도,공조, 경찰, 경제등을 찾아 준다.
반면 match에는 여러 검색어에 정확하게 맞는 쿼리를 보내고 싶을 때는 match_phrase를 사용한다. 구글에서 " " 로 감싸서 쿼리하는것과 비슷하다.
- 단, 검색어에서 순서는 정확하게 맞지만, 일부 단어가 생략되는것을 허용하려면 slop 값을 조정하면 된다.
그외 이것 저것은 생략. 나중에 필요할 때 찾아 보자

04장 일래스틱서치 분석

Metric 집계

Aggregation(어그리게이션)을 여기서는 집계라고 부른다. 쉽게 생각하면 걍 숫자 랑 관련되는 통계?를 내는것이라고 생각하자.
숫자 관련 통계는 합계(sum), 평균(avg), 최소(min), 최대(max), 이상의 4개를 모두 한번에 보여 줄 수 있는 통계(stats)가 있다. 아래는 이미지 데이터에서 각 이미지 용량의 합계, 평균, 최소, 최대 값을 출력한 것이다.
제곱, 분산, 표준편차, 표준편차 구간등을 한꺼번에 보여 줄 수 있는 확장통계(extended_stats)도 있다.
만약 데이터를 구성할때, 자식을 가지도록 구성했다면, aggs를 사용할때, nested라는걸 사용해서 처리해야 한다. ... (아.. 어려워... ) 아래는 이미지 데이터에서 각 이미지 해상도의 너비와 높이에 대한 통계 정보를 출력한 것이다.
unique한 값의 갯수를 세고 싶을때는 cardinality를 사용하면 된다. 아래는 이미지 데이터에서 unique한 Tag 갯수를 출력한 것이다. 이미지 데이터에 있는 Unique한 Tag 갯수는 약 10만개다.

Bucket 집계

문자열 데이터 버켓팅에서 Terms 집계 : 관련 내용은 아래에 나오는 fielddata 관련 부분을 확인해 보면 예제를 볼 수 있다.
숫자 데이터 버켓팅에서 재미난게 있다. histogram 집계인데, 일정 간격으로 숫자를 쪼개서 갯수를 세어주는게 있다. 아래는 이미지 데이터에서 이미지를 2Mbyte 단위의 용량별로 갯수를 센 결과를 출력한 것이다.
일정 간격이 아니라, 특정 간격으로 나눠서 보고 싶다면, range와 ranges, 그리고 from, to를 사용하면 된다. 단, to의 값은 포함하지 않는다. 자세한건 생략.ㅋ. 책을 찾아 보도록 하자. ( 170페이지 참고 )
그 이외에, A이면서 B인 경우 갯수 세기, 시간별로 쪼개서 확인하고, 지리적 위치를 기반으로 쪼개서 확인하기 등이 있다. 자세한건 책으로... ㅋ

05장 로그 데이터 분석 (아직 안 읽음)

로그스태시 아키텍처

로그스태시는, "입력", "필터", "출력"으로 이루어 진다. 즉, 이 세가지로 데이터를 처리 할 수 있다.
로그스태시는 기본적으로 파이프라인 단계별로 이벤트를 버퍼에 담기 위해 인 메모리 바운드 큐를 사용한다. 로그스태시가 불안정한 상태로 종료되면 인메모미레 저장된 이벤트는 손실 된다. 데이터 손실 방지를 위해서 영구 큐를 사용해 실행중인 이벤트를 디스크에 유지할 수도 있다.(LOGSTASH_HOME/config/logstash.yml 파일에서 queue.type:persisted 설정, RAM을 1GB사용하는데 변경하려면 LOGSTATSH+HOME/config/jvm.options에 Xms, Xmx를 변경 가능)
p210 윗쪽 예제에서 mutate{ 를 닫아두는 } 가 없다. 그러므로 잘 닫아 주어야 한다.

입력 플러그인(Input Plugin)

File
- p216 각 파일의 모든 변경 사항을 추적하고, 마지막으로 읽은 위치를 기반으로 해당 시점 이후 데이터만 전송한다. ... 각 파일에서 현재 위치는 sincedb라는 별도로 분리한 파일에 기록한다. 따라서 로그스태시를 중지하고 다시 실행해도 로그스태시가 실행되지 않은 순간에 추가된 행을 빠뜨리지 않고 중단된 부분부터 작업을 수행할 수 있다.
- 여러 파일을 설정할 수도 있고, 각종 옵션을 조정하며, 입력으로 사용할 위치(Line?)도 정할 수 있다.
Beat
- 일래스틱비트에서 발생하는 이벤트를 수신할 수 있음.
JDBC
IMAP : IMAP 서버에서 이메일을 읽을 수 있음. host, password, user 필수.

출력 플러그인(Output Plugin)

Elasticsearch : 권장하는 방법. 자동으로 localhost:9200 사용. 필요하다면 각종 옵션으로 다른곳에 저장 가능.
CSV
Kafka : 카프카 토픽에 이벤트를 작성할 때 사용. 필수 매개변수는 topic_id
PagerDuty : 알림을 보낼 수 있는 서비스에 연동 가능

코텍 플러그인(Codec Plugin)

Input전이나, Output후에 변환을 할 수 있는 기능
JSON : 입력 플러그인에서 JSON 데이터를 디코딩, 출력 플러그인에서 데이터를 JSON으로 인코딩 할 수 있음. 여러줄로 이루어져 있는 JSON인 경우, json_lines 코덱을 사용
rubydebuga
Multiline : 여러행에 걸친 데이터를 단일 이벤트로 병합하는데 유용한 플러그인. 여러행에 걸쳐 있는 스택트레이스 또는 단일 이벤트 정보를 처리할 때 매우 편리하다.

인제스트 노드

이전 일래스틱서치에서는 데이터를 사전 변환하려고 하면 별개의 프로그램을 이용해서 처리해 주었어야 했는데, 이제 인제스트 노드라는게 나왔다.
인제스트 노드는 일래스틱서치에서 색인을 생성하기 전에 도큐먼트를 사전 처리하고, 도큐먼트를 풍부하게 해 주는 경량 솔루션.
이 기능 덕분에 로그스태시 필터 부분을 제거하고 자체적으로 로그 데이터를 처리하고 변환할 수 있게 되었다.
gsub, grok, convert, remove, rename 등 20개가 넘는 내장 프로세서 보유
내장 프로세서를 조합해서 _ingest/pipline으로 PUT 해서 파이프라인을 정의할 수 있다.
대신 정의된 파이프라인을 사용해서 데이터를 밀어 넣어야 한다. ( .../mytype/1?pipeline=somepipeline { .... })
파이프라인이 잘 동작하는지 확인하기 위해서 시뮬레이트 해 볼 수 있는데, endpoint에 그 정보를 주면 된다. (.../_ingest/pipeline/somepipeline/_simulate { ... } )

06 로그스태시를 활용한 데이터 파이프라인 구축

로그스태시를 사용한 로그 구문 분석 및 강화

필터 플러그인

CSV 필터 : CSV 파일을 쪼개고, 컬럼 이름을 정의 하는 등의 작업 가능
Mutate 필터 : 필드 변환, 게저, 수정, 이름변경 등
Grok 필터 : 불규칙한 데이터를 분석해 구조화하고, 구조화된 데이터를 쉽게 쿼리하고 필터링 하는데 자주 사용되는 강력한 플러그인. 간단히 말해, 특정 행에서 정규식 기반의 패턴이 일치하도록 하는 방법
Date 필터 : 시간을 처리(포맷 정의 가능)
Geoip 필터
- ip주소로 위치 정보를 추가하는 필터(GeoLite2 City - Maxmind 회사 제품, CCA ShareAlike 4.0 라이선스 - 데이터베이스 사용)
- 문자열로 된 IP를 Geoip 필터를 통하면, 위도, 경도, 나라, 도시명 등이 나옴.
UserAgent 필터 : 웹브라우저의 UserAgent를 분석

비트 소개

엣지 서버에서 에이전트로 설치되는 경량 데이터 수집기.
립비트라는 라이브러리로 구성되어 있음.
비트는 입력, 출력, 옵션 설정, 이벤트 처리, 로깅 구현이 되어 있고, 데이터를 일래스틱서치, 로그스태시, 레디스, 카프카 등으로 보낼 수 있도록 API를 제공함.
로그스태시와 비트의 차이점
- 비트는 경량 에이전트로 더 적은 자원 소모(비트는 일반적으로 Go 언어로 작성되어, JVM이 필요 없이 동작 가능)
- 비트는 엣지 서버에 설치해서 사용하는것이 일반적임
- 하지만 비트는 이벤트 변환 및 분석, 즉 로그스태시에서 제공하는 강력한 기능은 없음.
- 로그스태시는 여러 자원에서 데이터를 수집하고 변환하는 가공 및 입력, 필터, 출력 플러그인 제공.
- 로그스태시는 자원에 더 초점을 두고 있으며, 일래스틱 스택 외에 독립된 제품으로도 사용 가능
- 로그스태시는 데이터 처리를 위해 이벤트를 수신하는 엣지 서버보다는 전용 서버에 설치하는것이 좋다.

일래스틱비트

파일비트 : 로컬파일에서 로그 수집
메트릭비트 : 운영체제 및 서버에서 실행중인 서비스 메트릭을 주기적으로 수집. 아차피, 몽고DB, 레디스 등 다양항 서비스의 멭릭을 수집. 모니터링하기 좋음.
패킷비트 : 실시간 네트워크 패킷 분석기. 애플리케이션 서버간 네트워크 트래픽을 캡처하거나 HTTP, Mysql, Redis, 맴캐시등의 프로토콜 해석 가능. 요청 응답 상관관계 기록 가능
하트비트 : 서비스 활성 상태 여부, 서비스 가능 여부 모니터링. 주기적으로 실행중인 서비스 상태를 모니터링 가능, ICMP, TCP, HTTP 지원
윈로그비트 : 윈도우 플랫폼에 특화된 비트. 윈도우 API를 사용해 여러 이벤트를 수집.
오디트비트 : 6.0 버젼에 새로 구현. 사용자 활동 모니터링, 니룩스의 auditd를 건드리지 않고 데이터 분석 가능. 실시간으로 변경되는 파일을 설정한 출력으로 보내 잠재적인 보안 정책 위반 행위를 식별하는데 사용 가능.

커뮤니티 비트

스프링부터. 레디스 로그, 엔진엑스 상태, mysql 결과, 몽고DB, 구글애널리틱스, Apache, 아마존 제품 데이터 수집

파일비트

아키텍처

Prospectors : 로그를 읽을 파일 목록을 구분하는 역할
Harvester : 실제 로그를 읽는 역할, 하나의 Harvester가 개별로 파일을 담당하며 파일을 열고 닫는다. 마지막 읽은 위치를 레지스트리에 관리한다.
Spooler : Harvester가 읽은 데이터를 전달 받는다. 이벤트를 집계하고 설정한 출력으로 전달한다.
파일 비트는 이벤트가 지정한 위치로 최소 한 번은 데이터 손실 없이 전달 되도록 보장한다.
파일비트가 일래스틱서치에 저장 될 때는 filebeat-YYYY.MM.DD 패턴의 index에 저장하게 된다.
Prospectors 설정
- input_type, path등을 설정 할 수 있다.
- 재미난건 exclude_lines 라는 설정을 하면 정규식과 일치하는 행을 제거한다는것이다.
- 단순히 파일의 선택뿐만 아니라, 내용을 읽어 보고 전달 할지 말지를 전할 수 있다는것이다.
출력 설정 : 일래스틱서치에 넣을때, 정의해 둔 파이프라인을 통해서 넣을 수도 있다.
모듈 : 자주 사용되는 형태의 데이터를 수집, 구문분석하는데 사용된다. ( Apache2, Auditd, MySQL, Nginx, Redis, Icinga, System )

07 키바나를 활용한 데이터 시각화

키바나는 node.js로 실행되는 웹 어플리케이션.
키바나는 일래스틱서치와 같은 버젼을 사용하는 것을 권장. 마이너 버젼도 같은것으로 사용하도록 하자.
기타 생략

08 일래스틱 엑스팩

최근에는 엑스팩이 아니라, Elastic Stack 확장 기능으로 이름을 바꾸었다.
엑스팩은 보안, 알림, 모니터링, 보고서, 머신러닝, 그래프 기능을 제공
기본적인 기능은 무료이나 머신러닝, 그래프 등은 유료
일래스틱서치 클러스터는 일반적으로 여러 노드로 구성되어 있으므로 클러스터에 속한 각 노드의 엑스팩을 설치해야 한다.
키바나에서도 엑스팩을 설치해야 한다.
엘라스틱서치는 내장 보안 기능이 없다. 그러므로 누구나 엘라스틱서치에 접근할 수 있음. 이러한 문제를 해결하기 위해서 일반적으로는 일래스틱서치 앞단에 방화벽을 두거나, 엔진엑스, HAProxy등 리버스 프록시를 사용해서 보안을 강화 한다.
하지만, 엑스팩을 사용하면 사용자 인증 및 권한 관리, 노드 클라이언트의 인증 및 채널 암호화, 감시 등을 지원한다.
키바나에서 사용자 추가/삭제, 권한 관리 가능(심지어 도큐먼트의 필드별로도 권한 관리가 가능하다. )
Watcher라는 구성요소는 일래스틱서치에 저장된 데이터의 변경 사항이나 이상징후를 자동으로 감지하고 적절한 조치를 취할 수 있는 기능 제공. 알림 기능을 설치하면 기본적으로 활성화 됨.

09 일래스틱 스택 운영 환경에 적용하기

일래스틱 스택 설정

역색인을 필요로하는 메모리 관련 작업
RAM에 저장할 수 있는 데이터가 많아질수록 성능이 좋아진다. 하지만 데이터 타입에따라 연산이 다를 수 있으므로 항상 그러한것은 아니다.
일래스틱서치는 비교적 쉽게 수평 확장 가능
- 초기에는 CPU 코어 8개, RAM 16GB 혹은 32GB로 사용하는것이 좋다.
- 어차피 일래스틱서치의 JVM Heap이 32GB 이상 메모리를 잡을 수 없다.
- 그러므로 64GB 이상의 RAM을 가진 인스턴스를 사용할 필요가 없다.
- 오히려 무거운 집계 연산을 수행하는 경우에는 SSD를 사용하는것이 좋다.
운영체제는 리눅스를 추천하나, 어느것을 써도 무방하다.
일래스틱서치 노드 설정
- JVM Heap 크기
  - -Xms와 -Xmx를 동일하게 설정한다. 힙이 많으면 좋겠지만, 그 만큼 Full GC도 많이 일어난다. Full GC가 일어나면 일래스틱 서치가 잠시 멈출 것이다.
  - 설정할 수 있는 RAM의 최대 크기는 32GB다.
  - 주의사항 : 일래스틱서치의 JVM에 총 메모리 기준 50% 이상을 할당하지 말아야 한다. 아차피 루씬의 파일 시스템 캐시에 충분한 메모리가 필요하기 때문. 궁극적으로 일래스틱서치 노드에 저장되는 데이터를 아파치 루씬 인덱스로 관리.
  - 확장이 필요하다면, 노드를 추가하는 방법을 선택할 것
- 스와핑 비활성화 : Swapping을 설정하면 OS가 메모리의 내용을 Disk로 옮기는 동작을 하게 됨. 그러므로 동작이 늦어 질 수 있음
- 파일 디스크립트 : 리눅스 및 맥 OS는 프로세스가 파일을 유지할 수 있는 파일 디스크립터 개수에 제한이 있음. 기본적으로 이 값이 매우 낮기 때문에 변경을 고려해야 한다.
- 스레드풀 및 가비지 컬렉터 : 색인, 검색, 집계 등 다양한 연산을 할 때 JVM의 Thread Pool을 사용한다. JVM의 Thread Pool 이나 가비지 컬렉터의 설정을 변경하면 일반적으로 악영향을 미치므로, 되도록이면 스레드풀과 가비지 컬렉터 설정을 변경하지 않고 사용하는것이 좋다.
클라우드 환경 사용시 고려사항(대표적으로 AWS)
- 인스턴스 타입 선택 : 시작하기 적당한 것은 m3.2xlarge(CPU 8core, 30GB RAM, 80GB SSD 2개)
- 포트(port)를 노출하지 않도록 변경
- 프록시 요청 : 요청 제어시 엔진엑스 또는 아파치와 같은 리버스 프록시 활용
- 로컬 주소에 Http 바인딩 : 인스턴스가 VPC 내에 위치 할 것이므로, 클라이언트와 통신할 필요가 없는 노드는 쿼리를 Http를 이용해서 수신.
- EC2 검색 플러그인 설치 : 같은 네트워크에서 다른 노드를 찾는 방법
- S3 저장소 플러그인 설치 : 정기적 백업을 위해 저장해 둘 공간
- 주기적인 스냅숏 저장

인덱스 별칭

원래 만들어 둔 인덱스의 이름을 변경해야 하는 경우, 기존에 배포된 애들이 문제가 될 수가 있다.
이때는 별칭을 생성해서, 기존의 애들은 잘 동작하게 하고, 새로운 이름으로 사용 할 수도 있다.
원본 데이터 이름이 A, B, C 로 3개가 있다고 하면, 별칭은 data라는 이름으로, 원본을 변경해 가면서 작업을 진행할 수도 있을 것이다.

기타

인덱스를 만들고 나면 샤드 갯수를 변경할 수 없음. 처음 만들때 잘 정해야 함.
단일 인덱스에 대규모 데이터를 저장하는것 보다, 시간 기반 인덱스를 여러개 만들어서 보관하는것이 더 편리하다.
- 1개월씩의 데이터를 각기 다른 인덱스로 만들었을때, 6개월이 지난 데이터를 삭제하는것은, 그냥 6개월이 지난 인덱스를 지우면 되기 때문이다.

10 데이터 분석 애플리케이션 구축

실제 데이터를 가지고 시각화 하는것까지 구축하는 예(생략)

11 서버 인프라 모니터링

매트릭비트 설치 및 운영 방법
Mongodb, 시스템메트릭 등에 대한 설명(생략)

기타 정보

실제로 해 보면서 겪었던 문제 정리

fielddata를 true로 주게 되면 역색인 정보를 바로 검색해 볼 수 있다.
- 뉴스에 나오는 용어를 찾기 위해서는 contents의 역색인 정보를 뒤져야 하는데, 이걸 그냥 뒤져 볼 수 있는 방법이 없다.
- vectorterms 인가 하는 방식을 쓸 수 있는데, 그건 id가 지정된 경우에만 사용할 수 있다.
- mapping을 생성할때, 에 "fielddata" : true를 주게 되면, 역색인 정보를 바로 검색해서 볼 수 있다.
- 역색인 정보를 검색하려면 아래와 같이 호출하면 된다.
하지만 fielddata를 true로 주면, 메모리 문제가 부족하다면서 검색이 안되는 경우도 있다.
- 엘라스틱 서치를 띄울때 메모리를 더 주면 해결 되더라.
- /etc/elasticsearch/jvm.options 파일에서 -Xms와 -Xmx 값을 더 늘려 주도록 하자.
- 내가 설치 했을때는 1g로 되어 있었다. 2g 정도로 주니깐 어느정도는 잘 동작하더라.
20만건 정도의 데이터를 엘라스틱서치에 넣는데는 얼마나 걸릴까?
- http request의 POST 방식으로 데이터를 하나씩 넣어 보았더니, 668초가 소요되었다.
- logstash 로 json 파일을, console에 로그를 찍어 가면서 넣어 보았더니, 350초가 소요되었다.
- logstash 로 json 파일을, console에 로그를 찍지 않고 넣어 보았더니, 70초가 소요되었다.
- 그러니 나 처럼 무식하게, http POST로 데이터를 밀어 넣지 말고, logstash를 좀 공부하도록 하자.
- 그리고, console에 log를 찍는것은 생각보다 오랜 시간이 걸린다는것을 알 수 있다. http request POST방식으로 데이터를 넣을때, console에 log를 일일이 출력하면 몇배로 더 늦어진다. 그러니 로그는 필요한 만큼만 찍자.