Elasticsearch 입문 6편 — ILM·Aliases·Rollover (시계열 데이터 라이프사이클 관리)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 6편이에요. 5편(Index 관리)에서 Create·Settings·Alias·Reindex 의 기초 공정을 잡았다면, 이번 6편은 "한 번 만든 인덱스를 시간이 지나면서 어떻게 늙히고, 언제 새 인덱스로 갈아끼우고, 마지막엔 어떻게 폐기하느냐" 운영 라이프사이클에 들어갈 차례예요.

시계열 데이터를 한 인덱스에 영원히 박으면 어떻게 되나

운영 첫 해의 흔한 실수가 있어요. "로그 인덱스 하나 만들고 거기에 계속 색인하면 되겠지" 하고 logs-app 하나에 1년 치 로그를 다 박는 거예요. 처음엔 잘 돌다가 3개월쯤 지나면 증상이 줄줄이 나오기 시작합니다.

첫째, 샤드(shard) 크기 폭증. 5편에서 본 Primary Shard 가 한 번 정하면 갯수 변경이 부담스럽다는 그 자리예요. 데이터가 늘어나면 샤드 하나당 크기가 50GB → 200GB → 500GB 로 커지고, 권장치인 샤드당 10~50GB 를 한참 넘어가요. 검색 한 번에 메모리·CPU 가 통째로 쓸려요.

둘째, 삭제가 비싸요. "3개월 지난 로그 지워주세요" 라는 요구가 들어왔을 때, 한 인덱스 안에서 _delete_by_query 로 일부만 지우는 작업은 세그먼트(segment) 재작성 을 동반해서 디스크·CPU 를 잡아먹어요. 진짜 디스크가 비워지지도 않고요. 세그먼트 단위로 통째로 폐기 하는 게 ES 가 가장 잘하는 일인데, 한 인덱스 안에선 그게 안 돼요.

셋째, 데이터 온도(hot/warm)가 안 나뉘어요. 어제 들어온 로그는 오늘도 검색되는 뜨거운 데이터 고, 6개월 전 로그는 컴플라이언스 때문에 보관만 하지 거의 안 찾는 차가운 데이터 예요. 같은 인덱스에 두면 비싼 NVMe SSD (Non-Volatile Memory express, PCIe 기반 초고속 SSD) 디스크 위에 둘 다 올라가서 비용이 폭증해요.

이 세 가지 문제를 한 인덱스 → 시간 단위로 잘게 쪼갠 여러 인덱스 + 오래된 인덱스는 자동으로 싼 디스크로 이동 + 수명 다한 인덱스는 자동 삭제 패턴으로 풀어 주는 게 이번 글의 주제 ILM 이에요.

ILM 이란 — Index Lifecycle Management

ILM (Index Lifecycle Management, 인덱스 수명 주기 관리) 은 Elasticsearch 6.7 부터 정식 기능으로 들어온, 인덱스를 시간이 지남에 따라 자동으로 다음 단계로 옮겨 주는 정책 엔진이에요. 운영자가 "30일 지나면 warm 단계로, 90일 지나면 cold 로, 1년 지나면 삭제" 같은 규칙을 JSON 정책 한 번 박아 두면, 이후로는 ES 가 알아서 인덱스를 옮기고 폐기합니다.

5개 단계가 있어요. Hot · Warm · Cold · Frozen · Delete — 이 다섯 단어를 순서대로 외워 두면 ILM 의 80% 가 잡혀요.

각 단계는 진입 조건 과 수행 액션 두 가지로 구성돼요. 진입 조건은 "이전 단계 진입 후 N일 경과" 같은 시간 기반이 가장 흔하고, "인덱스 크기 N GB 초과" 나 "문서 수 N건 초과" 같은 조건도 가능해요. 수행 액션은 단계마다 다른데 — 대표적으로 Hot 단계의 rollover, Warm 단계의 forcemerge·shrink, Cold 단계의 searchable_snapshot, Delete 단계의 delete 가 있어요.

ILM 은 기본 10분 주기 로 모든 인덱스를 스캔해서, 정책 조건을 만족한 인덱스를 다음 단계로 넘겨요. 이 주기는 indices.lifecycle.poll_interval 설정으로 조절 가능하지만, 일반적으로 기본값 그대로 두는 게 표준이에요.

ILM 을 사용하려면 기본 라이선스 (Basic, 무료) 면 충분해요. Hot/Warm/Cold/Delete 까지는 무료 티어에서 다 돌고, Frozen 단계 의 searchable_snapshot 액션만 Enterprise 라이선스가 필요해요.

Hot·Warm·Cold·Frozen 단계 — 각각 무엇을 의미하나

5단계가 각각 어떤 디스크 위에 살고, 어떤 빈도로 검색되고, 어떤 인스턴스 타입에 어울리는가 를 그림으로 그려 두면 운영 결정이 훨씬 쉬워져요.

Hot — 지금 쓰고 자주 읽는 단계

가장 최근 데이터가 살아 있는 단계예요. NVMe SSD (또는 그에 준하는 Local SSD) 위에 올라가고, 쓰기·읽기 둘 다 활발 하게 일어나요. 인스턴스 사양도 가장 비싼 r6id·i4i 계열 — 메모리·디스크 IOPS 둘 다 빵빵한 노드.

여기서 일어나는 가장 중요한 액션이 rollover 예요. "이 인덱스 크기가 50GB 가 넘었거나, 만든 지 1일이 지났거나, 문서 수가 2억 건이 넘으면 새 인덱스로 갈아끼워라" 같은 조건을 박아 두고, 조건 만족 시 새 인덱스가 자동으로 만들어지고 write alias 가 거기로 옮겨가는 패턴이에요. 다음 절에서 깊이.

예시 — logs-app-000001 이 50GB 차면 logs-app-000002 가 만들어지고, alias logs-app-write 가 002 로 이동. 001 은 이제 읽기 전용 Hot 단계 인덱스 가 돼요.

Warm — 읽기는 하지만 쓰지 않는 단계

Hot 단계에서 rollover 된 인덱스가 며칠 지나면 Warm 으로 이동해요. NVMe SSD 또는 SATA SSD 위에 살고, 쓰기는 더 이상 일어나지 않아요 (rollover 됐으니까). 읽기는 가끔 — 어제 로그를 디버깅으로 들여다보는 정도.

여기서 자주 하는 액션 두 가지가 forcemerge 와 shrink 예요. forcemerge 는 인덱스 안의 세그먼트들을 하나로 합쳐서 검색 성능을 끌어올리고 디스크를 정리해요. 쓰기가 더 이상 안 일어나는 단계라야 안전. shrink 는 Primary Shard 갯수를 줄이는 작업이에요 — 예를 들어 Hot 단계에서 Primary 5개 로 만들었던 인덱스를 Warm 으로 가면서 Primary 1개 로 줄여서 오버헤드를 절약.

Cold — 거의 읽지 않고 보관만 하는 단계

Warm 단계에서 한 달쯤 더 지나면 Cold 로 가요. SATA HDD (Serial ATA Hard Disk Drive, 전통 회전 디스크) 같은 느리지만 싼 디스크 위에 살아요. 읽기는 분기에 한 번 정도. 검색 응답이 수 초~수십 초 걸려도 OK 인 데이터 자리.

여기서 핵심 액션이 searchable_snapshot 이에요. Searchable Snapshot 은 인덱스를 S3 같은 오브젝트 스토리지로 옮기되, 검색은 여전히 가능하게 유지하는 기능이에요. 디스크 비용이 NVMe SSD 대비 1/10~1/20 수준으로 떨어져요. Replica 를 0으로 줄여도 S3 자체가 11 nines 내구성을 보장해 줘서 데이터 손실 위험이 거의 없어요.

Frozen — 컴플라이언스 보관용 단계

Cold 보다 한 단계 더 차가운 자리예요. 완전히 S3 위에만 살고, 로컬 디스크엔 인덱스 메타데이터만 캐시로 있어요. 검색은 분 단위 응답을 각오해야 하고, 법적 보관 의무 가 있어서 지우면 안 되지만 거의 안 보는 1~7년 차 데이터 자리예요.

Frozen 액션은 Enterprise 라이선스 가 필요한 유일한 단계예요. OpenSearch 진영엔 Cold Storage 라는 비슷한 개념이 있지만 세부 구현이 달라요.

Delete — 수명 끝, 폐기

마지막 단계예요. 컴플라이언스 보관 기간이 끝나면 인덱스를 통째로 삭제해요. 세그먼트 단위 통삭제 라서 비용이 거의 0 — 이게 한 인덱스 안에서 _delete_by_query 하는 것보다 압도적으로 효율적 인 이유예요.

단계 요약 표

이 표 한 장이 운영 비용 설계의 출발점이에요. 어느 단계에 얼마 머물게 할지 만 결정하면, 인스턴스 청구서가 거의 그대로 따라옵니다.

Rollover — write alias 패턴

ILM 의 심장이 rollover 액션이에요. 시계열 인덱스를 시간 단위로 잘게 쪼개되, 앱은 그 사실을 모르게 만들어 주는 메커니즘.

핵심 아이디어 두 가지. 첫째, 인덱스 이름은 숫자 접미사를 붙여 logs-app-000001, logs-app-000002 식으로 자동 증가시켜요. 둘째, 앱이 색인할 때 쓰는 이름은 인덱스 이름이 아니라 alias 인 logs-app 또는 logs-app-write — 이걸 write alias 라 불러요. rollover 가 일어나면 ES 가 새 인덱스를 만들고 write alias 를 거기로 자동으로 옮겨 줘요.

_rollover API 호출

수동으로 rollover 를 트리거할 때는 이런 형태예요.

POST logs-app-write/_rollover
{
  "conditions": {
    "max_size":  "50gb",
    "max_age":   "1d",
    "max_docs":  200000000
  }
}

세 조건 중 하나라도 만족 하면 새 인덱스가 만들어져요. ILM 안에 박아 두면 10분 주기로 ES 가 자동으로 이걸 호출해요.

초기 셋업 — write alias 만들기

처음 인덱스를 만들 때 반드시 write alias 를 함께 박아야 해요. 안 하면 rollover 가 작동을 안 합니다. 이게 6편에서 가장 자주 나는 사고 1위.

PUT logs-app-000001
{
  "aliases": {
    "logs-app-write": {
      "is_write_index": true
    }
  }
}

is_write_index: true 가 핵심이에요. 한 alias 가 여러 인덱스 를 가리킬 수 있는데, 쓰기는 그중 하나에만 가야 하니까 명시적으로 표시해 줘요. rollover 가 일어나면 ES 가 자동으로 이전 인덱스의 is_write_index 를 false 로 내리고 새 인덱스를 true 로 올려요.

조건 설계 가이드

세 조건을 어떻게 잡느냐 가 운영 품질을 좌우해요. 데이터 양·인덱스 패턴·검색 요구 에 따라 다르지만 흔한 가이드는 이래요.

• 로그 데이터 (일별 패턴) — max_age: 1d + max_size: 50gb 조합. 하루에 한 번 rollover, 단 트래픽 폭증 시 50GB 도달하면 그때 또.
• 메트릭 데이터 (분당 수백만 건) — max_size: 50gb 만으로 충분. 시간 조건은 빼고 크기로만.
• e-commerce 주문 로그 — max_age: 7d + max_docs: 100000000. 주 단위 묶음.

Primary Shard 갯수 도 50GB 도달 시 한 샤드당 10GB 가 되도록 5개 정도로 잡는 게 표준. 그러면 rollover 직후 새 인덱스도 5개 샤드로 시작.

ILM Policy 작성 예제

정책은 JSON 으로 만들어서 _ilm/policy API 에 PUT 해요. 한 번 만들면 인덱스 템플릿에 연결해서 그 패턴의 모든 인덱스에 자동 적용 시키는 게 표준 흐름.

Step 1 — Policy 정의

PUT _ilm/policy/logs-app-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age":  "1d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "shrink":     { "number_of_shards": 1 },
          "allocate":   { "include": { "data": "warm" } },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "searchable_snapshot": { "snapshot_repository": "found-snapshots" },
          "set_priority": { "priority": 0 }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

5단계 중 Frozen 은 생략 했고, 4단계 (Hot 7일 → Warm 23일 → Cold 11개월 → Delete) 구성이에요. min_age 는 인덱스가 rollover 된 시점부터 N일 경과 라는 뜻 — 현재 인덱스 생성 시점이 아니라 그 인덱스의 rollover 가 끝난 이후 인 점이 헷갈리기 쉬워요.

Step 2 — Index Template 에 연결

정책을 만들었으면, 그 정책을 어떤 인덱스 패턴에 적용할지 index template 에 박아요.

PUT _index_template/logs-app-template
{
  "index_patterns": ["logs-app-*"],
  "template": {
    "settings": {
      "number_of_shards":   5,
      "number_of_replicas": 1,
      "index.lifecycle.name":            "logs-app-policy",
      "index.lifecycle.rollover_alias":  "logs-app-write"
    }
  }
}

두 줄이 핵심이에요. index.lifecycle.name 으로 정책을 연결하고, index.lifecycle.rollover_alias 로 어느 write alias 를 회전시킬지 알려줘요. 이 두 줄 중 하나라도 빠지면 rollover 가 안 돼요.

Step 3 — 초기 인덱스 + alias 만들기

PUT logs-app-000001
{
  "aliases": {
    "logs-app-write": { "is_write_index": true }
  }
}

이게 끝이에요. 이후 앱은 logs-app-write 라는 alias 로 색인 하면, ILM 이 알아서 50GB 또는 1일 마다 새 인덱스를 만들고, 7일 지나면 Warm, 30일 지나면 Cold, 1년 지나면 삭제까지 돌려 줘요.

Step 4 — 상태 확인

운영 중 어느 인덱스가 지금 어느 단계에 있는가 확인할 때는 _ilm/explain 을 써요.

GET logs-app-*/_ilm/explain

응답에 phase, action, step, age 같은 필드가 나와서 어디서 멈췄는지 한눈에 보여요. 사고 진단 1순위 명령어.

Data Stream — 8.x 시계열 데이터 추상화

7.9 부터 들어온 Data Stream 은 위에서 본 alias + rollover + ILM 셋업을 한 통에 묶어 주는 추상화 예요. 8.x 부터는 시계열 데이터의 권장 패턴 으로 굳어졌어요.

핵심 차이는 세 가지예요. 첫째, write alias 를 직접 만들 필요가 없어요 — Data Stream 이름 자체가 alias 역할을 해요. 둘째, 백킹 인덱스 (backing index) 이름은 ES 가 자동 생성하는 .ds-logs-app-2026.05.19-000001 형태로 날짜가 박혀 있어서 운영 추적이 쉬워요. 셋째, Data Stream 은 append-only 라 update/delete by query 같은 행위가 막혀 있어요 — 시계열 데이터의 일반적 사용 패턴과 정합.

Data Stream 만들기

PUT _index_template/logs-app-template
{
  "index_patterns": ["logs-app"],
  "data_stream": {},
  "template": {
    "settings": {
      "number_of_shards":   5,
      "number_of_replicas": 1,
      "index.lifecycle.name": "logs-app-policy"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "message":    { "type": "text" }
      }
    }
  }
}

POST logs-app/_doc
{
  "@timestamp": "2026-05-19T10:30:00Z",
  "message":    "hello"
}

data_stream: {} 한 줄만 박으면 끝이에요. 첫 색인 요청이 들어오면 ES 가 백킹 인덱스를 자동 생성하고 ILM 정책을 자동 연결 해요. @timestamp 필드가 필수 라는 점만 기억하면 됩니다.

Data Stream 의 운영 이점

• 백킹 인덱스 이름에 날짜 가 박혀서 언제 만들어진 인덱스 인지 한눈에 보임.
• write alias 누락 사고 가 구조적으로 불가능 — 추상화 자체가 그 자리를 막아 줌.
• Data Tier 자동 인식 — Hot/Warm/Cold 노드가 클러스터에 있으면 단계 전환이 자동.
• Logs/Metrics/Traces 같은 관측 데이터 통합 — Elastic Observability 와 Fleet 가 Data Stream 을 기본 단위로 씀.

기존 alias + rollover 패턴이 틀린 건 아니지만, 신규 8.x 클러스터에서 시계열 데이터를 다룬다면 Data Stream 이 표준 이에요.

자주 만나는 사고

운영 6개월 차에 가장 자주 나는 사고 6가지를 모았어요.

사고 1 — write alias 누락

원인 — 초기 인덱스 생성 시 is_write_index: true alias 를 안 박았거나, index template 에 index.lifecycle.rollover_alias 가 빠짐. rollover 가 트리거되지 않고 한 인덱스가 200GB · 5억 건 으로 부풀어 오름.

해결 — _ilm/explain 으로 어디서 멈췄는지 확인. check-rollover-ready 단계에서 alias not found 에러가 나면 alias 부터 박고 다시 풀어줘요. 신규 셋업이면 Data Stream 으로 전환해서 이 사고 자체를 막는 게 정답.

사고 2 — Rollover 조건 미적용

원인 — Policy 에 rollover 조건은 박혀 있는데, 그 정책이 어느 alias 를 회전시킬지 알려주는 index.lifecycle.rollover_alias 가 빠져 있음. ILM 이 정책을 실행하긴 하는데 대상 alias 를 모르니 rollover 단계에서 무한 대기.

해결 — Index template 의 settings 에 두 줄 (index.lifecycle.name + index.lifecycle.rollover_alias) 이 모두 들어가 있는지 확인. 한 줄만 빠져도 침묵 실패예요.

사고 3 — Data Tier 미설정

원인 — Warm/Cold 단계 액션에 allocate: { include: { data: "warm" } } 같은 노드 필터링이 박혀 있는데, 클러스터에 warm 태그가 박힌 노드가 없음. ILM 이 no eligible node 에러로 멈춰서 인덱스가 Hot 에 영원히 남음.

해결 — 모든 데이터 노드에 적절한 role 또는 attribute 를 박아 둬요. 8.x 부터는 node.roles: [data_hot, data_warm, data_cold, data_frozen] 식 명시적 데이터 티어 role 이 권장이에요. 노드를 따로 못 분리할 거면 allocate 액션을 정책에서 빼는 게 차라리 안전.

사고 4 — ILM Policy 변경 후 적용 안 됨

원인 — _ilm/policy/logs-app-policy 를 PUT 으로 갈아끼웠는데, 이미 단계가 진행 중인 인덱스 에는 새 정책이 즉시 적용되지 않음. 사용자 입장에선 "방금 정책 바꿨는데 왜 그대로지" 혼란.

해결 — 진행 중 단계가 끝나야 다음 단계부터 새 정책이 적용되는 게 기본 동작. 즉시 적용이 필요하면 POST <인덱스>/_ilm/move/<단계> 로 강제 이동하거나, POST <인덱스>/_ilm/retry 로 재시도. 프로덕션에서 ILM 정책 변경은 거의 항상 신중하게 — 변경 전 _ilm/explain 으로 현재 상태 스냅샷부터.

사고 5 — Snapshot before Delete 누락

원인 — Delete 단계가 잘 돌아서 1년 지난 인덱스를 자동 폐기하는데, 사전 스냅샷 이 안 잡혀 있어서 컴플라이언스 감사 때 데이터를 못 보여줌. 지워진 다음에야 알아챔.

해결 — Delete 정책 옆에 Cold/Frozen 단계의 searchable_snapshot 이 먼저 돌도록 정책 순서를 잡거나, 별도 스냅샷 리포지토리에 보관용 백업 을 따로 돌려요. 28편(Snapshot·Restore) 에서 깊이.

사고 6 — Forcemerge 폭주

원인 — Warm 단계 액션에 forcemerge: { max_num_segments: 1 } 을 넣었는데, Hot 단계에서 너무 빨리 Warm 으로 전환 되면 forcemerge 가 수십 GB 인덱스 에 대해 돌면서 디스크 I/O 폭증·검색 응답 폭망.

해결 — min_age 를 최소 1~2일 로 잡아서 쓰기가 완전히 멈춘 다음에 forcemerge 가 돌게 함. 또는 forcemerge 액션 자체를 빼고 세그먼트 자동 머지에 맡기는 선택도 가능해요.

사고 7 — ILM 멈춤 (ERROR 단계)

원인 — 어떤 액션이 실패해서 인덱스가 step: ERROR 상태로 빠짐. _ilm/explain 을 보면 step_info 에 에러 메시지가 있고, 그 인덱스 이후로는 정책이 더 진행 안 됨.

해결 — _ilm/explain 으로 원인 확인 → 근본 원인 해결 (디스크 부족·노드 부족·권한 등) → POST <인덱스>/_ilm/retry 로 재시도. 알람으로 ERROR 상태를 잡는 모니터링 이 30편(Monitoring) 표준 구성에 들어가요.

운영 권장 패턴

운영 표준이라고 굳혀 두면 ILM 사고 80% 가 사라지는 패턴 네 가지예요.

신규 시계열 데이터는 Data Stream 으로 시작 합니다. alias + rollover 를 수동으로 짜는 패턴은 기존 7.x 환경에서 이미 굳어진 경우 만 유지하고, 8.x 신규 셋업이면 Data Stream 이 권장 표준이에요. write alias 누락 사고가 구조적으로 안 일어나요.

정책은 Hot · Warm · Delete 3단계 최소 셋업 부터 시작합니다. Cold·Frozen 은 데이터 규모 1TB 이상 또는 컴플라이언스 보관 요구가 명시적 일 때만 추가. 처음부터 5단계 다 박으면 Searchable Snapshot 리포지토리 셋업·노드 티어 분리 같은 사전 작업이 산더미라서 셋업이 무거워져요.

운영 인덱스의 ILM 상태 모니터링 을 Kibana 또는 Grafana 에 박아 둡니다. _ilm/explain 응답의 각 인덱스 phase · step · age 를 주기적으로 폴링해서, ERROR 단계로 빠진 인덱스 가 있으면 즉시 알람. 30편(Monitoring) 에서 깊이.

정책 변경은 반드시 dev 클러스터에서 검증 후 prod 적용. ILM 정책은 수정 즉시 모든 인덱스에 영향 을 줄 수 있어서, 잘못 짜면 운영 중인 인덱스가 Warm 으로 안 가거나, 거꾸로 너무 빨리 Cold 로 가버리는 사고가 나요. 변경 전엔 _ilm/explain 스냅샷을 떠놓고, 변경 후엔 한두 시간 모니터링 이 표준.

시험 직전 한 번 더 — 압축 노트

• ILM = Index Lifecycle Management. Hot · Warm · Cold · Frozen · Delete 5단계 자동 전환.
• 단계 진입 조건 = 시간 (min_age), 크기 (max_size), 문서 수 (max_docs) 중 하나 이상.
• ILM 폴링 주기 = 기본 10분. indices.lifecycle.poll_interval 로 조절.
• Hot = NVMe SSD · 쓰기·읽기 모두 · rollover · set_priority.
• Warm = SSD · 읽기만 · forcemerge · shrink · allocate.
• Cold = HDD + S3 · 가끔 읽기 · searchable_snapshot · allocate.
• Frozen = S3 only · 연 1회 읽기 · searchable_snapshot (full) · Enterprise 라이선스.
• Delete = 세그먼트 단위 통삭제 · delete.
• Rollover = max_size · max_age · max_docs 중 하나라도 만족 시 새 인덱스 생성 + write alias 자동 이동.
• write alias = is_write_index: true 박힌 alias. 한 alias 당 쓰기 인덱스 1개 만.
• 초기 셋업 3단계 = Policy PUT → Index Template 에 lifecycle.name + rollover_alias → 초기 인덱스 + alias.
• Data Stream = 8.x 시계열 표준. 백킹 인덱스 자동 생성, @timestamp 필수, append-only.
• 사고 7대장 = write alias 누락 · rollover_alias 누락 · data tier 미설정 · 정책 변경 미적용 · snapshot 누락 · forcemerge 폭주 · ERROR 단계 멈춤.
• 진단 1순위 명령어 = GET <인덱스>/_ilm/explain.
• 운영 표준 = Data Stream 기본 · Hot/Warm/Delete 3단계부터 · 모니터링 박기 · dev 검증 후 prod 적용.
• 라이선스 = Basic (무료) 으로 Hot/Warm/Cold/Delete 충분. Frozen 만 Enterprise.

시리즈 다른 편

• 이전 글 = 5편 Index 관리 — Create·Settings·Alias·Reindex
• 다음 글 = 7편 Document CRUD — Index·Get·Update·Delete API
• 4편 = Quickstart — Docker·curl·Kibana 첫 화면
• 8편 = Mapping Deep — Static·Dynamic·Multi-field·Runtime
• 11편 = Korean Analyzer — Nori·mecab-ko·사용자 사전
• 26편 = Cluster Operations — Master·Data·Coordinating 역할
• 27편 = Shard Allocation — awareness·filtering·rebalance
• 28편 = Snapshot·Restore — 리포지토리·SLM·복구 시나리오
• 30편 = Monitoring — _cluster/health · _nodes/stats · slow log
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — Elasticsearch ILM = 시계열 인덱스를 Hot → Warm → Cold → Frozen → Delete 5단계로 자동 전환하는 정책 엔진. Rollover + write alias + Data Stream 셋이 운영 표준 패턴이고, 8.x 신규 셋업이면 Data Stream 으로 시작 이 답.