Profile API — 쿼리가 실제로 어디서 시간을 쓰는지 들여다보기
Elasticsearch multi_match 쿼리 타입 및 Profile API 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(query-dsl-multi-match-query, search-profile) + Opster 기술 블로그 Elastic 공식 문서 Profile search requests
이 모듈을 다 읽으면
- Profile API가 쿼리 실행을 어떤 두 축(Query/Collectors)으로 나눠 분석하는지 설명할 수 있다
- breakdown이 알려주는 정보를 실제 튜닝 판단에 활용할 수 있다
느린 쿼리를 진단할 때 clickhouse의 EXPLAIN, spark의 Spark UI에 대응하는 elasticsearch의 진단 도구 — Profile API로 쿼리 실행 시간이 실제로 어디에 쓰였는지 뜯어보는 방법을 정리한다.
profile: true — 쿼리 실행을 두 축으로 쪼개서 본다
검색 요청에 "profile": true를 추가하면, 응답에 그 쿼리가 실제로 어떻게 실행됐는지에 대한 상세 타이밍 정보가 함께 온다. 이 정보는 크게 두 축으로 나뉜다: Query 부분은 실제 매칭 로직(term 조회, bool 절 결합 등)에 걸린 시간을, Collectors 부분은 매칭된 문서를 모으고 정렬·집계하는 데 걸린 시간을 보여준다 — 이 둘은 Lucene 실행 구조상 서로 독립적으로 계산되기 때문에 하나로 합쳐서 보여줄 수 없어 응답에서도 별도 섹션으로 분리된다.
핵심 포인트
- profile: true를 검색 요청에 추가하면 상세 타이밍 정보가 응답에 포함된다
- Query(매칭 로직 시간)와 Collectors(문서 수집·정렬·집계 시간)는 서로 독립적으로 계산돼 응답에서도 분리된 섹션으로 나온다
breakdown으로 병목 지점 좁히기
각 쿼리 노드의 breakdown 필드는 그 쿼리를 이루는 Lucene 내부 연산(예: 매칭 여부 판단 자체, next_doc으로 다음 후보 문서로 넘어가는 과정 등)별로 시간을 나눠 보여준다 — 이는 '이 쿼리가 왜 느린지'를 감으로 짐작하는 대신 실제로 어느 연산이 시간을 잡아먹는지 데이터로 확인하는 용도다. time_in_nanos 값은 자식 노드를 포함한 누적치이므로, 여러 절이 중첩된 bool 쿼리를 분석할 때는 트리 구조를 따라가며 어느 하위 절이 유독 오래 걸리는지 비교해야 한다.
핵심 포인트
- breakdown은 Lucene 내부 연산 단위로 시간을 세분화해 병목을 데이터로 확인하게 해준다
- time_in_nanos는 자식 노드 포함 누적치 — 중첩된 bool 쿼리는 트리를 따라가며 하위 절 단위로 비교해야 한다
실무 주의점 — 오버헤드와 프로덕션 사용 자제
Profile API는 그 자체로 상세한 계측 코드를 추가로 실행시키는 것이므로, 프로파일링을 켠 쿼리는 켜지 않았을 때보다 느리게 실행된다(계측 오버헤드) — 그래서 이 API는 프로덕션에서 상시로 켜두는 용도가 아니라, 특정 느린 쿼리를 개발/스테이징 환경에서 진단할 때 한시적으로 쓰는 도구로 취급해야 한다.
핵심 포인트
- Profile API 자체가 계측 오버헤드를 유발한다 — 상시 프로덕션 사용이 아니라 특정 쿼리 진단용 한시적 도구로 취급