니어 리얼타임 검색 — refresh_interval과 색인 직후 안 보이는 이유
Elasticsearch 공식 문서(elastic.co/docs) 및 기술 블로그 종합 — 아키텍처부터 운영까지 (웹 리서치, 2026) — Elastic 공식 문서 + 여러 기술 블로그(Opster, Baeldung 등) 교차 확인
이 모듈을 다 읽으면
- 문서를 색인한 직후 검색에 바로 안 나오는 이유를 refresh 메커니즘으로 설명할 수 있다
- refresh_interval을 조정할 때의 트레이드오프(색인 처리량 vs 검색 신선도)를 판단할 수 있다
Elasticsearch가 '준실시간(near real-time)'이라 불리는 이유와 refresh_interval의 동작·트레이드오프를 정리한다.
왜 '실시간'이 아니라 '준실시간(NRT)'인가
문서를 색인하면 그 데이터는 먼저 메모리 버퍼(in-memory buffer)와 트랜잭션 로그(translog, 장애 복구용)에 쓰인다 — 이 시점에는 아직 검색되지 않는다. index.refresh_interval(기본 1초)마다 이 메모리 버퍼의 내용이 실제로 검색 가능한 새 Lucene 세그먼트로 구체화(refresh)되는데, 이 refresh가 일어나야 비로소 검색 결과에 나타난다. 그래서 '색인 시점 T'와 '검색 가능해지는 시점' 사이에 최대 refresh_interval만큼의 지연이 생기고, 이를 완전한 실시간이 아니라 '준실시간(Near Real-Time, NRT)'이라 부른다. (참고: refresh와 fsync/디스크 커밋을 담당하는 flush는 다른 개념이다 — refresh는 '검색 가능하게 만드는 것', flush/commit은 translog를 비우고 데이터를 디스크에 확실히 내려쓰는 것이다.)
핵심 포인트
- 색인된 데이터는 먼저 메모리 버퍼+translog에만 있고, refresh가 일어나야 새 세그먼트로 구체화돼 검색 가능해진다
- refresh_interval 기본값 1초 — 이 지연 때문에 '준실시간(NRT)'이라 부른다
- refresh(검색 가능하게 만듦)와 flush(translog를 비우고 디스크에 커밋)는 서로 다른 메커니즘이다
refresh_interval 튜닝 트레이드오프
refresh_interval을 짧게 하면(또는 기본값 그대로 두면) 색인 후 검색 가능해지기까지의 지연이 줄어 신선도가 높아지지만, refresh 자체가 새 세그먼트를 만드는 작업이라 너무 자주 하면 세그먼트가 급격히 늘어나 병합(merge) 부담이 커지고 색인 처리량이 떨어진다. 반대로 refresh_interval을 늘리면(예: 대량 초기 적재 시 -1로 refresh를 아예 끄거나 30s로 늘림) 세그먼트 생성 빈도가 줄어 색인 처리량이 올라가지만, 그만큼 검색 신선도는 떨어진다. 실무 관행은 실시간 검색이 중요하지 않은 대량 벌크 적재 구간에서는 refresh_interval을 늘리거나 끄고, 적재가 끝난 뒤 원래 값(또는 기본값)으로 되돌리는 것이다.
핵심 포인트
- refresh를 자주 하면 신선도↑ 색인 처리량↓(세그먼트 급증→merge 부담), 드물게 하면 반대
- 대량 벌크 적재 구간에서는 refresh_interval을 늘리거나(-1로 끔) 적재 완료 후 원래 값으로 복원하는 게 실무 관행