When using elasticsearch for larger time data analytics use cases, we recommend using time-based indices and a tiered architecture with 3 different types of nodes (Master, Hot-Node and Warm-Node), which we refer to as the "Hot-Warm" architecture. Each node has their own characteristics, which are described below.
더 큰 시간 data 분석 사례에 대해 elasticsearch를 사용할 경우, 시간 기반의 index와 3가지 다른 유형의 node(Master, Hot-Node, Warm-Node)를 가진 계층형 아키텍처("Hot-Warm" 아키텍처)를 사용하는 것이 좋다. 각 node는 각자의 특성을 가지고 있는데, 아래에서 설명하겠다.
Master nodes
We recommend running 3 dedicated master nodes per cluster to provide the greatest resilience. When employing these, you should also have the discovery.zen.minimum_master_nodes setting at 2, which prevents the possibility of a "split-brain" scenario. Utilizing dedicated master nodes, responsible only for handling cluster management and state enhances overall stability. Because they do not contain data nor participate in search and indexing operations they do not experience the same demands on the JVM that may occur during heavy indexing or long, expensive searches. And therefore are not as likely to be affected by long garbage collection pauses. For this reason they can be provisioned with CPU, RAM and Disk configurations much lower than those that would be required for a data node.
복원력을 극대화하기 위해서는 cluster당 3개의 전용 master node를 운영하는 것이 좋다. 이들을 사용할 때, discovery.zen.minimum_master_nodes 설정을 2로 해야 하는데, 이는 "split-brain"을 방지한다. cluster 관리와 state를 처리하는 전용 master node를 활용하면, 전반적인 안정성이 향상된다. data가 없거나 search와 index 작업에 참여하지 않기 때문에, 대량 index나 길고 비용이 많이 소모되는 search에서 발생할 수 있는 JVM 요구 사항이 발생하지 않는다. 따라서, 긴 garbage collection 정지의 영향을 받지 않는다. 이러한 이유로, data node에서 필요한 것보다 훨씬 낮은 CPU, RAM, Disk 구성으로 가능하다.
Hot nodes
This specialized data node performs all indexing within the cluster. They also hold the most recent indices since these generally tend to be queried most frequently. As indexing is a CPU and IO intensive operation, these servers need to be powerful and backed by attached SSD storage. We recommend running a minimum of 3 Hot nodes for high availability. Depending on the amount of recent data you wish to collect and query though, you may well need to increase this number to achieve your performance goals.
이 특수한 data node는 cluster내에서 모든 index를 수행한다. 일반적으로 가장 최근 index가 가장 자주 query되므로, 이 node가 가장 최근 index를 가지고 있다. index는 CPU, IO 집약적인 작업이므로, 이들 server는 강력한 성능과 SSD 저장소를 사용해야 한다. 높은 가용성을 위해, 최소 3개의 Hot node를 실행하는 것이 좋다. 하지만, 수집 또는 query하려는 최근 data의 양에 따라, 성능을 위해, 이 수를 늘려야 할 수도 있다.
Warm nodes
This type of data nodes are designed to handle a large amount of read-only indices that are not as likely to be queried frequently. As these indices are read-only, warm nodes tend to utilize large attached disks (usually spinning disks) instead of SSDs. As with hot nodes, we recommend a minimum of 3 Warm nodes for high availability. And as before, with the caveat that larger amounts of data may require additional nodes to meet performance requirements. Also note that CPU and memory configurations will often need to mirror those of your hot nodes. This can only be determined by testing with queries similar to what you would experience in a production situation.
이 유형의 data node는 자주 query될 가능성이 낮은 대량의 읽기 전용 index를 처리하도록 설계되었다. 이들 index는 읽기 전용이므로, warm node는 SSD 대신 대용량 disk를 활요한다. hot node와 마찬가지로, 고 가용성을 위해 최소 3개의 warm node를 추천한다. 이전과 마찬가지로, data 양이 많을수록 성능을 위해 추가 node가 필요할 수 있다. 또한, CPU, memory 구성은 hot node의 구성을 반영해야 한다. 이는 실제 상황과 유사한 query로 test하여 결정될 수 있다.
The Elasticsearch cluster needs to know which servers contain the hot nodes and which server contain the warm nodes. This can be achieved by assigning arbitrary attributes to each server.
Elasticsearch cluster는 어느 server가 hot node 또는 warm node를 가지고 있는지 알아야 한다. 각 server에 임의의 attributes 를 할당하면 된다.
For instance, you could tag the node with node.attr.box_type: hot in elasticsearch.yml, or you could start a node using ./bin/elasticsearch -Enode.attr.box_type=hot
예를 들어, elasticsearch.yml에 node.attr.box_type: hot 라고 하거나, ./bin/elasticsearch -Enode.attr.box_type=hot 를 사용하여 node를 시작할 수 있다.
The nodes on the warm zone are "tagged" with node.attr.box_type: warm in elasticsearch.yml or you could start a node using ./bin/elasticsearch -Enode.attr.box_type=warm
warm zone의 node는 elasticsearch.yml에 node.attr.box_type: warm 라고 하거나, ./bin/elasticsearch -Enode.attr.box_type=warm 을 사용하여 node를 시작할 수 있다.
The box_type attribute is completely arbitrary and you could name it whatever you like. These arbitrary values will be used to tell Elasticsearch where to allocate an index.
box_type attribute는 완전히 임의적이며, 원하는 이름을 사용할 수 있다. 이 임의의 값은 Elasticsearch에게 index를 할당할 위치를 알려주는데 사용된다.
We can ensure today's index is on the hot nodes that utilize the SSD's by creating it with the following settings:
다음 설정을 통해, SSD를 사용하는 hot node에 오늘자 index를 생성할 수 있다.
PUT /logs_2016-12-26 { "settings": { "index.routing.allocation.require.box_type": "hot" } }
After few days if the index no longer needs to be on the most performant hardware, we can move it to the nodes tagged as warm by updating its index settings:
시간이 흘러, index가 가장 성능이 좋은 hardware에 있어야 할 필요가 없으면, index 설정을 update하여 해당 index를 warm node로 옮길 수 있다.
PUT /logs_2016-12-26/_settings { "settings": { "index.routing.allocation.require.box_type": "warm" } }
Now how can we achieve that using logstash or beats:
logstash나 beats를 사용하여 이를 하려면 어떻게 해야 할까?
If the index template is being managed at the logstash or beats level the index templates should be updated to include allocation filtering. The "index.routing.allocation.require.box_type" : "hot" setting will cause any new indices to be created on the hot nodes.
index template이 logstash나 beats 에서 관리된다면, index template이 allocation filtering을 포함하도록 update되어야 한다. "index.routing.allocation.require.box_type" : "hot" 을 설정하면, 새로운 index가 hot node에 생성된다.
Example:
{ "template" : "indexname-*", "version" : 50001, "settings" : { "index.routing.allocation.require.box_type": "hot" ...
Another strategy is to add a generic template for any index in the cluster, "template": "*" that creates new indices in hot nodes.
또 다른 방법은 cluster의 새로운 index에 대해 일반적인 template을 추가하는 것이다. "template" : "*" 은 hot node에 새로운 index를 생성한다.
Example:
{ "template" : "*", "version" : 50001, "settings" : { "index.routing.allocation.require.box_type": "hot" ...
When you have determined an index is not undergoing writes and is not being searched frequently it can be migrated from the hot nodes to the warm nodes. This can be accomplished by simply updating its index settings: "index.routing.allocation.require.box_type" : "warm". Elasticsearch will automatically migrate the indices over to the warm nodes.
index가 쓰기를 수행하지 않고 자주 search되지 않는 것으로 판단되면, hot node에서 warm node로 옮길 수 있다. 단순히 index 설정을 "index.routing.allocation.require.box_type" : "warm" 으로 update하면 된다. Elasticsearch는 자동으로 index를 warm node로 옮긴다.
Finally we can also enable better compression on all the warm data nodes by setting index.codec: best_compression in the elasticsearch.yml. When data is moved to warm nodes we can call the _forcemerge API in order to merge segments: not only will it save memory, disk-space and file handles by having fewer segments, but it will also have the side-effect of rewriting the index using this new best_compression codec.
마지막으로, elasticsearch.yml에서 index.codec: best_compression 을 설정하여, 모든 warm data node에서 더 나은 압축을 사용할 수 있다. data가 warm node로 옮겨지면, segment를 merge하기 위하여 _forcemerge API를 호출할 수 있다. 더 적은 segment를 가져 memory, disk 공간, file handle 절약할 수 있지만, 이 새로운 best_compression codec을 사용하려면 index를 다시 작성해야 하는 부작용이 있다.
It would be a bad idea to force merge the index while it was still allocated to the strong boxes, as the optimization process will swamp the I/O on those nodes and impact the indexing speed of today's logs. But the medium boxes aren't doing much, so it is safe to force merge them.
여전히 strong box에 할당되어 있는 index를 force merge하는 것은 좋지 않다. 왜냐하면, optimize process가 해당 node의 I/O를 잠식하고 오늘자 log의 index 속도에 영향을 미치기 때문이다. 그러나, medium box는 많지 않으므로, index를 force merge하는 것은 안전하다.
Now that we have seen how to manually change the shard allocation of an index, let's look at how to use one of our tools called Curator to automate the process.
이제, index의 shard allocation을 수동으로 변경하는 방법을 살펴았다. Curator 라는 tool을 사용하여 process를 자동화하는 방법을 살펴보자.
In the example below we are using curator 4.2 to move the indexes from hot nodes to warm nodes after 3 days:
아래의 예에서, index를 hot에서 warm node로 옮기기 위해 curator 4.2를 사용하였다.
actions: 1: action: allocation description: "Apply shard allocation filtering rules to the specified indices" options: key: box_type value: warm allocation_type: require wait_for_completion: true timeout_override: continue_if_exception: false disable_action: false filters: - filtertype: pattern kind: prefix value: logstash- - filtertype: age source: name direction: older timestring: '%Y.%m.%d' unit: days unit_count: 3
Finally we can use curator to force merge the index. Ensure you wait long enough for the reallocation to finish before running optimize. You can do that by setting wait_for_completion in action 1 or change the unit_count to select indices older than 4 days in the action 2, so they've had a chance to fully migrate before a force merge.
마지막으로, index를 force merge하기 위하여 curator를 사용할 수 있다. optimize를 실행하기 전에 reallocation이 완료될 때까지 충분히 기다려야 한다. 이를 위해, action 1에서 wait_for_completion을 설정하거나 action 2에서 4일 이상 경과된 index를 선택하기 위하여 unit_count를 변경해야 한다. 그러면, force merge 전에 완전히 옮길 수 있다.
2: action: forcemerge description: "Perform a forceMerge on selected indices to 'max_num_segments' per shard" options: max_num_segments: 1 delay: timeout_override: 21600 continue_if_exception: false disable_action: false filters: - filtertype: pattern kind: prefix value: logstash- - filtertype: age source: name direction: older timestring: '%Y.%m.%d' unit: days unit_count: 3
Note timeout_override should be increased the default is 21600 seconds, but it may go faster or slower, depending on your setup
timeout_override 는 기본값인 21600 초로 늘려야 하지만, 설정에 따라 더 빠르거나 더 느릴 수 있다는 점을 기억하자.
Since Elasticsearch 5.0 we can also use Rollover and shrink api to reduce the number of shards , which is a simpler, more efficient way of managing time-based indices. You can find more details about it in this blog.
Elasticsearch 5.0 부터, rollover, shrink API를 이용하여, shard의 수를 줄일 수 있는데, 이것이 시간 기반의 index를 관리하는 보다 간단하고 효율적인 방법이다. 여기에서 자세한 내용을 확인할 수 있다.
Like this topic? Dive deeper at Elastic{ON}, our user conference, and discuss it with our engineering team face to face. We hope to see you there.
원문 : "Hot-Warm" Architecture in Elasticsearch 5.x
참조 : Elasticsearch Hot Warm Architecture