2020년 11월 27일 ObjectRocket.com/blog에서 원래 게시되었습니다.
Elasticsearch®는 기본 설정으로 클러스터 전체에 데이터를 분산하는 데 탁월하지만 클러스터가 성장하기 시작한 후에는 기본 설정을 조정하여 효율성을 높여야 합니다. 샤딩의 몇 가지 기본 사항을 살펴보고 몇 가지 인덱싱 및 샤드 모범 사례를 제공하겠습니다.
Elasticsearch 샤딩 소개
Elasticsearch 샤드의 작동 방식에 대한 많은 문서가 있지만 샤딩의 기본 개념은 검색이 여러 부분에서 병렬로 작동할 수 있도록 데이터를 여러 개의 작은 조각으로 나누는 것입니다. 인덱스 함수의 클러스터링 및 병렬화를 용이하게 하려면 Elasticsearch 인스턴스의 각 인덱스를 번호가 매겨진 조각으로 분할하십시오. 이러한 슬라이스를 샤드라고 합니다. 이들의 주요 행동을 살펴보겠습니다.
- 각 샤드는 복제본 수에 따라 복제됩니다. 인덱스에 대한 설정. 따라서 복제본 수의 경우 1로 설정하면 각 샤드에 2개의 사본이 있습니다. 하나는 기본입니다. 샤드 및 하나의 복제본 사금파리. 기본 샤드는 메인 샤드이며
indexing/write에 사용됩니다. 및search/read복제 샤드는search/read에만 사용됩니다. 운영 및 기본 장애가 발생한 경우 복구를 위한 것입니다. - 복제본 조각은 상위와 다른 호스트에 있어야 합니다. 기본 샤드.
- 샤드는 기본적으로 클러스터의 여러 호스트에 자동으로 분산되지만 동일한 물리적 호스트에 여러 기본 샤드가 포함될 수 있습니다. Elasticsearch 설정을 사용하여 이 동작(재조정, 샤드 할당 등)을 수정할 수 있지만 해당 절차는 이 게시물의 범위를 벗어납니다.
- 샤드는 분할할 수 없으므로 각 샤드는 하나의 호스트에만 있어야 합니다.
- 인덱스 생성 중에 인덱스가 생성하는 샤드 수를 설정하거나 전역 기본값을 사용할 수 있습니다. 인덱스를 생성한 후에는 다시 인덱싱하지 않고는 샤드 수를 변경할 수 없습니다.
- 인덱스 생성 중에 인덱스가 갖는 복제본 수를 설정하거나 전역 기본값을 사용할 수 있습니다. 색인을 생성한 후 이 번호를 변경할 수 있습니다.
작은 예를 살펴보겠습니다. 샤드 개수가 3이고 복제본 설정이 1인 인덱스를 만들었습니다. 앞의 다이어그램에서 볼 수 있듯이 Elasticsearch는 3개의 기본 샤드(Ap, Bp 및 Cp)와 3개의 복제본 샤드(Ar, Br 및 Cr)라는 6개의 샤드를 생성합니다.
Elasticsearch는 복제본과 기본이 다른 호스트에 있는지 확인하지만 동일한 호스트에 여러 기본 샤드를 할당할 수 있습니다. 호스트를 주제로 호스트에 샤드를 할당하는 방법에 대해 알아보겠습니다.
샤드 할당 및 클러스터형 Elasticsearch
Elasticsearch는 기본적으로 사용 가능한 모든 호스트에 샤드를 할당하려고 시도합니다. Rackspace ObjectRocket에서 각 클러스터는 마스터 노드, 클라이언트 노드 및 데이터 노드로 구성됩니다. 아키텍처의 데이터 노드는 버킷을 형성합니다. 샤드를 할당할 수 있습니다.
앞의 예를 사용하여 6개의 샤드를 가져와 2개의 데이터 노드(최소값)가 있는 ObjectRocket for Elasticsearch 클러스터에 할당해 보겠습니다. 다음 다이어그램에서 각 샤드에 대해 기본 데이터 노드가 하나의 데이터 노드에 있는 반면 복제본은 다른 노드에 있음을 확인할 수 있습니다. 여기의 예는 하나의 가능한 할당만을 보여줍니다. 할당에 관계없이 유일하게 확실한 것은 복제본이 항상 기본 노드와 다른 데이터 노드에 배치된다는 것입니다.
이제 이 예제를 확장하고 세 번째 데이터 노드를 추가해 보겠습니다. 2개의 샤드가 새 데이터 노드로 이동되었으므로 각 노드에 2개의 샤드가 있습니다.
마지막으로 샤드 수가 2이고 복제본 수가 2로 설정된 이 클러스터에 새 인덱스를 추가해 보겠습니다. 이렇게 하면 다음 이미지와 같이 클러스터 전체에 분산할 수 있는 2개의 새로운 기본(Xp 및 Yp)과 4개의 복제본(Xr0, Xr1, Yr0, Yr1)이 제공됩니다.
그게 다야.
위험
Elasticsearch가 모든 힘든 일을 대신해 주지만 피해야 할 몇 가지 함정이 있습니다.
위험 #1 - 대규모 인덱스 및 대규모 샤드
대규모 샤드가 있는 대규모 인덱스 문제를 해결하는 것은 Elasticsearch에서 완화하기 가장 쉬운 문제 중 하나입니다. 사용자는 관리하기 쉬운 단일 인덱스로 시작합니다. 그러나 응용 프로그램이 증가함에 따라 색인도 증가합니다. 샤드 크기는 클러스터 데이터의 양과 직접적인 관련이 있기 때문에 이는 거대한 샤드로 이어집니다.
이로 인해 발생하는 첫 번째 문제는 클러스터 활용의 효율성이 떨어지는 것입니다. 샤드가 커질수록 데이터 노드에 배치하기가 더 어려워집니다. 거기에 샤드를 저장하려면 데이터 노드 여유 공간의 큰 블록이 필요합니다. 이 조건은 사용되지 않고 낭비되는 공간이 많은 노드로 이어집니다. 예를 들어, 8GB 데이터 노드가 있지만 각 샤드가 6GB인 경우 각 데이터 노드에서 2GB를 좌초합니다. 두 번째 문제는 핫 스포팅입니다. . 데이터를 몇 개의 샤드로 통합하면 복잡한 쿼리를 더 많은 노드로 분할하여 병렬로 실행할 수 없습니다.
인덱스에 집착하지 마세요
여러 인덱스를 사용하여 지연된 공간 문제를 해결합니다. 여러 인덱스에 데이터를 분산하여 클러스터의 샤드 수를 늘리고 데이터를 고르게 분산하십시오. 또한 테트리스 게임처럼 Elasticsearch가 샤드를 배치할 때 여러 인덱스를 큐레이션하기가 더 쉽습니다. Elasticsearch의 별칭 기능은 여전히 여러 인스턴스를 앱에 대한 단일 인덱스로 표시할 수 있습니다. 대부분의 Elastic Stack은 기본적으로 일일 인덱스를 생성하며 이는 좋은 방법입니다. 그런 다음 별칭을 사용하여 검색 범위를 특정 날짜 범위로 제한하고 큐레이터를 사용하여 오래된 인덱스를 제거하고 오래된 데이터를 다시 인덱스할 필요 없이 데이터가 증가함에 따라 인덱스 설정을 수정할 수 있습니다.
인덱스 크기가 증가함에 따라 샤드 수 증가
인덱스를 더 자주 추가하고 인덱스가 커짐에 따라 샤드 수를 늘립니다. 샤드 크기가 원하는 공간을 초과하기 시작하면 인덱스 템플릿(또는 새 인덱스 생성에 사용하는 모든 것)을 업데이트하여 각 인덱스에 더 많은 샤드를 사용할 수 있습니다. 그러나 이는 새 인덱스를 자주 생성하는 경우에만 도움이 되므로 이 권장 사항은 두 번째로 나열됩니다. 그렇지 않으면 여러 색인을 관리하는 것보다 더 많은 작업을 나타내는 샤드 수를 수정하기 위해 색인을 다시 작성해야 합니다.
경험의 법칙:샤드가 데이터 노드 크기의 40%보다 크면 해당 샤드가 너무 클 수 있습니다. 이 경우 더 많은 샤드가 있는 인덱스로 다시 인덱싱하거나 더 큰 계획 크기(데이터 노드당 더 많은 용량)로 이동하는 것이 좋습니다.
위험 #2 - 너무 많은 인덱스 또는 샤드
inverse는 인덱스나 샤드가 너무 많습니다. 이전 섹션을 읽은 후 "좋아요. 모든 문서를 인덱스에 넣고 백만 개의 샤드를 생성하겠습니다." 문제는 인덱스와 샤드에 오버헤드가 있다는 것입니다. 이러한 오버헤드는 스토리지, 메모리 리소스 및 처리 성능에서 나타납니다.
클러스터는 모든 샤드의 상태와 위치를 유지해야 하기 때문에 엄청난 수의 샤드가 더 큰 부기 작업이 되어 메모리 사용량에 영향을 미칩니다. 또한 쿼리를 더 많은 방법으로 분할해야 하기 때문에 쿼리를 위해 분산하거나 수집하는 데 훨씬 더 많은 시간을 소비합니다. 이 함정은 클러스터의 크기, 사용 사례 및 기타 요인에 따라 크게 달라지지만 일반적으로 몇 가지 권장 사항으로 이를 완화할 수 있습니다.
샤드는 50GB 이하여야 합니다.
일반적으로 25GB는 큰 샤드에 이상적인 크기이고 50GB는 다시 인덱싱해야 합니다. 이 고려 사항은 샤드의 성능 및 필요할 때 해당 샤드를 이동하는 프로세스와 관련이 있습니다. 재조정할 때 샤드를 클러스터의 다른 노드로 이동합니다. 50GB 데이터 전송은 너무 오래 걸리고 전체 프로세스 동안 두 개의 노드를 묶을 수 있습니다.
샤드 크기를 데이터 노드 크기의 40% 미만으로 유지
앞서 언급했듯이 두 번째 샤드 크기 메트릭은 샤드가 차지하는 데이터 노드 용량의 백분율입니다. Rackspace ObjectRocket 서비스에서는 데이터 노드의 스토리지 양과 관련된 다양한 계획 크기를 제공합니다. 클러스터와 샤드의 크기를 조정하여 가장 큰 샤드가 데이터 노드 용량의 40% 이상을 차지하지 않도록 합니다. 다양한 크기의 인덱스가 여러 개 있는 클러스터에서 이는 상당히 효과적입니다. 그러나 큰 인덱스가 거의 없는 클러스터에서는 더욱 공격적으로 착용하고 데이터 노드의 용량을 30% 미만으로 유지하십시오.
이상적으로는 데이터 노드에서 용량을 낭비하지 않는지 확인하십시오. 샤드가 데이터 노드 크기의 약 45%인 경우 해당 샤드를 배치하려면 사용률이 약 절반인 데이터 노드가 필요합니다. 사용하지 않은 여분의 용량이 많습니다!
결론
올바른 샤드 및 인덱싱 설정을 선택하는 것은 어려울 수 있지만 계획을 세우고 사전에 몇 가지 좋은 결정을 내리고 진행하면서 조정하면 클러스터를 정상 상태로 유지하고 최적으로 실행할 수 있습니다. 우리는 기업이 Elasticsearch 인스턴스를 항상 개선할 수 있도록 지원합니다.
Rackspace DBA 서비스에 대해 자세히 알아보십시오.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 영업 채팅을 클릭할 수도 있습니다. 지금 채팅하고 대화를 시작하세요.