Google Cloud 탄소 발자국 줄이기

Last reviewed 2021-10-11 UTC

이 문서에서는 Google Cloud의 환경 지속 가능성에 대한 접근 방식을 설명합니다. 여기에는 Google Cloud에서 탄소 발자국을 이해하는 데 사용할 수 있는 정보와 기타 리소스, 그 발자국을 줄이거나 최소화하기 위해 사용할 수 있는 방법이 포함됩니다. 이 문서의 대상에는 다음이 포함됩니다.

  • 탄소 발자국이 최소화된 애플리케이션을 빌드하려는 개발자
  • 현재 탄소 발자국을 파악하고 이러한 발자국을 줄일 수 있는 기회를 파악하려는 인프라 및 기타 기술팀

이 문서에서는 사용자가 Google Cloud와 가상 머신(VM) 워크로드 실행에 익숙하다고 가정합니다.

클라우드 탄소 배출 이해

Google은 2007년 이후 탄소 중립2030년까지 연중무휴 100% 무탄소 운영을 위해 노력하고 있습니다. 또한 Google Cloud 서비스를 실행하는 데이터 센터를 포함한 Google의 데이터 센터는 일반 데이터 센터보다 훨씬 적은 에너지를 사용합니다. 이러한 이유로 Google Cloud를 사용하면 오늘날 IT의 탄소 발자국을 줄일 수 있습니다.

Google은 글로벌 데이터 센터 네트워크를 통해 제공되는 여러 클라우드 리전을 운영합니다. 이러한 데이터 센터는 로컬 그리드에서 생성되는 전력을 소비하여 클라우드 서비스를 실행합니다. 로컬 그리드에서 생성되는 전력의 환경 영향은 전력망 탄소 강도로 측정됩니다. 그리드의 탄소 강도는 전기를 생산하는 발전소에서 배출되는 탄소의 양을 나타냅니다.

에너지 혼합 및 프로덕션 효율성 차이와 같은 요인으로 인해 모든 데이터 센터 위치에 걸쳐 환경에 미치는 영향이 동일하지는 않습니다. 2017년 이후 Google은 전력 구매 협정(PPA)을 통해 전년 동기로 소비하는 전기에 해당하는 재생 에너지를 조달합니다. 이러한 PPA는 Google의 데이터 센터가 전력을 소비하는 그리드로 들어오는 Google의 무탄소 에너지를 생산합니다.

Google 데이터 센터에서 사용하는 전력의 환경 영향은 그리드의 탄소 강도와 Google에서 소비하는 무탄소 에너지 소스의 에너지로 인해 결정됩니다. Google은 이러한 두 요소에서 계산된 무탄소 에너지 백분율(CFE%) 측정항목을 도입했습니다. CFE%는 각 리전의 시간당 평균 무탄소 에너지 소비량을 나타내며, 애플리케이션이 무탄소 에너지에서 실행되는 평균 시간 비율을 나타냅니다. 클린 에너지 사용으로 인해 CFE%가 높은 리전은 동일한 워크로드의 CFE%가 낮은 리전보다 탄소 배출량이 적습니다.

탄소 배출량을 줄이려면 탄소 기반 소스에서 클라우드 워크로드의 전력 소비를 줄여야 합니다. 탄소 배출량을 줄이려면 다음과 같은 기본 전략을 사용하는 것이 좋습니다.

  1. 평균 시간당 CFE%가 높고 그리드 탄소 강도가 낮은 클라우드 리전을 선택합니다. CFE%가 같은 리전의 경우 그리드 탄소 강도를 사용하여 해당 리전의 탄소 배출량을 추가로 비교합니다.
  2. 클라우드 워크로드를 최적화하여 탄소 배출량을 줄이세요. 예를 들어 탄력적인 클라우드 서비스 및 자동 확장 기능을 사용하여 미사용 컴퓨팅 리소스를 최소화하고 그리드 탄소 강도가 낮은 시간 동안 일괄 워크로드를 실행합니다.
  3. 클라우드 리소스의 위치를 클린 리전으로 제한하도록 조직 정책을 설정합니다.

탄소 발자국 이해

Google Cloud는 Google Cloud 사용량에서 탄소 발자국을 이해하는 데 도움이 되는 도구인 Carbon Footprint를 제공합니다. Carbon Footprint는 로컬 전력 그리드의 그리드 탄소 강도를 기준으로 총 탄소 배출량을 제공합니다. 이 보고서는 개발자가 소유한 Google Cloud 프로젝트와 사용하는 클라우드 서비스에 대한 배출량을 추가로 설명합니다. 배출량 데이터는 Google의 Carbon Footprint 보고 방법에 따라 보고되며 Google Cloud 고객으로서 온실 가스(GHG) 프로토콜 범위 3 표준을 지원할 수 있습니다. 추가 분석을 위해 Carbon Footprint 데이터를 BigQuery로 내보낼 수 있습니다.

Carbon Footprint 대시보드와 BigQuery 내보내기를 사용하면 Google Cloud 서비스 사용에 따른 위치 기반 배출량을 파악할 수 있습니다. 이 데이터를 사용하여 다양한 Google Cloud 서비스의 탄소 발자국을 비교할 수 있습니다. 예를 들어 상대적 배출량을 이해하기 위해 동일한 클라우드 리전에서 실행 중인 두 개 이상의 서비스의 총 배출량을 비교할 수 있습니다.

탄소 발자국 보고서에서 제공하는 Google Cloud 고객별 총 온실가스 배출량 데이터는 제3자가 인증하거나 보장하지 않습니다.

가장 적합한 클라우드 리전 선택

워크로드를 실행하기 위해 클리너 클라우드 리전을 선택하는 것은 탄소 배출량을 줄이는 가장 간단하고 효과적인 방법 중 하나입니다. Google은 로컬 전력 그리드의 CFE% 및 그리드 탄소 강도를 비롯한 모든 클라우드 리전의 탄소 데이터를 게시합니다. 전반적인 배출량을 줄이려면 가능한 경우 CFE%가 높은 리전을 선택하는 것이 좋습니다. 클린 리전을 선택할 수 있도록 Google Cloud에는 Google Cloud console의 일부 위치 선택기와 Google Cloud 문서의 '위치' 페이지에 낮은 CO2 표시기가 포함되어 있습니다. 이 표시기를 받기 위해 리전이 충족해야 하는 기준에 대한 자세한 내용은 Google Cloud 리전의 무탄소 에너지를 참조하세요.

CFE%가 유사한 리전이 여러 개 있는 경우 그리드 탄소 강도를 비교합니다. 위치 기반 배출량을 줄이는 데 주력하고 있다면 리전별로 그리드 탄소 강도를 비교하는 것도 중요합니다. 예를 들어 비슷한 CFE% 점수의 경우 석탄 발전소 또는 가스 발전소에 의해 그리드에 전력을 공급할 수 있습니다. 그리드 탄소 강도는 이러한 조합을 반영하며 가장 낮은 탄소 배출 그리드를 선택하는 데 도움이 됩니다.

리전을 선택할 때 배출량을 줄이는 것은 여러 요구사항 중 하나일 수 있습니다. 예를 들어 사용자에게 특정 Google Cloud 서비스의 가용성, 가격 책정, 데이터 위치 요구사항, 제공 지연 시간을 고려해야 할 수 있습니다. 전체 CFE%가 가장 높은 리전은 사용 사례에 적합하지 않을 수 있습니다. 배출량을 최소화하려면 CFE%가 가장 높고 모든 요구사항을 충족하는 리전을 선택하세요.

리전 선택을 간소화하려면 Google Cloud 리전 선택 도구를 사용하여 탄소 발자국, 가격, 지연 시간에 따라 요구사항을 충족하는 최적의 클라우드 리전을 결정합니다. Google Cloud 리전 선택 도구에 대한 자세한 내용은 적합한 Google Cloud 리전 선택을 참조하세요.

조직에서 사용 가능한 클라우드 리전을 선택하는 옵션을 제공하는 경우 위치를 낮은 CO2 리전으로 제한하는 조직 정책을 설정하는 것도 고려해 볼 수 있습니다.

가장 적합한 클라우드 서비스 선택

Google Cloud는 여러 IT 워크로드에 적합한 다양한 클라우드 서비스를 제공합니다. 기존 탄소 발자국을 줄이려면 VM 워크로드를 온프레미스 데이터 센터와 같이 에너지 효율이 낮은 인프라에서 Compute Engine으로 마이그레이션하는 것이 좋습니다. 온프레미스 데이터 센터 및 다양한 클라우드 환경에서 VM을 Google Cloud로 마이그레이션하는 방법에 대한 자세한 내용은 Migrate to Virtual Machines를 사용한 마이그레이션 여정을 참조하세요.

많은 워크로드에 VM이 필요하지 않으며 다양한 워크로드 유형을 위한 다른 완전 관리형 서비스에 대신 배포할 수 있습니다. 이러한 서비스에는 성능 및 리소스 사용량을 최적화하는 데 도움이 되는 자동 확장 및 올바른 크기 조정 기능이 기본으로 제공되는 경우가 많습니다. 예를 들어 Cloud Run은 VM에서 비슷한 애플리케이션 스택을 실행하는 것에 비해 컨테이너화된 애플리케이션을 더 빠르게 확장하고 유휴 리소스를 줄여주는 완전 서버리스 환경입니다. 유휴 리소스가 적으면 비용을 최적화하고 탄소 발자국을 줄일 수 있습니다.

일반적인 워크로드 유형에는 다음 제안 사항을 고려하세요. 서비스 목록이 모든 내용을 포함하지는 않지만 여러 관리형 서비스가 클라우드 리소스 사용량을 자동으로 최적화해 클라우드 비용과 탄소 발자국을 동시에 줄이는 방법을 설명합니다.

  • Cloud Run: 원하는 언어로 작성되어 컨테이너식 애플리케이션을 실행하는 서버리스 서비스입니다. 트래픽에 따라 0개에서 N개의 컨테이너 인스턴스로 빠르게 자동 확장합니다. 트래픽이 없는 경우 애플리케이션이 요청을 처리하기 위해 컴퓨팅 리소스를 사용하지 않습니다. 이 서비스는 갑작스럽게 바뀌는 트래픽 패턴을 처리하고 그에 따라 컴퓨팅 리소스 사용을 최적화하도록 설계되었습니다.
  • Cloud Functions: 서버리스 서비스로서의 기능(FaaS)입니다. Cloud Run 및 App Engine과 동일한 인프라에서 실행되므로 동일한 scale-from-zero 및 빠른 자동 확장 기능을 Cloud Functions로 확장합니다.
  • Google Kubernetes Engine(GKE): 관리형 Kubernetes 환경을 제공하는 클라우드 서비스입니다. GKE에서 Kubernetes 환경을 사용하여 컨테이너화된 워크로드를 실행하면 직접 VM 사용과 비교할 때 사용되지 않는 클라우드 리소스를 최소화하여 클라우드 비용을 절감하고 워크로드의 탄소 발자국을 줄일 수 있습니다.
  • BigQuery: 페타바이트급 규모의 데이터 세트 쿼리를 지원하는 서버리스 클라우드 데이터 웨어하우스입니다. BigQuery는 대규모 멀티 테넌트 인프라에서 많은 사용자를 지원함으로써 방대한 규모의 경제를 통해 컴퓨팅 리소스를 효율적으로 활용합니다. BigQuery 아키텍처는 스토리지와 컴퓨팅을 분리하고 컴퓨팅 리소스를 효율적으로 할당하여 쿼리 실행과 별도로 데이터 스토리지를 확장합니다. BigQuery는 쿼리 실행에 필요한 컴퓨팅 리소스(슬롯이라고 함)를 동적으로 할당합니다. 공정 예약은 필요에 따라 프로젝트 간에 슬롯 용량을 자동으로 재할당하고 쿼리를 실행합니다.

VM을 여전히 필요로 하는 다른 워크로드가 있을 수 있습니다. VM이 필요할 때 필요한 양을 넘어서는 초과 프로비저닝을 피하고 사용하지 않는 리소스를 실행 상태로 두지 마세요. 그러면 비용과 배출량이 늘어날 수 있습니다.

유휴 클라우드 리소스 최소화

유휴 또는 비효율적인 클라우드 리소스 사용을 줄이는 비용 최적화 방법도 탄소 발자국을 줄이는 데 도움이 된다는 사실을 알 수 있습니다. 유휴 리소스는 불필요한 비용과 배출량을 발생시켜 낭비를 유발합니다. 다음과 같은 형태의 미사용 리소스를 고려하세요.

  1. 사용되지 않는 활성 클라우드 리소스(예: 워크로드가 완료되었을 때 종료되지 않는 VM 인스턴스)
  2. 초과 프로비저닝 리소스(예: 워크로드에 필요한 것보다 더 많은 VM 또는 더 큰 VM 머신 유형 사용)
  3. 최적화되지 않은 아키텍처 또는 워크플로(예: 클라우드로 마이그레이션되었지만 최적화되지 않은 애플리케이션 또는 데이터 처리와 분석 작업 부하에 대해 구분되지 않은 스토리지 및 컴퓨팅 인프라 리프트 앤 시프트)

사용되지 않고 초과 프로비저닝된 VM 리소스는 일반적으로 불필요한 비용과 탄소 발자국 증가에 가장 큰 영향을 미칩니다. 탄소 발자국을 최소화하려면 워크로드 자동화, 모니터링, 최적화 프로세스를 통해 유휴 VM 용량 및 기타 사용되지 않는 클라우드 리소스를 최소화하는 방법을 고려하세요. 이러한 주제는 이 문서에서 다루지 않습니다. 그러나 비용 및 탄소 발자국에 많은 영향을 미칠 수 있는 간단한 방법이 있습니다. 이러한 방법 중 일부는 클라우드 사용을 최적화하기 위한 다음과 같은 종류의 자동화된 권장사항을 제공하는 솔루션인 Active Assist를 통해 사용 설정됩니다.

  1. 유휴 VM 리소스 식별 및 삭제: Google Cloud Console에서 미사용 디스크와 같은 유휴 리소스 권장사항을 정기적으로 확인합니다. gcloud CLI를 사용하거나 API를 통해 유휴 리소스 권장사항을 볼 수도 있습니다. 유휴 리소스가 더 이상 필요하지 않으면 이를 삭제하여 비용과 배출량을 절약할 수 있습니다.
  2. VM 인스턴스를 알맞은 크기로 조정: Google Cloud Console에서 크기 조정 권장사항을 정기적으로 확인하여 리소스 사용량에 따라 VM의 크기를 최적화합니다. 알맞은 크기 조정은 초과 프로비저닝으로 인한 낭비를 해결하는 데 도움이 됩니다. gcloud CLI 또는 API를 사용하여 알맞은 크기 권장사항을 수도 있습니다.
  3. 유휴 VM 식별 및 삭제: 유휴 VM 추천자를 사용하여 사용되지 않은 VM 인스턴스를 식별합니다. 유휴 VM이 더 이상 필요하지 않은지 확인한 후 삭제할 수 있습니다.
  4. 무인 프로젝트 회수 또는 삭제: 무인 프로젝트 추천자를 사용하여 사용량이 적거나 미사용 무인 프로젝트를 찾아 가능한 경우 해당 프로젝트를 종료할 수 있습니다.
  5. 필요할 때 VM이 실행되도록 예약: VM이 특정 시간에만 필요한 경우 VM 인스턴스가 자동으로 시작되고 중지되도록 예약하는 것이 좋습니다.
  6. 유휴 및 초과 프로비저닝된 Cloud SQL 인스턴스 문제 해결: Active Assist를 사용하여 초과 프로비저닝유휴 MySQL용 Cloud SQL, PostgresSQL, SQL Server 인스턴스를 식별합니다. 인스턴스가 식별되면 이러한 인스턴스의 크기를 조절하거나 삭제할 수 있습니다.

아키텍처가 최적화되지 않으면 클라우드 리소스를 효율적으로 사용할 수 없습니다. 클라우드용으로 빌드된 애플리케이션에서 아키텍처 문제가 발생할 수 있지만 이러한 문제는 온프레미스 워크로드에서 가장 일반적으로 발생합니다. 예를 들어 Google Cloud로 마이그레이션된 모놀리식 애플리케이션이 최적화 필요성을 없애거나 최소화할 수 있습니다(일반적으로 리프트 앤 시프트라고 함). 다음과 같은 방법은 아키텍처를 최적화하는 데 도움이 될 수 있습니다.

  1. 필요할 때 리소스 만들기: 클라우드 리소스는 탄력적이지만 실제 사용량에 관계없이 지속적으로 실행되는 고정된 리소스에 워크로드가 배포되면 효율성이 떨어집니다. VM 예약 또는 클라우드 서비스 내의 탄력적 기능 사용 등 필요한 경우 리소스를 만들고 삭제할 수 있는 기회를 파악합니다. 탄력적 기능 사용에는 Compute Engine으로 스테이트리스 웹 서버를 실행하는 VM을 자동 확장하거나 Dataflow로 스트리밍 데이터 파이프라인의 작업자를 자동 확장하는 작업이 포함됩니다.
  2. 워크로드 컨테이너화: 워크로드를 컨테이너로 패키징하고 Google Kubernetes Engine(GKE)과 같은 컨테이너 조정자를 사용하여 컨테이너를 효율적으로 실행하는 것을 고려합니다. GKE를 사용하면 리소스 요구사항에 따라 VM 클러스터에서 컨테이너를 효율적으로 예약할 수 있습니다. 여러 컨테이너가 리소스 요구사항을 허용하는 경우 단일 VM의 리소스도 공유할 수 있습니다.

Migrate for GKE 및 GKE Enterprise는 VM에서 컨테이너로의 워크로드 마이그레이션을 위한 간소화된 경로를 제공합니다. VM을 컨테이너로 마이그레이션하는 작업은 애플리케이션 현대화를 위한 첫 번째 단계일 수 있습니다. 이후 단계에는 탄소 배출량을 줄이기도 하는 비용 최적화 관행과 애플리케이션을 마이크로서비스로 리팩터링하는 작업을 포함합니다.

완전한 구성 유연성과 컨테이너 조정을 제어해야 하는 경우에는 GKE를 사용하는 것이 좋습니다. 컨테이너화된 웹 애플리케이션 또는 마이크로서비스를 실행해야 하고 전체 Kubernetes 환경이 필요하지 않으면 Cloud Run 사용을 고려합니다. Cloud Run은 컨테이너 실행의 복잡성을 추상화하고 대신 개발자에게 향상된 환경을 제공하는 데 중점을 둡니다. 보다 자세한 비교는 Google Kubernetes Engine과 Cloud Run 비교를 참조하세요.

  1. 모놀리식 애플리케이션을 마이크로서비스로 리팩터링: 모놀리식 애플리케이션은 모든 모듈을 단일 프로그램으로 결합하므로 특정 모듈을 실행하기 위해 리소스를 할당하기 어렵게 합니다. 따라서 모놀리식 애플리케이션은 효율적으로 실행하고 확장하기가 어려울 수 있으므로 마이크로서비스 기반 구현에 비해 탄소 발자국이 더 클 수 있습니다.

    장바구니 서비스와 결제 서비스가 있는 모놀리식 전자상거래 웹사이트를 생각해 보세요. 사용자는 한 세션에서 장바구니 서비스와 여러 번 상호작용하며 세션이 끝날 때만 결제 서비스와 상호작용할 수 있습니다. 두 서비스는 다양한 트래픽 및 부하 특성으로 인해 리소스 요구사항이 서로 다르지만 동일한 모놀리식 애플리케이션의 일부이므로 별도로 실행할 수 없습니다. VM에서 모놀리식으로 실행하는 경우 하나의 서비스만 처리 용량을 늘려야 하는 경우에도 각각의 추가 VM이 두 서비스를 실행하기 위한 컴퓨팅 리소스를 추가합니다.

    모놀리식과 달리 마이크로서비스는 네트워크 호출을 사용하여 통합된 자체 경량 프로그램으로 애플리케이션 모듈을 분리합니다. 마이크로서비스는 서로 독립적으로 확장될 수 있으며 실행에 적합한 다양한 리소스 형태(예: VM 머신 유형, Cloud Run vCPU 및 메모리 할당, App Engine 인스턴스 유형)를 사용합니다. 마이크로서비스는 세분화된 확장을 통해 클라우드 리소스를 보다 효율적으로 사용하고 초과 프로비저닝을 줄여 비용과 배출량을 낮출 수 있습니다. 자세한 내용은 모놀리식을 마이크로서비스로 리팩터링을 참조하세요.

  2. 스토리지 및 컴퓨팅 리소스를 분리하는 클라우드 서비스 사용: 일부 온프레미스(및 클라우드 기반) 데이터 처리 및 분석 워크로드(예: Apache HadoopApache Spark)는 데이터 스토리지와 컴퓨팅에 대해 동일한 인프라를 공유하는 경우가 많습니다. 최대 컴퓨팅 요구사항에 맞게 동일한 공간을 조정해야 하지만 데이터를 저장하기 위해 대규모 인프라 공간을 유지하면 컴퓨팅 리소스 사용률이 낮은 경우가 많습니다. 사용률이 낮으면 리소스가 유휴 상태가 되어 비용이 증가하고 불필요하게 배출량이 더 많아집니다.

    이러한 워크로드를 Google Cloud로 마이그레이션할 때는 다음과 같이 스토리지와 컴퓨팅 인프라를 분리하는 관리형 서비스를 사용하는 것이 좋습니다.

    • BigQuery: BigQuery는 페타바이트급 규모의 서버리스 데이터 웨어하우스입니다. SQL 기반 분석 워크로드에 BigQuery를 사용할 수 있습니다. BigQuery 내의 데이터 세트 스토리지는 컴퓨팅 리소스와 분리됩니다. 이러한 분리는 BigQuery 스토리지가 리소스를 효율적으로 사용하는 방식으로 사실상 무제한 스토리지를 제공하도록 확장된다는 것을 의미합니다. 또한 데이터를 복제하거나 새 클러스터를 작동시키지 않고도 데이터 세트를 한 곳에서 공유할 수 있습니다.
    • Dataproc: Dataproc는 Hadoop 및 Spark 워크로드를 위한 관리형 서비스입니다. 많은 온프레미스 Hadoop 및 Spark 배포가 사용 특성에 관계없이 항상 사용 가능한 컴퓨팅 클러스터를 사용합니다. Dataproc를 사용하여 장기 클러스터를 만들 수 있지만 작업을 실행해야 하는 경우 임시 클러스터를 만드는 것이 좋습니다. Dataproc 작업에서 읽거나 쓰는 데이터는 Cloud Storage 및 Bigtable과 같은 전용 스토리지 서비스에서 별도로 관리됩니다. 실행 중인 작업이 없더라도 Hadoop 스토리지의 환경을 유지관리할 필요가 없기 때문에 운영 복잡성, 비용, 탄소 배출량이 줄어듭니다.
    • Spanner: Spanner는 스토리지에서 컴퓨팅을 분리하는 전 세계적으로 확장 가능한 분산형 SQL Database 서비스이므로 이러한 리소스를 개별적으로 확장할 수 있습니다. 자동 확장 처리 도구를 사용하여 Spanner 인스턴스의 컴퓨팅 리소스 노드 수를 자동으로 확장할 수도 있습니다. Spanner 자동 확장을 사용하면 인프라가 부하 요구사항에 맞게 자동으로 조정 및 확장할 수 있으며, 부하가 적을 때 비용과 탄소 배출량을 줄이는 데 도움이 됩니다.
  3. 워크로드를 관리형 서비스로 마이그레이션: 관리형 제품은 워크로드를 자동으로 확장하여 사용하지 않는 리소스를 최소화하고 인프라 요구사항을 줄일 수 있는 다른 기능을 제공합니다. 자세한 내용은 이 문서의 앞 부분에서 설명한 가장 적합한 클라우드 서비스 선택을 참조하세요.

일괄 워크로드의 탄소 배출량 감소

많은 온라인 제공 워크로드와 달리 일괄 워크로드는 실행 위치와 시점에 따라 유연합니다. 일괄 워크로드의 예시로는 과학적 계산을 위한 고성능 컴퓨팅(HPC) 작업, 일일 계정 조정 실행, 마케팅 이메일을 위한 제품 추천 생성이 있습니다.

다른 워크로드와 마찬가지로 전체 탄소 발자국을 줄이려면 CFE%가 높은 리전에서 일괄 워크로드를 실행하는 것이 좋습니다. 일괄 작업을 실행해야 할 때 유연성을 갖춘 경우 그리드 탄소 강도가 일치하는 시점에 작업을 실행하여 탄소 발자국을 더 줄일 수 있습니다. Google Cloud 리전이 있는 여러 글로벌 위치에서 시간당 그리드 믹스 탄소 강도 데이터를 보려면 Tomorrow에서 유지되는 electricityMap 웹사이트를 사용하세요.

일괄 워크로드는 원치 않는 네트워킹 오버헤드를 발생시키는 관련 시스템(예: 데이터 소스 및 싱크)에 대한 종속 항목이 있을 수 있지만 기본적으로 지연 시간에 민감하지 않아야 합니다. 이 종속 항목은 더 큰 애플리케이션 또는 워크플로의 일부(예: 하나 이상의 소스 시스템에서 데이터를 읽는 추출, 변환, 로드(ETL) 작업)에 존재할 수 있으며 변환된 데이터를 데이터 웨어하우스에 씁니다. ETL 작업이 클라우드 리전 간에 대량의 데이터를 처리하고 전송하는 경우 네트워크 성능 영향 및 리전 간 이그레스 비용 증가로 인해 작업을 개별적으로 실행하는 것은 실용적이지 않거나 비용이 많이 들 수 있습니다.

낮은 CO2 리전에서 다음 유형의 일괄 워크로드를 실행하는 것이 좋습니다.

  1. 독립형 일괄 워크로드: 필요에 맞는 최고의 가격 및 탄소 배출량 특성으로 리전을 선택하고, 해당 리전에서 스토리지 및 컴퓨팅 서비스를 사용하는 독립형 HPC 워크로드를 고려하며, 분석 결과를 직접 다운로드합니다. 이 시나리오에서는 분석 결과를 가져오는 것 외에 네트워크 성능 저하 또는 네트워크 이그레스 비용이 발생할 수 있는 리전 간 트래픽이 없습니다.
  2. 다른 클라우드 리전에서 최소한의 데이터 전송이 필요한 일괄 워크로드: 머신러닝(ML) 모델의 제품 추천을 제공하는 API를 고려합니다. API는 사용자에게 짧은 지연 시간을 제공하기 위해 여러 클라우드 리전에서 호스팅될 수 있습니다. ML 모델은 중앙 집중식 일괄 프로세스로 브라우저의 클릭 스트림 데이터에서 주기적으로 학습시키고 API가 호스팅되는 각 클라우드 리전에 복사할 수 있습니다. 이 시나리오에서 학습 작업의 출력 모델 아티팩트는 크기가 수십 MB 정도로 작습니다.

    이 시나리오에서는 ML 모델 학습을 위한 클릭 스트림 데이터가 브라우저에서 ML 백엔드를 호스팅하는 클라우드 리전으로 직접 전송됩니다. ML 백엔드가 새로운 모델 집합을 학습시키면 다른 클라우드 리전으로 모델을 복사하기 위한 데이터 전송이 상대적으로 작아집니다(모델 10개를 복사해야 하는 경우 수백 MB 미만).

권장사항

다음 표에는 Google Cloud 탄소 발자국을 줄이기 위한 권장사항이 요약되어 있습니다.

주제 권장사항
클라우드 탄소 배출 이해

무탄소 에너지 백분율(CFE%)이 클라우드 리전의 무탄소 에너지 소비를 설명하는 방식을 이해합니다.

탄소 발자국을 줄이기 위한 기본 전략을 이해합니다.

탄소 발자국 이해 Carbon Footprint 도구를 사용하여 Google Cloud 사용량의 탄소 발자국을 이해할 수 있습니다.
가장 적합한 클라우드 리전 선택

Google Cloud 리전 선택 도구를 사용하여 상대적 고려사항으로 탄소 발자국, 가격, 지연 시간에 따라 최적의 클라우드 리전을 결정합니다.

낮은 CO2 리전으로 사용을 제한하려면 조직 정책을 만드는 것을 고려합니다.

가장 적합한 클라우드 서비스 선택

비효율적인 온프레미스 데이터 센터에서 Compute Engine으로 VM을 마이그레이션합니다.

자체 관리형 VM 대신 특정 워크로드에 최적화된 클라우드 관리형 서비스를 사용합니다.

미사용 클라우드 리소스 최소화

Active Assist 기능을 사용하여 미사용 VM을 삭제하고 VM 형태를 최적화하며 무인 프로젝트를 종료합니다.

클라우드 리소스를 영구적으로 유지하지 않고 필요할 때 만들고 삭제할 기회를 파악합니다.

필요할 때마다 VM을 예약하여 시작하고 중지할 수 있습니다.

워크로드를 컨테이너로 마이그레이션하고 Cloud Run 및 GKE와 같은 관리형 서비스를 사용하여 효율적으로 실행합니다.

효율성을 향상하기 위해 마이크로서비스로 모놀리식 애플리케이션을 리팩터링합니다.

데이터 처리와 분석을 위해 컴퓨팅과 스토리지를 분리하는 서비스를 사용합니다.

기존 VM 워크로드를 관리형 서비스로 마이그레이션합니다.

일괄 워크로드의 탄소 배출량 감소

낮은 CO2 리전에서 리전 간 이그레스가 거의 또는 전혀 없는 일괄 워크로드를 실행합니다.

가능하면 낮은 그리드 탄소 강도와 일치하는 시간 동안 일괄 워크로드를 실행합니다.

다음 단계