es 운영

09 Apr 2019

샤드

매우 큰 샤드를 만드는 것을 피하세요. 이는 장애시 클러스터의 복구 능력에 좋지 않은 영향을 끼칩니다. 샤드 최대 크기에 대한 제한은 없습니다만, 다양한 실 사용사례를 비춰봤을 때 50GB를 넘지 않는 것이 좋습니다.

인덱스 보관 주기

도큐먼트를 삭제하는 것 역시 삭제 대상 도큐먼트를 찾아서 삭제 대상이라는 것을 표기하는 것입니다. (역자주: 실제로 삭제되는 것이 아닙니다.) 이러한 이유로, 삭제된 도큐먼트는 병합되기 전까지는 디스크 공간을 차지하고 시스템 자원을 사용하게 하며, 이는 많은 시스템 자원을 소비하게 합니다.

Elasticsearch는 명시적으로 모든 레코드를 하나하나씩 삭제하지 않고, 파일 시스템에서 인덱스들을 바로 삭제할 수 있는 무척 효율적인 기능을 제공합니다. 이 기능은 현재 Elasticsearch에서 데이터를 삭제하는 가장 효율적인 방법입니다.

데이터 보관 주기를 관리하기 위하여 가능한한 시간 기반 인덱스를 사용하세요. 보관 주기에 따라 데이터를 그룹핑하여 인덱스에 저장하세요. 시간 기반 인덱스는 프라이머리 샤드와 리플리카의 개수 조정을 쉽게 해주며, 후속 인덱스 생성시 이를 쉽게 변경할 수도 있습니다. 또한, 데이터의 볼륨과 요구사항을 쉽게 반영할 수도 있게 해줍니다.

인덱스와 샤드 운영

작은 샤드는 작은 세그먼트를 만들며 부하를 증가시킵니다. 평균 샤드 크기를 최소한 수 GB와 수십 GB 사이를 유지하세요. 시간 기반 데이터를 사용한 과거 사례를 보면, 20GB ~ 40GB 정도의 사이즈가 적당합니다.

각 샤드의 부하는 세그먼트 개수와 크기에 따라 결정됩니다. forcemerge 기능을 사용하여 작은 세그먼트를 큰 세그먼트로 병합시키세요. 이 작업은 이상적으로 인덱스에 더 이상 데이터가 입력되지 않을 때 실행되어야 합니다. 그리고 무척 부하가 큰 작업이니 피크 시간을 피하여 수행해야 하는 것을 명심하세요.

하나의 노드에 저장할 수 있는 샤드의 개수는 가용한 힙의 크기와 비례하지만, Elasticsearch에서 그 크기를 제한하고 있지는 않습니다. 경험상 하나의 노드에 설정한 힙 1GB 당 20개 정도가 적당합니다. 따라서 30GB 힙을 가진 노드는 최대 600개 정도의 샤드를 가지는 것이 가능하지만, 이 보다는 적게 유지하는 것이 더 좋습니다. 일반적으로 이러한 구성은 클러스터를 건강하게 유지하는데 도움이 됩니다.

인덱스 방법

고정 시간 주기로 되어 있는 시간 기반 인덱스는 데이터 볼륨이 예측 가능하고 변동폭이 적을 때 잘 동작합니다. 하지만, 데이터 인덱싱량이 빈번하게 변하는 경우라면, 균일하게 목표 샤드 크기를 유지하는 것이 무척 어렵죠.

Rollover 인덱스 API는 클러스터가 저장해야 하는 도큐먼트와 인덱스의 개수를 지정하거나, 저장해야 할 도큐먼트의 최대 기간을 지정할 수 있습니다. 위 두 조건 중 하나의 제약 조건을 넘어서면, Elasticsearch는 다운타임 없이 신규 인덱스를 생성합니다. 각 인덱스가 특정 기간을 처리하는 대신, 특정 크기가 되면 신규 인덱스로 전환하는 것이 가능해지기 때문에 모든 인덱스의 샤드 크기를 원하는 수준으로 유지하는 것이 더욱 쉬워집니다.

Shrink 인덱스 API는 기존 인덱스를 더 적은 개수의 프라이머리 샤드를 가진 신규 인덱스로 변경(shrink)하게 해줍니다. 인덱싱 중에 전체 노드에 샤드를 균등하게 분배하고 싶은데 샤드의 크기가 너무 작다면, 이 API를 사용하여 더 이상 인덱싱이 이뤄지지 않은 인덱스의 프라이머리 샤드 개수를 줄입니다. 이는 더 큰 샤드를 만들게 해주며 긴 기간 동안 보관해야하는 데이터인 시나리오에 더욱 적합합니다.

Reference

https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster