오픈서치(엘라스틱서치) 인덱스와 매핑, 그리고 리인덱싱

오픈서치에서 작업을 하다가 매핑의 중요성을 몸소 깨닫게 된 적이 있다. 해당 데이터는 “확률 분포” 데이터였다.

예를 들어, 문서마다 특정 데이터의 확률 분포를 다음과 같이 넣어야 하는 상황이었다.

{
    "positive": 0.3,
    "neutral": 0.5,
    "negative": 0.2
}

평소처럼 동작에만 신경을 쓰고 워크플로우를 돌렸는데, 해당 데이터가 hot에서 warm으로 옮겨지면서 문제가 발견되었다.

최초 데이터의 저장은 hot 인덱스에 저장된다. 이 때, positive 필드가 float으로 동적 매핑이 되었다고 해보자.

그런데, warm 인덱스로 일부 데이터가 옮겨질 때, positive 값이 0.0인 게 맨 처음 들어가게 되어 warm 인덱스에서는 positive 필드가 int 로 매핑이 된 것이다.

그 결과, 이후에 0.3, 0.7 같은 float 값이 들어가려고 할 때마다 전부 매핑 충돌(mapping conflict) 오류가 발생했다.

새로운 필드가 추가되는 작업에서, 사전 매핑을 수행하지 않은 것이 원인이었다.

---

매핑(Mapping)이란

오픈서치에서 매핑은 각 필드가 어떤 타입으로 저장되고 검색되는지를 정의하는 스키마다.

대표적인 타입은 다음과 같다.

• text: 풀텍스트 검색용 (분석기가 적용됨)
• keyword: 정렬, 집계, exact match 용도
• integer, long, float, double: 수치형
• date: 날짜/시간

관계형 DB의 컬럼 타입과 비슷하지만, 한 번 정해진 매핑은 절대 바꿀 수 없다는 게 중요한 차이점이다.

매핑 충돌이 발생 이유

내 사례처럼 0.0 같은 값이 먼저 들어가면 오픈서치는 이를 int로 추론한다.

dynamic mapping은 편리하지만, 데이터 특성을 정확히 보장하지 못한다.

문제는 한 번 int로 매핑되면, 그 필드에 float 값을 넣을 수 없다는 점이다.

즉, 해당 필드명으로는 앞으로 영원히 integer 타입만 받아들여진다.

결국 선택지는 둘 중 하나다.

1. 리인덱싱(reindexing): 새 매핑을 가진 인덱스를 만들고 데이터를 전부 옮긴다.
2. 필드명을 새로 정의: 예를 들어 positive2 같은 이름으로 새 매핑을 만들어서 그 이후 데이터부터 저장한다.

---

리인덱싱(Reindexing) 과정

리인덱싱은 기존 인덱스 데이터를 새 인덱스로 복사하는 작업이다.

POST _reindex
{
    "source": { "index": "old_index" },
    "dest": { "index": "new_index" }
}

여기서 new_index를 만들 때는 반드시 매핑을 명시적으로 정의해야 한다.

PUT new_index
{
    "mappings": {
        "properties": {
            "positive": { "type": "float" },
            "neutral": { "type": "float" },
            "negative": { "type": "float" }
        }
    }
}

이렇게 해두면 더 이상 dynamic mapping에 의존하지 않고, 값이 0.0이든 0.3이든 float 타입으로 안전하게 들어간다.

리인덱싱을 수행하면 기존과 인덱스 명은 바뀌지만, alias를 통해 관리하면 관리 면에서의 차이는 없다.

배운 점

1. dynamic mapping이라는 기능은 없다고 생각하자.
   • 편리해 보여도 결국 발목을 잡는다. 운영 환경에서 새 데이터를 추가하는 경우 반드시 매핑을 미리 정의하자.
2. 매핑 실수는 마치 서비스 배포 전 테스트 수행을 안 한 것과 같다.
   • 매핑 실수가 일어나면, 리더에게 리인덱싱을 요청하거나 이런 실수를 했으니 필드명을 바꿔서 다시 적용하겠다고 자백해야 한다.. 다른 사람의 시간을 뺏는 실수는 가급적 일으키지 말자.