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

UltraWarm Amazon OpenSearch Service용 스토리지

UltraWarm 는 Amazon OpenSearch Service에 대량의 읽기 전용 데이터를 저장하는 비용 효율적인 방법을 제공합니다. 표준 데이터 노드는 각 노드에 연결된 인스턴스 스토어 또는 Amazon EBS 볼륨의 형태를 취하는 '핫' 스토리지를 사용합니다. 핫 스토리지의 새로운 데이터 인덱싱 및 검색 성능이 가장 빠릅니다.

연결된 스토리지 대신 UltraWarm 노드는 Amazon S3와 정교한 캐싱 솔루션을 사용하여 성능을 개선합니다. 활발하게 쓰지 않는 인덱스의 경우 쿼리 빈도가 적고 동일한 성능이 필요하지 않은 UltraWarm 는 GiB당 데이터 비용을 크게 절감합니다. 웜 인덱스는 핫 스토리지로 반환하지 않는 한 읽기 전용이므로 로그와 같은 변경 불가능한 데이터에 UltraWarm 가장 적합합니다.

에서 OpenSearch웜 인덱스는 다른 인덱스와 마찬가지로 동작합니다. 동일한를 사용하여 쿼리APIs하거나 대시보드에서 시각화를 생성하는 데 사용할 수 OpenSearch 있습니다.

사전 조건

UltraWarm 에는 몇 가지 중요한 사전 조건이 있습니다.

권한 구성

기존 OpenSearch 서비스 도메인 UltraWarm 에서를 활성화하면 도메인에 ultrawarm_manager 역할이 정의되지 않을 수 있습니다. 관리자가 아닌 사용자는 이 역할에 매핑되어 세분화된 액세스 제어를 사용하는 도메인의 웜 인덱스를 관리해야 합니다. 수동으로 ultrawarm_manager 역할을 생성하려면 다음 단계를 수행합니다.

UltraWarm 스토리지 요구 사항 및 성능 고려 사항

에서 다룬 것처럼 핫 스토리지의 데이터에는 복제본스토리지 요구 사항 계산, Linux 예약 공간 및 OpenSearch 서비스 예약 공간 등 상당한 오버헤드가 발생합니다. 예를 들어, 복제본 샤드가 1개인 20GiB 기본 샤드에는 약 58GiB의 핫 스토리지가 필요합니다.

Amazon S3를 사용하기 때문에는이 오버헤드를 UltraWarm 발생시키지 않습니다. UltraWarm 스토리지 요구 사항을 계산할 때 기본 샤드의 크기만 고려합니다. S3의 데이터 내구성 덕분에 복제본이 필요하지 않으며, S3는 운영 체제 또는 서비스 고려 사항을 추상화합니다. 동일한 20GiB 샤드에는 20GiB의 웜 스토리지가 필요합니다. ultrawarm1.large.search 인스턴스를 프로비저닝하는 경우, 기본 샤드에 최대 스토리지 20TiB를 모두 사용할 수 있습니다. 인스턴스 유형 요약과 각 인스턴스 유형이 사용할 수 있는 최대 스토리지 용량은 UltraWarm 스토리지 할당량 섹션을 참조하세요.

의 경우 최대 샤드 크기는 50GiB인 UltraWarm것이 좋습니다. 각 UltraWarm 인스턴스 유형에 RAM 할당된 CPU 코어 수와의 양은 동시에 검색할 수 있는 샤드 수에 대한 아이디어를 제공합니다. 기본 샤드만 S3의 스토리지에 UltraWarm 포함되지만, OpenSearch 대시보드는 _cat/indices 인덱스 UltraWarm 크기를 모든 기본 및 복제본 샤드의 합계로 보고합니다.

예를 들어 각 ultrawarm1.medium.search 인스턴스에는 CPU 코어가 2개 있으며 S3에서 최대 1.5TiB의 스토리지를 처리할 수 있습니다. 이러한 인스턴스 중 두 개에는 결합된 3TiB 스토리지가 있으며, 각 샤드가 50GiB인 경우 약 62개의 샤드로 작동합니다. 클러스터에 대한 요청이 이러한 샤드 중 네 개만 검색하는 경우 성능이 우수할 수 있습니다. 요청이 광범위하고 62개 모두 검색하면 4개의 CPU 코어가 작업을 수행하는 데 어려움을 겪을 수 있습니다. WarmCPUUtilization 및 WarmJVMMemoryPressure UltraWarm 지표를 모니터링하여 인스턴스가 워크로드를 처리하는 방법을 파악합니다.

검색 범위가 넓거나 빈번한 경우 인덱스를 핫 스토리지에 남겨 두는 것이 좋습니다. 다른 OpenSearch 워크로드와 마찬가지로가 요구 사항을 UltraWarm 충족하는지 확인하는 가장 중요한 단계는 사실적인 데이터 세트를 사용하여 대표적인 클라이언트 테스트를 수행하는 것입니다.

UltraWarm 요금

핫 스토리지를 사용하면 프로비저닝하는 만큼 비용을 지불합니다. 일부 인스턴스에는 연결된 Amazon EBS 볼륨이 필요한 반면, 다른 인스턴스에는 인스턴스 스토어가 포함됩니다. 스토리지가 비어 있든 가득 차 있든, 동일한 가격을 지불합니다.

UltraWarm 스토리지를 사용하면 사용한 비용을 지불합니다. ultrawarm1.large.search 인스턴스는 S3에서 최대 20TiB의 스토리지를 처리할 수 있지만, 1TiB의 데이터만 저장하는 경우 1TiB의 데이터에 해당하는 비용만 청구됩니다. 다른 모든 노드 유형과 마찬가지로 각 UltraWarm 노드에 대해 시간당 요금도 지불합니다. 자세한 내용은 Amazon OpenSearch Service 요금 단원을 참조하십시오.

활성화 UltraWarm

콘솔은 웜 스토리지를 사용하는 도메인을 생성하는 가장 간단한 방법입니다. 도메인을 생성하는 동안 UltraWarm 데이터 노드 활성화와 원하는 웜 노드 수를 선택합니다. 사전 조건을 충족하는 경우 기존 도메인에서도 동일한 기본 프로세스가 적용됩니다. 도메인 상태가 처리 중에서 활성으로 변경된 후에도 몇 시간 동안 사용하지 못할 수 UltraWarm 있습니다.

Multi-AZ with Standby 도메인을 사용하는 경우 웜 노드 수는 사용 중인 가용 영역 수의 배수여야 합니다. 자세한 내용은 Multi-AZ with Standby 단원을 참조하십시오.

AWS CLI 또는 구성을 API 사용하여 UltraWarm, 특히의 WarmEnabled, WarmCount및 WarmType 옵션을 활성화할 수도 있습니다ClusterConfig.

샘플 CLI 명령

다음 AWS CLI 명령은 3개의 데이터 노드, 3개의 전용 마스터 노드, 6개의 웜 노드 및 세분화된 액세스 제어가 활성화된 도메인을 생성합니다.

aws opensearch create-domain \
  --domain-name my-domain \
  --engine-version Opensearch_1.0 \
  --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.search \
  --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \
  --node-to-node-encryption-options Enabled=true \
  --encryption-at-rest-options Enabled=true \
  --domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \
  --advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName=master-user,MasterUserPassword=master-password}' \
  --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-west-1:123456789012:domain/my-domain/*"}]}' \
  --region us-east-1

자세한 내용은 AWS CLI 명령 참조를 참조하세요.

샘플 구성 API 요청

구성에 대한 다음 요청은 세 개의 데이터 노드, 세 개의 전용 마스터 노드, 세분화된 액세스 제어가 활성화되고 제한적인 액세스 정책이 있는 여섯 개의 웜 노드로 도메인을 API 생성합니다.

POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain
{
  "ClusterConfig": {
    "InstanceCount": 3,
    "InstanceType": "r6g.large.search",
    "DedicatedMasterEnabled": true,
    "DedicatedMasterType": "r6g.large.search",
    "DedicatedMasterCount": 3,
    "ZoneAwarenessEnabled": true,
    "ZoneAwarenessConfig": {
      "AvailabilityZoneCount": 3
    },
    "WarmEnabled": true,
    "WarmCount": 6,
    "WarmType": "ultrawarm1.medium.search"
  },
  "EBSOptions": {
    "EBSEnabled": true,
    "VolumeType": "gp2",
    "VolumeSize": 11
  },
  "EncryptionAtRestOptions": {
    "Enabled": true
  },
  "NodeToNodeEncryptionOptions": {
    "Enabled": true
  },
  "DomainEndpointOptions": {
    "EnforceHTTPS": true,
    "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
  },
   "AdvancedSecurityOptions": {
    "Enabled": true,
    "InternalUserDatabaseEnabled": true,
    "MasterUserOptions": {
      "MasterUserName": "master-user",
      "MasterUserPassword": "master-password"
    }
  },
  "EngineVersion": "Opensearch_1.0",
  "DomainName": "my-domain",
  "AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"123456789012\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:us-east-1:123456789012:domain/my-domain/*\"}]}"
}

자세한 내용은 Amazon OpenSearch 서비스 API 참조를 참조하세요.

인덱스를 UltraWarm 스토리지로 마이그레이션

인덱스에 쓰기를 마쳤지만 더 이상 가장 빠른 검색 성능이 필요하지 않은 경우 핫에서 UltraWarm다음으로 마이그레이션합니다.

POST _ultrawarm/migration/my-index/_warm

그런 다음 마이그레이션 상태를 확인합니다.

GET _ultrawarm/migration/my-index/_status

{
  "migration_status": {
    "index": "my-index",
    "state": "RUNNING_SHARD_RELOCATION",
    "migration_type": "HOT_TO_WARM",
    "shard_level_status": {
      "running": 0,
      "total": 5,
      "pending": 3,
      "failed": 0,
      "succeeded": 2
    }
  }
}

마이그레이션을 수행하려면 인덱스 상태가 녹색이어야 합니다. 여러 인덱스를 빠르게 연속적으로 마이그레이션하는 경우 _cat API와 마찬가지로 일반 텍스트로 모든 마이그레이션에 대한 요약을 얻을 수 있습니다.

GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch 서비스는 한 번에 하나의 인덱스를 로 마이그레이션합니다 UltraWarm. 대기열에 최대 200번의 마이그레이션이 있을 수 있습니다. 한도를 초과하는 요청은 거부됩니다. 현재 대기열의 마이그레이션 번호를 확인하려면 HotToWarmMigrationQueueSize 지표를 모니터링합니다. 인덱스는 마이그레이션 프로세스 전반에 걸쳐 계속 사용할 수 있으며 가동 중지 없이 사용할 수 있습니다.

마이그레이션 프로세스의 상태는 다음과 같습니다.

PENDING_INCREMENTAL_SNAPSHOT
RUNNING_INCREMENTAL_SNAPSHOT
FAILED_INCREMENTAL_SNAPSHOT
PENDING_FORCE_MERGE
RUNNING_FORCE_MERGE
FAILED_FORCE_MERGE
PENDING_FULL_SNAPSHOT
RUNNING_FULL_SNAPSHOT
FAILED_FULL_SNAPSHOT
PENDING_SHARD_RELOCATION
RUNNING_SHARD_RELOCATION
FINISHED_SHARD_RELOCATION

이러한 상태가 나타내듯이 스냅샷, 샤드 재배치 또는 강제 병합 중에 마이그레이션이 실패할 수 있습니다. 스냅샷 또는 샤드 재배치 중 실패는 일반적으로 노드 오류 또는 S3 연결 문제로 인해 발생합니다. 일반적으로 디스크 공간 부족이 강제 병합 실패의 근본 원인입니다.

마이그레이션이 완료되면 동일한 _status 요청이 오류를 반환합니다. 이때 인덱스를 확인하면 웜 인덱스만의 고유한 몇 가지 설정을 볼 수 있습니다.

GET my-index/_settings

{
  "my-index": {
    "settings": {
      "index": {
        "refresh_interval": "-1",
        "auto_expand_replicas": "false",
        "provided_name": "my-index",
        "creation_date": "1599241458998",
        "unassigned": {
          "node_left": {
            "delayed_timeout": "5m"
          }
        },
        "number_of_replicas": "1",
        "uuid": "GswyCdR0RSq0SJYmzsIpiw",
        "version": {
          "created": "7070099"
        },
        "routing": {
          "allocation": {
            "require": {
              "box_type": "warm"
            }
          }
        },
        "number_of_shards": "5",
        "merge": {
          "policy": {
            "max_merge_at_once_explicit": "50"
          }
        }
      }
    }
  }
}

웜 스토리지의 인덱스는 핫 스토리지로 반환하지 않는 한 읽기 전용이므로 로그와 같이 변경할 수 없는 데이터에 UltraWarm 가장 적합합니다. 인덱스를 쿼리하여 삭제할 수 있지만 개별 문서를 추가, 업데이트 또는 삭제할 수 없습니다. 시도하는 경우 오류가 발생할 수 있습니다.

{
  "error" : {
    "root_cause" : [
      {
        "type" : "cluster_block_exception",
        "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
      }
    ],
    "type" : "cluster_block_exception",
    "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
  },
  "status" : 429
}

마이그레이션 자동화

인덱스가 특정 기간에 도달하거나 다른 조건을 충족한 후에는 Amazon OpenSearch Service의 인덱스 상태 관리을 사용하여 마이그레이션 프로세스를 자동화하는 것이 좋습니다. 이 워크플로를 보여주는 샘플 정책을 참조하세요.

마이그레이션 조정

UltraWarm 스토리지로의 인덱스 마이그레이션에는 강제 병합이 필요합니다. 각 OpenSearch 인덱스는 몇 개의 샤드로 구성되며, 각 샤드는 몇 개의 Lucene 세그먼트로 구성됩니다. 강제 병합 작업은 삭제하도록 표시된 문서를 소거하고 디스크 공간을 절약합니다. 기본적으로는 20의 기본값이 사용되는 kNN 인덱스를 제외하고 하나의 세그먼트로 인덱스를 UltraWarm 병합합니다.

index.ultrawarm.migration.force_merge.max_num_segments 설정을 사용하여 이 값을 최대 1,000개의 세그먼트까지 변경할 수 있습니다. 값이 높을수록 마이그레이션 프로세스 속도가 빨라지지만 마이그레이션이 완료된 후 웜 인덱스에 대한 쿼리 대기 시간이 늘어납니다. 설정을 변경하려면 다음과 같이 요청합니다.

PUT my-index/_settings
{
  "index": {
    "ultrawarm": {
      "migration": {
        "force_merge": {
          "max_num_segments": 1
        }
      }
    }
  }
}

마이그레이션 프로세스의 이 단계에 걸리는 시간을 확인하려면HotToWarmMigrationForceMergeLatency 지표를 모니터링합니다.

마이그레이션 취소

UltraWarm 는 대기열에서 마이그레이션을 순차적으로 처리합니다. 마이그레이션이 대기열에 있지만 아직 시작되지 않은 경우 다음 요청을 사용하여 대기열에서 제거할 수 있습니다.

POST _ultrawarm/migration/_cancel/my-index

도메인에서 세분화된 액세스 제어를 사용하는 경우 이 요청을 하기 위해 indices:admin/ultrawarm/migration/cancel 권한이 필요합니다.

핫 인덱스 및 웜 인덱스 나열

UltraWarm 는 핫 인덱스와 웜 인덱스를 관리하는 _all데 도움이 되도록와 유사한 두 가지 추가 옵션을 추가합니다. 모든 웜 또는 핫 인덱스 목록을 보려면 다음과 같이 요청합니다.

GET _warm
GET _hot

인덱스를 지정하는 다른 요청에서 이러한 옵션을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

_cat/indices/_warm
_cluster/state/_all/_hot

핫 스토리지로 웜 인덱스 되돌리기

인덱스에 다시 기록해야 하는 경우 핫 스토리지로 다시 마이그레이션합니다.

POST _ultrawarm/migration/my-index/_hot

한 번에 최대 10개의 대기열에 있는 웜 스토리지에서 핫 스토리지로 마이그레이션할 수 있습니다. OpenSearch 서비스는 대기열에 있는 순서대로 마이그레이션 요청을 한 번에 하나씩 처리합니다. 현재 번호를 확인하려면 WarmToHotMigrationQueueSize 지표를 모니터링합니다.

마이그레이션을 완료한 후 인덱스 설정을 검토하여 요구 사항을 충족하는지 확인합니다. 인덱스가 하나의 복제본이 있는 핫 스토리지로 돌아갑니다.

스냅샷에서 웜 인덱스 복원

자동 스냅샷의 표준 리포지토리 외에도는 웜 인덱스의 두 번째 리포지토리인를 UltraWarm 추가합니다cs-ultrawarm. 이 리포지토리의 각 스냅샷에는 하나의 인덱스만 포함됩니다. 웜 인덱스를 삭제하면 해당 스냅샷은 다른 자동 스냅샷과 마찬가지로 14일 동안 cs-ultrawarm 리포지토리에 남아 있습니다.

cs-ultrawarm에서 스냅샷을 복원하면 핫 스토리지가 아닌 웜 스토리지로 복원됩니다. cs-automated 및 cs-automated-enc 리포지토리의 스냅샷은 핫 스토리지로 복원됩니다.

웜 인덱스의 수동 스냅샷

웜 인덱스의 수동 스냅 샷을 생성할 수 있지만 권장하지 않습니다. 마이그레이션 중에 생성한 각 웜 인덱스에 대한 스냅샷이 추가 비용 없이 자동 cs-ultrawarm 리포지토리에 이미 포함되어 있습니다.

기본적으로 OpenSearch 서비스는 수동 스냅샷에 웜 인덱스를 포함하지 않습니다. 예를 들어, 다음 호출에는 핫 인덱스만 포함됩니다.

PUT _snapshot/my-repository/my-snapshot

웜 인덱스의 수동 스냅샷을 생성하도록 선택하면 몇 가지 중요한 고려 사항이 적용됩니다.

콜드 스토리지로 웜 인덱스 마이그레이션

자주 쿼리하지 UltraWarm 않는에 데이터가 있는 경우 콜드 스토리지로 마이그레이션하는 것이 좋습니다. 콜드 스토리지는 가끔 액세스하거나 더 이상 사용하지 않는 데이터를 위한 것입니다. 콜드 인덱스에서 읽거나 쓸 수는 없지만 쿼리해야 할 때마다 무료로 웜 스토리지로 다시 마이그레이션 할 수 있습니다. 지침은 인덱스를 콜드 스토리지로 마이그레이션을 참조하세요.

KNN 인덱스 모범 사례

비활성화 UltraWarm

콘솔을 비활성화하는 가장 간단한 방법입니다 UltraWarm. 도메인을 선택하고 [작업(Actions)], [클러스터 구성 편집(Edit cluster configuration)]을 선택합니다. UltraWarm 데이터 노드 활성화를 선택 취소하고 변경 사항 저장을 선택합니다. AWS CLI 및 구성에서 WarmEnabled 옵션을 사용할 수도 있습니다API.

비활성화 UltraWarm하기 전에 모든 웜 인덱스를 삭제하거나 핫 스토리지로 다시 마이그레이션해야 합니다. 웜 스토리지가 비어 있으면 5분 후에 비활성화를 시도합니다 UltraWarm.