[List All Indexes]

이제 index에 대해서 가만히 들여다 보자.

curl 'localhost:9200/_cat/indices?v'

응답은 다음과 같다.

curl 'localhost:9200/_cat/indices?v'
health index pri rep docs.count docs.deleted store.size pri.store.size

아직 cluster에 index가 하나도 없다는 것을 의미한다.

[Cluster Health]

기본적인 cluster health check부터 시작해 보자. 이를 통해 우리는 cluster가 어떻게 작업을 수행하고 있는지 볼 수 있다. Curl을 사용하여 health check하겠지만, HTTP/REST call을 수행할 수 있는 어떤 tool을 사용해도 된다. Elasticsearch를 실행한 node에 있다고 가정하고, 또 다른 command shell window를 open하자.

Cluster health check하기 위해서, _cat API를 사용할 것이다. 이전에 node의 endpoint 주소를 기억해보면 9200 포트를 사용했다.

curl 'localhost:9200/_cat/health?v'

응답 결과는 다음과 같다.

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
1394735289 14:28:09  elasticsearch green           1         1      0   0    0    0        0

Cluster name이 elasticsearch임을 알 수 있다. 현재 cluser 상태는 green status이다.

Cluster health에 대해 언제든지 질의하면, green/yellow/red 중 한가지 상태를 알 수 있다. Green은 모든 것이 좋은 상태 (cluster가 모든 기능을 정상적으로 수행)임을 의미하고, yellow는 모든 data를 이용할 수는 있지만, 몇몇 replicas가 아직 할당되지 않은 상태(cluster가 모든 기능을 정상적으로 수행)임을 의미하고, red는 몇몇 데이터를 이용할 수 없는 상태임을 의미한다. Cluster가 red 상태일지라도 부분적으로 동작한다. (이용 가능한 shard에 있는 데이터에 대한 검색 요청을 지속적으로 수행) 하지만, 유실한 데이터가 있기 때문에 ASAP(As Soon As Possible) 문제 상황을 fix해야 한다.

위의 응답 결과로부터 우리는 전체 1개의 node가 있고, 0개의 shard가 있음을 알 수 있다. 왜냐하면 아직 데이터가 없기 때문이다. Default cluster name (elasticsearch)를 사용했고, 다른 node를 discover하기 위해서 elasticsearch는 multicase를 사용하므로 네트워크 상에서 하나 이상의 node를 우연하게 실행하면 모두 cluster에 join하게 된다. 이 시나리오에서는 응답 결과로 1개 이상의 node를 볼 수 있을 것이다.

다음과 같이 cluster에 있는 node list를 볼 수 있다.

curl 'localhost:9200/_cat/nodes?v'

응답은 다음과 같다.

curl 'localhost:9200/_cat/nodes?v'
host         ip        heap.percent ram.percent load node.role master name
mwubuntu1    127.0.1.1            8           4 0.00 d         *      New Goblin

여기서 우리는 현재 cluster에 있는 단일 node name이 "New Goblin"임을 알 수 있다.

[The REST API]

이제 우리는 실행된 node (cluster)를 가지고 있다. 다음 단계는 실행중인 node(cluster)와 어떻게 communicate하는지를 이해하는 것이다. 운이 좋게도, elasticsearch는 이해하기 쉽고 강력한 REST API를 제공한다. 여러분은 REST API를 통해서 cluster와 interact할 수 있다. API를 이용해서 할 수 있는 작업들은 다음과 같다.

• Cluster, node, index health, status, statistics 체크

• Cluster, node, index data, metadata 관리

• Index에 대한 CRUD(Create, Read, Update, Delete) 및 검색 작업 수행
• Paging, sorting, filtering, scripting, faceting, aggregation 등의 많은 advanced search 작업 실행

Elasticsearch는 java 7을 필요로 한다. 특히 이글을 쓰는 시점에서, Oracle J아 1.8.0_25 버전을 사용할 것을 추천한다. Java 설치는 platform에 따라 다르다. 따라서 여기서 Java 설치에 대해서 깊이 들어가지는 않을 것이다.

여러분이 elasticsearch를 설치하기 전에 java version을 체크하라는 것을 말하는 것으로 충분하다. (필요하다면 java를 설치하거나 업그레이드 하라)

java -version

echo $JAVA_HOME

Java를 셋업하고 나서, elasticsearch를 다운로드하고 실행한다. www.elasticsearch.org/download 에서 과거에 릴리즈된 모든 버전의 바이너리를 이용할 수 있다. 각 릴리즈별로 zip/tar 압축 파일을 선택하거나 DEB/RPM package를 선택할 수 있다. 간단하게 말하자면, 그냥 tar 파일을 사용하자.

Elasticsearch 1.5.1 tar 파일을 다음과 같이 다운로드 하자. (윈도우 사용자는 zip package를 다운로드 해야 한다.)

curl -L -O https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.5.1.tar.gz

그리고 다음과 같이 압축을 푼다. (윈도우 사용자는 zip package를 unzip 해야 한다.)

tar -xvf elasticsearch-1.5.1.tar.gz

현재 directory에 한 뭉텡이의 file/folder들을 생성할 것이다. 다음과 같이 bin directory로 이동하자.

cd elasticsearch-1.5.1/bin

이제 여러분은 지금 node에서 단일 cluster로 실행할 준비가 되었다. (윈도우 사용자는 elasticsearch.bat 파일을 실행하라)

./elasticsearch

모든 것이 제대로 되었다면, 아래와 같은 메시지들을 확인할 수 있을 것이다.

./elasticsearch
[2014-03-13 13:42:17,218][INFO ][node           ] [New Goblin] version[1.5.1], pid[2085], build[5c03844/2014-02-25T15:52:53Z]
[2014-03-13 13:42:17,219][INFO ][node           ] [New Goblin] initializing ...
[2014-03-13 13:42:17,223][INFO ][plugins        ] [New Goblin] loaded [], sites []
[2014-03-13 13:42:19,831][INFO ][node           ] [New Goblin] initialized
[2014-03-13 13:42:19,832][INFO ][node           ] [New Goblin] starting ...
[2014-03-13 13:42:19,958][INFO ][transport      ] [New Goblin] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/192.168.8.112:9300]}
[2014-03-13 13:42:23,030][INFO ][cluster.service] [New Goblin] new_master [New Goblin][rWMtGj3dQouz2r6ZFL9v4g][mwubuntu1][inet[/192.168.8.112:9300]], reason: zen-disco-join (elected_as_master)
[2014-03-13 13:42:23,100][INFO ][discovery      ] [New Goblin] elasticsearch/rWMtGj3dQouz2r6ZFL9v4g
[2014-03-13 13:42:23,125][INFO ][http           ] [New Goblin] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.8.112:9200]}
[2014-03-13 13:42:23,629][INFO ][gateway        ] [New Goblin] recovered [1] indices into cluster_state
[2014-03-13 13:42:23,630][INFO ][node           ] [New Goblin] started

너무 상세히 들어가지 말고, "New Goblin"이라고 이름 붙여진 node name을 볼 수 있을 것이다. 단일 cluster에서 master로서 선출되고 실행된 node이다. 지금 순간에 master가 무엇을 의미하는지에 대해서 걱정하지 말라. 여기서 중요한 것은 하나의 cluster에서 하나의 node를 실행했다는 것이다.

이전에 언급한 것처럼, cluster나 node name을 override (재정의) 할 수 있다. Command line에서 elasticsearch를 실행할 때 다음과 같이 할 수 있다.

./elasticsearch --cluster.name my_cluster_name --node.name my_node_name

또한 HTTP 주소와 포트에 대한 정보를 가진 http로 mark된 라인이 접속 가능한 주소임을 주목하라. 기본적으로 elasticsearch는 9200 포트 번호를 사용하여 REST API로 접근할 수 있다. 필요할 때, 이 포트 번호는 설정할 수 있다.

Elasticsearch의 핵심적인 몇가지 concept(개념)가 있다. 처음부터 이러한 concept을 이해하는 것이 elasticsearch에 대해서 배우는 과정 중에서 굉장히 도움이 될 것이다.

[Near Realtime (NRT)]

Elasticsearch는 near realtime 검색 플랫폼이다. 이것이 의미하는 바는 여러분이 document를 index하는 시점으로부터 검색 결과를 얻기까지 약간의 지연 현상(일반적으로 약 1초)이 있음을 의미한다.

[Cluster]

Cluster는 여러분의 전체 데이터를 담고 있는 하나 이상의 node(server)의 모음을 말한다. 그리고 Cluster는 모든 node에 있는 federated indexing (각 node에 개별적으로 존재하는 index들의 연합)과 검색 기능을 제공한다. Cluster는 기본적으로 "elasticsearch"라는 유일한 이름으로 구분된다. 하나의 node는 한번 cluster에 join하도록 셋팅되면 다른 곳에 참여할 수 없기 때문에 cluster 이름이 중요하다. Prodoction에서는 명시적으로 cluster name을 설정하는 것이 좋다. 하지만, testing/development 목적으로는 default name을 사용하는 것이 유용하다.

하나의 node만으로 cluster를 구성하는 것도 유효하고 완벽하게 동작한다는 것에 유념하라. 더욱이, 유일한 cluster name을 가지는 독립적인 여러 cluster를 구성하는 것도 가능하다.

[Node]

Node는 cluster의 일부분이고, 데이터를 저장하고, cluster의 index와 검색 기능에 참여하는 하나의 서버이다. Cluster와 같이 node는 유일한 이름을 갖는다. 기본적으로는 시작 시점에 node에 할당되는 임의의 Marvel character명을 갖는다. 기본적으로 부여되는 node명을 원하지 않으면 여러분이 원하는 어떤 이름으로도 node명을 정할 수 있다. 이 이름은 네트워크에 있는 어느 서버가 여러분의 elasticsearch cluster에 있는 node인지 구분하기 위한 관리하는데 사용되므로 중요하다.

Node는 cluster name으로 특정 cluser에 join하도록 설정할 수 있다. 기본적으로 각 개별 node는 elasticsearch라는 이름의 cluster에 join하도록 셋팅한다. 이것은 여러분이 네트워크 상에 많은 node를 실행한다면 - 서로 discover 가능하다고 가정하면 - 자동으로 elasticsearch라고 이름 붙여진 cluster에 join하여 cluster를 구성함을 의미한다.

여러분은 많은 node로 하나의 cluster를 구성할 수 있다. 더 나아가, 네트워크 상에 현재 구동되어 있는 Elasticsearch ndoe가 없다면, 하나의 node를 실행하여 elasticsearch로 이름붙여진 새로운 단일 node cluster를 기본적으로 구성할 수도 있다.

[Index]

Index는 유사한 특징들을 가진 document들의 집합이다. 예를 들어, customer data에 대한 index, 제품 카탈로그에 대한 또 다른 index, order(주문)에 대한 또 다른 index를 가질 수 있다. Index는 name (소문자여야만 한다.)으로 구분되고, 이 이름은 document에 대한 indexing, search, update, delete 작업을 수행하기 위해 index를 참조하는데 사용한다.

하나의 cluster에서 여러분이 원하는 대로 여러 개의 index를 정의할 수 있다.

[Type]

Index내에서 하나 이상의 type을 정의할 수 있다. Type은 논리적인 index의 category/partition이다. 일반적으로, type은 common field를 가진 document에 대해 정의되어 있다. 예를 들어, 여러분이 blogging platform을 운영하고 여러분의 모든 data를 하나의 index에 저장한다고 가정해 보자. 이 index에는 user data, blog data, comments data 등에 대한 type이 정의되어 있을 것이다.

[Document]

Document는 index되는 정보의 기본 단위이다. 예를 들어, 단일 고객에 대한 document, 단일 상품에 대한 document, 단일 주문에 대한 document등을 가질 수 있다. 이러한 document는 인터넷상에서 데이터 형식으로 폭넓게 사용되는 JSON으로 표시된다. (Javascript Object Notation)

여러분은 Index/type내에 여러분이 저장하고자 하는 많은 document를 저장할 수 있다. Document가 물리적으로는 index내에 있다고 할지라도, document는 실제로 index내에서 Type으로 index되고 지정되어야만 한다는 것에 유의하라.

[Shards & Replicas]

Index는 잠재적으로 하나의 node에서 하드웨어 limit을 넘어서는 대용량의 데이터를 저장할 수 있다.  예를 들어서 1TB disk space를 차지하는 10억개의 document에 대한 하나의 index는 하나의 node에 있는 disk에는 맞지 않거나 single node만으로 검색 요청을 수용하기에는 너무 느릴 것이다.

이 문제를 해결하기 위해서, elasticsearch는 여러분의 index를 shard라고 부르는 여러 개의 조각으로 세분화할 수 있도록 한다. 여러분이 index를 생성할 때, 여러분이 원하는 shard 수를 간단히 지정할 수 있다. 각 shard는 cluster에 있는 어떤 node에서도 host될 수 있는 fully-functional and independent한 "index" 그 자체이다.

Sharding은 2가지 주요 이유 때문에 중요하다.

• Content Volume을 수평적 확장 가능

• 성능과 Throughput 향상을 위해 (여러 node에 분산되어 있는) shard별 분산/병렬 처리 가능

Shard가 어떻게 분산되어 있는지, document들이 search request로부터 어떻게 수집되는지에 대한 메커니즘은 elasticsearch에 의해 완벽하게 관리된다. 그리고 여러분은 user로서 알기 쉽다.

언제라도 실패할 수 있는 네트워크나 클라우드 환경에서, 무슨 이유에서건 shard나 node가 offline이 되거나 사라지는 경우에 대한 failover 메커니즘을 가지는 것이 강력하게 추천되는 유용한 기능이다. 이러한 목적으로 elasticsearch는 (replica shard 혹은 짧게 replicas라고 부르는) index shard에 대한 하나 이상의 복사본을 가질 수 있다.

Replication은 2가지 이유 때문에 중요하다.

• Shard/node fail시, high availability를 제공한다. 이런 이유로, replica shard는 절대로 원본 (original/primary) shard와 동일한 node에 할당되면 안 된다.

• Search volume에 대한 scale out을 제공하고, 모든 replica에서 병렬적으로 검색을 실행할 수 있기 때문에 throughput이 향상된다.

요약하자면, 각 index는 여러 개의 shard로 나누어질 수 있다. Index는 0번(replicas가 없는 경우) 이상 복제될 수 있다. 한번 복제되면, 각 index는 primary shard(원본)와 replica shards를 갖는다. Shards와 replicas의 개수는 index가 생성될 때, index별로 정의될 수 있다. Index가 생성된 이후에는 어느 때라도 동적으로 replicas의 수를 변경할 수 있지만, 사후에 shard의 숫자를 변경할 수는 없다. (동적으로 replicas의 수를 변경할 수는 있지만 shard의 숫자는 변경할 수 없다.)

기본적으로, elasticsearch내의 각 index는 5개의 primary shard와 1개의 replica를 할당한다. 이것은 여러분이 cluster내에 최소한 2개의 node를 가지고 있다면, 여러분의 index는 5개의 primary shard와 5개의 replica shard (1개의 replica set)을 가진다는 의미이다. 인덱스당 총 10개의 shard를 갖는다.

{Note}

각 elasticsearch의 shard는 Lucene index이다. 하나의 Lucene Index에 저장할 수 있는 Max Document 수가 있다. Limit은 Integer.MAX_VALUE -128에 해당하는 2,147,483,519개이다. _cat/shards API를 통해서 shard size를 모니터링할 수 있다.