아마존 OpenSearch 서비스 운영 모범 사례

이 장에서는 Amazon OpenSearch Service 도메인 운영에 대한 모범 사례를 제공하고 많은 사용 사례에 적용되는 일반 지침을 제공합니다. 각 워크로드는 고유한 특성을 가지고 있으므로 모든 사용 사례에 적합한 일반적인 권장 사항은 없습니다. 가장 중요한 모범 사례는 지속적인 주기로 도메인을 배포, 테스트 및 조정하여 워크로드에 대한 최적의 구성, 안정성 및 비용을 찾는 것입니다.

주제

모니터링 및 알림

다음 모범 사례는 OpenSearch 서비스 도메인 모니터링에 적용됩니다.

CloudWatch 경보를 구성합니다.

OpenSearch 서비스는 CloudWatch Amazon에 성능 지표를 내보냅니다. 클러스터 및 인스턴스 지표를 정기적으로 검토하고 워크로드 성능에 따라 권장 CloudWatch 경보를 구성하십시오.

로그 게시 사용 설정

OpenSearch 서비스는 Amazon CloudWatch Logs의 OpenSearch 오류 로그, 검색 느린 로그, 색인 생성 느린 로그 및 감사 로그를 노출합니다. 검색 느린 로그, 인덱싱 느린 로그 및 오류 로그는 성능 및 안정성 문제 해결에 유용합니다. 감사 로그는 세분화된 액세스 제어를 사용 설정한 경우에만 사용할 수 있으며, 사용자 활동을 추적합니다. 자세한 내용은 설명서의 로그를 참조하십시오. OpenSearch

검색 느린 로그 및 인덱싱 느린 로그는 검색 및 인덱싱 작업의 성능을 이해하고 문제를 해결하는 데 중요한 도구입니다. 모든 프로덕션 도메인에 대해 검색 및 인덱스 느린 로그 전달을 사용 설정합니다. 또한 로깅 임계값을 구성해야 합니다. 그렇지 않으면 로그가 CloudWatch 캡처되지 않습니다.

샤드 전략

샤드는 서비스 도메인의 데이터 노드에 워크로드를 분산합니다 OpenSearch . 인덱스를 올바르게 구성하면 전반적인 도메인 성능을 향상시킬 수 있습니다.

OpenSearch 서비스에 데이터를 보내면 해당 데이터를 인덱스로 전송합니다. 인덱스는 문서가 행으로, 필드가 열로 되어 있는 데이터베이스 테이블과 유사합니다. 인덱스를 생성할 때 만들려는 기본 샤드의 OpenSearch 수를 지정합니다. 프라이머리 샤드는 전체 데이터세트의 독립적인 파티션입니다. OpenSearch 서비스는 인덱스의 기본 샤드에 데이터를 자동으로 배포합니다. 또한, 인덱스의 복제본을 구성할 수도 있습니다. 각 복제본 샤드 구성은 해당 인덱스에 대한 기본 샤드의 전체 복사본 집합으로 구성됩니다.

OpenSearch 서비스는 클러스터의 데이터 노드에 각 인덱스의 샤드를 매핑합니다. 인덱스의 기본 및 복제본 샤드가 서로 다른 데이터 노드에 상주하도록 보장합니다. 첫 번째 복제본은 인덱스에 두 개의 데이터 복사본이 있는지 확인합니다. 항상 하나 이상의 복제본을 사용해야 합니다. 추가 복제본은 추가 중복성과 읽기 용량을 제공합니다.

OpenSearch 인덱스에 속하는 샤드를 포함하는 모든 데이터 노드에 인덱싱 요청을 보냅니다. 먼저 기본 샤드를 포함하는 데이터 노드로 인덱싱 요청을 보낸 다음 복제본 샤드를 포함하는 데이터 노드로 인덱싱 요청을 보냅니다. 코디네이터 노드는 검색 요청을 인덱스에 속한 모든 샤드의 기본 샤드 또는 복제본 샤드로 라우팅합니다.

예를 들어 5개의 기본 샤드와 1개의 복제본이 있는 인덱스의 경우 각 인덱싱 요청은 10개의 샤드를 접합니다. 반면에 검색 요청은 n개의 샤드로 전송됩니다. 여기서 n은 기본 샤드의 수입니다. 5개의 기본 샤드와 1개의 복제본이 있는 인덱스의 경우, 각 검색 쿼리는 해당 인덱스의 샤드 5개(기본 또는 복제본)를 접합니다.

샤드 및 데이터 노드 수 결정

다음 모범 사례를 사용하여 도메인의 샤드 및 데이터 노드 수를 결정합니다.

샤드 크기 - 디스크의 데이터 크기는 소스 데이터 크기의 직접적인 결과이며 더 많은 데이터를 인덱싱할 때 변경됩니다. source-to-index 비율은 1:10 에서 10:1 이상으로 매우 다양할 수 있지만 일반적으로 1:1.10 정도입니다. 이 비율을 사용하여 디스크의 인덱스 크기를 예측할 수 있습니다. 또한 일부 데이터를 인덱싱하고 실제 인덱스 크기를 검색하여 워크로드에 대한 비율을 결정할 수 있습니다. 인덱스 크기를 예측했으면 각 샤드가 10~30GiB(검색 워크로드의 경우) 또는 30~50GiB(로그 워크로드의 경우)가 되도록 샤드 수를 설정합니다. 50GiB가 최대값이어야 하며, 성장에 대비한 계획을 세워야 합니다.

샤드 수 - 데이터 노드에 샤드를 배포하면 도메인 성능에 큰 영향을 미칩니다. 여러 샤드가 있는 인덱스가 있는 경우, 샤드 수를 데이터 노드 수의 짝수 배수로 설정합니다. 이렇게 하면 샤드가 데이터 노드 간에 고르게 분산되며, 핫 노드를 방지할 수 있습니다. 예를 들어, 12개의 기본 샤드가 있는 경우 데이터 노드 수는 2, 3, 4, 6 또는 12여야 합니다. 단, 샤드 수는 샤드 크기에 부차적입니다. 5GiB의 데이터가 있는 경우에도 단일 샤드를 사용해야 합니다.

데이터 노드당 샤드 - 노드가 보유할 수 있는 총 샤드 수는 노드의 Java 가상 머선(JVM) 힙 메모리에 비례합니다. 힙 메모리 GiB당 25개 이하의 샤드를 목표로 합니다. 예를 들어, 32GiB의 힙 메모리가 있는 노드는 800개 이하의 샤드를 보유해야 합니다. 샤드 배포는 워크로드 패턴에 따라 달라질 수 있지만, 노드당 샤드 수는 1,000개로 제한됩니다. cat/allocation API는 데이터 노드의 샤드 수와 전체 샤드 스토리지에 대한 빠른 보기를 제공합니다.

샤드 대 CPU 비율 - 샤드가 인덱싱 또는 검색 요청에 관련된 경우 vCPU 사용하여 요청을 처리합니다. 샤드당 1.5 vCPU의 초기 확장 지점을 사용하는 것이 가장 좋습니다. 인스턴스 유형에 vCPU가 8개인 경우, 각 노드에 샤드가 6개 이하가 되도록 데이터 노드 수를 설정합니다. 이 값은 근사치입니다. 워크로드를 테스트하고 그에 따라 클러스터를 확장해야 합니다.

스토리지 볼륨, 샤드 크기, 인스턴스 유형 권장 사항은 다음 리소스를 참조하세요.

스토리지 스큐 방지

스토리지 스큐는 클러스터 내의 하나 이상의 노드가 다른 노드보다 하나 이상의 인덱스에 대해 더 높은 비율의 스토리지를 보유할 때 발생합니다. 스토리지 스큐의 표시에는 불균등한 CPU 사용률, 간헐적이고 불균일한 대기 시간, 데이터 노드 전반의 불균등한 대기열이 포함됩니다. 스큐 문제가 있는지 확인하려면 다음 해결 방법 섹션을 참조하세요.

안정성

다음 모범 사례는 안정적이고 건강한 서비스 도메인을 유지 관리하는 데 적용됩니다. OpenSearch

스냅샷 성능 개선

스냅샷이 처리 중에 중단되는 것을 방지하려면 전용 프라이머리 노드의 인스턴스 유형이 샤드 수와 일치해야 합니다. 자세한 정보는 전용 프라이머리 노드에 대한 인스턴스 유형 선택을 참조하세요. 또한 각 노드에는 Java 힙 메모리의 GiB당 25개 이상의 권장 샤드가 있어서는 안 됩니다. 자세한 정보는 샤드 수 선택을 참조하세요.

전용 프라이머리 노드 사용 설정

전용 프라이머리 노드는 클러스터 안정성을 향상시킵니다. 전용 프라이머리 노드는 클러스터 관리 작업을 수행하지만 인덱스 데이터를 보유하거나 클라이언트 요청에 응답하지 않습니다. 클러스터 관리 작업을 오프로드하면 도메인의 안정성이 향상되고 일부 구성 변경이 다운타임 없이 일어날 수 있습니다.

3개의 전용 프라이머리 노드를 사용 설정하고 사용하여 3개의 가용 영역에서 도메인 안정성을 최적화합니다. Multi-AZ with Standby로 배포하면 전용 프라이머리 노드 3개가 구성됩니다. 인스턴스 유형 권장 사항은 전용 프라이머리 노드에 대한 인스턴스 유형 선택 섹션을 참조하세요.

여러 가용 영역에 걸쳐 배포

서비스 중단 발생 시 데이터 손실을 방지하고 클러스터 가동 중지 시간을 최소화하기 위해 동일한 AWS 리전에 있는 두 개 또는 세 개의 가용 영역에 노드를 분산할 수 있습니다. 모범 사례는 Multi-AZ with Standby를 사용하여 배포하는 것으로, 이 배포는 3개의 가용 영역(활성 영역 2개와 대기 영역 1개, 인덱스당 복제 샤드 2개 포함)을 구성합니다. 이 구성을 통해 OpenSearch Service는 복제본 샤드를 해당하는 기본 샤드가 아닌 다른 AZ에 배포할 수 있습니다. 가용 영역 간 클러스터 통신에 대해서는 교차 AZ 데이터 전송 요금이 부과되지 않습니다.

가용 영역은 각 리전 내에 있는 격리된 위치입니다. 2개의 AZ 구성에서 하나의 가용 영역이 손실되면 전체 도메인 용량의 절반이 손실됩니다. 세 개의 가용 영역으로 이동하면 단일 가용 영역이 손실될 경우의 영향이 더욱 줄어듭니다.

수집 흐름 및 버퍼링 제어

_bulk API 작업을 사용하여 전체 요청 수를 제한하는 것이 좋습니다. 단일 문서가 포함된 5,000개의 요청을 보내는 것보다 5,000개의 문서가 포함된 하나의 _bulk 요청을 보내는 것이 더 효율적입니다.

최적의 운영 안정성을 위해 인덱싱 요청의 업스트림 흐름을 제한하거나 일시 중지해야 하는 경우가 있습니다. 인덱스 요청 비율을 제한하는 것은 클러스터를 압도할 수 있는 예기치 않은 또는 간헐적인 요청 급증을 처리하기 위한 중요한 메커니즘입니다. 업스트림 아키텍처에 흐름 제어 메커니즘을 구축하는 것이 좋습니다.

다음 다이어그램은 로그 수집 아키텍처의 여러 구성 요소 옵션을 보여줍니다. 갑작스러운 트래픽 급증 및 간단한 도메인 유지 관리를 위해 들어오는 데이터를 버퍼링할 수 있는 충분한 공간을 확보하도록 집계 계층을 구성합니다.

검색 워크로드에 대한 매핑 생성

검색 워크로드의 경우 문서와 해당 필드를 OpenSearch 저장하고 인덱싱하는 방법을 정의하는 매핑을 생성하세요. 실수로 새 필드를 추가하지 않도록 dynamic을(를) strict(으)로 설정합니다.


PUT my-index
{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "title": { "type" : "text" },
      "author": { "type" : "integer" },
      "year": { "type" : "text" }
    }
  }
}

인덱스 템플릿 사용

인덱스 템플릿을 사용하여 인덱스를 생성할 때 인덱스를 구성하는 OpenSearch 방법을 지정할 수 있습니다. 인덱스를 만들기 전에 인덱스 템플릿을 구성합니다. 그런 다음 인덱스를 만들면 템플릿에서 설정 및 매핑을 상속합니다. 단일 인덱스에 둘 이상의 템플릿을 적용할 수 있으므로 한 템플릿에서 설정을 지정하고 다른 템플릿에서 매핑을 지정할 수 있습니다. 이 전략을 사용하면 여러 인덱스의 공통 설정을 위한 하나의 템플릿과 보다 구체적인 설정 및 매핑을 위한 별도의 템플릿을 사용할 수 있습니다.

다음 설정은 템플릿에서 구성할 때 유용합니다.

기본 및 복제본 샤드 수
새로 고침 간격(검색할 수 있도록 인덱스를 새로 고치고 최근 변경 사항을 적용하는 빈도)
동적 매핑 제어
명시적 필드 매핑

다음 예제 템플릿에는 이러한 각 설정이 포함되어 있습니다.


{
   "index_patterns":[
      "index-*"
   ],
   "order": 0,
   "settings": {
      "index": {
         "number_of_shards": 3,
         "number_of_replicas": 1,
         "refresh_interval": "60s"
      }
   },
   "mappings": {
      "dynamic": false,
      "properties": {
         "field_name1": {
            "type": "keyword"
         }
      }
   }
}

거의 변경되지 않더라도 설정과 매핑을 중앙에서 정의하면 여러 업스트림 클라이언트를 업데이트하는 것보다 관리가 더 OpenSearch 간단합니다.

인덱스 상태 관리를 사용한 인덱스 관리

로그 또는 시계열 데이터를 관리하는 경우 인덱스 상태 관리(ISM)를 사용하는 것이 좋습니다. ISM을 사용하면 일반 인덱스 수명 주기 관리 작업을 자동화할 수 있습니다 ISM을 사용하면 인덱스 별칭 롤오버를 호출하고, 인덱스 스냅샷을 생성하며, 스토리지 계층 간에 인덱스를 이동하고, 이전 인덱스를 삭제하는 정책을 생성할 수 있습니다. 샤드 스큐를 방지하기 위한 대체 데이터 수명 주기 관리 전략으로 ISM 롤오버 작업을 사용할 수도 있습니다.

먼저 ISM 정책을 설정합니다. 예제는 샘플 정책을 참조하세요. 그런 다음 정책을 하나 이상의 인덱스에 연결합니다. 정책에 ISM 템플릿 필드를 포함하는 경우 OpenSearch 서비스는 지정된 패턴과 일치하는 모든 인덱스에 정책을 자동으로 적용합니다.

사용되지 않는 인덱스 삭제

클러스터의 인덱스를 정기적으로 검토하고 사용하지 않는 인덱스를 식별합니다. 이러한 인덱스의 스냅샷을 만들어 S3에 저장한 다음 삭제합니다. 사용되지 않는 인덱스를 제거하면 샤드 수가 줄어들고 노드 간에 보다 균형 잡힌 스토리지 배포 및 리소스 활용이 가능합니다. 유휴 상태에서도 인덱스는 내부 인덱스 유지 관리 작업 중에 일부 리소스를 소비합니다.

사용하지 않는 인덱스를 수동으로 삭제하는 대신 ISM을 사용하여 자동으로 스냅샷을 만들고 일정 시간 후 인덱스를 삭제할 수 있습니다.

고가용성을 위한 여러 도메인을 사용

여러 리전에서 99.9% 가동 시간 이상의 고가용성을 달성하려면 두 개의 도메인을 사용하는 것이 좋습니다. 작거나 느리게 변화하는 데이터 세트의 경우 클러스터 간 복제를 설정하여 액티브-패시브 모델을 유지할 수 있습니다. 이 모델에서는 리더 도메인만 기록되지만, 어느 도메인에서든 읽을 수 있습니다. 더 큰 데이터 세트와 빠르게 변경되는 데이터의 경우, 모든 데이터가 액티브-액티브 모델의 두 도메인에 독립적으로 기록되도록 수집 파이프라인에서 이중 전달을 구성합니다.

장애 조치를 염두에 두고 업스트림 및 다운스트림 애플리케이션을 설계합니다. 장애 조치 프로세스를 다른 재해 복구 프로세스와 함께 테스트해야 합니다.

성능

최적의 성능을 위해 도메인을 조정하는 데 다음 모범 사례가 적용됩니다.

대량 요청 크기 및 압축 최적화

대량 크기 조정은 데이터, 분석 및 클러스터 구성에 따라 다르지만, 좋은 시작점은 대량 요청당 3~5MiB입니다.

gzip 압축을 사용하여 요청 및 응답의 페이로드 크기를 줄이면 OpenSearch 도메인으로부터 요청을 보내고 응답을 받을 수 있습니다. OpenSearch Python 클라이언트에서 gzip 압축을 사용하거나 클라이언트 측에서 다음 헤더를 포함하여 gzip 압축을 사용할 수 있습니다.

'Accept-Encoding': 'gzip'
'Content-Encoding': 'gzip'

대량 요청 크기를 최적화하려면 3MiB의 대량 요청 크기로 시작합니다. 그런 다음 인덱싱 성능이 개선되지 않을 때까지 요청 크기를 서서히 늘립니다.

참고

Elasticsearch 6.x 버전을 실행하는 도메인에서 gzip 압축을 사용 설정하려면 클러스터 수준에서 http_compression.enabled를 설정해야 합니다. 이 설정은 Elasticsearch 버전 7.x 및 모든 버전의 Elasticsearch에서 기본적으로 적용됩니다. OpenSearch

대량 요청 응답의 크기를 줄입니다.

OpenSearch 응답 크기를 줄이려면 파라미터에서 불필요한 필드를 제외하세요. filter_path 실패한 요청을 식별하거나 재시도하는 데 필요한 필드를 필터링하지 않도록 합니다. 자세한 정보와 지침은 응답 크기 감소 섹션을 참조하세요.

새로 고침 주기 조정

OpenSearch 인덱스는 최종 읽기 일관성을 갖습니다. 새로 고침 작업을 수행하면 인덱스에 대해 수행된 모든 업데이트를 검색할 수 있습니다. 기본 새로 고침 간격은 1초입니다. 즉, 인덱스를 쓰는 동안 1초마다 새로 고침을 OpenSearch 수행합니다.

인덱스를 새로 고치는 빈도가 낮을수록(새로 고침 간격이 길수록) 전반적인 인덱싱 성능이 향상됩니다. 새로 고침 간격을 늘리면 인덱스 업데이트와 새 데이터를 검색할 수 있는 시간 사이의 지연 시간이 길어진다는 단점이 있습니다. 전체 성능을 향상시키려면 새로 고침 간격을 허용할 수 있는 한 높게 설정합니다.

모든 인덱스에 대한 refresh_interval 파라미터를 30초 이상으로 설정하는 것이 좋습니다.

자동 조정 사용 설정

자동 조정은 OpenSearch 클러스터의 성능 및 사용량 지표를 사용하여 노드의 대기열 크기, 캐시 크기 및 JVM (Java Virtual Machine) 설정에 대한 변경을 제안합니다. 이러한 선택적 변경 사항은 클러스터 속도와 안정성을 향상시킵니다. 언제든지 기본 OpenSearch 서비스 설정으로 되돌릴 수 있습니다. 자동 조정은 명시적으로 사용 중지하지 않는 한 새 도메인에서 기본적으로 사용 설정됩니다.

모든 도메인에서 자동 조정을 사용하도록 설정하고 반복 유지 관리 기간을 설정하거나 권장 사항을 정기적으로 검토하는 것이 좋습니다.

보안

다음 모범 사례가 도메인 보안에 적용됩니다.

세분화된 액세스 제어 사용 설정

세분화된 액세스 제어를 통해 서비스 도메인 내의 특정 데이터에 액세스할 수 있는 사용자를 제어할 수 있습니다. OpenSearch 일반화된 액세스 제어와 비교하여 세분화된 액세스 제어는 각 클러스터, 인덱스, 문서 및 필드에 액세스에 지정된 고유한 정책을 제공합니다. 액세스 기준은 액세스를 요청하는 사람의 역할 및 데이터에 대해 수행하려는 작업을 비롯한 여러 요소를 기반으로 할 수 있습니다. 예를 들어 한 사용자에게는 인덱스에 쓸 수 있는 액세스 권한을 부여하고 다른 사용자에게는 변경 없이 인덱스의 데이터를 읽을 수 있는 액세스 권한만 부여할 수 있습니다.

세분화된 액세스 제어를 통해 보안 또는 규정 준수 문제를 일으키지 않고 액세스 요구 사항이 서로 다른 데이터가 동일한 스토리지 공간에 존재할 수 있습니다.

도메인에서 세분화된 액세스 제어를 사용 설정하는 것을 권장합니다.

VPC 내에 도메인 배포

OpenSearch 서비스 도메인을 가상 사설 클라우드 (VPC) 내에 배치하면 인터넷 게이트웨이, NAT 디바이스 또는 VPN 연결 없이 서비스와 VPC 내의 다른 OpenSearch 서비스 간에 보안 통신을 할 수 있습니다. 모든 트래픽은 클라우드 내에서 안전하게 유지됩니다. AWS 논리적 격리로 인해 퍼블릭 엔드포인트를 사용할 때에 비해, VPC에 상주하는 도메인에는 보안 계층이 하나 추가됩니다.

VPC 내에서 도메인을 생성하는 것이 좋습니다.

제한적 액세스 정책 적용

도메인이 VPC 내에 배포된 경우에도 계층으로 보안을 구현하는 것이 가장 좋습니다. 현재 액세스 정책의 구성을 확인합니다.

제한적인 리소스 기반 액세스 정책을 도메인에 적용하고 구성 API 및 API 작업에 대한 액세스 권한을 부여할 때는 최소 권한 원칙을 따르세요. OpenSearch 일반적인 액세스 정책에서 익명의 사용자 주체 "Principal": {"AWS": "*" }를 사용하지 않습니다.

단, 세분화된 액세스 제어를 사용하도록 설정하는 경우와 같이 오픈 액세스 정책을 사용하는 것이 허용되는 경우도 있습니다. 오픈 액세스 정책을 사용하면 특정 클라이언트 및 도구와 같이 요청 서명이 어렵거나 불가능한 경우 도메인에 액세스할 수 있습니다.

저장 시 암호화 사용 설정

OpenSearch 서비스 도메인은 저장된 데이터를 암호화하여 데이터에 대한 무단 액세스를 방지하는 데 도움이 됩니다. 저장 중 암호화는 AWS Key Management Service (AWS KMS) 를 사용하여 암호화 키를 저장 및 관리하고, 256비트 키를 사용하는 고급 암호화 표준 알고리즘 (AES-256) 을 사용하여 암호화를 수행합니다.

도메인에 민감한 데이터가 저장되는 경우 저장 데이터 암호화를 사용 설정합니다.

암호화를 활성화합니다. node-to-node

N ode-to-node 암호화는 OpenSearch 서비스 내 기본 보안 기능 외에 추가 보안 계층을 제공합니다. 서비스 내에서 프로비저닝되는 노드 간의 모든 통신에 대해 TLS (전송 계층 보안) 를 구현합니다. OpenSearch ode-to-node 암호화를 사용하지 않는 경우 HTTPS를 통해 OpenSearch 서비스 도메인으로 전송되는 모든 데이터는 전송 중에도 암호화된 상태로 유지되고 노드 간에 분산 및 복제됩니다.

도메인에 민감한 데이터가 저장되어 있는 경우 암호화를 node-to-node활성화하세요.

로 모니터링하십시오. AWS Security Hub

를 사용하여 보안 모범 사례와 관련된 OpenSearch 서비스 사용을 모니터링하십시오 AWS Security Hub. Security Hub는 보안 제어를 사용하여 리소스 구성 및 보안 표준을 평가하여 다양한 규정 준수 프레임워크를 준수할 수 있도록 지원합니다. Security Hub를 사용하여 OpenSearch 서비스 리소스를 평가하는 방법에 대한 자세한 내용은 사용 AWS Security Hub 설명서의 Amazon OpenSearch Service 컨트롤을 참조하십시오.

비용 최적화

다음 모범 사례는 OpenSearch 서비스 비용 최적화 및 절감에 적용됩니다.

시계열 로그 데이터를 UltraWarm 위한 사용 및 콜드 스토리지

로그 OpenSearch 분석에 사용하는 경우 데이터를 콜드 스토리지로 옮겨 비용을 절감하세요. UltraWarm 인덱스 상태 관리(ISM)를 사용하여 스토리지 계층 간에 데이터를 마이그레이션하고 데이터 보존을 관리할 수 있습니다.

UltraWarm대량의 읽기 전용 데이터를 OpenSearch Service에 저장할 수 있는 비용 효율적인 방법을 제공합니다. UltraWarm Amazon S3를 스토리지로 사용합니다. 즉, 데이터는 변경할 수 없으며 복사본 하나만 필요합니다. 인덱스의 기본 샤드 크기에 해당하는 스토리지에 대한 비용만 지불합니다. UltraWarm 쿼리를 처리하는 데 필요한 S3 데이터의 양에 따라 쿼리 지연 시간도 늘어납니다. 데이터가 노드에 캐시된 후 인덱스에 대한 쿼리는 핫 UltraWarm 인덱스에 대한 쿼리와 비슷한 방식으로 수행됩니다.

콜드 스토리지는 S3에서도 지원됩니다. 콜드 데이터를 쿼리해야 하는 경우 기존 노드에 선택적으로 연결할 수 있습니다. UltraWarm 콜드 데이터에는 동일한 관리 스토리지 비용이 발생하지만 콜드 스토리지의 오브젝트는 노드 리소스를 UltraWarm 소비하지 않습니다. UltraWarm 따라서 콜드 스토리지는 UltraWarm 노드 크기나 수에 영향을 주지 않으면서 상당한 양의 스토리지 용량을 제공합니다.

UltraWarm 핫 스토리지에서 마이그레이션할 데이터가 약 2.5TiB일 때 비용 효율적입니다. 유효노출률을 모니터링하고 해당 데이터 볼륨에 UltraWarm 도달하기 전으로 인덱스를 이동할 계획을 세우세요.

예약 인스턴스 권장 사항 검토

성능 및 컴퓨팅 소비에 대한 기준이 양호하다면 예약 인스턴스(RI) 구매를 고려하세요. 할인은 선결제 없는 1년 예약의 경우 약 30%부터 모두 선결제한 3년 약정의 경우 최대 50%까지 증가할 수 있습니다.

최소 14일 동안 안정적으로 작동하는 것으로 보이면 비용 탐색기에서 예약 인스턴스 권장 사항을 검토하세요. Amazon OpenSearch Service 제목에는 구체적인 RI 구매 권장 사항 및 예상 절감액이 표시됩니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

파이프 처리 언어

도메인 크기 조정