3장. Lucene 내부 구조 — 세그먼트의 일생

refresh는 왜 1초인가, 삭제한 문서는 왜 디스크에 남는가, 머지는 왜 계속 도는가 — Elasticsearch의 모든 미스터리는 Lucene의 "불변 세그먼트" 하나로 풀립니다.

3.1 Lucene이란 — 그리고 두 가지 본질

Lucene은 1999년 Doug Cutting이 시작한 자바 풀텍스트 검색 라이브러리입니다. 데이터베이스가 아닙니다. 분산도, 복제도, REST도 없습니다. "디렉터리 하나에 인덱스 자료구조를 만들고 그 위에서 검색하는 라이브러리"일 뿐입니다. Elasticsearch의 샤드 하나 = Lucene 인덱스 하나이고, 그 안은 이렇게 생겼습니다.

이 두 성질에서 refresh, flush, merge, NRT, 그리고 색인 처리량의 한계까지 — Elasticsearch의 모든 운영 특성이 흘러나옵니다. 이 장의 목표는 이 인과 사슬을 눈으로 확인하는 것입니다.

3.2 역색인은 디스크에 어떻게 저장되나

1장에서 본 "term → 문서 목록" 표가 실제로는 세 가지 컴포넌트로 저장됩니다.

• Term Dictionary — 정렬된 term 사전. 수백만 term을 메모리에 올리기 위해 FST(Finite State Transducer)라는 자료구조로 압축합니다. FST는 공통 접두사·접미사를 공유하는 압축 트라이 같은 것으로, term 룩업을 디스크 접근 없이 처리하게 해줍니다.
• Posting List — 각 term이 등장하는 doc ID 목록. doc ID 간의 차이값(delta)만 저장하고 bit packing으로 압축합니다.
• Term Frequencies + Positions — 각 term이 문서에서 몇 번, 어느 위치에 나왔는지. BM25 스코어링과 구문(phrase) 검색에 필요합니다.

# 쿼리 "the quick brown fox"가 처리되는 과정 (BM25)
① Analyzer가 토큰화:  [quick, brown, fox]        # the는 stopword로 제거
② 각 term의 posting list 조회 (FST로 룩업):
     quick → [doc1(tf=1), doc7(tf=2), ...]
     brown → [doc1(tf=1), doc15(tf=1)]
     fox   → [doc1(tf=1)]
③ 교집합(intersection):  {doc1}                   # SkipList로 정렬 순회
④ 각 문서의 BM25 점수 계산 → top-K 반환

3.3 Doc Values — 역색인의 반대 방향

역색인은 "term → docs"는 잘하지만 "doc → 필드 값"은 못 합니다. 그런데 정렬·집계·스크립트는 후자가 필요합니다. 그래서 Lucene은 색인 시 Doc Values라는 컬럼 지향 자료구조를 함께 만듭니다.

# 같은 데이터, 두 방향의 자료구조

Inverted Index (검색용):          Doc Values (정렬/집계용, 컬럼 지향):
  "apple"  → [doc1, doc5]           field "price":
  "banana" → [doc3, doc7]             doc1 → 100
                                      doc2 → 250
                                      doc3 → 80    # 한 필드 값이 연속 배치
                                      doc4 → 320   # → sequential read로 집계

ClickHouse의 컬럼 저장과 같은 원리입니다. 중요한 점: Doc Values는 JVM heap이 아니라 OS의 파일 시스템 캐시(off-heap)에 올라갑니다. Elasticsearch가 heap을 시스템 메모리의 50% 이하로 권장하는 이유가 바로 이것입니다 — 나머지 절반은 OS가 doc values와 posting list를 캐싱하는 데 씁니다.

3.4 _source — 원본 JSON의 자리

문서의 원본 JSON은 _source라는 stored field에 통째로 저장됩니다(LZ4/ZSTD 압축 청크). 검색 결과 반환, reindex, update API가 모두 이것에 의존합니다.

3.5 색인 라이프사이클 — buffer에서 디스크까지

이 절이 이 장의 심장입니다. 색인 요청 하나가 검색 가능해지고(refresh), 영속화되고(flush), 그 사이 유실을 막는(translog) 전체 과정을 봅시다.

정리하면, 세 단어의 역할 분담은 이렇습니다.

# refresh_interval 튜닝 — 색인 처리량의 가장 큰 변수
PUT /my-index/_settings
{ "index": { "refresh_interval": "30s" } }   # 30s만 돼도 처리량 2~5배 흔함

# 대량 초기 적재: refresh 끄기 → 적재 → 복원
PUT /logs-init/_settings
{ "index": { "refresh_interval": "-1" } }
# ... bulk 적재 ...
PUT /logs-init/_settings
{ "index": { "refresh_interval": "1s" } }
POST /logs-init/_refresh

# translog 내구성 모드 — 의식적으로 선택하라
index.translog.durability: request   # 기본. 매 요청 fsync (안전, IOPS 부담)
index.translog.durability: async     # 5초 주기 fsync (빠름, 최대 5초 유실 가능)

3.6 삭제와 업데이트 — 불변 세그먼트에서 지우는 법

세그먼트가 불변이라면 DELETE는 어떻게 처리될까요? 답: 지우지 않고 마킹만 합니다.

3.7 Merge — 세그먼트 정리반

refresh가 1초마다 새 세그먼트를 만들면 세그먼트가 빠르게 불어납니다. 세그먼트가 많을수록 검색이 모든 세그먼트를 순회해야 해서 느려지고, 파일 디스크립터와 메타데이터 메모리도 소모됩니다. 그래서 Lucene은 백그라운드에서 작은 세그먼트들을 큰 세그먼트로 병합합니다. 기본 정책은 TieredMergePolicy입니다.

3.8 운영 팁

• Heap 32GB 룰: JVM heap이 32GB를 넘으면 compressed object pointer가 꺼져 메모리 효율이 급락합니다. heap = min(시스템 메모리의 50%, 30GB)가 표준. 나머지는 OS 캐시 몫입니다.
• 세그먼트 수 모니터링: 한 샤드에 세그먼트가 100개를 넘으면 머지가 색인 속도를 따라잡지 못한다는 신호입니다.
• _id 자동 생성이 빠릅니다: _id를 직접 지정하면 같은 ID 존재 여부 확인 + 기존 버전 삭제 마킹이 필요해 더 비쌉니다.

# 세그먼트 상태 확인
GET /_cat/segments/logs-2026.07.11?v=true&h=shard,segment,size,docs.count,docs.deleted

# 샤드당 세그먼트 수
GET /_cat/shards/logs-*?v=true&h=index,shard,prirep,docs,store,segments.count

# jvm.options — heap 30GB 고정
-Xms30g
-Xmx30g

✍️ 이해도 체크