[AWS] 인덱스 라이프사이클 관리 실습

Hyunjun Kim·2025년 8월 1일

실습 - (AWS 환경)

목록 보기

46/61

4.2.1 rollover API

인덱스가 특정 조건에 도달했을 때 새로운 인덱스를 생성하는 API다. ISM 템플릿에 rollover 조건을 설정하면 주기적으로 rollover 조건을 체크하고, 새로운 인덱스를 생성해준다. 본 강의에서는 rollover API를 직접 호출해서 수동으로 인덱스를 rollover해볼 것이다.

ISM 템플릿
index 어떤 것이든 규칙에 맞으면 ISM 적용시키줘.

rollover를 사용하려면 인덱스 alias 설정이 필요하다. 인덱스 alias는 여러 인덱스를 가리킬 수 있는 가상의 인덱스 이름으로,여러 인덱스를 동일한 그룹으로 묶고 싶을 때 사용하면 된다.

alias가 가리키는 인덱스는 언제든지 변경할 수 있으며, alias를 통해 여러 인덱스에 걸쳐 분산 저장된 도큐먼트를 한 번에 쿼리할 수도 있다. 예를 들어, 월 기준으로 인덱스에 로그를 저장하고, 최근 두 달 동안의 로그를 자주 쿼리하는 경우 last_2_months라는 alias를 생성하고, 매월 해당 alias가 가리키는 인덱스를 업데이트하면 된다. rollover는 인덱스 alias에 대해 수행된다. 즉 인덱스 alias를 rollover하면, 해당 alias에 새로운 인덱스가 생성되는 것이다.

rollver API 실습을 위해 Elasticvue에서 my-index-000001 인덱스를 생성하자.

인덱스 alias를 rollover할 때 기존 인덱스 이름이 my-index-000001과 같이 하이픈과 6자리 숫자 조합으로 끝날 경우 새로운 인덱스의 이름은 my-index-000002처럼 자동으로 숫자가 증가되어 설정된다. 인덱스 이름이 위의 형식과 맞지 않을 경우 target-index 필드를 통해 새로 만들 인덱스 이름을 지정해줘야 한다.

다음 요청으로 my-index-000001 인덱스에 alias 설정을 추가할 수 있다. is_write_index를 true로 설정해야 해당 인덱스에 대한 쓰기 작업이 허용되며, 인덱스 alias의 여러 인덱스 중 하나의 인덱스에만 is_write_index를 true로 설정할 수 있다. 즉 인덱스 alias는 쓰기 가능한 인덱스를 한 개만 가질 수 있다.

$ curl -XPOST "$OPENSEARCH_REST_API/_aliases?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"actions": [
		{
			"add": {
				"index": "my-index-000001",
				"alias": "alias1",
				"is_write_index": true
			}
		}
	]
}
'

Indices 에 들어가서 보면 Aliases 부분이 변경되어 있다.

다음과 같은 조건으로 alias1을 rollover해보자. 현재 alias1에 인덱싱된 도큐먼트가 없기 때문에 rollover되지 않은 것을 확인할 수 있다.

$ curl -XPOST "$OPENSEARCH_REST_API/alias1/_rollover?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"conditions": {
		"max_age": "30d",
		"max_docs": 1,
		"max_size": "10gb"
	}
}
'

31이 지났거나, 10기가바이트가 넘었거나 조건에 해당되면 rollver가 될 수 있게 했다.

max_docs : 1 로 실습할 때 document 하나 넣으면 바로 rollover 되게 만들도록 하기 위해서 썼다. 실제로는 이렇게 1로 적으면 안됨 ㅋㅋ

그런데 POST 에서 error가 나왔다.

"reason": "index name [my_index_000001] does not match pattern '^.*-\\d+$'"

이 메시지는 rollover 조건을 사용하는 정책에서, rollover의 전제 조건인 인덱스 명명 규칙이 충족되지 않았다는 뜻이다.

rollover는 인덱스를 자동으로 교체(새 인덱스로 전환)하는 기능인데, 이때 rollover 대상 인덱스 이름은 반드시 name-000001 형식을 따라야 한다.

인덱스 이름이 `my_index_000001`인데, 언더스코어(_)가 아니라 하이픈(-) 을 사용해야 된다.

Elasticsearch 및 OpenSearch 모두에서 인덱스 이름은 immutable(불변)하게 설계되어 있기 때문에
index의 이름은 직접 수정할 수 없다.

index를 다시 만들어보자.

acknowledged": false, : 아무런 도큐먼트가 없기때문에 False

"new_index": "my-index-000002", : 롤오버가 발생했다면 해당 new index로 롤오버가 됐을 거다

"dry_run": false, : 실제로 수행은 안되고 이게 동작하는지만 확인하는 걸 드라이런이라고 함

conditions : 어떤 게 충족이 되었는지

다음 요청으로 alias1에 도큐먼트를 인덱싱해보자. my-index-000001 인덱스에 도큐먼트가 인덱싱된 것을 응답 본문에서 확인할 수 있다.

PUT /alias/_doc API를 사용하면 OpenSearch는 해당 인덱스 alias에 포함된 인덱스 중 쓰기 가능한 인덱스로 요청을 라우팅하기 때문이다.

$ curl -XPUT "$OPENSEARCH_REST_API/alias1/_doc/1?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"text": "Hello, world!"
}
'

Indices 탭에서
docs 개수가 늘어나야 하는데, 늘지 않아서 한참을 기다렸다.

해당 index 이름 클릭하면 Search 탭에 들어가는데,

들어가면 보이지 않던 docs 의 존재가 보이게 된다.
~~( 우연히 그 때 업데이트가 되었을 수도 있고 )~~

쩃든 됐음

다시 alias1을 rollover해보자.

$ curl -XPOST "$OPENSEARCH_REST_API/alias1/_rollover?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"conditions": {
		"max_age": "30d",
		"max_docs": 1,
		"max_size": "10gb"
	}
}
'

"acknowledged": true,
"shards_acknowledged": true,
"rolled_over": true,
"[max_docs: 1]": true
max_docs 조건을 만족했기 때문에 rollover가 되었다

새로운 my-index-000002 인덱스가 생성된 것을 확인할 수 있다.

인덱스 my-index-000002도 alias1로 되어있고,
이 친구는 document가 없고. rollover가 잘 된 것을 확인할 수 있다.

Elasticvue에서 my-index-000002의 Show info 버튼을 눌러서 인덱스 정보를 확인해보자.

is_write_index 설정이 변경된 것을 확인할 수 있다.

alias1 로 새로운 데이터를 쓰면 이 000002인덱스에 데이터가 들어갈 것이라는 뜻

my-index-000001 의 Show info 버튼을 눌러서 인덱스 정보를 확인해보면

"alias1"의 "is_write_index"가 false 로 바뀌어 있다. 이제 이 친구는 읽기만 할 때 사용이 된다.

즉 앞으로 alias1에 대한 쓰기 작업은 my-index-000002 인덱스만 참여하고,
alias1에 대한 검색 작업은 my-index-000001과 my-index-000002 인덱스 모두 참여하게 된다.
is_write_index는 인덱스 alias 수준의 설정이므로,
POST /my-index-000001/_doc으로 my-index-000001에 직접 인덱싱을 요청할 경우 여전히 정상적으로 처리된다.

alias1 로 get 요청을 하면 각 index의 세팅 정보들을 볼 수 있다.

다음과 같이 alias1에 도큐먼트를 인덱싱하면 my-index-000002에 인덱싱된 것을 응답 본문에서 확인할 수 있다.

$ curl -XPUT "$OPENSEARCH_REST_API/alias1/_doc/2?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"text": "What is your name?"
}
'

index my-index-000002에 2번 document가 써진 것을 확인할 수 있다.

alias1에 대해 검색을 요청하면, alias1에 포함된 모든 인덱스에 대해 검색 작업이 수행된 것을 확인할 수 있다.

4.2.2 shrink API

shrink API는 인덱스의 프라이머리 샤드 개수를 줄여준다. 내부적으로 shrink API는 기존 인덱스의 모든 데이터를 프라이머리 샤드 개수가 더 적게 설정된 새로운 인덱스로 옮겨서 샤드 병합을 수행한다. 자주 사용하지 않는 인덱스의 경우 shrink API로 샤드 개수를 줄여서 리소스 사용량을 최소화하는 것이 좋다.

shrink API를 사용하기 위한 전제 조건은 다음과 같다.

인덱스는 읽기 전용이어야 한다.
- shrink 작업 도중 도큐먼트가 인덱싱되는 것을 막아준다.
  - 데이터를 넣는 건 단순 넣는 것으로 끝나는 것이 아니라 루신의 inverted index가 업데이트 되니까 indexing table이 바뀐다. 그런데 루신은 내부적으로 세그먼트를 immutable하게 두니까 그 다음 번 세그먼트 병합되는 것까지 기다리라고 한다면 이게 어떤 기준으로 이걸 새로 병합해야 하지? 라는 게 실제 파일 레벨까지 가면 복잡해진다. 실시간으로 써지고 있으면. 그래서 애초에 읽기전인 상태로 한정하는 것
인덱스의 모든 프라이머리 또는 레플리카 샤드가 동일한 노드에 있어야 한다.
- 예를 들어 p0, p1, r0, r1 샤드가 존재하는 경우, p0, r1이 동일한 노드에 있으면 조건을 충족한다. 반드시 모든 샤드가 프라이머리 샤드일 필요는 없다.
- 인덱스의 레플리카 샤드를 모두 제거하면 shrink 작업이 더 쉬워진다. 어차피 레플리카 샤드는 병합된 프라이머리 샤드 기준으로 새롭게 생성된다.
인덱스는 green 상태여야 한다.

test2 인덱스 설정을 수정해서 shrink API를 사용할 수 있도록 만들어보자. 다음 요청은 test2 인덱스에 대해 3가지 작업을 수행한다.

test2 인덱스의 모든 레플리카 샤드를 제거한다.
test2 인덱스의 모든 프라이머리 샤드를 opensearch-d3 노드에 재배치한다.
test2 인덱스를 읽기 전용으로 만든다.

$ curl -XPUT "$OPENSEARCH_REST_API/test2/_settings?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
  "settings": {
    "index.number_of_replicas": 0,                                
    "index.routing.allocation.require._name": "opensearch_d3", 
    "index.blocks.write": true                                    
  }
}
'

"index.routing.allocation.require._name" : 모든 라우팅 얼로케이션을 여기로 넘겨줘.

샤드의 상태를 보면 리플리카 전부 없어졌고
d3로 모두 옮겨간 걸 확인할 수 있다.

index test2의 show info 보면
routing allocation require가 d3로 지정된 것을 볼 수 있다.

blocks write true 는
blocking 한다는 건데 write 에 대한 요청을 blocking 하겠다 라는 걸 index에 대고 설정을 해준 게 됨

write는 안 일어나고 read-only mode가 됨

다음 요청으로 test2 인덱스를 test2-new 인덱스로 shrink해보자.

shrink 작업은 원본 인덱스와 동일한 설정으로 새로운 인덱스를 생성하는데, 다음과 같이 settings 필드를 통해 일부 설정을 overwrite할 수 있다.

shrink로 옮겨갈 이 친구의 세팅을 넣어줄 수 있음

index.routing.allocation.require.name를 null로 초기화해서 인덱스가 여러 노드에 분산되도록 했고, index.blocks.write도 null로 초기화해서 인덱스를 쓰기 가능하도록 만들었다.

$ curl -XPOST "$OPENSEARCH_REST_API/test2/_shrink/test2-new?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"settings": {
		"index.number_of_shards": 2,
		"index.number_of_replicas": 1,
		"index.routing.allocation.require._name": null,
		"index.blocks.write": null
	}
}
'

test2-new 가 새로 생겼다.

shards 탭에 들어가서 확인해보면

test2를 지우진 않고, test2-new에 primary 2개, replica 2개가 생성된 걸 확인할 수 있다.

4.2.3 핫-웜-콜드(Hot-warm-cold) 아키텍처 설정

핫-웜-콜드 아키텍처에서는 데이터 검색 빈도에 따라 핫/웜/콜드 노드에 저장한다. 핫-웜-콜드 아키텍처는 로그, 메트릭 및 트랜잭션 같은 시계열 데이터에 주로 사용된다. 시계열 데이터는 한 번 인덱싱되면 업데이트 될 가능성이 거의 없고, 시간이 지날수록 데이터 검색 빈도가 낮아지기 때문에 오래된 데이터를 저렴한 스토리지로 이동시켜 비용을 절감할 수 있다. 즉 처음에는 데이터를 성능이 좋고 비싼 핫 노드에 인덱싱하고, 일정 시간이 지나면 약간 느리지만 저렴한 웜 노드로 이동시키는 아키텍처를 핫-웜-콜드 아키텍처라고 부른다. 핫-웜-콜드 노드의 특징은 다음과 같다.

핫 노드
- 핫 노드에는 활발하게 검색하고 인덱싱하는 데이터를 저장한다.
- 디스크와 메모리의 IO 성능이 중요하다. (SSD 사용 추천)
웜 노드
- 자주 사용되지 않는 데이터는 핫 노드에서 웜 노드로 이동시킬 수 있다.
- 디스크 IO 성능은 중요하지 않지만, 대용량 데이터를 저장할 수 있도록 사이즈가 큰 디스크를 사용하는 것이 좋다. (HDD 사용 추천)
콜드 노드
- 더 이상 업데이트되지 않는 데이터를 웜 노드에서 콜드 노드로 이동시킬 수 있다.
- 콜드 노드로 데이터를 마이그레이션할 때 디스크 공간을 절약하기 위해 데이터를 압축할 수 있다.
- 검색 속도가 중요하지 않기 때문에 데이터를 메모리에 띄워 놓지 않고, 검색 요청이 올 때마다 인덱스 파일을 디스크에서 읽을 수도 있다.

예를 들어 최근 로그는 활발하게 인덱싱되고 검색되기 때문에 핫 노드에, 지난주 로그는 최근 로그만큼 자주 검색되지 않기 때문에 웜 노드에, 지난달 로그는 거의 검색되지 않지만 혹시 모를 상황에 대비해서 콜드 노드에 저장할 수 있다.

노드 2개와 ISM으로 핫-웜 아키텍처를 구성해보자. opensearch-d1은 핫 노드로, opensearch-d2는 웜 노드로 사용할 것이다. 모든 인덱스는 처음에는 핫 노드에 저장되고, 이후 ISM에 의해 웜 노드로 이동된다. 먼저 노드에 hot 또는 warm 태그를 붙여줘야 한다.

opensearch-d1 노드 설정 파일을 다음과 같이 수정하고, 노드를 재시작하자.

node.attr.temp: hot

opensearch-d2 노드 설정 파일을 다음과 같이 수정하고, 노드를 재시작하자.

node.attr.temp: hot

d1, d2 를 모두 hot으로 한 경우는 d3 노드를 warm으로 하자.

node.attr.temp: warm

sudo systemctl daemon-reload
sudo systemctl restart opensearch.service

temp라는 노드 속성과 hot, warm과 같은 태그 값은 임의로 설정한 것이며, 다른 어떤 값이든 사용할 수 있다. 단, ISM 템플릿에서도 동일한 값을 사용해야 한다. 다음 요청으로 노드 설정이 잘 적용되었는지 확인해보자.

$ curl -XGET "$OPENSEARCH_REST_API/_cat/nodeattrs?v&h=node,attr,value&pretty=true"

인덱스를 생성하면 샤드를 무조건 핫 노드에 할당하도록 인덱스 템플릿을 생성하자.

인덱스 템플릿은 새로운 인덱스를 생성할 때 사용할 설정 값을 미리 정의해놓은 것이다.

다음과 같이 logs-template이라는 인덱스 템플릿을 만든 경우, 앞으로 인덱스 이름이 logs-* 패턴과 일치하면 해당 인덱스는 자동으로 hot 노드에 할당된다.

index.plugins.index_state_management.rollover_alias는 해당 인덱스가 rollover할 때 사용할 인덱스 alias를 정의하는 필드다.

$ curl -XPUT "$OPENSEARCH_REST_API/_index_template/logs-template?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"index_patterns": [
		"logs-*"
	],
	"template": {
		"settings": {
			"index": {
				"plugins": {
					"index_state_management": {
						"rollover_alias": "logs"
					}
				},
				"routing": {
					"allocation": {
						"require": {
							"temp": "hot"
						}
					}
				}
			}
		}
	}
}
'

"index_patterns"는 "logs-*" : logs 프리픽스로 들어오는 인덱스에 대해 모두 같은 규칙을 적용하겠다는 뜻

index의 plugins를 index_state_management 플러그인의 세팅으로 rollover_alias를 logs 라는 alias로 줄 거야 라는 뜻.

routing을 할 건데, allocation reqire할 건데, temp라는 attribute의 hot이라는 걸로 allocation할 거다. 라는 규칙

logs-test 인덱스를 생성해보자.

(d1: hot, d2: warm) 세팅인 경우
- 프라이머리 샤드만 핫 노드에 할당된 것은 hot으로 태깅된 노드가 한 개 뿐인 상황에서 레플리카 샤드를 동일한 노드에 할당할 수 없기 때문이다.
(d1,d2: hot, d3: warm) 세팅인 경우
- 프라이머리 샤드, 리플리카 샤드 모드 d1, d2 에 각각 할당된다. d3 는 warm이므로 할당되지 않는다.

$ curl -XPUT "$OPENSEARCH_REST_API/logs-test/_doc/1?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"content": "Hello, OpenSearch!"
}
'

logs-test에 id 1번에 데이터가 만들어졌다.!

get으로 바로 조회가 되는 모습.

index가 가지고 있는 settings를 조회해 보자.

GET logs-test/_settings?pretty=true

routing이 hot에 allocation 돼라 라고 되어 있고
rollover_alias도 logs 로 되어 있는 것을 확인할 수 있다.
아까 index template으로 된게 잘 적용된 것을 확인할 수 있다.

indices 탭에 가서 보면

logs-test 라는 index 가 생성된 것을 확인할 수 있다.

shards 탭에 가보면

(d1,d2: hot, d3: warm) 세팅인 경우

opensearch_d1,opensearch_d2 에 들어가 있는 모습이다

다른 친구들이 d1,d2에 들어가 있는 것들은 우연일 수 있지만 얘네들은 아닌 게, Hot인 친구한테만 allocation 해달라고 했고, d1, d2가 hot이기 때문에 프라이머리, 리플리카가 여기에 위치했다.

d1: hot, d2: warm, d3-nothing 인경우. replica를 위치할 hot이 없으므로 yellow

다음과 같은 방식으로 인덱스를 관리하는 ISM 정책을 생성해보자. 테스트를 위해 index_patterns에는 일부러 wildcard를 사용하지 않았다. 즉 logs-000001 인덱스에 대해서만 ISM 정책이 적용될 것이다.

인덱스는 hot 상태에서 시작하고, 샤드는 핫 노드에 할당된다.
hot 인덱스는 1분 후에 rollover를 한다.
rollover를 하고 5분이 지나면 warm 상태가 되고, 레플리카 샤드가 제거되면서 웜 노드에 재배치된다.

인덱스는 hot 상태에서 시작하고, 샤드는 핫 노드에 할당된다. 에 대한 설정

$ curl -XPUT "$OPENSEARCH_REST_API/_plugins/_ism/policies/hot-warm?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"policy": {
		"description": "hot-warm architecture",
		"error_notification": null,
		"default_state": "hot",
		"states": [
			{
				"name": "hot",
				"actions": [
					{
						"retry": {
							"count": 3,
							"backoff": "exponential",
							"delay": "1m"
						},
						"rollover": {
							"min_index_age": "1m"
						}
					}
				],
				"transitions": [
					{
						"state_name": "warm",
						"conditions": {
							"min_rollover_age": "5m"
						}
					}
				]
			},
			{
				"name": "warm",
				"actions": [
					{
						"retry": {
							"count": 3,
							"backoff": "exponential",
							"delay": "1m"
						},
						"replica_count": {
							"number_of_replicas": 0
						}
					},
					{
						"retry": {
							"count": 3,
							"backoff": "exponential",
							"delay": "1m"
						},
						"allocation": {
							"require": {
								"temp": "warm"
							},
							"include": {},
							"exclude": {},
							"wait_for": false
						}
					}
				],
				"transitions": []
			}
		],
		"ism_template": [
			{
				"index_patterns": [
					"logs-000001"
				]
			}
		]
	}
}
'

이 ISM 정책의 이름은 hot-warm architecture이며, 인덱스가 생성되면 가장 먼저 hot 상태로 진입한다. hot 상태는 인덱스가 생성된 직후부터 적용되며, 인덱스의 나이가 1분 이상이 되면 rollover 작업이 수행된다. 이때 새로운 인덱스가 생성되며, 이후 데이터는 해당 인덱스에 기록되고 기존 인덱스는 읽기 전용으로 전환된다. rollover는 실패 시 최대 3회까지 재시도되며, 재시도 간에는 지수적 backoff 전략이 적용되고 딜레이는 1분이다.

rollover가 수행된 후 기존 인덱스는 최소 5분이 지나야 warm 상태로 전환된다. 상태 전이는 OpenSearch 내부 ISM 모듈이 조건을 확인해 자동으로 처리한다.

warm 상태로 진입하면 두 가지 작업이 실행된다. 첫 번째는 리플리카 수를 0으로 설정하는 작업으로, warm 상태에서는 복제본을 유지하지 않아 디스크 자원을 절약할 수 있다. 이 작업도 실패 시 3회 재시도와 1분 backoff가 적용된다. 두 번째는 allocation 설정이다. warm 상태의 인덱스는 클러스터 내에서 temp 어트리뷰트가 warm인 노드로 shard가 재배치된다. 이 설정 역시 동일한 retry 조건이 적용되며, 핫 데이터와 웜 데이터를 처리하는 노드를 분리하는 데 목적이 있다.

warm 이후의 전이 상태는 정의되어 있지 않으므로 인덱스는 해당 상태에서 유지된다. 이 정책은 logs-000001 패턴의 인덱스에 자동 적용되며, 해당 이름을 가진 인덱스는 생성 즉시 본 정책을 따른다.

오른쪽 응답 결과

{
  "_id": "hot-warm",
  "_version": 1,
  "_primary_term": 1,
  "_seq_no": 0,
  "policy": {
    "policy": {
      "policy_id": "hot-warm",
      "description": "hot-warm architecture",
      "last_updated_time": 1754004492852,
      "schema_version": 1,
      "error_notification": null,
      "default_state": "hot",
      "states": [
        {
          "name": "hot",
          "actions": [
            {
              "retry": {
                "count": 3,
                "backoff": "exponential",
                "delay": "1m"
              },
              "rollover": {
                "min_index_age": "1m"
              }
            }
          ],
          "transitions": [
            {
              "state_name": "warm",
              "conditions": {
                "min_rollover_age": "5m"
              }
            }
          ]
        },
        {
          "name": "warm",
          "actions": [
            {
              "retry": {
                "count": 3,
                "backoff": "exponential",
                "delay": "1m"
              },
              "replica_count": {
                "number_of_replicas": 0
              }
            },
            {
              "retry": {
                "count": 3,
                "backoff": "exponential",
                "delay": "1m"
              },
              "allocation": {
                "require": {
                  "temp": "warm"
                },
                "include": {},
                "exclude": {},
                "wait_for": false
              }
            }
          ],
          "transitions": []
        }
      ],
      "ism_template": [
        {
          "index_patterns": [
            "logs-000001"
          ],
          "priority": 0,
          "last_updated_time": 1754004492852
        }
      ]
    }
  }
}

GET으로 잘 적용이 되었는지 바로 확인 가능.

그러면 대상이 될 index를 만들어보자.

다음 요청으로 ISM 정책이 적용될 logs-000001 인덱스를 생성하고, logs alias에 추가해주자.

$ curl -XPUT "$OPENSEARCH_REST_API/logs-000001?pretty=true"
	-H "Content-Type: application/json" \
	-d '
{
	"aliases": {
			"logs": {
				"is_write_index": true
			}
		}
}
'

indices 에서 확인해보면
Aliases가 맵핑된 것을 확인할 수 있다.

다음과 같이 explain API를 활용하면 해당 인덱스에 어떤 ISM 정책이 적용되었고, 현재 어떤 상태에 있는지 확인할 수 있다. 인덱스에 어떤 ISM 정책이 적용되는 데는 몇 분 정도 걸린다.

$ curl -XGET "$OPENSEARCH_REST_API/_plugins/_ism/explain/logs-000001?pretty=true"

이제는 데이터를 logs-000001에 넣어보자.

curl - XPUT "$OPENSEARCH_REST_API/logs-000001/_doc/1?pretty=true"
	-H "Content-Type: application/json" \
	-d '
{
	"aliases": "hello, world!"
}
'

그 다음

$ curl -XGET "$OPENSEARCH_REST_API/_plugins/_ism/explain/logs-000001?pretty=true"

plugins로 상태를 확인해보자.

1단계: hot-warm 정책이 logs-000001 인덱스에 성공적으로 적용되면 다음과 같은 응답 본문이 온다. 현재는 hot 상태에 있다.

2단계: logs-000001 인덱스가 rollover되면서 logs-000002 인덱스가 생성됐다.

3단계: rollover 를 성공적으로 마치고, transition 을 evaluation 했다. 하지만 아직 조건이 맞지 않아서 다음 시도를 기다릴 때 다음과 같은 응답이 나온다.

failed 가 false 이므로 실패한 것은 아니다.

4단계: Transition 조건이 맞아 transition을 시도하고 있다. 이 과정에서 노드간 복사가 일어나므로 시간이 오래 걸린다.

완료: warm 으로의 transition 이 완료되면 다음과 같은 메세지를 받을 수 있다.

Successfully updated allocation setting

샤드 결과

logs-000001 인덱스가 warm 상태로 바뀌면서 레플리카 샤드가 없어지고, 웜 노드(opensearch-d2)로 이동한 것을 확인할 수 있다.

📌 ElasticSearch에서는 ILM(Index Lifecycle Management)을 통해 인덱스 라이프사이클을 관리할 수 있다. ISM과 ILM은 모두 rollover된 인덱스 기반으로 작동하며, 인덱스는 인덱스 크기, 도큐먼트 개수 등을 기준으로 rollover된다. ISM에서 핫-웜 노드 타입은 앞서 본 것처럼 노드 속성으로 구분되는 반면, ISM은 노드 타입 자체로 구분된다. 예를 들어 ElasticSearch는 node.roles: [ data_hot ] 처럼 설정하면 핫 노드로 구분할 수 있다. 또한 ISM은 핫-웜-콜드 아키텍처를 구성하기 위해 직접 템플릿을 정의해야 하지만, ILM은 기본 템플릿으로 제공된다.

Hyunjun Kim

Data Analytics Engineer 가 되

이전 포스트

[AWS] 인덱스 라이프사이클 관리 실습

실습 - (AWS 환경)

4.2.1 rollover API

인덱스 이름이 `my_index_000001`인데, 언더스코어(_)가 아니라 하이픈(-) 을 사용해야 된다.

4.2.2 shrink API

4.2.3 핫-웜-콜드(Hot-warm-cold) 아키텍처 설정

[AWS] OpenSearch의 인덱스와 샤드 관리

0개의 댓글

[AWS] 인덱스 라이프사이클 관리 실습

실습 - (AWS 환경)

4.2.1 rollover API

인덱스 이름이 my_index_000001인데, 언더스코어(_)가 아니라 하이픈(-) 을 사용해야 된다.

4.2.2 shrink API

4.2.3 핫-웜-콜드(Hot-warm-cold) 아키텍처 설정

[AWS] OpenSearch의 인덱스와 샤드 관리

0개의 댓글

인덱스 이름이 `my_index_000001`인데, 언더스코어(_)가 아니라 하이픈(-) 을 사용해야 된다.