Amazon OpenSearch Service의 운영 모범 사례

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

주제

모니터링 및 알림

다음 모범 사례는 OpenSearch Service 도메인을 모니터링하는 데 적용됩니다.

CloudWatch 경보 구성

OpenSearch Service는 Amazon CloudWatch에 성능 지표를 전송합니다. 클러스터 및 인스턴스 지표를 정기적으로 검토하고 워크로드 성능에 따라 권장되는 CloudWatch 경보를 구성합니다.

로그 게시 사용 설정

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

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

샤드 전략

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

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

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

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

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

샤드 및 데이터 노드 수 결정

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

샤드 크기 - 디스크의 데이터 크기는 소스 데이터 크기의 직접적인 결과이며 더 많은 데이터를 인덱싱할 때 변경됩니다. 소스 대 인덱스 비율은 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개 이하의 샤드를 보유해야 합니다. 샤드 배포는 워크로드 패턴에 따라 다를 수 있지만 Elasticsearch 및 OpenSearch 1.1~2.15의 경우 노드당 1,000개의 샤드, OpenSearch 2.17 이상의 경우 4,000개의 샤드 제한이 있습니다. cat/allocation API는 데이터 노드의 샤드 수와 전체 샤드 스토리지에 대한 빠른 보기를 제공합니다.

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

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

스토리지 스큐 방지

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

안정성

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

OpenSearch로 최신 정보 유지

서비스 소프트웨어 업데이트

OpenSearch Service는 기능을 추가하거나 도메인을 개선하는 소프트웨어 업데이트를 정기적으로 릴리스합니다. 업데이트는 OpenSearch 또는 Elasticsearch 엔진 버전을 변경하지 않습니다. 설명 도메인 API 작업을 실행하도록 반복 시간을 예약하고 UpdateStatus이(가) ELIGIBLE인 경우 서비스 소프트웨어 업데이트를 시작하는 것이 좋습니다. 특정 기간(일반적으로 2주) 내에 도메인을 업데이트하지 않으면 OpenSearch Service가 업데이트를 자동으로 수행합니다.

OpenSearch 버전 업그레이드

OpenSearch Service는 커뮤니티에서 관리하는 OpenSearch 버전에 대한 지원을 정기적으로 추가합니다. 최신 OpenSearch 버전이 출시되면 항상 최신 버전으로 업그레이드합니다.

OpenSearch Service는 OpenSearch와 OpenSearch Dashboards(또는 도메인이 레거시 엔진을 실행하는 경우 Elasticsearch와 Kibana)를 동시에 업그레이드합니다. 클러스터에 전용 관리자 노드가 있는 경우 가동 중지 없이 업그레이드가 완료됩니다. 그렇지 않으면 클러스터가 관리자 노드를 선택하는 동안 업그레이드 후 몇 초 동안 응답하지 않을 수 있습니다. 일부 또는 모든 업그레이드 도중 OpenSearch Dashboards를 사용하지 못할 수 있습니다.

도메인을 업그레이드하는 방법은 두 가지입니다.

인 플레이스(In-place) 업그레이드 - 동일한 클러스터를 유지하므로 이 옵션이 더 쉽습니다.
스냅샷/복원 업그레이드 - 이 옵션은 새 클러스터에서 새 버전을 테스트하거나 클러스터 간 마이그레이션에 적합합니다.

어떤 업그레이드 프로세스를 사용하든 개발 및 테스트 전용 도메인을 유지 관리하고 프로덕션 도메인을 업그레이드하기 전에 새 버전으로 업그레이드하는 것이 좋습니다. 테스트 도메인을 생성할 때, 배포 유형은 Development and testing(개발 및 테스트)를 선택합니다. 도메인 업그레이드 직후 모든 클라이언트를 호환되는 버전으로 업그레이드해야 합니다.

스냅샷 성능 개선

스냅샷이 처리되지 않도록 하려면 전용 관리자 노드의 인스턴스 유형이 샤드 수와 일치해야 합니다. 자세한 내용은 전용 관리자 노드의 인스턴스 유형 선택 단원을 참조하십시오. 또한 각 노드에는 Java 힙 메모리의 GiB당 25개 이상의 권장 샤드가 있어서는 안 됩니다. 자세한 내용은 샤드 수 선택 단원을 참조하십시오.

전용 관리자 노드 활성화

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

세 개의 가용 영역에서 최적의 도메인 안정성을 위해 세 개의 전용 관리자 노드를 활성화하고 사용합니다. 다중 AZ와 Standby를 함께 배포하면 세 개의 전용 관리자 노드가 자동으로 구성됩니다. 인스턴스 유형 권장 사항은 전용 관리자 노드의 인스턴스 유형 선택 섹션을 참조하세요.

여러 가용 영역에 걸쳐 배포

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

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

수집 흐름 및 버퍼링 제어

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

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

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

Log ingest architecture with producers, collectors, aggregators, and dashboards components.

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

검색 워크로드의 경우 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 Service는 지정된 패턴과 일치하는 모든 인덱스에 정책을 자동으로 적용합니다.

사용되지 않는 인덱스 삭제

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

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

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

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

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

성능

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

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

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

요청 및 응답 페이로드 크기를 줄이기 위해 gzip 압축을 사용하여 OpenSearch 도메인에서 요청을 보내고 응답을 받습니다. OpenSearch Python 클라이언트와 함께 또는 클라이언트 측에서 다음 헤더를 포함하여 gzip 압축을 사용할 수 있습니다.

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

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

참고

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

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

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

새로 고침 주기 조정

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

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

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

자동 조정 사용 설정

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

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

보안

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

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

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

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

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

VPC 내에 도메인 배포

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

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

제한적 액세스 정책 적용

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

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

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

저장 시 암호화 사용 설정

OpenSearch Service 도메인은 데이터에 대한 무단 액세스를 방지하기 위해 저장 데이터 암호화를 제공합니다. 저장 시 암호화는 암호화 키를 저장 및 관리하는 데 AWS Key Management Service (AWS KMS)를 사용하고 암호화를 수행하는 데 256비트 키(AES-256)가 있는 고급 암호화 표준 알고리즘을 사용합니다.

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

노드 간 암호화 사용 설정

노드 간 암호화는 OpenSearch Service의 기본 보안 기능에 추가적인 보안 계층을 제공합니다. OpenSearch 내에서 프로비저닝된 노드 간의 모든 통신에 대해 전송 계층 보안(TLS)을 구현합니다. 노드 간 암호화를 사용하면 HTTPS를 통해 OpenSearch Service 도메인으로 전송된 모든 데이터가 노드 간에 배포 및 복제되는 동안 전송 중에 암호화된 상태로 유지됩니다.

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

를 사용하여 모니터링 AWS Security Hub

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

비용 최적화

다음 모범 사례는 OpenSearch Service 비용을 최적화하고 절약하는 데 적용됩니다.

시계열 로그 데이터에 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가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

파이프 처리 언어

도메인 크기 조정