Google Cloud Observability 비용 최적화 및 모니터링

이 페이지에서는 Google Cloud Observability 비용을 최적화하고 모니터링하는 방법을 설명합니다. 가격 책정 정보는 Google Cloud Observability 가격 책정을 참고하세요.

다음 문서도 참고해 보세요.

최적화

이 섹션에서는 Cloud Logging, Cloud Trace, Google Cloud Managed Service for Prometheus와 관련된 비용을 줄이거나 최적화하는 방법을 안내합니다.

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 호출을 통해 청구됩니다.

Trace 사용량 줄이기

Trace 스팬의 수집량을 관리하려면 trace 샘플링 레이트를 관리하여 성능 분석에 필요한 trace 수와 비용 허용 범위 간의 균형을 맞추면 됩니다.

트래픽 수준이 높은 시스템의 경우 대부분의 고객이 트랜잭션 1,000개 중 1개 또는 트랜잭션 10,000개 중 1개를 샘플링하면서도 성능 분석에 충분한 정보를 얻고 있습니다.

샘플링 레이트는 Cloud Trace 클라이언트 라이브러리로 구성됩니다.

알림 비용 절감

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

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

알림에는 조건별 비용이 청구됩니다. 따라서 가능한 경우 각 리소스별로 알림 정책을 만드는 대신 하나의 알림 정책을 사용하여 여러 리소스를 모니터링하세요.

예를 들어 VM이 100개 있다고 가정해 보겠습니다. 각 VM은 측정항목 유형 my_metric의 시계열을 생성합니다. 시계열을 모니터링하는 두 가지 방법은 다음과 같습니다.

  • 조건 하나가 포함된 알림 정책을 만듭니다. 이 조건은 my_metric을 모니터링하고 데이터를 VM 수준으로 집계합니다. 집계 후에는 VM마다 하나의 시계열이 있습니다. 따라서 조건은 100개의 시계열을 모니터링합니다.

  • 알림 정책 100개를 만들고 각 정책에는 조건이 1개씩 포함되어 있습니다. 각 조건은 VM 중 하나의 my_metric 시계열을 모니터링하고 데이터를 VM 수준으로 집계합니다. 따라서 각 조건은 하나의 시계열을 모니터링합니다.

조건 100개를 만드는 두 번째 옵션은 조건 1개만 만드는 첫 번째 옵션보다 비용이 더 많이 듭니다. 두 옵션 모두 100개의 시계열을 모니터링합니다.

알림이 필요한 레벨만 집계

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

예를 들어 VM이 100개 있다고 가정해 보겠습니다. 각 VM은 측정항목 유형 my_metric의 시계열을 생성합니다. 각 VM은 5가지 서비스 중 하나에 속합니다. my_metric을 모니터링하는 조건이 하나인 알림 정책을 만들기로 결정합니다. 다음은 두 가지 집계 옵션입니다.

  • 서비스에 데이터를 집계합니다. 집계 후 각 서비스에 하나의 시계열이 있습니다. 따라서 조건은 5개의 시계열을 모니터링합니다.

  • VM 수준으로 데이터를 집계합니다. 집계 후 각 VM에 하나의 시계열이 있습니다. 따라서 조건은 100개의 시계열을 모니터링합니다.

100개의 시계열을 모니터링하는 두 번째 옵션은 5개의 시계열만 모니터링하는 첫 번째 옵션보다 비용이 더 많이 듭니다.

알림 정책을 구성할 때 사용 사례에 가장 적합한 집계 수준을 선택하세요. 예를 들어 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초 간격의 쿼리보다 실행되는 빈도가 절반으로 감소합니다.

모니터링

이 섹션에서는 알림 정책을 만들어 비용을 모니터링하는 방법을 설명합니다. 알림 정책은 측정항목 데이터를 모니터링하고 데이터가 기준을 초과하면 알림을 보낼 수 있습니다.

수집된 월별 로그 바이트 모니터링

로그 버킷에 기록되는 로그 바이트 수가 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 콘솔의 예산 및 알림 페이지를 사용하여 알림을 만듭니다.

  1. Google Cloud 콘솔에서 결제 페이지로 이동합니다.

    결제로 이동

    검색창을 사용하여 이 페이지를 찾을 수도 있습니다.

    Cloud Billing 계정이 두 개 이상 있으면 다음 중 하나를 수행합니다.

    • 현재 프로젝트의 Cloud Billing을 관리하려면 연결된 결제 계정으로 이동을 선택합니다.
    • 다른 Cloud Billing 계정을 찾으려면 결제 계정 관리를 선택하고 예산을 설정할 계정을 선택합니다.
  2. 결제 탐색 메뉴에서 예산 및 알림을 선택합니다.
  3. 예산 만들기를 클릭합니다.
  4. 예산 대화상자를 완료합니다. 이 대화상자에서 Google Cloud 프로젝트 및 제품을 선택한 다음 이 조합에 대한 예산을 만듭니다. 기본적으로 예산의 50%, 90%, 100%에 도달하면 알림이 전송됩니다. 자세한 문서는 예산 및 예산 알림 설정을 참고하세요.