[es]샤드 크기 조정

Elasticsearch의 각 인덱스는 하나 이상의 샤드로 나뉘며, 각 샤드는 하드웨어 장애로부터 보호하기 위해 여러 노드에 걸쳐 복제될 수 있습니다. 데이터 스트림을 사용하는 경우 각 데이터 스트림은 인덱스 시퀀스로 지원됩니다. 단일 노드에 저장할 수 있는 데이터 양에는 제한이 있으므로 노드를 추가하고 일치시킬 인덱스 및 샤드 수를 늘려 클러스터의 용량을 늘릴 수 있습니다. 그러나 각 인덱스와 샤드에는 약간의 오버헤드가 있으며 데이터를 너무 많은 샤드로 나누면 오버헤드가 압도적으로 커질 수 있습니다. 너무 많은 인덱스 또는 샤드가 있는 클러스터는 오버샤딩 으로 인해 어려움을 겪는다고 합니다 . 오버샤딩된 클러스터는 검색에 대한 응답이 덜 효율적이며 극단적인 경우 불안정해질 수도 있습니다.

샤딩 전략 만들기

오버샤딩 및 기타 샤드 관련 문제를 방지하는 가장 좋은 방법은 샤딩 전략을 만드는 것입니다. 샤딩 전략은 샤드의 크기를 제한하면서 클러스터에 대한 최적의 샤드 수를 결정하고 유지하는 데 도움이 됩니다.

불행하게도 만능 샤딩 전략은 없습니다. 한 환경에서 작동하는 전략은 다른 환경에서 확장되지 않을 수 있습니다. 좋은 샤딩 전략은 인프라, 사용 사례 및 성능 기대치를 고려해야 합니다.

샤딩 전략을 만드는 가장 좋은 방법은 프로덕션에서 볼 수 있는 것과 동일한 쿼리 및 인덱싱 로드를 사용하여 프로덕션 하드웨어에서 프로덕션 데이터를 벤치마킹하는 것입니다. 권장 방법론에 대해서는 정량적 클러스터 크기 조정 비디오를 시청하십시오 . 다양한 샤드 구성을 테스트할 때 Kibana의 Elasticsearch 모니터링 도구를 사용하여 클러스터의 안정성과 성능을 추적하세요.

다음 섹션에서는 샤딩 전략을 설계할 때 고려해야 할 몇 가지 알림 및 지침을 제공합니다. 클러스터가 이미 오버샤딩된 경우 클러스터의 샤드 수 줄이기를 참조하십시오 .

크기 조정 고려 사항

샤딩 전략을 세울 때 다음 사항을 염두에 두십시오.

검색은 샤드당 단일 스레드에서 실행됩니다.

대부분의 검색은 여러 샤드에 도달합니다. 각 샤드는 단일 CPU 스레드에서 검색을 실행합니다. 샤드는 여러 동시 검색을 실행할 수 있지만 많은 수의 샤드에 대한 검색은 노드의 검색 스레드 풀을 고갈시킬 수 있습니다 . 이로 인해 처리량이 낮아지고 검색 속도가 느려질 수 있습니다.

각 인덱스, 샤드, 세그먼트 및 필드에는 오버헤드가 있습니다.

모든 인덱스와 모든 샤드에는 약간의 메모리와 CPU 리소스가 필요합니다. 대부분의 경우 큰 샤드의 작은 집합은 많은 작은 샤드보다 적은 리소스를 사용합니다.

세그먼트는 샤드의 리소스 사용에서 큰 역할을 합니다. 대부분의 샤드는 인덱스 데이터를 저장하는 여러 세그먼트를 포함합니다. Elasticsearch는 검색을 위해 빠르게 검색할 수 있도록 일부 세그먼트 메타데이터를 힙 메모리에 보관합니다. 샤드가 커짐에 따라 해당 세그먼트는 더 적은 수의 더 큰 세그먼트로 병합 됩니다. 이렇게 하면 세그먼트 수가 줄어들어 힙 메모리에 보관되는 메타데이터가 줄어듭니다.

모든 매핑된 필드에는 메모리 사용 및 디스크 공간 측면에서 약간의 오버헤드가 있습니다. 기본적으로 Elasticsearch는 인덱싱하는 모든 문서의 모든 필드에 대한 매핑을 자동으로 생성하지만 이 동작을 해제하여 매핑을 제어 할 수 있습니다 .

또한 모든 세그먼트에는 매핑된 각 필드에 대해 소량의 힙 메모리가 필요합니다. 이 필드당 세그먼트 힙 오버헤드에는 해당하는 경우 ISO-8859-1을 사용하거나 그렇지 않은 경우 UTF-16을 사용하여 인코딩된 필드 이름의 복사본이 포함됩니다. 일반적으로 이것은 눈에 띄지 않지만 샤드의 세그먼트 수가 많고 해당 매핑에 높은 필드 수 및/또는 매우 긴 필드 이름이 포함된 경우 이 오버헤드를 고려해야 할 수 있습니다.

Elasticsearch는 데이터 계층 내에서 샤드의 균형을 자동으로 조정합니다.

클러스터의 노드는 데이터 계층 으로 그룹화됩니다 . 각 계층 내에서 Elasticsearch는 가능한 한 많은 노드에 인덱스의 샤드를 분산시키려고 시도합니다. 새 노드를 추가하거나 노드에 장애가 발생하면 Elasticsearch는 계층의 나머지 노드에서 인덱스 샤드의 균형을 자동으로 재조정합니다.

모범 사례

해당하는 경우 샤딩 전략의 시작점으로 다음 모범 사례를 사용하십시오.

문서가 아닌 인덱스 삭제

삭제된 문서는 Elasticsearch의 파일 시스템에서 즉시 제거되지 않습니다. 대신 Elasticsearch는 각 관련 샤드에서 문서를 삭제된 것으로 표시합니다. 표시된 문서는 주기적 세그먼트 병합 중에 제거될 때까지 리소스를 계속 사용합니다 .

가능한 경우 대신 전체 색인을 삭제하십시오. Elasticsearch는 삭제된 인덱스를 파일 시스템에서 직접 즉시 제거하고 리소스를 확보할 수 있습니다.

시계열 데이터에 데이터 스트림 및 ILM 사용

데이터 스트림을 사용 하면 여러 시간 기반 백업 인덱스에 시계열 데이터를 저장할 수 있습니다. 인덱스 수명 주기 관리(ILM)를 사용하여 이러한 지원 인덱스를 자동으로 관리 할 수 있습니다 .

이 설정의 장점 중 하나는 현재 쓰기 인덱스가 정의된 , , 또는 임계값을 충족할 때 새 쓰기 인덱스를 생성하는 자동 롤오버 입니다 . 인덱스가 더 이상 필요하지 않으면 ILM을 사용하여 인덱스를 자동으로 삭제하고 리소스를 확보할 수 있습니다.max_primary_shard_sizemax_agemax_docsmax_size

또한 ILM을 사용하면 시간 경과에 따라 샤딩 전략을 쉽게 변경할 수 있습니다.

• 새 인덱스의 샤드 수를 줄이고 싶습니까? 데이터 스트림의 일치 색인 템플릿
  에서 설정 을 변경합니다. index.number_of_shards
• 더 큰 샤드 또는 더 적은 백업 인덱스를 원하십니까?
  ILM 정책의 롤오버 임계값을 높입니다 .
• 더 짧은 간격에 걸친 인덱스가 필요하십니까?
  오래된 인덱스를 더 빨리 삭제하여 증가된 샤드 수를 상쇄합니다. min_age정책의 삭제 단계 에 대한 임계값 을 낮추면 됩니다.

모든 새로운 지원 지수는 전략을 추가로 조정할 수 있는 기회입니다.

10GB에서 50GB 사이의 샤드 크기를 목표로 합니다.

샤드가 클수록 장애 후 복구하는 데 더 오래 걸립니다. 노드가 실패하면 Elasticsearch는 데이터 계층의 나머지 노드에서 노드의 샤드를 재조정합니다. 이 복구 프로세스에는 일반적으로 네트워크를 통해 샤드 콘텐츠를 복사하는 작업이 포함되므로 100GB 샤드는 50GB 샤드보다 복구하는 데 두 배의 시간이 걸립니다. 대조적으로, 작은 샤드는 상대적으로 더 많은 오버헤드를 수반하고 검색 효율성이 떨어집니다. 50개의 1GB 샤드를 검색하는 것은 동일한 데이터가 포함된 단일 50GB 샤드를 검색하는 것보다 훨씬 더 많은 리소스가 필요합니다.

샤드 크기에는 엄격한 제한이 없지만 경험에 따르면 로그 및 시계열 데이터에는 일반적으로 10GB에서 50GB 사이의 샤드가 적합합니다. 네트워크 및 사용 사례에 따라 더 큰 샤드를 사용할 수 있습니다. 엔터프라이즈 검색 및 유사한 사용 사례 에는 더 작은 샤드가 적합할 수 있습니다 .

ILM을 사용하는 경우 롤오버 작업 의 max_primary_shard_size임계값을 50gb50GB보다 큰 샤드를 방지하도록 설정합니다.

샤드의 현재 크기를 보려면 cat 샤드 API를 사용하십시오 .