인덱스와 샤드

Elasticsearch 용어 정리

---

엘라스틱 서치에 들어가는 낱개의 데이터 -> 도큐먼트

도큐먼트의 논리적인 집합 -> 인덱스 (RDBMS 테이블)

인덱스는 하나의 저장되지 않고 샤드라는 개념으로 쪼개서 저장이 됨 -> 여러개의 노드에 흩어져서 저장이 됨

 

RDBMS	Elasticsearch
테이블	인덱스
파티션	샤드 (Shard)
행(Row). 레코드	도큐먼트 (Document)
열	필드 (Field)
스키마 (Schema)	매핑 (Mapping)
SQL	Query DSL

 

 

프라이머리 샤드(Primary Shard)와 복제본(Replica)

---

• 인덱스를 생성할 때 별도의 설정을 하지 않으면 7.0 버전부터는 디폴트로 1개의 인덱스는 1개의 샤드로 구성
  • 6.x 이하 버전에서는 5개로 구성
• 클러스터에 노드를 추가하게 되면 샤드들이 각 노드들로 분산되고 디폴트로 1개의 복제본을 생성
• 처음 생성된 샤드를 프라이머리 샤드, 복제본을 레플리카(Replica) 라고 부릅니다.
• 예를들어 한 인덱스가 5개의 샤드로 구성되어있고 4개의 클러스터로 구성되어 있다고 가정하면
• 5개의 프라이머리 샤드와 복제본(Replica), 총 10개의 샤드들이 전체노드에 골고루 분배되어 저장.

 

 

프라이머리 샤드와 복제본은 반드시 서로 다른 노드에 저장이 된다. (0번 프라이머리 샤드와 0번 복제본은 각각 Node-1과 Node-3에 존재한다.)

 

만약 위 그림에서 Node3 노드가 시스템 다운이나 네트워크 단절등에서 사라지면 이 클러스터는 Node3 에 있던 0번과 4번 샤드들을 유실하게 됩니다. 하지만 아직 다른 노드들, Node1, Node2 에 0번, 4번 샤드가 남아있으므로 여전히 전체 데이터는 유실없이 사용 가능합니다

 

Node-3 노드가 유실되어 0번, 4번 샤드가 다른 노드에 복제본을 새로 생성한 예

 

• 처음에 클러스터는 먼저 유실된 노드가 복구되기를 기다립니다.
• 하지만 타임아웃이 지나 유실된 노드가 복구되지 않는다고 판단하면 ElasticSearch는 복제본이 사라져 1개만 남은 0번,4번 샤드의 복제를 시작
• 처음에 4개였던 노드가 3개로 줄어도 복제가 끝나면 샤드와 복제본(Replica) 이 각각 5개씩 총 10개의 데이터로 유지됩니다.

 

노드가 3개로 줄었을 때도 전체 데이터 유지

 

• 이렇게 프라이머리 샤드와 레플리카를 통해 ElasticSearch는 운영중에 노드가 유실되어도 데이터를 잃어버리지 않고 데이터의 가용성과 무결성을 보장합니다.

 

샤드 개수 설정

 

• 샤드의 개수는 인덱스를 처음 생성할때 지정할 수 있습니다.
• 샤드의 개수는 인덱스를 재색인 하지 않는 이상 바꿀 수 없습니다.
• 다만 복제본의 개수는 나중에 변경이 가능합니다.

 

키바나 -> devtools 에서 명령어 실행

 

현재 상태 확인

GET /

 

아래는 curl 명령을 통해 REST API로 샤드가 5개, 복제본은 1개인 books 라는 이름의 인덱스를 생성하는 예제입니다.

 

// 샤드 5개, 복제본 1개인 books 인덱스 생성
$ curl -XPUT "http://localhost:9200/books" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1
  }
}'

 

DELETE 명령어를  통해 인덱스를 삭제할 수도 있습니다.

 

DELETE books

 

샤드의 수는 변경할 수 없지만 복제본의 개수는 변경이 가능하다고 하였습니다.

아래 명령어를 통해 복제본의 개수를 0으로 변경해 봅시다.

 

// 복제본의 수를 0개로 변경하는 명령어
$ curl -XPUT "http://localhost:9200/books/_settings" -H 'Content-Type: application/json' -d'
{
  "number_of_replicas": 0
}'

 

elasticsearch의 정보는 cat 명령어를 통해 다양하게 확인할 수 있습니다.

 

// node 정보를 확인하는 방법
GET _cat/nodes
GET _cat/nodes?v
GET _cat/nodes?v&h=ip,name,node.role

// index 정보를 확인하는 방법
GET _cat/indices
GET _cat/indices?v
GET _cat/indices?v&h=health,index,dox.count,pri,rep

// cat으로 사용할 수 있는 명령어 확인하는 방법
GET _cat

 

샤드의 배치를 확인하고 싶으시다면 아래 명령어를 통해 확인할 수 있습니다.

 

// books 인덱스의 primary shard가 속한 node의 위치를 확인할 수 있다.
GET _cat/shards/books

 

만약에 4개의 노드를 가진 클러스터에 프라이머리 샤드 5개, 복제본 1개인 books 인덱스, 그리고 프라이머리 샤드 3개 복제본 0개인 Magagine 인덱스가 있다고 하면 전체 샤드들은 아래와 같은 모양으로 배치 될 수 있습니다.

 

 

마스터 노드와 데이터 노드 - Master & Data Nodes

---

마스터 노드

• Elasticsearch 클러스터는 하나 이상의 노드들로 구성
• 이 중 하나의 노드는 인덱스의 메타 데이터, 샤드의 위치와 같은 클러스터 상태 정보를 관리하는 마스터 노드의 역할을 수행
• 클러스터 마다 하나의 마스터 노드가 존재하며, 마스터 노드 역할을 수행할 수 있는 노드가 없을 경우 클러스터 정지
• elasticsearch.yml에 디폴트 설정은 node.master: true로 되어 있습니다.
• 기본적으로 모든 노드가 마스터 후보 노드 입니다.
• 마스터 노드가 끊어질 경우 다른 마스터 노드 후보중 하나가 마스터 노드로 선출되어 역할을 수행하게 됩니다.

 

데이터 노드

• 데이터 노드는 색인된 데이터를 저장하고 있는 노드
• 클러스터에서 마스터 노드와 데이터 노드를 분리하여 설정할 때 마스터 후보 노드들은 node.data:false로 설정하여 마스터 노드 역할만 하고 데이터는 저장하지 않도록 할 수 있음.
• 이렇게 하면 마스터 노드는 클러스터 관리만 하게되고, 데이터 노드는 클러스터 관리작업으로부터 자유롭게 되어 데이터 처리에만 집중할 수 있음.
• 다음은 4개의 노드를 실행하는데 node-1은 마스터 역할만 실행하는 전용노드, node2,3,4는 데이터 노드 입니다.

 

#[node-1] config/elasticsearch.yml
node.master: true
node.data: false

#[node-2] config/elasticsearch.yml
node.master: false
node.data: true

#[node-3] config/elasticsearch.yml
node.master: false
node.data: true

#[node-4] config/elasticsearch.yml
node.master: false
node.data: true

 

위와 같이 설정한 4개의 노드를 하나의 클러스터로 묶고 데이터를 입력하게 되면 데이터는 다음과 같이 node 2,3,4에만 저장이 됩니다.

 

 

• 키바나에서는 다음과 같이 확인할 수 있습니다.

 

실제 운영환경에서는 위 예제처럼 마스터 후보를 노드 1개만 설정하면 안되고 최소 3개 이상의 홀수개로 설정해야합니다.

이유는 다음의 Split Brain 문제에서 설명

 

Split Brain

---

• 마스터 후보 노드를 하나만 놓게 되면 그 마스터 노드가 유실 되었을 때 클러스터 전체가 작동을 정지 할 위험 존재
• 그래서 마스터 후보 노드를 여러개 두는데 3개 이상의 홀수개를 권장
• 짝수개로 운영하는 경우 네트워크 유실상황에서 다음과 같은 상황이 발생할 수 있음.

 

 

• 위와 같이 네트워크 단절로 후보 node1, node2가 분리되면서 서로 각자 다른 클러스터로 구성되어 동작하는 경우가 발생할 수 있음.
• 이러한 경우 각자의 클러스터에서 데이터가 추가되거나 변경되고 나면 나중에 네트워크가 복구되고 하나의 클러스터로 합쳐졌을때 데이터 정합성에 문제가 생기고 데이터 무결성을 유지할 수 없게 됩니다.
• 이런 문제를 Split Brain 이라고 합니다.

• Split Brain을 방지 하기 위해서는 마스터 후보 노드를 3개로 두고 클러스터에 마스터 후보 노드가 최소 2개이상 존재하고 있을때에만 클러스터가 동작하고 그렇지 않은 경우 클러스터는 동작을 멈추도록 수정

 

7.0 부터는 사용자가 최초 마스터 후보로 선출할 cluster.initial_master_nodes: [ ] 값만 설정하면 됩니다.

위 설정을 하고 나면 네트워크가 단절 되었을 때 minimum_master_nodes 가 2 이상인 클러스터만 살아있고 그렇지 않은 클러스터는 동작을 멈추게 됩니다.

 

클러스터 분리 시 마스터 노드가 절반 이상인 클러스터만 생존

 

마스터 노드가 절반 이상인 클러스터만 생존하는 것이 키 포인트입니다.

• 위의 경우 데이터는 노드 node-4, node-5의 데이터만 사용이 가능하고 node-6은 네트워크가 복구될 때 까지 동작하지 않고 노드가 분리되기 이전 상태 그대로 유지됩니다.
• 이렇게 하면 나중에 클러스터가 복구 되었을 때 node-4, node-5에 추가되거나 변경, 삭제 된 데이터의 정보들만 node-6으로 업데이트 되고 데이터 정합성에는 문제가 없게 됩니다.
• 이처럼 Split Brain 문제를 피하기 위해서 마스터 후보 노드 개수는 항상 홀수로 하고 가동을 위한 최소 마스터 후보 노드 설정은 (전체 마스터 후보 노드)/2+1 로 설정해야 합니다.

 

 

키바나 모니터링

---

 

Kibana -> Management -> Stack Monitoring 부분으로 접근을 해봅시다.

현재는 모니터링 기능이 활성화 되어있지 않다.

최근 버전에는 monitoring을 metricbeat와 함께 이용하게 되어있지만

metricbeat를 사용하지 않고 예전에 사용하던 방법인 elasticsearch 자체가 monitoring 데이터를 수집하는 방식을 사용

"Or, set up, with self monitoring" 을 클릭하면 된다.

 

Kibana에서 Monitoring을 끄는 방법

// 현재 elasticsearch cluster에 설정되어 잇는 setting을 볼 수 있다.
// persistent : cluster를 내려도 살아있는 setting
// transient : cluster를 내리면 죽는 setting
GET _cluster/settings

// enabled를 null로 해도 되고 false로 해도 된다.
PUT _cluster/settings
{
    "persistent" : {
    	"xpack": {
        	"monitoring": {
            	"collection" : {
                	"enabled" : null
                }
            }
        }
    }
}