Mengurangi jejak karbon Google Cloud Anda

Last reviewed 2021-10-11 UTC

Dokumen ini menjelaskan pendekatan Google Cloud terhadap keberlanjutan lingkungan. Panduan ini mencakup informasi dan resource lain yang dapat Anda gunakan untuk memahami jejak karbon Anda di Google Cloud, serta metode yang dapat Anda gunakan untuk mengurangi atau meminimalkan jejak karbon tersebut. Audiens yang dituju untuk dokumen ini mencakup:

  • Developer yang ingin mem-build aplikasi dengan jejak karbon minimal.
  • Tim infrastruktur dan tim teknis lainnya yang ingin memahami jejak karbon mereka saat ini dan mengidentifikasi peluang untuk mengurangi jejak karbon tersebut.

Dokumen ini mengasumsikan bahwa Anda sudah memahami Google Cloud dan menjalankan workload virtual machine (VM).

Memahami emisi karbon cloud

Google sudah mencapai 0 jejak karbon sejak 2007, dan telah berkomitmen untuk beroperasi pada 100% energi bebas karbon 24/7 pada 2030. Pusat data Google, termasuk yang menjalankan layanan Google Cloud, juga menggunakan energi yang jauh lebih sedikit daripada pusat data biasa. Karena alasan ini, penggunaan Google Cloud dapat membantu Anda mengurangi jejak karbon IT Anda saat ini.

Google mengoperasikan beberapa region cloud, yang dikirimkan melalui jaringan global pusat data. Pusat data ini menggunakan listrik yang dihasilkan oleh jaringan lokal untuk menjalankan layanan cloud. Dampak listrik terhadap lingkungan yang dihasilkan oleh jaringan listrik lokal diukur dengan intensitas karbon jaringannya. Intensitas karbon jaringan menunjukkan seberapa banyak karbon yang dipancarkan oleh pembangkit listrik yang menghasilkan listrik untuk jaringan.

Dampak terhadap lingkungan tidak sama di semua lokasi pusat data, karena beberapa faktor seperti perbedaan energi dan efisiensi produksi. Sejak tahun 2017, Google juga menghasilkan energi terbarukan yang setara dengan listrik yang digunakan secara global pada tahun yang sama, menggunakan perjanjian pembelian energy (PPA). PPA ini menghasilkan produksi energi bebas karbon yang disebabkan oleh Google, yang masuk ke jaringan tempat pusat data kami mengonsumsi listrik.

Dampak listrik yang dikonsumsi oleh pusat data Google terhadap lingkungan ditentukan oleh kombinasi intensitas karbon jaringan dan energi dari sumber energi bebas karbon yang diatribusikan dengan Google. Google memperkenalkan metrik persentase energi bebas karbon (CFE%), yang dihitung dari kedua elemen ini. CFE% menjelaskan rata-rata konsumsi energi bebas karbon per jam untuk setiap region, dan mewakili persentase waktu rata-rata saat aplikasi Anda dijalankan dengan energi bebas karbon. Karena suplai energi yang lebih bersih, region yang memiliki CFE% lebih tinggi menghasilkan emisi karbon yang lebih sedikit daripada region yang memiliki CFE% lebih rendah untuk beban kerja yang sama.

Untuk menurunkan emisi karbon, Anda perlu mengurangi konsumsi listrik beban kerja cloud Anda dari sumber berbasis karbon. Untuk menurunkan emisi karbon, sebaiknya gunakan strategi utama berikut:

  1. Pilih region cloud dengan CFE% per jam rata-rata yang lebih tinggi, dan intensitas karbon jaringan listrik yang lebih rendah. Untuk region yang memiliki CFE% yang sama, gunakan intensitas karbon jaringan untuk membandingkan lebih lanjut performa emisi di region tersebut.
  2. Optimalkan workload cloud untuk mengurangi emisi karbon. Misalnya, tingkatkan efisiensi dengan menggunakan layanan cloud yang elastis dan fitur fitur penskalaan otomatis untuk meminimalkan resource komputasi yang tidak digunakan, dan jalankan workload batch selama intensitas karbon jaringan lebih rendah.
  3. Tetapkan kebijakan organisasi untuk membatasi lokasi resource cloud ke region yang lebih bersih.

Memahami jejak karbon Anda

Google Cloud menyediakan Jejak Karbon, sebuah alat untuk membantu Anda memahami jejak karbon dari penggunaan Google Cloud Anda. Jejak Karbon memberikan total emisi berdasarkan intensitas karbon jaringan dari jaringan listrik lokal. Laporan tersebut lebih lanjut mengatribusikan emisi ke project Google Cloud yang Anda miliki dan layanan cloud yang Anda gunakan. Data emisi dilaporkan sesuai dengan metodologi pelaporan Jejak Karbon Google, dan dapat membantu dengan persyaratan pelaporan Protokol Cakupan 3 Standar Gas Rumah Kaca (GHG) sebagai pelanggan Google Cloud. Anda dapat mengekspor data Jejak Karbon ke BigQuery untuk analisis lebih lanjut.

Anda dapat menggunakan dasbor Jejak Karbon dan BigQuery Export untuk membantu Anda memahami emisi berbasis lokasi dari penggunaan layanan Google Cloud. Anda dapat menggunakan data ini untuk membandingkan jejak karbon dari berbagai layanan Google Cloud. Misalnya, untuk memahami emisi relatifnya, Anda dapat membandingkan total emisi dari dua atau beberapa layanan yang berjalan di region cloud yang sama.

Data emisi gas rumah kaca bruto khusus pelanggan Google Cloud yang diberikan oleh laporan Jejak Karbon belum diverifikasi atau dijamin oleh pihak ketiga.

Memilih region cloud yang paling sesuai

Memilih region cloud yang lebih bersih untuk menjalankan workload adalah salah satu cara paling sederhana dan paling efektif untuk mengurangi emisi karbon. Google memublikasikan data karbon untuk semua region cloud, termasuk CFE% dan intensitas karbon jaringan listrik dari jaringan listrik lokal. Untuk mengurangi keseluruhan emisi, sebaiknya pilih region dengan CFE% yang lebih tinggi jika memungkinkan. Untuk membantu Anda memilih region yang lebih bersih, Google Cloud menyertakan indikator Rendah CO2 on some of the location selectors of the di beberapa pemilih lokasi Konsol Google Cloud dan halaman "Lokasi" dalam dokumentasi Google Cloud. Untuk mengetahui informasi tentang kriteria yang harus dipenuhi suatu region agar dapat menerima indikator ini, lihat Energi bebas karbon untuk region Google Cloud.

Jika beberapa region memiliki CFE% yang serupa, bandingkan intensitas karbon jaringannya. Membandingkan intensitas karbon jaringan listrik di berbagai region juga penting jika Anda berfokus pada pengurangan emisi berbasis region. Misalnya, untuk skor CFE% yang serupa, jaringan dapat didukung oleh pembangkit listrik berbahan bakar batu bara atau pembangkit listrik bertenaga gas. Intensitas karbon jaringan mencerminkan campuran ini dan membantu Anda memilih jaringan penghasil karbon terendah.

Penurunan emisi mungkin merupakan salah satu dari banyak persyaratan yang perlu Anda seimbangkan saat memilih region. Misalnya, Anda mungkin perlu mempertimbangkan ketersediaan layanan Google Cloud tertentu, harga, persyaratan lokasi data, dan latensi penayangan kepada pengguna. Region dengan CFE% tertinggi secara keseluruhan mungkin tidak cocok untuk kasus penggunaan Anda. Untuk memastikan emisi terendah, pilih region yang memiliki CFE% tertinggi dan yang memenuhi semua persyaratan Anda.

Untuk menyederhanakan pemilihan region, gunakan Pemilih Region Google Cloud untuk menentukan region cloud terbaik yang memenuhi persyaratan Anda berdasarkan jejak karbon, harga, dan latensi. Untuk mengetahui informasi selengkapnya tentang Pemilih Region Google Cloud, lihat Memilih region Google Cloud yang tepat untuk Anda.

Jika organisasi Anda memberikan pilihan kepada pengguna terkait region cloud yang akan digunakan, Anda juga dapat mempertimbangkan untuk menetapkan kebijakan organisasi untuk membatasi lokasi ke region Rendah CO2.

Memilih layanan cloud yang paling sesuai

Google Cloud menawarkan berbagai layanan cloud yang cocok dengan berbagai workload IT. Untuk membantu mengurangi jejak karbon yang ada, pertimbangkan untuk memigrasikan workload VM ke Compute Engine dari infrastruktur yang kurang hemat energi, seperti pusat data lokal. Untuk mengetahui informasi tentang cara memigrasikan VM ke Google Cloud dari pusat data lokal dan berbagai lingkungan cloud, lihat Perjalanan migrasi dengan Migrate to Virtual Machines.

Banyak workload tidak memerlukan VM, dan Anda dapat men-deploy-nya ke layanan lain yang terkelola sepenuhnya yang ditujukan untuk berbagai jenis workload. Layanan ini sering kali memiliki fitur penskalaan otomatis dan penyesuaian ukuran bawaan yang membantu mengoptimalkan performa dan penggunaan resource untuk Anda. Misalnya, Cloud Run adalah lingkungan yang sepenuhnya serverless yang menskalakan aplikasi dalam container lebih cepat dan dengan resource nonaktif yang lebih sedikit dibandingkan dengan menjalankan stack aplikasi yang sebanding pada VM. Memiliki lebih sedikit resource nonaktif akan mengakibatkan biaya yang optimal dan pengurangan jejak karbon.

Pertimbangkan penawaran berikut untuk jenis workload umum. Daftar layanan ini tidak lengkap, tetapi menjelaskan cara berbagai layanan terkelola dapat mengoptimalkan penggunaan resource cloud (sering kali secara otomatis), yang pada saat yang bersamaan mengurangi biaya cloud dan jejak karbon.

  • Cloud Run: penawaran serverless untuk menjalankan aplikasi dalam container, yang ditulis dalam bahasa pilihan Anda. Layanan ini memiliki penskalaan otomatis yang cepat terhadap aplikasi Anda dari nol hingga N instance container, bergantung pada traffic. Jika tidak ada traffic, aplikasi Anda tidak akan menggunakan resource komputasi untuk pelayanan. Layanan ini dirancang untuk menangani pola traffic yang tidak teratur dan mengoptimalkan penggunaan resource komputasi Anda sesuai kebutuhan.
  • Cloud Functions: penawaran functions-as-a-service (FaaS) serverless. Platform ini berjalan di infrastruktur yang sama dengan Cloud Run dan App Engine, yang memperluas fungsionalitas penskalaan otomatis yang cepat dan berskala dari nol yang sama ke Cloud Functions.
  • Google Kubernetes Engine (GKE): layanan cloud yang menyediakan lingkungan Kubernetes terkelola. Dibandingkan dengan penggunaan VM langsung, menjalankan workload dalam container menggunakan lingkungan Kubernetes di GKE dapat meminimalkan resource cloud yang tidak digunakan, sehingga mengakibatkan penurunan biaya cloud dan jejak karbon yang lebih kecil untuk workload Anda.
  • BigQuery: cloud data warehouse serverless yang mendukung pembuatan kueri set data berskala petabyte yang besar. Dengan mendukung banyak pengguna di infrastruktur besar dan multi-tenant, BigQuery memanfaatkan resource komputasi secara efisien melalui skala ekonomi yang sangat besar. Arsitektur BigQuery memisahkan penyimpanan dan komputasi, yang mengalokasikan resource komputasi secara efisien untuk menskalakan penyimpanan data secara terpisah dari eksekusi kueri. BigQuery secara dinamis menetapkan resource komputasi (yang disebut slot) sesuai kebutuhan untuk menjalankan kueri. Penjadwalan wajar akan secara otomatis mengalokasikan ulang kapasitas slot di berbagai project dan menjalankan kueri sesuai kebutuhan.

Anda mungkin memiliki workload lain yang masih memerlukan VM. Saat VM diperlukan, hindari penyediaan yang berlebihan di luar yang Anda butuhkan dan hindari menjalankan resource yang tidak digunakan, yang dapat menyebabkan peningkatan biaya dan emisi.

Meminimalkan resource cloud yang tidak ada aktivitas

Anda mungkin mengamati bahwa praktik pengoptimalan biaya yang mengurangi penggunaan resource cloud yang tidak ada aktivitas (atau tidak efisien) juga berdampak baik pada pengurangan jejak karbon. Resource yang tidak ada aktivitas menimbulkan pemborosan dengan menimbulkan biaya dan emisi yang tidak diperlukan. Pertimbangkan bentuk resource yang tidak digunakan berikut:

  1. Resource cloud aktif yang tidak digunakan, misalnya instance VM yang tidak dihentikan saat workload telah selesai.
  2. Resource yang disediakan berlebihan, misalnya menggunakan lebih banyak VM atau jenis mesin VM yang lebih besar dari yang diperlukan workload.
  3. Arsitektur atau alur kerja yang tidak optimal, misalnya aplikasi lift-and-shift yang dimigrasikan ke (tetapi tidak dioptimalkan untuk) cloud, atau infrastruktur penyimpanan dan komputasi yang tidak terpisah untuk workload pemrosesan data dan analisis.

Resource VM yang tidak digunakan dan yang disediakan secara berlebihan biasanya memiliki dampak paling signifikan terhadap biaya yang tidak perlu dan peningkatan jejak karbon. Untuk meminimalkan jejak karbon, pertimbangkan cara untuk meminimalkan kapasitas VM yang tidak ada aktivitas dan resource cloud lain yang tidak digunakan melalui proses otomatisasi, pemantauan, dan pengoptimalan workload Anda. Topik-topik tersebut berada di luar cakupan dokumen ini; tetapi, ada beberapa praktik sederhana yang dapat memiliki dampak besar terhadap biaya dan jejak karbon Anda. Beberapa praktik ini diaktifkan oleh Active Assist, solusi yang memberikan jenis rekomendasi otomatis untuk mengoptimalkan penggunaan cloud Anda sebagai berikut:

  1. Mengidentifikasi dan menghapus resource VM nonaktif: Secara rutin periksa rekomendasi resource nonaktif, seperti disk yang tidak digunakan, di Konsol Google Cloud. Anda juga dapat melihat rekomendasi resource nonaktif dengan menggunakan gcloud CLI atau API. Setelah memastikan bahwa resource nonaktif tidak lagi diperlukan, Anda dapat menghapusnya untuk menghemat biaya dan emisi.
  2. Menyesuaikan ukuran instance VM: Sesuaikan ukuran VM secara optimal sesuai penggunaan resource dengan memeriksa rekomendasi penyesuaian secara rutin di Konsol Google Cloud. penyesuaian ukuran dapat membantu mengatasi pemborosan karena penyediaan yang berlebihan. Rekomendasi penyesuaian ukuran juga dapat dilihat menggunakan gcloud CLI atau API.
  3. Mengidentifikasi dan menghapus VM nonaktif: Gunakan pemberi rekomendasi VM nonaktif untuk membantu mengidentifikasi instance VM yang belum digunakan. Anda dapat menghapus VM yang tidak ada aktivitas setelah memastikan VM tersebut tidak diperlukan lagi.
  4. Dapatkan kembali atau hapus project tanpa pengawasan: Gunakan pemberi rekomendasi project tanpa pengawasan untuk membantu menemukan projects tanpa pengawasan dengan penggunaan rendah atau tanpa penggunaan sama sekali, dan jika memungkinkan matikan proyek-proyek ini.
  5. Menjadwalkan VM untuk dijalankan saat diperlukan: Jika VM hanya diperlukan pada waktu tertentu, pertimbangkan untuk menjadwalkan instance VM agar dimulai dan dihentikan secara otomatis.
  6. Memperbaiki instance Cloud SQL yang tidak ada aktivitas dan yang disediakan berlebihan: Gunakan Active Assist untuk mengidentifikasi instance Cloud SQL untuk MySQL, PostgresSQL, dan SQL Server yang disediakan secara berlebihandan tidak ada aktivitas. Setelah teridentifikasi, Anda dapat mengubah ukuran atau menghapus instance tersebut.

Arsitektur yang tidak optimal menyebabkan penggunaan resource cloud yang kurang efisien. Meskipun masalah arsitektur dapat terjadi pada aplikasi yang di-build untuk cloud, masalah ini paling sering terjadi pada workload lokal. Misalnya aplikasi monolitik yang dimigrasikan ke Google Cloud, tanpa atau dengan pengoptimalan minimal (umumnya disebut sebagai lift-and-shift). Praktik berikut dapat membantu Anda mengoptimalkan arsitektur:

  1. Membuat resource saat dibutuhkan: Meskipun resource cloud elastis, Anda akan mendapatkan manfaat efisiensi yang terbatas jika workload di-deploy ke resource tetap yang berjalan terus-menerus, terlepas dari penggunaan sebenarnya. Identifikasi peluang untuk membuat (dan menghapus) resource sesuai kebutuhan, seperti menggunakan penjadwalan VM atau fitur elastis dalam layanan cloud. Penggunaan fitur yang elastis mencakup penggunaan Compute Engine untuk menskalakan otomatis VM yang menjalankan server web stateless, atau penggunaan Dataflow untuk menskalakan pekerja secara otomatis untuk pipeline data streaming.
  2. Memasukkan workload dalam container: Pertimbangkan untuk mengemas workload Anda ke dalam container, dan gunakan orkestrator container seperti Google Kubernetes Engine (GKE) untuk menjalankan container secara efisien. Saat menggunakan GKE, Anda dapat menjadwalkan container secara efisien di seluruh cluster VM berdasarkan persyaratan sumber dayanya. Beberapa container juga dapat berbagi resource dari satu VM, jika persyaratan sumber dayanya memungkinkan.

Migrate for GKE and GKE Enterprise menyediakan jalur yang disederhanakan untuk migrasi workload dari VM ke container. Memigrasikan VM ke container dapat menjadi langkah pertama untuk menuju modernisasi aplikasi. Langkah-langkah selanjutnya dapat melibatkan praktik pengoptimalan biaya yang juga mengurangi emisi, dan memfaktorkan ulang aplikasi ke dalam microservice.

Jika Anda membutuhkan fleksibilitas konfigurasi dan kontrol penuh atas orkestrasi container, pertimbangkan untuk menggunakan GKE. Jika Anda perlu menjalankan aplikasi web atau microservice dalam container, dan jika tidak memerlukan lingkungan Kubernetes lengkap, pertimbangkan untuk menggunakan Cloud Run. Cloud Run meringkas kompleksitas container yang berjalan, dan berfokus pada penyediaan pengalaman yang lebih baik bagi developer. Untuk perbandingan yang lebih mendetail, lihat Google Kubernetes Engine vs Cloud Run.

  1. Memfaktorkan ulang aplikasi monolitik menjadi microservice: Aplikasi monolitik menggabungkan semua modulnya ke dalam satu program sehingga mempersulit alokasi resource untuk menjalankan modul tertentu. Oleh karena itu, aplikasi monolitik mungkin akan sulit dijalankan dan diskalakan secara efisien, sehingga mungkin memiliki jejak karbon yang lebih besar dibandingkan dengan implementasi berbasis microservice.

    Pertimbangkan situs e-commerce monolitik yang memiliki layanan keranjang belanja dan layanan pembayaran. Pengguna mungkin berinteraksi dengan layanan keranjang belanja beberapa kali dalam satu sesi, dan berinteraksi dengan layanan pembayaran hanya di akhir sesi. Kedua layanan ini memiliki persyaratan sumber daya yang berbeda karena karakteristik traffic dan beban yang berbeda, tetapi keduanya tidak dapat dijalankan secara terpisah karena keduanya merupakan bagian dari aplikasi monolitik yang sama. Jika monolit berjalan pada VM, setiap VM tambahan akan menambahkan resource komputasi untuk menjalankan kedua layanan, meskipun hanya satu layanan yang perlu meningkatkan kapasitas pelayanan.

    Berbeda dengan monolit, microservice memisahkan modul aplikasi ke dalam program ringannya sendiri yang diintegrasikan menggunakan panggilan jaringan. Microservice dapat diskalakan secara terpisah satu sama lain dan menggunakan berbagai bentuk resource (misalnya, jenis mesin VM, vCPU dan alokasi memori Cloud Run, atau jenis instance App Engine) yang cocok untuk menjalankan layanan tersebut. Penskalaan microservice menghasilkan penggunaan resource cloud yang lebih efisien melalui penskalaan terperinci dan penurunan penyediaan yang berlebihan, sehingga biaya dan emisi menjadi lebih rendah. Untuk mengetahui informasi selengkapnya, lihat Memfaktorkan ulang monolit menjadi microservice.

  2. Gunakan layanan cloud yang memisahkan resource penyimpanan dan komputasi: Beberapa workload analisis dan pemrosesan data lokal (dan berbasis cloud), seperti Apache Hadoop dan Apache Spark, sering kali berbagi infrastruktur yang sama untuk penyimpanan dan komputasi data. Jika Anda mempertahankan jejak infrastruktur yang besar untuk menyimpan data, meskipun Anda harus mengubah ukuran jejak yang sama untuk persyaratan komputasi puncak, maka pemanfaatan resource komputasi sering kali rendah. Pemakaian yang rendah menyebabkan lebih banyak resource yang tidak ada aktivitas, sehingga meningkatkan biaya dan menghasilkan lebih banyak emisi yang tidak perlu.

    Saat Anda memigrasikan workload ini ke Google Cloud, sebaiknya gunakan layanan terkelola yang memisahkan infrastruktur penyimpanan dan komputasi, seperti berikut:

    • BigQuery: adalah data warehouse serverless dan berskala petabyte sebagai layanan. Anda dapat menggunakan BigQuery untuk workload analisis berbasis SQL. Penyimpanan set data dalam BigQuery dipisahkan dari resource komputasi. Pemisahan ini berarti penyimpanan BigQuery diskalakan untuk menyediakan penyimpanan yang hampir tanpa batas dengan menggunakan resource secara efisien. Ini juga berarti bahwa set data dapat dibagikan di tempatnya tanpa menduplikasi data atau membuat cluster baru.
    • Dataproc: Dataproc adalah layanan terkelola untuk workload Hadoop dan Spark. Banyak deployment Hadoop dan Spark lokal menggunakan cluster komputasi yang selalu aktif, terlepas dari karakteristik penggunaan. Meskipun Anda dapat membuat cluster berumur panjang menggunakan Dataproc, sebaiknya Anda membuat cluster sementara saat Anda perlu menjalankan tugas. Data yang dibaca atau ditulis oleh tugas Dataproc dikelola secara terpisah dalam layanan penyimpanan khusus, seperti Cloud Storage dan Bigtable. Dengan meniadakan kebutuhan mengelola lingkungan untuk penyimpanan Hadoop, meskipun tidak ada tugas yang berjalan, Anda dapat mengurangi kompleksitas, biaya, dan emisi operasional.
    • Spanner: Spanner adalah layanan database SQL yang terdistribusi dan skalabel secara global, yang memisahkan komputasi dari penyimpanan, sehingga memungkinkan penskalaan resource ini secara terpisah. Anda juga dapat secara otomatis menskalakan jumlah node resource komputasi untuk instance Spanner menggunakan alat Autoscaler. Dengan menggunakan deployment Spanner penskalaan otomatis, infrastruktur Anda dapat otomatis beradaptasi dan diskalakan untuk memenuhi persyaratan beban, serta membantu mengurangi biaya dan emisi karbon saat beban rendah.
  3. Memigrasikan workload ke layanan terkelola: Penawaran terkelola dapat meminimalkan resource yang tidak digunakan dengan menskalakan workload secara otomatis, dan menawarkan fitur lain yang dapat mengurangi persyaratan infrastruktur Anda. Untuk mengetahui informasi selengkapnya, lihat Memilih layanan cloud yang paling sesuai di awal dokumen ini.

Mengurangi emisi untuk workload batch

Berbeda dengan banyak workload pelayanan online, workload batch sering kali fleksibel dalam hal dimana dan kapan dijalankan. Contoh workload batch mencakup tugas komputasi berperforma tinggi (HPC) untuk kalkulasi ilmiah, menjalankan rekonsiliasi akun harian, atau membuat rekomendasi produk untuk email pemasaran.

Serupa dengan workload lain, sebaiknya jalankan workload batch di region dengan CFE% lebih tinggi untuk menurunkan keseluruhan jejak karbon Anda. Jika ada fleksibilitas terkait kapan tugas batch harus dijalankan, Anda mungkin dapat lebih mengurangi jejak karbon dengan menjalankan tugas pada waktu yang bertepatan dengan intensitas karbon jaringan lebih rendah. Untuk melihat data intensitas karbon campuran jaringan per jam di berbagai lokasi global tempat region Google Cloud berada, gunakan situs electricityMap, yang dikelola oleh Tomorrow.

Berdasarkan definisi, workload batch seharusnya tidak sensitif terhadap latensi, meskipun mungkin ada dependensi pada sistem terkait (seperti sumber data dan sink) yang menghasilkan overhead jaringan yang tidak diinginkan. Dependensi ini mungkin ada untuk tugas yang merupakan bagian dari aplikasi atau alur kerja yang lebih besar, misalnya tugas Ekstraksi, Transformasi, dan Pemuatan (ETL) yang membaca data dari satu sistem sumber atau lebih, dan kemudian menulis data yang telah diubah ke data warehouse. Jika tugas ETL memproses dan mentransfer data dalam jumlah besar antar-region cloud, mungkin tidak praktis atau mahal untuk menjalankan tugas secara terpisah karena dampak performa jaringan dan peningkatan biaya traffic keluar lintas region.

Sebaiknya jalankan jenis workload batch berikut di region Rendah CO2:

  1. Workload batch mandiri: Pertimbangkan workload HPC mandiri saat Anda memilih region dengan karakteristik harga dan emisi terbaik untuk kebutuhan Anda, gunakan penyimpanan dan layanan komputasi di region tersebut, dan download hasil analisis secara langsung. Dalam skenario ini, tidak ada traffic lintas region yang dapat menyebabkan penalti performa jaringan atau biaya traffic keluar jaringan selain mengambil hasil analisis.
  2. Workload batch yang memerlukan transfer data minimal dengan region cloud lain: Pertimbangkan API yang menyalurkan rekomendasi produk dari model machine learning (ML). API mungkin dihosting di beberapa region cloud untuk layanan berlatensi rendah kepada pengguna. Model ML dapat dilatih secara berkala dari data clickstream dari browser sebagai proses batch terpusat, dan disalin ke setiap region cloud tempat API dihosting. Dalam skenario ini, artefak model output dari tugas pelatihan berukuran kecil, mungkin berukuran puluhan megabyte.

    Dalam skenario ini, data clickstream untuk melatih model ML dikirim langsung dari browser ke region cloud yang menghosting backend ML. Ketika backend ML melatih sekumpulan model baru, transfer data untuk menyalin model ke region cloud lain relatif kecil (mungkin hanya seratus megabyte jika sepuluh model perlu disalin).

Rekomendasi

Tabel berikut merangkum rekomendasi untuk mengurangi jejak karbon Google Cloud Anda:

Topik Rekomendasi
Memahami emisi karbon cloud

Pahami cara persentase energi bebas karbon (CFE%) menjelaskan konsumsi energi bebas karbon dari region cloud.

Memahami strategi utama untuk mengurangi jejak karbon Anda.

Memahami jejak karbon Anda Gunakan alat Jejak Karbon untuk membantu Anda memahami jejak karbon dari penggunaan Google Cloud.
Memilih region cloud yang paling sesuai

Gunakan Pemilih Region Google Cloud untuk menentukan region cloud terbaik berdasarkan jejak karbon, harga, dan latensi sebagai pertimbangan relatif.

Pertimbangkan untuk membuat kebijakan organisasi untuk membatasi penggunaan ke region Rendah CO2.

Memilih layanan cloud yang paling sesuai

Migrasikan VM dari pusat data lokal yang kurang efisien ke Compute Engine.

Gunakan layanan terkelola cloud yang dioptimalkan untuk workload tertentu, bukan VM yang dikelola sendiri.

Meminimalkan resource cloud yang tidak digunakan

Gunakan fitur Active Assist untuk menghapus VM yang tidak digunakan, mengoptimalkan bentuk VM, dan mematikan project tanpa pengawasan.

Mengidentifikasi peluang untuk membuat (dan menghapus) resource cloud sesuai kebutuhan, bukan menyimpannya secara permanen.

Jadwalkan VM untuk dimulai dan dihentikan sesuai waktu yang diperlukan.

Migrasikan workload ke container, lalu jalankan secara efisien menggunakan layanan terkelola seperti Cloud Run dan GKE.

Faktorkan ulang aplikasi monolitik ke microservice untuk mendapatkan manfaat efisiensi.

Gunakan layanan yang memisahkan komputasi dan penyimpanan untuk pemrosesan dan analisis data.

Memigrasikan workload VM yang ada ke layanan terkelola.

Mengurangi emisi untuk workload batch

Jalankan workload batch yang memiliki minimal atau tidak ada traffic keluar lintas region di region CO2 yang rendah.

Jalankan workload batch pada saat yang bertepatan dengan intensitas karbon jaringan lebih rendah jika memungkinkan.

Langkah selanjutnya