Google Cloud Observability 비용 최적화

Google Cloud Observability는 앱 및 인프라 서비스에 대해 심도 깊은 관측 가능성을 제공하기 위해 설계된 클라우드 기반 관리형 서비스 모음으로 구성됩니다. Google Cloud의 관리형 서비스의 이점 중 하나는 서비스가 사용자 기반으로 구성되어 사용한 대상에 대해서만 비용을 지불한다는 것입니다. 이 가격 모델은 표준 소프트웨어 라이선싱과 비교했을 때 비용상 유리할 수 있지만, 비용을 예측하기는 어려울 수 있습니다. 이 솔루션에서는 이러한 서비스의 사용 방식을 이해하고 비용을 최적화하는 방법을 설명합니다.

가격 책정

Google Cloud Observability 서비스는 관리형 서비스이기 때문에 이러한 서비스를 사용하는 데 필요한 인프라 대신 이러한 서비스로 제공되는 정보에 집중할 수 있게 해줍니다. 이러한 서비스를 사용할 때는 가상 머신, 소프트웨어 라이선스, 보안 검사, 하드웨어 유지보수, 데이터 센터 공간 등의 비용을 개별적으로 지불할 필요가 없습니다. 이 서비스에서는 사용량을 기준으로 간단하게 비용을 지불할 수 있습니다.

Cloud Logging, Cloud Monitoring, Cloud Trace에 대한 요금이 비용에 포함됩니다. Error Reporting 로깅 제품은 아직 베타 버전이라 별도의 비용이 발생하지 않으며, Cloud Profiler를 무료로 사용할 수 있습니다. Error Reporting의 경우 Logging에서 오류가 수집되면 소액의 비용이 발생할 수 있습니다.

또한 모든 가격 책정에 대한 요약 정보를 읽어볼 수 있습니다.

Logging 및 Error Reporting 비용

Logging 가격은 청구 대상인 내부 데이터화된 로그의 볼륨에 따라 결정됩니다. 이 제품 가격 책정은 간단하게 GiB를 기준으로 이루어집니다. 이것은 매달 제공되는 무료 할당량이며 Cloud 감사 로그 같은 특정 로그는 청구 대상이 아닙니다.

다음을 사용하면 추가 로그 볼륨으로 인해 비용이 발생하게 됩니다.

Cloud Load Balancing
Compute Engine의 Logging 에이전트
Amazon Web Services(AWS)의 Logging 에이전트
Cloud Logging API에서의 쓰기 작업

Monitoring 비용

Monitoring 가격은 청구 대상인 내부 데이터화된 측정항목의 볼륨과 청구 대상인 API 호출의 수에 따라 결정됩니다. 예를 들어 에이전트, 커스텀, 외부, AWS 등 Google Cloud의 것이 아닌 측정항목이 청구 대상입니다. Cloud Monitoring API의 projects.timeSeries.list 메서드는 API 호출을 기준으로 청구되는 반면, 나머지 API 사용량은 무료입니다. 매달 할당되는 무료 측정항목 볼륨이 있으며, 모든 Google Cloud 측정항목을 비롯한 다수의 측정항목은 청구 대상이 아닙니다. 어떤 측정항목이 청구 대상인지에 대한 자세한 내용은 Monitoring 가격 책정을 참조하세요.

다음을 사용하면 측정항목 볼륨 및 API 호출을 통해 비용이 발생하게 됩니다.

Monitoring 커스텀 측정항목
Compute Engine의 Monitoring 에이전트
AWS의 Monitoring 에이전트
Monitoring API의 읽기 작업

Trace 비용

Trace 가격은 수집되고 최종적으로 검색된 스팬 수에 따라 결정됩니다. App Engine 표준 환경과 같은 일부 Google Cloud 서비스는 청구 대상이 아닌 스팬을 자동으로 생성합니다. 매달 무료 Trace 할당량이 있습니다.

다음을 위한 계측을 추가하면 내부 데이터화된 스팬을 통해 비용이 발생하게 됩니다.

기본 스팸의 범위 밖에 있는 App Engine 앱의 스팬
Cloud Load Balancing
커스텀 앱

용도

사용량을 이해하면 어떤 구성요소에서 비용이 발생하는지 파악할 수 있습니다. 이를 통해 어느 부분을 최적화하면 좋을지 파악하는 데 도움이 됩니다.

Google Cloud 청구 분석

사용량을 이해하는 첫 번째 단계는 Google Cloud 청구서를 검토하고 비용을 파악하는 것입니다. 그 방법 중 하나는 Google Cloud Console의 청구 보고서를 확인하는 것입니다.

보고서 페이지는 시간, 프로젝트, 제품, SKU, 라벨별로 결과를 좁힐 수 있는 여러 가지 유용한 필터를 제공합니다. 제품 필터를 사용하여 청구 데이터 범위를 모니터링 및 로깅 비용으로 좁힐 수 있습니다.

Logging

Logging은 각 프로젝트에 대해 세부적인 로그 목록, 현재 로그 볼륨, 예상되는 월별 볼륨을 제공합니다. Google Cloud 청구서에서 Logging 요금을 검토하면서 프로젝트마다 이러한 세부정보를 검토할 수 있습니다. 그러면 어떤 로그에서 볼륨이 가장 높은지, 즉 가장 많은 비용이 발생하는지를 간단하게 확인할 수 있습니다.

로그 스토리지 페이지에서 프로젝트에 수집된 로그 볼륨을 찾을 수 있습니다. 로그 스토리지 페이지에는 지난 달과 이번 달의 로그 및 볼륨 목록과 예상되는 월말 볼륨이 표시됩니다.

이 분석을 통해 특정 프로젝트에서 로그가 얼마나 사용되었는지 그리고 시간이 지나면서 볼륨이 어떻게 변경되었는지를 파악할 수 있습니다. 이 분석을 사용하여 최적화를 고려해야 하는 로그를 식별할 수 있습니다.

Monitoring

측정항목 범위으로 정리되는 Monitoring은 세부적인 프로젝트 목록, 이전 측정항목 볼륨, 현재 측정항목 볼륨, 예상되는 측정항목 볼륨을 제공합니다. 측정항목 범위는 여러 개의 프로젝트를 포함할 수 있으므로 다음 이미지에 나온 것처럼 각 프로젝트의 볼륨이 따로 나열됩니다.

여러 프로젝트가 있는 작업공간

Monitoring 사용량 세부정보를 찾는 방법에 대해 알아보세요.

내부 데이터화된 측정항목의 시간 경과에 따른 볼륨 정보를 제공하는 Monitoring의 측정항목 탐색기에서 프로젝트별로 측정항목 용량 단위의 세부 그래프를 볼 수 있습니다.

이 분석은 Google Cloud 청구서에서 Monitoring 비용을 검토하면서 파악한 각 프로젝트의 Monitoring 측정항목 볼륨을 제공합니다. 그러면 특정 측정항목 볼륨을 검토하고, 어떤 구성요소가 볼륨과 비용에서 가장 많은 부분을 차지하는지를 이해할 수 있습니다.

Trace

Trace는 이번 달과 지난 달에 내부 데이터화된 스팬을 세부적으로 표시합니다. Google Cloud 청구서에서 Trace 요금을 검토하면서 파악한 각 프로젝트의 세부정보를 Google Cloud 콘솔에서 검토할 수 있습니다.

이 분석은 Google Cloud 청구서에서 Trace 비용을 검토하면서 파악한 작업공간 내 각 프로젝트의 수집된 스팬 수를 제공합니다. 그러면 수집된 특정 스팬 수를 검토하고, 어떤 프로젝트와 서비스가 스팬과 비용에서 가장 많은 부분을 차지하는지를 이해할 수 있습니다.

Logging 내보내기

Logging은 로그를 Cloud Storage, BigQuery, Pub/Sub로 내보내기 위한 로깅 싱크를 제공합니다.

예를 들어 장기 스토리지 및 분석을 위해 모든 Logging 로그를 BigQuery에 내보내는 경우에는 GiB당 스토리지, 스트리밍 삽입, 모든 쿼리 비용을 포함하는 BigQuery 비용이 발생합니다.

내보내기에 의해 발생하는 비용을 파악하려면 다음 단계를 고려하세요.

로깅 싱크를 찾습니다. 어떤 로깅 싱크를 사용 설정했는지 찾습니다. 예를 들어, 보안 운영이나 규제 준수 등 다른 목적으로 만들어진 여러 개의 로깅 싱크가 프로젝트에 있을 수도 있습니다.
사용량 세부정보를 검토합니다. 내보내기 대상의 사용량을 검토합니다. 예를 들어, BigQuery 내보내기의 BigQuery 테이블 크기나 Cloud Storage 내보내기의 버킷 크기를 검토합니다.

로깅 싱크 찾기

로깅 싱크는 프로젝트 수준에 있을 수도 있고(프로젝트당 하나 이상의 싱크), 내보내기 집계라고 부르는 Google Cloud 조직 수준에 있을 수도 있습니다. 싱크는 여러 프로젝트의 로그를 같은 Google Cloud 조직에 포함할 수 있습니다.

특정 프로젝트를 살펴봄으로써 로깅 싱크를 확인할 수 있습니다. Google Cloud 콘솔은 싱크 및 대상의 목록을 제공합니다. 조직의 내보내기 집계를 보려면 gcloud logging sinks list --organization ORGANIZATION_ID 명령줄을 사용하면 됩니다.

사용량 세부정보 검토

Monitoring은 앱뿐만 아니라 Google Cloud 제품 사용량에 대해서도 다양한 측정항목 집합을 제공합니다. 측정항목 탐색기에서 사용량 측정항목을 확인하여 Cloud Storage, BigQuery, Pub/Sub의 세부적인 사용량 측정항목을 얻을 수 있습니다.

Cloud Storage

Monitoring에서 측정항목 탐색기를 사용하면 Cloud Storage 버킷의 저장소 크기를 볼 수 있습니다. 측정항목 탐색기에서 다음 값을 사용하여 로깅 싱크에 사용되는 Cloud Storage 버킷의 저장소 크기를 확인합니다.

측정항목 탐색기를 사용하여 모니터링 리소스의 측정항목을 확인하려면 다음을 수행하세요.

Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.
측정항목 탐색기로 이동
측정항목 요소에서 측정항목 선택 메뉴를 펼치고 필터 표시줄에 Total bytes을 입력한 후 하위 메뉴를 사용하여 특정 리소스 유형과 측정항목을 선택합니다.
1. 활성 리소스 메뉴에서 GCS 버킷을 선택합니다.
2. 활성 측정항목 카테고리 메뉴에서 스토리지를 선택합니다.
3. 활성 측정항목 메뉴에서 총 바이트를 선택합니다.
4. 적용을 클릭합니다.
이 측정항목의 정규화된 이름은 storage.googleapis.com/storage/total_bytes입니다.
데이터 보기 방법을 구성합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 project_id를 선택합니다. 값으로 Google Cloud 프로젝트 ID를 선택합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 bucket_name을 선택합니다. 값으로 Cloud Storage 내보내기 버킷 이름을 선택합니다.
- 집계 항목에서 첫 번째 메뉴를 집계되지 않음으로 설정합니다.
차트 구성에 대한 자세한 내용은 측정항목 탐색기 사용 시 측정항목 선택을 참조하세요.

앞선 그래프는 시간 경과에 따라 내보낸 데이터의 크기를 TB 단위로 표시합니다. 이를 통해 Cloud Storage로의 Logging 내보내기를 어느 정도 사용했는지 알 수 있습니다.

BigQuery

Monitoring에서 측정항목 탐색기를 사용하면 BigQuery 데이터세트의 저장소 크기를 볼 수 있습니다. 측정항목 탐색기에서 다음 값을 사용하여 로깅 싱크에 사용되는 BigQuery 데이터 세트의 저장소 크기를 확인합니다.

측정항목 탐색기를 사용하여 모니터링 리소스의 측정항목을 확인하려면 다음을 수행하세요.

Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.
측정항목 탐색기로 이동
측정항목 요소에서 측정항목 선택 메뉴를 펼치고 필터 표시줄에 Stored bytes을 입력한 후 하위 메뉴를 사용하여 특정 리소스 유형과 측정항목을 선택합니다.
1. 활성 리소스 메뉴에서 BigQuery 데이터 세트를 선택합니다.
2. 활성 측정항목 카테고리 메뉴에서 스토리지를 선택합니다.
3. 활성 측정항목 메뉴에서 저장된 바이트를 선택합니다.
4. 적용을 클릭합니다.
이 측정항목의 정규화된 이름은 bigquery.googleapis.com/storage/stored_bytes입니다.
데이터 보기 방법을 구성합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 project_id를 선택합니다. 값으로 Google Cloud 프로젝트 ID를 선택합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 dataset_id를 선택합니다. 값으로 BigQuery 내보내기 데이터 세트 이름을 선택합니다.
- 집계 항목에서 첫 번째 메뉴를 Mean으로 설정하고 두 번째 메뉴를 dataset_id로 설정합니다.
- 표시 창에서 위젯 유형을 누적 막대 그래프로 설정합니다.
- 기간을 1일 이상으로 설정합니다.
차트 구성에 대한 자세한 내용은 측정항목 탐색기 사용 시 측정항목 선택을 참조하세요.

앞선 그래프는 시간 경과에 따른 내보내기 데이터 세트의 크기를 TB 단위로 표시합니다. 이를 통해 BigQuery로의 Logging 내보내기를 어느 정도 사용했는지 알 수 있습니다.

Pub/Sub

Monitoring에서 측정항목 탐색기를 사용하면 Pub/Sub에 내보낸 메시지 수와 메시지 크기를 볼 수 있습니다. 측정항목 탐색기에서 다음 값을 사용하여 로깅 싱크에 사용되는 Pub/Sub 주제의 스토리지 크기를 확인합니다.

측정항목 탐색기를 사용하여 모니터링 리소스의 측정항목을 확인하려면 다음을 수행하세요.

Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.
측정항목 탐색기로 이동
측정항목 요소에서 측정항목 선택 메뉴를 펼치고 필터 표시줄에 Byte cost을 입력한 후 하위 메뉴를 사용하여 특정 리소스 유형과 측정항목을 선택합니다.
1. 활성 리소스 메뉴에서 Cloud Pub/Sub 주제를 선택합니다.
2. 활성 측정항목 카테고리 메뉴에서 주제를 선택합니다.
3. 활성 측정항목 메뉴에서 주제 바이트 비용을 선택합니다.
4. 적용을 클릭합니다.
이 측정항목의 정규화된 이름은 pubsub.googleapis.com/topic/byte_cost입니다.
데이터 보기 방법을 구성합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 project_id를 선택합니다. 값으로 Google Cloud 프로젝트 ID를 선택합니다.
- 필터 요소에서 필터 추가를 클릭한 다음 topic_id를 선택합니다. 값으로 Pub/Sub 내보내기 주제 이름을 선택합니다.
- 집계 항목에서 첫 번째 메뉴를 집계되지 않음으로 설정합니다.
차트 구성에 대한 자세한 내용은 측정항목 탐색기 사용 시 측정항목 선택을 참조하세요.

앞선 그래프는 시간 경과에 따라 내보낸 데이터의 크기를 KB 단위로 표시합니다. 이를 통해 Pub/Sub로의 Logging 내보내기를 어느 정도 사용했는지 알 수 있습니다.

비용 관리 구현

다음 옵션들은 비용을 절감할 수 있는 잠재적인 방법을 설명합니다. 옵션마다 앱 및 인프라에 대한 정보가 제한된다는 단점이 있습니다. 관측 가능성과 비용의 균형을 가장 적절히 맞추는 옵션을 선택하세요.

Logging 비용 관리

Logging 사용량을 최적화함으로써 Logging에 내부 데이터화되는 로그 수를 줄일 수 있습니다. 개발자와 운영자에게 필요한 로그를 계속 유지하면서 로그 볼륨을 줄일 수 있는 여러 가지 전략이 있습니다.

로그 제외

개발자와 운영팀에서 필요로 하지 않는 대부분의 로그를 Logging 또는 Error Reporting에서 제외할 수 있습니다.

로그를 제외하면 Logging 또는 Error Reporting UI에 로그가 표시되지 않습니다. 로깅 필터를 사용하여 특정 로그 항목 또는 전체 로그를 제외하도록 선택할 수 있습니다. 샘플링 제외 규칙을 사용하여 로깅 항목의 일정 비율을 제외할 수도 있습니다. 예를 들어, 볼륨이 일정량을 초과하거나 실질적인 값이 없는 특정 로그를 제외하도록 할 수 있습니다.

일반적인 제외 예는 다음과 같습니다.

Cloud Load Balancing에서 로그를 제외합니다. 부하 분산기는 트래픽이 많은 앱의 로그를 대량으로 생성할 수 있습니다. 예를 들어, 로깅 필터를 사용하여 Cloud Load Balancing에서 메시지의 90%를 제외하도록 설정할 수 있습니다.
Virtual Private Cloud(VPC 서비스 제어) 흐름 로그를 제외합니다. 흐름 로그에는 VPC 서비스 제어 네트워크에 있는 가상 머신 간의 각 통신에 대한 로그가 포함되어 있으며, 이로 인해 대량의 로그가 생성될 수 있습니다. 로그 볼륨을 줄일 수 있는 두 가지 방식이 있는데, 함께 사용하거나 따로 사용할 수 있습니다.
- 로그 항목 콘텐츠별로 제외합니다. 대부분의 VPC 흐름 로그를 제외하고, 유용할 수 있는 특정 로그 메시지만 보존합니다. 예를 들어, 외부 소스로부터 인바운드 트래픽을 수신해서는 안 되는 사설 VPC가 있는 경우에는 외부 IP 주소의 소스 필드에 대해 흐름 로그만 보존할 수 있습니다.
- 일정 비율을 제외합니다. 또 다른 방식은 필터에 의해 식별된 로그 중 일부만 샘플링하는 것입니다. 예를 들어 흐름 로그의 95%는 제외하고 5%만 보존할 수 있습니다.
요청 로그에서 HTTP 200 OK 응답을 제외합니다. 앱의 경우에는 HTTP 200 OK 메시지가 많은 정보를 제공하지 못하고 트래픽이 많은 앱에 대해 대량의 로그를 생성할 수 있습니다.

로깅 제외를 구현하려면 로그 제외를 읽어 보세요.

로그 내보내기

로그를 내보냄으로써 Logging에서 내부 데이터화되지 않도록 할 수 있습니다. 그러면 Cloud Storage 및 BigQuery에서 로그를 보존하거나 Pub/Sub를 사용하여 로그를 처리하는 동시에 Logging에서 로그를 제외할 수 있으므로 비용을 줄이는 데 도움이 됩니다. 즉, 로그를 Logging에 표시하지 않고 내보냅니다.

Logging에 내부 데이터화하는 비용이 발생하지 않도록 하면서 장기 분석을 위해 로그를 보존하려면 이 방법을 사용하세요. 제외 및 내보내기가 상호작용하는 방법에 대해 자세히 알아보려면 내보낸 로그 항목이 Logging에서 어떻게 취급되는지를 설명하는 로그 수명 다이어그램을 참조하세요.

Logging 에이전트 사용량 줄이기

Logging 에이전트에 의해 생성된 추가 로그를 Logging에 보내지 않음으로써 로그 볼륨을 줄일 수 있습니다. Logging 에이전트는 Apache, Mongodb, MySQL 등 일반 타사 앱의 로그를 스트리밍합니다.

예를 들어, 개발 또는 기타 비필수 환경의 가상 머신에 연결된 Logging 에이전트를 Logging에 추가하지 않도록 설정해 로그 볼륨을 줄일 수 있습니다. 가상 머신은 계속해서 표준 로그를 Logging에 보고하지만, 타사 앱이나 syslog의 로그는 보고하지 않습니다.

Monitoring 비용 관리

Monitoring 사용량을 최적화하기 위해 Monitoring에 내부 데이터화되는 청구 가능한 측정항목 볼륨과 Monitoring API에 대한 읽기 호출 수를 줄일 수 있습니다. 개발자와 운영자에게 필요한 측정항목을 계속 유지하면서 측정항목 볼륨을 줄이는 데 도움이 될 수 있는 여러 가지 전략이 있습니다.

측정항목 및 라벨 사용량 최적화

Monitoring 커스텀 측정항목에서 라벨을 사용하는 방법이 생성되는 시계열 볼륨에 영향을 미칠 수 있습니다.

라벨 두 개(예: cost_center 및 env 값)가 포함된 커스텀 측정항목이 있는 경우 두 라벨의 카디널리티를 곱해 최대 시계열 수를 계산할 수 있습니다.

total_num_time_series = cost_center_cardinality * env_cardinality

cost_center 값 11개와 env 값 5개가 있으면 시계열을 최대 55개까지 생성할 수 있습니다. 따라서 측정항목 라벨을 추가하면 측정항목 볼륨이 크게 늘어날 수 있으며 이로 인해 비용이 증가합니다. 측정항목 카디널리티에 대한 자세한 설명은 Cloud Monitoring 도움말 및 유용한 정보: 측정항목 이해와 차트 작성 블로그 게시물을 참조하세요.

시계열 수를 최소화하려면 다음을 수행하는 것이 좋습니다.

가능하면 커스텀 측정항목 라벨 수를 제한합니다.
카디널리티가 높은 라벨 값이 방지되도록 라벨을 신중하게 선택합니다. 예를 들어 user_id를 라벨로 사용하면 사용자마다 시계열이 최소 하나 이상 생성되므로 트래픽이 많은 경우 시계열이 매우 많을 수 있습니다.

Monitoring 에이전트 사용량 줄이기

Monitoring 에이전트에서 전송되는 측정항목은 청구 대상 측정항목입니다. Monitoring 에이전트는 Apache, MySQL, Nginx 등 일반 타사 앱의 앱 및 시스템 측정항목과 추가 Google Cloud VM 수준 측정항목을 스트리밍합니다. 특정 VM에서 세부적인 시스템 측정항목이나 타사 앱의 측정항목이 필요하지 않은 경우에는 이런 측정항목을 보내지 않음으로써 볼륨을 줄일 수 있습니다. Monitoring 에이전트를 사용하는 VM 수를 줄여 측정항목 볼륨을 줄일 수도 있습니다.

예를 들어 개발 또는 기타 비필수 환경의 Google Cloud 프로젝트를 Monitoring에 추가하지 않도록 해 측정항목 볼륨을 줄일 수 있습니다. 또한 개발 및 기타 비필수 환경의 VM에 Monitoring 에이전트를 포함하지 않을 수 있습니다.

커스텀 측정항목 사용량 줄이기

커스텀 측정항목은 Monitoring API를 사용하여 생성되는 청구 대상 측정항목이며, 사용자가 계측하는 측정항목을 모니터링합니다. Monitoring API 또는 통합을 사용하여 이러한 측정항목을 만들 수 있습니다.

이러한 통합 중 하나로 OpenCensus가 있습니다. OpenCensus는 앱으로부터 측정항목 및 분산 trace를 수집하는 라이브러리 분산입니다. OpenCensus를 사용하여 계측된 앱은 커스텀 측정항목을 사용하여 Monitoring 등 여러 백엔드에 측정항목을 보고할 수 있습니다. 이러한 측정항목은 Monitoring에서 custom.googleapis.com/opencensus 프리픽스 리소스 유형 아래에 표시됩니다. 예를 들어 OpenCensus에 의해 보고되는 클라이언트 왕복 지연 시간은 Monitoring에서 custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency 리소스 유형 아래에 표시됩니다.

더 많은 앱을 계측해 측정항목을 보낼수록 더 많은 커스텀 모니터링 측정항목이 생성됩니다. 측정항목 볼륨을 줄이려면 앱이 보내는 커스텀 모니터링 측정항목 수를 줄일 수 있습니다.

Trace 비용 관리

Trace 사용량을 최적화하려면 내부 데이터화되고 검색되는 스팬 수를 줄이면 됩니다. 스팬을 Trace로 보내도록 앱을 설정할 때, 샘플링을 사용하여 트래픽의 일부를 내부 데이터화합니다. 샘플링은 RPC 호출 등 앱 구성요소에 의해 발생하는 지연 시간에 대한 분석 정보를 제공하기 때문에 추적 시스템의 핵심적인 부분입니다. 이것은 Trace를 사용할 때의 권장사항일 뿐만 아니라 비용 절감을 위해 스팬 볼륨을 줄이는 데도 도움이 됩니다.

OpenCensus 샘플링 사용

Trace를 OpenCensus 추적의 내보내기 대상으로 사용하는 경우, OpenCensus의 샘플링 기능을 사용하여 내부 데이터화되는 추적 볼륨을 줄일 수 있습니다.

예를 들어 초당 쿼리 수가 5000인 인기 웹 앱에서는 앱 트래픽의 20%가 아니라 5%만 샘플링해도 충분한 정보를 얻을 수 있습니다. 이렇게 하면 Trace에 수집되는 스팬 수가 1/4로 줄어듭니다.

Trace용 OpenCensus Python 라이브러리를 사용하여 계측 구성에서 샘플링을 지정할 수 있습니다. 일례로 OpenCensus Python 내보내기는 샘플링 레이트를 지정하는 데 사용할 수 있는 ProbabilitySampler를 제공합니다.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Cloud Trace API 스팬 할당량 사용

할당량을 사용하여 Trace 사용량 및 비용을 제한할 수 있습니다. Google Cloud 콘솔의 API별 할당량 페이지에서 스팬 할당량을 적용할 수 있습니다.

기본 제품 할당량보다 낮은 할당량을 설정하면 프로젝트가 지정한 할당량을 초과하지 않게 됩니다. 이렇게 하면 비용을 예상 가능한 범위 내로 제한할 수 있습니다. 다음 이미지에 표시된 것처럼 API 특정 할당량 페이지에서 이 할당량을 모니터링할 수 있습니다.

API별 할당량 페이지 모니터링

스팬 할당량을 줄이는 경우에는 스팬 할당량 측정항목을 모니터링하고, 사용량이 할당량에 근접할 때 알림을 보내도록 Monitoring에서 알림 정책을 설정하는 것도 고려해 봐야 합니다. 이 알림은 사용량을 살펴보고 대량의 스팬을 생성할 수 있는 앱과 개발자를 파악할 수 있게 도와줍니다. 설정된 스팬 할당량을 초과하게 되면 할당량을 조정하기 전까지 스팬이 삭제됩니다.

예를 들어, 스팬 할당량이 5천만 개의 내부 데이터화된 스팬일 경우 API 할당량의 80%, 즉 4천만 개 스팬을 사용할 때마다 알림을 보내도록 설정할 수 있습니다. 다음 세부정보를 사용하여 알림 정책을 만들려면 알림 정책 관리 안내를 따르세요.

Google Cloud Console에서 Monitoring으로 이동하거나 다음 버튼을 사용합니다.
Monitoring으로 이동
Monitoring 탐색창에서 알림을 선택한 다음 정책 만들기를 선택합니다.
알림 정책의 이름을 입력합니다.
조건 추가를 클릭합니다.
1. 대상 창의 설정은 모니터링할 리소스와 측정항목을 지정합니다. 텍스트 상자를 클릭하여 메뉴를 사용 설정한 다음 리소스 global을 선택합니다.
2. 텍스트 상자를 클릭하여 메뉴를 사용 설정한 다음 cloudtrace.googleapis.com/billing/monthly_spans_ingested를 선택합니다.
3. 다음 필터 값을 추가합니다.
4. 알림 정책의 구성 창에 있는 설정에 따라 알림이 실행되는 시점이 결정됩니다. 다음 입력란을 작성하세요.
5. 저장을 클릭합니다.
저장을 클릭합니다.

알림 정책에서 생성된 알림은 다음 알림과 비슷합니다. 알림에서 프로젝트에 대한 세부정보, 알림을 생성한 알림 정책, 측정항목의 현재 값을 볼 수 있습니다.

알림 세부정보

타사 호출자 최적화

앱이 다른 앱에 의해 호출될 수도 있습니다. 앱에서 스팬을 보고하는 경우, 앱에서 보고되는 스팬 수는 타사 앱으로부터 받는 수신 트래픽에 따라 다를 수 있습니다. 예를 들어 체크아웃 마이크로서비스를 호출하는 프런트엔드 마이크로서비스가 있고 두 앱 모두를 OpenCensus로 계측하는 경우 트래픽의 샘플링 레이트는 최소한 프런트엔드 샘플링 레이트와 같습니다. 계측된 앱이 어떻게 상호작용하는지를 이해하면 내부 데이터화되는 스팬 수의 영향을 평가할 수 있습니다.

Logging 내보내기

Logging 내보내기와 관련된 비용이 우려될 때의 한 가지 솔루션은 로깅 필터를 사용하여 내보내는 로그 볼륨을 줄이도록 로깅 싱크를 업데이트하는 것입니다. 필요하지 않은 내보내기에서 로그를 제외할 수 있습니다.

예를 들어 앱이 Compute Engine에서 실행되고 Cloud SQL, Cloud Storage, BigQuery를 사용하는 환경에서는 해당 제품에 대한 정보만 포함하도록 최종 로그를 제한할 수 있습니다. 다음 필터는 Cloud 감사 로그, Compute Engine, Cloud Storage, Cloud SQL, BigQuery의 로그로 내보내기를 제한합니다. 로깅 싱크에 이 필터를 사용하여 선택된 로그만 포함되도록 할 수 있습니다.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

결론

Google Cloud Observability는 제품 사용량의 세부정보를 이해할 수 있도록 제품 사용량 데이터를 표시합니다. 이 사용량 데이터를 통해 사용량 및 비용을 최적화되도록 제품을 구성할 수 있습니다.

다음 단계

Logging API 자세히 알아보기
Monitoring API 자세히 알아보기
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기