아마존 OpenSearch 서비스 도메인 크기 조정 - 아마존 OpenSearch 서비스
스토리지 요구 사항 계산샤드 수 선택인스턴스 유형 선택 및 테스트

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

아마존 OpenSearch 서비스 도메인 크기 조정

Amazon OpenSearch 서비스 도메인의 크기를 결정하는 완벽한 방법은 없습니다. 하지만 스토리지 요구 사항, 서비스 및 OpenSearch 자체에 대한 이해부터 시작하여 하드웨어 요구 사항에 대한 정보에 입각한 초기 추정을 할 수 있습니다. 이러한 예상치는 도메인 크기 조정의 가장 중요한 측면인 주요 워크로드로 도메인 크기 조정 테스트와 해당 성능 모니터링을 위한 유용한 시작점을 제공할 수 있습니다.

스토리지 요구 사항 계산

대부분의 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 서비스 오버헤드: OpenSearch 서비스는 각 인스턴스 스토리지 공간의 20% (최대 20GiB) 를 세그먼트 병합, 로그 및 기타 내부 작업을 위해 예약합니다.

    이 20GiB의 최댓값 때문에 예약된 총 공간은 도메인의 인스턴스 수에 따라 크게 달라질 수 있습니다. 예를 들어, 도메인에 3개의 m6g.xlarge.search 인스턴스가 포함될 수 있으며 각 스토리지 공간이 500GiB인 경우 총 공간은 1.46TiB입니다. 이 경우 예약된 총 공간은 60GiB에 불과합니다. 다른 도메인에 10개의 m3.medium.search 인스턴스가 포함될 수 있으며 각 스토리지 공간이 100GiB인 경우 총 공간은 0.98TiB입니다. 이 경우 첫 번째 도메인의 전체 스토리지 공간이 50% 더 크더라도, 두 번째 도메인의 예약된 총 공간은 200GiB입니다.

    다음 공식에서는 오버헤드에 대한 “최악의 경우” 추정치를 적용합니다. 이 추정치에는 노드 장애 및 가용 영역 중단의 영향을 최소화하는 데 도움이 되는 추가 여유 공간이 포함됩니다.

요약하면 지정된 기간에 66GiB의 데이터가 있고 한 개의 복제본이 필요한 경우 최소 스토리지 요구 사항은 66 * 2 * 1.1 / 0.95 / 0.8 = 191GiB에 근사합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.

소스 데이터* (1 이상의 복제본 수) * (1 + 인덱싱 오버헤드)/(1 - Linux 예약 공간)/(1 - OpenSearch 서비스 오버헤드) = 최소 스토리지 요구 사항

또는 아래와 같이 약식 버전을 사용할 수도 있습니다.

소스 데이터 * (1 + 복제본 수) * 1.45 = 최소 스토리지 요구 사항

스토리지 공간 부족은 클러스터 불안정성의 가장 일반적인 원인 중 하나입니다. 따라서 인스턴스 유형, 인스턴스 수, 스토리지 볼륨 선택 시 숫자를 교차 확인해야 합니다.

기타 스토리지 고려 사항은 다음과 같습니다.

샤드 수 선택

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

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

샤드가 크면 장애 복구가 어려울 수 있지만 각 샤드는 일정량의 CPU와 메모리를 사용하기 때문에 작은 샤드가 너무 많으면 성능 문제와 메모리 부족 오류가 발생할 수 있습니다. OpenSearch 즉, 샤드는 기본 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가 필요해 추가 리소스를 소비하지만 거의 권장 크기 범위에 미치지 못합니다. 현재는 12GiB 샤드를, 미래에는 48GiB 샤드를 사용할 수 있도록 6개의 샤드를 사용하는 것이 더 나은 middle-of-the-road 접근 방식을 고려해 볼 수 있습니다. 그런 다음 다시 샤드 3개로 시작하여 샤드가 50GiB를 초과하면 데이터를 다시 인덱싱하는 것이 좋습니다.

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

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

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

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

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

작은 정보

각 인스턴스 유형에 할당된 하드웨어 리소스의 요약은 Amazon OpenSearch Service 요금을 참조하십시오.

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

1단계: 초기 예상치 수립

먼저 스플릿 브레인 상태 (통신 장애로 인해 클러스터에 두 개의 마스터 노드가 있는 경우) 와 같은 잠재적 OpenSearch 문제를 방지하기 위해 최소 세 개의 노드를 사용하는 것이 좋습니다. 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개로 테스트할 수도 있습니다.

귀하의 클러스터가 수백 테라바이트의 데이터를 포함한다면 아마존 서비스의 페타바이트 스케일 OpenSearch 섹션을 참조하세요.

3단계: 대표 테스트 수행

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

4단계: 성공 또는 반복

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

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

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

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