Elastic 9.4: GPU로 벡터 인덱싱을 12배 빠르게 하고 Prometheus TSDB를 대체하며 FIPS 140-3을 완성한 릴리스

왜 이 릴리스를 지금 봐야 하나

2026년 4월 30일 공개된 Elastic 9.4.0은 서로 다른 세 방향에서 동시에 성숙한 릴리스다.

• GPU 벡터 인덱싱 GA: NVIDIA cuVS를 Elasticsearch에 연결한 GPU 가속 HNSW 인덱싱이 정식 기능이 됐다. 인덱싱 처리량 12배, force merge 7배 속도 향상.
• Prometheus/PromQL 네이티브 지원: Elasticsearch TSDB가 Prometheus보다 2.6배 저장 효율적이고 쿼리는 25배 빠르다는 수치로, Prometheus 대체 경로를 공식화했다.
• FIPS 140-3 전 스택 GA: Elasticsearch + Kibana 모두 FIPS 140-3 인증 경로를 완성했다. 2026년 9월 미국 연방 준수 기한에 앞서 GA가 됐다.

세 기능은 서로 독립적이지만, 공통점이 있다. 각각 대규모 벡터 검색, 메트릭 플랫폼, 규제 환경 운영이라는 세 가지 운영 압박에 응답한다. 업그레이드 여부를 이 세 기능 중 어느 것이 가장 급한 문제에 해당하는지로 판단하면 된다.

변화의 위치

1. GPU 벡터 인덱싱 GA: CAGRA → HNSW 파이프라인이 프로덕션 경로에 들어오다

왜 벡터 인덱싱이 CPU 병목인가

Elasticsearch의 HNSW(Hierarchical Navigable Small World) 그래프 구성은 본질적으로 CPU에서 돌아가는 단일 쓰레드 친화적 알고리즘이다. 각 벡터를 삽입할 때 기존 그래프에서 이웃을 탐색하고 엣지를 연결하는 과정이 순차적이기 때문이다. 대규모 벡터 인덱싱 파이프라인에서 CPU가 병목이 되는 이유가 여기 있다.

GPU는 이 작업을 다르게 처리한다. 수십만 개의 벡터를 VRAM에 올려 병렬로 그래프를 구성한다. NVIDIA cuVS 라이브러리의 CAGRA(CUDA ANN GRAph) 알고리즘이 이 병렬 구성을 담당한다.

처리 파이프라인

GPU 인덱싱이 켜진 상태에서 Elasticsearch의 벡터 세그먼트 flush 경로는 이렇게 바뀐다.

1. 벡터가 배치로 묶인다.
2. PCIe 버스를 통해 GPU VRAM으로 복사된다.
3. GPU에서 CAGRA 그래프가 구성된다.
4. CAGRA 그래프가 HNSW 포맷으로 변환된다.
5. 변환된 HNSW가 CPU RAM으로 복사된다.
6. Lucene 세그먼트 파일로 로컬 NVMe에 기록된다.

중요한 점: 이 파이프라인은 인덱싱 경로에만 GPU를 사용한다. 실제 벡터 검색(kNN 쿼리)은 여전히 CPU에서 수행된다. GPU는 인덱스를 만드는 데만 쓰인다.

cuvs-java와 Panama Foreign Function

Java로 구현된 Elasticsearch가 C++ 기반 NVIDIA cuVS 라이브러리를 호출하는 방식이 흥미롭다. NVIDIA가 오픈소스로 제공하는 cuvs-java 라이브러리가 중간 계층을 담당한다.

cuvs-java는 Java 22의 Panama Foreign Function & Memory (FFM) API를 사용한다. 기존 JNI(Java Native Interface)와 달리 Panama FFM API는 별도 네이티브 래퍼 코드 없이 Java 코드에서 직접 C 함수를 호출할 수 있다. 오버헤드가 적고 메모리 안전성도 높다.

Java (ES) → cuvs-java (Panama FFM) → cuVS C API → CUDA → GPU

이 아키텍처 덕분에 Elasticsearch는 JVM 재시작 없이 GPU 기능을 추가할 수 있었다.

요구 사항과 제약

GPU 인덱싱은 다음 조건이 모두 충족될 때만 활성화된다.

• NVIDIA GPU가 노드에 있어야 한다 (CUDA 지원 필수).
• OS 수준에서 cuVS 라이브러리가 설치돼 있어야 한다 (Elasticsearch 배포 패키지에 포함되지 않는다).
• 매핑에서 knn 필드가 HNSW 알고리즘으로 설정돼야 한다.

운영자 입장에서 이 의존성이 중요한 이유가 있다. 클라우드 기반 Elasticsearch(Elastic Cloud) 배포에서는 GPU 노드를 명시적으로 선택해야 하고, Kubernetes 등 컨테이너 환경에서는 GPU 노드 셀렉터 + cuVS 라이브러리 init container 구성이 필요하다.

언제 쓸 만한가

12배 향상이라는 수치는 초기 대규모 인덱싱(백필 시나리오)에 주로 해당한다. 문서가 실시간으로 작은 단위로 들어오는 스트리밍 인덱싱에서는 GPU에 배치를 묶어 보내는 오버헤드 때문에 개선 폭이 줄어든다.

가장 효과적인 시나리오는 다음과 같다.

• 수백만~수십억 개의 벡터를 한 번에 인덱싱하는 초기 로딩
• 인덱스 재구성(reindex) 작업
• 주기적 force merge가 병목인 경우

2. Prometheus/PromQL TSDB: Elasticsearch가 메트릭 스토어로 진지하게 경쟁한다

Prometheus의 운영 한계와 Elasticsearch의 포지션

Prometheus는 관측성 스택의 표준으로 자리 잡았지만, 두 가지 운영 한계가 있다.

1. 카디널리티 한계: 레이블 조합이 많아질수록 메모리 사용량이 급격히 오른다. 마이크로서비스·Kubernetes 환경에서 파드/서비스/네임스페이스 레이블이 수만 조합을 넘으면 Prometheus 단일 인스턴스가 버티기 어렵다.
2. 장기 보존 한계: Prometheus는 기본적으로 로컬 스토리지를 쓴다. 수개월~수년의 메트릭 보존은 Thanos, Cortex, Mimir 같은 별도 장기 저장 솔루션이 필요하다.

Elasticsearch는 이미 수백억 문서를 단일 클러스터에 저장하고 있다. Elastic 9.x부터는 time series mode라는 인덱스 최적화 모드를 통해 메트릭 데이터를 효율적으로 저장하고, Prometheus 호환 API를 제공한다.

무엇이 달라졌나: TSDB 최적화

Elasticsearch의 TSDB 모드는 시계열 데이터 특성에 맞게 세 가지를 최적화한다.

1. 저장 압축: 시계열 데이터는 같은 레이블 집합의 타임스탬프-값 쌍으로 구성된다. TSDB 모드에서는 이 반복 패턴을 활용해 비교 데이터 중복 제거(deduplicated storage)를 수행한다. Prometheus 대비 2.6배 저장 효율이 나오는 이유다.

2. 인덱싱 최적화: 메트릭 쿼리는 대부분 특정 시간 범위의 특정 레이블을 찾는다. TSDB 모드에서는 타임스탬프와 레이블을 위한 전용 인덱스 구조를 사용한다.

3. PromQL 엔드포인트: Elasticsearch 노드에서 직접 Prometheus remote read API를 서빙한다. Grafana나 기존 Prometheus 클라이언트가 URL만 바꾸면 연결된다.

수집 경로

Elasticsearch TSDB로 메트릭을 넣는 방법은 두 가지다.

Prometheus 에이전트 → remote_write → Elasticsearch
OpenTelemetry Collector → otlp/http → Elasticsearch (OTel 네이티브 수집)

기존 Prometheus remote_write 설정을 ES 엔드포인트로 바꾸면 된다. Grafana를 이미 쓰고 있다면 Prometheus 데이터소스 URL만 ES 호환 엔드포인트로 바꿔도 기존 대시보드가 작동한다.

성능 비교 수치를 어떻게 해석해야 하나

"2.6배 저장 효율"과 "25배 빠른 쿼리"는 Elastic이 공개한 자체 벤치마크다. 이 수치는 고카디널리티 시계열(레이블 수백만 개 이상)과 장기 집계 쿼리 시나리오에서 측정됐다.

운영자 입장에서 주의할 점이 있다.

• 낮은 카디널리티 환경에서는 Prometheus의 단순성이 여전히 강점이다.
• 저장 효율 수치는 데이터 특성(레이블 중복 비율, 타임스탬프 간격)에 따라 크게 달라진다.
• 25배 빠른 쿼리는 Mimir 기반 Prometheus 비교다. Thanos나 다른 장기 저장 솔루션과의 비교는 별도 측정이 필요하다.

즉, "Prometheus를 무조건 교체하라"가 아니라, 높은 카디널리티 + 장기 보존 + 기존 Elasticsearch 클러스터가 있는 환경에서 TSDB 모드를 검토하라는 맥락으로 읽어야 한다.

3. FIPS 140-3 GA: 규제 환경에서 Elasticsearch를 쓰는 운영자를 위한 마지막 퍼즐

FIPS 140-3이 왜 지금 급한가

FIPS 140-3은 미국 연방 정부의 암호화 모듈 표준이다. 2026년 9월부터 미국 연방 기관과 계약하는 시스템은 이 기준을 충족해야 한다. 의료(HIPAA+), 금융(DORA EU), 방산 관련 시스템이 우선 대상이다.

Elastic 9.4 이전까지는 Elasticsearch는 FIPS 140-2 호환 모드를 지원했지만 Kibana가 미완성이었다. 9.4에서 처음으로 Elasticsearch + Kibana가 동시에 FIPS 140-3 준수 상태로 운영 가능해졌다.

기술적 구현: Go 1.24 네이티브 FIPS

Elasticsearch 자체는 Java로 구현됐지만, 내부의 일부 모듈과 Elastic Agent는 Go로 구현됐다. Go 1.24에서 네이티브 FIPS 140-3 지원이 추가됐고, 외부 OpenSSL 라이브러리 의존성이 사라졌다.

이 변화의 실질적 의미는 두 가지다.

1. 오버헤드 감소: 기존 FIPS 구현은 OpenSSL을 JNI나 프로세스 경계로 호출하는 방식이었다. Go 1.24 네이티브 구현은 이 간접 경로를 제거한다.
2. 배포 단순화: OpenSSL FIPS provider를 OS에 별도 설치할 필요가 없다. Elasticsearch/Kibana 패키지 안에 포함된다.

Kibana FIPS 완성의 의미

Kibana는 Node.js로 구현됐다. Node.js의 FIPS 지원은 OpenSSL 기반이다. Kibana 9.4는 OpenSSL FIPS provider와의 연동을 완성해 전체 UI 스택까지 FIPS 체인이 닫혔다.

실무적으로는 다음을 의미한다.

• 대시보드 접속, 사용자 인증, 데이터 내보내기 등 Kibana를 통한 모든 경로가 FIPS 준수 암호화를 사용한다.
• ES + Kibana를 단일 클러스터로 감사(audit) 증거를 제출할 수 있다.

업그레이드 경로

8.x에서 9.x로 업그레이드 후 FIPS를 활성화하는 경로는 다음과 같다.

• 클러스터 재시작은 피할 수 없다 (JVM TLS 설정 변경 필요).
• 데이터 자체는 마이그레이션이 필요 없다고 Elastic이 명시했다.
• 단, 기존 비-FIPS 키스토어/트러스트스토어를 FIPS 준수 알고리즘으로 재생성해야 한다.

4. 9.x 시리즈 전반의 API 정리와 운영 영향

9.4는 9.0에서 시작된 큰 흐름의 일부다. 9.0에서 8.x에서 deprecated됐던 다수의 API와 설정이 제거됐다.

이 중 운영자가 가장 주의해야 할 변경은 다음이다.

인덱스 설정 API 변경

9.x에서 일부 인덱스 설정 API의 응답 구조가 바뀌었다. 특히 자동화 스크립트나 ILM(Index Lifecycle Management) 커스텀 스크립트가 _settings 응답을 파싱하는 방식이 영향을 받는다.

클러스터 API 비호환

일부 클러스터 상태 API가 9.x에서 필드 이름이 변경됐다. APM 에이전트, Kibana 플러그인, 커스텀 대시보드 스크립트가 이 필드에 의존하는 경우 업그레이드 전에 확인이 필요하다.

Java 클라이언트

Elastic Java Client 8.x는 9.x Elasticsearch와 기본적으로 호환되지만, 일부 deprecated 메서드가 제거됐을 수 있다. 8.14 이후 Java Client를 쓰고 있다면 큰 문제는 없을 가능성이 높지만, 통합 테스트로 확인해야 한다.

5. 이 릴리스가 특히 중요한 팀

대규모 벡터 검색을 운영하는 팀

RAG(Retrieval-Augmented Generation) 파이프라인이나 임베딩 기반 추천 시스템에서 주기적으로 수억 개 이상의 벡터를 재인덱싱해야 하는 팀에게 GPU 인덱싱은 운영 부담을 크게 줄인다. 단, GPU 노드 운영 비용과 cuVS 설치 복잡성을 먼저 평가해야 한다.

관측성 스택에서 카디널리티로 고생하는 팀

마이크로서비스가 수백 개이고 레이블이 복잡하게 얽혀 Prometheus 메모리가 자주 한계에 닿는다면, Elasticsearch TSDB를 장기 저장 + PromQL 쿼리 레이어로 쓰는 구성을 검토할 수 있다. 기존 Elasticsearch 클러스터가 이미 있는 경우에는 별도 스토리지 비용이 없다.

규제 산업의 운영 팀

2026년 9월 연방 기한 전에 FIPS 준수를 완료해야 하는 팀은 9.4 업그레이드가 필수 경로다. 특히 Kibana까지 포함한 전 스택 감사 증거가 필요한 경우 이번 GA가 직접 적용된다.

도입 전 체크리스트

6. 한 줄로 정리하면

Elastic 9.4는 "기능 하나 추가"가 아니라 벡터 검색 인프라, 메트릭 플랫폼, 규제 준수 세 가지 운영 압박을 동시에 다룬 릴리스다.

• GPU 인덱싱은 대규모 벡터 인덱스를 관리하는 비용을 줄인다.
• Prometheus TSDB는 고카디널리티 메트릭의 장기 보존과 PromQL 쿼리를 하나의 Elasticsearch 클러스터로 통합할 가능성을 연다.
• FIPS 140-3 GA는 규제 산업에서 전 스택 준수의 마지막 퍼즐을 완성한다.

셋 중 어느 것도 지금 당장 해결해야 하는 문제가 없다면 9.4 업그레이드를 서두를 이유는 없다. 그러나 셋 중 하나가 지금 운영 병목이라면, 9.4는 명확한 경로를 제공한다.

Open question

• GPU 인덱싱을 Elastic Cloud 관리형 서비스에서 쓸 수 있는지, GPU 노드 선택이 어떻게 지원되는지는 Elastic 공식 문서에서 추가 확인이 필요하다.
• TSDB 모드에서 기존 Elasticsearch 클러스터의 메모리/CPU 사용량 변화가 얼마나 되는지 독립 벤치마크가 부족하다.

References

• https://www.elastic.co/blog/whats-new-elastic-9-4-0
• https://www.elastic.co/search-labs/blog/nvidia-cuvs-elasticsearch-gpu-vector-indexing
• https://www.elastic.co/search-labs/blog/elasticsearch-gpu-accelerated-vector-indexing-nvidia
• https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/gpu-vector-indexing
• https://developer.nvidia.com/blog/optimizing-vector-search-for-indexing-and-real-time-retrieval-with-nvidia-cuvs/
• https://github.com/elastic/elasticsearch/pull/135545
• https://releases.sh/redis/releases