ILM과 데이터 스트림 — Hot-Warm-Cold-Frozen 계층과 샤드 운영
Elasticsearch 공식 문서(elastic.co/docs) 및 기술 블로그 종합 — 아키텍처부터 운영까지 (웹 리서치, 2026) — Elastic 공식 문서 + 여러 기술 블로그(Opster, Baeldung 등) 교차 확인
이 모듈을 다 읽으면
- ILM이 인덱스를 어떤 단계로 자동 이동시키는지 설명할 수 있다
- 데이터 스트림이 일별 로그 인덱스 운영 문제를 어떻게 해결하는지 설명할 수 있다
- 샤드를 과도하게 많이 만들었을 때(oversharding) 생기는 문제를 판단할 수 있다
로그·시계열 데이터 운영에 필수적인 ILM(Index Lifecycle Management)의 계층 구조와 데이터 스트림, 그리고 샤드 사이징 실수의 결과를 정리한다.
ILM — 인덱스를 나이 들게 놔두지 않고 자동으로 이동시킨다
ILM(Index Lifecycle Management)은 인덱스를 나이·크기·문서 수 같은 조건에 따라 Hot → Warm → Cold → Frozen → Delete 단계로 자동 이동시키는 정책이다. Hot 단계는 활발히 쓰기·읽기가 일어나는 최신 데이터(고성능 노드/디스크), Warm은 쓰기는 끝났지만 여전히 자주 조회되는 데이터(레플리카를 줄이거나 세그먼트를 병합해 최적화), Cold는 드물게 조회되는 데이터(저비용 스토리지), Frozen은 거의 조회 안 하지만 완전히 버릴 순 없는 데이터(검색 가능한 스냅샷으로 극도로 저비용 보관), Delete는 보존 기간이 끝나 삭제하는 단계다. 이 자동화 덕분에 '오늘 로그 인덱스는 SSD에, 6개월 지난 로그는 저비용 스토리지로' 같은 정책을 수동 개입 없이 유지할 수 있다.
핵심 포인트
- ILM 단계: Hot(활발한 쓰기/읽기) → Warm(읽기만, 최적화) → Cold(드문 조회, 저비용) → Frozen(거의 안 봄, 검색가능스냅샷) → Delete
- 나이·크기·문서 수 조건에 따라 인덱스를 자동으로 다음 단계로 이동시켜 수동 개입 없이 계층형 스토리지 정책을 유지한다
데이터 스트림 — 일별 인덱스를 수동으로 안 만들어도 되게
로그처럼 계속 새로 쌓이는 시계열 데이터를 예전에는 logs-2026.09.03 같은 이름으로 매일 수동(또는 스크립트)으로 새 인덱스를 만들어 관리했다. 데이터 스트림은 이 패턴을 추상화해, 애플리케이션은 하나의 논리적 이름(예: logs-app)으로만 쓰기 요청을 보내면 내부적으로 백킹 인덱스(backing index)를 자동 롤오버(용량/시간 조건에 따라 새 백킹 인덱스 생성)하며 관리해준다. ILM 정책을 데이터 스트림에 연결하면 롤오버 시점 결정과 오래된 백킹 인덱스의 Hot→Warm→Cold 이동·삭제까지 전부 자동화된다.
핵심 포인트
- 데이터 스트림 = 하나의 논리적 쓰기 이름 뒤에서 백킹 인덱스를 자동 롤오버하며 관리해주는 추상화
- ILM과 결합하면 롤오버 시점 결정부터 계층 이동·삭제까지 전부 자동화된다
샤드를 너무 많이 만들면 생기는 일 (Oversharding)
일별 인덱스를 프라이머리 샤드 수를 너무 크게 잡고(예: 20개) 장기간(1년) 운영하면 클러스터 전체 샤드 수가 수만 개까지 늘어날 수 있다. 샤드 하나하나가 마스터 노드가 추적해야 하는 클러스터 상태(cluster state)의 일부이자, 각각 별도의 Lucene 인덱스로서 파일 핸들·메모리 오버헤드를 갖기 때문에, 샤드 수가 과도하면 (1) 클러스터 상태 갱신·전파가 느려지고, (2) 각 샤드가 실제로 담는 데이터量에 비해 오버헤드 비율이 커지며(작은 샤드가 너무 많음), (3) 마스터 노드 부하가 늘어 클러스터 안정성 자체가 떨어질 수 있다. 실무 경험칙으로 샤드 하나의 크기를 수십GB 안팎으로 유지하고, 실제 데이터量에 맞춰 프라이머리 샤드 수를 정하는 것이 권장된다(무조건 많이 쪼갠다고 좋은 게 아니다).
핵심 포인트
- 샤드가 너무 많아지면(oversharding) 클러스터 상태 갱신이 느려지고 마스터 노드 부하가 커져 클러스터 안정성이 떨어진다
- 샤드 하나의 크기를 수십GB 안팎으로 유지하고 실제 데이터量에 맞춰 프라이머리 샤드 수를 정하는 게 실무 경험칙