샤드 수 선택

스토리지 요구 사항을 이해했으면 인덱싱 전략을 조사할 수 있습니다. 기본적으로 OpenSearch 서비스에서 각 인덱스는 5개의 기본 샤드와 1개의 복제본(총 10개의 샤드)으로 구분됩니다. 이 동작은 기본적으로 기본 샤드 하나와 복제본 샤드 하나를 OpenSearch사용하는 오픈 소스 와 다릅니다. 기존 인덱스에 대한 기본 샤드 수는 쉽게 변경할 수 없으므로, 첫 번째 문서를 인덱싱하기 전에 샤드 수를 결정해야 합니다.

여러 샤드를 선택하는 전반적인 목표는 클러스터의 모든 데이터 노드에서 인덱스를 균등하게 분산시키는 것입니다. 하지만 이러한 샤드는 너무 크거나 너무 많아서는 안 됩니다. 일반적인 지침은 검색 지연 시간이 핵심 성능 목표인 워크로드의 경우 샤드 크기를 10~30GiB로 유지하고, 로그 분석과 같은 쓰기 작업이 많은 워크로드의 경우 30~50GiB를 유지하는 것입니다.

큰 샤드는 장애 복구 OpenSearch 를 어렵게 만들 수 있지만 각 샤드는 일정량의 CPU 및 메모리를 사용하기 때문에 샤드가 너무 많으면 성능 문제가 발생하고 메모리 부족 오류가 발생할 수 있습니다. 즉, 샤드는 기본 OpenSearch 서비스 인스턴스가 처리할 수 있을 만큼 작아야 하지만 하드웨어에 불필요한 부담을 주지 않아야 합니다.

예를 들어, 66GiB의 데이터가 있다고 가정해 봅니다. 시간이 지남에 따라 그 수가 늘어날 것으로 예상하지 않으며 샤드를 각각 30GiB 정도로 유지하려고 합니다. 따라서 샤드 수는 약 66 * 1.1/30 = 3개가 되어야 합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.

(소스 데이터 + 늘어날 공간) * (1 + 인덱싱 오버헤드)/원하는 샤드 크기 = 대략적인 기본 샤드 수

이 수식은 시간이 지남에 따라 데이터 성장 보정에 유용합니다. 동일한 66GiB의 데이터가 내년에 4배가 될 것으로 예상한다면 대략적인 샤드 수는 (66 + 198) * 1.1/30 = 10개가 됩니다. 하지만 아직 추가로 198GiB의 데이터가 필요하지는 않습니다. 미래를 위한 이 준비가 현재 엄청난 양의 CPU 메모리를 소비하는 불필요하게 작은 샤드를 생성하지 않는지 확인하세요. 이 경우 샤드당 66 * 1.1/10개 샤드 = 7.26GiB가 필요해 추가 리소스를 소비하지만 거의 권장 크기 범위에 미치지 못합니다. 현재 12-GiB 샤드와 향후 48-GiB 샤드를 남길 수 있는 샤드 6개에 대한 더 많은 middle-of-the-road 접근 방식을 고려할 수 있습니다. 그런 다음 다시 샤드 3개로 시작하여 샤드가 50GiB를 초과하면 데이터를 다시 인덱싱하는 것이 좋습니다.

훨씬 덜 일반적인 문제는 노드당 샤드 수 제한과 관련이 있습니다. 샤드의 크기를 적절하게 지정하면 일반적으로 디스크 공간이 먼저 소진되어 이 제한이 발생하는 경우가 거의 없습니다. 예를 들어 m6g.large.search 인스턴스의 최대 디스크 크기는 512GiB입니다. 디스크 사용량을 80% 미만으로 유지하고 샤드의 크기를 20GiB로 지정하면 약 20개의 샤드를 수용할 수 있습니다. Elasticsearch 7.x 이상 및 의 모든 버전 OpenSearch에는 노드당 1,000개의 샤드 제한이 있습니다. 노드당 최대 샤드를 조정하려면 cluster.max_shards_per_node 설정을 구성하세요. 관련 예제는 클러스터 설정을 참조하세요.

샤드의 크기를 적절하게 지정하면 이 제한을 초과하는 경우가 거의 없지만, Java 힙의 각 GiB에 대한 샤드 수를 고려해 볼 수도 있습니다. 주어진 노드에서 Java 힙의 GiB당 샤드 수는 25개 이하입니다. 예를 들어 m5.large.search 인스턴스의 힙은 4GiB이므로 각 노드의 샤드 수는 100개 이하여야 합니다. 샤드 수가 이와 같을 때 각 샤드의 크기는 대략 5GiB로 권장 사항보다 훨씬 작습니다.