Reindex Slicing — 큰 재색인을 여러 조각으로 쪼개 병렬화하기
Elasticsearch Reindex Slicing 및 Document/Field Level Security 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(docs-reindex, controlling-access-at-document-field-level) Elastic 공식문서 Reindex API — Slicing
이 모듈을 다 읽으면
- elasticsearch-learn-11의 재색인이 기본적으로 단일 스레드로 순차 실행된다는 한계와, slices가 이를 어떻게 병렬화하는지 설명할 수 있다
- 슬라이스 개수를 shard 수와 맞춰야 하는 이유와 auto 옵션의 동작 방식을 설명할 수 있다
elasticsearch-learn-11에서 다룬 매핑 무중단 전환의 핵심 도구인 _reindex가 기본적으로는 단일 스레드라 대용량 인덱스에서 느리다는 것을 전제로, sliced scroll 기반 병렬화(slices)의 원리와 실무 튜닝 기준을 정리한다.
기본 재색인은 단일 스레드 — slices로 쪼갠다
_reindex API를 아무 옵션 없이 호출하면 내부적으로 scroll 하나로 원본 인덱스를 순차적으로 읽어 대상 인덱스에 쓴다 — 즉 단일 스레드 작업이라 대용량 인덱스에서는 시간이 오래 걸린다. slices 파라미터를 쓰면 이 scroll을 여러 개의 독립적인 조각(slice)으로 쪼개 병렬로 처리할 수 있다 — 각 슬라이스가 문서 부분집합을 담당해 스캔·색인을 동시에 진행하므로 전체 처리 시간이 줄어든다.
핵심 포인트
- 옵션 없는 기본 _reindex는 scroll 하나로 순차 처리하는 단일 스레드 작업
- slices 파라미터로 scroll을 여러 조각으로 쪼개 병렬 처리 — 문서 부분집합을 슬라이스마다 나눠 스캔·색인을 동시 진행
수동 슬라이싱 vs 자동 슬라이싱(slices=auto)
슬라이싱은 두 가지 방식으로 쓸 수 있다. 수동 방식은 요청마다 slice의 id와 전체 슬라이스 수(max)를 직접 지정해, 그 여러 요청을 애플리케이션이 각각 병렬로 보내는 방식이다. 더 간편한 방식은 slices 값을 auto로 주는 것 — 이 경우 Elasticsearch가 알아서 슬라이스 개수를 정하는데, 원칙적으로 샤드당 슬라이스 1개를 기준으로 상한을 두고 결정한다. 원격 클러스터(remote reindex)에서는 수동·자동 슬라이싱 둘 다 지원되지 않는다는 제약도 있다.
핵심 포인트
- 수동 슬라이싱: 요청마다 slice.id/slice.max를 직접 지정해 애플리케이션이 병렬로 여러 요청을 보냄
- 자동 슬라이싱(slices=auto): Elasticsearch가 샤드당 1개 슬라이스를 기준으로 상한 안에서 자동 결정 — 단, 원격 클러스터 reindex는 슬라이싱 자체를 지원 안 함
튜닝 기준 — 슬라이스 수는 샤드 수에 맞춰야 한다
슬라이스 개수를 원본 인덱스의 샤드 수와 일치시킬 때 쿼리 성능이 가장 효율적이다. 샤드 수가 500처럼 매우 많다면 더 낮은 슬라이스 수를 고르는 게 낫다 — 슬라이스가 너무 많으면 오히려 성능이 떨어지기 때문이다. 반대로 슬라이스 수를 샤드 수보다 높게 잡는다고 일반적으로 효율이 더 좋아지지는 않고, 조율 오버헤드만 늘어난다. 결국 '샤드 수만큼'이 기본 기준점이고, 샤드가 극단적으로 많을 때만 예외적으로 낮춰 잡는다.
핵심 포인트
- 슬라이스 수 = 원본 샤드 수일 때 가장 효율적
- 샤드가 매우 많으면(예 500개) 슬라이스 수를 낮게 잡을 것 — 슬라이스가 너무 많으면 오히려 성능 저하, 샤드 수보다 높게 잡아도 일반적으로 이득 없이 오버헤드만 증가