기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon OpenSearch Service 도메인 크기 조정
Amazon OpenSearch Service 도메인의 크기를 조정하는 완벽한 방법은 존재하지 않습니다. 하지만 스토리지 요구 사항, 서비스 및 OpenSearch 자체에 대해 이해한 다음 시작하면 하드웨어 요구 사항에 빈틈없이 대응하는 초기 예상치를 수립할 수 있습니다. 이러한 예상치는 도메인 크기 조정의 가장 중요한 측면인 주요 워크로드로 도메인 크기 조정 테스트와 해당 성능 모니터링을 위한 유용한 시작점을 제공할 수 있습니다.
**Topics**
+ [스토리지 요구 사항 계산](bp-storage.md)
+ [샤드 수 선택](bp-sharding.md)
+ [인스턴스 유형 선택 및 테스트](bp-instances.md)
# 스토리지 요구 사항 계산
대부분의 OpenSearch 워크로드는 두 가지 범주 중 하나로 분류됩니다.
+ **장기 인덱스**: 데이터를 하나 이상의 OpenSearch 인덱스로 처리하는 코드를 작성한 다음 소스 데이터가 변경됨에 따라 해당 인덱스를 주기적으로 업데이트합니다. 몇 가지 일반적인 예로 웹 사이트, 문서 및 전자 상거래 검색이 있습니다.
+ **롤링 인덱스**: 데이터가 인덱싱 기간과 보존 기간에 임시 인덱스 세트로 계속 유입됩니다(예: 2주 동안 보관되는 일일 인덱스 세트). 몇 가지 일반적인 예로 로그 분석, 시계열 처리 및 클릭스트림 분석이 있습니다.
장기 인덱스 워크로드의 경우 디스크에 있는 소스 데이터를 검사하여 스토리지 공간이 어느 정도 소비되었는지 쉽게 확인할 수 있습니다. 데이터를 여러 소스에서 가져온 경우 소스를 모두 추가하면 됩니다.
롤링 인덱스의 경우 주요 기간에 생성된 데이터의 양에 보존 기간을 곱할 수 있습니다. 예를 들어, 시간당 200MiB의 로그 데이터를 생성하면 하루에 4.7GiB가 생성되고 보존 기간이 2주면 이 기간에 66GiB의 데이터가 생성됩니다.
그러나 소스 데이터의 크기는 스토리지 요구 사항의 한 측면일 뿐입니다. 다음 사항도 고려해야 합니다.
+ **복제본 수**: 각 복제본은 기본 샤드의 전체 사본이며 인덱스의 저장 크기는 기본 및 복제본 샤드에서 가져온 크기를 보여줍니다. 기본적으로 각 OpenSearch 인덱스에는 한 개의 복제본이 포함됩니다. 데이터 손실을 방지하기 위해 하나 이상을 포함하는 것이 좋습니다. 또한 복제본은 검색 성능을 향상시켜 주므로 읽기 워크로드가 과중한 경우 여러 개를 사용할 수 있습니다. `PUT /my-index/_settings`을 사용하여 인덱스에 대한 `number_of_replicas` 설정을 업데이트합니다.
+ **OpenSearch 인덱싱 오버헤드**: 인덱스의 디스크 크기는 다양합니다. 소스 데이터와 인덱스의 전체 크기는 대개 소스의 110%이고 인덱스는 소스 데이터의 최대 10%입니다. 데이터 인덱싱 후 `_cat/indices?v` API 및 `pri.store.size` 값을 사용하여 정확한 오버헤드를 계산할 수 있습니다. `_cat/allocation?v`에서도 유용한 요약을 제공합니다.
+ **운영 체제 예약 공간**: 기본적으로 Linux는 중요한 프로세스와 시스템 복구를 위해, 그리고 디스크 단편화 문제를 방지할 목적으로 `root` 사용자가 사용할 수 있도록 파일 시스템의 5%를 예약합니다.
+ **OpenSearch Service 오버헤드**: OpenSearch Service는 세그먼트 병합, 로그 및 기타 내부 작업을 위해 각 인스턴스마다 스토리지 공간의 20%(최대 20GiB)를 예약해 둡니다.
이 20GiB의 최댓값 때문에 예약된 총 공간은 도메인의 인스턴스 수에 따라 크게 달라질 수 있습니다. 예를 들어, 도메인에 3개의 `m6g.xlarge.search` 인스턴스가 포함될 수 있으며 각 스토리지 공간이 500GiB인 경우 총 공간은 1.46TiB입니다. 이 경우 예약된 총 공간은 60GiB에 불과합니다. 다른 도메인에 10개의 `m3.medium.search` 인스턴스가 포함될 수 있으며 각 스토리지 공간이 100GiB인 경우 총 공간은 0.98TiB입니다. 이 경우 첫 번째 도메인의 전체 스토리지 공간이 50% 더 크더라도, 두 번째 도메인의 예약된 총 공간은 200GiB입니다.
다음 공식에서는 오버헤드에 대한 “최악의 경우” 추정치를 적용합니다. 이 추정치에는 노드 장애 및 가용 영역 중단의 영향을 최소화하는 데 도움이 되는 추가 여유 공간이 포함됩니다.
요약하면 지정된 기간에 66GiB의 데이터가 있고 한 개의 복제본이 필요한 경우 *최소* 스토리지 요구 사항은 66 \$1 2 \$1 1.1 / 0.95 / 0.8 = 191GiB에 근사합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.
**소스 데이터 \$1 (1 \$1 복제본 수) \$1 (1 \$1 인덱싱 오버헤드)/(1 - Linux 예약 공간)/(1 - OpenSearch Service 오버헤드) = 최소 스토리지 요구 사항**
또는 아래와 같이 약식 버전을 사용할 수도 있습니다.
**소스 데이터 \$1 (1 \$1 복제본 수) \$1 1.45 = 최소 스토리지 요구 사항**
스토리지 공간 부족은 클러스터 불안정성의 가장 일반적인 원인 중 하나입니다. 따라서 [인스턴스 유형, 인스턴스 수, 스토리지 볼륨 선택](bp-instances.md) 시 숫자를 교차 확인해야 합니다.
기타 스토리지 고려 사항은 다음과 같습니다.
+ 최소 스토리지 요구 사항이 1PB를 초과하는 경우 [Amazon OpenSearch Service의 페타바이트 규모](petabyte-scale.md) 섹션을 참조하세요.
+ 롤링 인덱스가 있고 핫-웜 아키텍처를 사용하려면 [Amazon OpenSearch Service를 위한 UltraWarm 스토리지](ultrawarm.md) 섹션을 참조하세요.
# 샤드 수 선택
스토리지 요구 사항을 이해했으면 인덱싱 전략을 조사할 수 있습니다. 기본적으로 OpenSearch Service에서 각 인덱스는 5개의 기본 샤드와 하나의 복제본(총 10개의 샤드)으로 나뉩니다. 이 동작은 기본 샤드와 하나의 복제본 샤드를 기본값으로 사용하는 오픈소스 OpenSearch와 다릅니다. 기존 인덱스에 대한 기본 샤드 수는 쉽게 변경할 수 없으므로, 첫 번째 문서를 인덱싱하기 *전에* 샤드 수를 결정해야 합니다.
여러 샤드를 선택하는 전반적인 목표는 클러스터의 모든 데이터 노드에서 인덱스를 균등하게 분산시키는 것입니다. 하지만 이러한 샤드는 너무 크거나 너무 많아서는 안 됩니다. 일반적인 지침은 검색 지연 시간이 핵심 성능 목표인 워크로드의 경우 샤드 크기를 10\$130GiB로 유지하고, 로그 분석과 같은 쓰기 작업이 많은 워크로드의 경우 30\$150GiB를 유지하는 것입니다.
크기가 큰 샤드는 OpenSearch에서 오류 발생 시 복구가 어렵기는 합니다. 하지만 각 샤드는 일정량의 CPU와 메모리를 사용하기 때문에 크기가 작은 샤드가 너무 많이 있으면 성능 문제와 메모리 부족 오류가 발생할 수 있습니다. 즉, 샤드는 기본 OpenSearch Service 인스턴스가 처리할 수 있을 정도로 작아야 하지만 너무 작아 하드웨어에 불필요한 부담을 주어서도 안 됩니다.
예를 들어, 66GiB의 데이터가 있다고 가정해 봅니다. 시간이 지남에 따라 그 수가 늘어날 것으로 예상하지 않으며 샤드를 각각 30GiB 정도로 유지하려고 합니다. 따라서 샤드 수는 약 66 \$1 1.1/30 = 3개가 되어야 합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.
**(소스 데이터 \$1 늘어날 공간) \$1 (1 \$1 인덱싱 오버헤드)/원하는 샤드 크기 = 대략적인 기본 샤드 수**
이 수식은 시간이 지남에 따라 데이터 성장 보정에 유용합니다. 동일한 66GiB의 데이터가 내년에 4배가 될 것으로 예상한다면 대략적인 샤드 수는 (66 \$1 198) \$1 1.1/30 = 10개가 됩니다. 하지만 *아직* 추가로 198GiB의 데이터가 필요하지는 않습니다. 향후 이 준비 작업을 통해 현재 엄청난 양의 CPU와 메모리를 소비하는 너무 작은 크기의 샤드를 생성하지 않는지 확인하세요. 이 경우 샤드당 66 \$1 1.1/10개 샤드 = 7.26GiB가 필요해 추가 리소스를 소비하지만 거의 권장 크기 범위에 미치지 못합니다. 샤드가 6개인 중간 정도의 접근 방식을 고려할 수 있으며, 이 경우 현재 12GiB 샤드, 향후 48GiB 샤드가 남게 됩니다. 그런 다음 다시 샤드 3개로 시작하여 샤드가 50GiB를 초과하면 데이터를 다시 인덱싱하는 것이 좋습니다.
훨씬 덜 일반적인 문제는 노드당 샤드 수 제한과 관련이 있습니다. 샤드의 크기를 적절하게 지정하면 일반적으로 디스크 공간이 먼저 소진되어 이 제한이 발생하는 경우가 거의 없습니다. 예를 들어 `m6g.large.search` 인스턴스의 최대 디스크 크기는 512GiB입니다. 디스크 사용량을 80% 미만으로 유지하고 샤드의 크기를 20GiB로 지정하면 약 20개의 샤드를 수용할 수 있습니다. Elasticsearch 7.*x* 이상과 최고 2.15까지 모든 OpenSearch 버전에서 노드당 샤드가 *1,000*개로 제한됩니다. 노드당 최대 샤드를 조정하려면 `cluster.max_shards_per_node` 설정을 구성하세요. OpenSearch 2.17 이상의 경우 OpenSearch Service는 노드당 최대 4,000개의 샤드까지, 16GB의 JVM 힙 메모리마다 1,000개의 샤드를 지원합니다. 관련 예제는 [클러스터 설정](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body)을 참조하세요. 샤드 수에 대한 자세한 내용은 [샤드 수 할당량](limits.md#shard-count)(을)를 참조하세요.
샤드의 크기를 적절하게 지정하면 이 제한을 초과하는 경우가 거의 없지만, Java 힙의 각 GiB에 대한 샤드 수를 고려해 볼 수도 있습니다. 주어진 노드에서 Java 힙의 GiB당 샤드 수는 25개 이하입니다. 예를 들어 `m5.large.search` 인스턴스의 힙은 4GiB이므로 각 노드의 샤드 수는 100개 이하여야 합니다. 샤드 수가 이와 같을 때 각 샤드의 크기는 대략 5GiB로 권장 사항보다 훨씬 작습니다.
# 인스턴스 유형 선택 및 테스트
스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어 결정을 시작할 수 있습니다. 하드웨어 요구 사항은 워크로드에 따라 크게 달라지기는 하지만 몇 가지 기본적인 권장 사항을 제공하겠습니다.
일반적으로 각 인스턴스 유형에 대한 [스토리지 한도](limits.md)는 가벼운 워크로드에 필요한 CPU와 메모리 양에 매핑됩니다. 예를 들어, `m6g.large.search` 인스턴스는 최대 512GiB의 EBS 볼륨 크기, 2개의 vCPU 코어 및 8GiB의 메모리를 사용합니다. 클러스터에 샤드가 많이 있거나, 집계를 과도하게 수행하거나, 문서를 자주 업데이트하거나, 쿼리를 많이 처리하는 경우 해당 리소스가 충분하지 않을 수 있습니다. 클러스터가 이러한 범주 중 하나에 해당하는 경우 각 100GiB의 스토리지 요구 사항에 맞게 2개의 vCPU 코어와 8GiB의 메모리에 근접한 구성으로 시작해 보세요.
**작은 정보**
각 인스턴스 유형에 할당되는 하드웨어 리소스 요약은 [Amazon OpenSearch Service 요금](https://aws.amazon.com/opensearch-service/pricing/)을 참조하세요.
하지만 이러한 리소스도 부족할 수 있습니다. 일부 OpenSearch 사용자는 자신의 요구 사항을 충족시키기 위해 이와 같은 리소스가 여러 번 필요했다고 보고했습니다. 워크로드에 적합한 올바른 하드웨어를 찾으려면 초기 예상치를 치밀하게 작성하고, 주요 워크로드를 통해 테스트한 후 조정하고, 다시 테스트해야 합니다.
## 1단계: 초기 예상치 수립
시작할 때 *브레인 분할* 상태 등 잠재적인 OpenSearch 문제를 피하기 위해 최소 3개의 노드를 선택하는 것이 좋습니다(통신 경과로 클러스터에 두 개의 프라이머리 노드가 있는 경우). 3개의 [전용 프라이머리 노드](managedomains-dedicatedmasternodes.md)가 있는 경우 복제를 위해 최소 2개의 데이터 노드를 사용하는 것이 좋습니다.
## 2단계: 노드별 스토리지 요구 사항 계산
스토리지 요구 사항이 184GiB이고 권장되는 최소 노드 수가 3개인 경우 184/3 = 61GiB 수식을 사용하여 각 노드에 필요한 스토리지 양을 찾으세요. 이 예제에서는 3개의 `m6g.large.search` 인스턴스를 선택했고 각 인스턴스는 90GiB의 EBS 스토리지 볼륨을 사용하므로 시간이 지나면서 늘어나는 요구 사항에 대한 안전망과 공간을 확보할 수 있습니다. 이 구성은 6개의 vCPU 코어와 24GiB의 메모리를 제공하므로 더 가벼운 워크로드에 적합합니다.
더욱 실질적인 예로 14TiB(14,336GiB)의 스토리지 요구 사항과 과도한 워크로드를 고려해 보겠습니다. 이 경우 2 \$1 144 = 288개의 vCPU 코어 및 8 \$1 144 = 1,152GiB의 메모리로 시작하도록 선택할 수 있습니다. 이러한 수치는 약 18개의 `i3.4xlarge.search` 인스턴스에 해당합니다. 이렇게 빠른 로컬 스토리지가 필요 없는 경우에는 각각 1TiB의 EBS 스토리지 볼륨을 사용하여 `r6g.4xlarge.search` 인스턴스 18개로 테스트할 수도 있습니다.
귀하의 클러스터가 수백 테라바이트의 데이터를 포함한다면 [Amazon OpenSearch Service의 페타바이트 규모](petabyte-scale.md) 섹션을 참조하세요.
## 3단계: 대표 테스트 수행
클러스터를 구성한 후에는 앞서 계산한 샤드 수를 사용하여 [인덱스를 추가](indexing.md)하고, 실제 데이터 세트를 사용하여 주요 클라이언트 테스트를 수행하고, [CloudWatch 지표를 모니터링](managedomains-cloudwatchmetrics.md)하여 클러스터가 워크로드를 처리하는 방식을 확인할 수 있습니다.
## 4단계: 성공 또는 반복
성능이 요구 사항을 충족하고 테스트에 성공했으며 CloudWatch 지표가 정상이면 클러스터 사용 준비를 마친 것입니다. 반드시 [CloudWatch 경보를 설정](cloudwatch-alarms.md)하여 비정상적인 리소스가 사용되는지를 검사합니다.
성능이 기대 이하이고 테스트에 실패했거나 `CPUUtilization` 또는 `JVMMemoryPressure`가 높은 경우 다른 인스턴스 유형을 선택(또는 인스턴스 추가)하여 계속 테스트해야 할 수 있습니다. 인스턴스를 추가함에 따라 OpenSearch에서는 자동으로 클러스터 전체에 샤드 배포를 다시 조정합니다.
성능이 떨어진 클러스터에서 부족 용량을 측정하는 것보다 성능이 높은 클러스터에서 초과 용량을 측정하는 것이 더 쉬우므로 필요한 것보다 더 큰 클러스터로 시작하는 것이 좋습니다. 그런 다음, 추가 리소스가 있는 효율적인 클러스터를 테스트하고 축소하여 활동이 늘어난 기간에 안정적인 운영을 보장합니다.
프로덕션 클러스터나 상태가 복잡한 클러스터는 [전용 프라이머리 노드](managedomains-dedicatedmasternodes.md)의 이점을 활용하여 성능과 클러스터의 안정성을 향상시킵니다.