7-2-5. Important Configuration Changes

Elasticsearch ships with very good defaults, especially when it comes to performance- related settings and options. When in doubt, just leave the settings alone. We have witnessed countless dozens of clusters ruined by errant settings because the administrator thought he could turn a knob and gain 100-fold improvement.

Elasticsearch는, 특히 성능과 관련된 설정과 옵션에서, 아주 훌륭한 기본값을 가지고 있다. 확신할 수 없다면, 설정을 그대로 두자. 관리자들이 설정을 수정해 100배의 향상을 얻을 수 있다고 생각해, 잘못된 설정으로 cluster를 망치는 것을 수도 없이 보았다.

Please read this entire section! All configurations presented are equally important, and are not listed in any particular order. Please read through all configuration options and apply them to your cluster.

이 부분을 모두 읽기 바란다. 모든 설정은 똑같이 중요하며, 어떤 특별한 순서로 나열된 것이 아니다. 모든 설정 옵션 전체를 읽고, cluster에 적용하길 바란다.

Other databases may require tuning, but by and large, Elasticsearch does not. If you are hitting performance problems, the solution is usually better data layout or more nodes. There are very few "magic knobs" in Elasticsearch. If there were, we’d have turned them already!

다른 데이터베이스는 튜닝이 필요하지만, 대체로 Elasticsearch는 그렇지 않다. 성능 문제가 발생한다면, 해결책은 일반적으로 더 나은 데이터 레이아웃이나, 더 많은 node(scale out)이다. Elasticsearch에는 "마법의 지팡이" 가 거의 없다. 있다면, 우리가 이미 튜닝했다.

With that said, there are some logistical configurations that should be changed for production. These changes are necessary either to make your life easier, or because there is no way to set a good default (because it depends on your cluster layout).

그렇지만, 제품을 위해 변경해야 할 몇 가지 논리적인 설정이 있다. 이 변경은 여러분들을 편하게 만들어 주거나, 좋은 기본값을 설정할 방법이 없기 때문에 필요하다. cluster 구성 방법에 따라 달라지기 때문이다.

Assign Namesedit

Elasticseach by default starts a cluster named elasticsearch. It is wise to rename your production cluster to something else, simply to prevent accidents whereby someone’s laptop joins the cluster. A simple change to elasticsearch_production can save a lot of heartache.

Elasticsearch cluster의 기본 이름은 elasticsearch 이다. 누군가의 노트북이 cluster에 조인되는 사고를 방지하기 위해, 제품에서는 cluster의 이름을 다른 것으로 바꾸는 것이 좋다. elasticsearch_production 으로의 간단한 변경은 심적 고통을 많이 줄일 수 있다.

This can be changed in your elasticsearch.yml file:

elasticsearch.yml 파일에서 이것을 변경할 수 있다.

cluster.name: elasticsearch_production

Similarly, it is wise to change the names of your nodes. As you’ve probably noticed by now, Elasticsearch assigns a random Marvel superhero name to your nodes at startup. This is cute in development—but less cute when it is 3a.m. and you are trying to remember which physical machine was Tagak the Leopard Lord.

마찬가지로, node의 이름을 변경하는 것이 좋다. 아마도 지금쯤은 알겠지만, Elasticsearch는 node가 시작될 때, node의 이름에 Marvel Superhero의 이름을 임의로 지정한다. 개발 시에는 귀여울지도 모른다. 하지만, 새벽 3시에 물리적인 machine이 Tagak the Leopard Lord 라는 것을 기억하려 할 때는, 많이 귀찮을 것이다.

More important, since these names are generated on startup, each time you restart your node, it will get a new name. This can make logs confusing, since the names of all the nodes are constantly changing.

더 중요한 것은, 이런 이름이 시작 시에 생성되기 때문에, node를 다시 시작할 때마다, 새로운 이름을 가진다는 것이다. 모든 node의 이름이 끊임없이 변하기 때문에, 로그를 매우 복잡하게 만들 수 있다.

Boring as it might be, we recommend you give each node a name that makes sense to you—a plain, descriptive name. This is also configured in your elasticsearch.yml:

지루할 수도 있겠지만, 각 node에 의미 있는 이름(쉽고, 설명이 포함된 이름)을 지정하는 것이 좋다. 역시, elasticsearch.yml 에서 이것을 설정할 수 있다.

node.name: elasticsearch_005_data

Pathsedit

By default, Elasticsearch will place the plug-ins, logs, and—most important—your data in the installation directory. This can lead to unfortunate accidents, whereby the installation directory is accidentally overwritten by a new installation of Elasticsearch. If you aren’t careful, you can erase all your data.

기본적으로, elasticsearch는 설치 디렉토리에 plug-ins, logs 그리고 가장 중요한 data가 배치된다. 이로 인해, Elasticsearch를 다시 설치하다가, 설치 디렉토리를 실수로 덮어쓰는, 불행한 사고로 이어질 수 있다. 주의하지 않으면, 데이터 모두를 지울 수 있다.

Don’t laugh—we’ve seen it happen more than a few times.

웃지 마라. 이런 일은 주위에서 자주 일어난다.

The best thing to do is relocate your data directory outside the installation location. You can optionally move your plug-in and log directories as well.

가장 좋은 방법은 data 디렉토리를 설치 디렉토리 외부로 옮기는 것이다. 마찬가지로, plugins과 logs 디렉토리도 선택적으로 옮길 수 있다.

This can be changed as follows:

아래처럼 하면, 변경할 수 있다.

path.data: /path/to/data1,/path/to/data2 

# Path to log files:
path.logs: /path/to/logs

# Path to where plugins are installed:
path.plugins: /path/to/plugins

comma(,)로 구분된 목록을 사용하여, data 디렉토리를 하나 이상 지정할 수 있다.

Data can be saved to multiple directories, and if each directory is mounted on a different hard drive, this is a simple and effective way to set up a software RAID 0. Elasticsearch will automatically stripe data between the different directories, boosting performance.

데이터는 다수의 디렉토리에 저장될 수 있다. 이들 디렉토리 각각이 다른 hard drive에 장착(mount)되어 있다면, 이것은 RAID 0을 software로 구성한, 간단하고 효과적인 방식이다. Elasticsearch는 성능 강화를 위해, 자동으로 다른 디렉토리에 데이터를 분류한다.

다수의 data path에 대한 안정성과 성능

Like any RAID 0 configuration, only a single copy of your data is saved to the hard drives. If you lose a hard drive, you are guaranteed to lose a portion of your data on that machine. With luck you’ll have replicas elsewhere in the cluster which can recover the data, and/or a recent backup.

RAID 0 설정과 마찬가지로, data의 단일 복사본은 여러 hard drive에 저장된다. 만약, hard drive 하나를 잃어버리면, 해당 machine에 있는 data의 일부분을 잃어버릴 것이 확실하다. 운 좋게도, cluster의 다른 곳에 replica를 가지고 있거나, 최신 backup이 있다면, 데이터를 복구할 수 있다.

Elasticsearch attempts to minimize the extent of data loss by striping entire shards to a drive. That means that Shard 0 will be placed entirely on a single drive. Elasticsearch will not stripe a shard across multiple drives, since the loss of one drive would corrupt the entire shard.

elasticsearch는 전체 shard를 하나의 drive에 striping하여 데이터 손실을 최소화하려 한다. 즉, Shard 0 은 전체가 단일 drive에 저장된다. elasticsearch는 shard를 여러 drive에 걸쳐 striping하지 않는다. 왜냐하면 어떤 drive의 손실은 전체 shard의 오류가 될 수 있기 때문이다.

This has ramifications for performance: if you are adding multiple drives to improve the performance of a single index, it is unlikely to help since most nodes will only have one shard, and thus one active drive. Multiple data paths only helps if you have many indices/shards on a single node.

이것은 성능에 대한 파급 효과가 있다. 단일 index의 성능을 향상시키기 위해 여러 개의 drive를 추가하면, 대부분의 node가 하나의 shard를 가지고, 이렇게 되면 하나의 active drive가 되기 때문에 그리 도움이 되지 않을 것이다. 다수의 data path는 단일 node에 많은 indices/shard를 가지는 경우에만 도움이 된다.

Multiple data paths is a nice convenience feature, but at the end of the day, Elasticsearch is not a software RAID package. If you need more advanced configuration, robustness and flexibility, we encourage you to use actual software RAID packages instead of the multiple data path feature.

다수의 data path는 편리한 기능이다. 그러나 결국 가장 중요한 것은, elasticsearch가 software RAID package가 아니라는 것이다. 더 고급스러운 설정, 견고함, 유연성이 필요하다면, 다수의 data path 기능 대신, 실제 software RAID package를 사용할 것을 추천한다.

Minimum Master Nodesedit

The minimum_master_nodes setting is extremely important to the stability of your cluster. This setting helps prevent split brains, the existence of two masters in a single cluster.

minimum_master_nodes 라는 설정은 cluster의 안정성을 위해 아주 중요하다. 이 설정은 하나의 cluster에 두 개의 master가 존재하는 상황, 즉 split brains 를 방지할 수 있다.

When you have a split brain, your cluster is at danger of losing data. Because the master is considered the supreme ruler of the cluster, it decides when new indices can be created, how shards are moved, and so forth. If you have two masters, data integrity becomes perilous, since you have two nodes that think they are in charge.

split brain이 발생하면, cluster는 데이터 손실의 위험을 가진다. master는 cluster의 최고 통치자이기 때문에, 새로운 index가 생성되는 시기, shard를 이동시키는 방법 등을 결정한다. master가 두 개라면, 데이터를 책임진다고 생각하는 두 개의 다른 node를 가지는 것이기 때문에, 데이터 무결성은 아주 위험해진다.

This setting tells Elasticsearch to not elect a master unless there are enough master-eligible nodes available. Only then will an election take place.

이 설정은 이용할 수 있는 master 자격이 있는 node가 충분하지 않다면, master를 선출하지 않도록 하는 것이다. 그래야만 선출이 진행될 것이다.

This setting should always be configured to a quorum (majority) of your master-eligible nodes. A quorum is (number of master-eligible nodes / 2) + 1. Here are some examples:

이 설정은 항상 master 자격이 있는 node의 정족수(과반수)로 설정되어야 한다. 정족수는 (number of master-eligible nodes / 2) + 1 이다. 예를 들면,

• If you have ten regular nodes (can hold data, can become master), a quorum is 6.

  10개의 정규 node(데이터를 가지고 있고, master가 될 수 있는)를 가지고 있는 경우, 정족수는 6 이다.

• If you have three dedicated master nodes and a hundred data nodes, the quorum is 2, since you need to count only nodes that are master eligible.

  3개의 master 전용 node와 100개의 데이터 node를 가지고 있는 경우, 정족수는 2 이다. 왜냐하면, master 자격이 있는 node만 계산해야 하기 때문이다.

• If you have two regular nodes, you are in a conundrum. A quorum would be 2, but this means a loss of one node will make your cluster inoperable. A setting of 1 will allow your cluster to function, but doesn’t protect against split brain. It is best to have a minimum of three nodes in situations like this.

  2개의 정규 node를 가지고 있는 경우, 조금 어려운 문제가 된다. 정족수는 2 일 것이다. 그러나, 이것은 하나의 node를 잃으면 cluster가 동작하지 않는 다는 것을 의미한다. 1 로 설정하면, cluster는 동작하겠지만, split brain을 방지할 수 없다. 이 같은 상황에서는 최소한 3개의 node를 가지는 것이 최선이다.

This setting can be configured in your elasticsearch.yml file:

이 설정은 elasticsearch.yml 에서 가능하다.

discovery.zen.minimum_master_nodes: 2

But because Elasticsearch clusters are dynamic, you could easily add or remove nodes that will change the quorum. It would be extremely irritating if you had to push new configurations to each node and restart your whole cluster just to change the setting.

그러나, Elasticsearch는 동적이기 때문에, 정족수를 변경하기 위해, node를 쉽게 추가하거나 제거할 수 있다. 단지, 설정을 변경하기 위하여, 각 node에 새로운 구성을 밀어 넣고, 전체 cluster를 다시 시작해야 한다면, 그것은 매우 짜증나는 일일 것이다.

For this reason, minimum_master_nodes (and other settings) can be configured via a dynamic API call. You can change the setting while your cluster is online:

이런 이유로, minimum_master_nodes 와 다른 설정은 동적 API 호출을 통해 설정될 수 있다. cluster가 온라인이라면, 설정을 변경할 수 있다.

PUT /_cluster/settings
{
    "persistent" : {
        "discovery.zen.minimum_master_nodes" : 2
    }
}

This will become a persistent setting that takes precedence over whatever is in the static configuration. You should modify this setting whenever you add or remove master-eligible nodes.

이것은 정적인 구성이 무엇이든 간에 우선하는 영구적인 설정이 된다. master 자격이 있는 node를 추가하거나 제거할 때마다, 이 설정을 변경해야 한다.

Recovery Settingsedit

Several settings affect the behavior of shard recovery when your cluster restarts. First, we need to understand what happens if nothing is configured.

cluster가 다시 시작될 때, shard 복구 동작에 영향을 주는 여러 가지 설정이 있다. 먼저, 아무것도 설정하지 않은 경우, 무슨 일이 일어나는지 이해해야 한다.

Imagine you have ten nodes, and each node holds a single shard—either a primary or a replica—in a 5 primary / 1 replica index. You take your entire cluster offline for maintenance (installing new drives, for example). When you restart your cluster, it just so happens that five nodes come online before the other five.

5개의 primary와 1개의 replica를 가진 index에서, 10개의 node를 가지고 있고, 각 node는 단일 shard(primary나 replica)를 가지고 있다고 가정해 보자. 유지 보수를 위해, 전체 cluster를 오프라인으로 한다. cluster를 다시 시작하는데, 우연히 5개의 node가 다른 5개보다 먼저 online이 되었다.

Maybe the switch to the other five is being flaky, and they didn’t receive the restart command right away. Whatever the reason, you have five nodes online. These five nodes will gossip with each other, elect a master, and form a cluster. They notice that data is no longer evenly distributed, since five nodes are missing from the cluster, and immediately start replicating new shards between each other.

아마, 다른 5개는 오류가 발생했거나, 재 시작 명령을 즉시 받지 못했을 것이다. 이유가 무엇이든, 온라인인 5개의 node가 있다. 이 5개의 node는 서로 통신하며, master를 선출하고, cluster를 형성할 것이다. 그들은 5개의 node가 cluster에서 누락되었기 때문에, 데이터가 더 이상 균형 있게 분산되지 않는다는 것을 알고 있다. 그래서, 즉시 서로 새로운 shard를 복제하기 시작한다.

Finally, your other five nodes turn on and join the cluster. These nodes see that their data is being replicated to other nodes, so they delete their local data (since it is now redundant, and may be outdated). Then the cluster starts to rebalance even more, since the cluster size just went from five to ten.

마침내, 다른 5개의 node가 켜지고, cluster에 조인한다. 이 node들은 자신들의 데이터가 다른 node에 복제되었다는 것을 알게 된다. 그래서, 그것들은 자신의 로컬 데이터를 삭제한다. 왜냐하면, 그것은 현재 중복이고, 유효기간이 지났기 때문이다. 그런 다음에, cluster는 재조정을 시작한다. 왜냐하면, cluster의 크기가 5에서 10으로 변경됐기 때문이다.

During this whole process, your nodes are thrashing the disk and network, moving data around—for no good reason. For large clusters with terabytes of data, this useless shuffling of data can take a really long time. If all the nodes had simply waited for the cluster to come online, all the data would have been local and nothing would need to move.

이 모든 과정에서, node는 디스크를 많이 사용하고, 네트워크는 이유 없이 데이터를 이동시킨다. 수 TB의 데이터를 가진 커다란 cluster의 경우, 이 쓸모 없는 데이터의 재배치는 정말 오래 걸릴 수 있다. 단순히 모든 node가 cluster가 온라인이 되기를 기다렸다면, 모든 데이터는 local에 있었을 것이고, 아무것도 이동할 필요가 없었을 것이다.

Now that we know the problem, we can configure a few settings to alleviate it. First, we need to give Elasticsearch a hard limit:

문제를 알았으니, 이런 현상을 줄이기 위한 몇 가지 설정을 구성할 수 있다. 첫 번째는 Elasticsearch에 hard limit을 지정할 수 있다.

gateway.recover_after_nodes: 8

This will prevent Elasticsearch from starting a recovery until at least eight (data or master) nodes are present. The value for this setting is a matter of personal preference: how many nodes do you want present before you consider your cluster functional? In this case, we are setting it to 8, which means the cluster is inoperable unless there are at least eight nodes.

이것은 최소 8개(data 또는 master)의 node가 조인할 때까지, 복구가 시작되는 것을 막는다. 이 설정의 값은 개인적인 성향에 달려 있다. (cluster가 동작하기 전에 node가 몇 개나 존재해야 하는가?) 이 예에서는 8로 설정하였다. 즉, cluster는 최소 8개의 node가 존재할 때까지 동작하지 않는다.

Then we tell Elasticsearch how many nodes should be in the cluster, and how long we want to wait for all those nodes:

그 다음에, cluster에 node가 몇 개인지, 해당 node 모두를 얼마 동안 기다릴 것인지를 알려줘야 한다.

gateway.expected_nodes: 10
gateway.recover_after_time: 5m

What this means is that Elasticsearch will do the following:

이것의 의미는 다음과 같다.

• Wait for eight nodes to be present

  8 개의 node가 존재할 때까지 기다린다.

• Begin recovering after 5 minutes or after ten nodes have joined the cluster, whichever comes first.

  5분 후 또는 10개의 node가 cluster에 조인한 후 복구를 시작한다. 먼저 발생하는 이벤트 다음에 복구를 시작한다.

These three settings allow you to avoid the excessive shard swapping that can occur on cluster restarts. It can literally make recovery take seconds instead of hours.

이 세가지 설정으로, cluster가 다시 시작할 때 발생할 수 있는, 과도한 shard 교체를 피할 수 있다. 문자 그대로, 시간 단위가 아닌 초 단위로 복구할 수 있다.

These settings can only be set in the config/elasticsearch.yml file or on the command line (they are not dynamically updatable) and they are only relevant during a full cluster restart.

이들 설정은 config/elasticsearch.yml file이나 command line에서만 설정할 수 있다. (그것은 동적 update가 아니다) 전체 cluster가 재시작되는 동안에만 의미가 있다.

Prefer Unicast over Multicastedit

Elasticsearch is configured to use unicast discovery out of the box to prevent nodes from accidentally joining a cluster. Only nodes running on the same machine will automatically form cluster.

Elasticsearch는 node가 실수로 cluster에 join되는 것을 방지하기 위하여, unicast discovery를 사용하도록 설정되어 있다. 동일한 machine에서 실행하는 node에서만 자동으로 cluster를 형성한다.

While multicast is still provided as a plugin, it should never be used in production. The last thing you want is for nodes to accidentally join your production network, simply because they received an errant multicast ping. There is nothing wrong with multicast per se. Multicast simply leads to silly problems, and can be a bit more fragile (for example, a network engineer fiddles with the network without telling you—and all of a sudden nodes can’t find each other anymore).

multicast는 여전히 plug-in으로 제공되지만, 제품에서는 절대로 사용되어서는 안된다. 단순히, 그들이 잘못된 multicast ping을 받아서, 실수로 제품의 네트워크에 node가 조인되는 것을 원할 리는 없다. multicast 그 자체로는 아무런 문제가 없다. multicast는 단지 말도 안 되는 문제를 초래할 뿐이다. 그리고 약간 더 취약(예: 네트워크 엔지니어가 관리자에게 아무런 언급도 없이, 네트워크를 수정하였다. 갑자기 모든 node는 더 이상 서로를 찾을 수 없게 된다)할 수 있다.

To use unicast, you provide Elasticsearch a list of nodes that it should try to contact. When a node contacts a member of the unicast list, it receives a full cluster state that lists all of the nodes in the cluster. It then contacts the master and joins the cluster.

unicast를 사용하기 위해서는, 접촉하려는 node의 목록을 Elasticsearch에게 제공해야 한다. node가 unicast 목록의 구성원에게 접촉하면, cluster에 있는 모든 node를 나열하는, 전체 cluster state를 받을 것이다. 그 다음에 master와 접촉하고, cluster에 조인하게 된다.

This means your unicast list does not need to include all of the nodes in your cluster. It just needs enough nodes that a new node can find someone to talk to. If you use dedicated masters, just list your three dedicated masters and call it a day. This setting is configured in elasticsearch.yml:

즉, unicast 목록은 cluster에 있는 모든 node를 포함할 필요가 없다. 단지, 새로운 node가 통신하기 위하여, 어떤 node를 찾을 수 있는 충분한 node가 필요할 뿐이다. 전용 master를 사용한다면, 3 개의 전용 master만 나열하면 된다. 이 설정은 elasticsearch.yml 에서 설정된다.

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]

For more information about how Elasticsearch nodes find eachother, see Zen Discovery in the Elasticsearch Reference.

Elasticsearch의 node가 서로를 찾는 방법에 대한 더 많은 정보는 Elasticsearch Reference의 Zen Discovery를 참고하자.