Elasticsearch 3TB의 인덱스를 reindex 하는 방법

다나와 검색 시스템이 10억 건 이상의 상품 문서, 약 3TB 인덱스를 매주 reindex하면서 겪은 이슈와 대응을 정리한 글이다. 사전 변경 적용과 mapping 변경을 반영하려면 주간 reindex가 필요하고, 레플리카를 포함해 10~11시간이 걸린다. 클러스터는 마스터 2대와 데이터 16대로 총 18노드이며 버전은 7.8.1 기준이라 최신 버전과는 결과가 다를 수 있다.

핵심 포인트

replica는 reindex에 포함하지 말고 끝난 뒤에 만든다. 사본을 끼고 색인하면 초기 IO가 높아져 매우 오래 걸린다
대상 인덱스에 검색이 들어올 일이 없으므로 refresh_interval을 -1로 두어 새로 고침 프로세스를 끈다
reindex는 search 후 bulk 구조라 size 파라미터를 올려가며 속도가 더 안 오르는 지점을 찾는다. 기본값은 1,000이다
작업 속도는 프라이머리 샤드 수에 비례하지만 자원 사용량도 같이 오르므로 조정 대상이다
es_rejected_execution_exception은 검색 스레드 풀 큐 한도 1,000을 넘겨 발생했고 실제로 문서 누락으로 이어졌다
circuit_breaker_exception은 메모리 사용량 이슈라 작업 시간대를 옮기거나 옵션으로 부하를 낮춘다

상세 정리

규모: 상품 수가 10억 건 이상이고 계속 증가하는 추세이며 인덱스는 3.X TB다
주기: 검색 품질을 높이기 위한 사전 변경과 mapping 변경 때문에 매주 reindex를 수행한다
배치 튜닝법: 색인 속도에 더는 영향이 없을 때까지 size를 올려 최대 속도 지점을 찾는 방식을 권한다. 환경마다 다르므로 몇 번의 시도가 필요하다
샤드 수 고려: 색인 중에는 문서 변경분을 반영하기 어려워 빠를수록 좋지만 자원 사용량과 함께 봐야 한다
큐 초과 상황: 운영 중 reindex에서 실제로 발생했고 reindex가 실패하며 많은 문서가 누락됐다
인덱스 이중화 효과: A·B 두 벌로 관리하고 있어 오색인된 인덱스로 전환되지는 않았지만 정상 색인도 되지 않았다
원인 해석: 검색 요청이 들어오면 스레드 풀에서 스레드를 할당받는데 최대 큐 사이즈를 초과해 거부된 것으로 봤다
스로틀링 산식: target_time을 기본 배치 사이즈 나누기 초당 처리량으로 잡고 거기서 write_time을 뺀 값을 wait_time으로 둔다
조치 결과: target_time을 조절해 wait_time을 늘리자 큐 초과 현상이 줄거나 발생하지 않게 됐다
서킷 브레이커 발생 지점: 작업 시간이 길어 중간에 검색·색인 부하가 겹칠 때 나온다
replica 생성 시 대응: indices.recovery.max_bytes_per_sec를 128mb로 낮춰 사본 생성 속도를 늦추면 해결된다
일반화: 검색 상품 데이터는 로그나 모니터링 지표에 비해 필드 수가 많고 데이터도 방대해 색인 시 부하가 훨씬 크다