Elasticsearch가 Apache Lucene 을 어떻게 사용하는지 refresh/flush API를 통해 알아보기

목표: 엘라스틱서치가 아파치 루씬을 어떻게 사용하는지 알아보기

 

Elasticsearch와 Apache Lucene의 관계

Apache Lucene은 문서를 색인하고 검색할 수 있게 해주는 오픈소스 Java 라이브러리로, 강력한 텍스트 검색 엔진입니다.(https://lucene.apache.org/)

반면, Elasticsearch는 Lucene을 기반으로 만들어진 분산형 검색 엔진으로, Lucene을 보다 쉽게 사용자들이 사용하기 위해 JSON 기반의 RESTful HTTP API를 제공하여 보다 쉽게 문서를 색인하고 검색할 수 있도록 도와줍니다.

 

예를 들어, GET으로 검색하고, POST/PUT으로 문서를 색인하며, DELETE로 문서를 삭제할 수 있습니다.

 

이 외에도 Elasticsearch는 고가용성을 제공합니다. Elasticsearch는 최소 3개 이상의 노드로 클러스터 구성할 것을 권장합니다. 이는 일부 노드에 장애가 발생해도, 다른 노드에 저장된 복제본(replica)을 활용해 서비스 중단 없이 운영할 수 있기 때문입니다

 

수평적 확장이 쉽습니다. 색인할 문서가 많아지거나 검색 요청이 많아질 경우, 클러스터에 노드를 추가함으로써 쉽게 확장이 가능합니다. 새로운 노드가 클러스터에 합류하면 기존 노드의 데이터를 복제하거나 옮기는 작업도 Elasticsearch가 자동으로 처리합니다.

 

Elasticsearch의 다양한 장점은 구글링하면 많은 글에서 소개하여, 이번 글에서는 이쯤에서 간단히 정리해보겠습니다.

Elasticsearch는 클러스터 및 노드 관리를 자동화해 클라이언트에게 간편한 운영 환경을 제공하고, Lucene은 검색 엔진의 핵심 기능을 담당하는 구조입니다.

 

그렇기에 Elasicsearch를 이해하기 위해서는 Lucene을 알 필요가 있습니다.

 

Lucene의 flush

1. 문서 색인 요청이 들어오면, 문서를 분석해 역색인(inverted index)을 생성합니다.
2. 생성된 역색인을 메모리 버퍼에 임시로 저장하며, 이들을 디스크에 저장하면 세그먼트(segment)라는 Lucene 인덱스 파일이 생성되고, 이 세그먼트들이 루씬이 검색할 대상입니다.
3. 그리고, 루씬은 이 세그먼트들을 디스크에 write() 합니다.(이 때, OS가 세그먼트들을 디스크가 아닌 자신이 관리하는 메모리의 일부인 페이지 캐시(filesystem cache)에 올립니다.)

이 과정을 Lucene의 flush라고 합니다.

💡역색인 이란?
Lucene이 문서를 검색 가능한 데이터로 만들기 위해 사용하는 일종의 자료구조
An "inverted index" is the data structure that Lucene uses to make data searchable

 

💡페이지 캐시란?
페이지 캐시(page cache)는 때때로 파일 시스템 캐시라고도 불리며, 운영체제가 메모리를 활용해 디스크 데이터를 임시로 저장하는 공간입니다. 즉, 운영체제 수준에서 메모리를 캐시처럼 사용하여, 디스크 I/O 없이 더 빠르게 데이터를 읽고 처리할 수 있도록 도와주는 기능입니다.

Elasticsearch는 검색 성능을 높이기 위해 파일 시스템 캐시에 많이 의존합니다. (Elasticsearch heavily relies on the filesystem cache in order to make search fast)

https://www.elastic.co/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time

 

즉, Lucene의 flush 를 통해 페이지 캐시에 데이터를 쓰고 메모리에서 데이터를 읽기 때문에 검색 성능이 향상됩니다.

 

이러한 이유로, Elasticsearch는 JVM Heap 메모리를 전체 시스템 메모리의 절반 이하로 설정할 것을 권장합니다.
나머지 절반은 페이지 캐시 용도로 운영체제가 사용할 수 있도록 남겨두기 위함입니다.(Set JVM heap size)

 

즉, JVM Heap 메모리를 가용 메모리의 절반 이하로 설정하는 것은 메모리 낭비가 아니라는 것을 의미하며, 오히려 페이지 캐시를 위해 재사용되고 있다는 뜻입니다.

 

또한 페이지 캐시는 커널 문서에 명시된 것처럼 LRU(Least Recently Used) 방식으로 동작하며, 오래 사용하지 않은 데이터부터 제거됩니다.(Elasticsearch Page Cache)

 

Elasticsearch의 Refresh

Elasticsearch의 refresh는 Lucene의 flush 을 활용해 요청한 문서를 색인시켜 검색 가능하게 합니다.

문서 색인 과정

1. Elasticsearch는 문서를 받아 Lucene에 전달
2. Lucene은 문서를 메모리 버퍼에 색인(Lucene flush의 일부)
3. 동시에 Elasticsearch는 해당 작업을 translog에 기록 (translog에 대해서는 후에 설명합니다)
4. 이 단계까지는 검색이 불가능합니다

검색 가능해지는 시점: refresh 발생

1. Elasticsearch의 refresh가 발생하면,
2. Lucene은 메모리에 있던 색인 데이터를 읽을 수 있는 세그먼트(segment)로 생성하고, 페이지 캐시(filesystem cache)에 기록합니다. (Lucene flush 일부)
3. 이 시점부터 해당 데이터(문서)는 검색 가능한 상태(searchable)가 됩니다

기본적으로 refresh 주기는 1초이며, 이는 인덱스 생성할 때 refresh_interval 설정을 통해 조정할 수 있습니다.

다만, refresh 는 무거운 작업이기 때문에 최근 30초 이내에 한 번 이상 검색 요청을 받은 인덱스에 한해서만 주기적인 refresh가 수행됩니다.

 

여기까지 정리하자면, 색인되거나 변경된 문서를 검색하려면 Elasticsearch의 refresh가 반드시 필요하며, 이 과정에서 내부적으로 Lucene의 flush가 사용됩니다.

 

데이터 유실 위험, Lucene의 commit 등장

하지만, 지금까지 과정은 데이터를 메모리(페이지 캐시) 에만 저장하기 때문에 전원 장애나 시스템 크래시 시 데이터가 유실될 위험이 있습니다. 이를 방지하기 위해 Lucene은 commit 기능을 제공합니다. Lucene의 commit은 fsync 라는 시스템 콜을 통해 운영체제의 페이지 캐시와 디스크 내용을 동기화하여 데이터의 영속성을 보장합니다.

 

그리고, Elasticsearch의 flush가 Lucene의 commit을 트리거하여 데이터를 메모리(페이지 캐시)가 아닌 디스크에 기록할 수 있도록 합니다. 이 과정을 통해 데이터를 디스크에 안전하게 영구 저장할 수 있게 됩니다.

다만, 이 과정은 디스크 I/O를 유발하기 때문에 비용이 큰 작업이라 자주할 수 없습니다. 그렇다고, 한 번에 많은 데이터를 디스크에 쓰기에는 언제 데이터가 유실될지 모르는 문제가 있습니다.

 

데이터 유실 방지를 위한 Translog의 역할과 Elasticsearch의 flush

이 문제를 해결하고자 엘라스틱서치는 Translog를 지원합니다.

Translog는 데이터 유실을 방지하기 위해 사용하는 일종의 로그입니다. Translog는 Lucene의 문서 색인 작업이 수행된 직후에 기록되며, 이러한 기록이 끝난 후에야 Elasticsearch는 문서 색인을 요청한 클라이언트에게 성공(200, OK)과 같은 응답을 내려줍니다.

 

즉, Elasticsearch의 샤드는 모든 작업마다 Translog라는 이름의 작업 로그를 남기고, 이러한 로그가 장애 발생 시 복구에 활용됩니다. 만약 노드에 장애가 나서 데이터가 유실된다면 샤드 복구 과정에서 translog를 이용해 Lucene의 commit에 포함되지 않았던 데이터들을 복구할 수 있습니다.

 

하지만 Translog의 크기가 너무 커지면, 복구 과정에서 시간이 오래 걸릴 수 있습니다. 이를 방지하기 위해 Elasticsearch는 백그라운드에서 주기적으로 flush를 수행하여 Translog의 크기를 적절하게 유지합니다.

 

즉, Elasticsearch의 flush는

1. Lucene의 commit을 트리거해 데이터를 디스크에 영구적으로 저장하고,
2. 해당 데이터에 대한 Translog가 더 이상 필요 없어지므로, 트랜잭션 로그를 함께 비우는 작업까지 수행합니다.

 

세그먼트 구조와 삭제 처리 방식

Elasticsearch에서 문서의 UPDATE는 기존 문서를 수정하는 것이 아니라, 기존 문서를 삭제하고, 변경된 내용을 포함한 새로운 문서를 재색인하는 방식으로 처리됩니다.

 

왜 이렇게 작동하는지 알려면 Lucene 의 세그먼트에 대해 이해해야 합니다. Lucene flush가 발생하면, 메모리에 있던 색인 정보가 세그먼트(segment)라는 형태로 디스크에 저장됩니다.(사실은 OS가 디스크에 쓰지 않고, 메모리에 올리겠지만요)
이렇게 생성된 세그먼트들은 계속 디스크에 쌓이게 되고, Lucene은 이 세그먼트 단위로 검색을 수행합니다.

 

그런데 중요한 점은, 세그먼트는 한 번 생성되면 변경이 불가능한 불변 구조라는 것입니다.
따라서 문서를 수정하거나 삭제할 경우, Lucene은 세그먼트에서 해당 문서를 실제로 삭제하지 않고, 삭제 플래그(delete flag)를 표시해두고 검색 시 제외시키는 방식으로 처리합니다.

 

그래서, Elasticsearch의 UPDATE는 Lucene 동작 방식에 따라 기존 문서에 삭제 플래그를 설정하고, 수정된 내용을 담은 새로운 문서를 새로운 세그먼트에 색인하는 방식으로 동작합니다.

 

이렇게 해서 삭제 플래그가 표시된 문서들이 포함된 세그먼트는 나중에 세그먼트 병합(segment merge)이 수행될 때 여러 작은 세그먼트를 하나의 큰 세그먼트로 통합하면서 동시에 삭제된 문서를 실제 디스크에서 제거합니다.

 

그리고, 세그먼트 병합을 통해 검색할 세그먼트 수가 줄어드므로 문서 검색에 더 빠르다는 장점을 가지게 됩니다.(마치 RDBMS의 역정규화 같다는 생각이 듭니다)

 

* 병합주기에 대해 궁금하신 분들은 링크 걸어두겠습니다. 다만, 해당 문서에서도 최적화가 되어있다고 설명하며, 최적화 방법은 해당 문서에 나오는 단어들을 보시면 될 것 같습니다. https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html

 

 

 

참고

- What is the difference between Lucene and Elasticsearch

- 엘라스틱 바이블

- What is the internal structure of Elasticsearch when it is clustered?

- Elasticsearch Page Cache(https://www.elastic.co/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time)

- Elasticsearch Flush API(https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-flush.html)

- Elasticsearch Refresh API(https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html)

- https://stackoverflow.com/questions/15426441/understanding-segments-in-elasticsearch

- https://stackoverflow.com/questions/19963406/refresh-vs-flush