알림 비용 관리

Cloud Monitoring은 2026년 5월 1일 이후부터 알림 정책 사용에 대한 요금 부과를 시작합니다. 가격 책정 모델에 대한 자세한 내용은 Cloud Monitoring 가격 책정 요약을 참조하세요.

이 문서에서는 알림 비용을 줄이기 위해 사용할 수 있는 전략에 대해 설정합니다.

더 많은 리소스로 작동하도록 알림 정책 통합

조건당 $0.10의 비용이 발생하므로 하나의 알림 정책을 사용하여 각 리소스를 모니터링하는 것보다 하나의 알림 정책을 사용하여 여러 리소스를 모니터링하는 것이 더 비용 효율적입니다. 다음 예를 고려하세요.

예시 1

데이터

  • VM 100개
  • 각 VM은 하나의 측정항목 metric_name을 내보냄
  • metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
알림 정책
  • 알림 조건 1개
  • VM 수준에서 조건 집계 수행
  • 실행 기간 30초
결과 비용
  • 조건 비용: 조건 1개 * $0.10/월 = 월별 $0.10
  • 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
  • 월별 총비용: $3.12/월

예시 2

데이터

  • VM 100개
  • 각 VM은 하나의 측정항목 metric_name을 내보냄
  • metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
알림 정책
  • 조건 100개
  • 각 조건이 필터링되고 하나의 VM으로 집계됨
  • 실행 기간 30초
결과 비용
  • 조건 비용: 조건 100개 * 월별 $0.10 = 월별 $10
  • 시계열 비용 : 조건 100개 * 기간별 조건당 반환된 시계열 1개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
  • 총비용: $13.02/월

두 예시 모두 동일한 숫자의 리소스를 모니터링합니다. 하지만 예시 2는 100개의 알림 정책을 사용하고, 예시 1은 알림 정책을 하나만 사용합니다. 따라서 예시 1은 매월 거의 $10 저렴합니다.

알림이 필요한 레벨만 집계

집계하는 세분성 수준이 높을수록 낮은 세분성으로 집계하는 것보다 높은 비용이 발생합니다. 예를 들어 클러스터 수준으로 집계하는 것보다는 Google Cloud 프로젝트 수준으로 집계하는 것이 더 저렴하고, 클러스터 및 네임스페이스 수준으로 집계하는 것보다는 클러스터 수준으로 집계하는 것이 더 저렴합니다.

다음 예를 고려하세요.

예시 1

데이터

  • VM 100개
  • 각 VM은 하나의 측정항목 metric_name을 내보냄
  • metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
알림 정책
  • 알림 조건 1개
  • VM 수준에서 조건 집계 수행
  • 실행 기간 30초
결과 비용
  • 조건 비용: 조건 1개 * $0.10/월 = 월별 $0.10
  • 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
  • 월별 총비용: $3.12/월

예시 4

데이터

  • VM 100개, 각 VM이 하나의 서비스에 속함
  • 총 5개 서비스
  • 각 VM은 하나의 측정항목 metric_name을 내보냄
  • metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
알림 정책
  • 조건 1개
  • 서비스 수준에 대한 조건 집계
  • 실행 기간 30초
결과 비용
  • 조건 비용: 조건 1개 * $0.10/월 = 월별 $0.10
  • 시계열 비용: 기간당 반환된 시계열 5개 * 월별 기간 86,400개 = 월별 반환된 시계열 432,000개 * 시계열 100만 개당 $0.35 = 월별 $0.14
  • 총비용: $0.24/월

예시 5

데이터

  • VM 100개
  • 각 VM은 하나의 측정항목 metric_name을 내보냄
  • metric_name에 100개의 라벨이 있고, 각 라벨에는 1,000개의 값이 있음
알림 정책
  • 조건 1개
  • VM 수준에서 조건 집계 수행
  • 실행 기간 30초
결과 비용
  • 조건 비용: 조건 1개 * $0.10/월 = 월별 $0.10
  • 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 850만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
  • 월별 총비용: $3.12/월

예시 1과 예시 4 비교: 두 예시 모두 동일한 기본 데이터로 작동하며 단일 알림 정책을 사용합니다. 하지만 예시 4의 알림 정책은 서비스로 집계되기 때문에 보다 세부적으로 VM으로 집계되는 예시 1의 알림 정책보다 비용이 낮습니다.

또한 예시 1과 예시 5를 비교하면, 예시 5의 측정항목 카디널리티는 예시 1의 측정항목 카디널리티보다 10,000배 더 높습니다. 하지만 예시 1과 예시 5의 알림 정책은 모두 VM으로 집계되고, 두 예시 모두 VM 수가 동일하기 때문에 가격 측면에서는 두 예시가 동등합니다.

알림 정책을 구성할 때 사용 사례에 가장 적합한 집계 수준을 선택하세요. 예를 들어 CPU 활용도 알림이 중요하면 VM 및 CPU 수준으로 집계해야 할 수 있습니다. 엔드포인트별 지연 시간에 대한 알림이 중요하면 엔드포인트 수준으로 집계해야 할 수 있습니다.

집계되지 않은 원시 데이터는 알림 수행 안함

Monitoring은 측정기준 측정항목 시스템을 사용합니다. 여기서 모든 측정항목의 총 카디널리티는 모니터링 리소스 수에 해당 측정항목의 라벨 조합 수를 곱한 값과 같습니다. 예를 들어 측정항목을 내보내는 VM이 100개 있고 이 측정항목에는 각각 10의 값이 포함된 라벨이 10개 있을 때 총 카디널리티는 100 * 10 * 10 = 10,000입니다.

카디널리티 결과가 확장됨에 따라 원시 데이터에 대한 알림 비용이 크게 증가할 수 있습니다. 이전 예시에서는 각 실행 기간에 10,000개의 시계열이 반환되었습니다. 하지만 VM으로 집계하면 기본 데이터의 라벨 카디널리티에 관계없이 실행 기간당 시계열이 100개만 반환됩니다.

또한 원시 데이터에 대한 알림은 측정항목에 새 라벨이 수신될 때 시계열이 증가하는 위험을 발생시킵니다. 이전 예시에서 사용자가 측정항목에 새 라벨을 추가하면 총 카디널리티가 100 * 11 * 10 = 11,000개의 시계열로 증가합니다. 이 경우에는 알림 정책이 변경되지 않더라도 각 실행 기간마다 반환되는 시계열 수가 1,000개씩 증가합니다. 대신 VM으로 집계하면 기본 카디널리티가 증가하더라도 여전히 100개의 시계열만 반환됩니다.

불필요한 응답 필터링

알림 요구에 따라 필요한 데이터만 평가하도록 조건을 구성합니다. 문제를 해결하기 위한 조치를 취하지 않는다면 알림 정책에서 해당 부분을 제외하세요. 예를 들어 인턴의 개발 VM에 대해서는 알림을 수행할 필요가 없을 것입니다.

불필요한 사고와 비용을 줄이기 위해 중요하지 않은 시계열을 필터링하는 것도 하나의 방법입니다. 이렇게 하려면 Google Cloud 메타데이터 라벨을 사용하여 애셋을 각 카테고리로 태그하고 불필요한 메타데이터 카테고리를 필터링하면 됩니다.

최상위 스트림 연산자를 사용하여 반환되는 시계열 수 줄이기

조건에 PromQL 쿼리가 사용되는 경우 최상위 스트림 연산자를 사용해서 최고 값으로 반환되는 시계열 수를 선택할 수 있습니다.

예를 들어 PromQL 쿼리의 topk(metric, 5) 절은 각 실행 기간에 반환되는 시계열 수를 5개로 제한합니다.

시계열 수를 상한 값으로 제한하면 다음과 같이 데이터 누락 및 잘못된 사고가 발생할 수 있습니다.

  • N개를 초과하는 시계열이 기준점을 위반하면 상위 N개 시계열을 벗어난 데이터가 누락됩니다.
  • 기준점을 위반하는 시계열이 최상위 N개 시계열을 넘어 발생할 경우 여전히 기준점을 위반하여 제외된 시계열에도 불구하고 이슈가 자동으로 종료될 수 있습니다.
  • 조건 쿼리에는 의도한 대로 작동 중인 기준 시계열과 같은 중요한 컨텍스트가 표시되지 않을 수 있습니다.

이러한 위험을 완화하려면 N에 대해 큰 값을 선택하고 개별 Kubernetes 컨테이너의 사고와 같이 여러 시계열을 평가하는 알림 정책에서만 최상위 스트림 연산자를 사용하세요.

실행 기간 길이 늘리기(PromQL만 해당)

조건이 PromQL 쿼리를 사용하는 경우 조건에서 evaluationInterval 필드를 설정하여 실행 기간의 길이를 수정할 수 있습니다.

평가 기간을 길게 설정하면 월별 반환되는 시계열 수가 감소됩니다. 예를 들어 15초 간격의 조건 쿼리는 30초 간격의 쿼리보다 2배 더 자주 실행되며, 간격이 1분 간격의 쿼리는 30초 간격의 쿼리보다 실행되는 빈도가 절반으로 감소합니다.