Elasticsearch 집계(Aggregations) 고급 완벽 가이드

Elasticsearch의 고급 집계 기능을 다룹니다. Pipeline 집계부터 bucket_script, moving_avg, significant_terms, composite 집계, 그리고 성능 최적화까지 실무에서 바로 활용할 수 있는 내용을 담았습니다.

---

목차

1. Pipeline_집계_개념
2. bucket_script_계산
3. moving_avg_이동평균
4. significant_terms_분석
5. composite_집계_페이징
6. 집계_성능_최적화

---

1. Pipeline 집계 개념

어느 날 김개발 씨는 월별 매출 데이터를 집계하던 중 이상한 요구사항을 받았습니다. "각 월의 매출뿐만 아니라, 전월 대비 성장률도 함께 보여주세요." 단순히 합계를 구하는 것만으로는 부족한 상황이었습니다.

Pipeline 집계는 다른 집계의 결과를 입력으로 받아 추가 연산을 수행하는 집계입니다. 마치 공장의 컨베이어 벨트처럼, 앞 단계에서 만들어진 결과물을 다음 단계에서 가공하는 방식입니다.

이를 활용하면 집계 결과에 대한 파생 지표를 한 번의 쿼리로 계산할 수 있습니다.

다음 코드를 살펴봅시다.

GET /sales/_search
{
  "size": 0,
  "aggs": {
    "monthly_sales": {
      "date_histogram": {
        "field": "date",
        "calendar_interval": "month"
      },
      "aggs": {
        "total_amount": { "sum": { "field": "amount" } },
        "cumulative_sales": {
          "cumulative_sum": { "buckets_path": "total_amount" }
        }
      }
    }
  }
}

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 오늘 팀장님으로부터 대시보드 개선 요청을 받았습니다.

기존에는 월별 매출 합계만 보여주던 화면에 누적 매출과 성장률까지 추가해야 했습니다. 처음에는 단순하게 생각했습니다.

월별 매출을 먼저 조회하고, 애플리케이션 코드에서 누적합을 계산하면 되지 않을까요? 하지만 선배 개발자 박시니어 씨가 고개를 저었습니다.

"그렇게 하면 데이터가 많아질수록 애플리케이션 서버에 부담이 커져요. Elasticsearch의 Pipeline 집계를 사용해보세요." 그렇다면 Pipeline 집계란 정확히 무엇일까요?

쉽게 비유하자면, Pipeline 집계는 마치 요리 과정과 같습니다. 첫 번째 요리사가 재료를 손질하고, 두 번째 요리사가 그 재료로 요리를 만들고, 세 번째 요리사가 완성된 요리를 플레이팅합니다.

각 단계가 이전 단계의 결과물을 받아서 작업을 이어가는 것입니다. Pipeline 집계도 마찬가지입니다.

먼저 Parent 집계가 기본 버킷을 만들고, 그 안에서 Metric 집계가 값을 계산합니다. 그리고 Pipeline 집계가 이 결과를 받아 추가 연산을 수행합니다.

Pipeline 집계가 없던 시절에는 어땠을까요? 개발자들은 Elasticsearch에서 기본 집계 결과를 가져온 뒤, 애플리케이션 레벨에서 누적합이나 이동평균을 직접 계산해야 했습니다.

코드가 복잡해지고, 네트워크 전송량도 늘어났습니다. 무엇보다 실시간 대시보드에서는 성능 저하가 심각했습니다.

Pipeline 집계는 크게 두 가지 유형으로 나뉩니다. 첫 번째는 Parent Pipeline 집계입니다.

이것은 형제 집계의 결과를 참조합니다. 위 코드의 cumulative_sum이 바로 이 유형입니다.

total_amount라는 형제 집계의 결과를 받아서 누적합을 계산합니다. 두 번째는 Sibling Pipeline 집계입니다.

이것은 형제 버킷들 전체를 대상으로 연산합니다. 예를 들어 모든 월의 평균 매출을 구하는 avg_bucket이 여기에 해당합니다.

코드를 자세히 살펴보겠습니다. buckets_path라는 파라미터가 보이시나요?

이것이 Pipeline 집계의 핵심입니다. 어떤 집계의 결과를 입력으로 사용할지 경로를 지정하는 것입니다.

실무에서는 다양한 Pipeline 집계를 조합하여 사용합니다. 예를 들어 전자상거래 플랫폼에서 일별 주문량의 7일 이동평균을 구하면서 동시에 전주 대비 성장률을 계산할 수 있습니다.

이 모든 것이 단 한 번의 쿼리로 가능합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언대로 Pipeline 집계를 적용한 결과, 대시보드 API의 응답 속도가 절반으로 줄었습니다. 코드도 훨씬 간결해졌습니다.

실전 팁

💡 - buckets_path에서 상위 경로를 참조할 때는 부모>자식 형태로 경로를 지정합니다

• Pipeline 집계는 size: 0으로 설정하여 문서 결과 없이 집계만 수행하는 것이 효율적입니다

---

2. bucket script 계산

김개발 씨는 새로운 과제를 받았습니다. 카테고리별로 평균 주문 금액 대비 배송비 비율을 계산해달라는 것이었습니다.

두 개의 집계 결과를 나누는 연산이 필요했는데, 이걸 Elasticsearch에서 어떻게 처리할 수 있을까요?

bucket_script는 다른 집계 결과들을 변수로 받아 스크립트 연산을 수행하는 Pipeline 집계입니다. 마치 엑셀에서 여러 셀의 값을 참조하여 수식을 만드는 것과 같습니다.

사칙연산은 물론 조건문까지 사용할 수 있어 복잡한 파생 지표를 계산할 수 있습니다.

다음 코드를 살펴봅시다.

GET /orders/_search
{
  "size": 0,
  "aggs": {
    "by_category": {
      "terms": { "field": "category.keyword" },
      "aggs": {
        "avg_order": { "avg": { "field": "order_amount" } },
        "avg_shipping": { "avg": { "field": "shipping_cost" } },
        "shipping_ratio": {
          "bucket_script": {
            "buckets_path": {
              "order": "avg_order",
              "shipping": "avg_shipping"
            },
            "script": "params.shipping / params.order * 100"
          }
        }
      }
    }
  }
}

어느 날 오후, 기획팀에서 긴급 요청이 들어왔습니다. 카테고리별 배송비 부담률을 분석해야 하는데, 현재 시스템에서는 이 데이터를 바로 확인할 수 없다는 것이었습니다.

김개발 씨는 처음에 두 번의 쿼리를 생각했습니다. 먼저 카테고리별 평균 주문 금액을 조회하고, 다음으로 평균 배송비를 조회한 뒤, 애플리케이션에서 나눗셈을 수행하는 방식이었습니다.

하지만 박시니어 씨가 더 좋은 방법을 알려주었습니다. "bucket_script를 사용하면 한 번의 쿼리로 해결할 수 있어요." bucket_script란 무엇일까요?

이것은 마치 계산기와 같습니다. 여러분이 계산기에 숫자 두 개를 입력하고 나누기 버튼을 누르면 결과가 나오죠?

bucket_script도 마찬가지입니다. 여러 집계 결과를 입력으로 받고, 원하는 연산을 수행하여 새로운 값을 만들어냅니다.

코드를 자세히 살펴보겠습니다. buckets_path 부분에서 두 개의 변수를 정의했습니다.

order는 avg_order 집계 결과를 참조하고, shipping은 avg_shipping 집계 결과를 참조합니다. 그리고 script 부분에서 실제 계산이 이루어집니다.

params.shipping을 params.order로 나누고 100을 곱해서 백분율을 구합니다. 이 모든 과정이 Elasticsearch 내부에서 처리됩니다.

bucket_script의 강력함은 여기서 끝나지 않습니다. Painless 스크립트를 사용하기 때문에 조건문도 작성할 수 있습니다.

예를 들어 주문 금액이 0인 경우를 처리하는 방어 코드를 넣을 수 있습니다. 실무에서 bucket_script는 정말 다양하게 활용됩니다.

전환율 계산, 재구매율 분석, 마진율 산출 등 두 개 이상의 지표를 조합해야 하는 모든 상황에서 유용합니다. 주의할 점도 있습니다.

스크립트 연산은 CPU 자원을 사용하므로, 너무 복잡한 로직은 성능에 영향을 줄 수 있습니다. 또한 0으로 나누는 상황을 반드시 고려해야 합니다.

gap_policy 옵션을 통해 데이터가 없는 버킷을 어떻게 처리할지 지정할 수 있습니다. 김개발 씨는 bucket_script를 적용하여 단 한 번의 API 호출로 모든 분석 데이터를 제공할 수 있게 되었습니다.

기획팀에서도 만족스러운 반응이었습니다.

실전 팁

💡 - 0으로 나누는 오류를 방지하려면 스크립트에서 조건문을 사용하세요

• gap_policy를 skip으로 설정하면 값이 없는 버킷은 건너뜁니다

---

3. moving avg 이동평균

대시보드를 보던 팀장님이 한 가지 요청을 했습니다. "일별 매출 그래프가 너무 들쭉날쭉해서 추세를 파악하기 어려워요.

7일 이동평균 선을 추가해줄 수 있나요?" 김개발 씨는 이동평균이라는 단어는 알지만, Elasticsearch에서 어떻게 구현할지 막막했습니다.

moving_avg는 시계열 데이터에서 이동평균을 계산하는 Pipeline 집계입니다. 마치 주식 차트에서 보는 이동평균선처럼, 데이터의 노이즈를 줄이고 추세를 파악하기 쉽게 해줍니다.

단순 이동평균부터 지수 이동평균까지 다양한 모델을 지원합니다.

다음 코드를 살펴봅시다.

GET /daily_sales/_search
{
  "size": 0,
  "aggs": {
    "sales_over_time": {
      "date_histogram": {
        "field": "date",
        "calendar_interval": "day"
      },
      "aggs": {
        "daily_revenue": { "sum": { "field": "revenue" } },
        "smoothed_revenue": {
          "moving_fn": {
            "buckets_path": "daily_revenue",
            "window": 7,
            "script": "MovingFunctions.unweightedAvg(values)"
          }
        }
      }
    }
  }
}

주식 투자를 해보신 분이라면 이동평균선이라는 개념이 익숙하실 것입니다. 매일 오르락내리락하는 주가만 보면 추세를 파악하기 어렵지만, 5일 이동평균이나 20일 이동평균을 함께 보면 전체적인 흐름이 눈에 들어옵니다.

Elasticsearch에서도 똑같은 분석이 가능합니다. 바로 moving_fn 집계를 사용하면 됩니다.

참고로 이전 버전에서는 moving_avg라는 이름이었지만, 7.x 버전부터 moving_fn으로 변경되어 더 유연한 기능을 제공합니다. 이동평균의 원리는 간단합니다.

오늘을 기준으로 최근 N일간의 평균을 구하는 것입니다. 예를 들어 7일 이동평균이라면, 오늘을 포함한 최근 7일의 평균값이 됩니다.

내일이 되면 가장 오래된 데이터는 빠지고 새로운 오늘 데이터가 추가됩니다. 코드를 살펴보면 window: 7이라는 설정이 보입니다.

이것이 바로 최근 몇 개의 버킷을 평균 계산에 포함할지를 결정합니다. 7을 설정하면 7일 이동평균이 됩니다.

MovingFunctions.unweightedAvg는 단순 이동평균을 의미합니다. 모든 날의 가중치가 동일합니다.

하지만 때로는 최근 데이터에 더 큰 가중치를 주고 싶을 수 있습니다. 그럴 때는 linearWeightedAvg나 ewma(지수 이동평균)를 사용할 수 있습니다.

실무에서 이동평균은 정말 다양한 곳에 활용됩니다. 서버 모니터링에서 CPU 사용률의 추세를 파악하거나, 마케팅에서 일별 방문자 수의 트렌드를 분석하거나, 물류에서 주문량 예측에 활용합니다.

주의할 점은 윈도우 크기를 너무 크게 설정하면 최신 트렌드가 늦게 반영된다는 것입니다. 반대로 너무 작게 설정하면 노이즈 제거 효과가 줄어듭니다.

데이터의 특성에 맞게 적절한 값을 선택해야 합니다. 김개발 씨는 7일 이동평균선을 추가한 차트를 팀장님께 보여드렸습니다.

들쭉날쭉하던 그래프가 부드러운 곡선으로 변하자, 팀장님은 만족스럽게 고개를 끄덕였습니다. "이제 추세가 한눈에 들어오네요!"

실전 팁

💡 - 비즈니스 주기에 맞게 윈도우 크기를 설정하세요. 주간 패턴이 있다면 7의 배수가 좋습니다

• min_doc_count를 0으로 설정하면 데이터가 없는 날도 버킷에 포함됩니다

---

4. significant terms 분석

고객 지원팀에서 흥미로운 요청이 들어왔습니다. "최근 불만 리뷰에서 유독 자주 등장하는 키워드가 무엇인지 알 수 있을까요?

단순히 자주 나오는 단어가 아니라, 불만 리뷰에서 특별히 두드러지는 단어요." 김개발 씨는 이 미묘한 차이를 어떻게 구현할지 고민에 빠졌습니다.

significant_terms는 특정 부분집합에서 통계적으로 유의미하게 자주 등장하는 용어를 찾아내는 집계입니다. 마치 범죄 현장에서 평소와 다른 특이한 증거를 찾는 탐정과 같습니다.

단순 빈도가 아닌, 전체 대비 해당 그룹에서 비정상적으로 많이 나타나는 용어를 발견합니다.

다음 코드를 살펴봅시다.

GET /reviews/_search
{
  "size": 0,
  "query": {
    "term": { "rating": 1 }
  },
  "aggs": {
    "unusual_terms": {
      "significant_terms": {
        "field": "content.keyword",
        "min_doc_count": 5,
        "size": 10
      }
    }
  }
}

여기서 핵심은 단순 빈도와 유의미한 빈도의 차이를 이해하는 것입니다. 예를 들어봅시다.

모든 리뷰에서 배송이라는 단어가 자주 등장한다고 가정합니다. 긍정 리뷰에서도 "배송이 빨라요", 부정 리뷰에서도 "배송이 늦어요"라고 나옵니다.

이런 경우 배송은 단순히 자주 쓰이는 단어일 뿐, 불만의 원인을 특정하는 데 도움이 되지 않습니다. 하지만 significant_terms는 다릅니다.

전체 리뷰에서는 파손이라는 단어가 1%만 등장하는데, 별점 1점 리뷰에서는 15%가 등장한다면? 이것은 통계적으로 유의미한 신호입니다.

significant_terms는 바로 이런 용어를 찾아냅니다. 비유하자면, 마트에서 도난이 의심되는 상품을 찾는 것과 비슷합니다.

콜라는 원래 많이 팔리니까 재고가 줄어도 이상하지 않습니다. 하지만 평소에 잘 안 팔리던 고급 위스키가 갑자기 재고에서 사라졌다면?

그것은 분명히 수상한 신호입니다. 내부적으로 significant_terms는 카이제곱 검정이나 JLH 점수 같은 통계 기법을 사용합니다.

전체 문서 집합에서의 출현 비율과 현재 버킷에서의 출현 비율을 비교하여 점수를 매깁니다. 실무에서 이 기능은 정말 강력합니다.

이커머스에서는 반품된 주문에서 특이하게 많이 등장하는 상품이나 키워드를 찾을 수 있습니다. 보안 분야에서는 해킹된 계정에서 비정상적으로 자주 사용된 IP나 User-Agent를 탐지할 수 있습니다.

주의할 점은 min_doc_count 설정입니다. 너무 낮게 설정하면 우연히 한두 번 등장한 단어가 높은 점수를 받을 수 있습니다.

적절한 최소 빈도를 설정하여 노이즈를 제거해야 합니다. 또한 텍스트 필드에 적용할 때는 keyword 타입을 사용해야 합니다.

형태소 분석된 토큰에 적용하면 의미 있는 결과를 얻기 어렵습니다. 김개발 씨는 significant_terms를 활용하여 별점 1점 리뷰에서 유독 두드러지는 키워드 목록을 추출했습니다.

포장 손상, 사이즈 오류, 색상 다름 같은 구체적인 불만 원인이 드러났습니다. 고객 지원팀은 이 분석 결과를 바탕으로 품질 개선 우선순위를 정할 수 있게 되었습니다.

실전 팁

💡 - background_filter를 사용하면 비교 기준이 되는 전체 집합을 커스터마이즈할 수 있습니다

• shard_size를 늘리면 더 정확한 결과를 얻을 수 있지만 성능 비용이 증가합니다

---

5. composite 집계 페이징

김개발 씨에게 새로운 도전이 찾아왔습니다. 모든 사용자별, 상품별 구매 횟수를 집계해야 하는데, 사용자가 100만 명이 넘었습니다.

terms 집계의 size를 100만으로 설정하자 메모리 오류가 발생했습니다. 이 많은 데이터를 어떻게 처리할 수 있을까요?

composite 집계는 대용량 버킷을 페이지 단위로 나누어 조회할 수 있는 집계입니다. 마치 도서관에서 책을 한 번에 다 가져오는 대신, 카트에 담을 수 있는 만큼씩 여러 번 나누어 가져오는 것과 같습니다.

메모리 효율적으로 수백만 개의 버킷을 처리할 수 있습니다.

다음 코드를 살펴봅시다.

GET /purchases/_search
{
  "size": 0,
  "aggs": {
    "user_products": {
      "composite": {
        "size": 1000,
        "sources": [
          { "user": { "terms": { "field": "user_id" } } },
          { "product": { "terms": { "field": "product_id" } } }
        ],
        "after": { "user": "user_500", "product": "prod_123" }
      },
      "aggs": {
        "purchase_count": { "value_count": { "field": "order_id" } }
      }
    }
  }
}

일반적인 terms 집계는 모든 버킷을 한 번에 메모리에 올려야 합니다. 버킷이 1000개라면 문제없지만, 100만 개라면 이야기가 달라집니다.

서버 메모리가 부족해지고, 최악의 경우 노드가 죽을 수도 있습니다. composite 집계는 이 문제를 해결하기 위해 등장했습니다.

비유하자면, 이삿짐을 옮기는 상황을 생각해보세요. 짐이 너무 많아서 트럭 한 대에 다 실을 수 없습니다.

그렇다고 엄청나게 큰 트럭을 빌리는 것은 비용이 너무 많이 듭니다. 가장 현명한 방법은 적당한 크기의 트럭으로 여러 번 왕복하는 것입니다.

composite 집계도 마찬가지입니다. 한 번에 1000개씩, 또는 10000개씩 버킷을 가져옵니다.

다음 페이지를 조회할 때는 after 파라미터에 마지막으로 받은 버킷의 키를 넣어줍니다. 마치 책갈피처럼, 어디까지 읽었는지 기억하는 것입니다.

코드를 살펴보면 sources 부분이 눈에 띕니다. 여기서 여러 필드를 조합한 복합 키를 정의합니다.

user_id와 product_id를 함께 사용하면, 각 사용자별 각 상품에 대한 버킷이 생성됩니다. after 파라미터가 핵심입니다.

첫 번째 요청에서는 이 파라미터를 생략합니다. 응답에서 after_key를 받으면, 다음 요청에서 이 값을 after에 넣습니다.

더 이상 데이터가 없으면 after_key가 반환되지 않습니다. 실무에서 composite 집계는 데이터 내보내기나 배치 처리에 많이 활용됩니다.

모든 고객의 월별 구매 현황을 CSV로 추출하거나, 모든 상품의 재고 현황을 분석할 때 유용합니다. 주의할 점은 composite 집계는 정렬이 고정되어 있다는 것입니다.

버킷은 항상 복합 키의 순서대로 정렬됩니다. 만약 특정 기준으로 정렬된 상위 N개만 필요하다면, terms 집계가 더 적합할 수 있습니다.

김개발 씨는 composite 집계를 사용하여 100만 사용자의 구매 데이터를 무사히 처리했습니다. while 루프를 돌면서 after_key가 없을 때까지 반복 호출하는 로직을 구현했고, 메모리 오류 없이 안정적으로 동작했습니다.

실전 팁

💡 - size는 너무 작으면 호출 횟수가 늘어나고, 너무 크면 응답 시간이 길어집니다. 1000~10000 사이가 적당합니다

• date_histogram도 sources에 포함할 수 있어 시계열 데이터의 페이징 처리가 가능합니다

---

6. 집계 성능 최적화

시스템 모니터링 알림이 울렸습니다. 대시보드 API의 응답 시간이 10초를 넘어가고 있었습니다.

원인은 복잡한 집계 쿼리였습니다. 김개발 씨는 기능을 유지하면서 성능을 개선해야 하는 과제를 받았습니다.

집계 성능 최적화는 Elasticsearch의 집계 쿼리가 더 빠르고 효율적으로 실행되도록 튜닝하는 작업입니다. 마치 자동차의 연비를 개선하기 위해 엔진을 튜닝하고 불필요한 짐을 덜어내는 것과 같습니다.

인덱스 설계부터 쿼리 구조까지 다양한 레벨에서 최적화가 가능합니다.

다음 코드를 살펴봅시다.

GET /logs/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "range": { "timestamp": { "gte": "now-7d" } } }
      ]
    }
  },
  "aggs": {
    "by_status": {
      "terms": {
        "field": "status",
        "size": 10,
        "execution_hint": "map"
      }
    }
  }
}

Elasticsearch 집계가 느려지는 원인은 다양합니다. 데이터가 너무 많거나, 버킷이 너무 많거나, 중첩된 집계가 깊거나, 스크립트 연산이 무겁거나.

각 원인에 맞는 해결책이 필요합니다. 첫 번째 원칙은 필터링을 먼저 하는 것입니다.

집계는 검색 결과에 대해 수행됩니다. 1억 건의 문서 전체를 집계하는 것과, 최근 7일 데이터 100만 건을 집계하는 것은 성능 차이가 엄청납니다.

반드시 필요한 범위만 조회하도록 query 절에 필터를 추가하세요. 두 번째는 bool의 filter 컨텍스트를 사용하는 것입니다.

must 대신 filter를 사용하면 스코어 계산이 생략되어 더 빠릅니다. 집계에서는 대부분 스코어가 필요 없으니, 가능하면 filter를 사용하세요.

세 번째는 doc_values를 활용하는 것입니다. 집계는 기본적으로 doc_values를 사용합니다.

text 필드는 doc_values가 없어서 집계에 비효율적입니다. keyword나 숫자 타입을 사용하세요.

네 번째는 execution_hint 설정입니다. terms 집계에서 map 힌트를 주면 전역 오디널 대신 직접 맵 방식을 사용합니다.

카디널리티가 낮은 필드에서는 map이 더 빠를 수 있습니다. 다섯 번째는 shard_size 조절입니다.

terms 집계의 shard_size는 각 샤드에서 가져올 버킷 수를 결정합니다. 기본값은 size의 1.5배 + 10인데, 정확도가 중요하면 늘리고 속도가 중요하면 줄일 수 있습니다.

여섯 번째는 중첩 집계 줄이기입니다. 집계 안에 집계를 깊게 중첩하면 조합 폭발이 일어납니다.

꼭 필요한 경우가 아니라면 집계 깊이를 2~3단계로 제한하세요. 일곱 번째는 캐싱 활용입니다.

Elasticsearch는 자주 사용되는 집계 결과를 캐싱합니다. 같은 쿼리를 반복 실행하면 두 번째부터는 캐시에서 결과를 가져옵니다.

단, now 같은 동적 값이 있으면 캐싱이 안 됩니다. 가능하면 고정된 시간 범위를 사용하세요.

인덱스 설계 단계에서도 성능을 고려해야 합니다. 시계열 데이터라면 날짜별로 인덱스를 분리하는 것이 좋습니다.

집계 대상을 특정 인덱스로 한정할 수 있어 효율적입니다. 김개발 씨는 이러한 최적화 기법들을 하나씩 적용했습니다.

필터를 추가하고, text 필드를 keyword로 변경하고, 불필요한 중첩을 제거했습니다. 결과적으로 응답 시간이 10초에서 800밀리초로 줄었습니다.

팀원들이 모두 놀라워했습니다.

실전 팁

💡 - Profile API를 사용하면 집계의 어느 부분이 느린지 상세하게 분석할 수 있습니다

• 실시간 대시보드라면 집계 결과를 별도 인덱스에 미리 계산해두는 방식도 고려하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!