기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어 결정을 시작할 수 있습니다. 하드웨어 요구 사항은 워크로드에 따라 크게 달라지기는 하지만 몇 가지 기본적인 권장 사항을 제공하겠습니다.
일반적으로 각 인스턴스 유형에 대한 스토리지 한도는 가벼운 워크로드에 필요한 CPU와 메모리 양에 매핑됩니다. 예를 들어, m6g.large.search 인스턴스는 최대 512GiB의 EBS 볼륨 크기, 2개의 vCPU 코어 및 8GiB의 메모리를 사용합니다. 클러스터에 샤드가 많이 있거나, 집계를 과도하게 수행하거나, 문서를 자주 업데이트하거나, 쿼리를 많이 처리하는 경우 해당 리소스가 충분하지 않을 수 있습니다. 클러스터가 이러한 범주 중 하나에 해당하는 경우 각 100GiB의 스토리지 요구 사항에 맞게 2개의 vCPU 코어와 8GiB의 메모리에 근접한 구성으로 시작해 보세요.
작은 정보
각 인스턴스 유형에 할당되는 하드웨어 리소스 요약은 Amazon OpenSearch Service 요금
하지만 이러한 리소스도 부족할 수 있습니다. 일부 OpenSearch 사용자는 자신의 요구 사항을 충족시키기 위해 이와 같은 리소스가 여러 번 필요했다고 보고했습니다. 워크로드에 적합한 올바른 하드웨어를 찾으려면 초기 예상치를 치밀하게 작성하고, 주요 워크로드를 통해 테스트한 후 조정하고, 다시 테스트해야 합니다.
1단계: 초기 예상치 수립
시작하려면 분할된 뇌 상태(통신이 끊어져 관리자 노드가 두 개 있는 클러스터로 이어지는 경우)와 같은 잠재적 OpenSearch 문제를 방지하기 위해 최소 3개의 노드를 사용하는 것이 좋습니다. 전용 관리자 노드가 3개 있는 경우에도 복제를 위해 최소 2개의 데이터 노드를 사용하는 것이 좋습니다.
2단계: 노드별 스토리지 요구 사항 계산
스토리지 요구 사항이 184GiB이고 권장되는 최소 노드 수가 3개인 경우 184/3 = 61GiB 수식을 사용하여 각 노드에 필요한 스토리지 양을 찾으세요. 이 예제에서는 3개의 m6g.large.search 인스턴스를 선택했고 각 인스턴스는 90GiB의 EBS 스토리지 볼륨을 사용하므로 시간이 지나면서 늘어나는 요구 사항에 대한 안전망과 공간을 확보할 수 있습니다. 이 구성은 6개의 vCPU 코어와 24GiB의 메모리를 제공하므로 더 가벼운 워크로드에 적합합니다.
더욱 실질적인 예로 14TiB(14,336GiB)의 스토리지 요구 사항과 과도한 워크로드를 고려해 보겠습니다. 이 경우 2 * 144 = 288개의 vCPU 코어 및 8 * 144 = 1,152GiB의 메모리로 시작하도록 선택할 수 있습니다. 이러한 수치는 약 18개의 i3.4xlarge.search 인스턴스에 해당합니다. 이렇게 빠른 로컬 스토리지가 필요 없는 경우에는 각각 1TiB의 EBS 스토리지 볼륨을 사용하여 r6g.4xlarge.search 인스턴스 18개로 테스트할 수도 있습니다.
귀하의 클러스터가 수백 테라바이트의 데이터를 포함한다면 Amazon OpenSearch Service의 페타바이트 규모 섹션을 참조하세요.
3단계: 대표 테스트 수행
클러스터를 구성한 후에는 앞서 계산한 샤드 수를 사용하여 인덱스를 추가하고, 실제 데이터 세트를 사용하여 주요 클라이언트 테스트를 수행하고, CloudWatch 지표를 모니터링하여 클러스터가 워크로드를 처리하는 방식을 확인할 수 있습니다.
4단계: 성공 또는 반복
성능이 요구 사항을 충족하고 테스트에 성공했으며 CloudWatch 지표가 정상이면 클러스터 사용 준비를 마친 것입니다. 반드시 CloudWatch 경보를 설정하여 비정상적인 리소스가 사용되는지를 검사합니다.
성능이 기대 이하이고 테스트에 실패했거나 CPUUtilization 또는 JVMMemoryPressure가 높은 경우 다른 인스턴스 유형을 선택(또는 인스턴스 추가)하여 계속 테스트해야 할 수 있습니다. 인스턴스를 추가함에 따라 OpenSearch에서는 자동으로 클러스터 전체에 샤드 배포를 다시 조정합니다.
성능이 떨어진 클러스터에서 부족 용량을 측정하는 것보다 성능이 높은 클러스터에서 초과 용량을 측정하는 것이 더 쉬우므로 필요한 것보다 더 큰 클러스터로 시작하는 것이 좋습니다. 그런 다음, 추가 리소스가 있는 효율적인 클러스터를 테스트하고 축소하여 활동이 늘어난 기간에 안정적인 운영을 보장합니다.
프로덕션 클러스터 또는 복잡한 상태의 클러스터는 전용 관리자 노드의 이점을 활용하여 성능과 클러스터 신뢰성을 개선합니다.
