9장. 인덱싱 전략 — 처리량과 내구성의 설계

색인은 "문서를 저장한다"가 아닙니다. segment 생성, refresh, translog, merge가 맞물려 도는 기계이며 — 잘못 돌리면 처리량 붕괴와 검색 지연 폭주로 직결됩니다. 8.x/9.x 기준의 내부 동작과 운영 정석을 그림으로 잡습니다.

9.1 단건 vs Bulk — 요청당 오버헤드는 같다

단건 색인 요청 하나에도 HTTP 라운드트립, primary 샤드 라우팅, replica 복제 대기, translog fsync가 전부 발생합니다. 핵심은 이것입니다: 1건을 쓰든 1,000건을 쓰든 요청당 라우팅·acking 오버헤드는 거의 동일합니다. 그래서 단건 색인의 처리량은 bulk 대비 1/100 이하로 떨어집니다.

POST /_bulk
{ "index" : { "_index" : "logs", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "logs", "_id" : "2" } }
{ "field1" : "value2" }
{ "delete" : { "_index" : "logs", "_id" : "3" } }
// NDJSON 포맷: 액션 줄 + 문서 줄(delete는 액션만). 마지막 줄 끝에도 개행 필수

• 권장 페이로드: 5~15 MiB (공식 권장 시작점). 문서 수로는 보통 1,000~10,000건
• 너무 작으면 오버헤드 비율↑, 너무 크면(>20MiB) coordinating node 메모리 압박·GC 유발
• 클라이언트 배칭은 크기(10MiB) / 건수(1000) / 시간(1s) 셋 중 하나라도 차면 flush — 자바 BulkProcessor/BulkIngester의 표준 패턴

9.2 색인의 내부 파이프라인 — refresh와 translog

"색인했는데 왜 바로 검색이 안 되죠?"와 "장애가 나면 방금 쓴 데이터는요?"의 답이 모두 이 파이프라인에 있습니다. Lucene은 segment 단위로만 검색할 수 있고, segment를 디스크에 완전히 커밋(fsync)하는 것은 비싸기 때문에, ES는 중간 단계들을 둡니다.

refresh_interval 트레이드오프

// 대량 backfill/reindex의 정석: refresh와 replica를 끄고 넣는다
PUT /target/_settings
{ "refresh_interval": "-1", "number_of_replicas": 0 }

... (bulk indexing) ...

PUT /target/_settings
{ "refresh_interval": "1s", "number_of_replicas": 1 }
POST /target/_forcemerge?max_num_segments=1

9.3 Rollover와 Data Stream — 시계열 인덱스를 자르는 법

로그·메트릭 같은 시계열 데이터를 하나의 인덱스에 계속 쌓으면 shard가 무한히 커집니다. 해법은 일정 기준마다 새 인덱스로 갈아타는 rollover입니다. Data stream은 이 패턴을 빌트인으로 자동화한 것으로, 사용자에게는 단일 이름(logs)으로 보이지만 내부적으로 .ds-logs-…-000001 같은 backing index들이 자동 관리됩니다.

Data stream의 제약: 모든 문서에 @timestamp 필수, append-only(_id로 update/delete 불가), 인덱스 템플릿 + ILM 정책과 한 세트로 동작합니다.

9.4 ILM — hot·warm·cold 티어를 흐르는 데이터의 일생

ILM(Index Lifecycle Management)은 rollover된 인덱스를 나이에 따라 싼 하드웨어로 옮기고 결국 삭제하는 자동화입니다. "최근 데이터는 비싸고 빠르게, 오래된 데이터는 싸고 느리게"가 설계 철학입니다.

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_age": "1d", "max_primary_shard_size": "50gb" },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "shrink":     { "number_of_shards": 1 },
          "allocate":   { "include": { "data_tier": "data_warm" } }
        }
      },
      "cold":   { "min_age": "30d",  "actions": { "searchable_snapshot": { "snapshot_repository": "my_repo" } } },
      "delete": { "min_age": "365d", "actions": { "delete": {} } }
    }
  }
}

9.5 Force merge — 하지 말아야 할 때를 아는 것이 핵심

Lucene은 background merge로 알아서 segment를 관리합니다. _forcemerge는 read-only가 된 인덱스의 segment를 1개로 합쳐 검색을 최적화하고 삭제 문서의 공간을 회수하는 마무리 작업입니다.

# 1. rollover로 write가 끝난 인덱스인지 확인 후 read-only 전환
PUT /logs-2026.07.01/_settings
{ "index.blocks.write": true }

# 2. force merge (비동기 실행)
POST /logs-2026.07.01/_forcemerge?max_num_segments=1&wait_for_completion=false

9.6 베스트 프랙티스 체크리스트

✍️ 이해도 체크