기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon OpenSearch Service에서 인덱스 관리
Amazon OpenSearch Service에 데이터를 추가한 후에는 해당 데이터를 다시 인덱싱하거나, 인덱스 별칭을 사용하여 작업하거나, 인덱스를 보다 비용 효율적인 스토리지로 이동하거나, 모두 삭제해야 하는 경우가 많습니다. 이 장에서는 스토리지 계층화 솔루션, 인덱스 상태 관리 및 기타 인덱스 작업을 다룹니다. OpenSearch 인덱스 API에 대한 자세한 내용은 [OpenSearch 설명서](https://docs.opensearch.org/latest/opensearch/reindex-data/)를 참조하세요.
**Topics**
+ [Amazon OpenSearch Service 도메인에 대한 OpenSearch 최적화 인스턴스](or1.md)
+ [Amazon OpenSearch Service용 멀티 티어 스토리지](multi-tier-storage.md)
+ [Amazon OpenSearch Service를 위한 UltraWarm 스토리지](ultrawarm.md)
+ [Amazon OpenSearch Service용 콜드 스토리지](cold-storage.md)
+ [Amazon OpenSearch Service의 인덱스 상태 관리](ism.md)
+ [인덱스 롤업을 사용하여 Amazon OpenSearch Service의 인덱스 요약](rollup.md)
+ [Amazon OpenSearch Service에서 인덱스 변환](transforms.md)
+ [Amazon OpenSearch Service의 클러스터 간 복제](replication.md)
+ [원격 재인덱스를 사용하여 Amazon OpenSearch Service 인덱스 마이그레이션](remote-reindex.md)
+ [데이터 스트림을 사용하여 Amazon OpenSearch Service에서 시계열 데이터 관리](data-streams.md)
# Amazon OpenSearch Service 도메인에 대한 OpenSearch 최적화 인스턴스
Amazon OpenSearch Service용 OpenSearch 최적화 인스턴스 패밀리는 대용량 데이터를 저장하기 위한 비용 효율적인 솔루션입니다. OpenSearch 최적화 인스턴스가 있는 도메인은 로컬 스토리지를 기본 스토리지로 사용하며, 데이터가 도착하면 Amazon S3에 동기적으로 복사됩니다. 이 스토리지 구조는 향상된 인덱싱 처리량과 높은 내구성을 제공합니다. OR1, OR2, OM2는 Amazon Elastic Block Store(Amazon EBS) `gp3` 또는 `io1` 볼륨을 로컬로 사용하는 반면 OI2 인스턴스는 로컬 NVMe 디스크를 사용합니다. 또한 OpenSearch 최적화 인스턴스 패밀리는 장애 발생 시 자동 데이터 복구를 지원합니다. OpenSearch 최적화 인스턴스 유형 옵션에 대한 자세한 내용은 [현재 세대 인스턴스 유형](supported-instance-types.md#latest-gen) 섹션을 참조하세요.
로그 분석, 관찰성 또는 보안 분석과 같은 운영 분석 워크로드의 인덱싱을 실행하는 경우 OpenSearch 최적화 인스턴스의 향상된 성능과 컴퓨팅 효율성의 이점을 누릴 수 있습니다. 또한 OpenSearch 최적화 인스턴스에서 제공하는 자동 데이터 복구는 도메인의 전반적인 신뢰성을 개선합니다.
OpenSearch Service는 Amazon CloudWatch에 스토리지 관련 OpenSearch 최적화 인스턴스 지표를 전송합니다. 사용 가능한 지표 목록은 [OpenSearch 최적화 인스턴스(OR1) 지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-or1) 섹션을 참조하세요.
OpenSearch 최적화 인스턴스는 온디맨드 또는 예약 인스턴스 요금으로 사용할 수 있으며, Amazon EBS 및 Amazon S3에서 프로비저닝된 인스턴스 및 스토리지에 대한 시간당 요금이 적용됩니다.
**Topics**
+ [제한 사항](#or1-considerations)
+ [더 나은 수집 처리량을 위한 조정](#or1-ultrawarm-tuning)
+ [OpenSearch 최적화 인스턴스와 다른 인스턴스의 차이](#or1-optimized-instances)
+ [OpenSearch 최적화 인스턴스와 UltraWarm 인스턴스의 차이점](#or1-ultrawarm-differences)
+ [OpenSearch 최적화 인스턴스를 사용하여 도메인 프로비저닝](#or1-using)
## 제한 사항
도메인에 대해 OpenSearch 최적화 인스턴스를 사용할 때 다음 제한 사항을 고려합니다.
+ 새로 생성된 도메인은 OpenSearch 버전 2.11 이상을 실행해야 합니다.
+ 기존 도메인은 OpenSearch 버전 2.15 이상을 실행해야 합니다.
+ 도메인에서 저장 시 암호화가 활성화되어 있어야 합니다. 자세한 내용은 [Amazon OpenSearch Service의 저장된 데이터 암호화](encryption-at-rest.md) 단원을 참조하십시오.
+ 도메인이 전용 마스터 노드를 사용하는 경우 Graviton 인스턴스를 사용해야 합니다. 전용 마스터 노드에 대한 자세한 내용은 [Amazon OpenSearch Service의 전용 프라이머리 노드](managedomains-dedicatedmasternodes.md) 섹션을 참조하세요.
+ OpenSearch 최적화 인스턴스에서 인덱스의 새로 고침 간격은 10초 이상이어야 합니다. OpenSearch 최적화 인스턴스의 기본 새로 고침 간격은 10초입니다.
## 더 나은 수집 처리량을 위한 조정
OpenSearch 최적화 인스턴스에서 최적의 인덱싱 처리량을 얻으려면 다음을 수행하는 것이 좋습니다.
+ 대용량 크기를 사용하여 버퍼 사용률을 개선합니다. 권장 크기는 10MB입니다.
+ 병렬 처리 성능을 개선하려면 여러 클라이언트를 사용합니다.
+ 리소스 사용률을 극대화하기 위해 데이터 노드 수와 일치하도록 활성 기본 샤드 수를 설정합니다.
## OpenSearch 최적화 인스턴스와 다른 인스턴스의 차이
OpenSearch 최적화 인스턴스와 최적화되지 않은 인스턴스는 다음 면에서 차이가 납니다.
+ OpenSearch의 최적화된 인스턴스에서는 기본 샤드에서만 인덱싱이 수행됩니다.
+ OpenSearch의 최적화된 인스턴스가 복제본으로 구성된 경우 인덱싱 속도가 실제보다 낮게 나타날 수 있습니다. 예를 들어 기본 샤드 1개와 복제본 샤드 1개가 있는 경우, 실제 인덱싱 속도가 2,000임에도 인덱싱 속도가 1,000으로 표시될 수 있습니다.
+ OpenSearch의 최적화된 인스턴스는 원격 소스로 전송하기 전에 버퍼 작업을 수행합니다. 이에 따라 수집 지연 시간이 길어집니다.
**참고**
`IndexingLatency` 지표에는 translog 동기화 시간이 포함되지 않으므로 지표에는 영향을 주지 않습니다.
+ 복제본 샤드는 기본 샤드보다 몇 초 지연될 수 있습니다. `ReplicationLagMaxTime` Amazon CloudWatch 지표를 사용하여 지연 시간을 모니터링할 수 있습니다.
## OpenSearch 최적화 인스턴스와 UltraWarm 인스턴스의 차이점
OpenSearch Service는 대량의 읽기 전용 데이터를 저장하는 비용 효율적인 방법인 UltraWarm 인스턴스를 제공합니다. OpenSearch 최적화 및 UltraWarm 인스턴스는 모두 Amazon EBS에 로컬로 데이터를 저장하고 Amazon S3에 원격으로 데이터를 저장합니다. 그러나 OpenSearch 최적화 및 UltraWarm 인스턴스는 몇 가지 중요한 방식에서 차이가 납니다.
+ OpenSearch 최적화 인스턴스는 로컬 및 원격 스토어 *모두*에 데이터 사본을 보관합니다. UltraWarm 인스턴스에서 데이터는 스토리지 비용을 절감하기 위해 주로 원격 스토어에 보관됩니다. 사용량 패턴에 따라 데이터를 로컬 스토리지로 이동할 수 있습니다.
+ OpenSearch 최적화 인스턴스는 활성 상태이며 읽기 및 쓰기 작업을 수락할 수 있는 반면, UltraWarm 인스턴스의 데이터는 수동으로 핫 스토리지로 다시 이동할 때까지 읽기 전용입니다.
+ UltraWarm은 데이터 내구성을 위해 인덱스 스냅샷을 사용합니다. 이에 비해 OpenSearch 최적화 인스턴스는 백그라운드에서 복제 및 복구를 수행합니다. 빨간색 인덱스가 있는 경우 OpenSearch 최적화 인스턴스는 Amazon S3의 원격 스토리지에서 누락된 샤드를 자동 복원합니다. 복구 시간은 복구할 데이터의 양에 따라 달라집니다.
UltraWarm 스토리지에 대한 자세한 내용은 [Amazon OpenSearch Service를 위한 UltraWarm 스토리지](ultrawarm.md) 섹션을 참조하세요.
## OpenSearch 최적화 인스턴스를 사용하여 도메인 프로비저닝
AWS Management Console 또는 AWS Command Line Interface ()를 사용하여 새 도메인을 생성할 때 데이터 노드에 대해 OpenSearch 최적화 인스턴스를 선택할 수 있습니다AWS CLI. 기존 도구를 사용하여 데이터를 인덱싱하고 쿼리할 수 있습니다.
### 콘솔
1. Amazon OpenSearch Service 콘솔([https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/))로 이동합니다.
1. 왼쪽 탐색 창에서 **Domains**(도메인)를 선택합니다.
1. **도메인 생성(Create domain)**을 선택합니다.
1. **데이터 노드 수** 섹션에서 **인스턴스 패밀리** 메뉴를 확장하고 **OpenSearch 최적화**를 선택합니다.
1. 인스턴스 유형과 기타 스토리지 설정을 선택합니다.
1. **암호화** 섹션에서 **유휴 시 데이터 암호화 활성화**가 선택되어 있는지 확인합니다.
1. 도메인의 나머지 부분을 구성하고 **생성**을 선택합니다.
### AWS CLI
를 사용하여 OpenSearch 최적화 스토리지를 사용하는 도메인을 프로비저닝하려면에서 특정 인스턴스 유형 크기(예: OR1, OR2, OM2 또는 OI2)의 값을 제공해야 AWS CLI합니다`InstanceType`.
다음 예에서는 크기가 `2xlarge`인 OR1 인스턴스를 사용하여 도메인을 생성하고 저장 데이터 암호화를 활성화합니다.
```
aws opensearch create-domain \
--domain-name test-domain \
--engine-version OpenSearch_2.11 \
--cluster-config "InstanceType=or1.2xlarge.search,InstanceCount=3,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3" \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=200" \
--encryption-at-rest-options Enabled=true \
--advanced-security-options "Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions={MasterUserName=test-user,MasterUserPassword=test-password}" \
--node-to-node-encryption-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:account-id:domain/test-domain/*"}]}'
```
다음 예제에서는 크기의 OI2 인스턴스가 있는 도메인을 생성하고 저장 시 암호화를 `large` 활성화합니다. OI2 인스턴스는 로컬 NVMe 스토리지를 사용하므로 EBS 구성이 필요하지 않습니다.
```
aws opensearch create-domain \
--domain-name test-domain-oi2 \
--engine-version OpenSearch_2.11 \
--cluster-config "InstanceType=oi2.2xlarge.search,InstanceCount=3,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3" \
--encryption-at-rest-options Enabled=true \
--advanced-security-options "Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions={MasterUserName=test-user,MasterUserPassword=test-password}" \
--node-to-node-encryption-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:account-id:domain/test-domain-oi2/*"}]}'
```
# Amazon OpenSearch Service용 멀티 티어 스토리지
Amazon OpenSearch Service용 다중 계층 스토리지는 다양한 스토리지 계층에서 데이터를 관리하여 성능과 비용을 모두 최적화하는 지능형 데이터 관리 솔루션입니다. 이 아키텍처를 통해 조직은 자주 액세스하는 데이터를 고성능 핫 스토리지에 유지하는 동시에 자주 액세스하지 않는 데이터를 보다 비용 효율적인 웜 스토리지로 이동하여 성능과 비용 간의 균형을 효율적으로 조정할 수 있습니다.
Amazon OpenSearch Service는 핫/웜 스토리지 계층을 위한 두 가지 아키텍처 옵션을 제공합니다.
+ **OpenSearch 다중 계층 스토리지 아키텍처 **
+ Amazon S3를 로컬 인스턴스 스토리지와 결합
+ OpenSearch 최적화 인스턴스 기반
+ 웜 티어에서 쓰기 작업 지원
+ 핫 티어와 웜 티어 간의 원활한 데이터 마이그레이션 지원
+ OpenSearch 3.3 이상에서 사용 가능
+ 콜드 티어를 지원하지 않음
+ **UltraWarm 기반 아키텍처**
+ Amazon S3를 로컬 인스턴스 스토리지와 결합
+ UltraWarm 인스턴스 기반
+ 읽기 전용 웜 티어 워크로드에 최적화
+ Elasticsearch 버전 6.8 이상 및 모든 OpenSearch 버전에서 사용 가능
+ 콜드 티어 지원
**참고**
이 설명서는 멀티 티어 아키텍처에만 중점을 둡니다. Ultrawarm 스토리지 아키텍처는 [Ultrawarm](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html) 및 [콜드 스토리지](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html)를 참조하세요.
## 다중 계층 스토리지 아키텍처
**Topics**
+ [주요 이점](#multi-tier-benefits)
+ [사전 조건](#multi-tier-prerequisites)
+ [제한 사항](#multi-tier-limitations)
+ [주의 사항](#things-to-note)
+ [다중 계층 도메인 생성](#multi-tier-creating)
+ [티어 마이그레이션 관리](#multi-tier-managing)
+ [보안 구성](#multi-tier-security)
+ [모범 사례](#multi-tier-best-practices)
+ [지표 모니터링](#multi-tier-metrics)
### 주요 이점
+ **쓰기 가능한 웜:** 웜 인덱스에 대한 쓰기 작업 지원
+ **원활한 마이그레이션:** 스토리지 계층 간 원활한 데이터 이동
+ **비용 최적화:** 덜 활동적인 데이터를 비용 효율적인 웜 스토리지로 이동하여 스토리지 비용 절감
+ **성능 향상:** 핫 티어에서 자주 액세스하는 데이터에 대한 고성능 유지
+ **유연한 데이터 관리:** 워크로드 요구 사항에 가장 적합한 아키텍처 선택
+ **자동 관리:** 스토리지 계층 간 데이터 수명 주기 관리 간소화
### 사전 조건
+ **엔진 버전:** OpenSearch **3.3 이상**
+ **인스턴스 패밀리:**
+ 핫 노드: OR1, OR2, OM2 또는 OI2
+ 웜 노드: OI2
+ **보안:** Node-to-node 암호화, 저장 시 암호화, HTTPS 적용
### 제한 사항
+ Ultrawarm이 아직 활성화되지 않은 OpenSearch 최적화 인스턴스가 있는 모든 도메인에서 작동
+ 콜드 티어를 지원하지 않음
### 주의 사항
+ 핫-웜 마이그레이션은 다중 계층 아키텍처에서 강제 병합을 트리거하지 않습니다. 필요한 경우 사용자는 인덱스 관리 정책을 사용하여 강제 병합을 조정할 수 있습니다.
+ 이제 웜 노드는 인덱싱 외에도 백그라운드 병합 작업(핫 노드와 유사)도 수행합니다.
+ 웜 인덱스에 대한 모든 검색 요청은 기본 샤드로 라우팅되며 복제본은 기본 샤드가 다운된 경우에만 읽기를 제공합니다.
+ 이 아키텍처에서는 웜 인덱스의 자동 스냅샷도 지원됩니다.
+ 클러스터 간 복제는 핫 인덱스에서만 지원됩니다.
+ 축소, 분할 및 복제와 같은 인덱스 APIs는 웜 인덱스에서 작동하지 않습니다.
### 다중 계층 도메인 생성
#### 1단계: 도메인 생성
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version OpenSearch_3.3 \
--cluster-config InstanceCount=3,InstanceType=or2.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3,WarmEnabled=true,WarmCount=3,WarmType=oi2.2xlarge.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":"user_name","MasterUserPassword":"your_pass"}}' \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":"*","Action":"es:*","Resource":"*"}]}' \
--region us-east-1
```
#### 2단계: 웜 노드 확인
```
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
```
샘플 응답(발췌):
```
{
"NodeType": "Warm",
"InstanceType": "oi2.large.search",
"NodeStatus": "Active"
}
```
### 티어 마이그레이션 관리
다중 계층 도메인 지원:
+ 간소화된 경험을 위한 새로운 계층화 APIs
+ 호환성을 위한 레거시 UltraWarm APIs
#### 새로운 계층화 APIs
**인덱스를 웜으로 마이그레이션합니다.**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
```
응답:
```
{"acknowledged": true}
```
**인덱스를 핫으로 마이그레이션:**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
```
응답:
```
{"acknowledged": true}
```
**계층화 상태 확인:**
```
curl -XGET 'https://localhost:9200/index-name/_tier'
```
응답 예제:
```
{
"tiering_status": {
"index": "index-name",
"state": "RUNNING_SHARD_RELOCATION",
"source": "HOT",
"target": "WARM",
"start_time": 1745836500563,
"shard_level_status": {
"running": 0,
"total": 100,
"pending": 100,
"succeeded": 0
}
}
}
```
**세부 샤드 보기:**
```
curl 'https://localhost:9200/index1/_tier?detailed=true'
```
**진행 중인 모든 마이그레이션 나열(텍스트):**
```
curl 'https://localhost:9200/_tier/all'
```
**진행 중인 마이그레이션(JSON)을 모두 나열합니다.**
```
curl 'https://localhost:9200/_tier/all?format=json'
```
**대상 계층을 기준으로 필터링:**
```
curl 'https://localhost:9200/_tier/all?target=_warm'
```
#### 호환성을 위한 레거시 UltraWarm APIs
**웜으로 마이그레이션:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
```
**핫으로 마이그레이션:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
```
**상태 확인:**
```
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
```
### 보안 구성
기존 Amazon OpenSearch Service 도메인에서 다중 계층 스토리지를 활성화하면 도메인에 `storage_tiering_manager` 역할이 정의되지 않을 수 있습니다. 관리자가 아닌 사용자는 이 역할에 매핑되어 세분화된 액세스 제어를 사용하는 도메인의 웜 인덱스를 관리해야 합니다. 수동으로 `storage_tiering_manager` 역할을 생성하려면 다음 단계를 수행합니다.
1. OpenSearch 대시보드에서 **보안(Security)**으로 이동하여 **권한(Permissions)**을 선택합니다.
1. **작업 그룹 생성(Create action group)**을 선택하고 다음 그룹을 구성합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/multi-tier-storage.html)
1. **역할(Roles)**과 **역할 생성(Create role)**을 차례로 선택합니다.
1. 역할 이름을 `storage_tiering_manager`로 지정합니다.
1. **클러스터 권한(Cluster permissions)**에서 `storage_tiering_cluster` 및 `cluster_monitor`를 선택합니다.
1. **인덱스(Index)**에 `*`를 입력합니다.
1. **인덱스 권한**에서 및 `storage_tiering_index_read``storage_tiering_index_write`를 선택합니다`indices_monitor`.
1. **생성(Create)**을 선택합니다.
1. 역할을 생성한 후 다중 계층 인덱스를 관리할 사용자 또는 백엔드 역할에 매핑합니다.
### 모범 사례
Amazon OpenSearch Service 도메인에서 다중 계층 스토리지를 구현할 때 다음 모범 사례를 고려하세요.
+ 데이터 액세스 패턴을 정기적으로 검토하여 계층 할당 최적화
+ 성능 지표를 모니터링하여 효율적인 리소스 사용률 보장
+ 새로운 계층화 APIs를 사용하여 데이터 마이그레이션을 세밀하게 제어
### 지표 모니터링
다중 계층 스토리지 도메인은 웜 티어 성능을 모니터링하기 위한 추가 지표를 제공합니다. 이러한 지표에는 기존 UltraWarm 지표와 OpenSearch 최적화 인스턴스 아키텍처와 관련된 새 지표가 모두 포함됩니다.
#### 새로운 지표
| 지표 이름 | 노드 수준 통계 | 클러스터 수준 통계 | 세부 수준 |
| --- | --- | --- | --- |
| WarmIndexingLatency | 평균 | 평균 | 1분 |
| WarmIndexingRate | 평균 | 평균, 최대, 합계 | 1분 |
| WarmThreadpoolIndexingQueue | 최대 | 합계, 최대값, 평균 | 1분 |
| WarmThreadpoolIndexingRejected | 최대 | Sum | 1분 |
| WarmThreadpoolIndexingThreads | 최대 | 합계, 평균 | 1분 |
# Amazon OpenSearch Service를 위한 UltraWarm 스토리지
UltraWarm은 대량의 읽기 전용 데이터를 Amazon OpenSearch Service에 저장하는 비용 효율적인 방법을 제공합니다. 표준 데이터 노드는 각 노드에 연결된 Amazon EBS 볼륨 또는 인스턴스 스토어의 형태를 취하는 “핫” 스토리지를 사용합니다. 핫 스토리지의 새로운 데이터 인덱싱 및 검색 성능이 가장 빠릅니다.
UltraWarm 노드는 연결된 스토리지가 아닌 Amazon S3와 정교한 캐싱 솔루션을 사용하여 성능을 향상시킵니다. 활발하게 사용하지 않고 쿼리 빈도가 낮으며 동일한 성능이 필요하지 않은 인덱스의 경우, UltraWarm은 GiB당 데이터 비용이 아주 저렴합니다. 웜 인덱스는 핫 스토리지로 되돌리지 않는 한 읽기 전용이므로 UltraWarm은 로그와 같은 변경 불가능한 데이터에 가장 적합합니다.
OpenSearch에서, 웜 인덱스는 다른 인덱스와 마찬가지로 작동합니다. 동일한 API를 사용하여 쿼리하거나, OpenSearch Dashboards에 시각화를 만드는 데 사용할 수 있습니다.
**Topics**
+ [사전 조건](#ultrawarm-pp)
+ [UltraWarm 스토리지 요구 사항 및 성능 고려 사항](#ultrawarm-calc)
+ [UltraWarm 가격](#ultrawarm-pricing)
+ [UltraWarm 활성화](#ultrawarm-enable)
+ [인덱스를 UltraWarm 스토리지로 마이그레이션](#ultrawarm-migrating)
+ [마이그레이션 자동화](#ultrawarm-ism)
+ [마이그레이션 조정](#ultrawarm-settings)
+ [마이그레이션 취소](#ultrawarm-cancel)
+ [핫 인덱스 및 웜 인덱스 나열](#ultrawarm-api)
+ [핫 스토리지로 웜 인덱스 되돌리기](#ultrawarm-migrating-back)
+ [스냅샷에서 웜 인덱스 복원](#ultrawarm-snapshot)
+ [웜 인덱스의 수동 스냅샷](#ultrawarm-manual-snapshot)
+ [콜드 스토리지로 웜 인덱스 마이그레이션](#ultrawarm-cold)
+ [KNN 인덱스 모범 사례](#ultrawarm-recommendations)
+ [UltraWarm 비활성화](#ultrawarm-disable)
## 사전 조건
UltraWarm에는 몇 가지 중요한 사전 조건이 있습니다.
+ UltraWarm을 사용하려면 OpenSearch 또는 Elasticsearch 6.8 이상이 필요합니다.
+ 웜 스토리지를 사용하려면 도메인에 [전용 프라이머리 노드](managedomains-dedicatedmasternodes.md)가 있어야 합니다.
+ [Multi-AZ with Standby](managedomains-multiaz.md#managedomains-za-standby) 도메인을 사용하는 경우 웜 노드 수는 사용 중인 가용 영역 수의 배수여야 합니다.
+ 도메인이 데이터 노드에 T2 또는 T3 인스턴스 유형을 사용하는 경우, 웜 스토리지를 사용할 수 없습니다.
+ 인덱스가 근사 k-NN(`"index.knn":true`)을 사용하는 경우 버전 2.17 이상에서 웜 스토리지로 이동할 수 있습니다. 2.17 이전 버전의 도메인은 2.17로 업그레이드하면 이 기능을 사용할 수 있지만, 2.x 이전 버전에서 생성된 KNN 인덱스는 UltraWarm으로 마이그레이션할 수 없습니다.
+ 도메인이 [세분화된 액세스 제어](fgac.md)를 사용하는 경우 사용자는 OpenSearch Dashboards에서 `ultrawarm_manager` 역할에 매핑하여 UltraWarm API를 직접 호출해야 합니다.
**참고**
`ultrawarm_manager` 역할이 일부 기존 OpenSearch Service 도메인에 정의되지 않을 수 있습니다. Dashboards에 역할이 보이지 않으면 [수동으로 생성](#ultrawarm-create-role)해야 합니다.
### 권한 구성
기존 OpenSearch Service 도메인에서 UltraWarm을 활성화한 경우 `ultrawarm_manager` 역할이 도메인에 정의되어 있지 않을 수 있습니다. 관리자가 아닌 사용자는 이 역할에 매핑되어 세분화된 액세스 제어를 사용하는 도메인의 웜 인덱스를 관리해야 합니다. 수동으로 `ultrawarm_manager` 역할을 생성하려면 다음 단계를 수행합니다.
1. OpenSearch 대시보드에서 **보안(Security)**으로 이동하여 **권한(Permissions)**을 선택합니다.
1. **작업 그룹 생성(Create action group)**을 선택하고 다음 그룹을 구성합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/ultrawarm.html)
1. **역할(Roles)**과 **역할 생성(Create role)**을 차례로 선택합니다.
1. 역할 이름을 **ultrawarm\$1manager**로 지정합니다.
1. **클러스터 권한(Cluster permissions)**에서 `ultrawarm_cluster` 및 `cluster_monitor`를 선택합니다.
1. **인덱스(Index)**에 `*`를 입력합니다.
1. **인덱스 권한(Index permissions)**에서 `ultrawarm_index_read`, `ultrawarm_index_write`, `indices_monitor`를 선택합니다.
1. **생성(Create)**을 선택합니다.
1. 역할을 생성한 후, UltraWarm 인덱스를 관리할 사용자 또는 백엔드 역할에 [매핑](fgac.md#fgac-mapping)합니다.
## UltraWarm 스토리지 요구 사항 및 성능 고려 사항
[스토리지 요구 사항 계산](bp-storage.md)에서 언급했듯이, 핫 스토리지의 데이터는 복제본, Linux 예약 공간 및 OpenSearch Service 예약 공간 등 상당한 오버헤드를 발생시킵니다. 예를 들어, 복제본 샤드가 1개인 20GiB 기본 샤드에는 약 58GiB의 핫 스토리지가 필요합니다.
UltraWarm은 Amazon S3를 사용하기 때문에 이러한 오버헤드를 발생시키지 않습니다. UltraWarm 스토리지 요구 사항을 계산할 때는 기본 샤드의 크기만 고려합니다. S3의 데이터 내구성 덕분에 복제본이 필요하지 않으며, S3는 운영 체제 또는 서비스 고려 사항을 추상화합니다. 동일한 20GiB 샤드에는 20GiB의 웜 스토리지가 필요합니다. `ultrawarm1.large.search` 인스턴스를 프로비저닝하는 경우, 기본 샤드에 최대 스토리지 20TiB를 모두 사용할 수 있습니다. 인스턴스 유형 요약과 각 인스턴스 유형이 사용할 수 있는 최대 스토리지 용량은 [UltraWarm 스토리지 할당량](limits.md#limits-ultrawarm) 섹션을 참조하세요.
UltraWarm의 경우, 권장하는 최대 샤드 크기는 50GiB입니다. [각 UltraWarm 인스턴스 유형에 할당된 CPU 코어 수 및 RAM 용량](#ultrawarm-pricing)은 동시에 검색 할 수 있는 샤드 수에 대한 정보를 제공합니다. 기본 샤드만 S3의 UltraWarm 스토리지에 포함되지만 OpenSearch Dashboards 및 `_cat/indices`는 여전히 UltraWarm 인덱스 크기를 모든 기본 및 복제 샤드의 *총합*으로 보고합니다.
예를 들어, 각 `ultrawarm1.medium.search` 인스턴스에는 2개의 CPU 코어가 있으며 S3에서 최대 1.5TiB 스토리지를 처리할 수 있습니다. 이러한 인스턴스 중 두 개에는 결합된 3TiB 스토리지가 있으며, 각 샤드가 50GiB인 경우 약 62개의 샤드로 작동합니다. 클러스터에 대한 요청이 이러한 샤드 중 네 개만 검색하는 경우 성능이 우수할 수 있습니다. 요청이 광범위하고 62개를 모두 검색하면 4개의 CPU 코어가 작업을 수행하는 데 어려움을 겪을 수 있습니다. 인스턴스가 워크로드를 처리하는 방법을 이해하기 위해 `WarmCPUUtilization` 및 `WarmJVMMemoryPressure` [UltraWarm 지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)를 모니터링합니다.
검색 범위가 넓거나 빈번한 경우 인덱스를 핫 스토리지에 남겨 두는 것이 좋습니다. 다른 OpenSearch 워크로드와 마찬가지로 요구에 맞는 UltraWarm을 판단하는 가장 중요한 단계는 실질적인 데이터 집합을 사용하여 대표적인 클라이언트 테스트를 수행하는 것입니다.
## UltraWarm 가격
핫 스토리지를 사용하면 프로비저닝하는 만큼 비용을 지불합니다. 연결된 Amazon EBS 볼륨이 필요한 인스턴스가 있는가 하면, 인스턴스 스토어가 포함되어 있는 인스턴스도 있습니다. 스토리지가 비어 있든 가득 차 있든, 동일한 가격을 지불합니다.
UltraWarm 스토리지를 사용하면 사용한 만큼만 비용을 지불합니다. `ultrawarm1.large.search` 인스턴스는 S3에서 최대 20TiB의 스토리지를 처리할 수 있지만, 1TiB의 데이터만 저장하는 경우 1TiB의 데이터에 해당하는 비용만 청구됩니다. 다른 모든 노드 유형과 마찬가지로, 각 UltraWarm 노드별 시간당 요금만 지불합니다. 자세한 내용은 [Amazon OpenSearch Service 요금](what-is.md#pricing) 섹션을 참조하세요.
## UltraWarm 활성화
콘솔은 웜 스토리지를 사용하는 도메인을 생성하는 가장 간단한 방법입니다. 도메인을 생성하는 동안 **웜 데이터 노드 활성화**를 선택한 다음, 원하는 웜 노드 수를 선택합니다. [사전 조건](#ultrawarm-pp)을 충족하는 경우 기존 도메인에서도 동일한 기본 프로세스가 적용됩니다. 도메인 상태가 **처리 중(Processing)**에서 **활성(Active)**으로 변경된 후에도 UltraWarm을 몇 시간 동안 사용하지 못할 수 있습니다.
Multi-AZ with Standby 도메인을 사용하는 경우 웜 노드 수는 가용 영역 수의 배수여야 합니다. 자세한 내용은 [Multi-AZ with Standby](managedomains-multiaz.md#managedomains-za-standby) 단원을 참조하십시오.
UltraWarm을 활성화하는 [AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html) 또는 [구성 API](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html), 특히 `ClusterConfig`의 `WarmEnabled`, `WarmCount`, `WarmType` 옵션을 사용할 수도 있습니다.
**참고**
도메인은 최대 수의 웜 노드를 지원합니다. 자세한 내용은 [Amazon OpenSearch Service 할당량](limits.md) 섹션을 참조하세요.
### 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 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/)를 참조하세요.
### 샘플 구성 API 요청
구성 API에 대한 다음 요청은 3개의 데이터 노드, 3개의 전용 프라이머리 노드, 세분화된 액세스 제어가 활성화되어 있고 제한적인 액세스 정책이 있는 6개의 웜 노드로 도메인을 생성합니다.
```
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 Service 참조](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)를 참조하세요.
## 인덱스를 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 Service는 한 번에 하나의 인덱스를 UltraWarm으로 마이그레이션합니다. 대기열에 최대 200번의 마이그레이션이 있을 수 있습니다. 한도를 초과하는 요청은 거부됩니다. 현재 대기열의 마이그레이션 번호를 확인하려면 `HotToWarmMigrationQueueSize` [지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)를 모니터링합니다. 인덱스는 마이그레이션 프로세스 전반에 걸쳐 계속 사용할 수 있으며 가동 중지 없이 사용할 수 있습니다.
마이그레이션 프로세스의 상태는 다음과 같습니다.
```
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"
}
}
}
}
}
}
```
+ 이 경우 `number_of_replicas`는 디스크 공간을 소비하지 않는 수동 복제본의 수입니다.
+ `routing.allocation.require.box_type`은 인덱스가 표준 데이터 노드가 아닌 웜 노드를 사용하도록 지정합니다.
+ `merge.policy.max_merge_at_once_explicit`는 마이그레이션 중에 동시에 병합할 세그먼트 수를 지정합니다.
웜 스토리지의 인덱스는 [핫 스토리지로 되돌리지](#ultrawarm-migrating-back) 않는 한 읽기 전용이므로 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의 인덱스 상태 관리](ism.md)을 사용하여 마이그레이션 프로세스를 자동화하는 것이 좋습니다. 이 워크플로를 보여주는 [샘플 정책](ism.md#ism-example-cold)을 참조하세요.
## 마이그레이션 조정
UltraWarm 스토리지로의 인덱스 마이그레이션에는 강제 병합이 필요합니다. 각 OpenSearch 인덱스는 몇 개의 샤드로 구성되며 각 샤드는 몇 개의 Lucene 세그먼트로 구성됩니다. 강제 병합 작업은 삭제하도록 표시된 문서를 소거하고 디스크 공간을 절약합니다. 기본적으로 UltraWarm은 인덱스를 하나의 세그먼트로 병합합니다. 단, 기본값 20이 사용되는 kNN 인덱스는 예외입니다.
`index.ultrawarm.migration.force_merge.max_num_segments` 설정을 사용하여 이 값을 최대 1,000개의 세그먼트까지 변경할 수 있습니다. 값이 높을수록 마이그레이션 프로세스 속도가 빨라지지만 마이그레이션이 완료된 후 웜 인덱스에 대한 쿼리 대기 시간이 늘어납니다. 설정을 변경하려면 다음과 같이 요청합니다.
```
PUT my-index/_settings
{
"index": {
"ultrawarm": {
"migration": {
"force_merge": {
"max_num_segments": 1
}
}
}
}
}
```
마이그레이션 프로세스의 이 단계에 걸리는 시간을 확인하려면`HotToWarmMigrationForceMergeLatency` [지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)를 모니터링합니다.
## 마이그레이션 취소
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 Service는 마이그레이션 요청을 대기열에 입력된 순서대로 한 번에 하나씩 처리합니다. 현재 번호를 확인하려면 `WarmToHotMigrationQueueSize` [지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)를 모니터링합니다.
마이그레이션을 완료한 후 인덱스 설정을 검토하여 요구 사항을 충족하는지 확인합니다. 인덱스가 하나의 복제본이 있는 핫 스토리지로 돌아갑니다.
## 스냅샷에서 웜 인덱스 복원
UltraWarm에는 자동 스냅샷용 표준 리포지토리 외에 웜 인덱스용 보조 리포지토리인 `cs-ultrawarm`이 추가됩니다. 이 리포지토리의 각 스냅샷에는 하나의 인덱스만 포함됩니다. 웜 인덱스를 삭제하면 해당 스냅샷은 다른 자동 스냅샷과 마찬가지로 14일 동안 `cs-ultrawarm` 리포지토리에 남아 있습니다.
`cs-ultrawarm`에서 스냅샷을 복원하면 핫 스토리지가 아닌 웜 스토리지로 복원됩니다. `cs-automated` 및 `cs-automated-enc` 리포지토리의 스냅샷은 핫 스토리지로 복원됩니다.
**UltraWarm 스냅샷을 웜 스토리지로 복원하려면**
1. 복원할 인덱스가 포함된 최신 스냅샷을 식별합니다.
```
GET _snapshot/cs-ultrawarm/_all?verbose=false
{
"snapshots": [{
"snapshot": "snapshot-name",
"version": "1.0",
"indices": [
"my-index"
]
}]
}
```
**참고**
기본적으로 `GET _snapshot/` 작업에는 리포지토리 내 각 스냅샷의 시작 시간, 종료 시간, 기간과 같은 자세한 데이터 정보가 표시됩니다. 이 `GET _snapshot/` 작업은 리포지토리에 포함된 각 스냅샷의 파일에서 정보를 검색합니다. 시작 시간, 종료 시간 및 기간이 필요하지 않고 스냅샷의 이름 및 인덱스 정보만 필요한 경우 스냅샷을 나열할 때 `verbose=false` 파라미터를 사용하여 처리 시간을 최소화하고 시간 초과를 방지하는 것이 좋습니다.
1. 인덱스가 이미 있는 경우 삭제합니다.
```
DELETE my-index
```
인덱스를 삭제하지 않으려면 [핫 스토리지로 돌아가](#ultrawarm-migrating-back) [재인덱스](https://docs.opensearch.org/latest/opensearch/reindex-data/)합니다.
1. 스냅샷을 복원합니다.
```
POST _snapshot/cs-ultrawarm/snapshot-name/_restore
```
UltraWarm은 이 복원 요청에서 지정한 인덱스 설정을 무시하지만 `rename_pattern` 및 `rename_replacement`와 같은 옵션을 지정할 수 있습니다. OpenSearch 스냅샷 복원 옵션에 대한 요약은 [OpenSearch 설명서](https://docs.opensearch.org/latest/opensearch/snapshot-restore/#restore-snapshots)를 참조하세요.
## 웜 인덱스의 수동 스냅샷
웜 인덱스의 수동 스냅 샷을 생성*할 수 있지만* 권장하지 않습니다. 마이그레이션 중에 생성한 각 웜 인덱스에 대한 스냅샷이 추가 비용 없이 자동 `cs-ultrawarm` 리포지토리에 이미 포함되어 있습니다.
기본적으로 OpenSearch Service는 수동 스냅샷에 웜 인덱스를 포함하지 않습니다. 예를 들어, 다음 호출에는 핫 인덱스만 포함됩니다.
```
PUT _snapshot/my-repository/my-snapshot
```
웜 인덱스의 수동 스냅샷을 생성하도록 선택하면 몇 가지 중요한 고려 사항이 적용됩니다.
+ 핫 인덱스와 웜 인덱스를 혼합할 수 없습니다. 예를 들어 다음 요청은 실패합니다.
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1,hot-index-1",
"include_global_state": false
}
```
핫 인덱스와 웜 인덱스의 혼합을 포함하는 경우, 와일드카드(`*`) 문도 실패합니다.
+ 스냅샷당 하나의 웜 인덱스만 포함할 수 있습니다. 예를 들어 다음 요청은 실패합니다.
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1,warm-index-2,other-warm-indices-*",
"include_global_state": false
}
```
이 요청이 성공한 경우:
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1",
"include_global_state": false
}
```
+ 수동 스냅샷은 원래 웜 인덱스가 포함된 경우에도 항상 핫 스토리지로 복원합니다.
## 콜드 스토리지로 웜 인덱스 마이그레이션
자주 쿼리하지 않는 UltraWarm에 데이터가 있는 경우 콜드 스토리지로 마이그레이션하는 것이 좋습니다. 콜드 스토리지는 가끔 액세스하거나 더 이상 사용하지 않는 데이터를 위한 것입니다. 콜드 인덱스에서 읽거나 쓸 수는 없지만 쿼리해야 할 때마다 무료로 웜 스토리지로 다시 마이그레이션 할 수 있습니다. 지침은 [콜드 스토리지로 인덱스 마이그레이션](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html#coldstorage-migrating)을 참조하세요.
## KNN 인덱스 모범 사례
+ Ultrawarm/Cold 티어는 모든 KNN 인덱스 엔진 유형에 사용할 수 있습니다. 그래프 데이터를 오프 힙 메모리에 완전히 로드할 필요가 없는 Lucene 엔진 및 디스크 최적화 벡터 검색을 사용하는 KNN 인덱스의 경우에 권장됩니다. FAISS 및 NMSLIB와 같은 네이티브 인 메모리 엔진과 함께 사용하는 경우, 능동적으로 검색할 샤드 그래프 크기를 고려하고 UltraWarm 인스턴스를 프로비저닝해야 하며, 이에 따라 가급적 `uw.large` 인스턴스 유형을 프로비저닝해야 합니다. 예를 들어 고객이 2개의 `uw.large` 인스턴스를 구성한 경우 각각 약 `knn.memory.circuit_breaker.limit * 61`GiB의 힙 외부 메모리를 사용할 수 있습니다. 누적 그래프 크기가 사용 가능한 오프 힙 메모리를 초과하지 않는 샤드를 대상으로 모든 웜 쿼리를 실행하면 최적의 성능을 얻을 수 있습니다. 제거 후 힙 외부 메모리를 사용할 수 있을 때까지 대기하기 때문에 사용 가능한 메모리가 그래프를 로드하는 데 필요한 것보다 적으면 지연 시간에 영향을 미칩니다. 따라서 인 메모리 엔진이 사용되는 사용 사례나 엔진에 관계없이 검색 처리량이 많은 사례에는 `uw.medium` 인스턴스를 사용하지 않는 것이 좋습니다.
+ UltraWarm으로 마이그레이션하는 KNN 인덱스는 단일 세그먼트로 강제 병합되지 않습니다. 이렇게 하면 그래프 크기가 인 메모리 엔진에 비해 너무 커지므로, OOM 문제로 실행되는 핫 노드와 웜 노드에 영향을 주지 않습니다. 샤드당 세그먼트 수가 증가하여 로컬 캐시 공간을 더 많이 사용하고 인덱스가 웜 티어로 마이그레이션되는 것을 줄일 수 있습니다. 기존 설정을 사용하고 인덱스를 웜 티어로 마이그레이션하기 전에 재정의하여 인덱스를 단일 세그먼트로 강제 병합하도록 선택할 수 있습니다. 자세한 내용은 [마이그레이션 조정](#ultrawarm-settings) 단원을 참조하십시오.
+ 인덱스가 자주 검색되지 않고 지연 시간에 민감한 워크로드를 제공하지 않는 사용 사례의 경우, 해당 인덱스를 UltraWarm 계층으로 마이그레이션하도록 선택할 수 있습니다. 이 경우 핫 티어 컴퓨팅 인스턴스를 스케일 다운하고 UltraWarm 티어 컴퓨팅이 이러한 낮은 우선순위의 인덱스에 대한 쿼리를 처리할 수 있습니다. 또한 우선순위가 낮은 인덱스와 높은 인덱스의 쿼리 간에 소비되는 리소스를 격리하여, 서로 영향을 미치지 않도록 하는 데 도움이 될 수 있습니다.
## UltraWarm 비활성화
콘솔은 UltraWarm을 비활성화하는 가장 간단한 방법입니다. 도메인을 선택하고 [**작업(Actions)**], [**클러스터 구성 편집(Edit cluster configuration)**]을 선택합니다. **웜 데이터 노드 활성화**를 선택 취소하고 **변경 사항 저장**을 선택합니다. AWS CLI 및 구성 API에서 `WarmEnabled` 옵션을 사용할 수도 있습니다.
UltraWarm을 사용 중지하기 전에 [모든 웜 인덱스를 삭제](https://opensearch.org/docs/latest/opensearch/rest-api/index-apis/delete-index/)하거나 [핫 스토리지로 다시 마이그레이션](#ultrawarm-migrating-back)해야 합니다. 웜 스토리지가 비어 있으면 5분 정도 기다린 후 UltraWarm을 사용 중지합니다.
# Amazon OpenSearch Service용 콜드 스토리지
콜드 스토리지를 사용하면 Amazon OpenSearch Service 도메인에 액세스 빈도가 낮은 데이터 또는 기록 데이터를 저장하고 필요에 따라 다른 스토리지 계층보다 저렴한 비용으로 분석할 수 있습니다. 콜드 스토리지는 오래된 데이터에 대한 정기적인 연구 또는 포렌식 분석을 수행해야 하는 경우에 적합합니다. 콜드 스토리지에 적합한 데이터의 실용적인 예로는 액세스 빈도가 낮은 로그, 규정 준수 요구 사항을 충족하기 위해 보존해야 하는 데이터 또는 기록 가치가 있는 로그가 있습니다.
[UltraWarm](ultrawarm.md)스토리지와 마찬가지로 콜드 스토리지는 Amazon S3 에서 지원됩니다. 콜드 데이터를 쿼리해야 하는 경우 기존 UltraWarm 노드에 선택적으로 연결할 수 있습니다. 수동으로 또는 인덱스 상태 관리 정책을 사용하여 콜드 데이터의 마이그레이션 및 수명 주기를 관리할 수 있습니다.
**Topics**
+ [사전 조건](#coldstorage-pp)
+ [콜드 스토리지 요구 사항 및 성능 고려 사항](#coldstorage-calc)
+ [콜드 스토리지 요금](#coldstorage-pricing)
+ [콜드 스토리지 활성화](#coldstorage-enable)
+ [OpenSearch Dashboards의 콜드 인덱스 관리](#coldstorage-dashboards)
+ [콜드 스토리지로 인덱스 마이그레이션](#coldstorage-migrating)
+ [콜드 스토리지로 마이그레이션 자동화](#coldstorage-ism)
+ [콜드 스토리지로의 마이그레이션 취소](#coldstorage-cancel)
+ [콜드 인덱스 목록 표시](#coldstorage-list)
+ [웜 스토리지로 콜드 인덱스 마이그레이션](#coldstorage-migrating-back)
+ [스냅샷에서 콜드 인덱스 복원](#cold-snapshot)
+ [콜드 스토리지에서 웜 스토리지로의 마이그레이션 취소](#coldtowarm-cancel)
+ [콜드 인덱스 메타데이터 업데이트](#cold-update-metadata)
+ [콜드 인덱스 삭제](#cold-delete)
+ [콜드 스토리지 비활성화](#coldstorage-disable)
## 사전 조건
콜드 스토리지에는 다음과 같은 사전 요구 사항이 있습니다.
+ 콜드 스토리지를 사용하려면 OpenSearch 또는 Elasticsearch 버전 7.9 이상이 필요합니다.
+ OpenSearch Service 도메인에서 콜드 스토리지를 활성화하려면 동일한 도메인에서 웜 스토리지도 활성화해야 합니다.
+ 콜드 스토리지를 사용하려면 도메인에 [전용 프라이머리 노드](managedomains-dedicatedmasternodes.md)가 있어야 합니다.
+ 도메인에서 데이터 노드에 T2 또는 T3 인스턴스 유형을 사용하는 경우, 콜드 스토리지를 사용할 수 없습니다.
+ 인덱스가 근사 k-NN(`"index.knn":true`)을 사용하는 경우 버전 2.17 이상에서 콜드 스토리지로 이동할 수 있습니다. 2.17 이전 버전의 도메인은 2.17로 업그레이드하면 이 기능을 사용할 수 있지만, 2.x 이전 버전에서 생성된 KNN 인덱스는 콜드로 마이그레이션할 수 없습니다.
+ 도메인에서 [세분화된 액세스 제어](fgac.md)를 사용하는 경우 관리자가 아닌 사용자는 OpenSearch Dashboards에서 `cold_manager` 역할에 [매핑되어](fgac.md#fgac-mapping) 콜드 인덱스를 관리해야 합니다.
**참고**
`cold_manager` 역할이 일부 기존 OpenSearch Service 도메인에 존재하지 않을 수 있습니다. Dashboards에 역할이 보이지 않으면 [수동으로 생성](#coldstorage-create-role)해야 합니다.
### 권한 구성
기존 OpenSearch Service 도메인에서 콜드 스토리지를 활성화한 경우 `cold_manager` 역할이 도메인에 정의되어 있지 않을 수 있습니다. 도메인에서 [세분화된 액세스 제어](fgac.md)를 사용하는 경우 관리자가 아닌 사용자는 이 역할에 매핑되어 콜드 인덱스를 관리해야 합니다. 수동으로 `cold_manager` 역할을 생성하려면 다음 단계를 수행합니다.
1. OpenSearch 대시보드에서 **보안(Security)**으로 이동하여 **권한(Permissions)**을 선택합니다.
1. **작업 그룹 생성(Create action group)**을 선택하고 다음 그룹을 구성합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/cold-storage.html)
1. **역할(Roles)**과 **역할 생성(Create role)**을 차례로 선택합니다.
1. 역할 이름을 **cold\$1manager**로 지정합니다.
1. **클러스터 권한(Cluster permissions)**의 경우 생성한 `cold_cluster` 그룹을 선택합니다.
1. **인덱스(Index)**에 `*`를 입력합니다.
1. **인덱스 권한(Index permissions)**의 경우 생성한 `cold_index` 그룹을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. 역할을 생성한 후, 콜드 인덱스를 관리하는 모든 사용자 또는 백엔드 역할에 [매핑](fgac.md#fgac-mapping)합니다.
## 콜드 스토리지 요구 사항 및 성능 고려 사항
콜드 스토리지는 Amazon S3를 사용하기 때문에 복제본, Linux 예약 공간 및 OpenSearch Service 예약 공간과 같은 핫 스토리지의 오버헤드가 발생하지 않습니다. 콜드 스토리지에는 컴퓨팅 용량이 연결되어 있지 않기 때문에 특정 인스턴스 유형이 없습니다. 콜드 스토리지에 원하는 양의 데이터를 저장할 수 있습니다. Amazon CloudWatch에서 `ColdStorageSpaceUtilization` 지표를 모니터링하여 사용 중인 콜드 스토리지 공간의 양을 확인할 수 있습니다.
## 콜드 스토리지 요금
UltraWarm 스토리지와 마찬가지로 콜드 스토리지를 사용하면 데이터 스토리지에 대해서만 비용을 지불합니다. 콜드 데이터에 대한 컴퓨팅 비용이 없으며 콜드 스토리지에 데이터가 없는 경우 요금이 청구되지 않습니다.
콜드 스토리지와 웜 스토리지 간에 데이터를 이동할 때 전송 요금이 발생하지 않습니다. 웜 스토리지와 콜드 스토리지 간에 인덱스를 마이그레이션하는 동안에는 인덱스 복사본 하나에 대해서만 비용을 계속 지불합니다. 마이그레이션이 완료되면 마이그레이션된 스토리지 계층에 따라 인덱스가 청구됩니다. 콜드 스토리지 요금에 대한 자세한 내용은 [Amazon OpenSearch Service 요금](https://aws.amazon.com/opensearch-service/pricing/)을 참조하세요.
## 콜드 스토리지 활성화
콘솔은 콜드 스토리지를 사용하는 도메인을 생성하는 가장 간단한 방법입니다. 도메인을 생성하는 중에 먼저 **웜 데이터 노드 활성화**를 선택합니다. 동일한 도메인에서 웜 스토리지를 활성화해야 하기 때문입니다. 그런 다음 **콜드 스토리지 활성화**를 선택합니다.
[사전 조건](#coldstorage-pp)을 충족하는 경우 기존 도메인에서도 동일한 프로세스가 적용됩니다. 도메인 상태가 **처리 중(Processing)**에서 **활성(Active)**으로 변경된 후에도 콜드 스토리지를 몇 시간 동안 사용하지 못할 수 있습니다.
[AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html) 또는 [구성 API](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)를 사용하여 콜드 스토리지를 활성화할 수도 있습니다.
### CLI 명령 예
다음 AWS CLI 명령은 데이터 노드 3개, 전용 마스터 노드 3개, 콜드 스토리지 활성화 및 세분화된 액세스 제어가 활성화된 도메인을 생성합니다.
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version Opensearch_1.0 \
--cluster-config ColdStorageOptions={Enabled=true},WarmEnabled=true,WarmCount=4,WarmType=ultrawarm1.medium.search,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,InstanceCount=3 \
--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}' \
--region us-east-2
```
자세한 내용은 [AWS CLI 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/)를 참조하세요.
### 샘플 구성 API 요청
구성 API에 대한 다음 요청은 3개의 데이터 노드, 3개의 전용 프라이머리 노드, 활성화된 콜드 스토리지 및 세분화된 액세스 제어가 활성화되어 있는 도메인을 생성합니다.
```
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": 4,
"WarmType": "ultrawarm1.medium.search",
"ColdStorageOptions": {
"Enabled": true
}
},
"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"
}
```
자세한 내용은 [Amazon OpenSearch Service 참조](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)를 참조하세요.
## OpenSearch Dashboards의 콜드 인덱스 관리
OpenSearch Service 도메인의 기존 Dashboards 인터페이스를 사용하여 핫 인덱스, 웜 인덱스 및 콜드 인덱스를 관리할 수 있습니다. Dashboards를 사용하면 CLI 또는 구성 API를 사용하지 않고도 웜 스토리지와 콜드 스토리지 간에 인덱스를 마이그레이션하고 인덱스 마이그레이션 상태를 모니터링할 수 있습니다. 자세한 내용은 [OpenSearch Dashboards의 인덱스 관리](dashboards.md#dashboards-indices)를 참조하세요.
## 콜드 스토리지로 인덱스 마이그레이션
콜드 스토리지로 인덱스를 마이그레이션하는 경우 데이터를 더욱 쉽게 검색할 수 있도록 시간 범위를 제공합니다. 인덱스의 데이터를 기반으로 타임스탬프 필드를 선택하거나, 시작 및 종료 타임스탬프를 수동으로 제공하거나, 타임스탬프를 지정하지 않도록 선택할 수 있습니다.
| 파라미터 | 지원되는 값 | 설명 |
| --- | --- | --- |
| timestamp\$1field | 인덱스 매핑의 날짜/시간 필드입니다. | 제공된 필드의 최솟값과 최댓값이 계산되어 콜드 인덱스에 대한 `start_time` 및 `end_time` 메타데이터로 저장됩니다. |
| start\$1time 및 end\$1time | 다음 형식 중 하나: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/cold-storage.html) | 제공된 값은 콜드 인덱스에 대한 `start_time` 및 `end_time` 메타데이터로 저장됩니다. |
타임 스탬프를 지정하지 않으려면 대신 `?ignore=timestamp`를 요청에 추가합니다.
다음 요청은 웜 인덱스를 콜드 스토리지로 마이그레이션하고 해당 인덱스의 데이터에 대한 시작 및 종료 시간을 제공합니다.
```
POST _ultrawarm/migration/my-index/_cold
{
"start_time": "2020-03-09",
"end_time": "2020-03-09T23:00:00Z"
}
```
그런 다음 마이그레이션 상태를 확인합니다.
```
GET _ultrawarm/migration/my-index/_status
{
"migration_status": {
"index": "my-index",
"state": "RUNNING_METADATA_RELOCATION",
"migration_type": "WARM_TO_COLD"
}
}
```
OpenSearch Service는 한 번에 하나의 인덱스를 콜드 스토리지로 마이그레이션합니다. 대기열에 최대 100번의 마이그레이션이 있을 수 있습니다. 한도를 초과하는 요청은 거부됩니다. 현재 대기열의 마이그레이션 번호를 확인하려면 `WarmToColdMigrationQueueSize` [지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage)를 모니터링합니다. 마이그레이션 프로세스의 상태는 다음과 같습니다.
```
ACCEPTED_COLD_MIGRATION - Migration request is accepted and queued.
RUNNING_METADATA_MIGRATION - The migration request was selected for execution and metadata is migrating to cold storage.
FAILED_METADATA_MIGRATION - The attempt to add index metadata has failed and all retries are exhausted.
PENDING_INDEX_DETACH - Index metadata migration to cold storage is completed. Preparing to detach the warm index state from the local cluster.
RUNNING_INDEX_DETACH - Local warm index state from the cluster is being removed. Upon success, the migration request will be completed.
FAILED_INDEX_DETACH - The index detach process failed and all retries are exhausted.
```
## 콜드 스토리지로 마이그레이션 자동화
인덱스가 특정 기간에 도달하거나 다른 조건을 충족한 후에는 [인덱스 상태 관리](ism.md)를 사용하여 마이그레이션 프로세스를 자동화할 수 있습니다. [샘플 정책](ism.md#ism-example-cold)을 참조하세요. 핫 스토리지에서 UltraWarm, 콜드 스토리지로 인덱스를 자동 마이그레이션하는 방법을 보여줍니다.
**참고**
명시적 `timestamp_field`은(는) 인덱스 상태 관리 정책을 사용하여 인덱스를 콜드 스토리지로 이동하는 데 필요합니다.
## 콜드 스토리지로의 마이그레이션 취소
콜드 스토리지로의 마이그레이션이 대기 중이거나 실패 상태인 경우 다음 요청을 사용하여 마이그레이션을 취소할 수 있습니다.
```
POST _ultrawarm/migration/_cancel/my-index
{
"acknowledged" : true
}
```
도메인에서 세분화된 액세스 제어를 사용하는 경우 이 요청을 하기 위해 `indices:admin/ultrawarm/migration/cancel` 권한이 필요합니다.
## 콜드 인덱스 목록 표시
쿼리하기 전에 콜드 스토리지에 인덱스를 나열하여 추가 분석을 위해 UltraWarm으로 마이그레이션할 인덱스를 결정할 수 있습니다. 다음 요청에는 인덱스 이름별로 정렬된 모든 콜드 인덱스가 나열됩니다.
```
GET _cold/indices/_search
```
**샘플 응답**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 3,
"indices" : [
{
"index" : "my-index-1",
"index_cold_uuid" : "hjEoh26mRRCFxRIMdgvLmg",
"size" : 10339,
"creation_date" : "2021-06-28T20:23:31.206Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-2",
"index_cold_uuid" : "0vIS2n-oROmOWDFmwFIgdw",
"size" : 6068,
"creation_date" : "2021-07-15T19:41:18.046Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-3",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
### 필터링
접두사 기반 인덱스 패턴 및 시간 범위 오프셋을 기반으로 콜드 인덱스를 필터링할 수 있습니다.
다음 요청은 `event-*`의 접두사 패턴과 일치하는 인덱스를 나열합니다.
```
GET _cold/indices/_search
{
"filters":{
"index_pattern": "event-*"
}
}
```
**샘플 응답**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "events-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
다음 요청은 `2019-03-01`\$1`2020-03-01`의 `start_time` 및 `end_time` 메타데이터 필드를 사용하여 인덱스를 반환합니다.
```
GET _cold/indices/_search
{
"filters": {
"time_range": {
"start_time": "2019-03-01",
"end_time": "2020-03-01"
}
}
}
```
**샘플 응답**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "my-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2019-05-09T00:00Z",
"end_time" : "2019-09-09T23:00Z"
}
]
}
```
### 정렬
인덱스 이름이나 크기와 같은 메타데이터 필드별로 콜드 인덱스를 정렬할 수 있습니다. 다음 요청은 크기별로 정렬된 모든 인덱스를 내림차순으로 나열합니다.
```
GET _cold/indices/_search
{
"sort_key": "size:desc"
}
```
**샘플 응답**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 5,
"indices" : [
{
"index" : "my-index-6",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-9",
"index_cold_uuid" : "mbD3ZRVDRI6ONqgEOsJyUA",
"size" : 57922,
"creation_date" : "2021-07-07T23:41:35.640Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-5",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
다른 유효한 정렬 키는`start_time:asc/desc`, `end_time:asc/desc`, `index_name:asc/desc`입니다.
### 페이지 매김
콜드 인덱스 목록을 페이지 매김할 수 있습니다. `page_size` 파라미터를 사용해 페이지당 반환될 인덱스 수를 구성합니다(기본값은 10). 콜드 인덱스에 대한 모든 `_search` 요청은 후속 호출에 사용할 수 있는 `pagination_id`을(를) 반환합니다.
다음 요청은 콜드 인덱스의 `_search` 요청 결과를 페이지 매김하고 다음 100개의 결과를 표시합니다.
```
GET _cold/indices/_search?page_size=100
{
"pagination_id": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY"
}
```
## 웜 스토리지로 콜드 인덱스 마이그레이션
이전 섹션의 필터링 기준을 적용해 콜드 인덱스 목록 범위를 좁힌 후, 데이터를 쿼리하고 이를 사용해 시각화를 생성할 수 있는 UltraWarm으로 다시 마이그레이션합니다.
다음 요청은 두 콜드 인덱스를 다시 웜 스토리지로 마이그레이션합니다.
```
POST _cold/migration/_warm
{
"indices": "my-index1,my-index2"
}
{
"acknowledged" : true
}
```
마이그레이션 상태를 확인하고 마이그레이션 ID를 검색하려면 다음 요청을 보냅니다.
```
GET _cold/migration/_status
```
**샘플 응답**
```
{
"cold_to_warm_migration_status" : [
{
"migration_id" : "tyLjXCA-S76zPQbPVHkOKA",
"indices" : [
"my-index1,my-index2"
],
"state" : "RUNNING_INDEX_CREATION"
}
]
}
```
인덱스 관련 마이그레이션 정보를 가져오려면 인덱스 이름을 포함하세요.
```
GET _cold/migration/my-index/_status
```
인덱스를 지정하는 대신 현재 마이그레이션 상태별로 인덱스를 나열할 수 있습니다. 유효한 값은 `_failed`, `_accepted`, `_all`입니다.
다음 명령은 단일 마이그레이션 요청에서 모든 인덱스의 상태를 가져옵니다.
```
GET _cold/migration/_status?migration_id=my-migration-id
```
상태 요청을 사용하여 마이그레이션 ID를 검색합니다. 자세한 마이그레이션 정보를 보려면 `&verbose=true`를 추가합니다.
최대 100개의 지표를 동시에 마이그레이션하여 콜드 스토리지에서 웜 스토리지로 인덱스를 10개 이하의 배치에 마이그레이션할 수 있습니다. 한도를 초과하는 요청은 거부됩니다. 현재 수행하고 있는 마이그레이션 번호를 확인하려면 `ColdToWarmMigrationQueueSize` [지표](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage)를 모니터링합니다. 마이그레이션 프로세스의 상태는 다음과 같습니다.
```
ACCEPTED_MIGRATION_REQUEST - Migration request is accepted and queued.
RUNNING_INDEX_CREATION - Migration request is picked up for processing and will create warm indexes in the cluster.
PENDING_COLD_METADATA_CLEANUP - Warm index is created and the migration service will attempt to clean up cold metadata.
RUNNING_COLD_METADATA_CLEANUP - Cleaning up cold metadata from the indexes migrated to warm storage.
FAILED_COLD_METADATA_CLEANUP - Failed to clean up metadata in the cold tier.
FAILED_INDEX_CREATION - Failed to create an index in the warm tier.
```
## 스냅샷에서 콜드 인덱스 복원
삭제된 콜드 인덱스를 복원해야 하는 경우 [스냅샷에서 웜 인덱스 복원](ultrawarm.md#ultrawarm-snapshot)의 지침에 따라 다시 웜 티어로 복원한 다음 인덱스를 다시 콜드 티어로 마이그레이션하면 됩니다. 삭제된 콜드 인덱스를 콜드 티어에 직접 복원할 수는 없습니다. OpenSearch Service는 콜드 인덱스를 삭제한 후 14일 동안 유지합니다.
## 콜드 스토리지에서 웜 스토리지로의 마이그레이션 취소
콜드 스토리지에서 웜 스토리지로의 인덱스 마이그레이션이 대기 중이거나 실패 상태인 경우 다음 요청으로 취소할 수 있습니다.
```
POST _cold/migration/my-index/_cancel
{
"acknowledged" : true
}
```
인덱스 배치에 대한 마이그레이션을 취소하려면(한 번에 최대 10개) 마이그레이션 ID를 지정합니다.
```
POST _cold/migration/_cancel?migration_id=my-migration-id
{
"acknowledged" : true
}
```
상태 요청을 사용하여 마이그레이션 ID를 검색합니다.
## 콜드 인덱스 메타데이터 업데이트
콜드 인덱스에 대한 `start_time` 및 `end_time` 필드를 업데이트할 수 있습니다.
```
PATCH _cold/my-index
{
"start_time": "2020-01-01",
"end_time": "2020-02-01"
}
```
콜드 스토리지에 있는 인덱스의 `timestamp_field`를 업데이트할 수 없습니다.
**참고**
OpenSearch Dashboards는 PATCH 메서드를 지원하지 않습니다. [curl](https://curl.haxx.se/), [Postman](https://www.getpostman.com/) 또는 다른 메서드를 사용하여 콜드 메타데이터를 업데이트합니다.
## 콜드 인덱스 삭제
ISM 정책을 사용하지 않는 경우 콜드 인덱스를 수동으로 삭제할 수 있습니다. 다음 요청은 콜드 인덱스를 삭제합니다.
```
DELETE _cold/my-index
{
"acknowledged" : true
}
```
## 콜드 스토리지 비활성화
OpenSearch Service 콘솔은 콜드 스토리지를 비활성화하는 가장 간단한 방법입니다. 도메인을 선택하고 [**작업(Actions)**], [**클러스터 구성 편집(Edit cluster configuration)**]을 선택한 다음 [**콜드 스토리지 사용(Enable cold storage)**]을 선택 취소합니다.
AWS CLI 또는 구성 API를 사용하려면 아래에서를 `ColdStorageOptions`설정합니다`"Enabled"="false"`.
콜드 스토리지를 비활성화하기 전에 모든 콜드 인덱스를 삭제하거나 웜 스토리지로 다시 마이그레이션해야 합니다. 그렇지 않으면 비활성화 작업이 실패합니다.
# Amazon OpenSearch Service의 인덱스 상태 관리
Amazon OpenSearch Service에서 인덱스 상태 관리(ISM)를 사용하면 주기적으로 수행되는 태스크를 자동화하도록 고객 관리형 정책을 정의하고 해당 정책을 인덱스와 인덱스 패턴에 적용할 수 있습니다. 인덱스 작업을 실행하기 위해 더 이상 외부 프로세스를 설정하고 관리할 필요가 없습니다.
정책에는 기본 상태와 인덱스 전환에 사용할 수 있는 상태 목록이 포함되어 있습니다. 각 상태 내에서 수행할 작업 목록과 이러한 전환을 트리거할 조건을 정의할 수 있습니다. 일반적인 사용 사례는 일정 기간 후에 오래된 인덱스를 주기적으로 삭제하는 것입니다. 예를 들어 인덱스를 30일 후에 `read_only` 상태로 이동한 다음 90일 후에 삭제하는 정책을 정의할 수 있습니다.
정책을 인덱스에 연결하면 ISM은 5\$18분(또는 1.3 이전 클러스터의 경우 30\$148분)마다 실행되는 작업을 생성하여 정책 작업을 수행하고 조건을 확인하며 인덱스를 다른 상태로 전환합니다. 이 작업을 실행하는 기본 시간은 5분마다 임의의 0\$160% 지터가 추가되어 모든 인덱스에서 동시에 활동이 급증하지 않도록 합니다. 클러스터 상태가 빨간색이면 ISM이 작업을 실행하지 않습니다.
ISM에는 OpenSearch 또는 Elasticsearch 6.8 이상이 필요합니다.
**참고**
이 설명서에서는 ISM 및 여러 샘플 정책에 대한 간략한 개요를 제공합니다. 또한 Amazon OpenSearch Service 도메인의 ISM과 자체 관리형 OpenSearch 클러스터의 ISM의 차이를 설명합니다. 포괄적인 파라미터 참조, 각 설정에 대한 설명 및 API 참조를 포함한 ISM에 대한 전체 설명서는 OpenSearch 설명서의 [Index State Management](https://docs.opensearch.org/latest/im-plugin/ism/index/)를 참조하세요.
**중요**
더 이상 인덱스 템플릿을 사용하여 새로 생성된 인덱스에 ISM 정책을 적용할 수 없습니다. [ISM 템플릿 필드](https://opensearch.org/docs/latest/im-plugin/ism/policies/#sample-policy-with-ism-template-for-auto-rollover)에서 새로 생성된 인덱스를 계속해서 자동으로 관리할 수 있습니다. 이 업데이트에서는 이 설정을 사용하여 기존 CloudFormation 템플릿에 영향을 주는 주요 변경 사항을 소개합니다.
## ISM 정책 생성
**인덱스 상태 관리를 시작하려면**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) Amazon OpenSearch Service 콘솔을 엽니다.
1. ISM 정책을 생성하려는 도메인을 선택합니다.
1. 도메인의 대시보드에서 OpenSearch 대시보드 URL로 이동하여 마스터 사용자 이름과 암호로 로그인합니다. URL은 다음 형식을 따릅니다.
```
domain-endpoint/_dashboards/
```
1. OpenSearch 대시보드에서 왼쪽 탐색 창을 열고 **인덱스 관리(Index Management)**를 선택한 다음 **정책 생성(Create policy)**을 선택합니다.
1. [시각적 편집기](https://opensearch.org/docs/latest/im-plugin/ism/index/#visual-editor) 또는 [JSON 편집기](https://opensearch.org/docs/latest/im-plugin/ism/index/#json-editor)를 사용하여 정책을 생성합니다. 시각적 편집기는 보다 체계적인 정책 정의 방법을 제공하므로 사용하는 것이 좋습니다. 정책 생성에 도움을 받으려면 아래 [샘플 정책](#ism-example)을 참조하세요.
1. 정책을 생성한 후 하나 이상의 인덱스에 연결합니다.
```
POST _plugins/_ism/add/my-index
{
"policy_id": "my-policy-id"
}
```
**참고**
도메인에서 레거시 Elasticsearch 버전을 실행 중인 경우, `_plugins` 대신 `_opendistro`를 사용하세요.
또는 OpenSearch Dashboards에서 인덱스를 선택하고 **정책 적용(Apply policy)**을 선택합니다.
## 샘플 정책
다음 샘플 정책은 일반 ISM 사용 사례를 자동화하는 방법을 보여줍니다.
### 핫 스토리지, 웜 스토리지, 콜드 스토리지
이 샘플 정책은 인덱스를 핫 스토리지에서 [UltraWarm](ultrawarm.md), 그리고 결국 [콜드 스토리지](cold-storage.md)로 이동합니다. 그런 다음 인덱스를 삭제합니다.
인덱스는 처음에 `hot` 상태입니다. 10일 후 ISM이 인덱스를 `warm` 상태로 전환하고 80일 후, 인덱스가 90일을 경과한 후에는 ISM이 인덱스를 `cold` 상태로 전환합니다. 1년 후, 서비스는 인덱스가 삭제 중이라는 알림을 Amazon Chime 공간에 보낸 다음 영구적으로 삭제합니다.
콜드 인덱스는 정상 `cold_delete` 작업이 아닌 `delete` 작업이 필요합니다. 또한 명시적 `timestamp_field`은(는) ISM으로 콜드 인덱스를 관리하기 위해 데이터에 필요합니다.
```
{
"policy": {
"description": "Demonstrate a hot-warm-cold-delete workflow.",
"default_state": "hot",
"schema_version": 1,
"states": [{
"name": "hot",
"actions": [],
"transitions": [{
"state_name": "warm",
"conditions": {
"min_index_age": "10d"
}
}]
},
{
"name": "warm",
"actions": [{
"warm_migration": {},
"retry": {
"count": 5,
"delay": "1h"
}
}],
"transitions": [{
"state_name": "cold",
"conditions": {
"min_index_age": "90d"
}
}]
},
{
"name": "cold",
"actions": [{
"cold_migration": {
"timestamp_field": ""
}
}
],
"transitions": [{
"state_name": "delete",
"conditions": {
"min_index_age": "365d"
}
}]
},
{
"name": "delete",
"actions": [{
"notification": {
"destination": {
"chime": {
"url": ""
}
},
"message_template": {
"source": "The index {{ctx.index}} is being deleted."
}
}
},
{
"cold_delete": {}
}]
}
]
}
}
```
### 복제본 수 감소
이 샘플 정책은 7일 후에 복제본 수를 0으로 줄여 디스크 공간을 절약한 다음, 21일 후에 인덱스를 삭제합니다. 이 정책은 인덱스가 중요하지 않으며 더 이상 쓰기 요청을 수신하지 않는다고 가정합니다. 복제본 수가 0이면 데이터 손실의 위험이 있습니다.
```
{
"policy": {
"description": "Changes replica count and deletes.",
"schema_version": 1,
"default_state": "current",
"states": [{
"name": "current",
"actions": [],
"transitions": [{
"state_name": "old",
"conditions": {
"min_index_age": "7d"
}
}]
},
{
"name": "old",
"actions": [{
"replica_count": {
"number_of_replicas": 0
}
}],
"transitions": [{
"state_name": "delete",
"conditions": {
"min_index_age": "21d"
}
}]
},
{
"name": "delete",
"actions": [{
"delete": {}
}],
"transitions": []
}
]
}
}
```
### 인덱스 스냅샷 생성
이 샘플 정책은 `[snapshot](https://docs.opensearch.org/latest/im-plugin/ism/policies/#snapshot)` 작업을 사용하여 하나 이상의 문서가 포함된 즉시 인덱스의 스냅샷을 생성할 수 있습니다. `repository`는 Amazon S3를 등록한 수동 스냅샷 리포지토리의 이름입니다. `snapshot`은 스냅샷의 이름입니다. 리포지토리를 등록하기 위한 스냅샷 사전 요구 사항 및 단계는 [Amazon OpenSearch Service에서 인덱스 스냅샷 생성](managedomains-snapshots.md) 섹션을 참조하세요.
```
{
"policy": {
"description": "Takes an index snapshot.",
"schema_version": 1,
"default_state": "empty",
"states": [{
"name": "empty",
"actions": [],
"transitions": [{
"state_name": "occupied",
"conditions": {
"min_doc_count": 1
}
}]
},
{
"name": "occupied",
"actions": [{
"snapshot": {
"repository": "",
"snapshot": ""
}
}],
"transitions": []
}
]
}
}
```
## ISM 템플릿
템플릿 패턴과 일치하는 인덱스를 생성할 때 정책이 해당 인덱스에 자동으로 연결되도록 정책에 `ism_template` 필드를 설정할 수 있습니다. 이 예제에서 “log”로 시작하는 이름으로 만든 인덱스는 ISM 정책 `my-policy-id`와 자동으로 일치됩니다.
```
PUT _plugins/_ism/policies/my-policy-id
{
"policy": {
"description": "Example policy.",
"default_state": "...",
"states": [...],
"ism_template": {
"index_patterns": ["log*"],
"priority": 100
}
}
}
```
자세한 예제는 [Sample policy with ISM template for auto rollover](https://opensearch.org/docs/latest/im-plugin/ism/policies/#sample-policy-with-ism-template-for-auto-rollover)(자동 롤오버를 위한 ISM 템플릿을 사용한 샘플 정책)을 참조하세요.
## 차이
OpenSearch 및 Elasticsearch와 비교할 때 Amazon OpenSearch Service의 ISM은 몇 가지 차이점이 있습니다.
### ISM 작업
+ OpenSearch Service는 세 가지 고유한 ISM 작업인 `warm_migration`, `cold_migration`, `cold_delete`을(를) 지원합니다.
+ 도메인에 [UltraWarm](ultrawarm.md)이 활성화된 경우 `warm_migration` 작업을 수행하면 인덱스가 웜 스토리지로 전환됩니다.
+ 도메인에 [콜드 스토리지](cold-storage.md)가 활성화된 경우, `cold_migration` 작업은 인덱스를 콜드 스토리지로 전환하고 `cold_delete` 작업은 콜드 스토리지에서 인덱스를 삭제합니다.
이러한 작업이 [설정된 제한 시간](https://docs.opensearch.org/latest/im-plugin/ism/policies/#actions) 내에 완료되지 않더라도 인덱스 마이그레이션 또는 삭제는 여전히 계속됩니다. 위의 작업 중 하나에 대해 [error\$1notification](https://opensearch.org/docs/latest/im-plugin/ism/policies/#error-notifications)을 설정하면 시간 초과 기간 내에 완료되지 않은 경우 작업이 실패했음을 알립니다. 단, 알림은 참조용입니다. 실제 작업에는 고유한 제한 시간이 없으며 결국 성공 또는 실패할 때까지 계속 실행됩니다.
+ 도메인에서 OpenSearch 또는 Elasticsearch 7.4 이상을 실행하는 경우, OpenSearch Service는 ISM `open` 및 `close` 작업을 지원합니다.
+ 도메인에서 OpenSearch 또는 Elasticsearch 7.7 이상을 실행하는 경우, OpenSearch Service는 ISM `snapshot` 작업을 지원합니다.
### 콜드 스토리지 ISM 작업
콜드 인덱스의 경우 다음과 같은 ISM API를 사용할 때 `?type=_cold` 파라미터를 지정해야 합니다.
+ [정책 추가](https://opensearch.org/docs/latest/im-plugin/ism/api/#add-policy)
+ [정책 제거](https://opensearch.org/docs/latest/im-plugin/ism/api/#remove-policy-from-index)
+ [업데이트 정책](https://opensearch.org/docs/latest/im-plugin/ism/api/#update-policy)
+ [실패한 인덱스 재시도](https://opensearch.org/docs/latest/im-plugin/ism/api/#retry-failed-index)
+ [인덱스 설명](https://opensearch.org/docs/latest/im-plugin/ism/api/#explain-index)
콜드 인덱스에 대한 이러한 API에는 다음과 같은 추가 차이점이 있습니다.
+ 와일드카드 연산자는 끝에서 사용할 때를 제외하고는 지원되지 않습니다. 예를 들어, `_plugins/_ism//logstash-*`는 지원되지만 `_plugins/_ism//iad-*-prod`는 지원되지 않습니다.
+ 여러 인덱스 이름 및 패턴을 지원하지 않습니다. 예를 들어, `_plugins/_ism//app-logs`는 지원되지만 `_plugins/_ism//app-logs,sample-data`는 지원되지 않습니다.
### ISM 설정
OpenSearch 및 Elasticsearch에서는 `_cluster/settings` API를 사용하여 이용 가능한 모든 ISM 설정을 변경할 수 있습니다. Amazon OpenSearch Service에서는 다음 [ISM 설정](https://opensearch.org/docs/latest/im-plugin/ism/settings/)만 변경할 수 있습니다.
+ **클러스터 수준 설정:**
+ `plugins.index_state_management.enabled`
+ `plugins.index_state_management.history.enabled`
+ **인덱스 수준 설정:**
+ `plugins.index_state_management.rollover_alias`
# 자습서: 인덱스 상태 관리 프로세스 자동화
이 자습서에서는 주기적으로 수행되는 인덱스 관리 태스크를 자동화하고 인덱스와 인덱스 패턴에 적용하는 ISM 정책을 구현하는 방법을 보여줍니다.
Amazon OpenSearch Service의 [인덱스 상태 관리(ISM)](ism.md)를 사용하면 반복적인 인덱스 관리 활동을 자동화할 수 있으므로 인덱스 수명 주기를 관리하기 위해 추가 도구를 사용하지 않아도 됩니다. Amazon OpenSearch Service 도메인 내에서 인덱스 기간, 크기 및 기타 조건을 기반으로 이러한 작업을 자동화하는 정책을 생성할 수 있습니다.
OpenSearch Service는 활성 쓰기 및 지연 시간이 짧은 분석을 위한 기본 '핫' 상태, 최대 3페타바이트의 읽기 전용 데이터를 위한 UltraWarm, 무제한 장기 보관을 위한 콜드 스토리지의 세 가지 스토리지 계층을 지원합니다.
이 자습서에서는 일별 인덱스에서 시계열 데이터를 처리하는 샘플 사용 사례를 제공합니다. 이 자습서에서는 24시간 후에 연결된 각 인덱스의 자동 스냅샷을 생성하는 정책을 설정합니다. 그런 다음 2일 후에 기본 핫 상태에서 UltraWarm 스토리지로, 30일 후에 콜드 스토리지로 인덱스를 마이그레이션하고, 마지막으로 60일 후에 인덱스를 삭제합니다.
## 사전 조건
+ OpenSearch Service 도메인은 Elasticsearch 버전 6.8 이상을 실행해야 합니다.
+ 도메인에 [UltraWarm](ultrawarm.md)과 [콜드 스토리지](cold-storage.md)가 활성화되어 있어야 합니다.
+ 도메인에 대한 [수동 스냅샷 리포지토리를 등록](managedomains-snapshot-registerdirectory.md)해야 합니다.
+ 사용자 역할에는 OpenSearch Service 콘솔에 액세스할 수 있는 충분한 권한이 필요합니다. 필요한 경우 [도메인에 대한 액세스를 구성](ac.md)하고 검증합니다.
## 1단계: ISM 정책 구성
먼저 OpenSearch Dashboards에서 ISM 정책을 구성합니다.
1. OpenSearch Service 콘솔의 도메인 대시보드에서 OpenSearch 대시보드 URL로 이동하여 마스터 사용자 이름과 암호로 로그인합니다. URL은 `domain-endpoint/_dashboards/` 형식입니다.
1. OpenSearch Dashboards에서 **Add sample data**(샘플 데이터 추가)를 선택하고 하나 이상의 샘플 인덱스를 도메인에 추가합니다.
1. 왼쪽 탐색 패널을 열고 **Index Management**(인덱스 관리)를 선택한 다음 **Create policy**(정책 생성)를 선택합니다.
1. 정책 이름을 `ism-policy-example`로 지정합니다.
1. 기본 정책을 다음과 같은 정책으로 바꿉니다.
```
{
"policy": {
"description": "Move indexes between storage tiers",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "snapshot",
"conditions": {
"min_index_age": "24h"
}
}
]
},
{
"name": "snapshot",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "30m"
},
"snapshot": {
"repository": "snapshot-repo",
"snapshot": "ism-snapshot"
}
}
],
"transitions": [
{
"state_name": "warm",
"conditions": {
"min_index_age": "2d"
}
}
]
},
{
"name": "warm",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"warm_migration": {}
}
],
"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "30d"
}
}
]
},
{
"name": "cold",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"cold_migration": {
"start_time": null,
"end_time": null,
"timestamp_field": "@timestamp",
"ignore": "none"
}
}
],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "60d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"cold_delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"index-*"
],
"priority": 100
}
]
}
}
```
**참고**
`ism_template` 필드는 지정된 `index_patterns` 중 하나와 일치하는 새로 생성된 인덱스에 정책을 자동으로 연결합니다. 이 경우 `index-`로 시작하는 모든 인덱스입니다. 사용자 환경의 인덱스 형식과 일치하도록 이 필드를 수정할 수 있습니다. 자세한 내용은 [ISM 템플릿](ism.md#ism-template)을 참조하세요.
1. 정책의 `snapshot` 섹션에서 `snapshot-repo`를 도메인에 등록한 [스냅샷 리포지토리](managedomains-snapshot-registerdirectory.md)의 이름으로 바꿉니다. 필요에 따라 `ism-snapshot`을 바꿀 수도 있습니다. 이는 스냅샷 생성 시 스냅샷의 이름이 됩니다.
1. **생성(Create)**을 선택합니다. 정책이 이제 **State management policies**(상태 관리 정책) 페이지에 표시됩니다.
## 2단계: 하나 이상의 인덱스에 정책 연결
생성한 정책을 클러스터에 있는 하나 이상의 인덱스에 연결합니다.
1. **Hot indicies**(핫 인덱스) 탭으로 이동하고 `opensearch_dashboards_sample`을 검색합니다. 1단계에서 추가한 모든 샘플 인덱스가 나열됩니다.
1. 모든 인덱스를 선택하고 **Apply policy**(정책 적용)를 선택한 다음 방금 생성한 **ism-policy-example** 정책을 선택합니다.
1. **적용**을 선택합니다.
**Policy managed indices**(정책 관리형 인덱스) 페이지에서 다양한 상태로 전환되는 인덱스를 모니터링할 수 있습니다.
# 인덱스 롤업을 사용하여 Amazon OpenSearch Service의 인덱스 요약
Amazon OpenSearch Service의 인덱스 롤업을 사용하면 오래된 데이터를 요약 인덱스로 주기적으로 롤업하여 스토리지 비용을 절감할 수 있습니다.
관심 있는 필드를 선택하고 인덱스 롤업을 사용하여 해당 필드만 대략적인 시간 버킷으로 집계된 새 인덱스를 생성합니다. 동일한 쿼리 성능으로 몇 달 또는 몇 년 동안의 기록 데이터를 훨씬 적은 비용으로 저장할 수 있습니다.
인덱스 롤업에는 OpenSearch 또는 Elasticsearch 7.9 이상이 필요합니다.
**참고**
이 설명서는 Amazon OpenSearch Service에서 인덱스 롤업 작업 생성을 시작하는 데 도움이 됩니다. 사용 가능한 모든 설정 목록과 전체 API 참조를 포함한 포괄적인 설명서는 OpenSearch 설명서의 [Index rollups](https://docs.opensearch.org/latest/im-plugin/index-rollups/)를 참조하세요.
## 인덱스 롤업 작업 생성
시작하려면 OpenSearch Dashboards에서 **인덱스 관리(Index Management)**를 선택합니다. **롤업 작업(Rollup Jobs)**을 선택하고 **롤업 작업 생성(Create rollup job)**을 선택합니다.
### 1단계: 인덱스 설정
소스 및 대상 인덱스를 설정합니다. 소스 인덱스는 롤업하려는 인덱스입니다. 대상 인덱스는 인덱스 롤업 결과가 저장되는 위치입니다.
인덱스 롤업 작업을 생성한 후에는 인덱스 선택을 변경할 수 없습니다.
### 2단계: 집계 및 지표 정의
롤업할 집계(용어 및 히스토그램) 및 지표(평균, 합계, 최대, 최소 및 값 개수)가 포함된 특성을 선택합니다. 많은 공간을 절약할 수 없으므로 매우 세분화된 속성을 많이 추가하지 않습니다.
### 3단계: 일정 지정
인덱스가 수집될 때 인덱스를 롤업할 일정을 지정합니다. 인덱스 롤업 작업은 기본적으로 활성화됩니다.
### 4단계: 검토 및 생성
구성을 검토하고 **생성(Create)**을 선택합니다.
### 5단계: 대상 인덱스 검색
표준 `_search` API를 사용하여 대상 인덱스를 검색할 수 있습니다. 플러그인이 백그라운드에서 대상 인덱스에 맞게 쿼리를 자동으로 다시 작성하므로 대상 인덱스 데이터의 내부 구조에 액세스할 수 없습니다. 이것은 소스 및 대상 인덱스에 대해 동일한 쿼리를 사용할 수 있도록 하기 위한 것입니다.
대상 인덱스를 쿼리하려면 `size`를 0으로 설정합니다.
```
GET target_index/_search
{
"size": 0,
"query": {
"match_all": {}
},
"aggs": {
"avg_cpu": {
"avg": {
"field": "cpu_usage"
}
}
}
}
```
**참고**
OpenSearch 버전 2.2 및 이후 버전에서는 한 번의 요청으로 여러 롤업 인덱스를 검색할 수 있습니다. 2.2 이전의 OpenSearch 버전과 레거시 Elasticsearch OSS 버전은 검색당 하나의 롤업 인덱스만 지원합니다.
# Amazon OpenSearch Service에서 인덱스 변환
[인덱스 롤업 작업](rollup.md)을 사용하면 이전 데이터를 압축된 인덱스로 롤업하여 데이터 세부 수준을 줄일 수 있으며 변환 작업을 통해 특정 필드를 중심으로 데이터의 다른 요약 보기를 만들 수 있으므로 데이터를 여러 가지 방법으로 시각화하거나 분석할 수 있습니다.
인덱스 변환에는 OpenSearch 대시보드 사용자 인터페이스와 REST API가 있습니다. 이 기능을 사용하려면 OpenSearch 1.0 이상이 필요합니다.
**참고**
이 설명서에서는 Amazon OpenSearch Service 도메인에서 인덱스 변환을 시작하는 데 도움이 되는 인덱스 변환에 대한 간략한 개요를 제공합니다. 포괄적인 설명서 및 REST API 참조는 오픈 소스 OpenSearch 설명서의 [Index transforms](https://docs.opensearch.org/latest/im-plugin/index-transforms/)를 참조하세요.
## 인덱스 변환 작업 만들기
클러스터에 데이터가 없는 경우 OpenSearch Dashboards에서 샘플 비행 데이터를 사용하여 변환 작업을 시도합니다. 데이터를 추가한 후 OpenSearch Dashboards를 시작합니다. 그런 다음 **인덱스 관리(Index Management)**, **변환 작업(Transform Jobs)**, **변환 작업 생성(Create Transform Job)**을 차례로 선택합니다.
### 1단계: 인덱스 선택
**인덱스(Indices)** 섹션에서 소스 및 대상 인덱스를 선택합니다. 기존 대상 인덱스를 선택하거나 이름을 입력하여 새 대상 인덱스를 생성할 수 있습니다.
소스 인덱스의 하위 집합만 변환하려면 **데이터 필터 추가(Add Data Filter)**를 선택하고 OpenSearch [쿼리 DSL](https://docs.opensearch.org/latest/opensearch/query-dsl/)을 사용하여 소스 인덱스의 하위 집합을 지정합니다.
### 2단계: 필드 선택
인덱스를 선택한 후 변환 작업에 사용할 필드를 선택하고 그룹화 또는 집계 중 사용할 기능을 선택합니다.
+ 그룹화를 사용하여 변환된 인덱스의 별도 버킷에 데이터를 배치할 수 있습니다. 예를 들어, 샘플 비행 데이터 내에서 모든 공항 목적지를 그룹화하려는 경우 `DestAirportID` 필드를 대상 필드인 `DestAirportID_terms` 필드로 그룹화하면 변환 작업이 완료된 후 변환된 인덱스에서 그룹화된 공항 ID를 확인할 수 있습니다.
+ 반면에 집계를 사용하면 간단한 계산을 수행할 수 있습니다. 예를 들어 변환 작업에 집계를 포함해 모든 비행기 티켓의 합계를 계산하는 새 필드 `sum_of_total_ticket_price`를 정의할 수 있습니다. 그런 다음 변환된 인덱스의 새 데이터를 분석할 수 있습니다.
### 3단계: 일정 지정
변환 작업은 기본적으로 활성화되며 일정에 따라 실행됩니다. **변환 실행 간격**에서 간격을 분, 시간 또는 일 단위로 지정합니다.
### 4단계: 검토 및 모니터링
구성을 검토하고 **생성(Create)**을 선택합니다. 그런 다음 **변환 작업 상태(Transform job status)** 열을 모니터링합니다.
### 5단계: 대상 인덱스 검색
작업이 완료되면 표준 `_search` API를 사용하여 대상 인덱스를 검색할 수 있습니다.
예를 들어, `DestAirportID` 필드를 기반으로 비행 데이터를 변환하는 변환 작업을 실행한 후 다음 요청을 실행하여 `SFO` 값이 있는 모든 필드를 반환할 수 있습니다.
```
GET target_index/_search
{
"query": {
"match": {
"DestAirportID_terms" : "SFO"
}
}
}
```
# Amazon OpenSearch Service의 클러스터 간 복제
Amazon OpenSearch Service의 클러스터 간 복제를 사용하면 특정 OpenSearch 서비스 도메인에서 다른 도메인으로 사용자 인덱스, 매핑 및 메타데이터를 복제할 수 있습니다. 클러스터 간 복제를 사용하면 중단 시 재해 복구를 보장하는 데 도움이 되며, 지리적으로 멀리 떨어진 데이터 센터 간에 데이터를 복제하여 대기 시간을 줄일 수 있습니다. 도메인 간에 [전송되는 AWS 데이터에 대해 표준 데이터 전송 요금을](https://aws.amazon.com/opensearch-service/pricing/) 지불합니다.
클러스터 간 복제는 *로컬* 또는 *팔로어* 인덱스가 *원격* 또는 *리더* 인덱스에서 데이터를 가져오는 액티브-패시브 복제 모델을 따릅니다. 리더 인덱스는 데이터 원본 또는 데이터를 복제하려는 인덱스를 나타냅니다. 팔로워 인덱스는 데이터 대상 또는 데이터를 복제하려는 인덱스를 나타냅니다.
클러스터 간 복제는 Elasticsearch 7.10 또는 OpenSearch 1.1 이상을 실행하는 도메인에서 사용할 수 있습니다.
**참고**
이 설명서에서는 Amazon OpenSearch Service 관점에서 교차 클러스터 복제를 설정하는 방법을 설명합니다. 여기에는 AWS Management Console 를 사용하여 자체 관리형 OpenSearch 클러스터에서 불가능한 교차 클러스터 연결을 설정하는 것이 포함됩니다. 설정 참조 및 포괄적인 API 참조를 포함한 전체 설명서는 OpenSearch 설명서의 [Cross-cluster replication](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/index/)을 참조하세요.
**Topics**
+ [제한 사항](#replication-limitations)
+ [사전 조건](#replication-prereqs)
+ [권한 요구 사항](#replication-permissions)
+ [클러스터 간 연결 설정](#replication-connect)
+ [복제 시작](#replication-start)
+ [복제 확인](#replication-confirm)
+ [복제 일시 중지 및 다시 시작](#replication-pause-resume)
+ [복제 중지](#replication-stop)
+ [자동 팔로우](#replication-autofollow)
+ [연결된 도메인 업그레이드](#replication-upgrade)
## 제한 사항
클러스터 간 복제에는 다음 제한 사항이 적용됩니다.
+ Amazon OpenSearch Service 도메인과 자체 관리형 OpenSearch 또는 Elasticsearch 클러스터 간에는 데이터를 복제할 수 없습니다.
+ 팔로워 도메인의 인덱스를 다른 팔로워 도메인으로 복제할 수 없습니다. 인덱스를 여러 팔로워 도메인에 복제하려는 경우 단일 리더 도메인에서만 복제할 수 있습니다.
+ 도메인은 인바운드 연결과 아웃바운드 연결의 조합을 통해 최대 20개의 다른 도메인에 연결할 수 있습니다.
+ 클러스터 간 연결을 처음 설정할 때는 리더 도메인이 팔로워 도메인과 같거나 상위 버전에 있어야 합니다.
+ CloudFormation 를 사용하여 도메인을 연결할 수 없습니다.
+ M3 또는 버스트 가능(T2 및 T3) 인스턴스에서는 클러스터 간 복제를 사용할 수 없습니다.
+ UltraWarm 또는 콜드 인덱스 간에는 데이터를 복제할 수 없습니다. 두 인덱스 모두 핫 스토리지에 있어야 합니다.
+ 리더 도메인에서 인덱스를 삭제해도 팔로워 도메인의 해당 인덱스는 자동으로 삭제되지 않습니다.
+ 클러스터 간 복제는 기본 및 [옵트인 ](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)간에 지원되지 않습니다. 두 도메인 모두 기본 리전 또는 옵트인 리전에 있어야 합니다.
## 사전 조건
클러스터 간 복제를 설정하기 전에 도메인이 다음 요구 사항을 충족하는지 확인하세요.
+ Elasticsearch 7.10 또는 OpenSearch 1.1 이상
+ [세분화된 액세스 제어](fgac.md)를 사용하도록 설정됨
+ [노드 간 암호화](ntn.md)를 사용하도록 설정됨
+ 리더 인덱스는 로 `index.soft_deletes.enabled` 설정되어 있어야 합니다`true`. Elasticsearch 7.0 또는 OpenSearch 1.0 이상에서 생성된 인덱스에는 기본적으로이 설정이 활성화되어 있습니다. 그러나 Elasticsearch 6.x에서 생성된 후 업그레이드된 인덱스는를 유지합니다`soft_deletes=false`. 이러한 인덱스를 복제하려면 먼저 인덱스를 다시 인덱싱해야 합니다.
인덱스에 소프트 삭제가 활성화되어 있는지 확인하려면:
```
GET /_settings?include_defaults=true&flat_settings=true&filter_path=*.settings.index.soft_deletes.enabled
```
이 `soft_deletes`인 경우 복제를 시작하기 전에 데이터를 새 인덱스로 `false`다시 인덱싱합니다.
## 권한 요구 사항
복제를 시작하려면 원격(리더) 도메인에 대한 `es:ESCrossClusterGet` 권한을 포함해야 합니다. 원격 도메인에서 다음 IAM 정책을 사용하는 것이 좋습니다. 이 정책을 사용하면 문서 인덱싱 및 표준 검색 수행과 같은 다른 작업까지 수행할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/leader-domain/*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESCrossClusterGet",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/leader-domain"
}
]
}
```
------
`es:ESCrossClusterGet` 권한이 `/leader-domain/*`이 아닌 `/leader-domain`에 적용되었는지 확인합니다.
관리자가 아닌 사용자가 복제 작업을 수행하려면 해당 사용자도 적절한 권한에 매핑되어야 합니다. 대부분의 권한은 특정 [REST API 작업](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/api/)에 해당합니다. 예를 들어 `indices:admin/plugins/replication/index/_resume` 권한을 사용하면 인덱스 복제를 재개할 수 있습니다. 전체 권한 목록은 OpenSearch 문서에서 [복제 권한](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#replication-permissions)을 참조하세요.
**참고**
복제를 시작하고 복제 규칙을 생성하는 명령은 특별한 경우입니다. 리더 도메인과 팔로워 도메인에서 백그라운드 프로세스를 호출하기 때문에 요청에서 `leader_cluster_role` 및 `follower_cluster_role`을(를) 통과해야 합니다. OpenSearch Service는 모든 백엔드 복제 작업에서 이러한 역할을 사용합니다. 이러한 역할을 매핑하고 사용하는 데 대한 자세한 내용은 OpenSearch 문서에서 [리더 및 팔로워 클러스터 역할 매핑](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles)을 참조하세요.
## 클러스터 간 연결 설정
특정 도메인에서 다른 도메인으로 인덱스를 복제하려면 도메인 간에 클러스터 간 연결을 설정해야 합니다. 도메인을 연결하는 가장 쉬운 방법은 도메인 대시보드의 [**연결(Connections)**] 탭을 사용하는 것입니다. [구성 API](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html) 또는 [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/opensearch/create-outbound-connection.html)를 사용할 수도 있습니다. 클러스터 간 복제는 ‘풀’ 모델을 따르므로 팔로워 도메인에서 연결을 초기화합니다.
**참고**
이전에 [클러스터 간 검색](cross-cluster-search.md)을 수행하기 위해 2개의 도메인을 연결한 경우, 동일한 연결을 복제에 사용할 수 없습니다. 해당 연결은 콘솔에서 `SEARCH_ONLY`로 표시됩니다. 이전에 연결된 두 도메인 간에 복제를 수행하려면 연결을 삭제하고 다시 생성해야 합니다. 이렇게 하면 교차 클러스터 검색 및 교차 클러스터 복제 모두에 연결을 사용할 수 있습니다.
**연결을 설정하려면**
1. Amazon OpenSearch Service 콘솔에서 팔로워 도메인을 선택하고 [**연결(Connections)**] 탭으로 이동하여 [**요청(Request)**]을 선택합니다.
1. [**연결 별칭(Connection alias)**]에 연결 이름을 입력합니다.
1. AWS 계정 및 리전 또는 다른 계정 또는 리전의 도메인에 연결할지 선택합니다.
+ AWS 계정 및 리전의 도메인에 연결하려면 도메인을 선택하고 **요청을** 선택합니다.
+ 다른 AWS 계정 또는 리전의 도메인에 연결하려면 원격 도메인의 ARN을 지정하고 **요청을** 선택합니다.
OpenSearch 서비스는 연결 요청을 검증합니다. 도메인이 서로 호환되지 않으면 연결이 실패합니다. 검증에 성공하면 승인을 위해 대상 도메인으로 전송됩니다. 대상 도메인이 요청을 승인하면 복제를 시작할 수 있습니다.
클러스터 간 복제는 양방향 복제를 지원합니다. 즉, 도메인 A에서 도메인 B로의 아웃바운드 연결과 도메인 B에서 도메인 A로의 또 다른 아웃바운드 연결을 만들 수 있습니다. 그런 다음 도메인 A가 도메인 B의 인덱스를 따르고 도메인 B가 도메인 A의 인덱스를 따르도록 복제를 설정할 수 있습니다.
## 복제 시작
클러스터 간 연결을 설정하고 나면 데이터 복제를 시작할 수 있습니다. 먼저 복제할 리더 도메인에 인덱스를 생성합니다.
```
PUT leader-01
```
해당 인덱스를 복제하기 위해 다음 명령을 팔로워 도메인으로 보냅니다.
```
PUT _plugins/_replication/follower-01/_start
{
"leader_alias": "connection-alias",
"leader_index": "leader-01",
"use_roles":{
"leader_cluster_role": "all_access",
"follower_cluster_role": "all_access"
}
}
```
도메인 대시보드의 **연결(Connections)** 탭에서 연결 별칭을 찾을 수 있습니다.
이 예에서는 설명의 편의를 위해 관리자가 요청을 실행하고 `leader_cluster_role` 및 `follower_cluster_role`(으)로 `all_access`을(를) 사용하는 것으로 가정합니다. 하지만 프로덕션 환경에서는 리더 및 팔로워 인덱스 모두에 복제 사용자를 생성하고 그에 따라 매핑하는 것이 좋습니다. 사용자 이름은 동일해야 합니다. 이러한 역할과 그 매핑 방법에 대한 자세한 내용은 OpenSearch 문서에서 [리더 및 팔로워 클러스터 역할 매핑](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles)을 참조하세요.
## 복제 확인
복제가 진행되고 있는지 확인하려면 복제 상태를 가져옵니다.
```
GET _plugins/_replication/follower-01/_status
{
"status" : "SYNCING",
"reason" : "User initiated",
"leader_alias" : "connection-alias",
"leader_index" : "leader-01",
"follower_index" : "follower-01",
"syncing_details" : {
"leader_checkpoint" : -5,
"follower_checkpoint" : -5,
"seq_no" : 0
}
}
```
리더 및 팔로워 체크포인트 값은 음의 정수로 시작하며, 보유한 샤드 수를 반영합니다(샤드가 하나인 경우 -1, 샤드가 5개인 경우 -5 등과 같은 식임). 변경할 때마다 값이 양의 정수로 증가합니다. 값이 동일하면 인덱스가 완전히 동기화되었음을 의미합니다. 이러한 체크포인트 값을 사용하여 도메인 전체의 복제 대기 시간을 측정할 수 있습니다.
복제를 추가로 검증하려면 리더 인덱스에 문서를 추가합니다.
```
PUT leader-01/_doc/1
{
"Doctor Sleep":"Stephen King"
}
```
그리고 팔로워 인덱스에 표시되는지 확인합니다.
```
GET follower-01/_search
{
...
"max_score" : 1.0,
"hits" : [
{
"_index" : "follower-01",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"Doctor Sleep" : "Stephen King"
}
}
]
}
}
```
## 복제 일시 중지 및 다시 시작
문제를 해결하거나 리더 도메인의 부하를 줄여야 하는 경우 복제를 일시적으로 중지할 수 있습니다. 이 요청을 팔로워 도메인에 보냅니다. 다음과 같이 빈 요청 본문을 포함해야 합니다.
```
POST _plugins/_replication/follower-01/_pause
{}
```
그런 다음 상태를 가져와 복제가 일시 중지되었는지 확인합니다.
```
GET _plugins/_replication/follower-01/_status
{
"status" : "PAUSED",
"reason" : "User initiated",
"leader_alias" : "connection-alias",
"leader_index" : "leader-01",
"follower_index" : "follower-01"
}
```
변경을 마치면 복제를 다시 시작합니다. 이 요청을 팔로워 도메인에 보냅니다. 다음과 같이 빈 요청 본문을 포함해야 합니다.
```
POST _plugins/_replication/follower-01/_resume
{}
```
12시간 이상 일시 중지된 후에는 복제를 재개할 수 없습니다. 복제를 중지하고 팔로워 인덱스를 삭제한 다음 리더의 복제를 다시 시작해야 합니다.
## 복제 중지
복제를 완전히 중지하면 팔로워 인덱스가 리더를 팔로우하지 않고 표준 인덱스가 됩니다. 복제를 중지한 후에는 다시 시작할 수 없습니다.
팔로워 도메인에서 복제를 중지합니다. 다음과 같이 빈 요청 본문을 포함해야 합니다.
```
POST _plugins/_replication/follower-01/_stop
{}
```
## 자동 팔로우
단일 리더 도메인에 대해 지정된 패턴과 일치하는 인덱스를 자동으로 복제하는 일련의 복제 규칙을 정의할 수 있습니다. 리더 도메인의 인덱스가 패턴 중 하나와 일치하는 경우(예: `books*`), 일치하는 팔로워 인덱스가 팔로워 도메인에 생성됩니다. OpenSearch Service에서는 패턴과 일치하는 기존 인덱스와 사용자가 생성하는 새 인덱스를 복제합니다. 팔로워 도메인에 이미 있는 인덱스는 복제하지 않습니다.
시스템에서 생성한 인덱스와 팔로워 도메인에 이미 있는 인덱스를 제외한 모든 인덱스를 복제하려면 와일드카드(`*`) 패턴을 사용합니다.
### 복제 규칙 생성
팔로워 도메인에 복제 규칙을 생성하고 클러스터 간 연결의 이름을 지정합니다.
```
POST _plugins/_replication/_autofollow
{
"leader_alias" : "connection-alias",
"name": "rule-name",
"pattern": "books*",
"use_roles":{
"leader_cluster_role": "all_access",
"follower_cluster_role": "all_access"
}
}
```
도메인 대시보드의 **연결(Connections)** 탭에서 연결 별칭을 찾을 수 있습니다.
이 예에서는 설명의 편의를 위해 관리자가 요청을 실행하고 리더 및 팔로워 도메인 역할로 `all_access`을(를) 사용하는 것으로 가정합니다. 하지만 프로덕션 환경에서는 리더 및 팔로워 인덱스 모두에 복제 사용자를 생성하고 그에 따라 매핑하는 것이 좋습니다. 사용자 이름은 동일해야 합니다. 이러한 역할과 그 매핑 방법에 대한 자세한 내용은 OpenSearch 문서에서 [리더 및 팔로워 클러스터 역할 매핑](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles)을 참조하세요.
도메인의 기존 복제 규칙 목록을 검색하려면 [자동 팔로우 통계 API 작업](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/api/#get-auto-follow-stats)을 사용합니다.
규칙을 테스트하려면 리더 도메인의 패턴과 일치하는 인덱스를 생성합니다.
```
PUT books-are-fun
```
그리고 해당 복제본이 팔로워 도메인에 표시되는지 확인합니다.
```
GET _cat/indices
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open books-are-fun ldfHO78xYYdxRMULuiTvSQ 1 1 0 0 208b 208b
```
### 복제 규칙 삭제
복제 규칙을 삭제하면 OpenSearch Service가 패턴과 일치하는 *새* 인덱스의 복제를 중지하지만, 기존 복제 작업은 해당 인덱스의 [복제를 중지](#replication-stop)할 때까지 계속합니다.
팔로워 도메인에서 복제 규칙을 삭제합니다.
```
DELETE _plugins/_replication/_autofollow
{
"leader_alias" : "connection-alias",
"name": "rule-name"
}
```
## 연결된 도메인 업그레이드
클러스터 간 연결이 있는 두 도메인의 엔진 버전을 업그레이드하려면 먼저 팔로워 도메인을 업그레이드한 다음 리더 도메인을 업그레이드하십시오. 두 도메인 간 연결을 삭제하면 복제가 일시 중지되고 다시 시작할 수 없으므로 연결을 삭제해서는 안 됩니다.
# 원격 재인덱스를 사용하여 Amazon OpenSearch Service 인덱스 마이그레이션
원격 재인덱스를 사용하면 한 Amazon OpenSearch Service 도메인에서 다른 도메인으로 인덱스를 복사할 수 있습니다. OpenSearch Service 도메인이나 자체 관리형 OpenSearch 및 Elasticsearch 클러스터에서 인덱스를 마이그레이션할 수 있습니다.
*원격* 도메인 및 인덱스는 데이터 원본 또는 데이터를 복사하려는 도메인과 인덱스를 나타냅니다. *로컬* 도메인 및 인덱스는 데이터 대상 또는 데이터를 복사하려는 도메인과 인덱스를 나타냅니다.
원격 인덱싱을 사용하려면 로컬 도메인에서 OpenSearch 1.0 이상 또는 Elasticsearch 6.7 이상이 필요합니다. 원격 도메인의 메이저 버전은 로컬 도메인보다 더 낮거나 대상 도메인과 동일해야 합니다. Elasticsearch 버전은 OpenSearch 버전보다 *낮은* 것이 좋습니다. 즉, Elasticsearch 도메인에서 OpenSearch 도메인으로 데이터를 재인덱스할 수 있습니다. 동일한 메이저 버전 내에서 원격 도메인은 마이너 버전이 될 수 있습니다. 예를 들어 Elasticsearch 7.10.x에서 7.9로 원격 재인덱싱은 지원되지만 OpenSearch 1.0에서 Elasticsearch 7.10.x로의 원격 재인덱싱은 지원되지 않습니다.
**참고**
이 설명서에서는 Amazon OpenSearch Service 도메인 사이에서 데이터를 다시 인덱싱하는 방법을 설명합니다. 자세한 단계 및 지원되는 옵션을 비롯한 `reindex` 작업에 대한 전체 설명서는 OpenSearch 설명서의 [Reindex document](https://docs.opensearch.org/latest/opensearch/reindex-data/)를 참조하세요.
**Topics**
+ [사전 조건](#remote-reindex-prereq)
+ [OpenSearch Service 인터넷 도메인 간의 데이터 재인덱스](#remote-reindex-domain)
+ [원격이 VPC에 있을 때 OpenSearch Service 도메인 간의 데이터 재인덱스](#remote-reindex-vpc)
+ [비 OpenSearch Service 도메인 간 데이터 재인덱스](#remote-reindex-non-aos)
+ [대용량 데이터 집합 재인덱스](#remote-reindex-largedatasets)
+ [원격 재인덱스 설정](#remote-reindex-settings)
## 사전 조건
원격 재인덱스의 요구 사항은 다음과 같습니다.
+ 원격 도메인은 로컬 도메인에서 액세스할 수 있어야 합니다. VPC에 상주하는 원격 도메인의 경우, 로컬 도메인이 VPC에 액세스할 수 있어야 합니다. 이 프로세스는 네트워크 구성에 따라 다르지만, VPN 또는 관리형 네트워크 연결 또는 네이티브 [VPC 엔드포인트 연결](#remote-reindex-vpc) 사용이 필요할 수 있습니다. 자세한 내용은 [VPC 내에서 Amazon OpenSearch Service 도메인 시작](vpc.md)를 참조하세요.
+ 요청은 다른 REST 요청과 마찬가지로 원격 도메인에서 승인해야 합니다. 원격 도메인에 세분화된 액세스 제어가 활성화된 경우, 원격 도메인에서 재인덱스를 수행하고 로컬 도메인의 인덱스를 읽을 수 있는 권한이 있어야 합니다. 보안 고려 사항에 대한 자세한 내용은 [Amazon OpenSearch Service에서 세분화된 액세스 제어](fgac.md) 단원을 고려하세요.
+ 재인덱스 프로세스를 시작하기 전에 로컬 도메인에서 원하는 설정으로 인덱스를 생성하는 것이 좋습니다.
+ 도메인에서 데이터 노드에 T2 또는 T3 인스턴스 유형을 사용하는 경우, 원격 재인덱스를 사용할 수 없습니다.
## OpenSearch Service 인터넷 도메인 간의 데이터 재인덱스
가장 기본적인 시나리오는 원격 인덱스가 공개적으로 액세스할 수 있는 엔드포인트가 있는 로컬 도메인과 AWS 리전 동일하고 IAM 자격 증명에 서명했다는 것입니다.
원격 도메인에서 재인덱스해올 원격 인덱스와 재인덱스할 로컬 인덱스를 지정하세요.
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
유효성 검사를 위해 원격 도메인 엔드포인트 끝에 443을 추가해야 합니다.
인덱스가 로컬 도메인으로 복사되었는지 확인하려면 다음 요청을 로컬 도메인에 보내세요.
```
GET local_index/_search
```
원격 인덱스가 로컬 도메인과 다른 리전에 있는 경우 다음 샘플 요청과 같이 해당 리전 이름을 전달하세요.
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"region": "eu-west-1"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
AWS GovCloud (US) 또는 중국 리전과 같은 격리된 리전의 경우 IAM 사용자가 해당 리전에서 인식되지 않기 때문에 엔드포인트에 액세스하지 못할 수 있습니다.
원격 도메인이 [기본 인증](fgac-http-auth.md)으로 보호되는 경우 사용자 이름과 암호를 지정합니다.
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"username": "username",
"password": "password"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
## 원격이 VPC에 있을 때 OpenSearch Service 도메인 간의 데이터 재인덱스
모든 OpenSearch Service 도메인은 자체 내부 Virtual Private Cloud(VPC) 인프라로 구성됩니다. 기존 OpenSearch Service VPC에 새 도메인을 생성하면 VPC의 각 데이터 노드에 대해 탄력적인 네트워크 인터페이스가 생성됩니다.
원격 재인덱스 작업은 원격 OpenSearch Service 도메인에서 수행되므로 자체 프라이빗 VPC 내에서 수행되기 때문에 로컬 도메인의 VPC에 액세스할 방법이 필요합니다. 기본 제공 VPC 엔드포인트 연결 기능을 사용하여 연결을 설정 AWS PrivateLink하거나 프록시를 구성하여이 작업을 수행할 수 있습니다.
로컬 도메인에서 OpenSearch 버전 1.0 이상을 사용하는 경우 콘솔 또는를 사용하여 AWS PrivateLink 연결을 AWS CLI 생성할 수 있습니다. AWS PrivateLink 연결을 사용하면 로컬 VPC의 리소스가 동일한 내의 원격 VPC의 리소스에 비공개로 연결할 수 있습니다 AWS 리전.
VPC 엔드포인트 연결을 생성하려면 다시 인덱싱할 소스 도메인이 로컬 VPC에 있어야 하며 소스 도메인과 대상 도메인이 모두 동일한 AWS 리전에 있어야 합니다.
### 를 사용하여 데이터 재인덱싱 AWS Management Console
콘솔로 원격 재인덱싱을 사용하여 VPC 엔드포인트 연결을 공유하는 두 도메인 간에 인덱스를 복사할 수 있습니다.
1. Amazon OpenSearch Service 콘솔([https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/))로 이동합니다.
1. 왼쪽 탐색 창에서 **Domains**(도메인)를 선택합니다.
1. 로컬 도메인 또는 데이터를 복사하려는 도메인을 선택합니다. 그러면 도메인 세부 정보 페이지가 열립니다. 일반 정보 아래에서 **연결** 탭을 선택하고 **요청**를 선택합니다.
1. **연결 요청** 페이지에서 연결 모드로 **VPC 엔드포인트 연결**을 선택하고 기타 관련 세부 정보를 입력합니다. 이러한 세부 정보에는 데이터를 복사하려는 도메인인 원격 도메인이 포함됩니다. 그런 다음 **Request**(요청)를 선택합니다.
1. 원격 도메인의 세부 정보 페이지로 이동하고 **연결** 탭을 선택한 다음 **인바운드 연결** 테이블을 찾습니다. 방금 연결을 생성한 도메인(로컬 도메인)의 이름 옆에 있는 확인란을 선택합니다. **Approve**(승인)를 선택합니다.
1. 로컬 도메인으로 다시 이동하여 **Connections**(연결) 탭을 선택하고 **Outbound connections**(아웃바운드 연결) 테이블을 찾습니다. 두 도메인 간의 연결이 활성화되면 테이블의 **Endpoint**(엔드포인트) 열에서 엔드포인트를 사용할 수 있게 됩니다. 엔드포인트를 복사합니다.
1. 로컬 도메인의 대시보드를 열고 왼쪽 탐색에서 **Dev Tools**(개발 도구)를 선택합니다. 원격 도메인 인덱스가 아직 로컬 도메인에 존재하지 않는지 확인하려면 다음 GET 요청을 실행합니다. *remote-domain-index-name*을 자체 인덱스 이름으로 바꿉니다.
```
GET remote-domain-index-name/_search
{
"query":{
"match_all":{}
}
}
```
출력에 인덱스를 찾을 수 없다는 오류가 표시되어야 합니다.
1. 다음과 같이 GET 요청 아래에서 POST 요청을 생성하고 엔드포인트를 원격 호스트로 사용합니다.
```
POST _reindex
{
"source":{
"remote":{
"host":"connection-endpoint",
"username":"username",
"password":"password"
},
"index":"remote-domain-index-name"
},
"dest":{
"index":"local-domain-index-name"
}
}
```
이 요청을 실행합니다.
1. GET 요청을 다시 실행합니다. 이제 출력에 로컬 인덱스가 존재한다는 내용이 표시되어야 합니다. 이 인덱스를 쿼리하여 OpenSearch가 원격 인덱스에서 모든 데이터를 복사했는지 확인할 수 있습니다.
### OpenSearch Service API 작업을 사용한 데이터 재인덱싱
API로 원격 재인덱싱을 사용하여 VPC 엔드포인트 연결을 공유하는 두 도메인 간에 인덱스를 복사할 수 있습니다.
1. [CreateOutboundConnection](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_CreateOutboundConnection.html) API 작업을 사용하여 로컬 도메인에서 원격 도메인으로의 새 연결을 요청하세요.
```
POST https://es.region.amazonaws.com/2021-01-01/opensearch/cc/outboundConnection
{
"ConnectionAlias": "remote-reindex-example",
"ConnectionMode": "VPC_ENDPOINT",
"LocalDomainInfo": {
"AWSDomainInformation": {
"DomainName": "local-domain-name",
"OwnerId": "aws-account-id",
"Region": "region"
}
},
"RemoteDomainInfo": {
"AWSDomainInformation": {
"DomainName": "remote-domain-name",
"OwnerId": "aws-account-id",
"Region": "region"
}
}
}
```
응답에서 `ConnectionId`을 받게 됩니다. 다음 단계에서 사용할 수 있도록 이 ID를 저장합니다.
1. 연결 ID로 [AcceptInboundConnection](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_AcceptInboundConnection.html) API 작업을 사용하여 로컬 도메인의 요청을 승인하세요.
```
PUT https://es.region.amazonaws.com/2021-01-01/opensearch/cc/inboundConnection/ConnectionId/accept
```
1. [DescribeOutboundConnections](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DescribeOutboundConnections.html) API 작업을 사용하여 원격 도메인의 엔드포인트를 검색하세요.
```
{
"Connections": [
{
"ConnectionAlias": "remote-reindex-example",
"ConnectionId": "connection-id",
"ConnectionMode": "VPC_ENDPOINT",
"ConnectionProperties": {
"Endpoint": "connection-endpoint"
},
...
}
]
}
```
5단계에서 사용할 *connection-endpoint*를 저장합니다.
1. 원격 도메인 인덱스가 아직 로컬 도메인에 존재하지 않는지 확인하려면 다음 GET 요청을 실행합니다. *remote-domain-index-name*을 자체 인덱스 이름으로 바꿉니다.
```
GET local-domain-endpoint/remote-domain-index-name/_search
{
"query":{
"match_all":{}
}
}
```
출력에 인덱스를 찾을 수 없다는 오류가 표시되어야 합니다.
1. 다음과 같이 POST 요청을 생성하고 엔드포인트를 원격 호스트로 사용합니다.
```
POST local-domain-endpoint/_reindex
{
"source":{
"remote":{
"host":"connection-endpoint",
"username":"username",
"password":"password"
},
"index":"remote-domain-index-name"
},
"dest":{
"index":"local-domain-index-name"
}
}
```
이 요청을 실행합니다.
1. GET 요청을 다시 실행합니다. 이제 출력에 로컬 인덱스가 존재한다는 내용이 표시되어야 합니다. 이 인덱스를 쿼리하여 OpenSearch가 원격 인덱스에서 모든 데이터를 복사했는지 확인할 수 있습니다.
원격 도메인이 VPC 내부에서 호스팅되고 VPC 엔드포인트 연결 기능을 사용하지 않으려는 경우, 공개적으로 액세스할 수 있는 엔드포인트로 프록시를 구성해야 합니다. 이 경우 OpenSearch Service에는 VPC로 트래픽을 전송할 수 있는 기능이 없으므로 퍼블릭 엔드포인트가 필요합니다.
[VPC 모드](vpc.md)에서 도메인을 실행하면 하나 이상의 엔드포인트가 VPC에 배치됩니다. 하지만 이러한 엔드포인트는 VPC 내에서 도메인으로 들어오는 트래픽만을 위한 것이며 VPC 자체로의 트래픽은 허용하지 않습니다.
원격 재인덱싱 명령은 로컬 도메인에서 실행되므로 원본 트래픽은 해당 엔드포인트를 사용하여 원격 도메인에 액세스할 수 없습니다. 이 사용 사례에서 프록시가 필요한 이유입니다. 프록시 도메인에는 공공 인증 기관(CA)에서 서명한 인증서가 있어야 합니다. 자체 서명 또는 개인 CA 서명 인증서는 지원되지 않습니다.
## 비 OpenSearch Service 도메인 간 데이터 재인덱스
원격 인덱스가 자체 관리형 EC2 인스턴스에서와 같이 OpenSearch 서비스 외부에서 호스팅되는 경우 `external` 파라미터를 `true`로 설정합니다.
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"username": "username",
"password": "password",
"external": true
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
이 경우 사용자 이름과 암호를 사용한 [기본 인증](fgac-http-auth.md)만 지원됩니다. 원격 도메인에는 공개적으로 액세스할 수 있는 엔드포인트(로컬 OpenSearch Service 도메인과 동일한 VPC에 있더라도)와 퍼블릭 CA에서 서명한 인증서가 있어야 합니다. 자체 서명 또는 개인 CA 서명 인증서는 지원되지 않습니다.
## 대용량 데이터 집합 재인덱스
원격 재인덱스는 다음 기본값을 사용하여 원격 도메인에 스크롤 요청을 보냅니다.
+ 검색 컨텍스트 5분
+ 소켓 제한 시간 30초
+ 배치 크기 1,000
데이터를 수용하기 위해 이러한 파라미터를 조정하는 것이 좋습니다. 큰 문서의 경우 일괄 처리 크기를 줄이거나 제한 시간을 늘리는 것을 고려합니다. 자세한 내용은 [결과 페이지 매김](https://docs.opensearch.org/docs/latest/search-plugins/searching-data/paginate/)을 참조하세요.
```
POST _reindex?pretty=true&scroll=10h&wait_for_completion=false
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"socket_timeout": "60m"
},
"size": 100,
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
또한 성능 향상을 위해 다음 설정을 로컬 인덱스에 추가하는 것이 좋습니다.
```
PUT local_index
{
"settings": {
"refresh_interval": -1,
"number_of_replicas": 0
}
}
```
재인덱스 프로세스가 완료되면 원하는 복제본 수를 설정하고 새로 고침 간격 설정을 제거할 수 있습니다.
쿼리를 통해 선택한 문서의 하위 집합만 재인덱스하려면 이 요청을 로컬 도메인으로 보내세요.
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443"
},
"index": "remote_index",
"query": {
"match": {
"field_name": "text"
}
}
},
"dest": {
"index": "local_index"
}
}
```
원격 재인덱스는 슬라이싱을 지원하지 않으므로 동일한 요청에 대해 여러 스크롤 작업을 병렬로 수행할 수 없습니다.
## 원격 재인덱스 설정
OpenSearch Service는 표준 재인덱싱 옵션 외에도 다음 옵션을 지원합니다.
| 옵션 | 유효값 | 설명 | 필수 |
| --- | --- | --- | --- |
| 외부 | 부울 | 원격 도메인이 OpenSearch Service 도메인이 아니거나 2개의 VPC 도메인 사이에서 재인덱싱하는 경우 true로 지정하세요. | 아니요 |
| 리전 | 문자열 | 원격 도메인이 다른 리전에 있는 경우 리전 이름을 지정하세요. | 아니요 |
# 데이터 스트림을 사용하여 Amazon OpenSearch Service에서 시계열 데이터 관리
시계열 데이터를 관리하는 일반적인 워크플로에는 롤오버 인덱스 별칭 생성, 쓰기 인덱스 정의, 백업 인덱스에 대한 공통 매핑 및 설정 정의와 같은 여러 단계가 포함됩니다.
Amazon OpenSearch Service의 데이터 스트림은 이러한 초기 설정 프로세스를 간소화하는 데 도움이 됩니다. 보통 본질적으로 추가 전용인 애플리케이션 로그와 같은 시간 기반 데이터에 대해서는 데이터 스트림이 즉시 작동합니다.
데이터 스트림을 사용하려면 OpenSearch 버전 1.0 이상이 필요합니다.
**참고**
이 설명서에서는 Amazon OpenSearch Service 도메인에서 데이터 스트림을 시작하는 데 도움이 되는 기본적인 단계를 제공합니다. 포괄적인 설명서를 보려면 OpenSearch 설명서의 [Data streams](https://docs.opensearch.org/latest/opensearch/data-streams/)를 참조하세요.
## 데이터 스트림 시작하기
데이터 스트림은 내부적으로 여러 백업 인덱스로 구성됩니다. 검색 요청은 모든 백업 인덱스로 라우팅되고 인덱싱 요청은 최신 쓰기 인덱스로 라우팅됩니다.
### 1단계: 인덱스 템플릿 생성
데이터 스트림을 생성하려면 먼저 인덱스 집합을 데이터 스트림으로 구성하는 인덱스 템플릿을 생성해야 합니다. `data_stream` 객체는 데이터 스트림이며 일반 인덱스 템플릿이 아니라는 것을 나타냅니다. 인덱스 패턴은 데이터 스트림의 이름과 일치합니다:
```
PUT _index_template/logs-template
{
"index_patterns": [
"my-data-stream",
"logs-*"
],
"data_stream": {},
"priority": 100
}
```
이 경우 수집된 각 문서에는 `@timestamp` 필드가 있어야 합니다. 사용자 지정 타임스탬프 필드를 `data_stream` 객체의 속성으로 정의할 수도 있습니다.
```
PUT _index_template/logs-template
{
"index_patterns": "my-data-stream",
"data_stream": {
"timestamp_field": {
"name": "request_time"
}
}
}
```
### 2단계: 데이터 스트림 생성
인덱스 템플릿을 생성한 후에는 데이터 스트림을 생성하지 않고 직접 데이터 수집을 시작할 수 있습니다.
`data_stream` 객체와 일치하는 인덱스 템플릿이 있기 때문에 OpenSearch가 자동으로 데이터 스트림을 생성합니다.
```
POST logs-staging/_doc
{
"message": "login attempt failed",
"@timestamp": "2013-03-01T00:00:00"
}
```
### 3단계: 데이터 스트림에 데이터 수집
데이터를 데이터 스트림으로 수집하기 위해 일반 인덱싱 API를 사용할 수 있습니다. 인덱싱하는 모든 문서에 타임스탬프 필드가 있는지 확인합니다. 타임스탬프 필드가 없는 문서를 수집하려고 하면 오류 메시지가 표시됩니다.
```
POST logs-redis/_doc
{
"message": "login attempt",
"@timestamp": "2013-03-01T00:00:00"
}
```
### 4단계: 데이터 스트림 검색
일반 인덱스 또는 인덱스 별칭을 검색하는 것처럼 데이터 스트림을 검색할 수 있습니다. 검색 작업은 모든 백업 인덱스(스트림에 존재하는 모든 데이터) 에 적용됩니다.
```
GET logs-redis/_search
{
"query": {
"match": {
"message": "login"
}
}
}
```
### 5단계: 데이터 스트림 롤오버
[인덱스 상태 관리(ISM)](ism.md) 정책을 설정하여 데이터 스트림에 대한 롤오버 프로세스를 자동화할 수 있습니다. ISM 정책은 생성 시 백업 인덱스에 적용됩니다. 정책을 데이터 스트림에 연결하면 해당 데이터 스트림의 향후 백업 인덱스에만 영향을 줍니다. 또한 ISM 정책이 백업 인덱스에서 이 정보를 유추하기 때문에 `rollover_alias` 설정을 제공할 필요가 없습니다.
**참고**
백업 인덱스를 [콜드 스토리지](cold-storage.md)로 롤오버하면 OpenSearch가 데이터 스트림에서 이 인덱스를 제거합니다. 인덱스를 [UltraWarm](ultrawarm.md)으로 다시 이동하더라도 인덱스는 독립적으로 유지되며 원래 데이터 스트림의 일부가 아닙니다. 데이터 스트림에서 인덱스를 제거한 후 스트림을 검색해도 인덱스에서 데이터가 반환되지 않습니다.
**주의**
데이터 스트림의 쓰기 인덱스는 콜드 스토리지로 마이그레이션할 수 없습니다. 데이터 스트림의 데이터를 콜드 스토리지로 마이그레이션하려면 마이그레이션하기 전에 데이터 스트림을 롤오버해야 합니다.
### 6단계: OpenSearch Dashboards에서 데이터 스트림 관리
OpenSearch Dashboards에서 데이터 스트림을 관리하려면 **OpenSearch Dashboards**를 열고 **인덱스 관리(Index Management)**를 선택한 다음 **인덱스(Indices)** 또는 **정책 관리형 인덱스(Policy managed indices)**를 선택합니다.
### 7단계: 데이터 스트림 삭제
삭제 작업은 먼저 데이터 스트림의 백업 인덱스를 삭제한 다음 데이터 스트림 자체를 삭제합니다.
데이터 스트림과 숨겨진 모든 백업 인덱스를 삭제하려면 다음을 수행합니다.
```
DELETE _data_stream/name_of_data_stream
```