반응형
샤드란 무엇인가
Elasticsearch에서 인덱스 템플릿(Index Template)을 추가할 때 샤드(Shard)의 숫자를 설정하는 것은 인덱스의 성능과 관리에 중요한 영향을 미칩니다. 샤드의 숫자를 결정할 때는 여러 가지 요소를 고려해야 하며, 샤드의 수가 많거나 적은 것이 각각 장단점을 가집니다.
샤드의 숫자가 많을 때의 장점:
- 병렬 처리 향상: 데이터가 여러 샤드에 분산되므로, 검색 및 색인 작업을 병렬로 처리할 수 있습니다. 이는 시스템의 처리량을 높일 수 있습니다.
- 확장성: 더 많은 샤드를 가지면 데이터를 여러 노드에 분산시킬 수 있어 클러스터의 확장성이 향상됩니다.
- 고가용성: 데이터가 여러 샤드에 복제되어 있기 때문에, 단일 샤드 또는 노드의 실패가 전체 시스템의 가용성에 덜 영향을 미칩니다.
샤드의 숫자가 많을 때의 단점:
- 관리 복잡성: 샤드의 수가 증가하면 클러스터 관리가 더 복잡해집니다. 샤드 할당 및 재조정 작업이 더 많아질 수 있습니다.
- 오버헤드 증가: 각 샤드는 자체적인 오버헤드를 가지므로, 너무 많은 샤드가 있으면 클러스터의 성능이 저하될 수 있습니다.
- 리소스 사용 증가: 더 많은 샤드는 더 많은 파일 핸들과 메모리 사용을 의미합니다. 이는 특히 작은 데이터 세트에 대해 과도한 수의 샤드를 가질 때 문제가 될 수 있습니다.
- 검색 성능 저하: 검색 시 각 샤드에서 결과를 병합해야 하는데, 샤드의 수가 많으면 병합 과정에 더 많은 시간과 리소스가 소요될 수 있습니다.
결론적으로, 샤드의 적절한 숫자는 사용 사례, 데이터의 크기, 클러스터의 사양 및 기대되는 성능 요구 사항에 따라 달라집니다. 일반적으로 너무 많은 샤드를 피하고, 데이터의 크기와 성장 예상치를 기반으로 샤드의 수를 계획하는 것이 좋습니다.
적절한 샤드 숫자는?
Elasticsearch 공식 문서에 보면 다음과 같은 팁이 있습니다.
Aim for shards of up to 200M documents, or with sizes between 10GB and 50GB
- Allow enough heap for field mappers and overheads
- 노드당 힙사이즈 계산시 데이터 노드의 인덱스당 필드당 1kB 힙 + 오버헤드를 허용하세요.
정확한 공식은 존재하지 않지만, 사용자가 경험하면서 적절한 값을 찾아 나가할 듯 합니다. 또 샤드에 맞는 적절한 Heap size을 갖고 있어야합니다. 참고로 7.x 버전에서는 다음과 같은 팁도 있었지만 8.x로 올라가면서 변경됐다고 합니다.
하나의 노드에 저장할 수 있는 샤드의 개수는 가용한 힙의 크기와 비례하지만, Elasticsearch에서 그 크기를 제한하고 있지는 않습니다. 경험상으로 보면 노드의 샤드 개수를 하나의 노드에 설정한 힙 1GB당 20개 미만으로 유지하는 것이 좋습니다. 따라서 힙이 30GB인 노드는 최대 600개의 샤드를 가질 수 있지만 이보다 훨씬 더 적게 유지하는 것이 더 좋습니다. 일반적으로 이러한 구성은 클러스터를 건강하게 유지하는데 도움이 됩니다.
https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
반응형