7-2-1. Hardware

If you’ve been following the normal development path, you’ve probably been playing with Elasticsearch on your laptop or on a small cluster of machines lying around. But when it comes time to deploy Elasticsearch to production, there are a few recommendations that you should consider. Nothing is a hard-and-fast rule; Elasticsearch is used for a wide range of tasks and on a bewildering array of machines. But these recommendations provide good starting points based on our experience with production clusters.

정상적인 개발 경로를 따라왔다면, 아마도 노트북이나 주위에 있는 작은 cluster machine에서Elasticsearch를 실행하고 있을 것이다. 그러나 Elasticsearch를 제품에 배포할 시점이 되면, 고려해야 할 몇 가지 권장 사항이 있다. 명확한 규칙은 없다. Elasticsearch는 다양한 업무 영역과 다양한 machine에서 사용된다. 하지만, 이들 권장 사항은, cluster에 대한 우리의 경험을 바탕으로, 좋은 출발점을 제공할 것이다.

Memoryedit

If there is one resource that you will run out of first, it will likely be memory. Sorting and aggregations can both be memory hungry, so enough heap space to accommodate these is important. Even when the heap is comparatively small, extra memory can be given to the OS filesystem cache. Because many data structures used by Lucene are disk-based formats, Elasticsearch leverages the OS cache to great effect.

가장 먼저 부족해지는 자원 하나가 있다면, 그것은 메모리일 것이다. 정렬과 aggregation은 모두 메모리를 많이 사용한다. 따라서, 이들을 위해 충분한 heap 공간이 중요하다. heap이 비교적 작은 경우에도, 추가 메모리는 OS filesystem cache로 제공될 수 있다. Lucene에 의해 사용되는 많은 데이터 구조들은 디스크 기반 형태이기 때문에, Elasticsearch에 커다란 영향을 미치는 OS cache를 강화해야 한다.

A machine with 64 GB of RAM is the ideal sweet spot, but 32 GB and 16 GB machines are also common. Less than 8 GB tends to be counterproductive (you end up needing many, many small machines), and greater than 64 GB has problems that we will discuss in Heap: Sizing and Swapping.

64 GB RAM을 가진 machine은 이상적이지만, 32GB와 16GB machine도 아주 일반적이다. 8GB 이하는 역효과를 낳고(매우 많은 작은 machine이 필요하게 된다), 64 GB 이상이면 Heap: Sizing and Swapping에서 이야기할 문제를 가지고 있다.

CPUsedit

Most Elasticsearch deployments tend to be rather light on CPU requirements. As such, the exact processor setup matters less than the other resources. You should choose a modern processor with multiple cores. Common clusters utilize two- to eight-core machines.

대부분의 Elasticsearch 배포는 CPU 요구 사항은 오히려 가벼운 경향이 있다. 따라서, 정확한 프로세서 설정은 다른 자원보다 덜 중요하다. 다수의 core를 가진 현대적인 프로세서를 선택해야 한다. 일반적으로 cluster는 2~8 core machine을 사용한다.

If you need to choose between faster CPUs or more cores, choose more cores. The extra concurrency that multiple cores offers will far outweigh a slightly faster clock speed.

더 빠른 CPU와 더 많은 core 중에 선택해야 한다면, 더 많은 core를 선택하자. 다수의 core가 제공하는 여분의 동시성은 약간 더 빠른 clock 속도를 훨씬 능가할 것이다.

Disksedit

Disks are important for all clusters, and doubly so for indexing-heavy clusters (such as those that ingest log data). Disks are the slowest subsystem in a server, which means that write-heavy clusters can easily saturate their disks, which in turn become the bottleneck of the cluster.

디스크는 모든 cluster에서 중요하다. 그리고, 색인이 많은 cluster(예: 로그 데이터를 색인 하는 cluster)에서는 두 배로 중요하다. 디스크는 서버에서 가장 느린 서브 시스템이다. 이것은 쓰기 동작이 많은 cluster는 cluster에 대해 차례로 병목현상이 발생해, 쉽게 자신의 디스크를 포화상태로 된다는 것을 의미한다.

If you can afford SSDs, they are by far superior to any spinning media. SSD-backed nodes see boosts in both query and indexing performance. If you can afford it, SSDs are the way to go.

SSD가 여유가 있다면, 그것은 지금까지의 어떤 회전 매체보다 우수하다. SSD가 있는 node는 query와 색인 성능이 모두 향상되는 것을 볼 수 있다. 여유가 있다면, SSD가 가야 할 방향이다.

I/O scheduler를 확인하자

If you are using SSDs, make sure your OS I/O scheduler is configured correctly. When you write data to disk, the I/O scheduler decides when that data is actually sent to the disk. The default under most *nix distributions is a scheduler called cfq (Completely Fair Queuing).

SSD를 사용한다면, OS의 I/O scheduler가 올바르게 설정되어 있는지 확인하자. 데이터가 디스크에 기록될 때, I/O scheduler는 데이터가 디스크에 실제로 보내질 시기를 결정한다. 대부분의 *nix 배포판에서 기본값은 cfq(Completely Fair Queuing)라는 scheduler이다.

This scheduler allocates time slices to each process, and then optimizes the delivery of these various queues to the disk. It is optimized for spinning media: the nature of rotating platters means it is more efficient to write data to disk based on physical layout.

이 scheduler는 각 프로세스에 time slices 를 할당한 후, 디스크에 이러한 다양한 queue의 전달을 최적화한다. 그것은 HDD에 최적화되어 있다. 회전하는 platters의 특성은 물리적인 레이아웃을 기반으로 디스크에 데이터를 기록하는 것이 더 효과적이라는 것을 의미한다.

This is inefficient for SSD, however, since there are no spinning platters involved. Instead, deadline or noop should be used instead. The deadline scheduler optimizes based on how long writes have been pending, while noop is just a simple FIFO queue.

그러나, 이것은 SSD에서 비효율적이다. 왜냐하면 회전하는 platters가 없기 때문이다. 대신에,deadline 이나 noop 를 사용해야 한다. deadline scheduler는 기록을 위해 기다린 시간을 기반으로 최적화한다. 반면에, noop 는 단순한 FIFO queue이다.

This simple change can have dramatic impacts. We’ve seen a 500-fold improvement to write throughput just by using the correct scheduler.

이 간단한 변화는 극적인 영향을 미칠 수 있다. 올바른 scheduler를 사용하여, 쓰기 처리량이 500배나 개선된 경우도 있다.

If you use spinning media, try to obtain the fastest disks possible (high-performance server disks, 15k RPM drives).

HDD를 사용하는 경우, 가능한 한 가장 빠른 디스크(고성능 서버 디스크, 15,000 RPM drive)를 구하도록 하자.

Using RAID 0 is an effective way to increase disk speed, for both spinning disks and SSD. There is no need to use mirroring or parity variants of RAID, since high availability is built into Elasticsearch via replicas.

RAID 0을 사용하는 것은 HDD와 SSD 모두에 대해, 디스크 속도를 증가시키는 효과적인 방식이다. 고가용성의 replica가 Elasticsearch에 내장되어 있기 때문에, RAID의 mirroring이나 parity variants를 사용할 필요가 없다.

Finally, avoid network-attached storage (NAS). People routinely claim their NAS solution is faster and more reliable than local drives. Despite these claims, we have never seen NAS live up to its hype. NAS is often slower, displays larger latencies with a wider deviation in average latency, and is a single point of failure.

마지막으로, NAS(Network Attached Storages)를 사용하지 말자. 사람들은 흔히 그들의 NAS가 로컬 드라이브보다 더 빠르고, 더 신뢰할 수 있다고 주장한다. 이런 주장에도 불구하고, 그 광고에 부응하는 NAS를 본적이 없다. NAS는 대체로 더 느리고, 평균 대기 시간에서 더 폭넓은 편차를 가진 더 큰 대기시간을 보여준다. 그리고, 단일 장애 지점(SPOF: Single Point Of Failure)이다.

Networkedit

A fast and reliable network is obviously important to performance in a distributed system. Low latency helps ensure that nodes can communicate easily, while high bandwidth helps shard movement and recovery. Modern data-center networking (1 GbE, 10 GbE) is sufficient for the vast majority of clusters.

빠르고 안정적인 네트워크는 분산 시스템에서 성능에 분명히 중요하다. 낮은 대기시간은 node가 쉽게 통신하도록 보장하는데 도움이 된다. 반면에, 높은 대역폭은 shard의 이동과 복구에 도움이 된다. 데이터센터의 네트워킹(1 GbE, 10 GbE)은 대부분의 cluster에 충분하다.

Avoid clusters that span multiple data centers, even if the data centers are colocated in close proximity. Definitely avoid clusters that span large geographic distances.

데이터센터가 아주 가깝게 있더라도, 다수의 데이터센터에 cluster를 배치하는 것을 피하자. 지리적으로 먼 거리에 cluster를 배치하는 것은 절대로 피하자.

Elasticsearch clusters assume that all nodes are equal—not that half the nodes are actually 150ms distant in another data center. Larger latencies tend to exacerbate problems in distributed systems and make debugging and resolution more difficult.

Elasticsearch cluster는 모든 node가 동일한 데이터센터에 있다고 가정한다. 더 큰 대기 시간은 분산 시스템에서 문제를 악화시키고, 디버깅과 해결을 더 어렵게 만드는 경향이 있다.

Similar to the NAS argument, everyone claims that their pipe between data centers is robust and low latency. This is true—until it isn’t (a network failure will happen eventually; you can count on it). From our experience, the hassle of managing cross–data center clusters is simply not worth the cost.

NAS와 마찬가지로, 모든 사람이 데이터센터간에 통신은 견고하고 낮은 대기시간을 가진다고 주장한다. 이것은 사실이다, 그러지 않을 때까지. 네트워크 장애는 언젠가는 발생한다. 믿어야 한다. 경험적으로 볼 때, 데이터센터간의 cluster를 관리하는 번거로움은, 간단히 말하면, 비용을 들일 가치가 없다.

General Considerationsedit

It is possible nowadays to obtain truly enormous machines: hundreds of gigabytes of RAM with dozens of CPU cores. Conversely, it is also possible to spin up thousands of small virtual machines in cloud platforms such as EC2. Which approach is best?

요즘에는 진짜 거대한 machine을 획득하는 것이 가능하다. 수십 개의 CPU core를 가진 수백 GB의 RAM. 역으로, EC2 같은 cloud platform에서 작은 가상 machine 수천 개를 운영하는 것도 가능하다. 어떤 것이 최선일가?

In general, it is better to prefer medium-to-large boxes. Avoid small machines, because you don’t want to manage a cluster with a thousand nodes, and the overhead of simply running Elasticsearch is more apparent on such small boxes.

일반적으로 큰 박스 보다 중간을 선호하는 것이 더 낫다. 천 개의 node를 가진 cluster를 운영하지 않으려면, 작은 machine은 피하자. 그리고, 단순히 Elasticsearch를 실행하는데 따른 오버헤드는 그런 작은 machine에서 더 분명해진다.

At the same time, avoid the truly enormous machines. They often lead to imbalanced resource usage (for example, all the memory is being used, but none of the CPU) and can add logistical complexity if you have to run multiple nodes per machine.

동시에, 정말 거대한 machine을 피하자. 그것은 가끔 자원 사용에 있어 불균형(예를 들어, 모든 메모리가 사용 중이지만, CPU는 전혀 아닌)이 자주 나타나고, machine 별로 다수의 node를 실행해야 하는 경우, 논리적인 복합성이 추가될 수 있다.