Elasticsearch가 문서 저장 성공을 반환했는데 바로 실행한 검색에는 문서가 없습니다. 왜 지연되며 즉시 확인이 필요한 화면은 어떻게 만드나요?

Elasticsearch의 색인 요청이 성공했다는 응답과 검색 결과에 문서가 나타나는 시점은 다를 수 있습니다. 문서는 먼저 색인 버퍼와 세그먼트 생성 경로를 거치고, refresh가 새 세그먼트를 검색 리더에 공개한 뒤 검색에서 보입니다. 그래서 Elasticsearch를 일반적인 관계형 DB의 즉시 검색 테이블처럼 다루지 않고 near real-time 검색 계약을 명시하겠습니다.

즉시 확인과 대량 색인을 분리합니다

저장 직후 사용자가 같은 문서를 확인해야 한다면 ID 기반 GET과 검색 결과의 가시성을 분리할 수 있습니다. 문서 ID를 알고 있으면 검색 refresh를 기다리지 않는 경로가 더 적합할 수 있고, 반드시 검색으로 확인해야 하는 특정 요청에는 refresh=wait_for처럼 다음 refresh까지 기다리는 정책을 검토합니다. 즉시 강제 refresh는 해당 요청의 검색 가시성을 앞당기지만 모든 쓰기에 적용하면 작은 세그먼트·병합·I/O와 색인 처리량 비용이 커집니다.

refresh 주기와 동시 색인 부하는 버전·클러스터 상태에 따라 지연을 바꿉니다. 대량 색인 중 refresh를 자주 하면 처리량이 떨어지고, 드물게 하면 사용자 검색의 최신성 지연이 늘어납니다. 저장 성공 후 ‘몇 초 안에 검색’ 같은 SLO를 측정해 화면별로 허용 범위를 정하겠습니다. 검색 결과가 늦으면 저장 실패로 표시하지 않고, 원본 상태나 색인 지연 상태를 사용자에게 맞는 방식으로 보여 줍니다.

검색 가시성·내구성·복제를 구분합니다

refresh는 검색 리더가 새 세그먼트를 보게 하는 작업이지 모든 변경이 디스크에 안전하게 flush됐다는 의미가 아닙니다. flush, translog 내구성, replica ACK, 샤드 장애 복구는 별도의 계약입니다. Elasticsearch의 primary 샤드와 replica 샤드, 클러스터 상태, 색인 요청의 반환 시점도 관계형 DB의 commit과 1:1로 대응하지 않습니다. 원본 DB가 있다면 DB 커밋·outbox·색인 이벤트·검색 노출을 하나의 즉시 트랜잭션이라고 말하지 않겠습니다.

검증은 색인 ACK 직후 ID 조회와 검색을 반복해 노출 지연 분포를 기록하고, 강제 refresh·wait_for·기본 refresh에서 처리량과 p99를 비교하는 방식으로 하겠습니다. 대량 입력, 샤드 재배치, replica 장애, refresh 중단도 포함합니다. refresh 호출 횟수만 성공 기준으로 두지 않고 검색 가시성 지연, 세그먼트 수·병합 비용, 복구 후 문서 보존을 별도로 확인하는 것이 핵심입니다.

검색 인덱스가 원본 DB의 보조 모델이라면 문서가 아직 검색되지 않는 상태와 색인 실패를 구분해 상태를 표시해야 합니다. 이벤트가 중복되거나 순서가 바뀌어도 문서 버전이 낮은 업데이트를 무시하고, 색인 실패는 재시도 큐와 대조 작업으로 복구하겠습니다. 샤드 replica가 있다고 refresh 지연이나 원본과의 정합성이 자동 해결되는 것은 아닙니다. 검색 화면에서 즉시 필요한 필드만 원본 조회로 보강하는 절충도 요청량과 원본 부하를 측정해 결정하겠습니다.