[Elasticsearch] 캐시 구조

Elasticsearch는 고성능 검색 및 필터링 기능을 제공하는 DB 시스템이다.

개떡같이 쿼리를 넣어도 찰떡같이 빠르게 결과를 내뱉어주니 마법처럼 보일 수도 있지만, 이 고성능 동작의 상당 부분은 캐싱 전략에서 나온다.

여기서는 Elasticsearch가 캐싱 전략을 사용해서 성능을 최적화하는 법. 그리고 사용자 입장에서 캐싱을 잘 할 수 있게 하는 방법을 간단히 정리해보겠다.

인덱스 구조에 대해서도 얼마간 알고 가면 좋다.
관련 포스트
https://blog.naver.com/sssang97/223640540316

1. OS 페이지 캐시

대부분의 DB가 그렇듯, Elasticsearch도 디스크에서 파일을 읽는 것이 가장 큰 병목 지점 중 하나다.

그래서 Elasticsearch는 페이지 캐시를 사용해서 반복적인 읽기 패턴을 최적화한다.
파일을 처음 읽을 때는 당연히 디스크에서 가져오지만, 두번째 읽기부터는 디스크에 접근하지 않고 메모리에 올려놨던 데이터를 바로 가져올 수 있게 하는 것이다.

페이지 캐시의 원본 데이터가 변경되면 해당 메모리의 데이터는 "dirty" 마크가 붙고 해제된다.

특히나 Elasticsearch, 그러니까 Lucene의 최소 저장 단위인 세그먼트가 "불변"형이란 것도 이러한 최적화 구조와 궁합이 매우 잘 맞는 편이다.
세그먼트는 데이터가 바뀔 일이 없으니 캐시를 만료시키고 갱신하는 동작의 구현에 유리하다.

그래서

그래서 Elasticsearch는 페이지 캐시에 많은 부분을 의존하고, 페이지 캐시를 위한 가용 메모리를 넉넉하게 잡아줘야 한다. 메모리를 괴물같이 많이 잡아먹는 이유도 여기에 있다...

공식 문서에서는 "서버 메모리의 절반 이상을" 페이지 캐시에 사용할 수 있게끔 여유있게 설정하는 것을 권장한다.

2. Shard Request 캐시

이건 사용 사례가 조금 복잡한 편이다.

정확히 말하면 집계로 인해서 나온 최종 결과만을 캐시하는게 아니라, 각 인덱스별로 나온 중간 결괏값 자체를 캐싱해서 일부 인덱스만 변경된 경우에도 부분적으로 캐시를 활용할 수 있도록 한다는 것이다.

그렇게 일반적인 사용사례는 아니다.
한번 키바나로 메트릭이나 로그 데이터를 조회한다고 가정해보자.

그럼 시간대별로 인덱스를 만들고 append하는 구조가 된다.

처음에 이 상태로는 당연히 거의 캐싱이 잘 될 것이다.

그런데 만약 시간이 좀 지나서, 옛날 데이터가 좀 지워지고, 끝에 데이터가 추가된다면 어떨 것 같은가?

왼쪽이 과거고 오른쪽이 미래다.

이러면 최종적인 결과가 달라지므로 일반적인 형태로만 캐시를 적용하면 캐시가 금방 날라갈 것이다.

여기서의 아이디어는, 각 인덱스의 값을 별도로 캐싱할 수 있도록 한다는 것이다.

그러니까, 저기서 logs-000002, logs-000003, logs-000004는 변경된 것이 없으니까 캐시해놓고 그대로 재활용하고, logs-000001, logs-000005만 캐시 없이 신규로 가져와서 집계를 수행하는 것이다.

이 캐시는 기본적으로 메모리의 최대 1% 정도를 점유한다.

3. Query 캐시

Elasticsearch는 사용자가 날린 쿼리에 대해서도 적극적인 캐싱을 수행한다.
최적화를 하고자 한다면 알아야 할 부분이다.

bitset 캐시

Bitset은 [0,0,1,0,1,1...] 같은 순수한 비트 시퀀스를 말한다.
예를 들어, {gt:5000} 같은 필터식으로 쿼리를 날린다면, 해당 조건에 부합하는 데이터에만 1을 기록하고, 부합하지 않으면 0을 기록하는 것이다.

컬럼에 비트 기반으로 저장하기 때문에 비교적 크기가 작게 저장된다.

유연한 캐시 구조

Elasticsearch의 캐시는 query와 result가 1:1로 매핑되는 단순한 구조가 아니다.
"서로 다른 쿼리 간에도" 같은 bitset 캐시를 공유할 수 있다.

예를 들면 이런 것이다.

다음과 같은 쿼리가 2개 있다고 가정해보자.

{
    "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "message": "hello"
                    }
                }
            ],
            "filter": [
                {
                    "range": {
                        "created_at": {
                            "gte": "2021-02-01",
                            "lt": "2021-03-01"
                        }
                    }
                }
            ]
        }
    }
}

{
    "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "message": "world"
                    }
                }
            ],
            "filter": [
                {
                    "range": {
                        "created_at": {
                            "gte": "2021-02-01",
                            "lt": "2021-03-01"
                        }
                    }
                }
            ]
        }
    }
}

둘은 최종적으로 가리키는 데이터가 완전히 다를 것이다.

첫번째는 2021-02-01 <= created_at < 2021-03-01 이면서 message가 "hello"인 데이터를 탐색한다.
두번째는 2021-02-01 <= created_at < 2021-03-01 이면서 message가 "world"인 데이터를 탐색한다.

요청이나 응답이 아마 완전히 다를 것이나, 그럼에도 created_at에 대한 필터링 조건은 동일하다.

Elasticsearch의 bitset 캐시는 이런 다양한 상황에 대응할 수 있을 정도로 유연하다. 저 created_at bitset만 사용해서 최초 로드한 다음에 message 필터를 수행할 수도 있고, bitset끼리 OR 압축을 해서 빠르게 디스크 액세스를 하는 방법도 가지고 있다.

bool을 사용하라

elastcisearch는 필터에 대해서 and나 or, not절 등을 직접적으로 걸 수 있는 논리식을 지원한다.

{
    "filter": {
        "or": [
            {
                "and": [
                    {
                        "range": {
                            "end": {
                                "gte": 201407292300
                            }
                        }
                    },
                    {
                        "term": {
                            "condtion1": false
                        }
                    }
                ]
            }
        ]
    }
}

이런 식으로 말이다.

하지만 이런 형태는 Elasticsearch의 캐시를 타지 못한다.
캐시를 통한 최적화를 원한다면 반드시 모든 조건절이 bool 절 안에 포함되도록 해야 한다.

{
    "query": {
        "bool": {
            "should": [
                {
                    "bool": {
                        "must": [
                            {
                                "range": {
                                    "end": {
                                        "gte": 201407292300
                                    }
                                }
                            },
                            {
                                "term": {
                                    "condtion1": false
                                }
                            }
                        ]
                    }
                }
            ]
        }
    }
}

그래야 상술했던 bitset 기반의 query 캐시를 탈 수 있다.

쿼리 캐시 옵션

쿼리 캐시 관련 설정에는 2가지 옵션이 있다.

- indices.queries.cache.size
쿼리 캐시의 최대 크기를 제어하는 옵션이다.
기본값은 JVM 힙 크기의 10%다.

- indices.queries.cache.count
이건 공식 문서에는 존재하지 않는데, 실제로 존재는 하는 전문가용? 옵션이다.
쿼리 캐시의 최대 총 개수를 뜻한다. 기본값은 10000이다.

참조
https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time
https://stackoverflow.com/questions/24893919/elasticsearch-performance-in-case-of-complex-filters-and-lot-of-records
https://www.elastic.co/guide/en/elasticsearch/reference/7.11/tune-for-search-speed.html#_give_memory_to_the_filesystem_cache_2
https://github.com/elastic/elasticsearch/issues/19799
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-cache.html