[Elasticsearch] 색인 (Indexing)

색인(Indexing)이란

색인(Indexing)이란 문서를 분석하고 저장하는 과정을 색인이라고 한다.

 

색인의 과정을 도식화해보면 아래와 같다.

예를 들어서 SERVER 3개에 Elasticsearch 가 Cluster 형태로 구성되어 있다고 가정해 보자.

1) movie 인덱스에 1001번 아이디를 가진 데이터를 NODE A에 PUT 한다.

 

2) NODE A에서 Primary shard를 하나 생성하고 해당 서버가 아닌 다른 서버에

 

Replica shard 를 하나 생성해 준다. (shard 1, replica 1 이 기본값임)

 

그다음 현재 Primary shard의 데이터를 복사해 준다.

 

 

그럼 다음으로 NODE B로 id 가 1002인 데이터가 PUT 된다고 가정해 보자.

1) movie 인덱스에 1002번 아이디를 가진 데이터를 NODE B에 PUT 한다.

 

해당 노드가 어느 역할을 수행하던, Elasitcsearch는 Cluster 구조이기 때문에 PUT 결과는 동일하다.

 

2) 이미 "movie" 인덱스는 존재하기 때문에, 해당 인덱스의 Primary shard 가 존재하는 

 

NODE A로 이동해 준다.

 

3) "movie" 인덱스에 대응하는 Primary shard에 데이터를 쓰고,

 

해당 데이터를 Replica shard 에도 복사해 준다.

 

 

위에 ES Cluster 구조를 보면 효율적이지 않다는 생각이 들 것이다.

 

노드는 3개인데, 결국 색인은 NODE A 만 담당하고 있다.

 

또한 NODE C는 아무런 행동도 하지 않고 놀고 있는 서버처럼 보인다.

 

즉 데이터 노드가 세 개지만, 색인에 있어서는 사실상 1대 있는 거나 

 

마찬가지인 상황인 것이다.

 

해당 상황은 클러스터로서 이점을 전혀 살리지 못하는 상황이라고 보면 된다.

 

즉 적절한 수의 샤드 개수를 설정하는 것이 성능에 가장 큰 영향을 미치게 된다.

 

 

그럼 이상적인 상황은 어떤 식으로 샤드를 설정하는 것일까?

 

어떤 서비스냐 어떤 환경이냐에 따라 다르겠지만,

 

이론적으로는 node 가 3개 있을 경우에는

 

primary shard 3n 개를 권장한다.

 

위와 같이 id 가 512 인 문서가 movie 인덱스에 쓰인다고 가정해 보자.

 

1) movie 인덱스에 512번 아이디를 가진 데이터를 NODE B에 PUT 한다.

 

2) 현재 primary shard는 3개이기 때문에

 

shard routing rules에 의해 512 % 3 = 2

 

즉, NODE A를 0번 노드라고 가정하면,

 

2는 NODE C와 대응되므로

 

NODE C에 존재하는 primary shard 인 a2 샤드에 데이터를 써준다.

 

3) a2 샤드의 Replica shard에 해당 샤드 데이터를 복사해 준다.

 

즉 위와 같이 샤드를 구성해 주면, shard routing rules에 의해

 

한쪽 노드만 색인 작업을 할 필요도 없으며,

 

노드 장애 시에도 서비스를 지속할 수 있다.

 

 

 

샤드를 어떤 식으로 구성하는지에 답은 존재하지 않는다.

 

ES를 운영해 나가면서 성능에 문제가 보인다면,

 

샤드의 수를 늘리거나 데이터노드를 scale up / scale out을

 

진행하면서 최적의 수치를 찾아가면 된다.