장애 원인을 추적하거나 특정 장비의 이벤트 흐름을 확인할 때, 운영자는 수많은 로그 데이터 중 필요한 조건에 맞는 결과를 빠르게 찾아야 합니다. 하지만 조회 범위가 넓어지고 시간 조건, 호스트, 이벤트 유형, 상태값 같은 필터가 함께 적용되면 Query DSL 작성 방식에 따라 OpenSearch의 응답 시간이 달라질 수 있습니다.

로그 검색은 일반적인 문서 검색처럼 “관련도 높은 순서”로 결과를 보여주는 것보다, 조건에 맞는 데이터를 정확하고 빠르게 필터링하는 것이 더 중요합니다. 따라서 불필요한 score 계산을 줄이고, Filter Context와 cache를 적절히 활용하는 방식으로 Query DSL을 구성해야 합니다. 이번 글에서는 Query Context와 Filter Context의 차이, Bool Query 구성 방식, Aggregation 사용 시 고려할 점을 중심으로 로그 검색 성능을 높이는 Query DSL 작성 기준을 살펴보겠습니다.

1. Query Context와  Filter Context의 차이

OpenSearch는 쿼리 조건을 Query Context와 Filter Context로 나누어 처리합니다. 두 방식의 가장 큰 차이는 관련도 점수(score) 계산 여부입니다. 로그 검색처럼 조건에 맞는 데이터를 빠르게 찾는 것이 목적이라면, 불필요한 score 계산을 줄일 수 있는 Filter Context가 더 적합합니다.

제니우스 SIEM은 이기종 장비에서 발생하는 대용량 로그를 수집·분석·저장·시각화하는 솔루션입니다. SIEM 환경에서의 로그 검색은 일반적인 문서 검색처럼 “관련도 높은 결과”를 찾는 과정이라기보다, 특정 시간 범위, 장비, 이벤트 유형, 상태값 등 조건에 맞는 데이터를 빠르게 찾아가는 과정에 가깝습니다.

따라서 대부분의 로그·이벤트 조회 조건은 Query Context보다 Filter Context로 처리하는 것이 적합합니다. Filter Context를 사용하면 불필요한 score 계산을 줄이고, 반복 조회 시 cache를 활용할 수 있어 대용량 인덱스에서도 더 안정적인 검색 성능을 기대할 수 있습니다.

---

흔한 실수

range 쿼리를 must 안에 넣으면 문서마다 score를 계산합니다. 같은 조건을 filter 안에 넣으면 계산을 건너뛰고 결과를 캐시합니다. 인덱스가 클수록 이 차이는 커집니다.

→ 실제 운영 인덱스(4.1M 문서) 기준 수치: opensearch-filter-context-benchmark.md

---

앞서 설명한 Query Context와 Filter Context의 차이는 실제 검색 응답에서도 확인할 수 있습니다. 동일한 조건을 조회하더라도 Query Context에서 실행하면 문서별 score가 계산되고, Filter Context에서 실행하면 score 계산 없이 조건 일치 여부만 판단합니다. 이 차이는 응답의 max_score 값과 took 시간에서도 드러납니다.

Context 차이 응답 비교

먼저 Query Context에서 (must) 를 사용한 경우입니다. 이 방식은 조건에 맞는 문서를 찾는 동시에 relevance score를 계산하므로, 응답 결과의 max_score에 실제 score 값이 표시됩니다.

반면 Filter Context에서 filter 를 사용한 경우에는 score 계산이 수행되지 않아 max_score가 null로 표시됩니다. 또한 동일 조건을 반복 조회하면 cache hit가 발생해 두 번째 호출부터 took 시간이 크게 줄어듭니다.

2. Leaf Query: 검색 조건을 구성하는 기본 단위

Leaf Query는 OpenSearch Query DSL에서 단일 조건을 검사하는 기본 쿼리입니다. 특정 필드의 값 일치 여부, 필드 존재 여부, 날짜·숫자 범위 포함 여부처럼 하나의 조건을 판단합니다.

로그 검색에서는 여러 Leaf Query를 Bool Query 안에서 조합해 사용하는 경우가 많습니다. 쿼리 종류에 따라 처리 비용과 캐시 활용 여부가 달라지므로, 먼저 자주 사용하는 Leaf Query를 상대 속도 기준으로 비교해보겠습니다.

속도 기준 한눈에 보기

match_all — 전체 조회

match_all은 인덱스의 모든 문서를 조회 대상으로 삼는 가장 단순한 쿼리입니다. 별도의 조건 판단이나 문서 간 relevance 계산이 필요하지 않기 때문에 Leaf Query 중에서도 처리 비용이 낮은 편입니다.

로그 검색에서는 전체 데이터를 모두 가져오기보다, 정렬 조건과 함께 최신 또는 가장 오래된 단건을 확인할 때 유용합니다. 예를 들어 size: 1과 indextime 기준 정렬을 조합하면 특정 인덱스에서 가장 최근에 수집된 로그를 빠르게 확인할 수 있습니다.

다만 match_all은 조회 대상이 전체 문서이기 때문에 큰 size 값과 함께 사용하면 응답 데이터가 급격히 늘어날 수 있습니다. 전체 문서를 순차적으로 처리해야 한다면 한 번에 많은 데이터를 가져오기보다 search_after와 같은 페이지네이션 방식을 함께 사용하는 것이 적합합니다.

match_all + size: 10000은 느립니다. 전체 문서가 필요하다면 search_after 페이지네이션과 함께 사용하세요.

응답 예시

term / terms — 정확한 값 매칭

inverted index를 직접 조회하므로 빠릅니다. filter 안에서는 bitset 캐시까지 활용합니다.

---

 .keyword 필드를 반드시 사용하세요.

text 타입 필드는 analyzer가 토크나이징한 결과를 저장하므로 term 쿼리와 불일치합니다.

예: "AXGATE-300" → ["axgate", "300"]으로 분리 저장 → term: "AXGATE-300" 매칭 실패

---

응답예시

exists — 필드 존재 여부

null/not-null 판단 전용. must_not과 조합하면 “필드가 없는 문서만 조회”가 됩니다.

응답 예시

range — 날짜·숫자 범위

filter 안에서만 캐시됩니다. must 안에 넣으면 score 계산이 발생합니다.

날짜 math 표현식(now-1d/d, now/h)은 rounding을 포함하므로 캐시 재사용률이 높아집니다. now 단독 사용보다 now/m, now/h처럼 rounding을 붙이는 것이 캐시에 유리합니다.

응답 예시

💡 동일 쿼리 두 번째 호출에서는 took이 1~2ms로 떨어집니다. bitset 캐시 hit입니다.

match_phrase — 구문 검색

단어 순서와 위치까지 검사하므로 analyzer를 통과합니다. query context에서 실행되므로 score 계산이 발생합니다.

💡 대안 검토

완전히 동일한 문자열을 매칭한다면 match_phrase 대신 keyword 필드 + term 쿼리로 교체하세요. scoring 없이 캐시가 적용되어 빠릅니다.

응답 예시

Lucene 쿼리 문자열 (?q=) — Spark 연동 전용

Spark-OpenSearch 커넥터에서 URL 파라미터로 전달하는 방식입니다. 내부적으로 query_string 쿼리로 파싱됩니다.

---

 wildcard(*) 사용을 주의하세요.

?q=zhost:* 같은 wildcard는 전체 term을 스캔합니다. Spark 연동에서 불가피하게 사용할 경우 인덱스 범위(dataSource)를 최대한 좁혀서 대상 문서 수를 줄이는 것이 중요합니다.

---

3. Bool Query- 여러 조건을 조합하는 방식

Bool Query는 여러 Leaf Query를 조합해 복합 검색 조건을 구성하는 쿼리입니다. 시간 범위, 장비명, 이벤트 유형, 상태값처럼 여러 조건을 함께 적용해야 하는 로그 검색에서 가장 자주 사용됩니다.

이때 중요한 것은 각 조건을 must, should, filter, must_not 중 어디에 배치하느냐입니다. 같은 조건이라도 Query Context에서 실행되면 score 계산이 발생하고, Filter Context에서 실행되면 조건 판단만 수행하므로 성능 차이가 생길 수 있습니다.

must vs filter — 같은 조건, 다른 비용

📄 동일 조건 응답 비교 (운영 인덱스 4.1M 문서 기준)

❌ must 버전

✅ filter 버전 (캐시 hit 후)

Bool Query 조합 판단 기준

4. Aggregation- 로그 데이터를 그룹화하고 집계하는 방식

Query가 조건에 맞는 문서를 찾아내는 과정이라면, Aggregation은 조회된 로그 데이터를 그룹화하거나 집계해 통계 형태로 만드는 과정입니다. 장비별 이벤트 수, 시간대별 로그 발생량, 이벤트 유형별 분포처럼 운영자가 상태를 파악하는 화면에서 주로 활용됩니다.

Aggregation은 Metric, Bucket, Pipeline Aggregation으로 나뉘며, 각 방식은 처리 목적과 비용이 다릅니다. 따라서 원하는 집계 결과뿐만 아니라 bucket 수, 응답 크기, 메모리 사용량까지 함께 고려해 설계해야 합니다.

---

집계만 할 때는 반드시 "size": 0

size: 0을 설정하지 않으면 hits(문서 본문)도 함께 반환됩니다.

집계 결과만 필요한 경우 hits 반환은 네트워크와 메모리 낭비입니다.

---

4-1. Metric Aggregation

Metric Aggregation은 조회된 문서를 기준으로 합계, 평균, 최댓값, 최솟값, 개수와 같은 숫자 값을 계산하는 집계 방식입니다. 버킷 없이 단독으로 사용할 수도 있고, 장비별·시간대별 그룹 안에서 세부 통계를 계산하는 용도로 중첩해 사용할 수도 있습니다

value_count — 가장 빠른 집계

doc_values(컬럼 스토리지)에서 필드 값을 읽어 카운트합니다. _source(문서 본문)를 읽지 않고 score 계산도 없어 집계 중 가장 빠릅니다.

응답 예시

sum — 합계

응답 예시

avg / max / min — 평균·최대·최소

응답 예시

cardinality — 유니크 값 수 (근사값)

HyperLogLog++ 알고리즘으로 근사값을 반환합니다. 기본 오차율 약 5%입니다.

응답 예시

4-2. Bucket Aggregation-문서를 그룹으로 나누는 집계

Bucket Aggregation은 조회된 문서를 특정 기준에 따라 그룹으로 나누는 집계 방식입니다. 장비별 이벤트 수, 이벤트 유형별 분포, 시간대별 로그 발생량처럼 데이터를 구간이나 항목 단위로 나누어 확인할 때 사용합니다. 다만 생성되는 bucket 수가 많아질수록 메모리 사용량과 집계 비용이 증가하므로, 필요한 기준과 범위를 적절히 제한해 사용하는 것이 중요합니다.

terms — 필드 값 기준 그룹화

---

 terms 버킷의 메모리 함정

size: 1000은 각 shard에서 상위 1000개씩 수집한 뒤 coordinator 노드에서 병합합니다.

shard가 5개라면 최대 5,000개 버킷이 메모리에 올라옵니다.

필요한 수만큼만 지정하세요.

 _id, longid처럼 cardinality가 매우 높은 필드에는 terms agg를 사용하지 마세요. 버킷 수가 폭발적으로 증가합니다.

---

응답 예시

multi_terms — 복합 필드 그룹화

두 개 이상의 필드 조합으로 그룹화합니다. 단일 terms보다 비용이 높습니다.

예: (zhost, zapptype) 조합별 이벤트 수를 한 번에 구할 때 사용합니다.

응답 예시

date_histogram — 시간 기준 그룹화

시계열 차트 데이터를 만드는 가장 기본적인 방법입니다.

fixed_interval vs calendar_interval 선택 기준:

---

 interval이 좁을수록 버킷 수가 급증합니다.

1주 데이터를 1m interval로 조회하면 버킷이 10,080개입니다.

aggregationTypes.js의 DATE_INTERVAL_OPTIONS에는 1h~1y가 정의되어 있습니다.

단, 1M·1y는 calendar_interval 전용 값이므로 fixed_interval로 전달하면 400 오류가 발생합니다. 월·연 단위 집계 시에는 반드시 calendar_interval을 사용하세요.

---

응답 예시

4-3. Pipeline Aggregation- 집계 결과를 다시 처리하는 방식

Pipeline Aggregation은 Bucket Aggregation으로 생성된 결과를 다시 처리하는 집계 방식입니다. 특정 bucket을 필터링하거나, 정렬·제한하거나, metric 값을 조합해 계산 값을 만들 때 사용하며, SQL의 HAVING, ORDER BY, 계산 컬럼과 유사한 역할을 합니다.

제니우스 SIEM에서는 화면에서 설정한 집계 조건을 OpenSearch Query DSL로 변환해 처리합니다. 이때 Pipeline Aggregation의 타입은 render/js/aggregation/aggregationTypes.js에서 정의하고, Query DSL 생성 로직은 render/js/aggregation/buildAggQuery.js에서 담당합니다

타입 정의: render/js/aggregation/aggregationTypes.js

변환 로직: render/js/aggregation/buildAggQuery.js

bucket_selector — HAVING 필터

bucket_selector는 집계를 모두 수행한 뒤 결과를 걸러냅니다.

집계 연산 자체는 줄어들지 않습니다. 응답 크기만 줄어듭니다.

📄 응답 예시 (count < 10인 버킷 제거됨)

bucket_sort — 정렬·페이지 제한

응답 예시

bucket_script — 계산 컬럼 생성

📄 응답 예시 (avg_bytes가 서버 계산 결과로 추가됨)

앞서 살펴본 Metric, Bucket, Pipeline Aggregation은 실제 서비스에서는 단독으로 사용되기보다 여러 단계로 중첩되어 하나의 집계 쿼리를 구성하는 경우가 많습니다. 다음은 제니우스 SIEM에서 활용할 수 있는 대표적인 중첩 패턴입니다.

4-4. 실전 중첩 패턴

패턴 A: 프로세스별 시계열 메트릭 (system-metric.service.js)

terms → date_histogram → avg/max/min 3단 중첩에, 프로세스 전체 통계를 병렬로 추가합니다.

응답 예시

패턴 B: buildAggQuery 빌더가 생성하는 구조

AggregationConfig → buildAggQuery() → OpenSearch aggs JSON 변환 흐름입니다.

text 타입 필드는 resolveAggField()가 .keyword를 자동으로 붙여줍니다.

📄 응답 예시

OpenSearch Query DSL은 같은 조건을 표현하더라도 어떤 Context와 clause에 배치하느냐에 따라 검색 비용이 달라질 수 있습니다. 로그·이벤트 검색처럼 관련도 순위보다 조건 일치 여부가 중요한 경우에는 불필요한 score 계산을 줄이고, Filter Context를 적극적으로 활용하는 것이 중요합니다.

Aggregation 역시 집계 결과뿐만 아니라 size: 0 설정, bucket 수, date_histogram의 interval, Pipeline Aggregation의 실행 특성을 함께 고려해야 합니다. 이러한 기준을 반영하면 대용량 로그 환경에서도 검색 응답 시간과 리소스 사용량을 더 안정적으로 관리할 수 있습니다.

제니우스 SIEM처럼 대용량 로그를 수집·분석·저장·시각화하는 환경에서는 이러한 작은 Query DSL 설계 차이가 실제 검색 성능과 사용성에 직접적인 영향을 줄 수 있습니다. 앞으로도 실제 운영 과정에서 확인한 개선 포인트를 기반으로 검색 성능을 지속적으로 고도화해 나갈 예정입니다.