기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

인스턴스 유형 선택 및 테스트

스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어 결정을 시작할 수 있습니다. 하드웨어 요구 사항은 워크로드에 따라 크게 달라지기는 하지만 몇 가지 기본적인 권장 사항을 제공하겠습니다.

일반적으로 각 인스턴스 유형의 스토리지 한도는 가벼운 워크로드에 필요할 수 있는 CPU 및 메모리의 양에 매핑됩니다. 예를 들어 인스턴스의 m6g.large.search 최대 EBS 볼륨 크기는 512GiB , 2vCPU 코어 및 8GiB 메모리입니다. 클러스터에 샤드가 많이 있거나, 집계를 과도하게 수행하거나, 문서를 자주 업데이트하거나, 쿼리를 많이 처리하는 경우 해당 리소스가 충분하지 않을 수 있습니다. 클러스터가 이러한 범주 중 하나에 속하는 경우 스토리지 요구 사항의 100GiB마다 2vCPU 코어 및 8GiB에 가까운 구성으로 시작해 보세요.

하지만 이러한 리소스도 부족할 수 있습니다. 일부 OpenSearch 사용자는 요구 사항을 충족하는 데 이러한 리소스가 여러 번 필요하다고 보고합니다. 워크로드에 적합한 올바른 하드웨어를 찾으려면 초기 예상치를 치밀하게 작성하고, 주요 워크로드를 통해 테스트한 후 조정하고, 다시 테스트해야 합니다.

1단계: 초기 예상치 수립

시작하려면 분할된 뇌 상태(통신이 중단되어 마스터 노드가 두 개 있는 클러스터로 이어지는 경우)와 같은 잠재적 OpenSearch 문제를 방지하기 위해 최소 세 개의 노드를 사용하는 것이 좋습니다. 3개의 전용 프라이머리 노드가 있는 경우 복제를 위해 최소 2개의 데이터 노드를 사용하는 것이 좋습니다.

2단계: 노드별 스토리지 요구 사항 계산

스토리지 요구 사항이 184GiB이고 권장되는 최소 노드 수가 3개인 경우 184/3 = 61GiB 수식을 사용하여 각 노드에 필요한 스토리지 양을 찾으세요. 이 예제에서는 세 개의 m6g.large.search 인스턴스를 선택할 수 있습니다. 각 인스턴스는 90-GiB EBS 스토리지 볼륨을 사용하므로 시간이 지남에 따라 안전망과 약간의 성장 여유 공간이 있습니다. 이 구성은 6개의 vCPU 코어와 24GiB의 메모리를 제공하므로 더 가벼운 워크로드에 적합합니다.

더욱 실질적인 예로 14TiB(14,336GiB)의 스토리지 요구 사항과 과도한 워크로드를 고려해 보겠습니다. 이 경우 2 * 144 = 288vCPU 코어 및 8 * 144 = 1152GiB 메모리로 테스트를 시작하도록 선택할 수 있습니다. 이러한 수치는 약 18개의 i3.4xlarge.search 인스턴스에 해당합니다. 빠른 로컬 스토리지가 필요하지 않은 경우 각각 11-TiB EBS 스토리지 볼륨을 사용하여 18개의 r6g.4xlarge.search 인스턴스를 테스트할 수도 있습니다.

귀하의 클러스터가 수백 테라바이트의 데이터를 포함한다면 Amazon OpenSearch Service의 페타바이트 규모 섹션을 참조하세요.

3단계: 대표 테스트 수행

클러스터를 구성한 후 이전에 계산한 샤드 수를 사용하여 인덱스를 추가하고, 실제 데이터 세트를 사용하여 몇 가지 대표적인 클라이언트 테스트를 수행하고, CloudWatch 지표를 모니터링하여 클러스터가 워크로드를 처리하는 방법을 확인할 수 있습니다.

4단계: 성공 또는 반복

성능이 요구 사항을 충족하고 테스트가 성공하며 CloudWatch 지표가 정상인 경우 클러스터를 사용할 준비가 된 것입니다. 비정상 리소스 사용량을 감지하도록 CloudWatch 경보를 설정해야 합니다.

성능이 기대 이하이고 테스트에 실패했거나 CPUUtilization 또는 JVMMemoryPressure가 높은 경우 다른 인스턴스 유형을 선택(또는 인스턴스 추가)하여 계속 테스트해야 할 수 있습니다. 인스턴스를 추가하면 는 클러스터 전체에서 샤드의 분포를 OpenSearch 자동으로 재조정합니다.

성능이 떨어진 클러스터에서 부족 용량을 측정하는 것보다 성능이 높은 클러스터에서 초과 용량을 측정하는 것이 더 쉬우므로 필요한 것보다 더 큰 클러스터로 시작하는 것이 좋습니다. 그런 다음, 추가 리소스가 있는 효율적인 클러스터를 테스트하고 축소하여 활동이 늘어난 기간에 안정적인 운영을 보장합니다.

프로덕션 클러스터나 상태가 복잡한 클러스터는 전용 프라이머리 노드의 이점을 활용하여 성능과 클러스터의 안정성을 향상시킵니다.