Kibana

설치

$ docker pull kibana
$ docker run --link some-elasticsearch:elasticsearch -d kibana # default로 kibana를 실행시키는 명령어
$ docker run --link some-elasticsearch:elasticsearch -d kibana --plugins /somewhere/else # flag를 추가해 kibana를 실행시키는 명령어
$ docker run --name some-kibana --link some-elasticsearch:elasticsearch -p 5601:5601 -d kibana # 해당 이미지의 기본포트는 5601 따라서 5601 포트를 host 포트와 바인딩
$ docker run --name some-kibana -e ELASTICSEARCH_URL=http://some-elasticsearch:9200 -p 5601:5601 -d kibana # elasticsearch url 환경변수를 통해 elasticsearch의 주소를 바인딩

위와 같이 진행했을 때, http://ip주소:5601로 브라우저로 접속할 수 있습니다. 

세팅

kibana를 사용하기위해 적어도 한개의 인덱스 패턴을 설정해야 합니다. 설정한 인덱스 패턴은 elasticsearch 인덱스를 식별하는데 사용되고 필드를 구성하는데에 사용됩니다. 와일드카드(*)를 사용할 수 있기 때문에 먼저 *로 패턴을 주면 다음과 같은 페이지로 넘어갑니다.

해당 index 이름 or 패턴을 지정하기 위해선 elasticsearch에 데이터가 쌓여있으면 좋습니다. 먼저 elasticsearch에 해당 값을 넣습니다.

curl -XPUT http://localhost:9200/log-2016-07-11/hadoop/1 -d '{     "projectName" : "hadoop",
    "logType": "hadoop-log",
    "logSource": "namenode",
    "logTime":"2012-12-27T02:02:02",
    "host": "host2 ",
    "body": "org.apache.hadoop.hdfs.server.namenode.FSNamesystem"
}'

다음 kibana의 logstash-*부분을 log-*로 변경하고 아무 곳을 클릭하면 다음과 같은 화면을 확인할 수 있습니다.

Index name or pattern 아래의 Time-field name은 사용자가 잡을 필요 없이 elasticsearch에 저장되어 있는 필드를 확인한 다음 자동으로 잡아줍니다.

다음 clear로 가면 다음과 같은 elasticsearch의 필드값들을 확인할 수 있습니다.

Log Stash

설치

$ docker pull logstash
$ docker run -it --rm logstash logstash -e 'input { stdin { } } output { stdout { } }' # 커맨드라인 상에서 실행을 하려면 다음과 같이 사용
$ docker run -it --rm -v "$PWD":/config-dir logstash logstash -f /config-dir/logstash.conf # logstash.conf파일을 직접 수정해 커맨드라인 상에서 실행을 하고자 할 때
 
(elasticsearch와 통신할 수 있는지 확인해봐야함)

문법

logstash는 입출력 도구이며, input > filter > output 의 pipeline구조로 이루어져 있습니다. 이러한 input, filter, output 설정은 직접 config 파일을 작성하여 설정시켜야 합니다.

input {
        .
        .
}

filter {
        .
        .
}

output {
        .
        .
}

예제

가장 기본적인 설정으로 커맨드라인으로 사용자에게 입력을 받고 출력을 하는 설정으로 예제를 시작하겠습니다. 

$ cat logstash.conf
 
input {
		stdin {}
}
 
output {
		stdout {
				codec =>  rubydebug {}
		}
}
 
$ docker run -it --rm -v $HOME/logstash:/config-dir logstash logstash -f /config-dir/logstash.conf
Settings: Default pipeline workers: 2
Pipeline main started
hello world! ### hello world!를 입력
{
       "message" => "hello world!",
      "@version" => "1",
    "@timestamp" => "2016-07-12T11:25:48.536Z",
          "host" => "61b494acbb39"
}

stdout 설정에 codec으로 rubydebug를 추가했는데 출력을 보기좋은 json 포맷으로 보여줍니다. 여기서 message, @version, @timestamp, host 필드는 logstash에 내장되어 있는 필드입니다.

filter

filter설정을 적용하면, 입력으로 들어온 데이터를 가공하는 작업을 할 수 있습니다. 예를 들어, json 형식으로 input 되었다면 json의 필드를 추가, 삭제, 필드의 값을 조작할 수 있습니다. 

다음 json 데이터를 가공하는 예제를 하기 위해 config 파일을 설정합니다.

$ cat logstash.conf
 
input {
        stdin { }
}

filter {
        json {
                source => "message"
                add_field => { "add_key1" => "add_value1"  }
                add_field => { "add_key2" => "add_value2 %{value}" }
                remove_field => [ "age" ]
        }
}

output {
        stdout {
                codec => rubydebug { }
        }
}

filter로 json을 추가하여 정의를 했습니다. source 설정은 가공할 데이터가 들어 있는 필드를 말합니다. (output의 필드) add_field는 출력 시, 필드를 추가하는 것으로 위에서 고정한 값을 출력할 수도 있고 기존 source 데이터의 필드값을 '%{필드명}'을 사용해 출력할 수도 있습니다. (연산이 가능한지 테스트 요망)

$ docker run -it --rm -v $HOME/logstash:/config-dir logstash logstash -f /config-dir/logstash.conf
Settings: Default pipeline workers: 2
Pipeline main started
{"name":"lee", "age":"11", "value":"edit value?"}  ### json 데이터를 입력, 형식이 json이 아닐 시, 에러
{
       "message" => "{\"name\":\"lee\", \"age\":\"11\", \"value\":\"edit value?\"}",
      "@version" => "1",
    "@timestamp" => "2016-07-12T11:41:20.594Z",
          "host" => "c6ee75a7e14d",
          "name" => "lee",
         "value" => "edit value?",
      "add_key1" => "add_value1",
      "add_key2" => "add_value2 edit value?"
}

결과로는 추가하고자 하는 필드 2개(add_key1, add_key2) 와 삭제하고자 하는 필드 1개(age)가 업데이트가 된 것을 확인할 수 있습니다.

플러그인

input, output, filter, codec의 플러그인은 매우 많기 때문에 아래의 링크에서 확인해 필요한 플러그인을 사용해야 합니다. (elasticsearch의 색인작업을 해주는 output 플러그인도 존재)

• input 플러그인: https://www.elastic.co/guide/en/logstash/current/input-plugins.html
• output 플러그인: https://www.elastic.co/guide/en/logstash/current/output-plugins.html
• codec 플러그인: https://www.elastic.co/guide/en/logstash/current/codec-plugins.html
• filter 플러그인: https://www.elastic.co/guide/en/logstash/current/filter-plugins.html

Elastic Search와 연동

elasticsearch의 output 플러그인은 node, transport, http 3가지 프로토콜이 있습니다. 여기서는 elasticsearch 클러스터의 9200번 포트로 직접 접속해 데이터를 전송해주는 방식인 http 프로토콜을 사용해 연동합니다.

현재 output 플러그인의 elastic search는 http 프로토콜만 지원하고 있습니다. 

다음과 같이 config 파일을 수정해 줍니다. 

$ cat logstash.conf
input {
        stdin {
                codec => json
        }
}
output {
        elasticsearch {
                hosts => "elasticsearch ip:port"
                index => "school"
                document_type => "students"
        }
        stdout {
                codec => rubydebug { }
        }
}
 
$ docker run -it --rm -v $HOME/logstash:/config-dir logstash logstash -f /config-dir/logstash.conf
Settings: Default pipeline workers: 2
Pipeline main started
{"name":"lee", "class":"a"} # 다음과 같이 json 전달
{
          "name" => "lee",
         "class" => "a",
      "@version" => "1",
    "@timestamp" => "2016-07-13T11:01:48.959Z",
          "host" => "2ecc38a0f260"
}

출력이 정상적으로 잘 되어 head 플러그인을 확인해 봅니다.

원래는 Jordan Seberius라는 노드 1개만 생성했지만 색인작업을 진행하였더니 Unassigned가 생성되었습니다. (노드가 1개라 그런지 설정을 잘못해서 그런지 확인필요)

두번째 row를 보면 위 logstash.conf 파일에서 설정해 준 대로, 'school' 인덱스와 'students' 타입이 동적으로 생성되며, 색인이 성공했음을 확인 할 수 있습니다. 

더 자세한 내용은 https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html를 참고하면 됩니다.

Template 사용 - 확인 필요

템플릿을 사용해 미리 index와 type의 스키마를 정해놓고 데이터를 색인할 수 있습니다.

$ curl -XPUT 'elasticsearch ip:9200/_template/school?pretty' -d '{
>     "template" : "school",
>     "settings" : { "index.refresh_interval" : "5s" },
>     "mappings" : {
>         "students" : {
>             "properties" : {
>                 "class" : { "type" : "string", "store" : "yes", index : "not_analyzed" },
>                 "name" : { "type" : "string",  "store" : "yes" },
>                 "address" : { "type" : "string",  "store" : "yes" }
>             }
>         }
>     }
> }'
{
  "acknowledged" : true
}

'students'라는 인덱스 템플릿을 위처럼 rest api로 생성했고 "acknowledged" : true 로 생성이 정상적으로 된 것을 확인 할 수 있습니다.

다음, logstash가 해당 템플릿을 사용해 색인할 수 있도록 설정해야합니다.

elasticsearch {
                host => "localhost"
                index => "school"
                index_type => "students"
                protocol => "http"
                template_name => "school" # 바로 여기 설정
        }
}
 
$ docker run -it --rm -v $HOME/logstash:/config-dir logstash logstash -f /config-dir/logstash.conf
Settings: Default pipeline workers: 2
Pipeline main started
{ "class" : "A", "name" : "iron man", "address" : "newyork" }
{
         "class" => "A",
          "name" => "iron man",
       "address" => "newyork",
      "@version" => "1",
    "@timestamp" => "2016-07-13T10:49:13.128Z",
          "host" => "6cdf7452aea1"
}

템플릿을 적용하지 않은 경우

Elasticsearch의 기본 idea는 realtime 으로 document를 색인하는것이여서 동적으로 인덱스와 타입이 생성됩니다. 위의 경우는 정해진 스키마없이 동적으로 인덱스와 타입이 생성된 경우이며 dynamic_templates 라는 기본 템플릿이 적용됩니다.

템플릿을 적용한 경우

위에서 생성한 템플릿의 필드설정대로, 'class' 필드는 index 설정이 'not_analyzed'로 되어있습니다. 템플릿이 정상적으로 적용되어 데이터가 색인되었다는 증거입니다.

templates에 관해 더 자세한 것은 https://www.elastic.co/guide/en/elasticsearch/reference/2.3/indices-templates.html에서 확인할 수 있습니다.

Elastic Search

설치

$ docker pull elasticsearch # 이미지 다운로드 $ docker run -d -p 9200:9200 --name elastic elasticsearch # 기본세팅으로 바로 실행 $ docker run -d -p 9200:9200 --name elastic elasticsearch elasticsearch -Des.node.name="TestNode" # 옆과 같이 flag를 달 수 있음 $ docker run -d -p 9200:9200 --name elastic -v "$PWD/config":/usr/share/elasticsearch/config elasticsearch # 수정한 config파일을 적용하여 컨테이너를 실행할 때 $ docker run -d -p 9200:9200 --name elastic -v "$PWD/esdata":/usr/share/elasticsearch/data elasticsearch # 컨테이너 내 인덱스가 저장되는 폴더를 공유합니다.

추가설치

elasticsearch에서 'head'와 'bigdesk'를 plugin으로 설치할 시, 모니터링을 할 수 있으므로 필수 플러그인 입니다.

$ docker exec -it elastic /bin/bash $ plugin --help NAME plugin - Manages plugins SYNOPSIS plugin <command> DESCRIPTION Manage plugins COMMANDS install Install a plugin remove Remove a plugin list List installed plugins NOTES [*] For usage help on specific commands please type "plugin <command> -h" # 다음과 같은 설명을 확인 할 수 있음   $ plugin install mobz/elasticsearch-head

위와 같이 설치가 전부 성공했으면, http://ip주소/_plugin/head/로 확인이 가능합니다.

config 설정

간단한 기능 테스트에는 설정 변경이 필요 없으나, 성능 테스트를 하거나 실서비스에 적용할 때에는 기본 설정에 대한 몇 가지 변경이 필요합니다.

# 클러스터를 식별하기 위한 이름이므로 유일성과 의미를 가진 이름을 사용 cluster.name: es-cluster # 노드 이름은 자동으로 생성되지만 호스트명과 같이 클러스터 내에서 식별 가능한 이름을 활용하는 것을 권장 node.name: "es-node1" # 기본값은 아래 두 값이 모두 true. node.master는 노드가 마스터가 될 수 있지에 대한 설정이고, node.data는 데이터를 저장하는 노드인지에 대한 설정. 보통은 두 값을 true로 설정하면 되고, 클러스터의 규모가 큰 경우에는 3가지 종류의 노드를 구성하기 위해 이 값을 노드별로 조정해 설정합니다. node.master: true node.data: true # 샤드와 리플리카 수를 변경하는 설정. 아래 값은 기본값. index.number_of_shards: 5 index.number_of_replicas: 1 #JVM의 스왑을 방지하려면 아래 설정 값을 true해야 함. bootstrap.mlockall: true # 클러스터 내의 각 노드의 상태 체크를 위한 타임아웃 값으로, 너무 작게 하면 노드가 클러스터에서 자주 이탈하는 문제가 발생할 수 있어 적절한 값을 설정해야 함. 기본값은 3초. discovery.zen.ping.timeout: 10s # 기본값은 멀티캐스트를 사용하지만, 실환경에서는 다른 클러스터와 노드가 섞이는 위험이 발생할 수 있으므로 유니캐스트를 사용하고 두 번째 설정 값에 마스터가 될 수 있는 서버들의 목록을 나열하는 것이 좋음. discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]

Clustering 하기

elasticsearch는 각 노드끼리 동일한 네트워크 상에 존재하면 자동으로 찾아서 클러스터링을 맺는다라고 합니다. 그래서 서버 1대에 docker로 아무런 설정없이 3개의 node를 실행했지만 각기 다른 클러스터로 묶여서 다음과 같이 각 설정을 주었습니다. 노드의 갯수는 3개로 마스터노드 1개 데이터노드 2개로 구성해봤습니다.

master node 

cluster.name: jh-cluster # 같은 클러스터끼리 묶이고자 하면 이름이 동일해야함 node.name: "jh-node1" node.master: true #해당 노드를 마스터로 임명 node.data: false index.number_of_shards: 5 # shard는 default로 지정 index.number_of_replicas: 1 network.host: 0.0.0.0 transport.tcp.port: 9300 transport.tcp.compress: true http.port: 9200 http.enabled: true discovery.zen.minimum_master_nodes: 1 discovery.zen.ping.timeout: 10s discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["ip주소:9301", "ip주소:9302"] # 클러스터링할 node의 정보

위와 같이 elasticsearch.yml을 설정한 다음, 아래와 같이 실행합니다.

$ docker run -d -p 9202:9200 -p 9302:9300 --name ela -v $PWD/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml elasticsearch

data node

cluster.name: jh-cluster node.name: "jh-node2" index.number_of_shards: 5 index.number_of_replicas: 1 network.host: 0.0.0.0 transport.tcp.port: 9301 transport.tcp.compress: true http.port: 9201 http.enabled: true discovery.zen.minimum_master_nodes: 1 discovery.zen.ping.timeout: 10s discovery.zen.ping.multicast.enabled: false discovery.zen.ping.unicast.hosts: ["ip주소:9300","ip주소:9302"]

master node 구성과 똑같이 port와 node name, discovery.zen.ping.unicast.hosts를 맞게 변경합니다.

다음 아래와 같이 컨테이너를 실행합니다.

$ docker run -d -p 9202:9200 -p 9302:9300 --name ela -v $PWD/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml elasticsearch

확인

아래의 명령어로 클러스터링이 되었는지 확인을 할 수 있습니다.

$ curl -XGET http://localhost:9200/_cluster/health?pretty=true { "cluster_name" : "jh-cluster", "status" : "green", "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 2, "active_primary_shards" : 0, "active_shards" : 0, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 }

노드들의 클러스터링이 약간 느리게 진행될 수도 있습니다.

또한 master node의 컨테이너에서 mobz/elasticsearch-head를 설치해 웹페이지에서 확인할 수 있습니다.

REST API 사용

elasticsearch는 REST API를 제공합니다.

http://host:port/(index)/(type)/(action|id)

다음은 날짜별로 인덱스를 분리하고, 프로젝트 별로 타입을 나누어 관리하고 있다. 2016년 07월 11일에 hadoop이라는 프로젝트로 들어온 로그를 문서 단위로 생성하는 과정을 REST API를 사용해 수행하는 예입니다.

#문서 생성 curl -XPUT http://localhost:9200/log-2016-07-11/hadoop/1 curl -XGET http://localhost:9200/log-2012-0712-27/hadoop/1 curl -XDELETE http://localhost:9200/log-2016-07-11/hadoop/1 #검색 curl -XGET http://localhost:9200/log-2016-07-11/hadoop/_search curl -XGET http://localhost:9200/log-2016-07-11/_search curl -XGET http://localhost:9200/_search #인덱스 상태 보기 curl -XGET http://localhost:9200/log-2016-07-11/_status

문서와 인덱스 생성

아래와 같이 요청을 보내면 인덱스와 타입이 정의돼 있지 않더라도 elasticsearch는 자동으로 log-2016-07-11 인덱스와 hadoop 타입을 생성합니다. 자동으로 생성하지 않고 명시적으로 생성하려면 설정 파일에서 action.auto_create_index와 index.mapper.dynamic의 설정 값을 false로 명시해야 합니다.

# 요청 curl -XPUT http://localhost:9200/log-2016-07-11/hadoop/1 -d '{ "projectName" : "hadoop", "logType": "hadoop-log", "logSource": "namenode", "logTime":"2012-12-27T02:02:02", "host": "host2 ", "body": "org.apache.hadoop.hdfs.server.namenode.FSNamesystem" }' # 결과 { "ok" : true, "_index" : "log-2016-07-11", "_type" : "hadoop", "_id" : "1", "_version" : 1 }   # 다음과 같이 타입을 문서에 포함할 수 있음 curl -XPUT http://localhost:9200/log-2012-12-27/hadoop/1 -d '{ "hadoop" : { "projectName" : "hadoop", "logType": "hadoop-log", "logSource": "namenode", "logTime":"2012-12-27T02:02:02", "host": "host2 ", "body": "org.apache.hadoop.hdfs.server.namenode.FSNamesystem" } }'   #요청 (POST)에서 id값을 누락할 시, 자동으로 생성됨 # 요청 curl -XPOST http://localhost:9200/log-2012-12-27/hadoop/ -d '{ "projectName" : "hadoop", "logType": "hadoop-log", "logSource": "namenode", "logTime":"2012-12-27T02:02:02", "host": "host2 ", "body": "org.apache.hadoop.hdfs.server.namenode.FSNamesystem" }' # 결과 { "ok" : true, "_index" : "log-2012-12-27", "_type" : "hadoop", "_id" : "kgfrarduRk2bKhzrtR-zhQ", "_version" : 1 }   # 문서를 삭제할 때 # 요청 $ curl -XDELETE 'http://localhost:9200/log-2012-12-27/hadoop/1' # 결과 { "ok" : true, "_index" : "log-2012-12-27", "_type" : "hadoop", "_id" : "1", "found" : true }

문서 가져오기

GET 메서드를 사용하면 log-2012-12-27 인덱스에서 타입이 hadoop이고 ID가 1인 문서를 가져올 수 있습니다.

#요청 curl -XGET 'http://localhost:9200/log-2012-12-27/hadoop/1' # 결과 { "_index" : "log-2012-12-27", "_type" : "hadoop", "_id" : "1", "_source" : { "projectName" : "hadoop", "logType": "hadoop-log", "logSource": "namenode", "logTime":"2012-12-27T02:02:02", "host": "host2 ", "body": "org.apache.hadoop.hdfs.server.namenode.FSNamesystem" } }

검색

# 특정 인덱스의 모든 타입 $ curl -XGET 'http://localhost:9200/log-2012-12-27/_search?q=host:host2' # 특정 인덱스의 특정 타입 $ curl -XGET 'http://localhost:9200/log-2012-12-27/hadoop,apache/_search?q=host:host2' # 모든 인덱스의 특정 타입 $ curl - XGET 'http://localhost:9200/_all/hadoop/_search?q=host:host2' # 모든 인덱스와 타입 $ curl -XGET 'http://localhost:9200/_search?q=host:host2'

Mapping

## 특정 타입에 매핑을 추가 $ curl -XPUT 'http://localhost:9200/log-2012-12-27/hadoop/_mapping' -d ' { "hadoop" : { "properties" : { "projectName" : {"type" : "string", "index" : "not_analyzed"}, "logType" : {"type" : "string", "index" : "not_analyzed"}, "logSource" : {"type" : "string", "index" : "not_analyzed"}, "logTime" : {"type" : "date"}, "host" : {"type" : "string", "index" : "not_analyzed"}, "body" : {"type" : "string"}, } } } '   ## 정의된 매핑 정보 얻기 $ curl -XGET 'http://localhost:9200/log-2012-12-27/hadoop/_mapping' ## 정의된 매핑 삭제 $ curl -XDELETE 'http://localhost:9200/log-2012-12-27/hadoop'

성능 최적화

메모리와 오픈 파일 수

검색할 데이터가 많아질수록 많은 메모리가 필요합니다. elasticsearch를 운영하다 보면 메모리 사용으로 인한 문제를 많이 겪게 됩니다. elasticsearch 커뮤니티에서 권장하는 운영 방법에 따르면, elasticsearch 전용 서버를 운영할 때는 메모리 용량의 절반만 elasticsearch에 할당하고, 나머지 메모리 용량은 운영체제가 시스템 캐시 목적으로 사용할 수 있도록 하는 것이 좋다라고 나와 있습니다. 메모리 크기는 ES_HEAP_SIZE 환경 변수를 설정하거나 JVM의 -Xms와 -Xmx 값을 사용해서 설정할 수 있습니다.

bin/ElasticSearch -Xmx=2G -Xms=2G # 힙크기를 수동으로 지정

elasticsearch를 사용할 때는 OOME(Out Of Memory Error)가 발생하는 경우가 많습니다. 이유는 필드 캐시가 최대 힙 크기를 넘어서면서 발생하는데, index.cache.field.type 설정을 기본값인 resident 대신 soft로 설정하면 soft 레퍼런스를 활용하므로 캐시 영역에 대해 우선 가비지 컬렉션(Garbage Collection)을 실행해 문제를 해결할 수 있습니다.

index.cache.field.type: soft # 필드 캐시 타입 설정

데이터가 많아지면 인덱스 파일 개수 또한 증가하게 됩니다. elasticsearch가 사용하고 있는 Lucene에서 인덱스를 세그먼트 단위로 관리하기 때문입니다. 경우에 따라 MAX_OPEN 파일 개수를 넘어서는 일도 발생합니다. ulimit 명령으로 최대 오픈 파일 제한을 변경해야 합니다. 권장되는 값은 32000~64000이지만, 시스템 규모나 데이터의 양에 따라 더 큰 값으로 설정해야 할 수도 합니다.

인덱스 최적화

날짜별로 인덱스를 관리하면 아래에서 보는 것처럼 관리가 필요 없는 오래된 로그를 쉽고 빠르게 삭제할 수 있어서, 문서 별로 TTL 값을 설정해 삭제하는 것 보다 시스템에 주는 오버헤드가 적습니다.

$ curl -XDELETE 'http://localhost:9200/log-2012-10-01/' # 인덱스 삭제

인덱스 최적화(Index Optimization)를 수행하면 세그먼트를 병합시키는 방식으로 검색 성능을 향상시킬 수 있습니다. 다만 시스템에 부담을 주므로 시스템 사용이 적은 시간대에 작업하도록 해야 합니다.

$ curl -XPOST 'http://localhost:9200/log-2012-10-01/_optimize' # 인덱스 병합

샤드와 복제본

샤드 개수는 초기에 설정한 다음에는 변경이 불가능하므로 현재 시스템의 노드 수와 추후 발생할 수 있는 노드 증가를 고려해 정해야 합니다. 예를 들어 현재 5개의 노드가 향후 10개까지 증가할 계획이라면, 초기부터 샤드 수를 10개로 지정하는 것이 좋습니다. 초기에 샤드를 5개로 지정하면 이후 노드를 10개로 증가시켜도 샤드는 5개이므로 5개의 노드는 활용할 수 없게 됩니다. 물론 복제본 수를 1로 지정했다면 추가한 5개 노드를 복제 전용 노드로 활용할 수는 있습니다. 샤드 수를 늘리면 질의가 샤드 개수만큼 분산되므로 많은 데이터 처리에 유리하게 되지만, 너무 크게 설정하면 오히려 트래픽이 증가해 성능이 떨어질 수 있으니 적절하게 설정해야 합니다.

클러스터 토폴로지 구성

elasticsearch의 설정 파일에는 세 가지 종류의 노드(데이터 노드, 마스터 노드, 검색 밸런서 노드)가 있습니다.

• 데이터 노드: 마스터 역할을 수행하지 않고, 데이터만 저장. 클라이언트로부터의 요청이 왔을 때 샤드에서 데이터를 검색하거나 인덱스를 생성.
• 마스터 노드: 클러스터를 유지하기 위한 역할을 하고 인덱싱이나 검색 요청을 데이터 노드들에 요청.
• 검색 로드 밸런서 노드: 검색 요청이 오면 노드들에 데이터를 요청 후 취합해 결과를 전달.

하나의 노드가 마스터와 데이터 노드 역할을 다 하도록 운영할 수도 있으나, 세 가지 형태의 노드를 각각 사용하면 데이터 노드의 부담을 줄일 수 있습니다. 또한 마스터 노드를 별도로 구성하면 클러스터의 안정성을 높일 수 있고 마스터 노드와 검색 노드는 저사양의 서버 장비를 활용할 수 있도록 해 운영 비용 또한 줄일 수 있습니다.

# You can exploit these settings to design advanced cluster topologies. # # 1. You want this node to never become a master node, only to hold data. # This will be the "workhorse" of your cluster. # # node.master: false # node.data: true # # 2. You want this node to only serve as a master: to not store any data and # to have free resources. This will be the "coordinator" of your cluster. # # node.master: true # node.data: false # # 3. You want this node to be neither master nor data node, but # to act as a "search load balancer" (fetching data from nodes, # aggregating results, etc.) # # node.master: false # node.data: false

라우팅 설정

인덱싱할 데이터가 많으면 샤드의 수를 늘리는 것이 전체적인 성능을 증가시킬 수 있지만, 샤드의 개수를 증가시키는 만큼 노드 간의 트래픽이 증가한다는 문제점이 있습니다. 예를 들어 샤드가 100개면 하나의 검색 요청이 왔을 때 100개의 샤드에 모두 요청을 보내 데이터를 취합하는 형식이기 때문에 전체 클러스터에 부담이 됩니다. 라우팅을 사용하면 특정 샤드에만 데이터가 저장이 되어 샤드 수가 아무리 커져도 1개의 샤드(데이터가 저장이 되어 있는 샤드)에만 요청을 보내게 되므로 트래픽을 극적으로 줄일 수 있습니다. 라우팅을 사용하지 않으면 <그림 1>과 같이 전체 샤드에 모두 요청을 보내지만 라우팅을 사용하면 <그림 2>와 같이 특정 샤드에만 요청을 보내는 것을 볼 수 있습니다. <그림 3>에 따르면 200개의 샤드에서 라우팅 사용 전과 후의 성능을 비교 했을 때 반응 시간이 10배 이상 차이 나는 것을 볼 수 있습니다. 라우팅을 적용하면 적용하지 않은 경우와 비교해 스레드 개수가 10~20배 증가하지만 CPU 사용률은 훨씬 적은 것을 볼 수 있습니다. 하지만 경우에 따라 라우팅을 적용하지 않은 것이 성능이 더 좋을 때도 있습니다. 여러 샤드로부터 결과가 취합되어야 하는 검색 질의에 대해서는 여러 샤드에 요청이 전달되는 것이 성능 상 유리할 수 있습니다.

<그림1> 라우팅 사용 이전

<그림2> 라우팅 사용 후

<그림3> 라우팅 사용 이전/이후 비교

스플렁크 개요

Splunk는 모든 머신 데이터를 실시간으로 collecting하고 Indexing하고 Reporting하는 End-to-End Solution. 모든 머신 데이터를 제한 없이 처리 할 수 있습니다. 사용자가 원하는 데이터를 즉시 분석할수 있으며, 원하는 Reporter, Dashboard를 추가적인 개발없이 구성 할 수 있습니다.

또한 통계적 명령들을 조합하여 여러가지 Query문으로 Search가 가능하며 Query문의 자동완성 기능까지 갖추고 있어 사용하기 매우 편리합니다. 하지만 상당히 높은 가격대가 높다는 단점이 있습니다.

특징

머신 데이터(machine data)를 강력한 통찰력으로 변환

 모든 소스의 머신 데이터(machine data)를 실시간으로 수집하고 인덱싱합니다. 이를 통해 데이터를 검색, 모니터링, 분석 및 가상화하여 새로운 통찰력과 인텔리전스를 얻을 수 있습니다.

세부적인 가시성, 포렌식 및 문제 해결을 위한 정보 인덱싱

사용자와 사용자의 팀이 검색 결과를 공유

컴플라이언스 대응을 입증하기 위한 임시 보고서 생성

보안 사고, 서비스 레벨 및 기타 주요한 성능 메트릭 모니터링 위한 대화식 대시보드 생성

사용자 트랜잭션, 고객 행동, 시스템 작업, 보안 위협 및 부정행위 등 실시간 분석

데이터 인덱싱

 로그, 클릭스트림 데이터, 구성, 센서 데이터, 트랩 및 경고, 변경 이벤트, 진단 명령 결과, API 및 메시지 대기열의 데이터, 사용자 지정 애플리케이션의 멀티라인 로그에 이르기까지 형식이나 위치에 관계없이 모든 머신 데이터(machine data)를 인덱싱합니다. 사전 정의된 스키마 없이 모든 소스, 형식 및 위치에서 데이터를 인덱싱할 수 있습니다. 그 인덱싱 결과를 문제 해결, 보안 사고 조사, 네트워크 모니터링, 컴플라이언스 보고, 비즈니스 분석 및 기타 중요한 용도로 사용할 수 있습니다.

검색 및 조사

 동일한 인터페이스를 사용하여 실시간 및 이력 데이터를 검색합니다. 유사한 검색 명령어를 사용하여 검색을 정의하거나 제한 또는 확장합니다. 또한 통계 보고 명령어를 사용하고, 트랜잭션 개수 업데이트, 매트릭 계산, 롤링 시간 윈도우 내에서 특정 조건을 찾을 수 있습니다. 검색 길잡이는 자동 완 성 및 상황별 도움말을 제공하므로 SPLTM(Search Processing Language)의 강력한 기능을 모두 활용할 수 있습니다.

검색 결과 활용

 실시간으로 검색 결과를 활용할 수 있습니다. 결과의 타임라인을 줌인하거나 줌아웃하여 동향을 신속히 포착할 수 있습니다. 클릭만으로 결과를 즉시 볼 수 있고 불필요한 항목을 제거하여 방대한 데이터에서 필요한 정보를 얻을 수 있습니다. 예를 들면, 장애 접수 티켓에 대한 문제 해결, 보안 경고 발생과 관련된 조사 또는 단순한 데이터 검색 등 모든 상황에 대해 분 단위의 답변을 얻을 수 있습니다.

의미있는 데이터 구현

 Splunk Enterprise는 자동으로 머신 데이터(machine data)에서 정보를 추출합니다. 필드 및 데이터 소스를 식별하고 이름 및 태그를 지정하여 더 많은 정보와 의미를 추가할 수 있습니다. 외부 자산 관리 데이터베이스 및 구성 관리 시스템과 사용자 디렉토리에서 얻은 정보를 추가할 수도 있습니다. 기본 머신 데이터(machine data)에서 관계를 설명하는 데이터 모델을 쉽게 정의하여 사용자가 검색 언어를 배우지 않고도 강력한 보고서를 작성할 수 있는 피벗 인터페이스를 제공합니다.

이벤트의 상관관계 추적

 Splunk Enterprise 검색은 관련 없어 보이는 이벤트나 작업 간의 관계를 쉽게 설정하거나 찾을 수 있습니다. 시간, 외부 데이터, 위치, 하위 검색 또는 조인을 기반으로 머신 데이터(machine data)를 상관하고 관련 이벤트를 트랜잭션 또는 세션으로 식별합니다. 동향과 특성을 보고서 및 대시보드로 시각화합니다.

모니터링 및 경고

 검색을 실시간 경고로 전환함으로써 이메일 또는 RSS를 통해 자동으로 통보하거나 교정 작업을 수행하고, SNMP 트랩을 시스템 관리 콘솔로 보내거나 서비스 데스크에 자동으로 티켓을 생성할 수 있습니다. 경고는 다양한 임계값, 동향 기반 조건 및 기타 복합 검색을 기준으로 발생시킬 수 있습니다. 경고 시 추가 정보를 확보하여 더 신속하게 근본 원인을 분석하고 문제를 해결할 수 있습니다.

보고 및 분석

조직의 모든 사용자가 신속하게 데이터를 분석할 수 있습니다. 보고서, 고급 그래프 및 차트를 작성하여 중요한 동향을 파악하고 고급 시각화를 생성해 주므로 이를 통해 빠른 통찰력을 제공받을 수 있습니다.

새로운 예측 시각화 : 최고점과 최저점을 예측하여 시스템 자원을 계획하거나 부하량 예측 가능

피벗 인터페이스 : 사용자가 검색 언어를 배우지 않고서도 머신 데이터(machine data) 조작 및 상호작용을 통해 풍부한 정보가 있는 강력한 보고서 작성

대시보드 통합 및 PDF 파일로 공유

가격

스플렁크 라이선스를  한번구입하면 추가비용 들지 않습니다. (유저, 검색, 변경, 리포트, 대시보드 의 양에 상관 X)

ELK 소개

ELK는 Elastic search, Log stash, Kibana의 약자입니다. 각각의 소개는 다음 링크에서 자세히 설명하고 있습니다.

     -  Elastic search

     -  Log stash

     -  Kibana

ELK는 다음과 같은 구조로 동작하고 있습니다.

차이점

Splunk와 ELK Stack은 End-to-End Solution이라는 면에서는 비슷할지 모르나, Splunk보다 기능적으로 부족합니다.

몇가지 예를 들자면 다음과 같다.

1. Splunk는 Query문의 자동완성 기능이 매우 잘되어있으나, Kibana는 이전에 사용했던 검색어에 대해서만 Query문의 자동완성을 지원 합니다.

2. Splunk는 한개의 그래프에 한개의 Query 결과가 붙는 형태인 반면, Kibana는 한개의 Dashboard에 한개의 Query가 붙는 형태로 이를 공유하여 사용하기 때문에 하나의 Dashboard가 다양한 데이터를 가지고 표현할 수가 없다.

1) 소개

루씬(Lucene)은 자바로 개발된 오픈소스 정보검색(IR, Information Retrieval) 라이브러리입니다. 루씬은 강력한 기능을 포함하고 간단해서 많은 IT업계에서 사용하고 있습니다.

루씬은 독립된 프로그램이 아닌 소프트웨어 라이브러리이기 때문에 루씬을 설치 후, 바로 검색서비스를 실행할 수 있는 것이 아닌, 사용자가 루씬 라이브러리를 사용해 검색서비스, 어플리케이션을 구현해야 합니다.

루씬을 사용할 때, 검색에 대한 전문적인 지식을 반드시 알 필요가 없고, 꼭 필요한 몇 가지 클래스들의 사용법만 익히면 색인과 검색 기능을 직접 추가할 수 있습니다.

2) Indexing과 검색이 적용 가능한 사례

이메일 검색: 저장된 메시지를 검색할 수 있고 새로 도착한 메시지를 색인에 추가할 수 있는 이메일 어플리케이션

온라인 문서 검색 : 온라인 문서 또는 저장된 출판물을 검색할 수 있는 CD기반이나 웹 기반 또는 어플리케이션에 포함된 문서 판독기

웹 페이지 검색 : 사용자가 방문한 모든 웹 페이지를 색인화하기 위해 개인 검색 엔진을 만들 수 있는 웹 브라우저 또는 프록시 서버

내용 검색 : 저장된 문서에서 특정 내용을 검색할 수 있는 애플리케이션

버전 관리 및 컨텐트 관리 : 문서나 문서 버전을 색인화해서 쉽게 검색할 수 있는 문서 관리 시스템

뉴스 및 유선(wire) 서비스 : 뉴스가 도착했을 때 기사를 색인할 수 있는 뉴스 서버나 릴레이 서버

> 각각에 대한 전용 라이브러리가 존재하는 것이 아닌, 루씬을 사용해 개발할 수 있는 영역입니다.

3) 루씬의 기능

 색인을 저장할 수 있는 곳

RAMDirectory: 컴퓨터의 메인 메모리를 색인 장소로 사용

FSDirectory: 디스크의 파일 시스템에 색인을 저장 (가장 많이 사용)

JDBCDirectory: DB를 색인 저장소로 사용하는 방법. 일반적으로 지원하지는 않지만 별도의 루씬 샌드박스라는 것을 통해 지원

 색인 기능 지원

 검색 기능 지원

 다양한 나라의 Full Text 분석기 지원 (한글 x)

 Hadoop을 분산 파일 시스템으로 사용할 수 있음

4) 해석(parse)의 필요성

실전에서는 단순한 문자열 색인보다 다양한 문서를 indexing하고 검색하는 작업이 빈번

XML, PDF, HTML, MS WORD와 같이 다양한 문서들을 색인화 하기 위해 각각의 문서를 루씬의 Analyzer가 이해할 수 있도록 해석(parse)해서 텍스트로 추출해 내는 과정이 필요

5) 결론

Full Text를 검색하는데 효율적

Full Text(Contents)와 text를 단어로 쪼개는 방법(Analyzer)을 제시하면 알아서 index를 구성해주고 빠른 검색 결과를 얻을 수 있다.

Full text index는 full text serach를 위한 index입니다.

예를 하나 들면, 아래 예시 1)과 같은 내용을 어떠한 게시판에서 검색하려고 한다고 가정합니다.

Full Text Index가 무엇인가요?

그냥 index로 찾는 것과 차이가 뭔가요??

예시 1)

만약 게시판에 'index'가 들어가 있는 본문 + 내용이 많다라고 하면 'index' 글자가 들어있는 레코드를 찾으려면 검색 속도가 현저히 떨어집니다..

 그렇다고 내용 필드에 index(정규인덱스)를 심어놔도 이 검색은 전혀 index를 사용하지 못하는 꼴이 됩니다,

예를 들어, SELECT id FROM board WHERE Content LIKE "%index%"  이런식으로 쿼리를 만들어 사용한다고 하면 모든 행의 문자열을 검색하기 때문에 시간이 오래 걸립니다..

이럴때 사용하는 검색이 Full Text Index입니다. 미리(아님 스케줄로 또는 컴파일할 때,) Content필드의 내용들을 모두 검색해서 검색 불필요 단어(예-영어 : a, the ....)을 뺀 나머지 단어들의 Index를 카타로그로 저장하고 있다가,

Full Text로 질의를 하면, 이때 board테이블의 Contents를 검색하지 않고, 미리 만들어진 카타로그를 통해서 레코드를 찾아 결과를 뿌려주는 방식의 검색입니다.

질의도 보통 검색질의와는 다르게 CONTAINS, FREETEXT등의 질의를 사용합니다.