기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 인스턴스 유형 선택 및 테스트
스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어 결정을 시작할 수 있습니다. 하드웨어 요구 사항은 워크로드에 따라 크게 달라지기는 하지만 몇 가지 기본적인 권장 사항을 제공하겠습니다.
일반적으로 각 인스턴스 유형에 대한 [스토리지 한도](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)의 이점을 활용하여 성능과 클러스터의 안정성을 향상시킵니다.