[Elasticsearch] ILM

ILM(Index Lifecycle Management)

• Elasticsearch의 인덱스 수명 주기를 자동으로 관리하기 위한 기능
• 로깅 시스템처럼 인덱스가 계속해서 쌓이는 환경에서 인덱스를 효율적으로 관리 가능
• ILM을 사용하면 인덱스가 생성된 후의 상태를 단계별로 정의하고, 각 단계에서 수행할 작업 지정 가능하며 이를 통해 인덱스의 크기와 성능을 최적화하고, 스토리지 비용을 절감하며, 인덱스 수명 주기 전반에 걸쳐 데이터를 효율적으로 관리 가능
  • 인덱스가 특정 크기 또는 문서 수에 도달하면 새 인덱스를 생성
  • 특정 기간이 지나면 새로운 인덱스를 생성하고 이전 인덱스를 보관
  • 아주 오래된 인덱스를 제거

 

ILM의 주요 개념

 

1. 수명 주기 정책(Lifecycle Policy)

• 인덱스의 수명 주기를 정의하는 정책
• 각 정책은 여러 단계로 구성되며, 각 단계는 일련의 작업을 포함

 

2. 단계(Phase)

• 수명 주기 정책은 네 가지 주요 단계로 구성
  • Hot 단계: 데이터가 가장 활발하게 인덱싱 되고 검색되는 단계이며 성능이 중요한 데이터가 주로 이 단계에 존재
  • Warm 단계: 데이터의 인덱싱 빈도가 줄어들지만 여전히 검색 가능한 상태이며 성능 요구사항이 낮아지며, 비용을 절감하기 위해 자원을 줄일 수 있음
  • Cold 단계: 데이터가 거의 변경되지 않고, 검색 빈도도 낮은 상태이며 비용을 보다 절감하기 위해 저비용 스토리지에 저장될 수 있음
  • Delete 단계: 데이터가 더 이상 필요하지 않을 때 인덱스를 삭제하는 단계

 

3. Elasticsearch의 multi-tier 구조

• Elasticsearch 7.10부터 data-tier 개념 소개
• 노드의 role을 통해 hot/warm/cold/frozen 아키텍처를 구현할 수 있는 방법 제공
• data-tier: 하드웨어 특성이나 가용성과 관련된 특성을 공유하는 노드 모음
  • content-tier: 시스템 인덱스와 데이터 스트림이 아닌 인덱스를 자동으로 할당하는 필수 티어이며 모든 데이터 티어 중에서 default로 설정되어 있으며, 컨텐츠가 시간이 지나도 비교적 일정하게 유지되며 문서를 다른 계층으로 마이그레이션 할 필요가 없는 데이터를 보관
  • hot-tier: 가장 빈번하게 접근되는 데이터를 저장하며 색인 생성과 같은 높은 I/O 작업을 처리하기 위해 최적화
  • warm-tier: hot-tier보다는 덜 접근되지만 여전히 중요한 데이터를 저장하며 이 때문에 hot-tier보다 비용 효율적인 스토리지를 사용
  • cold-tier: warm-tier보다 덜 자주 접근되는 데이터를 저장하며 더 이상 업데이트되지 않을 가능성이 높은 문서를 저장
  • frozen-tier: 거의 접근되지 않는 데이터를 저장하며 해당 티어는 데이터를 압축하여 저장 공간을 최소화

 

ILM이 필요한 이유

• 자동화된 관리: 인덱스의 생성, 보관, 삭제 등을 자동으로 관리할 수 있게 함으로써 수동 관리에 비해 시간과 리소스 절약 가능
• 비용 최적화: 오래된 데이터를 더 저렴한 저장소로 이동시키거나 필요없는 데이터를 삭제함으로써 저장 비용을 최적화 가능
• 성능 향상: 최신 데이터와 오래된 데이터를 적절한 저장소로 이동시킴으로써 시스템의 전반적인 성능 향상 가능
• 규정 준수: 데이터 보관 기간을 규제하는 규정을 자동으로 준수하며 필요 기간 동안 데이터를 보관하고 이후 자동으로 삭제 가능
• 데이터 가용성: 데이터의 중요도에 따라 다른 레벨의 가용성 설정 가능하기 때문에 최신 데이터는 빠른 검색을 위해 높은 가용성을 유지할 수 있고, 오래된 데이터는 저렴한 비용으로 낮은 가용성 설정 가능

 

ILM 예시

• 이번 예시는 간단하게 실습하기 위해 기간을 극단적으로 단축시켰습니다.
• 실제 적용하기 위해서는 각 시스템 특성을 고려하여 기간 혹은 문서 수 산정 필요합니다.

 

1. Elasticsearch Cluster 구성

• es01: data_content, data_hot
• es02: data_warm
• es03: data_cold

 

2. ILM Policy 구성

 

	{
	"my-ilm": {
	"version": 1,
	"modified_date": "2024-06-27T09:32:12.385Z",
	"policy": {
	"phases": {
	"cold": {
	"min_age": "5d",
	"actions": {
	"set_priority": {
	"priority": 0
	}
	}
	},
	"hot": {
	"min_age": "0ms",
	"actions": {
	"rollover": {
	"max_docs": 10
	},
	"set_priority": {
	"priority": 100
	}
	}
	},
	"warm": {
	"min_age": "2d",
	"actions": {
	"allocate": {
	"number_of_replicas": 0,
	"include": {},
	"exclude": {},
	"require": {}
	},
	"forcemerge": {
	"max_num_segments": 2
	},
	"set_priority": {
	"priority": 50
	}
	}
	},
	"delete": {
	"min_age": "20d",
	"actions": {
	"delete": {
	"delete_searchable_snapshot": true
	}
	}
	}
	}
	}
	}
	}

view raw .json hosted with ❤ by GitHub

 

 

부연 설명

• Hot 단계에서 인덱스는 즉시 생성되고, 최대 10개의 문서에 도달하면 롤오버 되며, 높은 우선순위를 가짐
• Warm 단계로 2일 후 넘어가며, 복제본 수를 0으로 줄이고, 세그먼트를 2개로 병합하며, 우선 순위를 50으로 낮춤
• Cold 단계로 5일 후 넘어가며, 우선 순위를 0으로 설정하여 접근 빈도가 낮아진 데이터를 관리
• Delete 단계로 20일 후 넘어가며, 인덱스와 관련된 스냅샷을 삭제하여 스토리지를 확보

 

3. Index Template 구성

 

	{
	"index": {
	"lifecycle": {
	"name": "my-ilm",
	"rollover_alias": "my-index"
	},
	"number_of_shards": "1",
	"number_of_replicas": "1"
	}
	}

view raw .json hosted with ❤ by GitHub

 

 

부연 설명

• index: 인덱스와 관련된 설정을 포함하는 최상위 키
• lifecycle: 인덱스 수명 주기 관리(ILM)와 관련된 설정을 포함
  • name: 적용할 ILM 정책명
  • rollover_alias: 롤오버 작업에 사용할 인덱스 별칭이며 롤오버는 데이터 양이 많아지거나 일정 시간이 지나면 새 인덱스를 생성하고 현재 인덱스를 아카이브 하는 작업

 

• number_of_shards: 인덱스를 생성할 때 기본적으로 설정할 샤드(Shard)의 수이며 샤드는 Elasticsearch에서 데이터를 분산 저장하는 단위
• number_of_replicas: 각 샤드의 복제본 수를 지정하며 복제본은 데이터 가용성과 내결함성을 높이기 위해 사용

 

4. ILM polling 주기 단축

• polling 주기는 default로 10분
• 하지만 해당 예제에서는 빠른 결과 확인을 위해 3초로 단축

 

	PUT _cluster/settings
	{
	"transient": {
	"indices.lifecycle.poll_interval": "3s"
	}
	}

view raw .json hosted with ❤ by GitHub

 

5. 롤어버 인덱스 설정

 

	PUT my-index-000001
	{
	"aliases": {
	"my-index": {
	"is_write_index": true
	}
	}
	}

view raw .json hosted with ❤ by GitHub

 

부연 설명

• 이 설정은 롤오버 인덱스를 사용할 때 유용
• ex) my-index라는 별칭을 통해 데이터가 지속적으로 인덱싱 되지만, 인덱스가 일정 크기나 문서 수에 도달하면 새로운 인덱스로 롤오버할 수 있음
  • 다음 롤오버 시에는 새로운 인덱스(my-index-000002 등)를 생성하고 해당 인덱스를 my-index 별칭의 새로운 쓰기 인덱스로 설정할 수 있음 (문서가 10개 이상이고 ILM polling에 의해 감지되면 롤오버 진행)
  • 이렇게 하면 애플리케이션은 항상 my-index 별칭을 통해 데이터에 접근할 수 있으며, 백엔드에서는 인덱스 관리에 용이

 

롤오버 된 것을 확인

 

6. my-index 인덱스의 생성 시점을 수동으로 설정하여 data-warm에 저장되도록 처리

 

	PUT my-index/_settings
	{
	"index.lifecycle.origination_date": 1718876413
	}

view raw .json hosted with ❤ by GitHub

 

부연 설명

• 만약 인덱스가 실제로는 오래 전에 생성되었으나 ILM 정책 적용이 늦게 설정되었을 경우, index.lifecycle.origination_date를 수동으로 설정하여 ILM 정책이 제대로 적용 가능
• 이 설정이 없다면 ILM 정책은 인덱스 생성 시점을 현재 시점으로 간주하게 되지만, 이 값을 설정하면 인덱스의 나이를 올바르게 인식
• epoch timestamp 기준이므로 epoch converter 사이트 가서 참고하는 것을 권장

 

7. my-index 인덱스의 생성 시점을 수동으로 설정하여 data-cold에 저장되도록 처리

 

	PUT my-index/_settings
	{
	"index.lifecycle.origination_date": 1718876413
	}

view raw .json hosted with ❤ by GitHub

 

8. 특정 티어에 인덱스 할당되도록 처리

 

	PUT my-test7
	{
	"settings": {
	"index.routing.allocation.include._tier_preference": "data_cold",
	"number_of_replicas": 0
	}
	}

view raw .json hosted with ❤ by GitHub

 

부연 설명

• _tier_preference: Elasticsearch에서 데이터 계층(tier)을 지정하여 데이터 저장소를 최적화할 수 있음
  • ex) 자주 접근되는 데이터를 hot 계층에, 덜 자주 접근되는 데이터를 warm 계층에, 거의 접근하지 않는 데이터를 cold 계층에 저장하는 방식

 

참고

• 패스트 캠퍼스 -  고성능 검색 엔진 구축으로 한 번에 끝내는 Elasticsearch