6-4-02. Shard Overallocation

A shard lives on a single node, but a node can hold multiple shards. Imagine that we created our index with two primary shards instead of one:

shard는 단일 node에 존재하지만, node는 여러 개의 shard를 가질 수 있다. 하나가 아닌 두 개의 primary shard를 가진, index를 생성했다고 가정해 보자.

PUT /my_index
{
  "settings": {
    "number_of_shards":   2, 
    "number_of_replicas": 0
  }
}

replica shard 없이, 두 개의 primary shard를 가진 index를 생성

With a single node, both shards would be assigned to the same node. From the point of view of our application, everything functions as it did before. The application communicates with the index, not the shards, and there is still only one index.

단일 node에서는, 두 개의 shard 모두는 동일한 node에 할당된다. 응용프로그램 입장에서 보면, 모든 기능은 전과 같다. 응용프로그램은 shard가 아닌, index와 통신하는데, 여전히 단 하나의 index만 있다.

This time, when we add a second node, Elasticsearch will automatically move one shard from the first node to the second node, as depicted in Figure 50, “두 개의 shard를 가진 index는 두 번째 node를 활용할 수 있다”. Once the relocation has finished, each shard will have access to twice the computing power that it had before.

이 때, 두 번째 node를 추가하면, Figure 50, “두 개의 shard를 가진 index는 두 번째 node를 활용할 수 있다” 처럼, Elasticsearch는 자동으로 첫 번째 node에 있는 어떤 shard를 두 번째 node로 옮긴다. 일단, 재할당이 완료되면, 각 shard는 기존에 비해, 두 배의 계산 능력을 가지게 된다.

Figure 50. 두 개의 shard를 가진 index는 두 번째 node를 활용할 수 있다

We have been able to double our capacity by simply copying a shard across the network to the new node. The best part is, we achieved this with zero downtime. All indexing and search requests continued to function normally while the shard was being moved.

네트워크를 통해, 단순히 특정 shard를 새로운 node로 복사하여, 능력을 두 배로 할 수 있었다. 가장 멋진 부분은 무정지(zero downtime)가 달성되었다는 점이다. 모든 색인과 검색 request는, shard를 옮기는 동안에도, 정상적으로 동작한다.

A new index in Elasticsearch is allotted five primary shards by default. That means that we can spread that index out over a maximum of five nodes, with one shard on each node. That’s a lot of capacity, and it happens without you having to think about it at all!

Elasticsearch에서, 새로운 index는 기본적으로 5개의 primary shard가 할당된다. 즉, 각 node당 하나의 shard를 가진, 최대 5개의 node로 해당 index를 확장할 수 있다. 이것은 많은 용량을 가진다. 생각지도 않았던 일들이 벌어진다.

shard 분할

Users often ask why Elasticsearch doesn’t support shard-splitting—the ability to split each shard into two or more pieces. The reason is that shard-splitting is a bad idea:

사용자들은 Elasticsearch는 왜 _shard 분할_(shard-splitting, 각 shard를 두 개 이상의 조각으로 나누는 기능)을 지원하지 않는지를 질문한다. 그 이유는 shard 분할이 좋지 않은 생각이기 때문이다.

• Splitting a shard is almost equivalent to reindexing your data. It’s a much heavier process than just copying a shard from one node to another.

  shard 분할은 데이터를 다시 색인하는 것과 거의 동일하다. 그것은 단순히 특정 node에서 다른 node로 shard를 복사하는 것보다, 훨씬 더 무거운 프로세스다.

• Splitting is exponential. You start with one shard, then split into two, and then four, eight, sixteen, and so on. Splitting doesn’t allow you to increase capacity by just 50%.

  분할은 기하급수적이다. 하나의 shard로 시작해서, 둘로 분할하고, 4, 8, 16, 등. 분할 때문에 용량을 50% 이상으로 증가시킬 수 없다.

• Shard splitting requires you to have enough capacity to hold a second copy of your index. Usually, by the time you realize that you need to scale out, you don’t have enough free space left to perform the split.

  shard 분할은 index의 두 번째 복사본을 저장하기 위한, 충분한 용량이 필요하다. 일반적으로, 수평 확장을 해야 한다고 느끼는 순간까지, 분할을 수행할 충분한 여유 공간을 가지고 있지는 않다.

In a way, Elasticsearch does support shard splitting. You can always reindex your data to a new index with the appropriate number of shards (see Reindexing Your Data). It is still a more intensive process than moving shards around, and still requires enough free space to complete, but at least you can control the number of shards in the new index.

어떤 면에서는, Elasticsearch는 shard 분할을 지원한다. 데이터를 적절한 shard의 수를 가진 새로운 index에 언제나 다시 색인할 수 있다(Reindexing Your Data 참조). 여전히 shard의 이동보다 더 무거운 프로세스이며, 여전히 충분한 여유 공간이 필요하지만, 적어도 새로운 index에서 shard의 수를 제어할 수 있다.