재색인(Reindex)과 alias — 매핑을 바꾸는 무중단 전환
Elasticsearch Reindex/Alias 무중단 전환 및 Ingest Pipeline 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Elastic 공식 문서(changing-mapping-with-zero-downtime, ingest-simulate) + 기술 블로그 종합 Elastic 공식 블로그 'Changing Mapping with Zero Downtime'
이 모듈을 다 읽으면
- 이미 존재하는 필드의 매핑을 왜 그 자리에서 바로 못 바꾸는지 설명할 수 있다
- alias 기반 무중단 전환의 3단계(신규 인덱스 생성→reindex→alias 스위치)를 설명할 수 있다
- 애플리케이션이 인덱스 이름을 직접 참조하면 왜 이 패턴이 무의미해지는지 판단할 수 있다
elasticsearch-learn-03에서 다룬 매핑을 실제로 바꿔야 할 때(예: text를 keyword로 변경) 어떻게 무중단으로 전환하는지, _reindex API와 alias 조합의 표준 패턴을 정리한다.
왜 매핑을 그 자리에서 못 바꾸는가
elasticsearch-learn-02에서 다룬 것처럼 Lucene 세그먼트는 불변이고, 이미 색인된 필드는 특정 analyzer·타입으로 이미 물리적으로 저장돼 있다. 매핑에서 어떤 필드의 타입을 바꾸는 것(예: text를 keyword로)은 이미 저장된 데이터의 물리적 형태 자체를 바꾸라는 요구인데, Elasticsearch는 이를 그 자리에서 지원하지 않는다 — 새 매핑을 가진 새 인덱스를 만들고 데이터를 옮기는 것(재색인)이 유일한 방법이다.
핵심 포인트
- 이미 색인된 필드는 특정 analyzer·타입으로 물리적으로 저장돼 있어 매핑을 그 자리에서 못 바꾼다
- 타입을 바꾸려면 새 매핑의 새 인덱스를 만들고 데이터를 옮기는 재색인이 유일한 방법
표준 패턴 — 신규 인덱스 생성 → _reindex → alias 스위치
표준 절차는 세 단계다. (1) 원하는 새 매핑으로 신규 인덱스를 만든다. (2) _reindex API로 기존 인덱스의 문서를 전부 새 인덱스로 복사한다(필요하면 이 과정에서 스크립트로 값 변환도 가능하다). (3) 기존 인덱스에서 alias를 떼고 새 인덱스에 같은 alias를 붙이는 것을 원자적(단일) 연산으로 수행한다 — 이 스위치 순간이 원자적이라 그 사이에 요청이 어중간한 상태를 보는 일이 없다. 이 패턴이 성립하려면 전제조건이 하나 있다: 애플리케이션이 처음부터 인덱스 이름이 아니라 alias를 대상으로 쿼리해야 한다. 애플리케이션이 실제 인덱스 이름을 직접 하드코딩해 참조하고 있었다면, 이 무중단 전환 패턴 자체를 적용할 수 없다 — 그래서 실무에서는 처음 인덱스를 설계할 때부터 애플리케이션이 alias만 바라보게 만드는 것이 표준 관행이다.
핵심 포인트
- 표준 3단계: 새 매핑으로 신규 인덱스 생성 → _reindex로 데이터 복사 → alias를 구인덱스에서 신인덱스로 원자적 스위치
- 전제조건: 애플리케이션이 인덱스 이름이 아니라 alias를 대상으로 쿼리해야 한다 — 처음부터 alias로 설계하는 게 표준 관행
전환 중 새로 들어오는 쓰기는 어떻게 하는가
_reindex가 진행되는 동안(대량 데이터라면 시간이 걸릴 수 있다)에도 원본 인덱스에는 계속 새 문서가 쓰일 수 있다. 이를 놓치지 않으려면 애플리케이션 레벨에서 그 기간 동안 신규/변경 데이터를 구인덱스와 신인덱스 양쪽에 동시에 쓰는(dual-write) 방식을 임시로 적용하거나, _reindex를 완료한 뒤 '재색인 시작 시점 이후 변경된 문서만' 다시 한 번 델타 재색인하는 방식으로 누락을 보완한다.
핵심 포인트
- 재색인 도중 원본에 계속 쓰기가 발생하는 문제를 막으려면 dual-write 또는 델타 재색인으로 보완해야 한다