왜 9.5인가
Elastic 9.4(2026년 4월)에서 GPU 벡터 인덱싱과 Prometheus TSDB 대체 기능을 내놓은 지 두 달 만에 9.5가 나왔다(2026년 7월 9일). 단순 버그픽스 릴리스가 아니다. 세 가지 구조적 변화가 함께 왔다.
- Columnar Mode: 역인덱스 없이 컬럼 저장소로만 구성하는 새 인덱스 모드
- VectorDB Index Mode + Auto-calibration: 벡터 검색 설정을 단일 옵션으로 자동화
- Batched Query Execution: 같은 데이터 노드의 샤드를 한 번에 묶어 전송 비용 절감
세 변화는 서로 독립적으로 사용할 수 있지만, 조합하면 로그·메트릭·벡터 워크로드 각각에서 명확한 운영 선택지가 생긴다.
Columnar Mode: 역인덱스를 선택적으로 포기하는 결정
역인덱스는 항상 필요한가
Elasticsearch는 기본적으로 역인덱스(inverted index)를 구축해 모든 필드에서 전문 검색을 지원한다. 이 구조는 텍스트 검색에는 최적이지만 로그·메트릭처럼 집계와 범위 쿼리가 주된 패턴에서는 저장 오버헤드가 크다.
TSDB 모드는 이미 타임스탬프와 측정값에 컬럼형 저장을 도입했다. 9.5의 Columnar Mode는 이를 일반 인덱스 레벨로 확장한다.
두 가지 Columnar 옵션
Columnar Metrics
- 기존 ES 메트릭 저장의 ES95 코덱 위에 구축
- 필드당 스토리지 ~3바이트/샘플 수준
- TSDB 연속 집계와 결합 시 ~20% 추가 절감
Columnar Logs (새로 도입)
message필드에만 역인덱스 유지, 나머지는 전체 컬럼형 저장- 목표:
grep수준 전문 검색 + 집계 성능 동시 확보 - 기존 로그 인덱스 대비 저장 공간 유의미하게 감소
운영 판단 기준
| 워크로드 | 권장 모드 | 이유 |
|---|---|---|
| 임의 필드 전문 검색이 잦음 | Standard | 역인덱스가 필수 |
| message 검색 + 집계 위주 | Columnar Logs | 저장 절감 + 집계 성능 |
| 순수 메트릭 집계, 검색 없음 | Columnar Metrics | 최대 압축 |
| 벡터 검색 전용 | VectorDB Mode | 별도 최적화 (아래 참조) |
VectorDB Index Mode와 Auto-calibration
수동 튜닝의 종료
기존 Elasticsearch 벡터 검색은 num_candidates, ef_construction, 양자화 비트 수, 오버샘플링 배율 같은 파라미터를 직접 조정해야 했다. 잘못 설정하면 recall이 떨어지거나 메모리가 폭발했다.
9.5의 VectorDB Index Mode는 단일 설정으로 이 과정을 자동화한다.
PUT /my-vector-index
{
"settings": {
"index": {
"mode": "vectordb"
}
},
"mappings": {
"properties": {
"embedding": {
"type": "dense_vector",
"dims": 1536
}
}
}
}Auto-calibration은 내부에서 세 파라미터를 자동으로 선택한다:
- 양자화 깊이: 데이터 분포를 분석해 int4/int8/float32를 결정
- 프리컨디셔닝: HNSW 그래프 품질을 높이기 위한 전처리 방식 선택
- 오버샘플링:
num_candidates를 자동 계산해 목표 recall 달성
운영 함의
Auto-calibration은 설정 없이도 목표 recall에 근접하는 것이 목표다. 그러나 SLA가 엄격한 환경에서는 여전히 검증이 필요하다.
- 인덱스 생성 후
GET /_cat/indices?v&h=index,store.size로 실제 압축률 확인 POST /my-index/_search에"explain": true를 붙여 HNSW 단계 수 확인- 주기적 recall 측정: ground truth 결과와 비교해 0.95 미만이면
vectordb.recall_target파라미터 수동 조정 고려
Batched Query Execution: 코디네이터 노드 부담 분산
기존 멀티샤드 쿼리의 비효율
하나의 인덱스가 여러 샤드로 분산될 때, 기존 Elasticsearch는 코디네이터 노드가 각 샤드에 개별 요청을 보냈다. 샤드 수 = 왕복 횟수였다. 10개 샤드가 3개 데이터 노드에 분산돼 있으면 코디네이터는 10번 왕복했다.
9.5의 Batched Query Execution은 같은 데이터 노드에 있는 샤드를 한 번에 묶어 전송한다. 10개 샤드가 3개 노드에 분산돼 있으면 왕복이 3번으로 줄어든다.
기존: 코디네이터 → 샤드1 (왕복)
코디네이터 → 샤드2 (왕복)
코디네이터 → 샤드3 (왕복)
...
9.5: 코디네이터 → 노드A [샤드1+샤드3+샤드7] (왕복 1회)
코디네이터 → 노드B [샤드2+샤드5] (왕복 1회)
코디네이터 → 노드C [샤드4+샤드6+샤드8] (왕복 1회)부분 집계(partial reduce)도 데이터 노드에서 처리하므로 코디네이터의 집계 부담이 함께 줄어든다.
설정: search.batched_query_phase=true (9.5에서 기본 활성화).
비활성화가 필요한 경우: 샤드 하나하나의 처리 시간이 극히 불균등할 때(스큐가 심한 경우) 배치가 느린 샤드에 묶여 전체 지연이 늘어날 수 있다. 이 경우 search.batched_query_phase=false로 되돌릴 수 있다.
TSDB: 5배 빠른 쿼리
TSDB 모드의 범위 쿼리(rate 계산, 연속 집계)에서 최대 5배 속도 향상이 보고됐다.
변경 내용:
- 카운터 값 디코딩과 rate 계산 사이의 복사 연산 제거
- 시계열 접근 패턴이 밀집·순차적이 되도록 인덱스 구조 최적화
- 동일 메트릭의 시계열이 세그먼트 내에서 인접하게 배치되어 I/O 지역성 향상
TSDB를 사용하는 Prometheus 데이터 관리 환경에서 특히 효과적이다. _prometheus/api/v1/query (Tech Preview) 엔드포인트를 통해 Elasticsearch를 PromQL 엔진으로 직접 사용하는 경우, 이 최적화가 쿼리 응답 시간에 직접 반영된다.
9.5 운영 체크리스트
| 항목 | 확인 사항 |
|---|---|
| Columnar Logs 마이그레이션 | 기존 인덱스는 재인덱싱 필요. ILM rollover와 연계해 신규 인덱스부터 적용 |
| VectorDB Mode 도입 | 기존 dense_vector 인덱스와 공존 가능. 전환 전 recall 측정 |
| Batched Query 모니터링 | elasticsearch_search_latency_ms를 샤드 수 기준으로 분리해 배치 효과 측정 |
| TSDB 쿼리 성능 | GET /_cluster/stats에서 indices.segments.doc_values_memory 변화 확인 |
| Auto-calibration 검증 | 주기적 recall 측정 파이프라인 구축. 목표: recall@10 ≥ 0.95 |
| PromQL 엔드포인트 | Tech Preview 상태. 프로덕션에는 별도 Prometheus 인스턴스와 병행 운영 권장 |
요약
Elastic 9.5는 인덱스 모드 선택을 구체화했다. Columnar Logs는 로그 워크로드에서 역인덱스 범위를 최소화해 저장 비용과 집계 성능을 동시에 개선하고, VectorDB Mode는 수동 튜닝 없이 벡터 검색을 가동 가능한 상태로 만들며, Batched Query Execution은 멀티샤드 환경에서 코디네이터 왕복을 줄인다. 기존 9.4 환경에서 점진적으로 적용 가능한 변화들이라, 한 릴리스 내에서 여러 워크로드 개선 기회가 함께 왔다.