Shard Request Cache — 검색 결과 자체를 캐싱한다
Elasticsearch Shard Allocation Awareness 및 Shard Request Cache 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(shard-allocation-awareness, shard-request-cache) Elastic 공식문서 The shard request cache
이 모듈을 다 읽으면
- shard request cache가 refresh 시점마다 무효화되는 이유를 elasticsearch-learn-04와 연결해 설명할 수 있다
- 이 캐시가 기본적으로 문서 히트(hits)는 캐싱하지 않고 집계·suggestion 위주로 캐싱한다는 것을 설명할 수 있다
elasticsearch-learn-04에서 다룬 refresh_interval(색인이 검색 가능해지는 주기)을 전제로, 그 refresh 시점을 기준으로 자동 무효화되는 shard 단위 검색 결과 캐시를 정리한다.
동작 방식 — 요청 본문을 해시해서 캐시를 찾는다
검색 요청이 샤드에 도착하면, Elasticsearch는 요청 본문을 해시해 그 샤드에 대한 캐시된 결과가 있는지 확인한다. 캐시에 있으면(hit) 쿼리를 다시 실행하지 않고 캐시된 결과를 그대로 반환하고, 없으면(miss) 평소대로 쿼리를 실행한 뒤 캐싱 대상이면 그 결과를 캐시에 저장한다. 캐시가 가득 차면 가장 오래 안 쓰인(LRU) 캐시 항목부터 밀려난다.
핵심 포인트
- 요청 본문을 해시해 캐시 hit/miss 판정 — hit이면 쿼리 재실행 없이 캐시된 결과 그대로 반환, miss면 실행 후 캐싱
- 캐시가 가득 차면 LRU(가장 오래 안 쓰인 항목)부터 밀려남
무효화 시점 — refresh와 매핑 변경에 묶여 있다
캐시된 결과는 그 샤드가 refresh될 때(elasticsearch-learn-04에서 다룬, 문서가 검색 가능해지는 그 시점), 즉 문서 변경사항이 실제로 반영될 때 자동으로 무효화된다 — 매핑을 변경할 때도 무효화된다. 그래서 refresh_interval을 길게 잡을수록, 그동안 문서가 바뀌어도 캐시된 항목이 더 오래 유효하게 남아있게 된다(refresh 자체가 늦게 일어나므로). 수동으로는 clear-cache API(POST /인덱스/_cache/clear?request=true)로 즉시 비울 수도 있다.
핵심 포인트
- 캐시 무효화는 그 샤드의 refresh 시점(module04)이나 매핑 변경 시 자동으로 일어남
- refresh_interval을 길게 잡을수록 캐시가 더 오래 유효 — refresh 자체가 늦게 일어나기 때문. 수동 무효화는 clear-cache API
무엇을 캐싱하는가 — 문서 히트가 아니라 집계·건수·suggestion 위주
이 캐시는 기본적으로 size: 0인 요청(문서 자체를 반환하지 않는 요청)을 캐싱 대상으로 삼는다 — 즉 개별 문서 히트(hits)는 기본적으로 캐싱하지 않지만, hits.total(전체 매칭 건수), 집계(aggregation) 결과, suggestion 결과는 캐싱될 수 있다. 이는 계속 바뀌는 최신 데이터를 대상으로 하는 대시보드성 집계 쿼리(예: '지난 24시간 에러 건수 추이')를 반복 실행할 때 특히 유용하다 — 매번 전체 집계를 다시 계산하는 대신 캐시를 재사용할 수 있다.
핵심 포인트
- size: 0 요청(문서 자체를 안 반환) 대상 — 개별 문서 히트는 기본적으로 캐싱 안 됨, hits.total·집계·suggestion 결과는 캐싱 가능
- 반복 실행되는 대시보드성 집계 쿼리에 특히 유용 — 매번 전체 재계산 대신 캐시 재사용