인덱스를 날짜로 나누는 이유

한 줄 요약

로그 인덱스를 logs-2026.08.21 처럼 날짜로 나누는 이유는 지우기 위해서다. 문서 하나씩 지우는 것은 느리지만 인덱스 통째로 지우는 것은 파일 삭제라 즉시 끝난다.

왜 이게 필요했나

검색 엔진에서 문서를 지우는 것은 실제로 지우는 것이 아니다. "지워졌음" 표시를 하고, 나중에 세그먼트를 병합할 때 실제로 빠진다. 그래서 오래된 로그 1억 건을 delete_by_query 로 지우면 몇 시간이 걸리고 그동안 클러스터가 느려진다.

인덱스를 날짜로 나눠 두면 "8월 1일치 지우기" 가 DELETE logs-2026.08.01 한 번이다. 디렉터리를 지우는 것과 같은 비용이다.

어떻게 동작하나

인덱스 템플릿이 새로 생기는 인덱스에 설정을 자동으로 입힌다.

PUT _index_template/labhub-logs{  "index_patterns": ["labhub-*"],  "template": {    "settings": {      "number_of_shards": 1,      "number_of_replicas": 1,      "refresh_interval": "10s"    },    "mappings": {      "dynamic": false,      "properties": {        "@timestamp": { "type": "date" },        "level":      { "type": "keyword" },        "message":    { "type": "text" },        "trace_id":   { "type": "keyword" },        "pod":        { "type": "keyword" }      }    }  }}

"dynamic": false 가 이 설정의 핵심이다. 이유는 아래에.

ISM(수명주기 관리) 이 지우는 일을 자동화한다.

hot (7일)  →  warm (23일, 복제본 0, 강제 병합)  →  delete

매핑 폭발

dynamic 을 켜 두면 새 필드가 들어올 때마다 매핑이 자동으로 생긴다. 그런데 애플리케이션이 로그에 사용자 ID 를 필드 이름으로 넣거나(user_12345: "..."), 오류 객체를 통째로 JSON 으로 넣으면 필드가 수천 개가 된다.

필드가 늘면 클러스터 상태(cluster state) 가 커지고, 그건 모든 노드에 복제되므로 클러스터 전체가 느려진다. 심하면 마스터 노드가 죽는다. 이걸 매핑 폭발(mapping explosion)이라 한다.

막는 방법은 셋이다.

1. "dynamic": false — 정의하지 않은 필드는 저장은 하되 색인하지 않는다(검색 안 됨, 조회는 됨)
2. "dynamic": "strict" — 정의하지 않은 필드가 오면 거부한다
3. index.mapping.total_fields.limit — 상한을 둔다(기본 1000)

strict 는 안전해 보이지만 위험하다. 수집기가 예상 못 한 필드 하나를 붙이면 문서가 통째로 거부되고 로그가 유실된다. 실제로 Fluent Bit 이 내부 필드 _p 를 붙여 400 오류가 무한 재시도로 돌면서 로그가 통째로 막힌 적이 있다. 그래서 로그 인덱스에는 false 가 낫다.

흔한 착각

샤드를 많이 두면 빠르다는 것. 샤드 하나는 루씬 인덱스 하나이고 각각 파일 핸들과 메모리를 쓴다. 하루 몇 GB 수준의 로그에 샤드 5개는 낭비다. 경험칙은 샤드 하나당 10~50GB, 그보다 작으면 샤드를 줄인다.

text 와 keyword 를 헷갈리는 것. text 는 분석해서 토큰으로 쪼개므로 전문 검색은 되지만 집계와 정렬이 안 된다. keyword 는 통째로 저장해 집계·정렬은 되지만 부분 검색이 안 된다. 레벨·파드명·트레이스ID 는 keyword, 메시지 본문은 text 다.

실무에서 진짜 중요한 것

로그에 트레이스 ID 를 넣는 것이 관측성의 절반이다. 그게 있으면 "이 느린 요청이 남긴 로그" 를 한 번에 찾을 수 있다. 없으면 시각과 파드 이름으로 더듬어야 한다.

필드 이름은 처음부터 표준을 따르는 것이 좋다. ECS(Elastic Common Schema)는 @timestamp, log.level, service.name, trace.id 같은 이름을 정해 두었다. 나중에 바꾸려면 옛 인덱스를 전부 재색인해야 한다.