이 페이지에서는 Google Cloud Observability 비용을 최적화하고 모니터링하는 방법을 설명합니다. 가격 책정 정보는 Google Cloud Observability 가격 책정을 참조하세요.
다음 문서도 참고해 보세요.
- 청구 요금 추정
- 가격 책정 예시를 참고하세요.
- 비용 탐색기로 비용 최적화 비용 탐색기는 비용 데이터와 사용률 측정항목의 현재 및 이전 시각화를 제공합니다. 따라서 이 데이터를 통해 최적화 기회를 파악할 수 있습니다.
최적화
이 섹션에서는 Cloud Logging, Cloud Trace, Google Cloud Managed Service for Prometheus와 관련된 비용을 줄이거나 최적화하는 방법을 안내합니다.
로그 스토리지 줄이기
Cloud Logging 스토리지 비용을 줄이려면 로그 싱크에서 제외 필터를 구성하여 특정 로그가 라우팅되지 않도록 합니다. 제외 필터는 필터와 일치하는 모든 로그 항목을 삭제할 수도 있고 로그의 일부만 삭제할 수도 있습니다. 로그 항목이 싱크의 제외 필터와 일치하면 싱크는 로그 항목을 대상으로 라우팅하지 않습니다. 제외된 로그 항목은 스토리지 할당량으로 집계되지 않습니다. 제외 필터 설정에 대한 안내는 로그 제외를 참고하세요.
Cloud Logging 스토리지 비용을 줄이는 또 다른 방법은 Cloud Logging에서 지원되는 대상으로 로그를 라우팅하는 것입니다. Cloud Logging은 로그를 지원되는 대상으로 라우팅하는 데 비용을 청구하지 않습니다. 하지만 대상에서 로그를 수신할 때 요금이 청구될 수 있습니다.
Cloud Logging에서 로그를 라우팅하는 방법에 대한 자세한 내용은 지원되는 대상으로 로그 라우팅을 참고하세요.
Managed Service for Prometheus 비용 최적화
Managed Service for Prometheus의 가격은 제어 가능하도록 설계되었습니다. 샘플별로 요금이 부과되므로 다음 수단을 사용하여 비용을 관리할 수 있습니다.
샘플링 기간: 측정항목 스크랩 기간을 15초에서 60초로 변경하면 카디널리티를 그대로 유지하면서 75% 의 비용 절감 효과를 얻을 수 있습니다. 작업별, 대상별, 전역별로 샘플링 기간을 구성할 수 있습니다.
필터링: 필터링을 사용하여 서비스의 전역 데이터 저장소로 전송되는 샘플 수를 줄일 수 있습니다. 자세한 내용은 내보낸 측정항목 필터링을 참고하세요. Prometheus 스크레이핑 구성에서 측정항목 라벨 재지정 구성을 사용하여 라벨 일치자를 기준으로 수집 시 측정항목을 삭제합니다.
카디널리티가 높고 값이 낮은 데이터를 로컬에 유지합니다. 동일한 스크레잎ㅇ 구성을 사용하여 관리형 서비스와 함께 표준 Prometheus를 실행하고, 서비스의 전역 데이터 저장소로 보낼 가치가 없는 데이터를 로컬에 유지할 수 있습니다.
Managed Service for Prometheus의 가격은 예측 가능하도록 설계되었습니다.
희소 히스토그램 사용에 따른 불이익은 없습니다. 샘플은 0이 아닌 첫 번째 값에서만 집계되며 이후에는 n 버킷 값이 n-1 버킷 값보다 큰 경우에 집계됩니다. 예를 들어 값이
10 10 13 14 14 14인 히스토그램은 첫 번째, 세 번째, 네 번째 버킷에서 샘플 3개가 집계됩니다.히스토그램 수와 용도에 따라 가격 책정에서 변경되지 않은 버킷을 제외하면 일반적으로 히스토그램 버킷이 표시하는 절대 수보다 청구를 위해 집계되는 샘플이 20~40% 더 적을 수 있습니다.
샘플 단위로 요금이 부과되는 경우 HPA 또는 GKE Autopilot에서 만든 컨테이너와 같이 빠르게 확장되거나 확장되지 않은 선점형 컨테이너 또는 임시 컨테이너 사용에 따른 불이익이 없습니다.
Managed Service for Prometheus가 측정항목 단위로 요금이 부과되는 경우 새 컨테이너가 가동될 때마다 한 달 전체의 카디널리티에 대한 요금이 한 번에 부과됩니다. 샘플당 가격 책정을 사용하면 컨테이너가 실행 중일 때만 비용을 지불합니다.
알림 쿼리를 포함한 쿼리
Prometheus 기록 규칙 실행 시 실행된 쿼리를 포함하여 사용자가 실행한 모든 쿼리의 요금은 Cloud Monitoring API 호출을 통해 청구됩니다. 현재 요율은 Managed Service for Prometheus 가격 책정 또는 Monitoring 가격 책정의 요약 표를 참조하세요.
Trace 사용량 줄이기
Trace 스팬의 수집량을 관리하려면 trace 샘플링 레이트를 관리하여 성능 분석에 필요한 trace 수와 비용 허용 범위 간의 균형을 맞추면 됩니다.
트래픽 수준이 높은 시스템의 경우 대부분의 고객이 트랜잭션 1,000개 중 1개 또는 트랜잭션 10,000개 중 1개를 샘플링하면서도 성능 분석에 충분한 정보를 얻고 있습니다.
샘플링 레이트는 Cloud Trace 클라이언트 라이브러리로 구성됩니다.
알림 비용 절감
Cloud Monitoring은 2026년 5월 1일 이후부터 알림 정책 사용에 대한 요금 부과를 시작합니다. 가격 정책 모델에 대한 자세한 내용은 알림 가격 책정을 참조하세요.이 문서에서는 알림 비용을 줄이기 위해 사용할 수 있는 전략에 대해 설정합니다.
더 많은 리소스로 작동하도록 알림 정책 통합
조건당 $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 또는 MQL 쿼리가 사용되는 경우 최상위 스트림 연산자를 사용해서 최고 값으로 반환되는 시계열 수를 선택할 수 있습니다.
예를 들어 PromQL 쿼리의 topk(metric, 5) 절은 각 실행 기간에 반환되는 시계열 수를 5개로 제한합니다.
시계열 수를 상한 값으로 제한하면 다음과 같이 데이터 누락 및 잘못된 알림이 발생할 수 있습니다.
- N개를 초과하는 시계열이 기준점을 위반하면 상위 N개 시계열을 벗어난 데이터가 누락됩니다.
- 기준점을 위반하는 시계열이 최상위 N개 시계열을 넘어 발생할 경우 여전히 기준점을 위반하여 제외된 시계열에도 불구하고 이슈가 자동으로 종료될 수 있습니다.
- 조건 쿼리에는 의도한 대로 작동 중인 기준 시계열과 같은 중요한 컨텍스트가 표시되지 않을 수 있습니다.
이러한 위험을 완화하려면 N에 대해 큰 값을 선택하고 개별 Kubernetes 컨테이너의 알림과 같이 여러 시계열을 평가하는 알림 정책에서만 최상위 스트림 연산자를 사용하세요.
실행 기간 길이 늘리기(PromQL만 해당)
조건이 PromQL 쿼리를 사용하는 경우 조건에서 evaluationInterval 필드를 설정하여 실행 기간의 길이를 수정할 수 있습니다.
평가 기간을 길게 설정하면 월별 반환되는 시계열 수가 감소됩니다. 예를 들어 15초 간격의 조건 쿼리는 30초 간격의 쿼리보다 2배 더 자주 실행되며, 간격이 1분 간격의 쿼리는 30초 간격의 쿼리보다 실행되는 빈도가 절반으로 감소합니다.
모니터링
이 섹션에서는 알림 정책을 만들어 비용을 모니터링하는 방법을 설명합니다. 알림 정책은 측정항목 데이터를 모니터링하고 데이터가 기준을 초과하면 알림을 보낼 수 있습니다.
수집된 월별 로그 바이트 모니터링
로그 버킷에 기록되는 로그 바이트 수가 Cloud Logging의 사용자 정의 한도를 초과할 때 트리거되는 알림 정책을 만들려면 다음 설정을 사용하세요.
| 새 조건 필드 |
값 |
|---|---|
| 리소스 및 측정항목 | 리소스 메뉴에서 전역을 선택합니다. 측정항목 카테고리 메뉴에서 로그 기반 측정항목을 선택합니다. 측정항목 메뉴에서 수집된 월별 로그 바이트를 선택합니다. |
| 필터 | 없음 |
| 시계열 시계열 집계 |
sum |
| 순환 기간 | 60 m |
| 순환 윈도우 함수 | max |
| 알림 트리거 구성 필드 |
값 |
|---|---|
| 조건 유형 | Threshold |
| 알림 트리거 | Any time series violates |
| 기준 위치 | Above threshold |
| 기준 값 | 허용 가능한 값을 결정합니다. |
| 재테스트 범위 | 허용 가능한 최솟값은 30분입니다. |
수집된 총 측정항목 모니터링
수집된 월별 측정항목을 기준으로 알림을 만들 수는 없습니다. Cloud Monitoring 비용을 기준으로 알림을 만들 수 있습니다. 자세한 내용은 결제 알림 구성을 참고하세요.
수집된 월별 추적 스팬 모니터링
월별로 수집되는 Cloud Trace 스팬 수가 사용자 정의 한도를 초과하면 트리거되는 알림 정책을 만들려면 다음 설정을 사용하세요.
| 새 조건 필드 |
값 |
|---|---|
| 리소스 및 측정항목 | 리소스 메뉴에서 전역을 선택합니다. 측정항목 카테고리 메뉴에서 청구를 선택합니다. 측정항목 메뉴에서 수집된 월간 trace 스팬을 선택합니다. |
| 필터 | |
| 시계열 시계열 집계 |
sum |
| 순환 기간 | 60 m |
| 순환 윈도우 함수 | max |
| 알림 트리거 구성 필드 |
값 |
|---|---|
| 조건 유형 | Threshold |
| 알림 트리거 | Any time series violates |
| 기준 위치 | Above threshold |
Threshold value |
허용 가능한 값을 결정합니다. |
| 재테스트 범위 | 허용 가능한 최솟값은 30분입니다. |
결제 알림 구성
청구 가능 또는 예측 요금이 예산을 초과하는 경우 알림을 받으려면 Google Cloud 콘솔의 예산 및 알림 페이지를 사용하여 알림을 만듭니다.
-
Google Cloud 콘솔에서 결제 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾을 수도 있습니다.
Cloud Billing 계정이 두 개 이상 있으면 다음 중 하나를 수행합니다.
- 현재 프로젝트의 Cloud Billing을 관리하려면 연결된 결제 계정으로 이동을 선택합니다.
- 다른 Cloud Billing 계정을 찾으려면 결제 계정 관리를 선택하고 예산을 설정할 계정을 선택합니다.
- 결제 탐색 메뉴에서 예산 및 알림을 선택합니다.
- 예산 만들기를 클릭합니다.
- 예산 대화상자를 완료합니다. 이 대화상자에서 Google Cloud 프로젝트 및 제품을 선택한 다음 이 조합에 대한 예산을 만듭니다. 기본적으로 예산의 50%, 90%, 100%에 도달하면 알림이 전송됩니다. 자세한 문서는 예산 및 예산 알림 설정을 참고하세요.