7-1-6. Pending Tasks

There are certain tasks that only the master can perform, such as creating a new index or moving shards around the cluster. Since a cluster can have only one master, only one node can ever process cluster-level metadata changes. For 99.9999% of the time, this is never a problem. The queue of metadata changes remains essentially zero.

새로운 index를 생성하거나, cluster에서 shard의 이동처럼, master만이 할 수 있는 특정 작업이 있다. cluster는 오직 하나의 master만을 가질 수 있기 때문에, 하나의 node만이 cluster 수준의 metadata 변경을 처리할 수 있다. 거의 대부분의 경우에서, 이것은 절대 문제가 되지 않는다. metadata 변경 queue는 기본적으로 비어 있다.

In some rare clusters, the number of metadata changes occurs faster than the master can process them. This leads to a buildup of pending actions that are queued.

어떤 희귀한 cluster에서는, metadata 변경 작업은 master가 그것을 처리하는 것보다 더 빨리 발생한다. 이로 인해, queue에 들어가 대기 작업 열을 만들게 된다.

The pending-tasks API will show you what (if any) cluster-level metadata changes are pending in the queue:

pending_tasks API는 queue에 대기하고 있는 cluster 수준의 metadata 변경 작업이 무엇인지(있다면)를 보여준다.

GET _cluster/pending_tasks

Usually, the response will look like this:

일반적으로, response는 다음과 같다.

{
   "tasks": []
}

This means there are no pending tasks. If you have one of the rare clusters that bottlenecks on the master node, your pending task list may look like this:

이것은 대기 작업이 없다는 것을 의미한다. master node에 병목현상이 있는 희귀한 cluster를 가지고 있다면, 대기 작업은 아래와 같이 나열될 것이다.

{
   "tasks": [
      {
         "insert_order": 101,
         "priority": "URGENT",
         "source": "create-index [foo_9], cause [api]",
         "time_in_queue_millis": 86,
         "time_in_queue": "86ms"
      },
      {
         "insert_order": 46,
         "priority": "HIGH",
         "source": "shard-started ([foo_2][1], node[tMTocMvQQgGCkj7QDHl3OA], [P],
         s[INITIALIZING]), reason [after recovery from gateway]",
         "time_in_queue_millis": 842,
         "time_in_queue": "842ms"
      },
      {
         "insert_order": 45,
         "priority": "HIGH",
         "source": "shard-started ([foo_2][0], node[tMTocMvQQgGCkj7QDHl3OA], [P],
         s[INITIALIZING]), reason [after recovery from gateway]",
         "time_in_queue_millis": 858,
         "time_in_queue": "858ms"
      }
  ]
}

You can see that tasks are assigned a priority (URGENT is processed before HIGH, for example), the order it was inserted, how long the action has been queued and what the action is trying to perform. In the preceding list, there is a create-index action and two shard-started actions pending.

우선 순위가 할당된 작업(예를 들어, URGENT 는 HIGH 보다 먼저 처리된다), 입력된 순서, 작업의 대기 시간, 작업이 수행하려는 것을 볼 수 있다. 위의 목록에서, create-index 작업, 두 개의 shard-started 작업이 대기 중이다.

언제 대기중인 작업에 대해 관심을 가져야 하는가?

As mentioned, the master node is rarely the bottleneck for clusters. The only time it could bottleneck is if the cluster state is both very large and updated frequently.

언급한 바와 같이, master node는 cluster에서 거의 병목현상이 없다. cluster state가 매우 크 _고_, 빈번하게 업데이트되는 경우에, 병목현상이 있을 수 있는 유일한 시간이다.

For example, if you allow customers to create as many dynamic fields as they wish, and have a unique index for each customer every day, your cluster state will grow very large. The cluster state includes (among other things) a list of all indices, their types, and the fields for each index.

예를 들어, 고객이 마음대로 많은 동적 field를 생성할 수 있고, 각 고객이 매일 유일한 index를 생성한다면, cluster state는 매우 커질 것이다. cluster state는 모든 index의 목록, 그것의 type, 그리고 각 index에 대한 field를 포함한다.

So if you have 100,000 customers, and each customer averages 1,000 fields and 90 days of retention—that’s nine billion fields to keep in the cluster state. Whenever this changes, the nodes must be notified.

100,000 명의 고객이 있고, 각 고객이 평균 1,000 개의 field, 90 일 동안 있었다면, cluster state에는 90 억개의 field가 있다. 이것이 변경될 때마다, node에 알려줘야 한다.

The master must process these changes, which requires nontrivial CPU overhead, plus the network overhead of pushing the updated cluster state to all nodes.

master는 이런 변경을 반드시 처리해야 한다. 하지만, 모든 node에 cluster state를 업데이트하기 위해, 적지 않은 CPU 오버헤드, 추가로 네트워크 오버헤드가 필요하다.

It is these clusters that may begin to see cluster-state actions queuing up. There is no easy solution to this problem, however. You have three options:

cluster-state 작업이 queue에 쌓이는 것이 보이기 시작하는 것이 이런 cluster이다. 이 문제에 대한 쉬운 해결책은 없다. 그러나, 세 가지 옵션이 있다.

• Obtain a beefier master node. Vertical scaling just delays the inevitable, unfortunately.

  커다란 master node를 구해 보자. 불행하게도, 수직확장은 불가피하게 지연되었다.

• Restrict the dynamic nature of the documents in some way, so as to limit the cluster-state size.

  cluster-state의 크기를 제한하기 위하여, 어떻게 해서든, document의 동적 특성을 제한하자.

• Spin up another cluster after a certain threshold has been crossed.

  특정 임계 값에 이르게 되면, 다른 cluster로 전환하자.