Framework Arsitektur Google Cloud

Last reviewed 2023-11-09 UTC

Anda dapat mencetak halaman ini atau menyimpan halaman dalam format PDF menggunakan fungsi cetak browser Anda dan memilih opsi Simpan sebagai PDF. Untuk versi standar halaman ini, kembali ke Framework Arsitektur.

Framework Arsitektur Google Cloud memberikan rekomendasi dan menjelaskan praktik terbaik untuk membantu arsitek, developer, administrator, dan praktisi cloud lainnya dalam mendesain dan mengoperasikan topologi cloud yang aman, efisien, tangguh, berperforma tinggi, dan hemat biaya. Framework Arsitektur Google Cloud adalah versi framework kami yang dirancang dengan baik.

Tim pakar lintas fungsi di Google memvalidasi rekomendasi desain dan praktik terbaik yang membentuk Framework Arsitektur. Tim menyeleksi Framework Arsitektur untuk mencerminkan kemampuan Google Cloud yang terus berkembang, praktik terbaik industri, pengetahuan komunitas, dan masukan dari Anda. Untuk ringkasan perubahan yang signifikan, lihat Apa yang baru.

Panduan desain dalam Framework Arsitektur berlaku pada aplikasi yang dibangun untuk cloud dan untuk workload yang dimigrasikan dari lokal ke Google Cloud, deployment hybrid cloud, dan lingkungan multi-cloud.

Framework Arsitektur Google Cloud disusun ke dalam enam kategori (juga dikenal sebagai pilar), seperti yang ditunjukkan dalam diagram berikut:

Desain sistem

Kategori ini adalah dasar dari Framework Arsitektur Google Cloud. Tentukan arsitektur, komponen, modul, antarmuka, dan data yang diperlukan untuk memenuhi persyaratan sistem cloud, serta pelajari produk dan fitur Google Cloud dan mendukung desain sistem.

Keunggulan operasional

Deploy, operasikan, pantau, dan kelola beban kerja cloud Anda secara efisien.

Keamanan, privasi, dan kepatuhan

Maksimalkan keamanan data dan beban kerja Anda di cloud, buat desain yang menjaga privasi, dan sesuaikan dengan persyaratan serta standar peraturan.

Keandalan

Rancang dan operasikan beban kerja yang tangguh dan sangat tersedia di cloud.

Pengoptimalan biaya

Maksimalkan nilai bisnis dari investasi Anda di Google Cloud.

Pengoptimalan Performa

Rancang dan sesuaikan resource cloud Anda untuk performa yang optimal.

Untuk melihat ringkasan produk Google Cloud dan kaitannya satu sama lain, lihat produk, fitur, dan layanan Google Cloud dalam empat kata atau kurang.

Framework Arsitektur Google Cloud: Desain sistem

Desain sistem adalah kategori dasar Framework Arsitektur Google Cloud. Kategori ini menyediakan rekomendasi desain serta menjelaskan praktik terbaik dan prinsip untuk membantu Anda menentukan arsitektur, komponen, modul, antarmuka, dan data di platform cloud untuk memenuhi persyaratan sistem Anda. Anda juga akan mempelajari produk dan fitur Google Cloud yang mendukung desain sistem.

Dokumen dalam kategori desain sistem ini mengasumsikan bahwa Anda memahami prinsip-prinsip desain sistem dasar. Dokumen ini tidak mengasumsikan bahwa Anda sudah memahami konsep cloud dan produk Google Cloud.

Untuk skenario migrasi dan deployment cloud yang kompleks, sebaiknya gunakan layanan konsultasi Google Cloud. Konsultan kami memberikan keahlian tentang praktik terbaik dan prinsip panduan untuk membantu Anda meraih kesuksesan dalam perjalanan cloud Anda. Google Cloud juga memiliki ekosistem partners yang kuat, mulai dari integrator sistem global yang besar hingga partner dengan spesialisasi mendalam di bidang tertentu seperti machine learning. Sebaiknya libatkan partner Google Cloud untuk mempercepat transformasi digital dan meningkatkan hasil bisnis Anda.

Catatan: Sebelum mengubah lingkungan produksi, sebaiknya Anda bereksperimen dengan fitur atau desain baru di lingkungan sandbox.

Dalam kategori desain sistem Framework Arsitektur, Anda akan mempelajari cara melakukan hal berikut:

• Menerapkan prinsip inti desain sistem.
• Memilih region geografis untuk mendukung aplikasi bisnis Anda.
• Mengelola resource cloud.
• Memilih dan mengelola komputasi.
• Mendesain infrastruktur jaringan.
• Memilih dan menerapkan strategi penyimpanan.
• Mengoptimalkan database.
• Menganalisis data Anda.
• Mengimplementasikan machine learning.
• Mendesain workload cloud Anda untuk keberlanjutan.

Prinsip inti desain sistem

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan prinsip-prinsip inti desain sistem. Desain sistem yang tangguh harus aman, andal, skalabel, dan independen. Dengan begitu, Anda dapat membuat perubahan yang iteratif dan dapat diurungkan tanpa mengganggu sistem, meminimalkan potensi risiko, dan meningkatkan efisiensi operasional. Untuk mencapai desain sistem yang tangguh, sebaiknya Anda mengikuti empat prinsip inti.

Dokumentasikan semuanya

Saat Anda mulai memindahkan workload ke cloud atau membangun aplikasi, hambatan utama keberhasilan Anda adalah kurangnya dokumentasi sistem. Dokumentasi sangat penting untuk memvisualisasikan arsitektur deployment Anda saat ini dengan benar.

Arsitektur cloud yang didokumentasikan dengan baik membentuk bahasa dan standar yang sama, sehingga tim lintas fungsi dapat berkomunikasi dan berkolaborasi secara efektif. Bagian ini juga memberikan informasi yang diperlukan untuk mengidentifikasi dan memandu keputusan desain di masa mendatang. Dokumentasi harus ditulis dengan mempertimbangkan kasus penggunaan Anda, untuk memberikan konteks pada keputusan desain.

Seiring waktu, keputusan desain Anda akan berkembang dan berubah. Histori perubahan memberikan konteks yang diperlukan tim Anda untuk menyelaraskan inisiatif, menghindari duplikasi, dan mengukur perubahan performa secara efektif dari waktu ke waktu. Log perubahan sangat berharga saat Anda mengorientasi arsitek cloud baru yang belum memahami desain sistem, strategi, atau histori Anda saat ini.

Menyederhanakan desain Anda dan menggunakan layanan terkelola sepenuhnya

Kesederhanaan sangat penting untuk desain sistem. Jika arsitektur Anda terlalu rumit untuk dipahami, akan sulit untuk menerapkan desain dan mengelolanya seiring waktu. Jika memungkinkan, gunakan layanan terkelola sepenuhnya untuk meminimalkan risiko, waktu, dan upaya yang terkait dengan pengelolaan dan pemeliharaan sistem dasar pengukuran.

Jika Anda sudah menjalankan workload dalam produksi, lakukan pengujian dengan layanan terkelola untuk melihat bagaimana layanan tersebut dapat membantu mengurangi kompleksitas operasional. Jika Anda mengembangkan workload baru, mulailah dengan yang sederhana, buat produk dengan kelayakan minimal (MVP), dan tahan keinginan untuk merekayasa secara berlebihan. Anda dapat mengidentifikasi kasus penggunaan yang luar biasa, melakukan iterasi, dan meningkatkan sistem secara bertahap dari waktu ke waktu.

Pisahkan arsitektur Anda

Pemisahan adalah teknik yang digunakan untuk memisahkan aplikasi dan komponen layanan Anda menjadi komponen yang lebih kecil yang dapat beroperasi secara independen. Misalnya, Anda dapat memecah stack aplikasi monolitik menjadi komponen layanan yang terpisah. Dalam arsitektur yang dipisahkan, aplikasi dapat menjalankan fungsinya secara independen, terlepas dari berbagai dependensi.

Arsitektur yang dipisahkan memberi Anda peningkatan fleksibilitas untuk melakukan hal berikut:

• Menerapkan upgrade independen.
• Menerapkan kontrol keamanan tertentu.
• Menetapkan tujuan keandalan untuk setiap subsistem.
• Memantau kondisi.
• Mengontrol performa dan parameter biaya secara terperinci.

Anda dapat memulai pemisahan di awal fase desain atau menyertakannya sebagai bagian dari upgrade sistem seiring berubahnya skala sistem.

Menggunakan arsitektur stateless

Arsitektur stateless dapat meningkatkan keandalan dan skalabilitas aplikasi Anda.

Aplikasi stateful mengandalkan berbagai dependensi untuk melakukan tugas, seperti data yang di-cache secara lokal. Aplikasi stateful sering kali memerlukan mekanisme tambahan untuk menangkap progres dan memulai ulang dengan lancar. Aplikasi stateless dapat melakukan tugas tanpa dependensi lokal yang signifikan menggunakan penyimpanan bersama atau layanan yang di-cache. Arsitektur stateless memungkinkan aplikasi Anda melakukan peningkatan skala dengan cepat dengan dependensi booting minimum. Aplikasi tersebut dapat bertahan saat mulai ulang keras, memiliki periode nonaktif yang lebih rendah, dan memberikan performa yang lebih baik untuk pengguna akhir.

Kategori desain sistem menjelaskan rekomendasi untuk membuat aplikasi Anda stateless atau memanfaatkan fitur berbasis cloud guna meningkatkan pencatatan status mesin untuk aplikasi stateful Anda.

Langkah selanjutnya

• Memilih region geografis untuk mendukung aplikasi bisnis Anda.
• Mengelola resource cloud.
• Memilih dan mengelola komputasi.
• Mendesain infrastruktur jaringan.
• Memilih dan menerapkan strategi penyimpanan.
• Mengoptimalkan database.
• Menganalisis data Anda.
• Mengimplementasikan machine learning.
• Mendesain workload cloud Anda untuk keberlanjutan.

Pilih arketipe deployment Google Cloud

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan enam arketipe deployment¹—zona, regional, multi-regional, global, hybrid, dan multicloud—yang dapat Anda gunakan untuk membangun arsitektur untuk workload cloud Anda berdasarkan persyaratan ketersediaan, biaya, performa, dan efisiensi operasional.

Apa itu arketipe deployment?

Arketipe deployment adalah model abstrak yang tidak bergantung pada penyedia yang Anda gunakan sebagai dasar untuk membangun arsitektur deployment khusus aplikasi yang memenuhi persyaratan bisnis dan teknis Anda. Setiap arketipe deployment menentukan kombinasi domain gagal tempat aplikasi dapat berjalan. Domain kegagalan ini dapat berupa satu atau beberapa zona atau region Google Cloud, dan dapat diperluas untuk menyertakan pusat data lokal Anda atau domain kegagalan di penyedia cloud lainnya.

Diagram berikut menunjukkan enam aplikasi yang di-deploy di Google Cloud. Setiap aplikasi menggunakan arketipe deployment yang memenuhi persyaratan khususnya.

Seperti yang ditunjukkan diagram sebelumnya, dalam arsitektur yang menggunakan arketipe deployment hybrid atau multicloud, topologi cloud didasarkan pada salah satu arketipe dasar: zonal, regional, multi-regional, atau global. Dalam hal ini, arketipe deployment hybrid dan multicloud dapat dianggap sebagai arketipe deployment komposit yang mencakup salah satu arketipe dasar.

Catatan: Arketipe deployment berbeda dengan cakupan lokasi. Cakupan lokasi resource Google Cloud menentukan batas ketersediaannya. Misalnya, cakupan lokasi VM Compute Engine bersifat zona. Artinya, jika zona Google Cloud tempat VM disediakan mengalami gangguan, ketersediaan VM tersebut akan terpengaruh. Namun, dengan mendistribusikan VM di beberapa zona, Anda dapat membangun arsitektur yang sangat tersedia berdasarkan arketipe deployment regional.

Memilih arketipe deployment akan membantu memudahkan Anda dalam mengambil keputusan selanjutnya terkait produk dan fitur Google Cloud yang harus digunakan. Misalnya, untuk aplikasi dalam container yang sangat tersedia, jika Anda memilih arketipe deployment regional, cluster Google Kubernetes Engine (GKE) regional lebih tepat daripada cluster GKE zona.

Saat memilih arketipe deployment untuk aplikasi, Anda perlu mempertimbangkan keseimbangan antara faktor seperti ketersediaan, biaya, dan kompleksitas operasional. Misalnya, jika aplikasi melayani pengguna di beberapa negara dan memerlukan ketersediaan tinggi, Anda dapat memilih arketipe deployment multi-regional. Namun, untuk aplikasi internal yang digunakan oleh karyawan di satu wilayah geografis, Anda dapat memprioritaskan biaya daripada ketersediaan, sehingga memilih arketipe deployment regional.

Ringkasan arketipe deployment

Tab berikut memberikan definisi untuk arketipe deployment serta ringkasan kasus penggunaan dan pertimbangan desain untuk setiap arketipe.

Zonal

Aplikasi Anda berjalan dalam satu zona Google Cloud, seperti yang ditunjukkan pada diagram berikut:

Kasus penggunaan	Lingkungan pengembangan dan pengujian. Aplikasi yang tidak memerlukan ketersediaan tinggi. Networking berlatensi rendah antar-komponen aplikasi. Memigrasikan workload komoditas. Aplikasi yang menggunakan software yang dibatasi lisensi.
Pertimbangan desain	Periode nonaktif selama pemadaman zona. Untuk kelangsungan bisnis, Anda dapat menyediakan replika pasif aplikasi di zona lain dalam region yang sama. Jika terjadi pemadaman zona, Anda dapat memulihkan aplikasi ke produksi menggunakan replika pasif.
Informasi selengkapnya	Lihat bagian berikut: Arketipe deployment zona Analisis komparatif semua arketipe deployment

Regional

Aplikasi Anda berjalan secara independen di dua zona atau lebih dalam satu region Google Cloud, seperti yang ditunjukkan dalam diagram berikut:

Kasus penggunaan	Aplikasi yang sangat tersedia yang melayani pengguna di area geografis. Kepatuhan terhadap persyaratan residensi dan kedaulatan data.
Pertimbangan desain	Periode nonaktif selama pemadaman layanan region. Untuk kelangsungan bisnis, Anda dapat mencadangkan aplikasi dan data ke region lain. Jika terjadi pemadaman layanan region, Anda dapat menggunakan cadangan di region lain untuk memulihkan aplikasi ke produksi. Biaya dan upaya untuk menyediakan dan mengelola resource yang redundan.
Informasi selengkapnya	Lihat bagian berikut: Arketipe deployment regional Analisis komparatif semua arketipe deployment

Multi-regional

Aplikasi Anda berjalan secara independen di beberapa zona di dua region Google Cloud atau lebih. Anda dapat menggunakan kebijakan perutean DNS untuk merutekan traffic masuk ke load balancer regional. Selanjutnya, load balancer regional mendistribusikan traffic ke replika zona aplikasi, seperti yang ditunjukkan dalam diagram berikut:

Kasus penggunaan	Aplikasi yang sangat tersedia dengan pengguna yang tersebar secara geografis. Aplikasi yang memerlukan pengalaman latensi pengguna akhir rendah. Kepatuhan terhadap persyaratan residensi dan kedaulatan data dengan menggunakan kebijakan perutean DNS yang dibatasi wilayah.
Pertimbangan desain	Biaya untuk transfer data lintas region dan replikasi data. Kompleksitas operasional.
Informasi selengkapnya	Lihat bagian berikut: Arketipe deployment multiregional Analisis komparatif semua arketipe deployment

Global

Aplikasi Anda berjalan di seluruh region Google Cloud di seluruh dunia, baik sebagai stack yang terdistribusi secara global (tidak mengetahui lokasi) atau sebagai stack yang terisolasi secara regional. Load balancer anycast global mendistribusikan traffic ke region yang paling dekat dengan pengguna. Komponen lain dari stack aplikasi juga dapat bersifat global, seperti database, cache, dan penyimpanan objek.

Diagram berikut menunjukkan varian arketipe deployment global yang terdistribusi secara global. Load balancer anycast global meneruskan permintaan ke stack aplikasi yang didistribusikan di beberapa region dan yang menggunakan database yang direplikasi secara global.

Diagram berikut menunjukkan varian arketipe deployment global dengan stack aplikasi yang diisolasi secara regional. Load balancer anycast global meneruskan permintaan ke stack aplikasi di salah satu region. Semua stack aplikasi menggunakan satu database yang direplikasi secara global.

Kasus penggunaan	Aplikasi yang sangat tersedia dan melayani pengguna yang tersebar secara global. Peluang untuk mengoptimalkan biaya dan menyederhanakan operasi dengan menggunakan resource global, bukan banyak instance resource regional.
Pertimbangan desain	Biaya untuk transfer data lintas region dan replikasi data.
Informasi selengkapnya	Lihat bagian berikut: arketipe deployment global Analisis komparatif semua arketipe deployment

Hybrid

Bagian tertentu dari aplikasi Anda di-deploy di Google Cloud, sementara bagian lain berjalan secara lokal, seperti ditunjukkan dalam diagram berikut. Topologi di Google Cloud dapat menggunakan arketipe deployment zona, regional, multi-regional, atau global.

Kasus penggunaan	Situs pemulihan bencana (DR) untuk workload lokal. Pengembangan lokal untuk aplikasi cloud. Migrasi progresif ke cloud untuk aplikasi lama. Meningkatkan aplikasi lokal dengan kemampuan cloud.
Pertimbangan desain	Upaya penyiapan dan kompleksitas operasional. Biaya resource redundan.
Informasi selengkapnya	Lihat bagian berikut: Aketipe deployment hybrid Analisis komparatif semua arketipe deployment

Multi-cloud

Beberapa bagian dari aplikasi Anda di-deploy di Google Cloud, dan bagian lainnya di-deploy di platform cloud lainnya, seperti yang ditunjukkan dalam diagram berikut. Topologi di setiap platform cloud dapat menggunakan arketipe deployment zona, regional, multi-regional, atau global.

Kasus penggunaan	Google Cloud sebagai situs utama dan cloud lain sebagai situs DR. Meningkatkan aplikasi dengan kemampuan Google Cloud tingkat lanjut.
Pertimbangan desain	Upaya penyiapan dan kompleksitas operasional. Biaya resource redundan dan traffic jaringan lintas-cloud.
Informasi selengkapnya	Lihat bagian berikut: ARketipe deployment multicloud Analisis komparatif semua arketipe deployment

Pilih zona dan wilayah geografis

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy sistem Anda berdasarkan persyaratan geografis. Anda akan mempelajari cara memilih zona dan wilayah geografis yang optimal berdasarkan ketersediaan dan kedekatan, untuk mendukung kepatuhan, mengoptimalkan biaya, dan menerapkan load balancing.

Saat memilih satu atau beberapa wilayah untuk aplikasi bisnis, Anda mempertimbangkan kriteria yang mencakup ketersediaan layanan, latensi pengguna akhir, latensi aplikasi, biaya, dan persyaratan peraturan atau keberlanjutan. Untuk mendukung prioritas dan kebijakan bisnis Anda, seimbangkan persyaratan ini dan identifikasi konsekuensi terbaiknya. Misalnya, wilayah yang paling sesuai mungkin bukan wilayah yang paling hemat biaya atau mungkin tidak memiliki jejak karbon terendah.

Deploy di beberapa region

Region adalah area geografis independen yang terdiri dari beberapa zona. Suatu zona adalah area deployment untuk resource Google Cloud dalam suatu wilayah; setiap zona mewakili satu domain kegagalan dalam satu wilayah.

Agar terlindung dari periode nonaktif umum (termasuk pemeliharaan) dan periode nonaktif tidak terduga seperti insiden, sebaiknya deploy fault-tolerant yang memiliki ketersediaan tinggi dan deploy aplikasi Anda di beberapa zona dalam satu atau beberapa wilayah. Untuk mengetahui informasi lebih lanjut, lihat Geografi dan wilayah, Pertimbangan deployment aplikasi, dan Praktik terbaik untuk Pemilihan wilayah Compute Engine.

Deployment multi-zona dapat memberikan ketahanan jika deployment multi-wilayah tidak dapat dilakukan karena pertimbangan biaya atau lainnya. Pendekatan ini sangat bermanfaat terutama untuk mencegah pemadaman layanan zona atau regional serta menangani pemulihan dari bencana (disaster recovery) dan masalah keberlangsungan bisnis. Untuk mengetahui informasi selengkapnya, lihat Mendesain untuk skala dan ketersediaan tinggi.

Pilih region berdasarkan kedekatan lokasi geografis

Latensi berdampak pada pengalaman pengguna dan memengaruhi biaya yang terkait dengan penyaluran traffic kepada pengguna eksternal. Untuk meminimalkan latensi saat menyalurkan traffic kepada pengguna eksternal, pilih wilayah atau sekumpulan wilayah yang lokasinya dekat dengan pengguna Anda dan tempat layanan Anda berjalan dengan cara yang mendukung kepatuhan. Untuk mengetahui informasi selengkapnya, lihat Lokasi cloud dan Pusat referensi kepatuhan.

Pilih region berdasarkan layanan yang tersedia

Pilih region berdasarkan layanan yang tersedia yang diperlukan bisnis Anda. Kebanyakan layanan tersedia di semua region. Beberapa layanan khusus perusahaan tersedia di subkumpulan wilayah bersama dengan rilis awalnya. Untuk memverifikasi pemilihan region, lihat Lokasi cloud.

Pilih region untuk mendukung kepatuhan

Pilih region atau kumpulan region tertentu untuk memenuhi peraturan geografis atau regulasi kepatuhan yang mewajibkan penggunaan geografi tertentu, misalnya General Data Protection Regulation (GDPR) atau residensi data. Untuk mempelajari lebih lanjut cara mendesain sistem yang aman, lihat Penawaran kepatuhan dan Residensi data, transparansi operasional, dan privasi untuk pelanggan Eropa di Google Cloud.

Bandingkan harga resource utama

Region memiliki tarif biaya yang berbeda untuk layanan yang sama. Untuk mengidentifikasi region dengan biaya yang terjangkau, bandingkan harga resource utama yang ingin Anda gunakan. Pertimbangan biaya dapat berbeda, tergantung pada kebutuhan pencadangan dan resource seperti komputasi, jaringan, dan penyimpanan data. Untuk mempelajari lebih lanjut, lihat Kategori pengoptimalan biaya.

Gunakan Cloud Load Balancing untuk melayani pengguna global

Untuk meningkatkan kualitas pengalaman pengguna saat melayani pengguna global, gunakan Cloud Load Balancing untuk membantu memberikan satu alamat IP yang dialihkan ke aplikasi Anda. Untuk mempelajari lebih lanjut cara mendesain sistem yang andal, baca Framework Arsitektur Google Cloud.

Gunakan Pemilih Region Google Cloud untuk mendukung keberlanjutan

Google berhasil mencapai 0 jejak karbon sejak 2007 dan berkomitmen untuk menggunakan energi bebas karbon pada 2030. Untuk memilih region berdasarkan jejak karbonnya, gunakan Pemilih Region Google Cloud. Untuk mempelajari lebih lanjut cara mendesain dengan pertimbangan keberlanjutan, baca Cloud untuk keberlanjutan.

Langkah selanjutnya

Pelajari cara mengelola resource cloud Anda menggunakan Resource Manager, hierarki resource Google Cloud, dan Layanan Kebijakan Organisasi.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Kelola resource cloud

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk mengatur dan mengelola resource Anda di Google Cloud.

Hierarki resource

Resource Google Cloud disusun hierarkis dalam organisasi, folder, dan project. Hierarki ini memungkinkan Anda mengelola aspek umum resource seperti kontrol akses, setelan konfigurasi, dan kebijakan. Untuk praktik terbaik dalam mendesain hierarki resource cloud Anda, lihat Menentukan hierarki resource untuk zona landing Google Cloud Anda.

Label dan tag resource

Bagian ini memberikan praktik terbaik dalam menggunakan label dan tag dalam mengatur resource Google Cloud Anda.

Gunakan struktur folder yang sederhana

Dengan folder, Anda dapat mengelompokkan berbagai kombinasi project dan subfolder. Membuat struktur folder yang sederhana untuk menyusun resource Google Cloud Anda. Anda dapat menambahkan lebih banyak level sesuai kebutuhan untuk menentukan hierarki resource sehingga mendukung kebutuhan bisnis Anda. Struktur folder bersifat fleksibel dan dapat diperluas.Untuk mempelajari lebih lanjut, lihat Membuat dan mengelola folder.

Gunakan folder dan project untuk mencerminkan kebijakan tata kelola data

Gunakan folder, subfolder, dan project untuk memisahkan masing-masing resource agar mencerminkan kebijakan tata kelola data dalam organisasi Anda. Misalnya, Anda dapat menggunakan kombinasi folder dan project untuk memisahkan resource keuangan, sumber daya manusia, dan engineering.

Gunakan project untuk mengelompokkan resource yang memiliki batas kepercayaan yang sama. Misalnya, resource untuk produk atau microservice yang sama dapat dimiliki project yang sama. Untuk mengetahui informasi selengkapnya, lihat Menentukan hierarki resource untuk zona landing Google Cloud Anda.

Gunakan tag dan label di awal project Anda

Gunakan label dan tag ketika Anda mulai menggunakan produk Google Cloud, bahkan jika keduanya belum diperlukan. Menambahkan label dan tag akan memerlukan upaya manual yang dapat menyebabkan error dan sulit untuk diselesaikan.

Tag memberikan cara untuk mengizinkan atau menolak kebijakan secara bersyarat berdasarkan apakah resource memiliki tag tertentu. Label adalah pasangan nilai kunci yang membantu Anda mengatur instance Google Cloud. Untuk mengetahui informasi selengkapnya tentang label, lihat persyaratan untuk label,daftar layanan yang mendukung label, dan format label.

Resource Manager menyediakan label dan tag untuk membantu Anda mengelola resource, mengalokasikan dan melaporkan biaya, serta menetapkan kebijakan ke berbagai resource untuk kontrol akses terperinci. Misalnya, Anda dapat menggunakan label dan tag untuk menerapkan prinsip akses dan pengelolaan terperinci ke berbagai resource dan layanan tenant. Untuk mengetahui informasi selengkapnya tentang label VM dan tag jaringan, lihat Hubungan antara label VM dan tag jaringan.

Anda dapat menggunakan label untuk beberapa tujuan, termasuk sebagai berikut:

• Mengelola penagihan resource: Label tersedia dalam sistem penagihan, yang memungkinkan Anda memisahkan biaya berdasarkan label. Misalnya, Anda dapat memberi label pusat biaya atau anggaran yang berbeda.
• Mengelompokkan resource menurut karakteristik atau hubungan yang serupa: Anda dapat menggunakan label untuk memisahkan tahap atau lingkungan siklus proses aplikasi yang berbeda. Misalnya, Anda dapat memberi label pada lingkungan produksi, pengembangan, dan pengujian.

Tetapkan label untuk mendukung pelaporan biaya dan penagihan

Untuk mendukung pelaporan biaya dan penagihan terperinci berdasarkan atribut di luar struktur pelaporan terintegrasi (seperti jenis per project atau per produk), tetapkan label ke resource. Label dapat membantu Anda mengalokasikan konsumsi ke pusat biaya, departemen, project tertentu, atau mekanisme pengisian ulang internal. Untuk mengetahui informasi selengkapnya, lihat Kategori pengoptimalan biaya.

Hindari membuat label dalam jumlah besar

Hindari membuat label dalam jumlah besar. Sebaiknya buat label terutama di level project, dan hindari membuat label di level sub-tim. Jika Anda membuat label yang terlalu terperinci, tindakan tersebut dapat menambahkan derau ke analisis Anda. Untuk mempelajari kasus penggunaan umum label, lihat Penggunaan label umum.

Hindari menambahkan informasi sensitif pada label

Label tidak dirancang untuk menangani informasi sensitif. Jangan sertakan informasi sensitif dalam label, termasuk informasi berupa identitas pribadi, seperti nama atau gelar individu.

Anonimkan informasi dalam nama project

Ikuti pola penamaan project seperti COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, dengan placeholder yang unik dan tidak mengungkapkan nama perusahaan atau aplikasi. Jangan sertakan atribut yang dapat berubah di masa mendatang, misalnya, nama tim atau teknologi.

Terapkan tag untuk membuat model dimensi bisnis

Anda dapat menerapkan tag untuk membuat model dimensi bisnis tambahan seperti struktur organisasi, region, jenis workload, atau pusat biaya. Untuk mempelajari tentang tag lebih lanjut, lihat Ringkasan tag, Pewarisan tag, serta Membuat dan mengelola tag. Untuk mempelajari cara menggunakan tag dengan kebijakan, lihat Kebijakan dan tag. Untuk mempelajari cara menggunakan tag dalam mengelola kontrol akses, lihat Tag dan kontrol akses.

Kebijakan organisasi

Bagian ini memberikan praktik terbaik untuk mengonfigurasi aturan tata kelola pada resource Google Cloud di seluruh hierarki resource cloud.

Tetapkan konvensi penamaan proyek

Tetapkan konvensi penamaan project standar, misalnya, SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

Nama project memiliki batas 30 karakter.

Meskipun Anda dapat menerapkan prefiks seperti COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, nama project dapat menjadi tidak berlaku saat perusahaan melakukan reorganisasi. Pertimbangkan untuk memindahkan nama yang dapat diidentifikasi dari nama proyek ke label proyek.

Otomatiskan pembuatan project

Untuk membuat project untuk produksi dan bisnis skala besar, gunakan proses otomatis seperti Deployment Manager atau modul Google Cloud project factory Terraform. Alat ini dapat melakukan hal berikut:

• Buat lingkungan atau project pengembangan, pengujian, dan produksi secara otomatis yang memiliki izin yang sesuai.
• Konfigurasi logging dan pemantauan.

Modul Terraform factory project Google Cloud membantu Anda mengotomatiskan pembuatan project Google Cloud. Di perusahaan besar, sebaiknya tinjau dan setujui project sebelum sebelum membuatnya di Google Cloud. Proses ini membantu memastikan hal berikut:

• Biaya dapat diatribusikan. Untuk mengetahui informasi selengkapnya, lihat Kategori pengoptimalan biaya.
• Persetujuan tersedia untuk upload data.
• Persyaratan peraturan atau kepatuhan terpenuhi.

Jika mengotomatiskan pembuatan dan pengelolaan project serta resource Google Cloud, Anda akan mendapatkan manfaat berupa konsistensi, reproduktifitas, dan kemudahan pengujian. Dengan memperlakukan konfigurasi sebagai kode, Anda dapat membuat versi dan mengelola siklus proses konfigurasi bersama dengan artefak software Anda. Otomatisasi memungkinkan Anda mendukung praktik terbaik seperti konvensi penamaan yang konsisten dan pelabelan resource. Seiring dengan berkembangnya kebutuhan Anda, otomatisasi dapat menyederhanakan pemfaktoran ulang project.

Audit sistem Anda secara teratur

Untuk memastikan bahwa permintaan project baru dapat diaudit dan disetujui, integrasikan dengan sistem tiket perusahaan Anda atau sistem mandiri yang menyediakan audit.

Konfigurasi project secara konsisten

Mengonfigurasi project untuk memenuhi kebutuhan organisasi Anda secara konsisten. Menyertakan hal berikut saat Anda menyiapkan project:

• Project ID dan konvensi penamaan
• Menghubungkan akun penagihan
• Konfigurasi jaringan
• API dan layanan yang diaktifkan
• Konfigurasi akses Compute Engine
• Laporan ekspor dan penggunaan log
• Lien penghapusan project

Pisahkan dan isolasi workload atau lingkungan

Kuota dan batas diterapkan di level project. Untuk mengelola kuota dan batasan, pisahkan dan isolasi workload atau lingkungan di level project. Untuk mengetahui informasi selengkapnya, lihat Mengelola kuota.

Lingkungan pemisahan berbeda dengan persyaratan klasifikasi data. Memisahkan data dari infrastruktur dapat memerlukan biaya yang mahal dan rumit untuk diterapkan, jadi sebaiknya Anda menerapkan klasifikasi data berdasarkan persyaratan sensitivitas dan kepatuhan data.

Terapkan isolasi penagihan

Terapkan isolasi penagihan untuk mendukung berbagai akun penagihan dan visibilitas biaya per workload dan lingkungan. Untuk mengetahui informasi selengkapnya, lihat Membuat, mengubah, atau menutup akun Penagihan Cloud layanan mandiri dan Mengaktifkan, menonaktifkan, atau mengubah penagihan untuk sebuah project.

Untuk meminimalkan kompleksitas administratif, gunakan kontrol pengelolaan akses terperinci untuk lingkungan penting di level project, atau untuk workload yang tersebar di beberapa project. Saat menyeleksi kontrol akses untuk aplikasi produksi penting, Anda memastikan bahwa workload diamankan dan dikelola secara efektif.

Gunakan Layanan Kebijakan Organisasi untuk mengontrol resource

Layanan Kebijakan Organisasi memberi administrator kebijakan kontrol terpusat dan terprogram atas resource cloud organisasi Anda sehingga mereka dapat mengonfigurasi batasan di seluruh hierarki resource. Untuk mengetahui informasi selengkapnya, lihat Menambahkan administrator kebijakan organisasi.

Gunakan Layanan Kebijakan Organisasi untuk mematuhi kebijakan peraturan

Untuk memenuhi persyaratan kepatuhan, gunakan Layanan Kebijakan Organisasi untuk menerapkan persyaratan kepatuhan dalam berbagi dan akses resource. Misalnya, Anda dapat membatasi pembagian dengan pihak eksternal atau menentukan tempat deployment resource cloud secara geografis. Skenario kepatuhan lainnya mencakup hal berikut:

• Kontrol terpusat untuk mengonfigurasi batasan yang menentukan cara penggunaan resource organisasi Anda.
• Menentukan dan menetapkan kebijakan untuk membantu tim pengembangan Anda tetap berada dalam batas kepatuhan.
• Membantu pemilik project dan tim mereka membuat perubahan sistem sekaligus menjaga kepatuhan terhadap peraturan dan meminimalkan kecemasan terhadap pelanggaran aturan kepatuhan.

Batasi resource berbagi berdasarkan domain

Kebijakan organisasi berbagi terbatas membantu Anda mencegah resource Google Cloud dibagikan dengan identitas di luar organisasi Anda. Untuk mengetahui informasi selengkapnya, lihat Membatasi identitas berdasarkan domain dan Batasan kebijakan organisasi.

Nonaktifkan akun layanan dan pembuatan kunci

Untuk membantu meningkatkan keamanan, batasi penggunaan akun layanan Identity and Access Management (IAM) dan kunci yang sesuai. Untuk mengetahui informasi selengkapnya, lihat Membatasi penggunaan akun layanan.

Batasi lokasi fisik resource baru

Membatasi lokasi fisik resource yang baru dibuat dengan membatasi lokasi resource. Untuk melihat daftar batasan yang memberi Anda kontrol atas resource organisasi, lihat Batasan Layanan Kebijakan Organisasi.

Langkah selanjutnya

Pelajari cara memilih dan mengelola komputasi, termasuk hal berikut ini:

• Pendekatan migrasi Compute.

• Mendesain workload dan menskalakan workload Anda.

• Mengelola operasi.

• Mengelola VM migrations.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Pilih dan kelola komputasi

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy sistem Anda berdasarkan persyaratan komputasi. Anda akan mempelajari cara memilih platform komputasi dan pendekatan migrasi, mendesain dan menskalakan workload, serta mengelola operasi dan migrasi VM.

Komputasi merupakan inti dari banyak workload, baik mengacu pada eksekusi logika bisnis kustom maupun penerapan algoritma komputasi yang kompleks terhadap set data. Sebagian besar solusi menggunakan resource komputasi dalam beberapa bentuk, dan penting bagi Anda untuk memilih resource komputasi yang tepat sesuai kebutuhan aplikasi Anda.

Google Cloud memberikan sejumlah opsi untuk menggunakan waktu pada CPU. Opsi didasarkan pada jenis CPU, performa, dan cara kode dijadwalkan untuk dijalankan, termasuk penagihan penggunaan.

Opsi komputasi Google Cloud mencakup:

• Mesin virtual (VM) dengan manfaat khusus cloud, seperti migrasi langsung.
• Pengemasan container secara berkelompok di mesin cluster yang dapat berbagi penggunaan CPU.
• Fungsi dan pendekatan serverless, di mana penggunaan waktu CPU Anda dapat diukur ke pekerjaan yang dilakukan selama satu permintaan HTTP.

Memilih komputasi

Bagian ini memberikan praktik terbaik untuk memilih dan bermigrasi ke platform komputasi.

Pilih platform komputasi

Saat memilih platform komputasi untuk workload Anda, pertimbangkan persyaratan teknis workload, proses otomatisasi siklus proses, regionalisasi, dan keamanan.

Evaluasi sifat penggunaan CPU oleh aplikasi dan seluruh sistem pendukung, termasuk cara kode Anda dikemas dan di-deploy, didistribusikan, serta dipanggil. Meskipun beberapa skenario mungkin kompatibel dengan beberapa opsi platform, workload portabel harus mampu dan berperforma baik pada berbagai opsi komputasi.

Tabel berikut memberikan ringkasan layanan komputasi Google Cloud yang direkomendasikan untuk berbagai kasus penggunaan:

Platform komputasi	Kasus penggunaan	Produk yang direkomendasikan
Serverless	Deploy aplikasi pertama Anda. Fokus pada logika pemrosesan dan data, serta pada pengembangan aplikasi, bukan pemeliharaan pengoperasian infrastruktur.	Cloud Run: Masukkan logika bisnis Anda ke dalam container menggunakan opsi serverless yang terkelola sepenuhnya ini. Cloud Run dirancang untuk workload yang membutuhkan komputasi intensif, tetapi tidak selalu aktif. Skalakan biaya secara efektif dari 0 (tanpa traffic) dan tentukan CPU dan RAM dari tugas dan layanan Anda. Deploy dengan satu perintah dan Google akan otomatis menyediakan jumlah resource yang tepat. Cloud Functions: Memisahkan kode Anda menjadi bagian-bagian logika bisnis yang fleksibel tanpa masalah infrastruktur seperti load balancing, update, autentikasi, atau penskalaan.
Kubernetes	Build arsitektur microservice kompleks yang memerlukan layanan tambahan seperti Istio untuk mengelola kontrol mesh layanan.	Google Kubernetes Engine: Mesin orkestrasi container open source yang mengotomatiskan deploy, penskalaan, dan pengelolaan aplikasi dalam container.
Mesin virtual (VM)	Buat dan jalankan VM dari kelompok VM yang telah ditetapkan dan dapat disesuaikan, yang mendukung persyaratan aplikasi dan workload Anda, serta software dan layanan pihak ketiga.	Compute Engine: Menambahkan unit pemrosesan grafis (GPU) ke instance VM Anda. Anda dapat menggunakan GPU ini untuk mempercepat workload tertentu di instance Anda seperti machine learning dan pemrosesan data. Untuk memilih jenis mesin yang sesuai berdasarkan kebutuhan Anda, lihat Rekomendasi untuk kelompok mesin.

Untuk informasi selengkapnya, lihat Memilih opsi komputasi.

Pilih pendekatan migrasi komputasi

Jika Anda memigrasikan aplikasi yang sudah ada dari cloud lain atau dari infrastruktur lokal, gunakan salah satu produk Google Cloud berikut untuk membantu Anda mengoptimalkan performa, skala, biaya, dan keamanan.

Sasaran migrasi	Kasus penggunaan	Produk yang direkomendasikan
Lift-and-shift	Migrasikan atau perluas workload VMware Anda ke Google Cloud dalam hitungan menit.	Google Cloud VMware Engine
Lift-and-shift	Pindahkan aplikasi berbasis VM ke Compute Engine.	Migrate to Virtual Machines
Melakukan upgrade ke container	Memodernisasi aplikasi tradisional ke dalam container bawaan di Google Kubernetes Engine.	Migrate to Containers

Untuk mempelajari cara memigrasikan workload Anda sekaligus menyelaraskan tim internal, lihat Siklus proses VM Migration dan Membangun Program Migrasi Skala Besar dengan Google Cloud.

Mendesain workload

Bagian ini memberikan praktik terbaik untuk mendesain workload guna mendukung sistem Anda.

Evaluasi opsi serverless untuk logika sederhana

Logika sederhana adalah jenis komputasi yang tidak memerlukan hardware atau jenis mesin khusus seperti mesin yang dioptimalkan untuk CPU. Sebelum Anda berinvestasi dalam implementasi Google Kubernetes Engine (GKE) atau Compute Engine untuk meminimalkan beban operasional serta mengoptimalkan biaya dan performa, pertimbangkan opsi serverless untuk logika yang ringan.

Pisahkan aplikasi menjadi model stateless

Jika memungkinkan, pisahkan aplikasi Anda menjadi stateless untuk memaksimalkan penggunaan opsi komputasi serverless. Pendekatan ini memungkinkan Anda menggunakan penawaran komputasi terkelola, menskalakan aplikasi on-demand, serta mengoptimalkan biaya dan performa. Untuk informasi selengkapnya tentang memisahkan aplikasi Anda untuk desain yang memungkinkan skalabilitas dan ketersediaan tinggi, lihat Desain untuk skalabilitas dan ketersediaan tinggi.

Gunakan logika caching saat memisahkan arsitektur

Jika aplikasi Anda dirancang untuk menjadi stateful, gunakan logika caching untuk memisahkan dan membuat workload Anda skalabel. Untuk informasi selengkapnya, lihat Praktik terbaik database.

Gunakan migrasi langsung untuk memfasilitasi upgrade

Untuk memfasilitasi upgrade pemeliharaan Google, gunakan migrasi langsung dengan menyetel kebijakan ketersediaan instance. Untuk informasi selengkapnya, lihat Menetapkan kebijakan pemeliharaan host VM.

Menskalakan workload

Bagian ini memberikan praktik terbaik untuk menskalakan workload guna mendukung sistem Anda.

Gunakan skrip startup dan shutdown

Untuk aplikasi stateful, gunakan skrip startup dan shutdown jika memungkinkan untuk memulai dan menghentikan status aplikasi Anda dengan lancar. Memulai secara tuntas terjadi ketika komputer dihidupkan melalui fungsi software, dan sistem operasi diperbolehkan untuk menyelesaikan tugasnya dalam memulai proses dan membuka koneksi dengan aman.

Memulai dan penghentian secara tuntas sangat penting karena aplikasi stateful bergantung pada ketersediaan langsung terhadap data yang berada di dekat komputasi, biasanya pada disk lokal atau persistent disk, atau di RAM. Agar data aplikasi tidak berjalan dari awal untuk setiap startup, gunakan skrip startup untuk memuat ulang data yang terakhir disimpan dan jalankan proses dari tempat sebelumnya berhenti saat dimatikan. Untuk menyimpan status memori aplikasi agar tidak kehilangan progres saat dinonaktifkan, gunakan skrip shutdown. Misalnya, gunakan skrip penonaktifan saat VM dijadwalkan untuk dinonaktifkan karena penurunan skala atau peristiwa pemeliharaan Google.

Gunakan MIG untuk mendukung pengelolaan VM

Saat menggunakan VM Compute Engine, grup instance terkelola (MIGs) mendukung fitur seperti autohealing, load balancing, penskalaan otomatis, update otomatis, dan workload stateful. Anda dapat membuat MIG berbasis region atau zona berdasarkan tujuan ketersediaan. Anda dapat menggunakan MIG untuk inferensi stateless atau workload batch dan untuk aplikasi stateful yang perlu mempertahankan status unik setiap VM.

Menggunakan autoscaler pod untuk menskalakan workload GKE

Gunakan horizontal dan autoscaler Pod vertikal untuk menskalakan workload Anda, dan menggunakan penyediaan otomatis node untuk menskalakan resource komputasi yang mendasarinya.

Distribusikan traffic aplikasi

Untuk menskalakan aplikasi Anda secara global, gunakan Cloud Load Balancing untuk mendistribusikan instance aplikasi di lebih dari satu region atau zona. Load balancer mengoptimalkan perutean paket dari jaringan edge Google Cloud ke zona terdekat, yang meningkatkan efisiensi inferensi traffic dan meminimalkan biaya inferensi. Untuk mengoptimalkan latensi pengguna akhir, gunakan Cloud CDN untuk menyimpan konten statis ke dalam cache bila memungkinkan.

Otomatiskan pembuatan dan pengelolaan komputasi

Minimalkan error yang disebabkan oleh kesalahan manusia di lingkungan produksi Anda dengan mengotomatiskan pembuatan dan pengelolaan komputasi.

Mengelola operasi

Bagian ini memberikan praktik terbaik untuk mengelola operasi guna mendukung sistem Anda.

Gunakan image publik yang disediakan Google

Gunakan image publik yang disediakan Google Cloud. Image publik Google Cloud secara teratur diperbarui. Untuk informasi selengkapnya, lihat Daftar image publik yang tersedia di Compute Engine.

Anda juga dapat membuat image sendiri dengan konfigurasi dan setelan tertentu. Jika memungkinkan, otomatiskan dan pusatkan pembuatan image dalam project terpisah yang dapat Anda bagikan kepada pengguna yang diberi otorisasi dalam organisasi Anda. Membuat dan menyeleksi image kustom dalam project terpisah memungkinkan Anda memperbarui, melakukan patch, dan membuat VM menggunakan konfigurasi Anda sendiri. Kemudian, Anda dapat membagikan image VM yang diseleksi dengan project yang relevan.

Gunakan snapshot untuk cadangan instance

Dengan snapshot, Anda dapat membuat cadangan untuk instance Anda. Snapshot sangat berguna untuk aplikasi stateful, yang tidak memiliki cukup fleksibilitas untuk mempertahankan status atau menyimpan progres saat terjadi penonaktifan tiba-tiba. Jika sering menggunakan snapshot untuk membuat instance baru, Anda dapat mengoptimalkan proses pencadangan dengan membuat image dasar dari snapshot tersebut.

Gunakan image mesin untuk mengaktifkan pembuatan instance VM

Meski snapshot hanya mengambil image data di dalam mesin, image mesin mengambil konfigurasi dan setelan mesin, beserta datanya. Gunakan image mesin untuk menyimpan semua konfigurasi, metadata, izin, dan data dari satu atau beberapa disk yang diperlukan untuk membuat instance VM.

Saat membuat mesin dari snapshot, Anda harus mengonfigurasi setelan instance pada instance VM baru yang memerlukan banyak pekerjaan. Menggunakan image mesin memungkinkan Anda menyalin setelan yang diketahui tersebut ke mesin baru, sehingga mengurangi overhead. Untuk informasi selengkapnya, lihat Kapan harus menggunakan image mesin.

Kapasitas, pemesanan, dan isolasi

Bagian ini memberikan praktik terbaik untuk mengelola kapasitas, pemesanan, dan isolasi untuk mendukung sistem Anda.

Gunakan diskon abonemen untuk mengurangi biaya

Anda dapat mengurangi biaya pengeluaran operasional (OPEX) untuk workload yang selalu aktif dengan menggunakan diskon abonemen. Untuk informasi selengkapnya, lihat Kategori pengoptimalan biaya.

Pilih jenis mesin untuk mendukung efisiensi biaya dan performa

Google Cloud menawarkan jenis mesin yang memungkinkan Anda memilih komputasi berdasarkan parameter biaya dan performa. Anda dapat memilih penawaran berperforma rendah untuk mengoptimalkan biaya atau memilih opsi komputasi berperforma tinggi dengan biaya lebih tinggi. Untuk informasi selengkapnya, lihat Kategori pengoptimalan biaya.

Gunakan node tenant tunggal untuk mendukung kebutuhan kepatuhan

Sole-tenant node adalah server Compute Engine fisik yang dikhususkan untuk menghosting VM project Anda. Sole-tenant node dapat membantu Anda memenuhi persyaratan kepatuhan untuk isolasi fisik, termasuk hal berikut:

• Pisahkan VM Anda secara fisik dari VM di project lainnya.
• Kelompokkan VM Anda di hardware host yang sama.
• Isolasikan workload pemrosesan pembayaran.

Untuk informasi selengkapnya, lihat Sole-tenant node.

Gunakan pemesanan untuk memastikan ketersediaan resource

Google Cloud memungkinkan Anda menetapkan pemesanan untuk workload guna memastikan resource tersebut selalu tersedia. Tidak ada biaya tambahan untuk membuat pemesanan, tetapi Anda membayar resource yang telah dipesan meski tidak digunakan. Untuk informasi selengkapnya, lihat Menggunakan dan mengelola pemesanan.

Migrasi VM

Bagian ini memberikan praktik terbaik untuk memigrasikan VM guna mendukung sistem Anda.

Evaluasi alat migrasi bawaan

Evaluasi alat migrasi bawaan untuk memindahkan workload Anda dari cloud lain atau dari infrastruktur lokal. Untuk informasi selengkapnya, lihat Migrasi ke Google Cloud. Google Cloud menawarkan alat dan layanan untuk membantu Anda memigrasikan workload serta mengoptimalkan biaya dan performa. Untuk menerima penilaian biaya migrasi gratis berdasarkan lanskap IT Anda saat ini, lihat Google Cloud Rapid Assessment & Migration Program.

Gunakan impor disk virtual untuk sistem operasi yang disesuaikan

Untuk mengimpor sistem operasi yang didukung yang disesuaikan, lihat Mengimpor disk virtual. Sole-tenant node dapat membantu memenuhi persyaratan bring your own license (BYOL) untuk lisensi per inti dan per prosesor hardware Anda. Untuk informasi selengkapnya, lihat Menggunakan lisensi Anda sendiri (BYOL).

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, kami merekomendasikan untuk melakukan hal berikut:

• Tinjau penawaran Google Cloud Marketplace untuk mengevaluasi apakah aplikasi Anda tercantum dalam vendor yang didukung. Google Cloud mendukung penggunaan berbagai jenis sistem open source dan software pihak ketiga.

• Pertimbangkan menggunakan Migrate to Containers dan GKE untuk mengekstrak dan memaketkan aplikasi berbasis VM sebagai aplikasi dalam container yang berjalan di GKE.

• Gunakan Compute Engine untuk menjalankan aplikasi Anda di Google Cloud. Jika Anda memiliki dependensi lama yang berjalan di aplikasi berbasis VM, verifikasi kesesuaiannya dengan persyaratan vendor.

• Evaluasi menggunakan Load Balancer Jaringan passthrough internal Google Cloud untuk menskalakan arsitektur yang dipisahkan. Untuk informasi selengkapnya, lihat Ringkasan Load Balancer Jaringan passthrough internal.

• Evaluasi opsi Anda untuk beralih dari kasus penggunaan infrastruktur lokal konvensional, seperti penggunaan HA-Proxy. Untuk informasi selengkapnya, lihat praktik terbaik untuk alamat IP mengambang.

• Gunakan VM Manager untuk mengelola sistem operasi untuk fleet VM berskala besar yang menjalankan windows atau Linux di Compute Engine, dan menerapkan kebijakan konfigurasi yang konsisten.

• Pertimbangkan menggunakan GKE Autopilotdan izinkan Google SRE mengelola cluster Anda sepenuhnya.

• Gunakan Pengontrol Kebijakan dan Config Sync untuk pengelolaan kebijakan dan konfigurasi di seluruh cluster GKE Anda.

• Pastikan ketersediaan dan skalabilitas mesin di region dan zona tertentu. Google Cloud dapat melakukan penskalaan untuk mendukung kebutuhan komputasi Anda. Namun, jika Anda memerlukan banyak jenis mesin tertentu di region atau zona tertentu, harap bekerja sama dengan tim akun Anda untuk memastikan ketersediaan. Untuk informasi selengkapnya, lihat Pemesanan untuk Compute Engine.

Langkah selanjutnya

Pelajari prinsip-prinsip desain jaringan, termasuk yang berikut:

• Desain arsitektur VPC workload.

• Desain konektivitas antar-VPC.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Desain infrastruktur jaringan Anda

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy sistem Anda berdasarkan desain jaringan. Anda akan mempelajari cara memilih dan menerapkan Virtual Private Cloud (VPC), serta cara menguji dan mengelola keamanan jaringan.

Prinsip inti

Desain jaringan sangat penting untuk keberhasilan desain sistem karena membantu Anda mengoptimalkan performa dan komunikasi aplikasi yang aman dengan layanan internal dan eksternal. Saat memilih layanan jaringan, Anda harus mengevaluasi kebutuhan aplikasi dan mengevaluasi cara aplikasi berkomunikasi satu sama lain. Misalnya, meskipun beberapa komponen memerlukan layanan global, komponen lain mungkin perlu berlokasi geografis di region tertentu.

Jaringan pribadi Google menghubungkan lokasi regional ke lebih dari 100 titik kehadiran jaringan global. Google Cloud menggunakan software-defined networking dan teknologi sistem terdistribusi untuk menghosting dan memberikan layanan Anda di seluruh dunia. Elemen inti Google untuk jaringan dalam Google Cloud adalah VPC global. VPC menggunakan jaringan berkecepatan tinggi global milik Google untuk menautkan aplikasi Anda di seluruh region sekaligus mendukung privasi dan keandalan. Google memastikan bahwa konten Anda dikirimkan dengan throughput tinggi menggunakan teknologi seperti kecerdasan kontrol kemacetan waktu penerapan Bandwidth Bottleneck and Round-trip (BBR).

Langkah-langkah untuk mengembangkan desain jaringan cloud Anda mencakup:

1. Mendesain arsitektur VPC beban kerja. Mulai dengan mengidentifikasi berapa banyak project Google Cloud dan Jaringan VPC yang Anda butuhkan.
2. Menambahkan konektivitas antar-VPC. Desain cara beban kerja Anda terhubung ke beban kerja lain di berbagai Jaringan VPC.
3. Mendesain konektivitas jaringan hybrid. Desain cara VPC workload Anda terhubung ke lingkungan lokal dan lingkungan cloud lainnya.

Saat mendesain jaringan Google Cloud, pertimbangkan hal-hal berikut:

• VPC menyediakan lingkungan jaringan pribadi di cloud untuk layanan interkoneksi yang dibuat di Compute Engine, Google Kubernetes Engine (GKE), dan Solusi Komputasi Serverless. Anda juga dapat menggunakan VPC untuk secara pribadi mengakses layanan yang dikelola Google seperti Cloud Storage, BigQuery, dan Cloud SQL.
• Jaringan VPC, termasuk rute dan aturan firewall yang terkait, merupakan resource global; mereka tidak terkait dengan region atau zona tertentu.
• Subnet adalah resource regional. Instance VM Compute Engine yang di-deploy di zona berbeda di region cloud yang sama dapat menggunakan alamat IP dari subnet yang sama.
• Traffic ke dan dari instance dapat dikontrol menggunakan aturan firewall VPC.
• Administrasi jaringan dapat diamankan menggunakan peran Identity and Access Management (IAM).
• Jaringan VPC dapat dihubungkan secara aman di lingkungan hybrid menggunakan Cloud VPN atau Cloud Interconnect.

Untuk melihat daftar lengkap spesifikasi VPC, lihat Spesifikasi.

Arsitektur VPC workload

Bagian ini memberikan praktik terbaik untuk mendesain arsitektur VPC workload guna mendukung sistem Anda.

Pertimbangkan desain jaringan VPC dari awal

Jadikan desain jaringan VPC sebagai bagian awal proses mendesain penyiapan organisasi Anda di Google Cloud. Pilihan desain level organisasi tidak dapat dibatalkan dengan mudah setelah proses berlangsung. Untuk informasi selengkapnya, baca Praktik terbaik dan arsitektur referensi untuk desain VPC serta Menentukan desain jaringan untuk zona landing Google Cloud Anda.

Mulai dengan satu Jaringan VPC

Untuk banyak kasus penggunaan yang menyertakan resource dengan persyaratan umum, satu jaringan VPC menyediakan fitur yang Anda butuhkan. Satu jaringan VPC mudah dibuat, dikelola, dan dipahami. Untuk informasi selengkapnya, lihat Spesifikasi Jaringan VPC.

Menjaga agar topologi jaringan VPC tetap sederhana

Untuk memastikan arsitektur yang mudah dikelola, andal, dan dipahami dengan baik, jaga desain topologi jaringan VPC Anda sesederhana mungkin.

Gunakan jaringan VPC dalam mode kustom

Untuk memastikan bahwa jaringan Google Cloud terintegrasi dengan lancar dengan sistem jaringan Anda yang ada, sebaiknya gunakan mode kustom saat membuat jaringan VPC. Penggunaan mode kustom dapat membantu Anda mengintegrasikan jaringan Google Cloud ke skema pengelolaan alamat IP yang ada dan memungkinkan Anda mengontrol region cloud mana yang disertakan dalam VPC. Untuk informasi lebih lanjut, lihat VPC.

Konektivitas antar-VPC

Bagian ini memberikan praktik terbaik untuk mendesain konektivitas antar-VPC guna mendukung sistem Anda.

Pilih metode koneksi VPC

Jika Anda memutuskan untuk menerapkan beberapa jaringan VPC, Anda perlu menghubungkan jaringan-jaringan tersebut. Jaringan VPC adalah ruang tenant yang terisolasi dalam software-defined network (SDN) Andromeda milik Google. Jaringan VPC dapat berkomunikasi satu sama lain melalui beberapa cara. Pilih cara Anda menghubungkan jaringan berdasarkan persyaratan bandwidth, latensi, dan perjanjian tingkat layanan (SLA) Anda. Untuk mempelajari opsi koneksi lebih lanjut, baca artikel Memilih metode koneksi VPC yang memenuhi kebutuhan biaya, performa, dan keamanan Anda.

Gunakan VPC Bersama untuk mengelola beberapa kelompok kerja

Untuk organisasi yang memiliki beberapa tim, VPC Bersama menyediakan alat yang efektif untuk memperluas kesederhanaan arsitektural jaringan VPC di beberapa kelompok kerja.

Gunakan konvensi penamaan yang sederhana

Pilih konvensi penamaan yang sederhana, intuitif, dan konsisten. Hal ini akan membantu administrator dan pengguna untuk memahami tujuan setiap resource, tempat lokasinya berada, dan cara membedakan masing-masing resource.

Gunakan uji konektivitas untuk memverifikasi keamanan jaringan

Dalam konteks keamanan jaringan, Anda dapat menggunakan uji konektivitas untuk memverifikasi bahwa traffic yang ingin Anda cegah di antara dua endpoint sudah diblokir. Untuk memverifikasi bahwa traffic sudah diblokir dan alasan pemblokirannya, tentukan pengujian di antara dua endpoint dan evaluasi hasilnya. Misalnya, Anda dapat menguji fitur VPC yang memungkinkan Anda menentukan aturan yang mendukung pemblokiran traffic. Untuk informasi selengkapnya, lihat Ringkasan Uji Konektivitas.

Gunakan Private Service Connect untuk membuat endpoint pribadi

Untuk membuat endpoint pribadi yang dapat Anda gunakan untuk mengakses layanan Google dengan skema alamat IP Anda sendiri, gunakan Private Service Connect. Anda dapat mengakses endpoint pribadi dari dalam VPC dan melalui konektivitas hybrid yang terhenti di VPC Anda.

Amankan dan batasi konektivitas eksternal

Batasi akses internet hanya untuk resource yang membutuhkannya. Resource dengan hanya alamat IP internal pribadi masih dapat mengakses banyak API dan layanan Google melalui Akses Google Pribadi.

Gunakan Network Intelligence Center untuk memantau jaringan cloud Anda

Network Intelligence Center memberikan gambaran menyeluruh tentang jaringan Google Cloud Anda di semua region. Data ini membantu Anda mengidentifikasi pola traffic dan akses yang dapat menyebabkan risiko operasional atau keamanan.

Langkah selanjutnya

Pelajari praktik terbaik untuk pengelolaan penyimpanan, termasuk yang berikut:

• Memilih jenis penyimpanan.
• Memilih pola akses penyimpanan dan jenis workload.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Pilih dan terapkan strategi penyimpanan

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy sistem Anda berdasarkan penyimpanan. Anda mempelajari cara memilih strategi penyimpanan dan cara mengelola penyimpanan, pola akses, dan workload.

Untuk memfasilitasi pertukaran data serta mencadangkan dan menyimpan data dengan aman, organisasi harus memilih paket penyimpanan berdasarkan workload, operasi input/output per detik (IOPS), latensi, frekuensi pengambilan, lokasi, kapasitas, dan format (blok, file, dan objek).

Cloud Storage menyediakan layanan penyimpanan objek yang andal dan aman, termasuk.di bawah ini:

• Opsi redundansi bawaan untuk melindungi data Anda dari kegagalan peralatan dan untuk memastikan ketersediaan data selama pemeliharaan pusat data.
• Opsi transfer data, termasuk berikut ini:
  • Storage Transfer Service
  • Transfer Appliance
  • BigQuery Data Transfer Service
  • Migrasi ke Google Cloud: Mentransfer set data besar
• Kelas penyimpanan untuk mendukung workload Anda.
• Checksum yang dihitung untuk semua operasi Cloud Storage yang memungkinkan Google untuk memverifikasi pembacaan dan penulisan.

Di Google Cloud, IOPS diskalakan sesuai dengan ruang penyimpanan yang disediakan. Jenis penyimpanan seperti Persistent Disk memerlukan replikasi dan pencadangan manual karena bersifat zonal atau regional. Sebaliknya, penyimpanan objek sangat tersedia dan secara otomatis mereplikasi data di satu atau beberapa region.

Jenis penyimpanan

Bagian ini memberikan praktik terbaik untuk memilih jenis penyimpanan yang mendukung sistem Anda.

Evaluasi opsi untuk kebutuhan penyimpanan berperforma tinggi

Evaluasi persistent disk atau Solid State Drive (SSD) lokal untuk aplikasi komputasi yang memerlukan penyimpanan berperforma tinggi. Cloud Storage adalah penyimpanan objek yang tidak dapat diubah dengan pembuatan versi. Penggunaan Cloud Storage dengan Cloud CDNmembantu mengoptimalkan biaya, terutama untuk objek statis yang sering diakses.

Filestore mendukung aplikasi multi-tulis yang membutuhkan ruang bersama berperforma tinggi. Filestore juga mendukung aplikasi lama dan modern yang memerlukan operasi file seperti POSIX melalui pemasangan Network File System (NFS).

Cloud Storage mendukung kasus penggunaan seperti pembuatan data lake dan penanganan kebutuhan pengarsipan. Buat keputusan yang seimbang berdasarkan cara Anda memilih kelas Cloud Storagedisebabkan biaya akses dan pengambilan, terutama saat Anda mengonfigurasi kebijakan retensi. Untuk informasi selengkapnya, lihat Mendesain strategi penyimpanan yang optimal untuk workload cloud Anda.

Semua opsi penyimpanan secara default terenkripsi saat dalam penyimpanan dan selama transit menggunakan kunci yang dikelola Google. Untuk jenis penyimpanan seperti Persistent Disk dan Cloud Storage, Anda dapat menyediakan kunci sendiri atau mengelolanya melalui Cloud Key Management Service (Cloud KMS). Menetapkan strategi untuk menangani kunci tersebut sebelum Anda menggunakannya pada data produksi.

Pilih layanan Google Cloud untuk mendukung desain penyimpanan

Untuk mempelajari layanan Google Cloud yang mendukung desain penyimpanan, gunakan tabel berikut:

Layanan Google Cloud	Deskripsi
Cloud Storage	Menyediakan penyimpanan dan pengambilan data secara global, berapa pun ukurannya, kapan pun waktunya. Anda dapat menggunakan Cloud Storage untuk beberapa skenario, termasuk menyalurkan konten situs, menyimpan data untuk pemulihan arsip dan pemulihan dari bencana, atau mendistribusikan objek data besar kepada pengguna melalui download langsung. Untuk informasi selengkapnya, lihat referensi berikut: Praktik terbaik Cloud Storage Lokasi bucket Kelas penyimpanan FUSE Cloud Storage
Persistent Disk	Block storage berperforma tinggi untuk Google Cloud. Persistent Disk menyediakan penyimpanan SSD dan hard disk drive (HDD) yang dapat Anda pasang ke instance yang berjalan di Compute Engine atau Google Kubernetes Engine (GKE). Disk regionalmenyediakan penyimpanan dan replikasi data yang tahan lama antara dua zona di region yang sama. Jika Anda membutuhkan IOPS yang lebih tinggi dan latensi rendah, Google Cloud menawarkan Cloud Filestore. SSD lokal secara fisik terpasang ke server yang menghosting instance mesin virtual Anda. Anda dapat menggunakan SSD lokal sebagai kapasitas disk sementara.
Filestore	Layanan penyimpanan file terkelola untuk aplikasi yang memerlukan antarmuka sistem file dan sistem file bersama untuk data. Filestore memberi pengguna pengalaman yang lancar untuk menyediakan Network Attached Storage (NAS) terkelola dengan instance Compute Engine dan GKE mereka.
Cloud Storage for Firebase	Dirancang untuk developer aplikasi yang perlu menyimpan dan menyalurkan konten buatan penggunaan, seperti foto atau video Semua file Anda disimpan di Cloud Storage buckets, sehingga dapat diakses dari Firebase dan Google Cloud.

Pilih strategi penyimpanan

Untuk memilih strategi penyimpanan yang memenuhi persyaratan aplikasi Anda, gunakan tabel berikut:

Kasus penggunaan	Rekomendasi
Anda ingin menyimpan data dalam skala besar dengan biaya terendah, dan performa akses bukan menjadi masalah.	Cloud Storage
Anda sedang menjalankan aplikasi komputasi yang membutuhkan penyimpanan segera. Untuk informasi selengkapnya, lihat Mengoptimalkan performa Persistent Disk dan SSD Lokal.	Persistent Disk atau SSD Lokal
Anda menjalankan workload berperforma tinggi yang memerlukan akses baca dan tulis ke ruang bersama.	Filestore
Anda memiliki kasus penggunaan komputasi berperforma tinggi (HPC) atau komputasi throughput tinggi (HTC).	Menggunakan cluster untuk komputasi teknis skala besar di cloud

Pilih penyimpanan arsip atau aktif berdasarkan kebutuhan akses penyimpanan

Sebuah Kelas penyimpanan adalah bagian dari metadata yang digunakan oleh setiap objek. Untuk data yang disajikan pada tarif tinggi dengan ketersediaan tinggi, gunakan kelas Standard Storage. Untuk data yang jarang diakses dan dapat menoleransi ketersediaan yang sedikit lebih rendah, gunakan kelas Nearline Storage, Coldline Storage, atau Archive Storage. Untuk informasi selengkapnya tentang pertimbangan biaya saat memilih kelas penyimpanan, lihat Harga Cloud Storage.

Evaluasi lokasi penyimpanan dan kebutuhan perlindungan data untuk Cloud Storage

Untuk bucket Cloud Storage yang terletak di suatu region, data yang ada di dalamnya secara otomatis direplikasi ke berbagai zona dalam region tersebut. Replikasi data ke berbagai zona akan melindungi data tersebut jika ada kegagalan zona dalam suatu region.

Cloud Storage juga menawarkan lokasi yang redundan di seluruh region, yang berarti data direplikasi di beberapa pusat data yang terpisah secara geografis. Untuk mengetahui informasi selengkapnya, lihat Lokasi bucket.

Gunakan Cloud CDN untuk meningkatkan pengiriman objek statis

Untuk mengoptimalkan biaya pengambilan objek dan meminimalkan latensi akses, gunakan Cloud CDN. Cloud CDN menggunakan Load Balancer Aplikasi eksternalCloud Load Balancing untuk menyediakan pemilihan rute, health check, dan dukungan alamat IP anycast. Untuk informasi lebih lanjut, baca Menyiapkan Cloud CDN dengan bucket cloud.

Pola akses penyimpanan dan jenis workload

Bagian ini memberikan praktik terbaik untuk memilih pola akses penyimpanan dan jenis workload untuk mendukung sistem Anda.

Gunakan persistent disk untuk mendukung akses penyimpanan berperforma tinggi

Pola akses data bergantung pada cara Anda mendesain performa sistem. Cloud Storage menyediakan penyimpanan yang skalabel, tetapi bukanlah pilihan ideal jika Anda menjalankan workload komputasi berat yang memerlukan akses throughput tinggi ke data dalam jumlah besar. Untuk akses penyimpanan berperforma tinggi, gunakan Persistent Disk.

Gunakan backoff eksponensial saat menerapkan logika coba lagi

Gunakan backoff eksponensial saat menerapkan logika coba lagi untuk menangani error 5XX, 408, dan 429. Setiap bucket Cloud Storage dilengkapi dengan kapasitas I/O awal. Untuk informasi lebih lanjut, baca Pedoman rasio permintaan dan distribusi akses.. Rencanakan peningkatan bertahap untuk permintaan coba lagi.

Pengelolaan penyimpanan

Bagian ini memberikan praktik terbaik untuk pengelolaan penyimpanan guna mendukung sistem Anda.

Tetapkan nama unik untuk setiap bucket

Buat nama unik untuk setiap bucket di seluruh namespace Cloud Storage. Jangan menyertakan informasi sensitif dalam nama bucket. Pilih bucket dan nama objek yang sulit ditebak. Untuk informasi selengkapnya, lihat pedoman penamaan bucket dan Panduan penamaan objek.

Jaga bucket Cloud Storage agar tetap pribadi

Pastikan bucket Cloud Storage Anda tidak dapat diakses secara anonim atau publik, kecuali jika ada alasan terkait bisnis. Untuk informasi selengkapnya, lihat Ringkasan kontrol akses.

Tetapkan nama objek acak untuk mendistribusikan beban secara merata

Tetapkan nama objek acak untuk memfasilitasi performa dan menghindari hotspotting. Gunakan awalan yang acak untuk objek jika memungkinkan. Untuk informasi selengkapnya, lihat Menggunakan konvensi penamaan yang mendistribusikan beban secara merata di seluruh rentang kunci.

Gunakan pencegahan akses publik

Untuk mencegah akses di tingkat organisasi, folder, project, atau bucket, gunakan pencegahan akses publik. Untuk informasi selengkapnya, lihat Menggunakan pencegahan akses publik.

Langkah selanjutnya

Pelajari layanan database Google Cloud dan praktik terbaik, termasuk:

• Pilih dan migrasikan database.
• Mengelola enkripsi database.
• Mengelola jaringan dan akses database.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Mengoptimalkan database

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy sistem Anda berdasarkan desain database. Anda akan mempelajari cara mendesain, memindahkan, dan menskalakan database, mengenkripsi informasi database, mengelola pemberian lisensi, dan memantau database untuk peristiwa Anda.

Layanan kunci enkripsi

Dokumen dalam kategori desain sistem Framework Arsitektur ini memberikan praktik terbaik yang mencakup berbagai layanan database Google Cloud. Tabel berikut memberikan ringkasan umum tentang layanan ini:

Layanan Google Cloud	Deskripsi
Cloud SQL	Layanan database terkelola sepenuhnya yang dapat Anda gunakan untuk menyiapkan, memelihara, mengelola, dan mengatur database relasional yang menggunakan Cloud SQL untuk PostgreSQL, Cloud SQL untuk MySQL, dan Cloud SQL untuk SQL Server. Cloud SQL menawarkan performa dan skalabilitas tinggi. Dihosting di Google Cloud Platform, Cloud SQL menyediakan infrastruktur database untuk aplikasi yang dapat berjalan di mana saja.
Bigtable	Tabel yang dapat diskalakan hingga miliaran baris dan ribuan kolom, sehingga memungkinkan Anda dapat menyimpan data hingga petabyte. Satu nilai di setiap baris terindeks; nilai ini dikenal sebagai row key. Gunakan Bigtable untuk menyimpan data dengan satu kunci dalam jumlah yang sangat besar dengan latensi yang sangat rendah. Hal tersebut mendukung throughput baca dan tulis yang tinggi pada latensi rendah, serta merupakan sumber data untuk operasi MapReduce.
Spanner	Layanan database perusahaan yang skalabel, terdistribusi secara global, dan dibuat untuk cloud yang mencakup struktur database relasional dan skala horizontal non-relasional. Kombinasi ini menghasilkan transaksi dan konsistensi berperforma tinggi di seluruh baris, region, dan benua. Spanner memberikan ketersediaan SLA 99,999%, tanpa periode nonaktif terencana, dan keamanan tingkat perusahaan.
Memorystore	Layanan Redis yang terkelola sepenuhnya untuk Google Cloud. Aplikasi yang berjalan di Google Cloud dapat meningkatkan performa menggunakan layanan Redis yang sangat tersedia, skalabel, dan aman tanpa mengelola deployment Redis yang rumit.
Firestore	Database dokumen NoSQL yang dibuat untuk penskalaan otomatis, performa tinggi, dan pengembangan aplikasi. Meskipun antarmuka Firestore memiliki banyak fitur yang sama seperti database tradisional, antarmuka Firestore merupakan database NoSQL dan mendeskripsikan hubungan antar-objek data secara berbeda.
Firebase Realtime Database	Database yang dihosting di cloud. Firebase menyimpan data sebagai JSON dan disinkronkan secara real time ke setiap klien yang terhubung. Ketika Anda mem-build aplikasi lintas platform dengan SDK iOS, Android, dan JavaScript kami, semua klien akan menggunakan satu instance Realtime Database yang sama dan menerima perubahan data terbaru secara otomatis.
Database open source	Partner Google menawarkan berbagai database open source, termasuk MongoDB, MariaDB, dan Redis.
AlloyDB untuk PostgreSQL	Layanan database yang kompatibel dengan PostgreSQL dan terkelola sepenuhnya untuk workload perusahaan dengan tuntutan tinggi. PostgreSQL memberikan performa hingga 4x lebih cepat untuk workload transaksional dan kueri analitis hingga 100x lebih cepat jika dibandingkan dengan PostgreSQL standar. AlloyDB untuk PostgreSQL menyederhanakan pengelolaan dengan sistem autopilot berkemampuan machine learning.

Pilihan database

Bagian ini memberikan praktik terbaik untuk memilih database yang mendukung sistem Anda.

Pertimbangkan untuk menggunakan layanan database terkelola

Evaluasi layanan database terkelola Google Cloud sebelum Anda menginstal database atau cluster database Anda sendiri. Menginstal database sendiri memerlukan overhead pemeliharaan termasuk menginstal patch dan update, serta mengelola aktivitas operasional harian seperti pemantauan dan melakukan pencadangan.

Gunakan persyaratan aplikasi fungsional dan non-fungsional untuk mendorong pemilihan database. Pertimbangkan akses latensi rendah, pemrosesan data deret waktu, pemulihan dari bencana, dan sinkronisasi klien seluler.

Untuk memigrasikan database, gunakan salah satu produk yang dijelaskan dalam tabel berikut:

Produk migrasi database	Deskripsi
Cloud SQL	Layanan regional yang mendukung replika baca di region terpencil, pembacaan latensi rendah, dan pemulihan dari bencana.
Spanner	Penawaran multi-regional yang memberikan konsistensi eksternal, replikasi global, dan 99,999% perjanjian tingkat layanan (SLA).
Bigtable	Layanan database NoSQL yang skalabel dan terkelola sepenuhnya untuk workload operasional dan analisis yang besar dengan ketersediaan hingga 99,999%
Memorystore	Layanan database terkelola sepenuhnya yang menyediakan versi terkelola dari dua solusi cache open source yang populer: Redis dan Memcached.
Firebase Realtime Database	Firebase Realtime Database adalah database NoSQL yang cloud-hosted dan dapat digunakan untuk menyimpan dan menyinkronkan data antarpengguna secara real-time.
Firestore	Database dokumen NoSQL yang dibuat untuk penskalaan otomatis, performa tinggi, dan kemudahan untuk mengembangkan aplikasi.
Open source	Opsi database alternatif termasuk MongoDB dan MariaDB.

Migrasi database

Untuk memastikan pengguna tidak mengalami periode nonaktif aplikasi saat Anda memigrasikan workload yang ada ke Google Cloud, Anda harus memilih teknologi database yang mendukung persyaratan Anda. Untuk mengetahui informasi tentang opsi dan praktik terbaik migrasi database, lihat Solusi migrasi database dan Praktik terbaik untuk migrasi database homogen.

Perencanaan untuk migrasi database meliputi hal berikut:

• Penilaian dan penemuan pada database saat ini.
• Definisi dari kriteria keberhasilan migrasi.
• Penyiapan lingkungan untuk migrasi dan database target.
• Pembuatan skema dalam database target.
• Migrasi data ke database target.
• Validasi migrasi untuk memverifikasi bahwa semua data dimigrasikan dengan benar dan ada di database.
• Pembuatan strategi rollback.

Pilih strategi migrasi

Memilih database target yang sesuai adalah salah satu kunci keberhasilan dari migrasi. Tabel berikut menyediakan opsi migrasi untuk beberapa kasus penggunaan:

Kasus penggunaan	Rekomendasi
Pengembangan baru di Google Cloud.	Pilih salah satu database terkelola yang di-build untuk cloud—Cloud SQL, Spanner, Bigtable, atau Firestore—untuk memenuhi persyaratan kasus penggunaan Anda.
Migrasi lift-and-shift.	Pilih layanan database terkelola yang kompatibel seperti Cloud SQL, MYSQL, PostgreSQL, atau SQLServer.
Aplikasi Anda memerlukan akses terperinci ke database yang tidak didukung oleh CloudSQL.	Jalankan database Anda di VM Compute Engine.

Gunakan Memorystore untuk mendukung lapisan database cache Anda

Memorystore adalah database Redis dan Memcached terkelola sepenuhnya yang mendukung latensi submilidetik. Memorystore sepenuhnya kompatibel dengan Redis dan Memcached Jika Anda menggunakan database cache ini di aplikasi Anda, Anda dapat menggunakan Memorystore tanpa membuat perubahan tingkat aplikasi dalam kode Anda.

Gunakan server Bare Metal untuk menjalankan database Oracle

Jika workload Anda memerlukan database Oracle, gunakan server Bare Metal yang disediakan oleh Google Cloud. Pendekatan ini cocok dengan strategi migrasi lift-and-shift.

Jika Anda ingin memindahkan workload Anda ke Google Cloud dan memodernisasikan setelah workload dasar pengukuran Anda berfungsi, pertimbangkan untuk menggunakan opsi database terkelola seperti Spanner, Bigtable, dan Firestore.

Database yang di-build untuk cloud adalah database terkelola modern yang di-build dari bawah ke atas di infrastruktur cloud. Database ini memberikan kemampuan default unik seperti skalabilitas dan ketersediaan tinggi, yang sulit dicapai jika Anda menjalankan database sendiri.

Modernisasi database Anda

Rencanakan strategi database Anda di awal proses desain sistem, baik saat akan mendesain aplikasi baru di cloud atau memigrasikan database yang sudah ada ke cloud. Google Cloud menyediakan opsi database terkelola untuk database open source seperti Cloud SQL untuk MySQLdan Cloud SQL untuk PostgreSQL. Sebaiknya gunakan migrasi sebagai peluang untuk memodernisasi database Anda dan menyiapkannya untuk mendukung kebutuhan bisnis di masa mendatang.

Gunakan database tetap dengan aplikasi siap pakai

Aplikasi Commercial off-the-shelf (COTS) memerlukan jenis database tetap dan konfigurasi tetap. Lift-and-shift biasanya merupakan pendekatan migrasi yang paling cocok untuk aplikasi COTS.

Verifikasi keahlian migrasi database tim Anda

Pilih pendekatan migrasi database cloud berdasarkan kemampuan dan keahlian migrasi database tim Anda. Gunakan Google Cloud Partner Advantage untuk menemukan partner yang dapat mendukung Anda di sepanjang perjalanan migrasi Anda.

Rancang database Anda untuk memenuhi persyaratan HA dan DR

Saat Anda merancang database untuk memenuhi persyaratan ketersediaan tinggi (HA) dan pemulihan dari bencana (DR), lakukan evaluasi keseimbangan antara keandalan dan biaya. Layanan database yang di-buid untuk cloud membuat beberapa salinan data Anda dalam satu atau beberapa region, bergantung pada database dan konfigurasinya.

Beberapa layanan Google Cloud memiliki varian multi-regional, seperti BigQuery dan Spanner. Agar tidak terganggu oleh kegagalan regional, gunakan layanan multi-regional ini dalam desain Anda jika memungkinkan.

Jika Anda mendesain database di VM Compute Engine, dan bukan menggunakan database terkelola di Google Cloud, pastikan Anda menjalankan beberapa salinan dari database Anda. Untuk informasi selengkapnya, lihat Desain untuk skala dan ketersediaan tinggi dalam kategori Keandalan.

Tentukan region cloud untuk mendukung residensi data

Residensi data menjelaskan lokasi data Anda secara fisik dalam penyimpanan. Pertimbangkan untuk memilih region cloud tertentu untuk men-deploy database berdasarkan persyaratan residensi data Anda.

Jika Anda men-deploy database di beberapa region, mungkin ada replikasi data di antara region, tergantung bagaimana cara Anda mengonfigurasinya. Pilih konfigurasi yang menyimpan data Anda dalam region yang diinginkan pada penyimpanan. Beberapa database, seperti Spanner, menawarkan replikasi multi-regional default. Anda juga dapat menerapkan residensi data dengan menetapkan kebijakan organisasi yang menyertakan batasan lokasi resource. Untuk informasi selengkapnya, lihat Membatasi Lokasi Resource.

Sertakan pemulihan dari bencana dalam desain residensi data

Sertakan Batas Waktu Pemulihan (RTO) dan Toleransi Durasi Kehilangan Data (RPO) dalam rencana residensi data Anda, dan pertimbangkan keseimbangan antara RTO/RPO serta biaya solusi pemulihan dari bencana. Jumlah RTO/RPO yang lebih kecil akan menghasilkan biaya yang lebih tinggi. Jika ingin sistem Anda pulih lebih cepat dari berbagai gangguan, biaya untuk mengoperasikannya akan lebih mahal. Selain itu, pertimbangkan kepuasan pelanggan ke dalam pendekatan pemulihan dari bencana untuk memastikan bahwa investasi keandalan Anda sesuai. Untuk informasi selengkapnya, baca artikel Keandalan 100% adalah target yang salah dan Panduan rencana pemulihan dari bencana.

Pastikan database Anda mematuhi kebijakan Google Cloud

Saat Anda memilih database untuk workload Anda, pastikan layanan yang dipilih memenuhi kepatuhan untuk region geografis tempat Anda beroperasi dan tempat data Anda disimpan secara fisik. Untuk informasi selengkapnya tentang sertifikasi dan standar kepatuhan Google, lihat Penawaran kepatuhan.

Enkripsi

Bagian ini memberikan praktik terbaik untuk mengidentifikasi persyaratan enkripsi dan memilih strategi kunci enkripsi untuk mendukung sistem Anda.

Tentukan persyaratan enkripsi

Persyaratan enkripsi Anda bergantung pada beberapa faktor, termasuk kebijakan keamanan perusahaan dan persyaratan kepatuhan. Semua data yang disimpan di Google Cloud dienkripsi dalam penyimpanan secara default, tanpa memerlukan tindakan dari Anda, menggunakan AES256. Untuk informasi selengkapnya, lihat Enkripsi dalam penyimpanan di Google Cloud.

Pilih strategi kunci enkripsi

Tentukan apakah Anda ingin mengelola kunci enkripsi sendiri atau ingin menggunakan layanan terkelola. Google Cloud mendukung kedua skenario tersebut. Jika Anda menginginkan layanan terkelola sepenuhnya untuk mengelola kunci enkripsi Anda di Google Cloud, pilih Cloud Key Management Service (Cloud KMS). Jika Anda ingin mengelola kunci enkripsi untuk mempertahankan kontrol lebih besar atas siklus proses kunci, gunakan Customer-managed encryption keys (CMEK.

Untuk membuat dan mengelola kunci enkripsi Anda di luar Google Cloud, pilih salah satu opsi berikut:

• Jika Anda menggunakan akselerator solusi untuk mengelola kunci, gunakan Cloud External Key Manager.
• Jika Anda mengelola kunci secara lokal dan ingin menggunakan kunci tersebut untuk mengenkripsi data di Google Cloud, importkunci tersebut ke Cloud KMS baik sebagai kunci KMS atau kunci Hardware Key Module (HSM). Gunakan kunci tersebut untuk mengenkripsi data Anda di Google Cloud.

Desain database dan penskalaan

Bagian ini memberikan praktik terbaik untuk mendesain dan penskalaan database guna mendukung sistem Anda.

Gunakan metrik pemantauan untuk menilai kebutuhan penskalaan

Gunakan metrik dari alat dan lingkungan pemantauan yang sudah ada untuk menetapkan pemahaman dasar tentang ukuran database dan persyaratan penskalaan. Sebagai contoh, menentukan ukuran yang tepat dan merancang strategi penskalaan untuk instance database Anda.

Untuk desain database baru, tentukan jumlah penskalaan berdasarkan beban dan pola traffic yang diharapkan dari aplikasi penyaluran. Untuk informasi selengkapnya, lihat Pemantauan instance Cloud SQL, Pemantauan dengan Cloud Monitoring, dan Pemantauan instance.

Jaringan dan akses

Bagian ini memberikan praktik terbaik untuk mengelola jaringan dan akses untuk mendukung sistem Anda.

Jalankan database di dalam jaringan pribadi

Jalankan database di dalam jaringan pribadi Anda dan berikan akses terbatas hanya kepada klien yang perlu berinteraksi dengan database tersebut. Anda dapat membuat instance Cloud SQL di dalam VPC Google Cloud juga menyediakan Kontrol Layanan VPC untuk database Cloud SQL, Spanner, dan Bigtable database untuk memastikan bahwa akses ke resource ini dibatasi hanya untuk klien dalam jaringan VPC yang diotorisasi.

Berikan hak istimewa minimum kepada pengguna

Identity and Access Management (IAM) mengontrol akses ke layanan Google Cloud, termasuk layanan database. Untuk memperkecil risiko akses yang tidak diinginkan, berikan hak istimewa dengan jumlah yang paling sedikit kepada pengguna Anda. Untuk akses tingkat aplikasi ke database Anda, gunakan akun layanan dengan hak istimewa yang paling sedikit.

Otomatisasi dan penyesuaian ukuran

Bagian ini menampilkan praktik terbaik untuk menentukan otomatisasi dan ukuran yang tepat untuk mendukung sistem Anda

Tentukan instance database sebagai kode

Salah satu manfaat bermigrasi ke Google Cloud adalah kemampuan untuk mengotomatisasikan infrastruktur dan aspek lainya dari workload Anda seperti lapisan compute dan database. Google Deployment Manager dan alat pihak ketiga seperti Terraform Cloud dapat Anda gunakan untuk menentukan instance database sebagai kode, sehingga Anda dapat menerapkan pendekatan yang konsisten dan dapat diulang untuk membuat dan memperbarui database.

Gunakan Liquibase untuk mengontrol versi database Anda

Layanan database Google seperti Cloud SQL dan Spanner mendukung Liquibase, alat kontrol versi open source untuk database. Liquibase membantu Anda untuk melacak perubahan skema database, perubahan skema roll back, dan melakukan migrasi berulang.

Uji dan sesuaikan database Anda untuk mendukung penskalaan

Lakukan uji beban pada instance database Anda dan sesuaikan berdasarkan hasil pengujian untuk memenuhi persyaratan aplikasi Anda. Tentukan skala awal database Anda dengan melakukan uji beban pada indikator performa utama (KPI) atau dengan menggunakan KPI pemantauan yang berasal dari database Anda saat ini.

Saat Anda membuat instance database, mulailah dengan ukuran yang didasarkan pada hasil pengujian atau metrik pemantauan historis. Uji instance database Anda dengan muatan yang diharapkan di cloud. Kemudian, sempurnakan instance hingga Anda mendapatkan hasil yang diinginkan untuk beban yang diharapkan pada instance database Anda.

Pilih database yang tepat untuk kebutuhan penskalaan Anda.

Penskalaan database berbeda dengan penskalaan komponen lapisan komputasi. Database memiliki status ketika satu instance dari database Anda tidak dapat menangani muatan, pertimbangkan strategi yang tepat untuk instance database Anda. Strategi penskalaan berbeda-beda bergantung pada jenis database.

Gunakan tabel berikut untuk mempelajari tentang produk Google yang menangani kasus penggunaan penskalaan.

Kasus penggunaan	Produk yang direkomendasikan	Deskripsi
Skalakan instance database Anda secara horizontal dengan menambahkan node ke database Anda saat Anda perlu meningkatkan skala kapasitas serving dan penyimpanan.	Spanner	Database relasional yang di-build untuk cloud.
Tambahkan node untuk menskalakan database Anda.	Bigtable	Layanan database big data NoSQL yang terkelola sepenuhnya.
Menangani penskalaan database secara otomatis.	Firestore	Database yang fleksibel dan skalabel untuk pengembangan seluler, web, dan server.
Untuk menayangkan lebih banyak kueri, tingkatan skala instance database Cloud SQL secara vertikal guna membekali mereka kapasitas komputasi dan memori lebih banyak. Di Cloud SQL, lapisan penyimpanan dipisahkan dari instance database. Anda dapat memilih untuk menskalakan lapisan penyimpanan Anda secara otomatis setiap kali mendekati kapasitas.	Cloud SQL	Layanan database yang terkelola sepenuhnya membantu Anda menyiapkan, memelihara, mengelola, dan mengatur database relasional Anda pada Google Cloud.

Operasi

Bagian ini menampilkan praktik terbaik untuk pengoperasianl guna mendukung sistem Anda.

Gunakan Cloud Monitoring untuk memantau dan menyiapkan pemberitahuan untuk database Anda

Gunakan Cloud Monitoring untuk memantau Instance database Anda dan menyiapkan pemberitahuan untuk memberi tahu tim yang sesuai terkait peristiwa yang terjadi. Untuk mengetahui pemberitahuan praktik terbaik, baca Bangun pemberitahuan efisien.

Semua database yang di-build untuk cloud menyediakan metrik logging dan pemantauan. Setiap layanan menyediakan dasbor untuk memvisualisasikan metrik logging dan pemantauan. Metrik pemantauan untuk semua layanan terintegrasi dengan Kemampuan Observasi Google Cloud. Spanner menyediakan alat introspeksi kueri seperti Key Visualizer untuk proses debug dan analisis akar masalah. Key Visualizer menyediakan kemampuan sebagai berikut:

• Membantu Anda menganalisis pola penggunaan Spanner dengan membuat laporan visual untuk database Anda. Laporan tersebut menampilkan pola penggunaan berdasarkan rentang baris dari waktu ke waktu.
• Memberikan insight tentang pola penggunaan dalam skala besar.

Bigtable juga menyediakan alat diagnostik Key Visualizer yang membantu Anda menganalisis pola penggunaan instance Bigtable

Pemberian Lisensi

Bagian ini menampilkan praktik terbaik terkait pemberian lisensi guna mendukung sistem Anda.

Pilih antara lisensi on demand dan lisensi yang sudah ada

Jika Anda menggunakan Cloud SQL untuk SQL Server, bring your own license tidak didukung, biaya lisensi Anda didasarkan pada penggunaan inti perjam.

Jika Anda ingin menggunakan lisensi Cloud SQL untuk SQL Server yang sudah ada, pertimbangkan untuk menjalankan Cloud SQL untuk SQL Server di VM Compute. Untuk mengetahui informasi lebih lanjut baca Lisensi Microsoft dan Memilih antara lisensi on demand dan membawa lisensi yang sudah ada..

Jika Anda menggunakan Oracle dan jika Anda bermigrasi ke Solusi Bare Metal untuk Oracle, Anda dapat membawa Lisensi sendiri. Untuk informasi lebih lanjut, lihat Rencana untuk Solusi Bare Metal.

Jadwal migrasi, metodologi, dan kumpulan alat

Bagian ini menampilkan praktik terbaik untuk merencanakan dan mendukung migrasi database Anda guna mendukung sistem Anda.

Menentukan kesiapan modernisasi database

Lakukan penilaian apakah organisasi Anda siap untuk modernisasi database dan menggunakan database yang dibuat untuk cloud.

Pertimbangkan modernisasi database saat Anda merencanakan linimasa migrasi overload karena modernisasi kemungkinan akan mempengaruhi sisi aplikasi Anda.

Libatkan pemangku kepentingan yang relevan dalam perencanaan migrasi

Untuk memigrasikan database, selesaikan tugas berikut:

• Siapkan database target.
• Konversi skema.
• Siapkan replikasi data antara database sumber dan target.
• Lakukan debug masalah yang muncul selama migrasi.
• Tetapkan konektivitas jaringan antara lapisan aplikasi dan database.
• Implementasikan keamanan database target.
• Pastikan aplikasi terhubung ke database target.

Tugas ini sering kali memerlukan keterampilan yang berbeda, dan beberapa tim berkolaborasi di seluruh organisasi Anda untuk menyelesaikan migrasi. Saat Anda merencanakan migrasi, sertakan pemangku kepentingan dari semua tim, seperti developer aplikasi, administrator database, serta tim infrastruktur dan keamanan.

Jika tim Anda tidak memiliki keterampilan untuk mendukung jenis migrasi ini, partner Google dapat membantu Anda melakukan migrasi. Untuk informasi selengkapnya, baca Google Cloud Partner Advantage.

Identifikasi sekumpulan alat untuk migrasi homogen dan heterogen

Migrasi homogen adalah migrasi data antara database sumber dan target dari teknologi database yang sama. Migrasi heterogen adalah migrasi yang database targetnya berbeda dari database sumber.

Migrasi heterogen biasanya melibatkan langkah tambahan konversi skema dari database sumber ke jenis mesin database target. Tim database Anda harus menilai tantangan yang terlibat dalam konversi skema karena tantangan tersebut bergantung pada kompleksitas skema database sumber.

Uji dan validasi setiap langkah dalam migrasi data

Migrasi data melibatkan beberapa langkah. Untuk meminimalkan error migrasi, uji dan validasi setiap langkah dalam migrasi sebelum melanjutkan ke langkah berikutnya, Faktor-faktor berikut mendorong proses migrasi:

• Apakah migrasi homogen atau heterogen.
• Jenis alat dan keahlian apa yang Anda miliki untuk melakukan migrasi.
• Untuk migrasi heterogen, pelajari pengalaman Anda dengan mesin database target.

Tentukan persyaratan replikasi data berkelanjutan

Buat rencana untuk memigrasikan data awal dan kemudian replikasikan data secara terus menerus dari database sumber ke target. Lanjutkan replikasi hingga target stabil dan aplikasi sepenuhnya dimigrasikan ke database baru. Rencana ini membantu Anda mengidentifikasi potensi periode nonaktif selama peralihan database dan membuat perencanaan yang sesuai.

Jika Anda merencanakan untuk memigrasikan mesin database dari Cloud SQL, Cloud SQL untuk MySQL, atau Cloud SQL untuk PostgreSQL, gunakan Database Migration Service untuk mengotomatisasi ini dengan cara terkelola sepenuhnya. Untuk informasi tentang alat pihak ketiga yang mendukung jenis migrasi lainnya, lihat Cloud Marketplace.

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda, sebaiknya lakukan hal berikut:

• Multi-tenancy untuk database melibatkan penyimpanan data dari beberapa pelanggan dalam infrastruktur bersama, dalam hal ini database. Jika Anda menawarkan software-as-a-service (SaaS) berdasarkan penawaran kepada pelanggan Anda, pastikan bahwa Anda memahami bagaimana Anda dapat secara logis mengisolasi set data milik pelanggan yang berbeda, dan mendukung akses persyaratan mereka. Selain itu, evaluasi persyaratan Anda berdasarkan tingkat pemisahan.

  Untuk database relasional seperti Spanner dan Cloud SQL, ada beberapa pendekatan, seperti mengisolasi data tenant pada tingkat instance database, tingkat database, tingkat skema, atau tingkat tabel database. Seperti keputusan desain lainnya, ada kompromi antara tingkat isolasi dan faktor lainnya seperti biaya dan performa. IAM kebijakan mengontrol akses ke instansi database Anda.

• Pilih database yang tepat untuk persyaratan model data Anda.

• Pilih nilai kunci untuk menghindari hotspotting kunci. Hotspot adalah lokasi di dalam tabel yang menerima lebih banyak permintaan akses daripada lokasi lain. Untuk informasi selengkapnya tentang hotspot, lihat Praktik terbaik desain skema.

• Lakukan sharding terhadap instance database Anda jika memungkinkan.

• Gunakan praktik terbaik pengelolaan koneksi, seperti penggabungan koneksi dan backoff eksponensial.

• Hindari transaksi yang sangat besar.

• Rancang dan uji respons aplikasi Anda terhadap update pemeliharaan pada database.

• Amankan dan isolasikan koneksi ke database Anda.

• Perhitungkan ekspektasi database dan pertumbuhan Anda untuk memastikan database tersebut mendukung kebutuhan Anda.

• Uji strategi failover HA dan DR Anda.

• Lakukan pencadangan dan pemulihan serta ekspor dan impor sehingga Anda memahami prosesnya.

Rekomendasi Cloud SQL

• Gunakan jaringan alamat IP pribadi Untuk keamanan tambahan, pertimbangkan hal berikut:
  • Gunakan Cloud SQL Auth proxy untuk mendukung jaringan pribadi.
  • Batasi akses alamat IP publik constraints/sql.restrictPublicIp.
• Jika Anda memerlukan jaringan alamat IP publik, pertimbangkan hal berikut:
  • Gunakan firewall bawaan dengan daftar alamat IP terbatas atau dengan rentang sempit, dan pastikan instance Cloud SQL mengharuskan koneksi yang masuk menggunakan SSL. Untuk informasi selengkapnya, lihat Mengonfigurasi sertifikat SSL/TLS.
• Untuk keamanan tambahan, pertimbangkan hal berikut:
  • Jangan memberikan akses umum. Sebagai gantinya, gunakan proxy Cloud SQL Auth.
  • Batasi jaringan yang diizinkan constraints/sql.restrictAuthorizedNetworks.
• Gunakan hak istimewa terbatas untuk pengguna database.

Langkah selanjutnya

Pelajari praktik terbaik analisis data, termasuk yang berikut:

• Pelajari prinsip-prinsip inti analisis data dan layanan utama Google Cloud.
• Pelajari siklus data.
• Pelajari cara menyerap data.
• Pilih dan kelola penyimpanan data.
• Proses dan transformasikan data.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Analisis data Anda

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan beberapa prinsip inti dan praktik terbaik untuk analisis data di Google Cloud. Anda akan mempelajari beberapa layanan analisis data utama, dan bagaimana layanan tersebut dapat membantu di berbagai tahap siklus proses data. Praktik terbaik ini membantu Anda memenuhi kebutuhan analisis data dan membuat desain sistem Anda.

Prinsip inti

Bisnis ingin menganalisis data dan menghasilkan hasil analisis yang bisa ditindaklanjuti dari data tersebut. Google Cloud menyediakan berbagai layanan yang membantu Anda menangani seluruh siklus proses pendataan, mulai dari penyerapan data hingga laporan dan visualisasi. Sebagian besar layanan ini dikelola sepenuhnya, dan ada di antaranya yang beroperasi serverless. Anda juga dapat mem-build dan mengelola lingkungan analisis data di VM Compute Engine, seperti menghosting sendiri Apache Hadoop atau Beam.

Fokus khusus, keahlian tim, dan pandangan strategis membantu Anda menentukan layanan Google Cloud yang digunakan untuk mendukung kebutuhan analisis data Anda. Misalnya, Dataflow memungkinkan Anda menulis transformasi kompleks dalam pendekatan serverless, tetapi Anda harus mengandalkan versi konfigurasi opini untuk kebutuhan komputasi dan pemrosesan. Atau, Dataproc memungkinkan Anda menjalankan transformasi yang sama, tetapi Anda mengelola cluster dan menyesuaikan tugas sendiri.

Dalam desain sistem Anda, pikirkan strategi pemrosesan yang digunakan tim Anda, seperti ekstrak, transformasi, load (ETL) atau ekstrak, load, transformasi (ELT). Desain sistem Anda juga harus mempertimbangkan apakah Anda perlu memproses analisis batch atau analisis streaming. Google Cloud menyediakan platform data terpadu, dan memungkinkan Anda mem-build data lake atau data warehouse untuk memenuhi kebutuhan bisnis Anda.

Layanan utama

Tabel berikut memberikan ringkasan umum tentang layanan analisis Google Cloud:

Layanan Google Cloud	Deskripsi
Pub/Sub	Fondasi sederhana, andal, dan skalabel untuk analisis stream dan sistem komputasi berbasis peristiwa.
Dataflow	Layanan terkelola sepenuhnya untuk mengubah dan memperkaya data dalam mode streaming (real time) dan batch (historis).
Dataprep by Trifacta	Layanan data cerdas untuk menjelajahi, membersihkan, dan menyiapkan data terstruktur dan tidak terstruktur secara visual untuk analisis.
Dataproc	Layanan cloud yang cepat, mudah digunakan, dan terkelola sepenuhnya untuk menjalankan cluster Apache Spark dan Apache Hadoop.
Cloud Data Fusion	Layanan integrasi data terkelola sepenuhnya yang dibangun untuk cloud dan memungkinkan Anda membangun serta mengelola pipeline data ETL/ELT. Cloud DataFusion menyediakan grafis antarmuka dan library open source yang luas dari konektor dan transformasi yang telah dikonfigurasi sebelumnya.
BigQuery	Data warehouse yang terkelola sepenuhnya, hemat biaya, dan serverless yang dapat diskalakan dengan kebutuhan penyimpanan dan daya komputasi Anda. BigQuery adalah database berbasis kolom dan ANSI SQL yang dapat menganalisis data berukuran terabyte hingga petabyte.
Cloud Composer	Layanan orkestrasi alur kerja yang terkelola sepenuhnya, yang memungkinkan Anda membuat, menjadwalkan, dan memantau pipeline yang mencakup cloud dan pusat data lokal.
Data Catalog	Layanan pengelolaan metadata yang skalabel dan terkelola sepenuhnya, yang membantu Anda menemukan, mengelola, dan memahami semua data Anda.
Looker Studio	Layanan analisis visual yang terkelola sepenuhnya dapat membantu Anda membuka insight dari data melalui dasbor interaktif.
Looker	Platform perusahaan yang menghubungkan, menganalisis, dan memvisualisasikan data di seluruh lingkungan multi-cloud.
Dataform	Produk yang terkelola sepenuhnya untuk membantu Anda berkolaborasi, membuat, dan men-deploy data pipeline, serta memastikan kualitas data.
Dataplex	Layanan data lake terkelola yang mengelola, memantau, dan mengatur data secara terpusat di seluruh data lake, data warehouse, dan data mart menggunakan kontrol yang konsisten.
AnalyticsHub	Platform yang bertukar aset analisis data secara efisien dan aman di seluruh organisasi Anda untuk mengatasi tantangan keandalan dan biaya data.

Siklus proses data

Saat membuat desain sistem, Anda dapat mengelompokkan layanan analisis data Google Cloud mengikuti pergerakan data umum di sistem apa pun, atau mengikuti siklus proses data.

Siklus proses data mencakup tahapan dan layanan contoh berikut:

• Penyerapan mencakup layanan seperti Pub/Sub, Storage Transfer Service, Transfer Appliance, dan BigQuery.
• Penyimpanan mencakup layanan seperti Cloud Storage, Bigtable, Memorystore, and BigQuery.
• Pemrosesan dan transformasi mencakup layanan seperti Dataflow, Dataproc, Dataprep, Sensitive Data Protection, dan BigQuery.
• Analisis dan warehousing mencakup layanan seperti BigQuery.
• Pelaporan dan visualisasi mencakup layanan seperti Looker Studio dan Looker.

Tahapan dan layanan berikut berjalan di seluruh siklus proses data:

• Integrasi data mencakup layanan seperti Data Fusion.
• Pengelolaan dan tata kelola metadata mencakup layanan seperti Data Catalog.
• Pengelolaan alur kerja mencakup layanan seperti Cloud Composer.

Penyerapan data

Terapkan praktik terbaik penyerapan data berikut di lingkungan Anda sendiri.

Tentukan sumber data untuk penyerapan

Data biasanya berasal dari penyedia atau layanan cloud lain, atau dari lokasi lokal:

• Untuk menyerap data dari penyedia cloud lain, Anda dapat menggunakan Cloud Data Fusion, Storage Transfer Service, or BigQuery Transfer Service.

• Untuk penyerapan data lokal, pertimbangkan volume data yang akan diserap dan keahlian tim Anda. Jika tim Anda lebih menyukai pendekatan antarmuka pengguna grafis (GUI) dengan sedikit kode, gunakan Cloud Data Fusion dengan konektor yang sesuai, seperti Java Database Connectivity (JDBC). Untuk volume data yang besar, Anda dapat menggunakan Transfer Appliance atau Storage Transfer Service.

Pertimbangkan cara yang Anda inginkan untuk memproses data setelah Anda menyerapnya. Misalnya, Storage Transfer Service hanya menulis data ke bucket Cloud Storage, dan BigQuery Data Transfer Service hanya menulis data ke set data BigQuery. Cloud Data Fusion mendukung beberapa tujuan.

Identifikasi sumber data streaming atau batch

Pertimbangkan bagaimana Anda perlu menggunakan data Anda dan kenali dimana Anda memiliki kasus penggunaan streaming atau batch. Misalnya, jika Anda menjalankan layanan streaming global yang memiliki persyaratan latensi rendah, Anda dapat menggunakan Pub/Sub. Jika memerlukan data untuk penggunaan analisis dan pelaporan, Anda dapatmelakukan streaming data ke BigQuery.

Jika Anda perlu melakukan streaming data dari sistem seperti Apache Kafka di lingkungan lokal atau cloud lainnya, gunakan Template Kafka ke Dataflow BigQuery. Untuk workload batch, langkah pertama biasanya adalah menyerap data ke Cloud Storage. Gunakan alat gsutil atau Storage Transfer Service untuk menyerap data.

Serap data dengan alat otomatis

Memindahkan data secara manual dari sistem lain ke cloud bisa menjadi sebuah tantangan. Jika memungkinkan, gunakan alat yang dapat mengotomatiskan proses penyerapan data. Misalnya, Cloud Data Fusion menyediakan konektor dan plugin untuk membawa data dari sumber eksternal dengan GUI tarik lalu lepas. Jika tim Anda ingin menulis beberapa kode, Data Flow atau BigQuery dapat membantu mengotomatiskan penyerapan data. Pub/Sub dapat membantu dalam pendekatan sedikit kode atau yang mendahulukan kode. Untuk menyerap data ke dalam bucket penyimpanan, gunakan gsutil untuk ukuran data hingga 1 TB. Untuk menyerap jumlah data yang lebih besar dari 1 TB, gunakan Storage Transfer Service.

Gunakan alat migrasi untuk menyerap dari data warehouse lain

Jika Anda perlu bermigrasi dari sistem data warehouse lain, seperti Teradata, Netezza, atau Redshift, Anda dapat menggunakan BigQuery Data Transfer Service bantuan migrasi. BigQuery Data Transfer Service juga menyediakan transfer pihak ketiga yang membantu Anda menyerap data sesuai jadwal dari sumber eksternal. Untuk informasi selengkapnya, baca pendekatan migrasi mendetail untuk setiap data warehouse.

Perkirakan kebutuhan penyerapan data Anda

Volume data yang perlu diserap membantu Anda menentukan layanan mana yang akan digunakan dalam desain sistem. Untuk penyerapan streaming data, Pub/Sub menskalakan hingga puluhan gigabyte per detik. Persyaratan regional, kapasitas, dan penyimpanan untuk data Anda membantu menentukan apakah Pub/Sub Lite merupakan opsi yang lebih baik untuk desain sistem Anda atau tidak. Untuk mengetahui informasi selengkapnya, baca artikel Memilih Pub/Sub atau Pub/Sub Lite.

Untuk penyerapan batch data, perkirakan jumlah total data yang ingin Anda transfer, dan seberapa cepat Anda ingin melakukannya. Tinjau opsi migrasi yang tersedia, termasuk perkiraan waktu dan perbandingan transfer online versus offline.

Gunakan alat yang sesuai untuk secara teratur menyerap data sesuai jadwal

Storage Transfer Service dan BigQuery Data Transfer Service dapat Anda gunakan untuk menjadwalkan tugas penyerapan. Untuk kontrol yang lebih mendetail terkait waktu penyerapan atau sistem sumber dan tujuan, gunakan sistem manajemen alur kerja seperti Cloud Composer. Jika Anda lebih menginginkan pendekatan yang manual, gunakan Cloud Scheduler dan Pub/Sub untuk memicu Cloud Function.
Jika ingin mengelola infrastruktur Compute, Anda dapat menggunakan perintah gsutil dengan cron untuk transfer data maksimal 1 TB. Jika Anda menggunakan pendekatan manual ini, daripada Cloud Composer, ikuti praktik terbaik untuk membuat skrip transfer produksi.

Tinjau kebutuhan penyerapan data server FTP/SFTP

Jika memerlukan lingkungan bebas kode untuk menyerap data dari server FTP/SFTP, Anda dapat menggunakan salinan plugin FTP. Jika Anda ingin memperbarui dan membuat solusi alur kerja jangka panjang, Cloud Composer adalah layanan terkelola sepenuhnya yang memungkinkan Anda membaca dan menulis dari berbagai sumber dan sink.

Gunakan konektor Apache Kafka untuk menyerap data

Jika Anda menggunakan Pub/Sub, Dataflow, atau BigQuery, Anda dapat menyerap data menggunakan salah satu konektor Apache Kafka. Misalnya, konektor open source Kafka Pub/Sub dapat Anda gunakan untuk menyerap data dari Pub/Sub atau Pub/Sub Lite.

Referensi tambahan

• Praktik terbaik agen Cloud Storage Transfer Service
• Cara menyerap data ke BigQuery agar Anda dapat menganalisisnya
• Menyerap data klinis dan operasional dengan Cloud Data Fusion
• Mengoptimalkan penyerapan peristiwa dan log analisis dalam skala besar

Penyimpanan data

Terapkan praktik terbaik penyimpanan databerikut di lingkungan Anda sendiri.

Memilih penyimpanan data yang sesuai dengan kebutuhan Anda

Untuk membantu Anda memilih jenis solusi penyimpanan yang akan digunakan, ditinjau, dan dipahami penggunaan data downstream Anda. Kasus umum penggunaan data Anda berikut memberikan rekomendasi produk Google Cloud yang akan digunakan:

Kasus penggunaan data	Rekomendasi produk
Berbasis file	Filestore
Berbasis objek	Cloud Storage
Latensi rendah	Bigtable
Deret waktu	Bigtable
Cache online	Memorystore
Pemrosesan transaksi	Cloud SQL
Business intelligence (BI) & analisis	BigQuery
Batch processing	Cloud Storage Bigtable jika data yang masuk adalah deret waktu dan Anda memerlukan akses latensi rendah ke data tersebut. BigQuery jika Anda menggunakan SQL.

Tinjau kebutuhan struktur data Anda

Untuk sebagian besar data yangtidak terstruktur seperti dokumen dan teks file, audio dan file video, atau logs, . Anda kemudian dapat memuat dan memproses data dari penyimpanan objek saat Anda membutuhkannya.

Untuk data semi-terstruktur seperti XML atau JSON, kasus penggunaan dan pola akses data membantu memandu pilihan Anda. Anda dapat memuat set data tersebut ke BigQuery untuk deteksi skema secara otomatis. Jika Anda memiliki persyaratan latensi rendah, Anda dapat memuat data JSON ke Bigtable Jika Anda memiliki persyaratan lama atau aplikasi bekerja dengan database relasional, Anda juga dapat memuat set data ke dalam penyimpanan relasi.

Untuk data terstruktur, seperti CSV, Parquet, Avro, or ORC, Anda dapat menggunakan BigQuery jika Anda memiliki BI dan persyaratan analisis yang menggunakan SQL. Untuk informasi selengkapnya, lihat cara memuat data secara kelompok. Jika Anda ingin membuat data lake pada standar dan teknologi terbuka, Anda dapat menggunakan Cloud Storage.

Migrasikan data dan kurangi biaya untuk HDFS

Cari cara untuk memindahkan data Hadoop Distributed File System (HDFS) dari penyedia lokal atau cloud lain ke sistem penyimpanan yang lebih murah. Cloud Storage adalah pilihan yang paling umum yang di pakai sebagai tempat penyimpanan data alternatif Untuk informasi tentang kelebihan dan kekurangan pilihan ini, lihat HDFS vs. Cloud Storage.

Anda dapat memindahkan data dengan metode push atau pull. Kedua metode tersebut menggunakan perintah hadoop distcp. Untuk informasi selengkapnya, lihat Memigrasikan Data HDFS dari Lokal ke Google Cloud.

konektor Cloud Storage open source untuk mengizinkan tugas Hadoop dan Spark mengakses data di Cloud Storage Konektor tersebut diinstal secara default di cluster Dataproc dan dapat diinstal secara manual di cluster lain.

Gunakan penyimpanan objek untuk mem-build data lake yang kohesif

Data lake adalah repositori terpusat yang didesain untuk menyimpan dan mengamankan sejumlah besar data terstruktur, semi-terstruktur, dan tidak terstruktur. Anda dapat menggunakan Cloud Composer dan Cloud Data Fusion untuk membangun data lake.

Untuk membangun sebuah platform data modern, Anda dapat menggunakan BigQuery sebagai sumber pusat data, bukan dari Cloud Storage. BigQuery adalah data warehouse modern dengan penyimpanan dan komputasi yang terpisah. Data yang dibangun di BigQuery memungkinkan Anda melakukan analisis dari BigQuery ke konsol Cloud. Data tersebut juga memungkinkan Anda mengakses data yang disimpan dari framwork lain seperti Apache Spark.

Referensi tambahan

• Praktik terbaik untuk Cloud Storage
• Praktik terbaik untuk pengoptimalan biaya Cloud Storage
• Praktik terbaik untuk memastikan privasi dan keamanan data Anda di Cloud Storage
• Praktik terbaik untuk Memorystore
• Mengoptimalkan penyimpanan di BigQuery
• Desain skema Bigtable

Proses dan transformasikan data

Terapkan praktik terbaik analisis data berikut ini di lingkungan Anda sendiri saat memproses dan mengubah data.

Pelajari software open source yang dapat Anda gunakan di Google Cloud

Banyak layanan Google Cloud yang menggunakan software open source untuk membuat transisi Anda menjadi lancar. Google Cloud menawarkan solusi terkelola dan serverless yang memiliki API Open Source dan kompatibel dengan framework open source untuk mengurangi ketergantungan vendor.

Dataproc adalah layanan terkelola yang kompatibel dengan Hadoop yang memungkinkan Anda untuk menghosting software open source, dengan beban operasional yang kecil. Dataproc menyertakan dukungan untuk Spark, Hive, Pig, Presto, and Zookeeper. Dataproc juga menyediakan Hive Metastore sebagai layanan terkelola untuk menghapus dirinya sendiri sebagai titik tunggal kegagalan di ekosistem Hadoop

Anda dapat bermigrasi ke Dataflow jika saat ini Anda menggunakan Apache Beam sebagai mesin pemrosesan batch dan streaming. Dataflow adalah layanan terkelola sepenuhnya dan serverless yang menggunakan Apache Beam. Gunakan Dataflow untuk menulis pekerjaan di Beam tetapi biarkan Google Cloud mengatur lingkungan eksekusi.

Jika Anda menggunakan CDAP sebagai platform integrasi data, Anda dapat bermigrasi ke Cloud Data Fusion untuk pengalaman yang terkelola sepenuhnya.

Tentukan kebutuhan pemrosesan data ETL atau ELT Anda

Pengalaman dan preferensi tim Anda membantu Anda menentukan desain sistem untuk cara memproses data. Google Cloud memungkinkan Anda menggunakan salah satu dari ETL tradisional atau ELT yang lebih modern dalam sistem pemrosesan data.

• Untuk pipline ETL Anda dapat menggunakan Data Fusion, Dataproc, atau Dataflow.

  • Untuk lingkungan baru, kami merekomendasikan Dataflow untuk Cara terpadu untuk membuat aplikasi batch dan steaming .
  • Untuk pendekatan terkelola sepenuhnya, Data Fusion menawarkan tarik dan lepas GUI untuk membantu Anda membuat pipeline.

• Untuk pipeline ELT gunakan BIgQuery yang mendukung kedua beban data batch dan streaming. Setelah data Anda berada di BigQuery, gunakan SQL untuk menjalankan seluruh transformasi untuk memperoleh set data baru untuk kasus penggunaan bisnis Anda.

• Jika Anda ingin memodernisasikan dan memindahkan dari ETL ke ELT, Anda dapat menggunakan Dataform.

Gunakan framework yang sesuai untuk kasus penggunaan data Anda

Kasus penggunaan data Anda menentukan alat dan framework mana yang akan digunakan. Beberapa produk Google Cloud dibuat untuk menangani semua kasus penggunaan data berikut ini sedangkan pendukung terbaik lain hanya satu kasus penggunaan tertentu.

• Untuk pemrosesan sistem data batch, Anda dapat memproses dan mengubah data di BigQuery dengan antarmuka SQL yang umum diketahui Jika Anda sudah memiliki pipeline yang berjalan di Apache Hadoop atau Spark lokal atau di publik lainnya, Anda dapat menggunakan Dataproc.
  • Anda juga dapat menggunakan Dataflow jika menginginkan grafis pemrograman terpadu untuk kedua kasus penggunaan batch dan streaming. Kami merekomendasikan Anda untuk memodernisasi dan menggunakan Dataflow untuk ETL dan BigQuery untuk ELT.

• Untuk melakukanstreaming data pipeline, gunakan layanan terkelola dan serverless seperti Dataflow yang menyediakan windowing, server otomatis, dan template. Untuk informasi selengkapnya, lihat Membangun pipeline data siap produksi menggunakan Dataflow.

  • Jika Anda memiliki tim dan kemampuan analisis yang berfokus pada analisis serta SQL, Anda juga dapat streaming data ke BigQuery.

• Untuk kasus penggunaan real-time , seperti analisis deret waktu atau analisis video streaming, gunakan Dataflow.

Pertahankan kendali di masa mendatang atas mesin eksekusi Anda

Untuk meminimalkan ketergantungan dengan vendor dan dapat menggunakan platform berbeda di masa mendatang, gunakan model pemrograman Apache Beam dan Dataflow sebagai solusi serverless terkelola Model pemrograman Beam memungkinkan Anda mengubah dasar mesin eksekusi, seperti mengubah Dataflow ke Apache Flink atau Apache Spark.

Gunakan Dataflow untuk menyerap data dari beberapa sumber

Untuk menyerap data dari beberapa sumber, seperti Pub/Sub, Cloud Storage, HDFS, S3, or Kafka, gunakan Dataflow. Dataflow adalah layanan serverless terkelola yang mendukung template Dataflow, yang memungkinkan team Anda menjalankan template dari alat yang berbeda.

Dataflow Prime menyediakan mesin server horizontal and vertikal that are yang digunakan dalam proses eksekusi pipeline. Dataflow Prime juga menyediakan diagnostik dan rekomendasi cerdas dalam mengidentifikasi masalah dan menyarankan cara memperbaikinya.

Temukan, identifikasi, dan lindungi data sensitif

Gunakan Sensitive Data Protection untuk memeriksa dan mengubah data terstruktur serta tidak terstruktur Sensitive Data Protection bekerja pada data yang terletak di manapun di Google Cloud, seperti di Cloud Storage atau database. Anda dapat mengklasifikasikan, menyamarkan, dan membuat token data sensitif Anda agar dapat terus menggunakan dengan aman untuk pemrosesan downstream. Gunakan Sensitive Data Protection untuk melakukan tindakan seperti, memindai data BigQuery atau melakukan de-identifikasi dan mengidentifikasi ulang PII dalam set data skala besar

Modernisasi proses transformasi data Anda

Gunakan Dataform untuk menulis transformasi data seperti kode dan untuk mulai menggunakan kontrol versi default. Anda juga dapat mengadopsi praktik terbaik pengembangan software seperti CI/CD, pengujian unit, dan kontrol versi ke kode SQL. Dataform mendukung semua produk dan database cloud data warehouse (CDW) seperti PostgreSQL.

Referensi Tambahan

• Dataproc
  • Panduan praktik terbaik
  • Tips cluster yang berjalan lama
  • Menggunakan Apache Hive di Dataproc
  • Praktik terbaik untuk menjalankan produksi
  • Praktik terbaik untuk menggunakan Apache Ranger
  • Rekomendasi konfigurasi penskalaan otomatis
  • Bantuan untuk slow Hadoop/Spark jobs
• Dataflow
  • Pindahkan pipeline ke produksi
  • Kasus penggunaan umum
• Data Fusion
  • Performa Pipeline
• BigQuery
  • Pengoptimalan performa kueri
• Dataform
  • Praktik terbaik untuk mengelola project
• Sensitive Data Protection
  • Menjaga biaya tetap terkendali
  • Memeriksa Penyimpanan dan Database untuk data sensitif
  • Memeriksa teks untuk data sensitif

Analisis data dan warehouse

Penerapan persiapan analisis data dan praktik terbaik warehouse untuk lingkungan Anda sendiri.

Tinjau kebutuhan penyimpanan data Anda

Data lake dan data warehouse tidak eksklusif terhadap satu sama lain. Data lake berguna untuk pemrosesan penyimpanan data tidak terstruktur dan semi-terstruktur. Data warehouse adalah data yang terbaik untuk analisis dan BI.

Tinjau data Anda untuk membantu menentukan tempat penyimpanan data dan produk Google Cloud mana yang paling sesuai untuk memproses dan menganalisis data Anda. Produk seperti BigQuery dapat memproses sebuah data PBs dan tumbuh sesuai permintaan Anda.

Identifikasi peluang untuk bermigrasi dari data warehouse tradisional ke BigQuery

Tinjau data warehouse tradisional yang saat ini digunakan di lingkungan Anda. Untuk mengurangi kompleksitas dan potensi pengurangan biaya, peluang identifikasi untuk migrasi data warehouse tradisional Anda ke layanan Google Cloud seperti BigQuery. Untuk informasi selengkapnya dan contoh skenario, lihat data migrasi warehouse ke BigQuery.

Rencanakan akses gabungan ke data

Tinjau persyaratan data Anda dan bagaimana Anda butuh berinteraksi dengan layanan dan produk lain Identifikasi kebutuhan gabungan data Anda, dan buat desain sistem yang sesuai.

Sebagai contoh, BigQuery membiarkan Anda menggunakan tabel eksternal yang dapat membaca data dari sumber lain, seperti Bigtable, Cloud SQL, Cloud Storage, atau Google Drive. Anda dapat menggabungkan sumber eksternal dengan tabel yang Anda simpan di BigQuery.

Gunakan slot fleksibel BigQuery untuk menyediakan kapasitas burst on demand

Terkadang Anda butuh kapasitas ekstra untuk melakukan analisis eksperimental atau eksploratif yang akan membutuhkan banyak resource komputasi. BigQuery membiarkan Anda mendapat tambahan kapasitas komputasi dalam bentuk slot fleksibel. Slot fleksibel ini membantu Anda saat ada periode permintaan tinggi atau saat Anda ingin menyelesaikan analisis penting.

Pahami perbedaan skema jika Anda bermigrasi ke BigQuery

BigQuery mendukung kedua skema bintang and snowflake, tetapi secara default menggunakan kolom berulang dan bertingkat. kolom berulang dan bertingkat dapat lebih mudah untuk dibaca dan dikorelasikan dibandingkan dengan skema lain. Jika data Anda direpresentasikan di dalam skema star atau snowflake, dan jika Anda ingin memigrasikannya ke BigQuery, tinjau desain sistem Anda untuk mengetahui perubahan pada analisis atau proses.

Referensi tambahan

• Praktik terbaik untuk workload multi-tenant pada BigQuery
• Praktik terbaik untuk keamanan level baris di BigQuery
• Praktik terbaik untuk tampilan terwujud di BigQuery

Laporan dan visualisasi

Terapkan praktik terbaik pelaporan dan visualisasi berikut ke lingkungan Anda sendiri.

Gunakan BigQuery BI Engine untuk memvisualisasikan data Anda

BigQuery BI Engine adalah layanan, analisis memori yang cepat. Anda dapat menggunakan BI Engine untuk menganalisis data yang tersimpan di BigQuery dengan waktu respons kueri subdetik dan konkurensi tinggi. BI Engine terintegrasi ke dalam BigQuery API. Gunakan kapasitas pencadangan BI Engine untuk mengelola sebuah on-demand atau harga tarif tetap untuk kebutuhan Anda. BI Engine juga dapat bekerja dengan BI lain atau aplikasi dasbor kustom yang memerlukan respons waktu subdetik.

Modernisasi proses BI Anda dengan Looker

Looker adalah platform, perusahaan modern untuk BI, aplikasi data, dan analisis tersemat. Anda dapat membuat model data yang konsisten di atas data Anda dengan cepat dan akurat, dan Anda juga dapat mengakses data dalam transaksi dan datastore analitis. Looker juga dapat menganalisis data Anda di beberapa database dan clouds. Jika Anda memiliki proses BI dan alat yang sudah ada, kami merekomendasikan Anda untuk memodernisasi dan menggunakan platform terpusat seperti Looker

Referensi tambahan

• Migrasikan warehouse data ke Pelaporan BigQuery: dan analisis
• Arsitektur untuk menghubungkan software visualisasi ke Hadoop di Google Cloud
• Mempercepat kueri kecil di BigQuery dengan BI Engine

Gunakan alat pengelolaan alur kerja

Analisis data melibatkan banyak proses dan layanan. Data bergerak melalui alat yang berbeda dan pemrosesan pipeline saat siklus proses analisis data Untuk mengelola dan mempertahankan data pipeline end-to-end, gunakan alur kerja alat manajemen yang sesuai. Cloud Composer adalah alat manajemen alur kerja yang terkelola berdasarkan open source project Apache Airflow.

Anda bisa menggunakan Cloud Composer untuk meluncurkan pipeline Dataflow dan untuk menggunakan Template Alur Kerja Dataproc. Cloud Composer juga dapat membantu Anda membuat pipeline CI/CD untuk menguji, menyinkronkan, dan men-deploy DAG atau menggunakan pipeline CI/CD untuk alur kerja pemrosesan data. Untuk informasi selengkapnya, tonton praktik terbaik Cloud Composer: Development .

Resource migrasi

Jika Anda telah menjalankan platform analisis data dan jika Anda ingin migrasi beberapa atau semua workload ke Google Cloud, tinjau referensi migrasi berikut untuk panduan dan praktik terbaik:

• Panduan migrasi umum
  • Migrasi ke Google Cloud: Memilih jalur migrasi.
  • Contoh dari memodernisasi platform analisis engagement iklan Twitter.
• Migrasi Cloud Storage
  • Migrasikan Data HDFS dari Infrastruktur Lokal ke Google Cloud.
  • Mentransfer data dari Amazon S3 ke Cloud Storage menggunakan kontrol layanan VPC dan Storage Transfer Service.
• Migrasi Pub/Sub
  • Migrasi dari Kafka menjadi Pub/Sub.
• Migrasi Bigtable
  • Memigrasikan data dari HBase menjadi Bigtable.
  • Melakukan migrasi dari Aerospike menjadi Bigtable.
• Migrasi Dataproc
  • Migrasikan infrastruktur Hadoop lokal ke Google Cloud.
  • Tips dan biaya migrasi Hadoop.
  • Hadoop ke Dataproc.
  • Tugas Hadoop Lokal ke Dataproc.
  • Apache Spark ke Dataproc.
  • Metastore Hive Eksternal ke Metastore Dataproc.
• Migrasi BigQuery
  • Tantangan migrasi data warehouse lama challenges.
  • Migrasikan data warehouses ke BigQuery.
  • BigQuery untuk profesional Data Warehouse.
• Migrasi komposer
  • Migrasikan lingkungan ke Airflow 2.

Langkah selanjutnya

Pelajari tentang praktik terbaik sistem desain untuk Google Cloud AI dan machine learning, termasuk hal berikut:

• Pelajari layanan machine learning dan AI Google Cloud yang mendukung desain sistem.
• Pelajari praktik terbaik pemrosesan data ML.
• Pelajari praktik terbaik untuk pengembangan dan pelatihan model.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Terapkan machine learning

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan beberapa prinsip inti dan praktik terbaik untuk analisis data di Google Cloud. Anda akan mempelajari tentang beberapa layanan utama AI dan machine learning (ML), dan bagaimana layanan tersebut dapat membantu Anda selama berbagai tahap siklus proses AI dan ML. Praktik terbaik ini membantu Anda memenuhi kebutuhan AI dan ML Anda serta membuat desain sistem Anda. Dokumen ini mengasumsikan bahwa Anda telah familier dengan konsep dasar AI dan ML.

Untuk menyederhanakan proses pengembangan dan meminimalkan overhead saat Anda membangun model ML di Google Cloud, pertimbangkan tingkat abstraksi tertinggi yang cocok untuk kasus penggunaan Anda. Tingkat abstraksi didefinisikan sebagai jumlah kompleksitas penampilan atau pemrograman suatu sistem. Semakin tinggi tingkat abstraksi, semakin sedikit detail yang dapat ditampilkan.

Untuk memilih layanan Google AI dan ML berdasarkan kebutuhan bisnis Anda, gunakan tabel berikut ini:

Persona	Layanan Google
Pengguna bisnis	Solusi standar sepertiContact Center AI Insights, Document AI .Discovery AI, dan Cloud Healthcare API.
Developer dengan pengalaman ML minimum	API yang telah dilatih menangani tugas persepsi umum seperti visi, video, dan natural language. API ini didukung oleh model yang telah dilatih sebelumnya dan menyediakan pendeteksi default. API ini siap digunakan tanpa keahlian ML apa pun atau upaya pengembangan model. API terlatih mencakup: Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API, dan Cloud Translation API.
AI generatif untuk Developer	Vertex AI Search and Conversation memungkinkan developer menggunakan kemampuan uniknya untuk membangun dan men-deploy chatbot dalam hitungan menit dan mesin telusur dalam hitungan jam. Developer yang ingin menggabungkan beberapa kemampuan ke dalam alur kerja perusahaan dapat menggunakan Gen App Builder API untuk integrasi langsung.
Developer dan data scientist	AutoML memungkinkan pengembangan model kustom dengan gambar, video, teks, atau data tabulasi Anda sendiri. AutoML mempercepat pengembangan model dengan penelusuran otomatis melalui model zoo Google untuk arsitektur model yang paling sesuai harapan, sehingga Anda tidak perlu mem-build model tersebut. AutoML menangani tugas-tugas umum untuk Anda, seperti memilih arsitektur model, penyesuaian hyperparameter, penyediaan mesin untuk pelatihan dan serving.
Data scientist dan engineer ML	Alat model kustom Vertex AI dapat Anda gunakan untuk melatih dan menyalurkan model kustom, serta mengoperasionalkan alur kerja ML. Anda juga dapat menjalankan workload ML pada komputasi yang dikelola sendiri seperti VMCompute Engine.
Data scientist & engineer machine learning	Dukungan AI generatif di Vertex AI (juga dikenal sebagai genai) menyediakan akses ke model AI generatif berukuran besar milik Google sehingga Anda dapat menguji, menyesuaikan, dan men-deploy model tersebut di aplikasi yang didukung teknologi AI.
Data engineers, data scientist, dan analis data yang sudah biasa menggunakan antarmuka SQL	BigQuery ML dapat Anda gunakan untuk mengembangkan model berbasis SQL berdasarkan data yang disimpan di BigQuery.

Layanan utama

Tabel berikut memberikan ringkasan umum tingkat tinggi terkait layanan AI dan ML:

Layanan Google	Deskripsi
Cloud Storage dan BigQuery	Menyediakan opsi penyimpanan yang fleksibel untuk data dan artefak machine learning.
BigQuery ML	Memungkinkan Anda mem-build model machine learning secara langsung dari data yang disimpan di dalam BigQuery.
Pub/Sub, Dataflow, Cloud Data Fusion, dan Dataproc	Dukung penyerapan dan pemrosesan data batch dan real-time. Untuk informasi selengkapnya, lihat Analisis Data.
Vertex AI	Menawarkan satu platform kepada data scientist dan engineer machine learning untuk membuat, melatih, menguji, memantau, menyesuaikan, dan men-deploy model ML untuk segala hal, mulai dari AI generatif hingga MLOps. Alat-alat mencakup hal berikut: Vertex data labeling untuk mendapatkan label data yang akurat. Deep Learning Containers untuk membangun dan men-deploy model di lingkungan yang portabel dan konsisten. Vertex AI Workbench untuk lingkungan JupyterLab terkelola atau dikelola pengguna. Pelatihan Vertex untuk layanan pelatihan yang terkelola sepenuhnya. Vertex AI TensorBoard untuk pelacakan eksperimen. Vertex AI Vizier untuk penyesuaian hyperparameter. Prediksi Vertex untuk framework deployment terpadu yang mendukung model BigQuery ML, dan AutoML yang dilatih khusus. Vertex Explainable AI untuk menampilkan penjelasan untuk prediksi model. Vertex Experiments untuk mempercepat deployment model ke dalam tahap produksi. Kini dengan pemilihan model lebih cepat. Alat MLOps, seperti Vertex AI Pipelines untuk orkestrasi dan Vertex AI Feature Store untuk repositori fitur yang terkelola sepenuhnya.
Vertex AI Search and Conversation	Memungkinkan Anda build chatbot dan mesin telusur untuk situs dan untuk digunakan di seluruh data perusahaan. AI Percakapan di Vertex AI Search and Conversation dapat membantu mengubah interaksi pelanggan dan karyawan dengan chatbot dan asisten digital yang didukung AI generatif. Misalnya, dengan alat ini, Anda dapat memberikan lebih dari sekadar informasi dengan mengaktifkan transaksi dari dalam pengalaman chat. Enterprise Search di Vertex AI Search and Conversation, memungkinkan perusahaan membangun pengalaman penelusuran untuk pelanggan dan karyawan di situs publik atau pribadi mereka. Selain menyediakan hasil penelusuran multimodal berkualitas tinggi, Penelusuran Enterprise juga dapat meringkas hasil dan menyediakan kutipan yang sesuai dengan AI generatif.
AI Generatif di Vertex AI	Memberi Anda akses ke model AI generatif besar dari Google sehingga Anda dapat menguji, menyesuaikan, dan men-deploy-nya untuk digunakan dalam aplikasi yang didukung AI. AI Generatif di Vertex AI juga dikenal sebagai genai. Model AI generatif, yang juga dikenal sebagai model dasar, dikategorikan berdasarkan jenis konten yang dirancang untuk dihasilkan. Konten ini mencakup teks dan chat, gambar, kode, dan penyematan teks. Vertex AI Studio memungkinkan Anda membuat prototipe dan menguji model AI generatif dengan cepat di Konsol Google Cloud. Anda dapat menguji perintah contoh, mendesain perintah Anda sendiri, dan menyesuaikan model dasar untuk menangani tugas yang memenuhi kebutuhan aplikasi Anda. Penyesuaian Model - memungkinkan Anda menyesuaikan model dasar untuk kasus penggunaan tertentu dengan menyesuaikannya menggunakan set data contoh input-output. Model Garden menyediakan model dasar yang siap digunakan perusahaan, model khusus tugas, dan API.
API Terlatih	API terlatih mencakup Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API, dan Cloud Translation API.
AutoML	Menyediakan alat model kustom untuk mem-build, men-deploy, dan menskalakan model ML. Developer dapat mengupload datanya sendiri dan menggunakan layanan AutoML yang berlaku untuk membuat model kustom. AutoML Image: Melakukan klasifikasi gambar dan deteksi objek pada data gambar. AutoML Video: Melakukan deteksi objek, klasifikasi, dan pengenalan tindakan pada data video. AutoML Text: Melakukan klasifikasi bahasa, ekstraksi entity, dan analisis sentimen pada data teks. AutoML Translation: Mendeteksi dan menerjemahkan antara pasangan bahasa. AutoML Tabular: Memungkinkan Anda mem-build model regresi, klasifikasi, atau perkiraan. Ditujukan untuk data terstruktur.
Infrastruktur AI	Memungkinkan Anda menggunakan akselerator AI untuk memproses workload ML berskala besar. Akselerator ini memungkinkan Anda melatih dan mendapatkan inferensi dari model deep learning dan dari model machine learning dengan cara yang hemat biaya. GPUdapat membantu inferensi hemat biaya dan pelatihan peningkatan skala atau penyebaran skala untuk model deep learning. Tensor Processing Unit (TPU) adalah ASIC yang dibuat khusus untuk melatih dan menyetujui deep neural networks.
Dialogflow	Memberikan agen virtual yang memberikan pengalaman percakapan.
Contact Center AI	Memberikan pengalaman pusat kontak otomatis dan kaya insight dengan fungsi Agent Assist untuk agen manusia.
Document AI	Memberikan pemahaman dokumen dalam skala besar untuk dokumen secara umum, dan untuk jenis dokumen tertentu seperti dokumen terkait pinjaman dan pengadaan.
Lending DocAI	Mengotomatiskan pemrosesan dokumen hipotek. Mengurangi waktu pemrosesan dan menyederhanakan pengambilan data sekaligus mendukung persyaratan peraturan dan kepatuhan.
Procurement DocAI	Mengotomatiskan pengambilan data pengadaan dalam skala besar dengan mengubah dokumen yang tidak terstruktur, seperti invoice dan tanda terima, menjadi data terstruktur untuk meningkatkan efisiensi operasional, memperbaiki kualitas pengalaman pelanggan, dan mendasari pengambilan keputusan.
Saran	Memberikan rekomendasi produk yang dipersonalisasi.
Healthcare Natural Language AI	Memungkinkan Anda meninjau dan menganalisis dokumen medis.
Media Translation API	Mengaktifkan terjemahan ucapan real-time dari data audio.

Pemrosesan data

Menerapkan praktik terbaik pemrosesan data berikut di lingkungan Anda sendiri.

Pastikan data Anda memenuhi persyaratan ML

Data yang Anda gunakan untuk ML harus memenuhi persyaratan dasar tertentu, apa pun jenis datanya. Persyaratan ini mencakup kemampuan data untuk memprediksi target, konsistensi dalam perincian antara data yang digunakan untuk pelatihan dan data yang digunakan untuk prediksi, serta data yang diberi label secara akurat untuk pelatihan. Volume data Anda juga harus memadai. Untuk informasi selengkapnya, lihat Pemrosesan data.

Simpan data tabulasi di BigQuery

Jika Anda menggunakan data tabulasi, pertimbangkan untuk menyimpan semua data di BigQuery dan menggunakan BigQuery Storage API untuk membaca data dari situ. Untuk menyederhanakan interaksi dengan API tersebut, gunakan salah satu opsi alat tambahan berikut, bergantung pada tempat Anda ingin membaca data tersebut:

• Jika Anda menggunakan Dataflow, gunakan BigQuery I/O Connector.
• Jika Anda menggunakan TensorFlow atau Keras, gunakan pembaca tf.data.dataset untuk BigQuery.
• Jika Anda menggunakan data tidak terstruktur seperti gambar atau video, pertimbangkan untuk menyimpan semua data di Cloud Storage.

Jenis data input juga menentukan alat pengembangan model yang tersedia. API yang telah dilatih sebelumnya, AutoML, dan BigQuery ML dapat menyediakan lingkungan pengembangan yang lebih hemat dan efisien dalam hal waktu untuk kasus penggunaan gambar, video, teks, dan data terstruktur tertentu.

Pastikan Anda memiliki cukup data untuk mengembangkan model ML

Untuk mengembangkan model ML yang berguna, Anda harus memiliki data yang cukup. Untuk memprediksi kategori, jumlah contoh yang direkomendasikan untuk setiap kategori adalah 10 kali jumlah fitur. Semakin banyak kategori yang ingin Anda prediksi, semakin banyak data yang Anda butuhkan. Set data tak seimbang membutuhkan lebih banyak lagi data. Jika Anda tidak memiliki cukup data berlabel yang tersedia, pertimbangkan semi-supervised learning.

Ukuran set data juga memiliki implikasi pelatihan dan penyaluran: jika Anda memiliki set data yang kecil, latih secara langsung dalam instance Notebook; jika Anda memiliki set data yang lebih besar yang memerlukan pelatihan terdistribusi, gunakan layanan pelatihan kustom Vertex AI. Jika Anda ingin Google melatih model untuk data Anda, gunakan AutoML.

Siapkan data untuk digunakan

Data yang disiapkan dengan baik dapat mempercepat pengembangan model. Saat Anda mengonfigurasi pipeline data Anda, pastikan pipeline tersebut dapat memproses data batch dan streaming sehingga Anda akan mendapatkan hasil yang konsisten dari kedua jenis data.

Pengembangan dan pelatihan model

Terapkan praktik terbaik pengembangan dan pelatihan model berikut di lingkungan Anda sendiri.

Pilih pengembangan model yang dilatih atau dikelola khusus

Saat Anda mem-build model, pertimbangkan tingkat abstraksi setinggi mungkin. Gunakan AutoML jika memungkinkan sehingga tugas pengembangan dan pelatihan ditangani untuk Anda. Untuk model yang dilatih khusus, pilih opsi terkelola untuk skalabilitas dan fleksibilitas, bukan opsi yang dikelola sendiri. Untuk mempelajari lebih lanjut opsi pengembangan model, baca artikel Menggunakan alat dan produk yang direkomendasikan.

Pertimbangkan layanan pelatihan Vertex AI, bukan pelatihan yang dikelola sendiri pada Compute Engine VM atau container VM Deep Learning. Untuk lingkungan JupyterLab, pertimbangkan Vertex AI Workbench, yang menyediakan lingkungan JupyterLab yang terkelola dan dikelola oleh pengguna. Untuk informasi selengkapnya, baca artikel Pengembangan Machine learning dan Pelatihan yang dioperasionalkan.

Gunakan container kustom atau yang telah dibuat sebelumnya untuk model yang dilatih khusus

Untuk model yang dilatih khusus di Vertex AI, Anda dapat menggunakan container kustom atau yang telah dibuat sebelumnya, bergantung pada framework machine learning dan versi framework Anda. Container yang telah dibuat sebelumnya telah tersedia untuk aplikasi pelatihan Python yang dibuat untuk versi TensorFlow, scikit-learn, PyTorch, dan XGBoost tertentu.

Jika tidak, Anda dapat memilih untuk membuat container kustom untuk tugas pelatihan Anda. Misalnya, gunakan container kustom jika ingin melatih model Anda menggunakan framework Python ML yang tidak tersedia dalam container yang telah dibuat sebelumnya, atau jika Anda ingin berlatih menggunakan bahasa pemrograman selain Python. Dalam container kustom Anda, pra-instal aplikasi pelatihan Anda dan semua dependensinya ke dalam image yang menjalankan tugas pelatihan Anda.

Pertimbangkan persyaratan pelatihan terdistribusi

Pertimbangkan persyaratan pelatihan terdistribusi. Beberapa framework ML, seperti TensorFlow dan PyTorch, dapat Anda gunakan untuk menjalankan kode pelatihan yang identik di beberapa mesin. Framework ini secara otomatis mengoordinasikan pembagian kerja berdasarkan variabel lingkungan yang ditetapkan pada setiap mesin. Framework lainnya mungkin memerlukan penyesuaian tambahan.

Langkah selanjutnya

Untuk mengetahui informasi selengkapnya tentang AI dan machine learning, lihat artikel berikut ini:

• Praktik terbaik untuk menerapkan machine learning di Google Cloud.
• Panduan praktisi untuk MLOps: Framework untuk continuous delivery dan otomatisasi machine learning.

Pelajari kategori lainnya dalam Framework Arsitektur seperti keandalan, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Desain untuk kelestarian lingkungan

Dokumen dalam Framework Arsitektur Google Cloud ini merangkum cara Anda menangani keberlanjutan lingkungan untuk workload Anda di Google Cloud. Panduan ini mencakup informasi tentang cara meminimalkan jejak karbon Anda di Google Cloud.

Memahami jejak karbon Anda

Untuk memahami jejak karbon dari penggunaan Google Cloud, gunakan dasbor Jejak Karbon. Dasbor Jejak Karbon mengatribusikan emisi ke project Google Cloud yang Anda miliki dan layanan cloud yang Anda gunakan.

Untuk informasi selengkapnya, lihat Memahami jejak karbon Anda dalam "Mengurangi jejak karbon Google Cloud Anda".

Memilih region cloud yang paling sesuai

Salah satu cara sederhana dan efektif untuk mengurangi emisi karbon adalah dengan memilih region cloud dengan emisi karbon yang lebih rendah. Untuk membantu Anda membuat pilihan ini, Google memublikasikan data karbon untuk semua region Google Cloud.

Saat memilih region, Anda mungkin perlu menyeimbangkan penurunan emisi dengan persyaratan lain, seperti harga dan latensi jaringan. Untuk membantu memilih region, gunakan Pemilih Region Google Cloud.

Untuk informasi selengkapnya, lihat Memilih region cloud yang paling sesuai dalam "Mengurangi jejak karbon Google Cloud".

Memilih layanan cloud yang paling sesuai

Untuk membantu mengurangi jejak karbon yang ada, pertimbangkan untuk memigrasikan workload VM lokal Anda ke Compute Engine.

Pertimbangkan juga bahwa banyak workload yang tidak memerlukan VM. Sering kali Anda dapat memanfaatkan penawaran serverless Layanan terkelola ini dapat mengoptimalkan penggunaan resource cloud, sering kali secara otomatis, yang secara bersamaan mengurangi biaya cloud dan jejak karbon.

Untuk informasi selengkapnya, lihat Memilih layanan cloud yang paling sesuai dalam "Mengurangi jejak karbon Google Cloud".

Meminimalkan resource cloud nonaktif

Resource nonaktif dikenai biaya dan emisi yang tidak perlu. Beberapa penyebab umum resource nonaktif mencakup hal-hal berikut:

• Resource cloud aktif yang tidak digunakan, seperti instance VM nonaktif.
• Resource yang disediakan secara berlebih, seperti jenis mesin instance VM yang lebih besar dari yang diperlukan untuk workload.
• Arsitektur yang tidak optimal, seperti migrasi lift-and-shift yang tidak selalu dioptimalkan untuk efisiensi. Pertimbangkan untuk melakukan peningkatan inkremental pada arsitektur ini.

Berikut adalah beberapa strategi umum untuk membantu meminimalkan limbah resource cloud:

• Identifikasi resource nonaktif atau yang disediakan secara berlebih, lalu hapus atau sesuaikan ukuran resource tersebut.
• Faktorkan ulang arsitektur Anda untuk menggabungkan desain yang lebih optimal.
• Memigrasikan workload ke layanan terkelola.

Untuk informasi selengkapnya, lihat Meminimalkan resource cloud nonaktif dalam "Mengurangi jejak karbon Google Cloud Anda."

Mengurangi emisi untuk workload batch

Jalankan workload batch di region dengan emisi karbon yang lebih rendah. Untuk pengurangan lebih lanjut, jalankan workload pada waktu yang bertepatan dengan intensitas karbon petak yang lebih rendah jika memungkinkan.

Untuk informasi selengkapnya, lihat Mengurangi emisi untuk workload batch dalam "Mengurangi jejak karbon Google Cloud".

Langkah selanjutnya

• Pelajari cara menggunakan Data Jejak Karbon untuk mengukur, melaporkan, dan mengurangi emisi karbon cloud Anda.
• Pelajari cara mengurangi jejak karbon Google Cloud Anda.

Framework Arsitektur Google Cloud: Keunggulan operasional

Kategori dalam Framework Arsitektur Google Cloud ini menunjukkan cara mengoperasikan layanan secara efisien di Google Cloud. Bagian ini membahas cara menjalankan, mengelola, dan memantau sistem yang memberikan nilai bisnis. Topik ini juga membahas produk dan fitur Google Cloud yang mendukung keunggulan operasional. Menggunakan prinsip-prinsip keunggulan operasional membantu Anda membangun fondasi keandalan. Yaitu dengan menyiapkan elemen dasar seperti kemampuan observasi, otomatisasi, dan skalabilitas.

Framework Arsitektur ini mendeskripsikan praktik terbaik, memberikan rekomendasi implementasi, serta menjelaskan beberapa produk dan layanan yang tersedia yang membantu Anda mencapai keunggulan operasional. Framework ini bertujuan untuk membantu Anda mendesain deployment Google Cloud agar sesuai dengan kebutuhan bisnis Anda.

Dalam kategori keunggulan operasional Framework Arsitektur, Anda akan mempelajari cara melakukan hal-hal berikut:

• Mengotomatiskan deployment Anda
• Menyiapkan pemantauan, pemberitahuan, dan logging
• Membangun dukungan cloud dan proses eskalasi
• Mengelola kapasitas dan kuota
• Merencanakan traffic puncak dan acara peluncuran
• Ciptakan budaya otomatisasi

Mengotomatiskan deployment Anda

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk mengotomatiskan build, pengujian, dan deployment Anda.

Otomatisasi membantu Anda menstandarkan build, pengujian, dan deployment dengan menghilangkan error yang disebabkan oleh manusia untuk proses berulang seperti update kode. Bagian ini menjelaskan cara menggunakan berbagai pemeriksaan dan pengamanan saat Anda melakukan otomatisasi. Proses standar yang dikontrol mesin membantu memastikan deployment Anda diterapkan dengan aman. Solusi ini juga memberikan mekanisme untuk memulihkan deployment sebelumnya sesuai kebutuhan tanpa memengaruhi pengalaman pengguna Anda secara signifikan.

Simpan kode Anda di repositori kode pusat

Simpan kode Anda di repositori kode pusat yang menyertakan sistem kontrol versi dengan pemberian tag dan kemampuan untuk me-roll back perubahan kode. Kontrol versi memungkinkan Anda mengatur file serta mengontrol akses, pembaruan, dan penghapusan di seluruh tim dan organisasi.

Untuk berbagai tahap pengembangan, buat versi dan beri label repositori sesuai kebutuhan. Misalnya, label dapat berupa test, dev, dan prod.

Di Google Cloud, Anda dapat menyimpan kode di Cloud Source Repositories, dan membuat versi serta mengintegrasikannya dengan produk Google Cloud lainnya. Jika Anda mem-build aplikasi dalam container, gunakan Artifact Registry, sebuah registry terkelola untuk container.

Untuk detail selengkapnya tentang kontrol versi, lihat Kontrol versi. Untuk mengetahui detail tentang mengimplementasikan pengembangan berbasis trunk dengan repositori Anda, lihat Pengembangan berbasis trunk.

Gunakan continuous integration dan continuous deployment (CI/CD)

Otomatiskan deployment Anda menggunakan pendekatan continuous integration dan continuous deployment (CI/CD). Pendekatan CI/CD adalah kombinasi pipeline yang Anda konfigurasi dan proses yang diikuti oleh tim pengembangan Anda.

Pendekatan CI/CD meningkatkan kecepatan deployment velocity dengan membuat tim pengembangan software Anda lebih produktif. Pendekatan ini memungkinkan developer membuat perubahan yang lebih kecil dan lebih sering yang diuji secara menyeluruh, sekaligus mengurangi waktu yang diperlukan untuk men-deploy perubahan tersebut.

Sebagai bagian dari pendekatan CI/CD, otomatiskan semua langkah yang merupakan bagian dari pembuatan, pengujian, dan deployment kode Anda. Contoh:

• Setiap kali kode baru di-commit ke repositori, minta commit untuk otomatis memanggil pipeline build dan pengujian.
• Mengotomatiskan pengujian integrasi.
• Otomatiskan deployment Anda agar perubahan di-deploy setelah build memenuhi kriteria pengujian tertentu.

Di Google Cloud, Anda dapat menggunakan Cloud Build dan Cloud Deploy untuk pipeline CI/CD Anda.

Gunakan Cloud Build untuk membantu menentukan dependensi dan versi yang dapat Anda gunakan untuk membuat dan mem-build paket aplikasi. Tetapkan versi konfigurasi build untuk memastikan semua build konsisten, dan untuk memastikan Anda dapat melakukan roll back ke konfigurasi sebelumnya jika diperlukan.

Gunakan Cloud Deploy untuk men-deploy aplikasi Anda ke lingkungan tertentu di Google Cloud, dan untuk mengelola pipeline deployment Anda.

Untuk mengetahui detail selengkapnya tentang cara mengimplementasikan CI/CD, baca Continuous integration dan Otomatisasi deployment.

Sediakan dan kelola infrastruktur menggunakan infrastruktur sebagai kode

Infrastruktur sebagai kode adalah penggunaan model deskriptif untuk mengelola infrastruktur, seperti VM, dan konfigurasi, seperti aturan firewall. Infrastruktur sebagai kode memungkinkan Anda melakukan hal berikut:

• Buat resource cloud Anda secara otomatis, termasuk lingkungan deployment atau pengujian untuk pipeline CI/CD Anda.
• Perlakukan perubahan infrastruktur seperti Anda memperlakukan perubahan aplikasi. Misalnya, pastikan perubahan pada konfigurasi ditinjau, diuji, dan dapat diaudit.
• Siapkan satu versi yang terpercaya untuk infrastruktur cloud Anda.
• Replikasikan lingkungan cloud Anda sesuai kebutuhan.
• Melakukan roll back ke konfigurasi sebelumnya jika diperlukan.

Konsep infrastruktur sebagai kode ini juga berlaku untuk project di Google Cloud. Anda dapat menggunakan pendekatan ini untuk menentukan resource seperti konektivitas VPC Bersama atau akses Identity and Access Management (IAM) dalam project Anda. Untuk contoh pendekatan ini, lihat Modul Terraform Factory Project Google Cloud.

Alat pihak ketiga, seperti Terraform, membantu Anda membuat infrastruktur di Google Cloud secara otomatis. Untuk informasi selengkapnya, baca artikel Mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.

Pertimbangkan untuk menggunakan fitur Google Cloud, seperti lien project .Kebijakan retensi Cloud Storage , dan Cloud Storagepenguncian bucket , untuk melindungi resource penting agar tidak terhapus secara tidak sengaja atau berbahaya.

Hadirkan pengujian di seluruh siklus proses penyediaan software

Pengujian sangat penting untuk keberhasilan peluncuran software. Pengujian berkelanjutan membantu tim membuat software berkualitas tinggi dengan lebih cepat dan meningkatkan stabilitas software.

Jenis pengujian:

• Pengujian unit. Pengujian unit cepat dan membantu Anda melakukan deployment dengan cepat. Perlakukan pengujian unit sebagai bagian dari codebase dan sertakan sebagai bagian dari proses build.
• Pengujian integrasi Pengujian integrasi itu penting, terutama untuk workload yang dirancang untuk penskalaan dan bergantung pada lebih dari satu layanan. Pengujian ini dapat menjadi kompleks saat Anda menguji integrasi dengan layanan yang saling terhubung.
• Pengujian sistem. Pengujian sistem memakan waktu dan kompleks, tetapi membantu Anda mengidentifikasi kasus ekstrem dan memperbaiki masalah sebelum deployment.
• Pengujian lainnya. Ada pengujian lain yang harus Anda jalankan, termasuk pengujian statis, pengujian beban, pengujian keamanan, pengujian validasi kebijakan, dan lainnya. Jalankan pengujian ini sebelum men-deploy aplikasi Anda dalam produksi.

Untuk menerapkan pengujian:

• Melakukan semua jenis pengujian secara terus-menerus selama siklus proses pengiriman software.
• Otomatiskan pengujian ini dan sertakan dalam pipeline CI/CD. Buat pipeline Anda gagal jika salah satu pengujian gagal.
• Mengupdate dan menambahkan pengujian baru secara terus-menerus untuk meningkatkan dan mempertahankan kondisi operasional deployment Anda.

Untuk lingkungan pengujian Anda:

• Gunakan project Google Cloud yang terpisah untuk setiap lingkungan pengujian yang Anda miliki. Untuk setiap aplikasi, gunakan lingkungan project yang terpisah. Pemisahan ini memberikan demarkasi yang jelas antara resource lingkungan produksi dan resource lingkungan Anda yang lebih rendah. Pemisahan ini membantu memastikan bahwa perubahan apa pun di satu lingkungan tidak akan memengaruhi lingkungan lain secara tidak sengaja.
• Mengotomatiskan pembuatan lingkungan pengujian. Salah satu cara untuk melakukan otomatisasi ini adalah menggunakan infrastruktur sebagai kode.
• Gunakan lingkungan produksi sintetis untuk menguji perubahan. Lingkungan ini menyediakan lingkungan seperti produksi untuk menguji aplikasi Anda dan menjalankan berbagai jenis pengujian pada workload Anda, termasuk pengujian menyeluruh dan pengujian performa.

Untuk informasi selengkapnya tentang menerapkan pengujian berkelanjutan, lihat Otomatisasi pengujian.

Luncurkan deployment secara bertahap

Pilih strategi deployment Anda berdasarkan parameter penting, seperti gangguan minimum terhadap pengguna akhir, update berkelanjutan, strategi rollback, dan strategi pengujian A/B. Untuk setiap workload, evaluasi persyaratan ini dan pilih strategi deployment dari teknik yang telah terbukti, seperti update berkelanjutan, blue-green deployment, dan deployment canary.

Hanya biarkan proses CI/CD membuat dan mengirim perubahan di lingkungan produksi Anda.

Pertimbangkan untuk menggunakan infrastruktur yang tidak dapat diubah. Infrastruktur yang tidak dapat diubah adalah infrastruktur yang tidak berubah atau diperbarui. Jika perlu men-deploy kode baru atau mengubah konfigurasi lain di lingkungan, Anda mengganti seluruh lingkungan (misalnya, kumpulan VM, atau Pod) dengan lingkungan baru. Blue/green deployment adalah contoh infrastruktur yang tidak dapat diubah.

Sebaiknya lakukan pengujian terbatas dan amati sistem untuk menemukan error saat men-deploy perubahan. Jenis pengamatan ini lebih mudah jika Anda memiliki sistem pemantauan dan pemberitahuan yang canggih. Untuk melakukan pengujian A/B atau pengujian canary, Anda dapat menggunakan grup instance terkelola Google Cloud. Kemudian, Anda dapat melakukan peluncuran lambat, atau pemulihan jika perlu.

Pertimbangkan untuk menggunakan Cloud Deploy untuk mengotomatiskan deployment dan mengelola pipeline deployment Anda. Anda juga dapat menggunakan banyak alat pihak ketiga, seperti Spinnaker dan Tekton, di Google Cloud untuk deployment otomatis dan untuk membuat pipeline deployment singkat ini.

Pulihkan rilis sebelumnya dengan lancar

Tentukan strategi pemulihan Anda sebagai bagian dari strategi deployment. Pastikan Anda dapat melakukan roll back deployment, atau konfigurasi infrastruktur, ke versi kode sumber sebelumnya. Memulihkan deployment yang stabil sebelumnya merupakan langkah penting dalam manajemen insiden untuk keandalan dan insiden keamanan.

Selain itu, pastikan Anda dapat memulihkan lingkungan ke keadaan semula sebelum proses deployment dimulai. Hal ini dapat mencakup:

• Kemampuan untuk mengembalikan perubahan kode apa pun di aplikasi Anda.
• Kemampuan untuk mengembalikan perubahan konfigurasi apa pun yang dilakukan pada lingkungan.
• Menggunakan infrastruktur yang tidak dapat diubah dan memastikan bahwa deployment tidak mengubah lingkungan. Praktik ini mempermudah pengembalian perubahan konfigurasi.

Memantau pipeline CI/CD

Agar proses build, pengujian, dan deployment otomatis Anda berjalan lancar, pantau pipeline CI/CD Anda. Tetapkan pemberitahuan yang menunjukkan ketika ada yang gagal di pipeline. Setiap langkah pipeline Anda harus menulis laporan log yang sesuai sehingga tim Anda dapat melakukan analisis akar masalah jika pipeline gagal.

Di Google Cloud, semua layanan CI/CD terintegrasi dengan Kemampuan Observabilitas Google Cloud. Contoh:

• Cloud Source Repositories terintegrasi dengan layanan Pub/Sub.
• Cloud Build terintegrasi dengan Pub/Sub dan juga menyimpan log audit dan log build. Anda dapat menyetel pemberitahuan untuk kata kunci tertentu di log build dan untuk berbagai metrik lainnya menggunakan layanan Cloud Monitoring.
• Cloud Deploy menyimpan log audit.

Untuk mengetahui detail tentang pemantauan dan logging, lihat Menyiapkan pemantauan, pemberitahuan, dan logging.

Deploy aplikasi secara aman

Tinjau bagian Men-deploy aplikasi dengan aman dari kategori keamanan, kepatuhan, dan privasi Framework Arsitektur.

Tetapkan panduan pengelolaan untuk rilis versi

Untuk membantu engineer Anda menghindari kesalahan, dan untuk memungkinkan pengiriman software velocity tinggi, pastikan pedoman pengelolaan Anda untuk merilis versi software baru didokumentasikan dengan jelas.

Engineer rilis mengawasi cara pembuatan dan pengiriman software. Sistem engineering rilis dipandu oleh empat praktik:

• Mode layanan mandiri. Tetapkan pedoman untuk membantu software engineer menghindari kesalahan umum. Pedoman ini umumnya dikodifikasi dalam proses otomatis.

• Rilis rutin. Kecepatan tinggi membantu pemecahan masalah dan mempermudah penyelesaian masalah. Rilis rutin bergantung pada pengujian unit otomatis.

• Build hermetis. Pastikan konsistensi dengan alat build Anda. Versi compiler build yang Anda gunakan untuk mem-build versi saat ini dan satu bulan lalu.

• Penerapan kebijakan. Semua perubahan memerlukan peninjauan kode, idealnya termasuk serangkaian pedoman dan kebijakan untuk menerapkan keamanan. Penerapan kebijakan meningkatkan peninjauan kode, pemecahan masalah, dan pengujian rilis baru.

Langkah selanjutnya

• Menyiapkan pemantauan, pemberitahuan, dan logging (dokumen berikutnya dalam seri ini)
• Men-deploy aplikasi dengan aman dari kategori keamanan, kepatuhan, dan privasi Framework Arsitektur
• Tinjau praktik terbaik untuk membuat container
• Pelajari Kemampuan teknis
• Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem, keamanan, privasi, serta kepatuhan, keandalan, pengoptimalan biaya, dan pengoptimalan performa.

Siapkan pemantauan, pemberitahuan, dan logging

Dokumen dalam Framework Arsitektur Google Cloud ini menunjukkan cara menyiapkan pemantauan, pemberitahuan, dan logging sehingga Anda dapat bertindak berdasarkan perilaku sistem Anda. Hal ini termasuk mengidentifikasi metrik yang bermakna untuk melacak dan membangun dasbor guna mempermudah Anda melihat informasi tentang sistem Anda.

Program riset DevOps Resource and Assessment (DORA) mendefinisikan pemantauan sebagai:

"Pemantauan adalah proses mengumpulkan, menganalisis, dan menggunakan informasi untuk melacak aplikasi dan infrastruktur untuk mengarahkan keputusan bisnis. Pemantauan adalah sebuah kemampuan utama karena hal ini dapat memberi Anda insight tentang sistem dan pekerjaan Anda."

Pemantauan memungkinkan pemilik layanan untuk:

• Membuat keputusan yang tepat saat perubahan pada layanan berpengaruh pada performa
• Menerapkan pendekatan ilmiah untuk respons insiden
• Mengukur keselarasan layanan Anda dengan sasaran bisnis

Dengan menerapkan pemantauan, logging, dan pemberitahuan, Anda dapat melakukan hal berikut:

• Menganalisis tren jangka panjang
• Membandingkan eksperimen dari waktu ke waktu
• Menentukan pemberitahuan tentang metrik penting
• Membangun dasbor real-time yang relevan
• Melakukan analisis retrospektif
• Memantau metrik berbasis bisnis dan metrik kesehatan sistem
  • Metrik berbasis bisnis membantu Anda memahami seberapa baik sistem mendukung bisnis Anda. Misalnya, gunakan metrik untuk memantau hal berikut:
    • Biaya aplikasi untuk melayani pengguna
    • Perubahan volume traffic situs setelah didesain ulang
    • Waktu yang dibutuhkan pelanggan untuk membeli produk di situs Anda
  • Metrik kesehatan sistem membantu Anda memahami apakah sistem Anda beroperasi dengan benar dan dalam tingkat performa yang dapat diterima.

Gunakan empat sinyal emas berikut untuk memantau sistem Anda:

• Latensi. Waktu yang diperlukan untuk melayani permintaan.
• Traffic. Banyaknya permintaan yang ditempatkan pada sistem Anda.
• Error. Jumlah permintaan yang gagal. Kegagalan dapat bersifat eksplisit (misalnya, HTTP 500), implisit (misalnya, respons sukses HTTP 200 yang digabungkan dengan konten yang tidak tepat), atau menurut kebijakan (misalnya, jika Anda berkomitmen pada waktu respon satu detik, setiap permintaan di atas satu detik akan dianggap error).
• Saturasi. Seberapa penuh layanan Anda. Saturasi adalah ukuran fraksi sistem Anda, dengan menekankan resource yang paling terbatas (yaitu, dalam sistem yang terbatas memori, menampilkan memori; dalam sistem I/O terbatas, tunjukkan I/O).

Buat rencana pemantauan

Buat rencana pemantauan yang sesuai dengan misi dan strategi operasi organisasi Anda. Sertakan perencanaan pemantauan dan kemampuan observasi selama pengembangan aplikasi. Menyertakan rencana pemantauan di awal pengembangan aplikasi dapat mendorong organisasi menjadi unggul secara operasional.

Sertakan detail berikut dalam rencana pemantauan Anda:

• Sertakan semua sistem Anda, termasuk resource lokal dan resource cloud.
• Sertakan pemantauan biaya cloud Anda untuk membantu memastikan bahwa peristiwa penskalaan tidak menyebabkan penggunaan melampaui batas anggaran Anda.
• Buat berbagai strategi pemantauan untuk mengukur performa infrastruktur, pengalaman pengguna, dan indikator performa utama (KPI) bisnis. Misalnya, batas statis mungkin berfungsi dengan baik untuk mengukur performa infrastruktur, tetapi tidak dapat mencerminkan pengalaman pengguna yang sesungguhnya.

Perbarui rencana seiring dengan matangnya strategi pemantauan Anda. Sempurnakan rencana untuk meningkatkan kesehatan sistem Anda.

Tentukan metrik yang mengukur semua aspek organisasi Anda

Tentukan metrik yang diperlukan untuk mengukur perilaku deployment Anda. Untuk melakukannya:

• Tentukan tujuan bisnis Anda.
• Identifikasi metrik dan KPI yang dapat memberi Anda informasi yang terukur untuk mengukur performa. Pastikan definisi metrik Anda tercermin dalam semua aspek organisasi Anda, mulai dari kebutuhan bisnis—termasuk biaya cloud—hingga komponen teknis.
• Gunakan metrik tersebut untuk membuat indikator tingkat layanan (SLI) untuk aplikasi Anda. Untuk informasi selengkapnya, lihat Memilih SLI yang sesuai.

Metrik umum untuk berbagai komponen

Metrik dibuat di semua tingkat layanan Anda, mulai dari infrastruktur dan jaringan hingga logika bisnis. Contoh:

• Metrik infrastruktur:
  • Statistik mesin virtual, termasuk instance, CPU, memori, penggunaan, dan jumlah
  • Statistik berbasis container, termasuk pemanfaatan cluster, kapasitas cluster, pemanfaatan level pod, dan jumlah
  • Statistik networking, termasuk traffic masuk/keluar, bandwidth antarkomponen, latensi, dan throughput
  • Permintaan per detik, seperti yang diukur oleh load balancer
  • Total disk block yang dibaca, per disk
  • Paket yang dikirim melalui antarmuka jaringan tertentu
  • Ukuran heap memori untuk proses tertentu
  • Distribusi latensi respons
  • Jumlah kueri tidak valid yang ditolak oleh instance database
• Metrik aplikasi:
  • Perilaku khusus aplikasi, termasuk kueri per detik, penulisan per detik, dan pesan terkirim per detik
• Metrik statistik layanan terkelola:
  • QPS, throughput, latensi, pemakaian untuk layanan yang dikelola Google (API atau produk seperti BigQuery, App Engine, dan Bigtable)
• Metrik statistik network connectivity:
  • Statistik terkait VPN/interconnect terkait cara menghubungkan ke sistem lokal atau sistem lokal yang berada di luar Google Cloud.
• SLI
  • Metrik yang terkait dengan kesehatan sistem secara keseluruhan.

Siapkan pemantauan

Siapkan pemantauan untuk memantau resource lokal dan resource cloud.

Pilih solusi pemantauan yang:

• Tidak bergantung pada platform
• Memberikan kemampuan yang seragam untuk memantau lingkungan lokal, hybrid, dan multi-cloud

Dengan menggunakan satu platform untuk menggabungkan data pemantauan yang masuk dari berbagai sumber, Anda dapat membuat metrik yang seragam dan dasbor visualisasi.

Saat Anda menyiapkan pemantauan, otomatisasi tugas pemantauan yang dapat diubah menjadi otomatis.

Memantau menggunakan Google Cloud

Menggunakan layanan pemantauan, seperti Cloud Monitoring, lebih mudah daripada membuat layanan pemantauan sendiri. Memantau aplikasi yang kompleks itu sendiri sudah merupakan upaya teknis yang besar. Meskipun sudah ada infrastruktur untuk instrumentasi, pengumpulan dan penampilan data, serta pemberitahuan yang diterapkan, membuat dan mengelola hal ini memerlukan usaha dan waktu yang tinggi.

Coba gunakan Cloud Monitoring untuk mendapatkan visibilitas terkait performa, ketersediaan, dan kesehatan aplikasi serta infrastruktur Anda, baik untuk resource lokal maupun cloud.

Cloud Monitoring adalah layanan terkelola yang merupakan bagian dari Kemampuan Observasi Google Cloud. Anda dapat menggunakan Cloud Monitoring untuk memantau layanan Google Cloud dan metrik kustom. Cloud Monitoring menyediakan API untuk integrasi dengan alat pemantauan pihak ketiga.

Cloud Monitoring menggabungkan metrik, log, dan peristiwa dari infrastruktur berbasis cloud sistem Anda. Dengan data tersebut, developer dan operator memiliki banyak sinyal untuk diamati, yang dapat mempercepat analisis akar masalah dan mengurangi waktu rata-rata untuk melakukan penyelesaian. Anda dapat menggunakan Cloud Monitoring untuk menentukan pemberitahuan dan metrik kustom yang sesuai dengan tujuan bisnis Anda dan membantu Anda menggabungkan, memvisualisasikan, dan memantau kesehatan sistem.

Cloud Monitoring menyediakan dasbor default untuk layanan aplikasi cloud dan open source. Dengan model metrik, Anda dapat menentukan dasbor kustom dengan alat visualisasi yang canggih dan mengonfigurasi diagram di Metrics Explorer.

Menyiapkan pemberitahuan

Sistem peringatan yang baik akan meningkatkan kemampuan Anda untuk merilis fitur. Fitur ini membantu membandingkan performa dari waktu ke waktu untuk menentukan kecepatan rilis fitur atau kebutuhan untuk melakukan roll back rilis fitur. Untuk informasi tentang rollback, lihat Memulihkan rilis sebelumnya dengan lancar.

Saat Anda menyiapkan pemberitahuan, petakan pemberitahuan langsung ke metrik yang penting. Metrik penting ini mencakup:

• Empat sinyal emas:
  • Latensi
  • Traffic
  • Error
  • Saturasi
• Kesehatan sistem
• Service usage
• Peristiwa keamanan
• Pengalaman pengguna

Buat pemberitahuan dapat ditindaklanjuti untuk meminimalisasi waktu penyelesaian. Caranya, untuk setiap pemberitahuan:

• Sertakan deskripsi yang jelas, termasuk menyatakan apa yang dipantau dan dampaknya terhadap bisnis.
• Berikan semua informasi yang diperlukan untuk segera bertindak. Jika diperlukan beberapa klik dan navigasi untuk memahami suatu pemberitahuan, maka masih sulit bagi staf siaga untuk bertindak.
• Tentukan tingkat prioritas untuk berbagai pemberitahuan.
• Identifikasi orang atau tim yang bertanggung jawab untuk merespons pemberitahuan dengan jelas.

Untuk aplikasi dan layanan penting, integrasikan tindakan pemulihan mandiri ke dalam pemberitahuan yang dipicu karena kondisi kesalahan umum, seperti kegagalan service health, perubahan konfigurasi, atau lonjakan throughput.

Saat menyiapkan pemberitahuan, cobalah untuk menghilangkan toil. Misalnya, hilangkan toil dengan menghilangkan error yang sering terjadi, atau mengotomatiskan perbaikan untuk error tersebut sehingga dapat menghindari memicu munculnya pemberitahuan. Dengan menghilangkan toil, staf yang siaga dapat berfokus untuk membuat komponen operasional aplikasi Anda menjadi andal. Untuk informasi selengkapnya, lihat Menciptakan budaya otomatisasi.

Buat dasbor pemantauan dan pemberitahuan

Setelah pemantauan diterapkan, buatlah dasbor yang relevan dan tidak rumit yang menyertakan informasi dari sistem pemantauan dan pemberitahuan Anda.

Memilih cara yang tepat untuk memvisualisasikan dasbor bisa jadi sulit untuk dikaitkan dengan sasaran keandalan Anda. Buatlah dasbor untuk memvisualisasikan:

• Analisis jangka pendek dan real-time
• Analisis jangka panjang

Untuk mengetahui informasi selengkapnya tentang menerapkan pengelolaan visual, lihat artikel kemampuan Pengelolaan visual.

Aktifkan logging untuk aplikasi penting

Layanan logging sangatlah penting untuk memantau sistem Anda. Metrik membentuk dasar item tertentu yang akan dipantau, sedangkan log berisi informasi berharga yang Anda perlukan untuk proses debug, analisis terkait keamanan, dan persyaratan kepatuhan.

Melakukan logging atas data yang dihasilkan sistem membantu Anda memastikan postur keamanan yang efektif. Untuk informasi selengkapnya tentang logging dan keamanan, lihat Menerapkan kontrol logging dan detektif dalam kategori keamanan Framework Arsitektur.

Cloud Logging adalah layanan logging terintegrasi yang dapat Anda gunakan untuk menyimpan, menelusuri, menganalisis, memantau, serta membuat pemberitahuan terkait data dan peristiwa log. Logging akan otomatis mengumpulkan log dari layanan Google Cloud dan penyedia cloud lainnya. Anda dapat menggunakan log tersebut untuk membuat metrik guna memantau dan membuat ekspor logging ke layanan eksternal seperti Cloud Storage BigQuery, dan Pub/Sub.

Menyiapkan jejak audit

Untuk membantu menjawab pertanyaan seperti "siapa yang melakukan apa, di mana, dan kapan" dalam project Google Cloud Anda, gunakan Cloud Audit Logs.

Cloud Audit Logs merekam beberapa jenis aktivitas, seperti berikut:

• Log Aktivitas Admin berisi entri log untuk panggilan API atau tindakan administratif lainnya yang mengubah konfigurasi atau metadata resource. Log Aktivitas Admin selalu dalam kondisi diaktifkan.
• Log audit Akses Data merekam panggilan API yang membuat, mengubah, atau membaca data yang disediakan pengguna. Log audit Akses Data dinonaktifkan secara default karena ukurannya yang kadang cukup besar. Anda dapat mengonfigurasi layanan Google Cloud mana yang menghasilkan log akses data.

Untuk mengetahui daftar layanan Google Cloud yang menghasilkan log audit, lihat Layanan Google dengan log audit. Gunakan kontrol Identity and Access Management (IAM) untuk membatasi siapa yang memiliki akses untuk melihat log audit.

Langkah selanjutnya

• Menetapkan dukungan cloud dan proses eskalasi (dokumen berikutnya dalam seri ini).
• Pelajari Kemampuan Observasi Google Cloud.
• Deploy Cloud Monitoring untuk mendapatkan visibilitas terkait performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda.
• Pelajari Pemantauan dan kemampuan observasi lebih lanjut.
• Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem, keamanan, privasi, serta kepatuhan, keandalan, pengoptimalan biaya, dan pengoptimalan performa.

Bentuk dukungan cloud dan proses eskalasi

Dokumen dalam Framework Arsitektur Google Cloud ini menunjukkan cara menentukan proses eskalasi yang efektif. Memberikan dukungan dari penyedia cloud Anda atau penyedia layanan pihak ketiga lainnya adalah bagian penting dari pengelolaan eskalasi yang efektif.

Google Cloud menyediakan berbagai saluran dukungan, termasuk dukungan langsung atau melalui panduan yang dipublikasikan seperti komunitas developer atau dokumentasi produk. Penawaran dari Cloud Customer Care memastikan Anda dapat bekerja sama dengan Google Cloud untuk menjalankan workload Anda secara efisien.

Bangun dukungan dari penyedia Anda

Beli kontrak dukungan dari penyedia cloud atau penyedia layanan pihak ketiga lainnya. Dukungan sangat penting untuk memastikan respons yang cepat dan penyelesaian berbagai masalah operasional.

Untuk bekerja sama dengan Layanan Pelanggan Google Cloud, pertimbangkan untuk membeli penawaran Layanan Pelanggan yang mencakup Dukungan Standard, Enhanced, atau Premium. Pertimbangkan untuk menggunakan Dukungan Enhanced atau Premium untuk lingkungan produksi utama Anda.

Tentukan proses eskalasi Anda

Proses eskalasi yang jelas adalah kunci untuk mengurangi upaya dan waktu yang diperlukan untuk mengidentifikasi dan mengatasi masalah apapun di sistem Anda. Ini termasuk masalah yang memerlukan dukungan untuk produk Google Cloud atau untuk produsen cloud atau layanan pihak ketiga lainnya.

Untuk membuat jalur eskalasi:

• Tentukan waktu dan cara mengeskalasi masalah secara internal.
• Tentukan kapan dan cara membuat kasus dukungan dengan penyedia cloud atau penyedia layanan pihak ketiga lainnya.
• Pelajari cara bekerja dengan tim yang memberi Anda dukungan. Untuk Google Cloud, Anda dan tim operasi Anda harus meninjau Praktik terbaik untuk bekerja dengan Layanan Pelanggan. Sertakan praktik ini dalam jalur eskalasi Anda.
• Temukan atau buat dokumen yang mendeskripsikan arsitektur Anda. Pastikan dokumen ini menyertakan informasi yang berguna bagi engineer dukungan.
• Tentukan cara tim Anda berkomunikasi selama pemadaman layanan.
• Pastikan orang yang memerlukan dukungan memiliki tingkat izin yang sesuai untuk mengakses Pusat Dukungan Google Cloud atau untuk berkomunikasi dengan penyedia dukungan lainnya. Untuk mempelajari cara menggunakan Pusat Dukungan Google Cloud, bukaProsedur dukungan.
• Siapkan pemantauan, pemberitahuan, dan logging sehingga Anda memiliki informasi yang diperlukan untuk ditindaklanjuti saat terjadi masalah.
• Membuat template untuk pelaporan insiden. Untuk mengetahui informasi yang dapat disertakan dalam laporan insiden, lihat Praktik terbaik untuk bekerja dengan Layanan Pelanggan.
• Dokumentasikan proses eskalasi organisasi Anda. Pastikan Anda memiliki tindakan yang jelas dan terdefinisi dengan baik untuk menangani eskalasi
• Sertakan rencana untuk mengajarkan anggota tim baru bagaimana cara berinteraksi dengan dukungan.

Uji secara rutin proses eskalasi Anda secara internal. Uji proses eskalasi Anda sebelum peristiwa besar seperti migrasi, peluncuran produk baru, dan peristiwa traffic puncak. Jika Anda memiliki Layanan Pelanggan Google Cloud Dukungan Premium, Manajer Akun Teknis Anda dapat membantu meninjau proses eskalasi dan mengoordinasikan pengujian dengan Google Cloud Layanan Pelanggan.

Pastikan Anda menerima komunikasi dari dukungan

Pastikan administrator Anda menerima komunikasi dari penyedia cloud dan layanan pihak ketiga. Informasi ini memungkinkan admin membuat keputusan yang tepat dan memperbaiki masalah sebelum menyebabkan masalah yang lebih besar. Pastikan hal berikut terpenuhi:

• Administrator keamanan, jaringan, dan sistem disiapkan untuk menerima email penting dari Google Cloud dan penyedia atau layanan Anda yang lain.
• Administrator keamanan jaringan dan sistem disiapkan untuk menerima pemberitahuan sistem yang dihasilkan oleh alat pemantauan, seperti Cloud Monitoring.
• Pemilik project memiliki nama pengguna yang dapat dirutekan melalui email, sehingga mereka dapat menerima email penting.

Untuk informasi tentang cara mengelola notifikasi dari Google Cloud, lihat Mengelola kontak untuk notifikasi.

Tetapkan proses peninjauan

Menetapkan peninjauan atau proses postmortem. Ikuti proses ini setelah Anda mengajukan tiket dukungan baru atau mengeskalasikan tiket bantuan yang ada. Sebagai bagian dari postmortem, dokumentasikan pelajaran yang diperoleh dan lacak mitigasi. Saat Anda melakukan ulasan ini, tanamkan budaya postmortem blameless.

Untuk mengetahui informasi selengkapnya tentang postmortem, lihat Budaya Postmortem: Belajar dari Kegagalan.

Bangun pusat keunggulan

Ada baiknya untuk menangkap informasi, pengalaman dan pola organisasi Anda dalam basis pengetahuan internal, seperti wiki, situs Google, atau situs intranet. Karena produk dan fitur baru terus diluncurkan di Google Cloud, pengetahuan ini dapat membantu melacak alasan Anda memilih desain tertentu untuk aplikasi dan layanan Anda. Untuk informasi selengkapnya, lihat Catatan keputusan arsitektur.

Ini juga merupakan praktik yang baik untuk menominasikan pakar dan juara Google Cloud di organisasi Anda. Tersedia berbagai opsi pelatihan dan sertifikasi untuk membantu para juara yang dinominasikan berkembang di bidang keahlian mereka. Para tim dapat terus mendapatkan berita, pengumuman, dan kisah pelanggan yang terbaru dengan berlangganan ke blog Google Cloud.

Langkah selanjutnya

• Mengelola kapasitas dan kuota (dokumen berikutnya dalam seri ini)
• Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem keamanan, privasi, dan kepatuhan, keandalan, pengoptimalan biaya, serta pengoptimalan performa.

Kelola kapasitas dan kuota

Dokumen dalam Framework Arsitektur Google Cloud ini menunjukkan cara memberikan evaluasi serta merencanakan kapasitas dan kuota Anda di cloud.

Di pusat data konvensional, Anda biasanya menghabiskan siklus setiap kuartal untuk meninjau persyaratan resource saat ini dan memperkirakan persyaratan mendatang. Anda harus mempertimbangkan masalah terkait fisik, logistik, dan sumber daya manusia. Urusan seperti ruang rak, pendinginan, listrik, bandwidth, pemasangan kabel, waktu pengadaan, waktu pengiriman, dan jumlah engineer yang tersedia untuk menyiapkan rak dan menumpuk peralatan baru perlu dipertimbangkan. Anda juga harus secara aktif mengelola distribusi kapasitas dan workload sehingga tugas yang membutuhkan banyak resource, seperti pipeline Hadoop, tidak akan mengganggu layanan, seperti server web, yang harus memiliki banyak ketersediaan.

Sebaliknya, saat menggunakan Google Cloud, Anda menyerahkan sebagian besar perencanaan kapasitas kepada Google. Menggunakan cloud berarti Anda tidak perlu menyediakan dan memelihara resource nonaktif saat tidak diperlukan. Misalnya, Anda dapat membuat, meningkatkan skala, dan menurunkan skala instance VM sesuai kebutuhan. Karena membayar untuk apa yang digunakan, Anda dapat mengoptimalkan pengeluaran, termasuk kelebihan kapasitas yang hanya Anda butuhkan pada waktu puncak traffic. Untuk membantu Anda menyimpan, Compute Engine memberikan rekomendasi jenis mesin jika Compute Engine mendeteksi bahwa Anda memiliki instance VM yang kurang dimanfaatkan, yang dapat diubah ukurannya atau dihapus.

Evaluasi kebutuhan kapasitas cloud Anda

Untuk mengelola kapasitas secara efektif, Anda perlu mengetahui persyaratan kapasitas organisasi Anda.

Untuk mengevaluasi persyaratan kapasitas Anda, mulailah dengan mengidentifikasi workload cloud teratas Anda. Berikan evaluasi penggunaan rata-rata dan puncak workload ini, serta kebutuhan kapasitasnya saat ini dan di masa mendatang.

Identifikasi tim yang menggunakan workload teratas ini. Bekerja dengan mereka untuk membangun proses perencanaan permintaan internal. Gunakan proses ini untuk memahami kebutuhan resource cloud mereka saat ini dan perkiraan kebutuhannya.

Analisis pola pemuatan dan distribusi panggilan. Gunakan faktor seperti 30 hari terakhir terakhir, puncak per jam, dan puncak per menit dalam analisis Anda.

Pertimbangkan untuk menggunakan Cloud Monitoring untuk mendapatkan visibilitas yang ada kaitannya dengan performa, waktu beroperasi, dan kondisi keseluruhan aplikasi serta infrastruktur Anda.

Lihat metrik penggunaan infrastruktur Anda

Untuk mempermudah perencanaan kapasitas, kumpulkan dan simpan data historis tentang penggunaan resource cloud yang digunakan organisasi Anda.

Pastikan Anda memiliki visibilitas terkait metrik penggunaan infrastruktur. Misalnya, untuk workload teratas, evaluasi hal berikut:

• Pemakaian rata-rata dan puncak
• Lonjakan dalam pola penggunaan
• Lonjakan musiman berdasarkan persyaratan bisnis, seperti periode liburan untuk retailer
• Jumlah penyediaan yang berlebihan yang diperlukan untuk mempersiapkan peristiwa puncak dan menangani potensi lonjakan traffic dengan cepat

Pastikan organisasi Anda telah menyiapkan pemberitahuan agar mendapatkan pemberitahuan secara otomatis saat Anda mendekati batas kuota dan kapasitas.

Gunakan alat pemantauan Google untuk mendapatkan insight penggunaan dan kapasitas aplikasi. Misalnya, Anda dapat menentukan metrik kustom dengan Monitoring. Gunakan metrik kustom ini untuk menentukan tren pemberitahuan. Monitoring juga menyediakan dasbor fleksibel dan alat visualisasi yang beragam untuk membantu mengidentifikasi kemunculan masalah.

Buat proses untuk perencanaan kapasitas

Tetapkan proses untuk perencanaan kapasitas dan dokumentasikan rencana ini.

Saat Anda membuat rencana ini, lakukan hal berikut:

1. Jalankan uji beban untuk menentukan seberapa banyak beban yang dapat ditangani sistem sementara memenuhi target latensi, dengan jumlah resource yang tetap. Pengujian beban harus menggunakan campuran jenis permintaan yang cocok dengan profil traffic produksi dari pengguna aktif. Jangan gunakan campuran operasi yang seragam atau acak. Sertakan lonjakan penggunaan dalam profil traffic Anda.
2. Buat model kapasitas. Model kapasitas adalah sekumpulan formula untuk menghitung resource inkremental yang diperlukan per peningkatan unit dalam beban layanan, seperti yang ditentukan dari pengujian beban.
3. Perkirakan traffic mendatang dan perhitungkan pertumbuhan. Lihat artikel Mengukur Pemuatan Masa Depan untuk ringkasan tentang cara Google membuat perkiraan traffic.
4. Terapkan model kapasitas ke perkiraan untuk menentukan kebutuhan sumber daya di masa mendatang.
5. Perkirakan biaya resource yang dibutuhkan oleh organisasi Anda. Kemudian, dapatkan persetujuan anggaran dari bagian Keuangan Anda. Langkah ini sangat penting karena bisnis dapat menentukan untuk melakukan kompromi biaya versus risiko di berbagai produk. Konsekuensi tersebut dapat berarti memperoleh kapasitas yang lebih rendah atau lebih tinggi dibandingkan dengan prediksi kebutuhan untuk produk tertentu berdasarkan prioritas bisnis.
6. Bekerja samalah dengan penyedia cloud Anda untuk mendapatkan jumlah resource yang tepat pada waktu yang tepat dengan kuota dan reservasi. Libatkan tim infrastruktur untuk perencanaan kapasitas dan membuat operasi membuat rencana kapasitas dengan interval keyakinan.
7. Ulangi langkah sebelumnya setiap seperempat atau dua langkah.

Untuk panduan yang lebih mendetail tentang proses perencanaan kapasitas sekaligus mengoptimalkan penggunaan resource, lihat Perencanaan Kapasitas.

Pastikan kuota Anda sesuai dengan kebutuhan kapasitas Anda

Google Cloud menggunakan quotas untuk membatasi jumlah resource Google Cloud bersama yang dapat Anda gunakan. Setiap kuota mewakili resource tertentu yang dapat dihitung, seperti panggilan API ke layanan tertentu, jumlah load balancer yang digunakan secara bersamaan oleh berbagai project Anda, atau jumlah project yang dapat Anda buat Misalnya, kuota memastikan bahwa beberapa pelanggan atau project tidak dapat memonopoli core CPU di wilayah atau zona tertentu.

Saat melakukan peninjauan kuota, pertimbangkan detail berikut:

• Rencanakan dahulu persyaratan kapasitas project Anda untuk mencegah pembatasan yang tidak terduga pada konsumsi resource Anda
• Siapkan kuota dan kapasitas Anda untuk menangani region gagal penuh.
• Gunakan kuota untuk membatasi pemakaian resource tertentu. Misalnya, Anda dapat menetapkan kuota maksimum penggunaan kueri per hari melalui BigQuery API untuk memastikan bahwa project tidak melakukan pembelanjaan berlebihan di BigQuery.
• Buat rencana lonjakan penggunaan dan sertakan lonjakan ini sebagai bagian dari perencanaan kuota Anda. Lonjakan penggunaan dapat berupa fluktuasi yang diperkirakan sepanjang hari, peristiwa traffic puncak yang tidak terduga, atau peristiwa peluncuran dan traffic puncak yang diketahui. Untuk detail tentang cara merencanakan traffic puncak dan peristiwa peluncuran, baca bagian berikutnya di Keunggulan Operasional: Merencanakan traffic puncak dan peristiwa peluncuran.

Jika kuota saat ini tidak cukup, Anda dapat mengelola kuota menggunakan Google Cloud Console. Jika Anda memerlukan kapasitas besar, hubungi tim penjualan Google Cloud. Namun, Anda perlu mengetahui bahwa banyak layanan juga memiliki batasan yang tidak terkait dengan sistem kuota. Untuk mengetahui informasi selengkapnya, lihat Menangani kuota.

Tinjau kuota Anda secara berkala. Kirimkan permintaan kuota sebelum diperlukan. Baca artikel Menangani kuota untuk mengetahui detail tentang cara permintaan kuota dievaluasi dan cara permintaan disetujui atau ditolak.

Terdapat beberapa cara untuk melihat dan mengelola kuota Google Cloud Anda:

• Menggunakan Google Cloud Console
• Menggunakan Google Cloud CLI
• Menggunakan Service Usage API
• Menggunakan Monitoring untuk melihat metrik penawaran harga
• Untuk mengelola kuota di banyak project Google Cloud dalam organisasi atau folder, pertimbangkan untuk menerapkan Solusi Dasbor Pemantauan Kuota.

Langkah selanjutnya

• Rencanakan traffic puncak dan peristiwa peluncuran (dokumen berikutnya dalam seri ini)
• Pelajari kategori lain dalam Framework Arsitektur seperti desain sistem, keamanan, privasi, dan kepatuhan, keandalan, pengoptimalan biaya, dan pengoptimalan performa.

Buat rencana untuk peristiwa traffic puncak dan peluncuran

Dokumen dalam Framework Arsitektur Google Cloud ini menunjukkan cara untuk merencanakan peristiwa traffic puncak dan peluncuran agar bisnis Anda tidak terganggu.

Peristiwa puncak adalah peristiwa besar yang terkait dengan bisnis. Peristiwa ini menyebabkan peningkatan tajam pada traffic yang melampaui garis dasar standar aplikasi. Peristiwa puncak ini memerlukan penskalaan yang direncanakan.

Misalnya, bisnis retail yang ada di internet dapat mengharapkan peristiwa puncak selama liburan. Black Friday yang berlangsung setelah hari Thanksgiving di Amerika Serikat adalah salah satu hari belanja tersibuk dalam tahun ini. Untuk industri layanan kesehatan di Amerika Serikat, bulan Oktober dan November dapat menjadi peristiwa puncak karena lonjakan traffic untuk pendaftaran manfaat.

Peristiwa peluncuran adalah peluncuran substansial atau migrasi kemampuan baru dalam produksi. Misalnya, migrasi dari lokal ke cloud, atau peluncuran layanan atau fitur produk baru.

Jika meluncurkan produk baru, Anda akan melihat peningkatan beban pada sistem saat pemberitahuan dan mungkin setelahnya. Peristiwa ini sering kali dapat menyebabkan peningkatan beban 5–20 kali lipat (atau lebih besar) pada sistem frontend. Peningkatan beban tersebut juga dapat meningkatkan beban pada sistem backend. Sering kali, beban frontend dan backend ditandai dengan penskalaan cepat dalam waktu singkat saat peristiwa terbuka untuk traffic web. Peristiwa peluncuran melibatkan penurunan akhir pada traffic ke level normal. Penurunan ini biasanya lebih lambat dari skala untuk mencapai puncak.

Peristiwa puncak dan peluncuran mencakup tiga tahap:

• Perencanaan dan persiapan untuk peristiwa peluncuran atau traffic puncak
• Peluncuran peristiwa
• Peninjauan performa peristiwa dan analisis pasca-peristiwa

Praktik yang dijelaskan dalam dokumen ini dapat membantu setiap tahapan ini untuk berjalan dengan lancar.

Membuat playbook umum untuk peristiwa puncak dan peluncuran

Buat playbook umum untuk gambaran jangka panjang tentang peristiwa puncak di saat ini dan di masa mendatang. Terus tambahkan pengalaman yang diperoleh ke dalam dokumen agar dapat menjadi referensi peristiwa puncak di masa mendatang.

Merencanakan peluncuran dan peristiwa puncak

Buat rencana ke depan. Buat proyeksi bisnis untuk peluncuran mendatang, serta untuk peristiwa puncak yang diharapkan (dan yang tidak terduga). Persiapkan sistem untuk menghadapi lonjakan skala berdasarkan pemahaman proyeksi bisnis Anda. Makin banyak yang diketahui tentang perkiraan sebelumnya, Anda dapat makin akurat dalam membuat perkiraan bisnis baru. Perkiraan baru tersebut adalah input penting untuk memproyeksikan permintaan yang diharapkan pada sistem.

Menetapkan manajemen program dan perencanaan yang terkoordinasi (di seluruh organisasi dan dengan vendor pihak ketiga) juga termasuk kunci kesuksesan. Siapkan tim ini lebih awal agar tim manajemen program dapat menetapkan linimasa, mengamankan anggaran, dan mengumpulkan resource untuk infrastruktur tambahan, dukungan pengujian, dan pelatihan.

Anda harus menyiapkan saluran komunikasi yang jelas. Komunikasi sangatlah penting untuk semua tahapan dalam peluncuran atau peristiwa puncak. Diskusikan dulu risiko dan area yang dikhawatirkan, lalu akhiri masalah sebelum masalah tersebut menjadi penghambat. Buat dokumentasi perencanaan peristiwa. Ringkas informasi terpenting tentang peristiwa puncak, lalu distribusikan informasi tersebut. Langkah ini dapat membantu orang-orang menyerap informasi dan menemukan jawaban dari pertanyaan dasar. Dokumen tersebut dapat membantu orang-orang baru agar lebih cepat dalam merencanakan peristiwa puncak.

Dokumentasikan rencana untuk setiap peristiwa. Saat mendokumentasikan rencana, pastikan Anda melakukan langkah-langkah berikut:

• Identifikasi asumsi, risiko, dan faktor yang tidak diketahui.
• Tinjau peristiwa sebelumnya guna menentukan informasi yang relevan untuk peristiwa puncak atau peluncuran mendatang. Tentukan data yang tersedia dan nilai yang telah diberikan oleh data di peristiwa sebelumnya.
• Buat detail rencana rollback untuk peristiwa peluncuran dan migrasi.
• Lakukan tinjauan arsitektur:
  • Dokumentasikan resource utama dan komponen arsitektur.
  • Gunakan Framework Arsitektur untuk meninjau semua aspek lingkungan terkait risiko dan masalah skala.
  • Buat diagram yang menunjukkan cara komponen utama arsitektur terhubung. Peninjauan diagram dapat membantu Anda untuk mengisolasi masalah, serta mempercepat penyelesaiannya.
• Jika sesuai, konfigurasikan layanan untuk menggunakan tindakan pemberitahuan agar dapat memulai ulang otomatis saat terjadi kegagalan. Saat menggunakan Compute Engine, pertimbangkan untuk menggunakan penskalaan otomatis guna menangani lonjakan throughput.
• Untuk memastikan bahwa resource Compute Engine tersedia saat dibutuhkan, gunakan Pemesanan. Pemesanan memberikan tingkat jaminan yang sangat tinggi dalam mendapatkan kapasitas resource zona Compute Engine. Anda dapat menggunakan pemesanan untuk membantu memastikan bahwa project Anda memiliki resource yang tersedia.
• Identifikasi metrik dan pemberitahuan untuk dilacak:
  • Identifikasi bisnis dan metrik sistem untuk memantau peristiwa. Jika metrik atau indikator tingkat layanan (SLI) tidak dikumpulkan, ubah sistem ini untuk mengumpulkan data ini.
  • Pastikan Anda memiliki kemampuan pemantauan dan pemberitahuan yang memadai, serta sudah meninjau pola traffic puncak normal dan pola traffic sebelumnya. Pastikan pemberitahuan ditetapkan dengan tepat. Gunakan alat Google Cloud Monitoring untuk melihat penggunaan aplikasi, kapasitas, serta kondisi keseluruhan aplikasi dan infrastruktur Anda.
  • Pastikan metrik sistem direkam dengan tingkat kepentingan pemantauan dan pemberitahuan.
• Tinjau peningkatan persyaratan kapasitas dengan tim akun Google Cloud dan rencanakan pengelolaan kuota yang diperlukan. Untuk detail selengkapnya, baca Memastikan kuota sesuai dengan persyaratan kapasitas.
• Pastikan Anda memiliki tingkat dukungan cloud yang sesuai, tim Anda memahami cara membuka kasus dukungan, dan Anda sudah menetapkan jalur eskalasi. Untuk detail selengkapnya, tinjau Membuat dukungan cloud dan proses eskalasi.
• Tetapkan rencana komunikasi, linimasa, dan tanggung jawab:
  • Libatkan pemangku kepentingan lintas fungsi untuk mengoordinasikan komunikasi dan perencanaan program. Pemangku kepentingan ini dapat mencakup orang-orang yang sesuai dari tim teknis, operasional, dan kepemimpinan, serta vendor pihak ketiga.
  • Tetapkan linimasa yang jelas berisi tugas penting dan tim yang memiliki tugas tersebut.
  • Buat matriks penugasan tanggung jawab (RACI) guna menyampaikan kepemilikan untuk tim, pemimpin tim, pemangku kepentingan, dan pihak yang bertanggung jawab.
  • Anda dapat menggunakan Layanan Pengelolaan Peristiwa Dukungan Premium untuk peristiwa puncak yang direncanakan. Dengan layanan ini, Layanan Pelanggan bermitra dengan tim Anda untuk membuat rencana dan memberikan panduan selama peristiwa berlangsung.

Tetapkan proses peninjauan

Saat peristiwa traffic puncak atau peristiwa peluncuran selesai, tinjau peristiwa tersebut untuk mendokumentasikan pengalaman yang dipelajari. Lalu, update playbook Anda dengan pengalaman tersebut. Akhirnya, terapkan pengalaman yang sudah dipelajari untuk peristiwa besar berikutnya. Belajar dari peristiwa sebelumnya itu penting, terutama saat peristiwa tersebut menyoroti batasan pada sistem selama berada dalam tekanan.

Peninjauan retrospektif, disebut juga sebagai postmortem, untuk peristiwa traffic puncak atau peristiwa peluncuran adalah teknik yang berguna untuk pengambilan data dan memahami insiden yang terjadi. Lakukan peninjauan ini untuk peristiwa traffic puncak dan peluncuran yang berjalan seperti yang diharapkan, serta untuk insiden yang menyebabkan masalah. Saat melakukan peninjauan ini, tanamkan budaya untuk tidak menyalahkan orang lain.

Untuk informasi selengkapnya tentang postmortem, lihat Budaya Postmortem: Belajar dari Kegagalan.

Langkah selanjutnya

• Menciptakan budaya otomatisasi (dokumen berikutnya dalam seri ini)
• Pelajari kategori lain dalam Framework Arsitektur seperti desain sistem, keamanan, privasi, dan kepatuhan, keandalan, pengoptimalan biaya, dan pengoptimalan performa.

Ciptakan budaya otomatisasi

Dokumen dalam Framework Arsitektur Google Cloud ini menunjukkan cara menilai toil dan mengurangi dampaknya pada sistem dan tim Anda.

Toil adalah pekerjaan manual dan berulang tanpa nilai yang berkelanjutan, dan meningkat seiring dengan pertumbuhan layanan. Terus upayakan untuk mengurangi atau menghilangkan toil. Jika tidak, pekerjaan operasional pada akhirnya dapat membebani operator, dan setiap pertumbuhan penggunaan atau kompleksitas produk dapat memerlukan tambahan staf.

Otomatisasi adalah cara utama untuk meminimalkan toil. Otomatisasi juga meningkatkan kecepatan rilis dan membantu meminimalkan error yang disebabkan oleh manusia.

Untuk informasi selengkapnya, baca Menghilangkan Toil.

Buat inventaris dan lakukan penilaian biaya toil

Mulailah dengan membuat inventaris dan menilai biaya toil pada tim yang mengelola sistem Anda. Jadikan ini sebagai proses berkelanjutan, diikuti dengan berinvestasi dalam otomatisasi yang disesuaikan untuk memperluas apa yang sudah disediakan oleh layanan dan partner Google Cloud. Anda sering kali dapat memodifikasi otomatisasi Google Cloud sendiri—misalnya, autoscaler Compute Engine.

Prioritaskan untuk menghilangkan toil

Otomatisasi berguna, tetapi bukan solusi untuk semua masalah operasional. Sebagai langkah pertama dalam mengatasi toil yang diketahui, sebaiknya tinjau inventaris Anda dari toil yang ada dan prioritaskan untuk menghilangkan toil sebanyak mungkin. Kemudian, Anda dapat fokus pada otomatisasi.

Otomatiskan toil yang diperlukan

Beberapa toil dalam sistem Anda tidak dapat dihilangkan. Sebagai langkah kedua dalam mengatasi toil yang diketahui, otomatiskan toil ini menggunakan solusi yang disediakan Google Cloud melalui otomatisasi yang dapat dikonfigurasi.

Berikut adalah beberapa area dengan otomatisasi yang dapat dikonfigurasi atau otomatisasi yang disesuaikan dapat membantu organisasi Anda menghilangkan toil:

• Pengelolaan identitas—misalnya, Cloud Identity dan Identity and Access Management.
• Solusi yang dihosting Google Cloud, bukan solusi yang didesain sendiri—misalnya, pengelolaan cluster (Google Kubernetes Engine (GKE)), manajemen database relasional (Cloud SQL), pengelolaan data warehouse (BigQuery), dan pengelolaan API (Apigee).
• Layanan Google Cloud dan penyediaan tenant—misalnya, Terraform dan Cloud Foundation Toolkit.
• Orkestrasi alur kerja otomatis untuk operasi multi-langkah—misalnya, Cloud Composer.
• Penyediaan kapasitas tambahan—misalnya, beberapa produk Google Cloud, seperti Compute Engine dan GKE, menawarkan penskalaan otomatis yang dapat dikonfigurasi. Evaluasi layanan Google Cloud yang Anda gunakan untuk menentukan apakah layanan tersebut mencakup penskalaan otomatis yang dapat dikonfigurasi.
• Pipeline CI/CD dengan deployment otomatis—misalnya, Cloud Build.
• Analisis canary untuk memvalidasi deployment.
• Pelatihan model otomatis (untuk machine learning)—misalnya, AutoML.

Jika produk atau layanan Google Cloud hanya memenuhi sebagian kebutuhan teknis Anda saat mengotomatiskan atau menghapus alur kerja manual, pertimbangkan untuk mengajukan permintaan fitur melalui perwakilan akun Google Cloud Anda. Masalah Anda mungkin menjadi prioritas bagi pelanggan lain atau sudah menjadi bagian dari roadmap kami. Jika demikian, mengetahui prioritas dan linimasa fitur akan membantu Anda menilai dengan lebih baik konsekuensi dari pembuatan solusi sendiri dibandingkan menunggu untuk menggunakan fitur Google Cloud.

Build atau beli solusi untuk toil berbiaya tinggi

Langkah ketiga, yang dapat diselesaikan secara paralel dengan langkah pertama dan kedua, mencakup evaluasi pembuatan atau pembelian solusi lain jika biaya toil Anda tetap tinggi—misalnya, jika toil memakan banyak waktu untuk tim mana pun yang mengelola sistem produksi Anda.

Saat membuat atau membeli solusi, pertimbangkan biaya integrasi, keamanan, privasi, dan kepatuhan. Merancang dan menerapkan otomatisasi Anda sendiri memunculkan biaya pemeliharaan dan risiko terhadap keandalan di luar biaya pengembangan dan penyiapan awal, jadi pertimbangkan opsi ini sebagai upaya terakhir.

Langkah selanjutnya

Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem keamanan, privasi, dan kepatuhan, keandalan, pengoptimalan biaya, serta pengoptimalan performa.

Framework Arsitektur Google Cloud: Keamanan, privasi, dan kepatuhan

Kategori dalam Framework Arsitektur Google Cloud ini menunjukkan cara merancang dan mengoperasikan layanan yang aman di Google Cloud. Anda juga akan mempelajari tentang produk Google Cloud dan fitur yang mendukung keamanan dan kepatuhan.

Framework Arsitektur menjelaskan praktik terbaik, menyediakan rekomendasi implementasi, dan menjelaskan beberapa produk dan layanan yang tersedia. Framework ini membantu Anda mendesain deployment Google Cloud agar cocok dengan kebutuhan bisnis Anda.

Memindahkan workload Anda ke Google Cloud memerlukan evaluasi dari kebutuhan bisnis, risiko. kewajiban kepatuhan, dan kontrol keamanan Anda. Dokumen ini membantu Anda mempertimbangkan praktik terbaik utama terkait perancangan solusi aman di Google Cloud.

Prinsip inti Google mencakup pertahanan secara mendalam, dalam skala besar, dan secara default. Di Google Cloud, data dan sistem dilindungi melalui pertahanan berlapis dengan menggunakan kebijakan dan kontrol yang dikonfigurasi melalui IAM, enkripsi networking, deteksi, logging dan monitoring.

Google Cloud dilengkapi dengan banyak kontrol keamanan yang dapat Anda bangun, seperti berikut:

• Opsi aman untuk data dalam pengiriman, dan enkripsi default untuk data dalam penyimpanan.
• Fitur keamanan bawaan untuk produk dan layanan Google Cloud.
• Infrastruktur global yang didesain untuk geo-redundansi, dengan kontrol keamanan di sepanjang siklus pemrosesan informasi.
• Kemampuan otomatisasi yang menggunakan infrastruktur sebagai kode (IaC) dan pelindung konfigurasi.

Untuk informasi selengkapnya tentang postur keamanan Google Cloud, lihat Makalah keamanan Google dan Ringkasan Desain Keamanan Infrastruktur Google. Untuk mengetahui contoh lingkungan yang aman secara default, lihat blueprint Enterprise Foundation Google Cloud.

Dalam kategori keamanan Framework Arsitektur, Anda akan mempelajari cara melakukan hal-hal berikut:

• Meninjau tanggung jawab bersama dan konsekuensi bersama di Google Cloud
• Memahami prinsip keamanan
• Mengelola risiko dengan kontrol
• Mengelola aset
• Mengelola identitas dan akses
• Mengimplementasikan keamanan komputasi dan container
• Mengamankan jaringan Anda
• Menerapkan keamanan data
• Men-deploy keamanan aplikasi
• Mengelola kewajiban kepatuhan
• Menerapkan persyaratan residensi dan kedaulatan data
• Menerapkan persyaratan privasi
• Mengimplementasikan kontrol logging dan detektif

Tanggung jawab dan konsekuensi bersama di Google Cloud

Dokumen ini menjelaskan perbedaan antara model tanggung jawab bersama dan konsekuensi bersama di Google Cloud. Bagian ini membahas tantangan dan nuansa model tanggung jawab bersama. Dokumen ini menjelaskan tentang konsekuensi bersama dan cara kami bermitra dengan pelanggan untuk mengatasi tantangan keamanan cloud.

Memahami model tanggung jawab bersama sangatlah penting saat menentukan cara terbaik untuk melindungi data dan workload Anda di Google Cloud. Model tanggung jawab bersama menjelaskan tugas yang Anda miliki terkait keamanan di cloud dan perbedaan tugas ini untuk penyedia cloud.

Namun, memahami tanggung jawab bersama bisa menjadi tantangan tersendiri. Model ini memerlukan pemahaman mendalam tentang setiap layanan yang Anda gunakan, opsi konfigurasi yang disediakan setiap layanan, dan hal yang dilakukan Google Cloud untuk mengamankan layanan. Setiap layanan memiliki profil konfigurasi yang berbeda, dan sulit untuk menentukan konfigurasi keamanan terbaik. Google yakin bahwa model tanggung jawab bersama tidak akan membantu pelanggan cloud mencapai hasil keamanan yang lebih baik. Kami percaya pada konsekuensi bersama, bukan tanggung jawab bersama.

Konsekuensi bersama memungkinkan kami membangun dan mengoperasikan platform cloud tepercaya untuk workload Anda. Kami memberikan panduan praktik terbaik dan kode infrastruktur yang aman dan tervalidasi yang dapat Anda gunakan untuk men-deploy workload dengan cara yang aman. Kami merilis solusi yang menggabungkan berbagai layanan Google Cloud untuk mengatasi masalah keamanan yang kompleks dan kami menawarkan opsi asuransi yang inovatif untuk membantu Anda mengukur dan mengurangi risiko yang harus Anda terima. Konsekuensi bersama melibatkan kami agar lebih dekat dengan Anda saat Anda mengamankan resource di Google Cloud.

Tanggung jawab bersama

Anda adalah pakar dalam mengetahui persyaratan keamanan dan peraturan untuk bisnis, serta mengetahui persyaratan untuk melindungi data dan resource rahasia. Saat menjalankan workload di Google Cloud, Anda harus mengidentifikasi kontrol keamanan yang perlu dikonfigurasi di Google Cloud untuk membantu melindungi data rahasia dan setiap workload. Untuk menentukan kontrol keamanan yang akan diterapkan, Anda harus mempertimbangkan faktor-faktor berikut:

• Kewajiban kepatuhan terhadap peraturan Anda
• Standar keamanan dan rencana manajemen risiko organisasi Anda
• Persyaratan keamanan pelanggan dan vendor Anda

Ditentukan oleh workload

Secara tradisional, tanggung jawab ditentukan berdasarkan jenis workload yang Anda jalankan dan layanan cloud yang Anda butuhkan. Layanan cloud mencakup kategori berikut:

Layanan cloud	Deskripsi
Infrastructure as a Service (IaaS)	Layanan IaaS mencakup Compute Engine, Cloud Storage, dan layanan jaringan seperti Cloud VPN, Cloud Load Balancing, dan Cloud DNS. IaaS menyediakan layanan komputasi, penyimpanan, dan jaringan on demand dengan harga bayar sesuai penggunaan. Anda dapat menggunakan IaaS jika berencana memigrasikan lokal yang ada ke cloud menggunakan lift-and-shift, atau jika Anda ingin menjalankan aplikasi pada VM tertentu, menggunakan konfigurasi jaringan. Di IaaS, sebagian besar tanggung jawab keamanan adalah milik Anda, dan tanggung jawab kami difokuskan pada infrastruktur dasar serta keamanan fisik.
Platform as a Service (PaaS)	Layanan PaaS mencakup App Engine, Google Kubernetes Engine (GKE), dan BigQuery. PaaS menyediakan lingkungan runtime tempat Anda dapat mengembangkan dan menjalankan aplikasi. Anda dapat menggunakan PaaS saat membangun aplikasi (seperti situs web), dan ingin berfokus pada pengembangan, bukan pada infrastruktur yang mendasarinya. Di PaaS, kami bertanggung jawab atas lebih banyak kontrol daripada di IaaS, termasuk kontrol jaringan. Anda berbagi tanggung jawab dengan kami terkait kontrol tingkat aplikasi dan pengelolaan IAM. Anda tetap bertanggung jawab atas keamanan data dan perlindungan klien Anda.
Software as a Service (SaaS)	Aplikasi SaaS mencakup Google Workspace, Chronicle, dan aplikasi SaaS pihak ketiga yang tersedia di Google Cloud Marketplace. SaaS menyediakan aplikasi online yang memungkinkan Anda berlangganan atau membayar dengan cara tertentu. Anda dapat menggunakan aplikasi SaaS saat perusahaan Anda tidak memiliki keahlian internal atau persyaratan bisnis untuk membangun aplikasi itu sendiri tetapi memerlukan kemampuan untuk memproses workload. Di SaaS, kami memiliki sebagian besar tanggung jawab keamanan. Anda tetap bertanggung jawab atas kontrol akses dan data yang Anda pilih untuk disimpan di aplikasi.
Function as a Service (FaaS) atau serverless	FaaS menyediakan platform bagi developer untuk menjalankan kode kecil dengan satu tujuan (disebut fungsi) yang berjalan sebagai respons terhadap peristiwa tertentu. Anda akan menggunakan FaaS ketika Anda ingin hal-hal tertentu terjadi berdasarkan peristiwa tertentu. Misalnya, Anda dapat membuat fungsi yang berjalan setiap kali data diupload ke Cloud Storage sehingga dapat diklasifikasikan. FaaS memiliki daftar tanggung jawab bersama yang serupa dengan SaaS. Cloud Functions adalah aplikasi FaaS.

Diagram berikut menunjukkan layanan cloud dan menentukan cara berbagi tanggung jawab antara penyedia cloud dan pelanggan.

Seperti yang ditunjukkan dalam diagram, penyedia cloud selalu bertanggung jawab atas jaringan dan infrastruktur yang mendasarinya, dan pelanggan selalu bertanggung jawab atas kebijakan akses dan data mereka.

Ditentukan oleh framework peraturan dan industri

Berbagai industri memiliki kerangka peraturan yang menentukan kontrol keamanan yang harus diterapkan. Saat memindahkan workload ke cloud, Anda harus memahami hal-hal berikut:

• Kontrol keamanan mana yang menjadi tanggung jawab Anda
• Kontrol keamanan mana yang tersedia sebagai bagian dari penawaran cloud
• Kontrol keamanan default mana yang diwarisi

Kontrol keamanan yang diwarisi (seperti enkripsi default dan kontrol infrastruktur kami) adalah kontrol yang dapat Anda berikan sebagai bagian dari bukti keamanan Anda kepada auditor dan badan pengatur. Misalnya, Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) menetapkan peraturan untuk pemroses pembayaran. Saat Anda memindahkan bisnis ke cloud, peraturan ini akan berlaku untuk Anda dan CSP. Untuk memahami pembagian tanggung jawab PCI DSS antara Anda dan Google Cloud, lihat Google Cloud: Matriks Tanggung Jawab Bersama PCI DSS.

Sebagai contoh lain, di Amerika Serikat, Health Insurance Portability and Accountability Act (HIPAA) telah menetapkan standar untuk menangani informasi kesehatan pribadi elektronik (PHI). Tanggung jawab ini juga dibagi antara CSP dan Anda. Untuk informasi selengkapnya tentang cara Google Cloud memenuhi tanggung jawab kami berdasarkan HIPAA, lihat HIPAA - Kepatuhan.

Industri lain (seperti, keuangan atau manufaktur) juga memiliki peraturan yang menentukan cara data dikumpulkan, diproses, dan disimpan. Untuk informasi selengkapnya tentang tanggung jawab bersama terkait hal ini, dan bagaimana Google Cloud memenuhi tanggung jawab kami, lihat Pusat referensi kepatuhan.

Ditentukan menurut lokasi

Bergantung pada skenario bisnis, Anda mungkin perlu mempertimbangkan tanggung jawab berdasarkan lokasi kantor bisnis, pelanggan, dan data Anda. Beberapa negara dan wilayah telah membuat peraturan yang menentukan cara Anda dapat memproses dan menyimpan data pelanggan. Misalnya, jika bisnis Anda memiliki pelanggan yang tinggal di Uni Eropa, bisnis Anda mungkin harus mematuhi persyaratan yang dijelaskan dalam General Data Protection Regulation (GDPR), dan Anda mungkin diwajibkan untuk menyimpan data pelanggan di Uni Eropa. Dalam situasi ini, Anda bertanggung jawab untuk memastikan bahwa data yang Anda kumpulkan tetap berada di region Google Cloud di Uni Eropa. Untuk informasi selengkapnya tentang cara kami memenuhi kewajiban GDPR, baca artikel GDPR dan Google Cloud.

Untuk informasi persyaratan terkait region Anda, lihat Penawaran kepatuhan. Jika skenario Anda sangat rumit, sebaiknya hubungi tim penjualan atau salah satu partners kami untuk membantu mengevaluasi tanggung jawab keamanan.

Tantangan dari tanggung jawab bersama

Meskipun tanggung jawab bersama membantu menentukan peran keamanan yang Anda atau penyedia cloud miliki, mengandalkan tanggung jawab bersama tetap dapat menimbulkan tantangan. Perhatikan skenario berikut:

• Sebagian besar pelanggaran keamanan cloud diakibatkan oleh kesalahan konfigurasi (tercantum pada nomor 3 dalam Laporan Pandemic 11 Cloud Security Alliance) dan tren ini diperkirakan akan meningkat. Produk-produk cloud terus berubah, dan produk baru terus diluncurkan. Mengikuti perubahan secara terus-menerus bisa sangat melelahkan. Pelanggan memerlukan penyedia cloud untuk memberikan praktik terbaik opini agar dapat terus mengikuti perubahan, dimulai dengan praktik terbaik secara default dan memiliki konfigurasi dasar yang aman.
• Pembagian item dengan layanan cloud sangat membantu, banyak perusahaan memiliki workload yang memerlukan beberapa jenis layanan cloud. Dalam situasi ini Anda harus mempertimbangkan berbagai cara kontrol keamanan bagi layanan ini berinteraksi, termasuk apakah kontrol tersebut tumpang-tindih antar layanan. Misalnya, Anda mungkin memiliki aplikasi lokal yang dimigrasikan ke Compute Engine, menggunakan Google Workspace untuk email perusahaan, dan juga menjalankan BigQuery untuk menganalisis data guna meningkatkan kualitas produk Anda.
• Bisnis dan pasar Anda akan terus berubah; ketika peraturan berubah, saat Anda memasuki pasar baru, atau saat Anda mengakuisisi perusahaan lain. Pasar baru Anda mungkin memiliki persyaratan yang berbeda, dan akuisisi Anda yang baru mungkin menghosting workload di cloud lain. Untuk mengelola perubahan yang konstan, Anda harus terus menilai ulang profil risiko dan dapat menerapkan kontrol baru dengan cepat.
• Bagaimana dan dimana mengelola kunci enkripsi data adalah keputusan penting yang terikat dengan tanggung jawab untuk melindungi data Anda. Opsi yang Anda pilih bergantung pada persyaratan peraturan, apakah Anda menjalankan lingkungan hybrid cloud atau masih memiliki lingkungan lokal, serta sensitivitas data yang Anda proses dan penyimpanan.
• Manajemen insiden adalah area penting dan sering diabaikan, dimana tanggung jawab Anda dan tanggung jawab penyedia cloud sulit ditentukan. Banyak insiden memerlukan kolaborasi dan dukungan kuat dari penyedia cloud untuk membantu menyelidiki dan memitigasinya. Insiden lainnya mungkin berasal dari resource cloud yang dikonfigurasi dengan buruk atau kredensial curian, dan memastikan bahwa Anda memenuhi praktik terbaik untuk mengamankan resource dan akun bisa jadi cukup sulit.
• Ancaman persisten tingkat lanjut (APTs) dan kerentanan baru dapat memengaruhi workload Anda dengan cara yang mungkin tidak Anda pertimbangkan saat memulai transformasi cloud. Memastikan bahwa Anda selalu mengikuti info terbaru tentang lanskap yang terus berubah, dan siapa yang bertanggung jawab atas mitigasi ancaman adalah hal yang sulit dilakukan, terutama jika bisnis Anda tidak memiliki tim keamanan yang besar.

Konsekuensi bersama

Kami mengembangkan konsekuensi bersama di Google Cloud untuk mulai menangani tantangan yang tidak diatasi oleh model tanggung jawab bersama. Konsekuensi bersama berfokus pada bagaimana semua pihak dapat berinteraksi dengan lebih baik untuk terus meningkatkan keamanan. Konsekuensi bersama dibangun berdasarkan model tanggung jawab bersama dengan melihat hubungan antara penyedia cloud dan pelanggan sebagai kemitraan berkelanjutan untuk meningkatkan keamanan.

Konsekuensi bersama adalah bagaimana kami bertanggung jawab untuk membuat Google Cloud. lebih aman. Konsekuensi bersama dapat membantu Anda untuk memulai zona landing yang aman serta bersikap jelas, dogmatis, dan transparan terkait kontrol keamanan, setelan, dan praktik terbaik yang direkomendasikan. Fitur ini dapat membantu Anda mengukur dan mengelola risiko dengan lebih baik dengan asuransi cyber, menggunakan Program Proteksi Risiko kami. Dengan menggunakan konsekuensi bersama, kami ingin berkembang dari framework tanggung jawab bersama standar menjadi model yang lebih baik yang membantu Anda mengamankan bisnis dan membangun kepercayaan di Google Cloud.

Bagian berikut menjelaskan berbagai komponen konsekuensi bersama.

Bantuan untuk memulai

Komponen utama dari konsekuensi bersama adalah resource yang kami sediakan untuk membantu Anda memulai, konfigurasi yang aman di Google Cloud. Memulai dengan konfigurasi yang aman dapat membantu mengurangi masalah kesalahan konfigurasi yang merupakan akar penyebab sebagian besar pelanggaran keamanan.

Referensi kami meliputi:

• Blueprint Enterprise Foundation yang membahas masalah keamanan utama dan rekomendasi utama kami.

• Blueprint aman yang memungkinkan Anda men-deploy dan mengelola solusi yang aman menggunakan infrastruktur sebagai kode (IaC). Blueprint mengaktifkan rekomendasi keamanan kami secara default. Banyak blueprint yang dibuat oleh tim keamanan Google dan dikelola sebagai produk. Dengan dukungan ini, konfigurasi harus diperbarui secara rutin, melalui proses pengujian yang ketat, dan menerima pengesahan dari grup pengujian pihak ketiga. Blueprint mencakup blueprint fondasi perusahaan, blueprint data warehouse yang aman, dan blueprint notebook Vertex AI Workbench.

• Praktik terbaik Framework Arsitektur yang membahas rekomendasi teratas untuk membangun keamanan ke dalam desain Anda. Framework Arsitektur mencakup bagian keamanan dan zona komunitas yang dapat Anda gunakan untuk terhubung dengan pakar dan rekan Anda.

• Panduan navigasi zona landing yang memandu Anda dalam mengambil keputusan penting untuk membangun fondasi yang aman bagi workload Anda, termasuk hierarki resource, orientasi identitas, keamanan, dan manajemen kunci, serta struktur jaringan.

Risk Protection Program

Konsekuensi bersama juga mencakup Program Proteksi Risiko (dalam pratinjau saat ini), yang membantu Anda menggunakan kecanggihan Google Cloud sebagai platform untuk mengelola risiko, bukan hanya melihat workload cloud Anda sebagai sumber risiko lain yang perlu Anda kelola. Program Proteksi Risiko adalah kolaborasi antara Google Cloud dan dua perusahaan asuransi cyber terkemuka, Munich Re dan Allianz Global & Corporate Speciality.

Program Proteksi Risiko mencakup Risk Manager, yang memberikan insight berbasis data yang dapat Anda gunakan untuk lebih memahami postur keamanan cloud Anda. Jika mencari perlindungan asuransi cyber, Anda dapat membagikan insight dari Risk Manager secara langsung kepada partner asuransi kami untuk mendapatkan penawaran harga. Untuk informasi selengkapnya, lihat Program Perlindungan Risiko Google Cloud sekarang dalam Pratinjau.

Bantuan terkait deployment dan tata kelola

Konsekuensi bersama juga membantu tata kelola berkelanjutan terhadap lingkungan Anda. Misalnya kami memfokuskan upaya pada produk berikut ini:

• Assured Workloads, yang membantu Anda memenuhi kewajiban kepatuhan.
• Security Command Center Premium, yang menggunakan kecerdasan ancaman, deteksi ancaman, pemindaian web, dan metode canggih lainnya untuk memantau dan mendeteksi ancaman. Selain itu, platform ini juga menyediakan cara untuk menyelesaikan berbagai ancaman tersebut dengan cepat dan secara otomatis.
• Kebijakan organisasi dan setelan resource yang memungkinkan Anda mengonfigurasi kebijakan di seluruh hierarki folder dan project.
• Alat Policy Intelligence yang menyediakan insight tentang akses ke akun dan resource.
• Confidential Computing, yang memungkinkan Anda mengenkripsi data aktif.
• Sovereign Cloud, yang tersedia di Jerman dan menerapkan persyaratan residensi data.

Mempraktikkan tanggung jawab bersama dan konsekuensi bersama

Sebagai bagian dari proses perencanaan, pertimbangkan tindakan berikut untuk membantu Anda memahami dan menerapkan kontrol keamanan yang tepat:

• Buat daftar jenis workload yang akan Anda hosting di Google Cloud, dan apakah workload tersebut memerlukan layanan IaaS, PaaS, dan SaaS. Anda dapat menggunakan diagram tanggung jawab bersama sebagai checklist untuk memastikan bahwa Anda mengetahui kontrol keamanan yang perlu dipertimbangkan.
• Buat daftar persyaratan peraturan yang harus Anda patuhi, dan akses referensi di Pusat referensi kepatuhan terkait persyaratan tersebut.
• Tinjau daftar blueprint dan arsitektur yang tersedia di Pusat Arsitektur untuk kontrol keamanan yang diperlukan bagi workload khusus Anda. Blueprint ini memberikan daftar kontrol yang direkomendasikan dan kode IaC yang Anda perlukan untuk men-deploy arsitektur tersebut.
• Gunakan dokumentasi zona landing dan rekomendasi dalam panduan dasar-dasar perusahaan untuk mendesain hierarki resource dan arsitektur jaringan yang memenuhi persyaratan Anda. Anda dapat menggunakan blueprint workload dogmatis, seperti data warehouse yang diamankan, untuk mempercepat proses pengembangan.
• Setelah men-deploy workload, pastikan Anda memenuhi tanggung jawab keamanan menggunakan layanan seperti Risk Manager, Assured Workloads, alat Policy Intelligence, dan Security Command Center Premium

Untuk informasi selengkapnya, lihat makalah Panduan CISO untuk Cloud Transformation.

Langkah selanjutnya

• Tinjau prinsip keamanan (dokumen berikutnya dalam seri ini)
• Ikuti terus referensi konsekuensi bersama.
• Pelajari blueprint yang tersedia, termasuk blueprint security foundation dan contoh workload seperti data warehouse yang aman.
• Baca selengkapnya tentang konsekuensi bersama.
• Baca infrastruktur keamanan dasar kami di ringkasan desain keamanan infrastruktur Google.
• Baca cara menerapkan praktik terbaik Framework NIST Cybersecurity di Google Cloud (PDF).

Prinsip keamanan

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan prinsip-prinsip inti untuk menjalankan layanan yang aman dan sesuai standar di Google Cloud. Banyak prinsip keamanan yang sudah Anda kenal di lingkungan lokal juga berlaku untuk lingkungan cloud.

Membangun pendekatan keamanan berlapis

Keamanan di setiap level dalam aplikasi dan infrastruktur Anda dengan menerapkan pendekatan defense-in-depth. Gunakan fitur di setiap produk untuk membatasi akses dan mengonfigurasi enkripsi jika diperlukan.

Desain untuk sistem terpisah yang aman

Sederhanakan desain sistem untuk mengakomodasi fleksibilitas jika memungkinkan, dan persyaratan keamanan dokumen untuk setiap komponen. Gabungkan mekanisme aman yang tangguh untuk memperhitungkan ketahanan dan pemulihan.

Mengotomatiskan deployment tugas sensitif

Tidak lagi melibatkan manusia dalam alur kerja dengan mengotomatiskan deployment dan tugas admin lainnya

Mengotomatiskan pemantauan keamanan

Gunakan alat otomatis untuk memantau aplikasi dan infrastruktur Anda. Untuk memindai infrastruktur Anda guna mencari kerentanan dan mendeteksi insiden keamanan, gunakan pemindaian otomatis di pipeline integrasi berkelanjutan dan deployment berkelanjutan (CI/CD) Anda.

Penuhi persyaratan kepatuhan untuk region Anda

Perhatikan bahwa Anda mungkin perlu meng-obfuscate atau menyamarkan informasi identitas pribadi (PII) untuk memenuhi persyaratan peraturan Anda. Jika memungkinkan, otomatiskan upaya kepatuhan Anda. Misalnya, gunakan Sensitive Data Protection dan Dataflow untuk mengotomatiskan tugas penyamaran PII sebelum data baru disimpan di sistem.

Patuhi persyaratan residensi dan kedaulatan data

Anda mungkin memiliki persyaratan internal (atau eksternal) yang mengharuskan Anda mengontrol lokasi penyimpanan dan pemrosesan data. Persyaratan ini bervariasi berdasarkan tujuan desain sistem, masalah peraturan industri, hukum nasional, implikasi pajak, dan budaya. Residensi data menjelaskan tempat data Anda disimpan. Untuk membantu mematuhi persyaratan residensi data, Google Cloud memungkinkan Anda mengontrol tempat data disimpan, cara data diakses, dan cara pemrosesannya.

Terapkan keamanan dari awal proses

DevOps dan otomatisasi deployment memungkinkan organisasi Anda meningkatkan kecepatan pengiriman produk. Untuk membantu memastikan produk Anda tetap aman, terapkan proses keamanan sejak awal proses pengembangan. Misalnya, Anda dapat melakukan hal berikut:

• Uji masalah keamanan dalam kode lebih awal dalam pipeline deployment.
• Pindai image container dan infrastruktur cloud secara berkelanjutan.
• Deteksi otomatis kesalahan konfigurasi dan anti-pola keamanan. Misalnya, gunakan otomatisasi untuk mencari rahasia yang di-hard code di aplikasi atau dalam konfigurasi.

Langkah selanjutnya

Pelajari lebih lanjut prinsip keamanan inti dengan referensi berikut:

• Mengelola risiko dengan kontrol (dokumen berikutnya dalam seri ini)
• Blueprint Google Cloud Enterprise Foundation
• Laporan keamanan Google
• Ringkasan Desain Keamanan Infrastruktur Google
• Membangun proses manajemen insiden kolaboratif
• Blueprint yang dapat di-deploy untuk berbagai industri

Kelola risiko dengan kontrol

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan praktik terbaik untuk mengelola risiko dalam deployment cloud. Melakukan analisis cermat terhadap risiko yang terjadi pada organisasi memungkinkan Anda menentukan kontrol keamanan yang diperlukan. Anda harus menyelesaikan analisis risiko sebelum men-deploy workload di Google Cloud, dan secara berkala setelahnya saat kebutuhan bisnis, persyaratan peraturan, dan ancaman yang relevan bagi organisasi Anda berubah.

Identifikasi risiko terhadap organisasi Anda

Sebelum Anda membuat dan men-deploy resource di Google Cloud, selesaikan penilaian risiko untuk menentukan fitur keamanan yang Anda butuhkan untuk memenuhi persyaratan keamanan internal dan persyaratan peraturan eksternal. Penilaian risiko memberi Anda katalog risiko yang relevan bagi Anda, dan menunjukkan seberapa mampu organisasi Anda dalam mendeteksi dan menangkal ancaman keamanan.

Risiko Anda di lingkungan cloud berbeda dengan risiko di lingkungan lokal hal ini disebabkan adanya pengaturan tanggung jawab bersama yang Anda lakukan dengan penyedia cloud. Misalnya, di lingkungan lokal Anda perlu mengurangi kerentanan terhadap tumpukan hardware. Sebaliknya, di lingkungan cloud risiko ini ditanggung oleh penyedia cloud.

Sebagai tambahan, risiko Anda akan berbeda-beda, tergantung rencana Anda untuk menggunakan Google Cloud. Apakah Anda mentransfer beberapa workload Anda ke Google Cloud, atau seluruhnya? Apakah Anda menggunakan Google Cloud hanya untuk tujuan pemulihan dari bencana? Apakah Anda menyiapkan lingkungan hybrid cloud?

Sebaiknya gunakan framework penilaian risiko standar industri yang berlaku untuk lingkungan cloud dan persyaratan peraturan Anda. Misalnya, Cloud Security Alliance (CSA) menyediakan Cloud Controls Matrix (CCM). Selain itu, ada model ancaman seperti pemodelan ancaman aplikasi OWASP yang memberi Anda daftar potensi celah, dan menyarankan tindakan untuk memperbaiki setiap celah yang ditemukan singkat ini. Anda dapat memeriksa direktori partner kami untuk daftar pakar dalam melakukan penilaian risiko untuk Google Cloud.

Untuk membuat katalog risiko, pertimbangkan Risk Manager, yang merupakan bagian dari Program Perlindungan Risiko. (Program ini sedang dalam pratinjau.) Risk Manager memindai workload Anda untuk membantu memahami risiko bisnis. Laporan detail ini memberi Anda dasar pengukuran keamanan. Selain itu, Anda dapat menggunakan laporan Risk Manager untuk membandingkan risiko dengan risiko yang diuraikan dalam Benchmark Center untuk Internet Security (CIS).

Setelah membuat katalog risiko, Anda harus menentukan cara mengatasinya—yaitu, apakah Anda ingin menerima, menghindari, mentransfer, atau menguranginya. Bagian berikut menjelaskan kontrol mitigasi.

Mitigasi risiko Anda

Anda dapat memitigasi risiko menggunakan kontrol teknis, perlindungan kontrak, dan verifikasi atau pengesahan pihak ketiga. Tabel berikut mencantumkan bagaimana cara Anda menggunakan mitigasi ini ketika Anda mengadopsi layanan cloud publik baru.

Mitigasi	Deskripsi
Kontrol teknis	Kontrol teknis mengacu pada fitur dan teknologi yang Anda gunakan untuk melindungi lingkungan Anda. Hal ini mencakup kontrol keamanan cloud bawaan, seperti firewall dan logging. Kontrol teknis juga dapat disertakan untuk penggunaan alat pihak ketiga untuk memperkuat atau mendukung strategi keamanan Anda. Terdapat dua kategori kontrol teknis: Google Cloud mencakup berbagai kontrol keamanan agar Anda dapat mengurangi risiko yang berlaku untuk Anda. Misalnya, jika memiliki lingkungan lokal, Anda dapat menggunakan Cloud VPN dan Cloud Interconnect untuk mengamankan koneksi antara infrastruktur lokal dan sumber daya cloud Anda. Google memiliki kontrol dan audit internal yang kuat untuk melindungi dari akses orang dalam ke data pelanggan. Log audit kami memberi pelanggan log akses administrator Google yang mendekati real-time di Google Cloud.
Perlindungan kontraktual	Perlindungan kontrak mengacu pada komitmen hukum yang kami buat terkait layanan Google Cloud. Google berkomitmen untuk mengelola dan memperluas portofolio kepatuhan kami. Dokumen Adendum Pemrosesan Data Cloud (CDPA) menentukan komitmen kami untuk mempertahankan sertifikasi ISO 27001, 27017, dan 27018 kami serta memperbarui laporan SOC 2 dan SOC 3 kami setiap 12 bulan. Dokumen DPST juga menguraikan kontrol akses yang tersedia untuk membatasi akses oleh engineer dukungan Google ke lingkungan pelanggan, dan dokumen ini juga menjelaskan logging kami yang ketat dan proses persetujuan. Sebaiknya tinjau kontrol kontraktual Google Cloud dengan pakar hukum dan peraturan, lalu verifikasi bahwa mereka memenuhi persyaratan Anda. Jika Anda memerlukan informasi lebih lanjut, hubungi perwakilan akun teknis Anda.
Verifikasi atau pengesahan pihak ketiga	Verifikasi atau pengesahan pihak ketiga mengacu pada permintaan vendor pihak ketiga mengaudit penyedia cloud untuk memastikan bahwa penyedia tersebut memenuhi persyaratan kepatuhan. Misalnya, Google diaudit oleh pihak ketiga untuk memastikan kepatuhan pada ISO 27017. Anda dapat melihat surat dan sertifikasi pengesahan Google Cloud terbaru di Pusat Referensi Kepatuhan.

Langkah selanjutnya

Pelajari manajemen risiko lebih lanjut dengan referensi berikut:

• Mengelola aset Anda (dokumen berikutnya dalam seri ini)

• Program Perlindungan Risiko

• Pusat referensi kepatuhan

• Tata kelola risiko transformasi digital di cloud (PDF)

Kelola aset Anda

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk mengelola aset.

Manajemen aset merupakan bagian penting dari analisis kebutuhan bisnis Anda. Anda harus tahu aset apa yang dimiliki, dan Anda harus memiliki pemahaman yang baik tentang semua aset, nilainya, serta jalur atau proses penting yang berkaitan dengannya. Anda harus memiliki inventaris aset yang akurat sebelum dapat mendesain segala jenis kontrol keamanan untuk melindungi aset Anda.

Untuk mengelola insiden keamanan dan memenuhi persyaratan peraturan organisasi, Anda memerlukan inventaris aset terbaru dan akurat yang menyertakan cara untuk menganalisis data historis. Anda harus dapat melacak aset Anda, termasuk perubahan eksposur risikonya seiring waktu.

Dengan beralih ke Google Cloud, Anda perlu mengubah proses pengelolaan aset agar dapat beradaptasi dengan lingkungan cloud. Misalnya, salah satu manfaat beralih ke cloud adalah meningkatkan kemampuan organisasi untuk melakukan penskalaan dengan cepat. Namun, kemampuan untuk menskalakan dengan cepat dapat menyebabkan masalah IT bayangan, ketika karyawan Anda membuat resource cloud yang tidak dikelola dan diamankan dengan benar. Oleh karena itu, proses pengelolaan aset Anda harus memberikan fleksibilitas yang cukup bagi karyawan untuk menyelesaikan pekerjaan, sekaligus menyediakan kontrol keamanan yang sesuai.

Gunakan alat pengelolaan aset cloud

Alat pengelolaan aset Google Cloud disesuaikan secara khusus dengan lingkungan kami dan kasus penggunaan pelanggan teratas.

Salah satu alat ini adalah Inventaris Aset Cloud, yang memberikan informasi real time tentang status resource Anda saat ini dan dengan histori lima minggu. Dengan menggunakan layanan ini, Anda bisa mendapatkan snapshot di seluruh organisasi dari inventaris Anda untuk berbagai resource dan kebijakan Google Cloud. Alat otomatisasi kemudian dapat menggunakan snapshot untuk pemantauan atau untuk penegakan kebijakan, atau alat tersebut dapat mengarsipkan snapshot untuk audit kepatuhan. Jika ingin menganalisis perubahan pada aset, inventaris aset juga memungkinkan Anda mengekspor histori metadata.

Untuk mengetahui informasi selengkapnya tentang Inventaris Aset Cloud, baca artikel Solusi kustom untuk merespons perubahan aset dan Kontrol detektif.

Mengotomatiskan pengelolaan aset

Otomatisasi memungkinkan Anda membuat dan mengelola aset dengan cepat berdasarkan persyaratan keamanan yang Anda tentukan Anda dapat mengotomatiskan aspek siklus proses aset dengan cara berikut:

• Deploy infrastruktur cloud Anda menggunakan alat otomatisasi seperti Terraform Google Cloud menyediakan blueprint fondasi perusahaan, yang membantu Anda menyiapkan resource infrastruktur yang memenuhi praktik terbaik keamanan. Selain itu, konsol ini mengonfigurasi perubahan aset dan notifikasi kepatuhan kebijakan di Inventaris Aset Cloud.
• Deploy aplikasi Anda menggunakan alat otomatisasi seperti Cloud Run dan Artifact Registry.

Pantau penyimpangan dari kebijakan kepatuhan Anda

Penyimpangan dari kebijakan dapat terjadi selama semua fase siklus proses aset. Misalnya, aset mungkin dibuat tanpa kontrol keamanan yang tepat, atau hak istimewanya dapat dieskalasi. Demikian pula, aset dapat ditinggalkan tanpa diikuti prosedur akhir siklus proses yang sesuai.

Untuk membantu menghindari skenario ini, sebaiknya Anda memantau penyimpangan aset dari kepatuhan. Kumpulan aset yang Anda pantau bergantung pada hasil penilaian risiko dan persyaratan bisnis Anda. Untuk informasi selengkapnya tentang pemantauan aset, lihat Memantau perubahan aset.

Integrasikan dengan sistem pemantauan pengelolaan aset Anda yang ada

Jika Anda sudah menggunakan sistem SIEM atau sistem pemantauan lainnya, integrasikan aset Google Cloud Anda dengan sistem tersebut. Integrasi memastikan bahwa organisasi Anda memiliki satu pandangan yang komprehensif ke semua resource, terlepas dari lingkungannya. Untuk informasi selengkapnya, lihat Mengekspor data keamanan Google Cloud ke sistem SIEM Anda dan Skenario untuk mengekspor data Cloud Logging: Splunk.

Gunakan analisis data untuk memperkaya pemantauan Anda

Anda dapat mengekspor inventaris ke Tabel BigQuery atau bucket Cloud Storage untuk analisis tambahan.

Langkah selanjutnya

Pelajari lebih lanjut cara mengelola aset dengan resource berikut:

• Mengelola identitas dan akses (dokumen berikutnya dalam seri ini)
• Pengelolaan resource
• Desain Sistem

Mengelola identitas dan akses

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk mengelola identitas dan akses.

Praktik identity and access management (umumnya disebut sebagai IAM) membantu Anda memastikan bahwa orang yang tepat dapat mengakses resource yang tepat. IAM menangani aspek autentikasi dan otorisasi berikut:

• Pengelolaan akun, termasuk penyediaan
• Tata kelola identitas
• Autentikasi
• Kontrol akses (otorisasi)
• Penggabungan identitas

Mengelola IAM dapat menjadi tantangan saat Anda memiliki lingkungan yang berbeda atau menggunakan beberapa penyedia identitas. Namun, Anda harus menyiapkan sistem yang dapat memenuhi persyaratan bisnis Anda sekaligus melakukan mitigasi risiko.

Rekomendasi dalam dokumen ini membantu Anda meninjau kebijakan dan prosedur IAM saat ini, serta menentukan kebijakan dan prosedur mana yang mungkin perlu diubah untuk workload Anda di Google Cloud. Misalnya, Anda harus meninjau hal berikut:

• Apakah Anda dapat menggunakan grup yang sudah ada untuk mengelola akses atau apakah Anda perlu membuat grup baru.
• Persyaratan autentikasi Anda (seperti autentikasi multi-faktor (MFA) menggunakan token).
• Dampak akun layanan terhadap kebijakan Anda saat ini.
• Jika Anda menggunakan Google Cloud untuk pemulihan dari bencana (disaster recovery), pertahankan pemisahan tugas yang sesuai.

Dalam Google Cloud, Anda menggunakan Cloud Identity untuk mengautentikasi pengguna dan resource dan produk Identity and Access Management (IAM) Google mendikte akses sumber daya. Administrator dapat membatasi akses di tingkat organisasi, folder, project, dan resource. Kebijakan IAM Google menentukan siapa yang dapat melakukan apa pada resource mana. Kebijakan IAM yang dikonfigurasi dengan benar membantu mengamankan lingkungan Anda dengan mencegah akses tidak sah ke resource.

Untuk informasi selengkapnya, lihat Ringkasan identity and access management.

Gunakan satu penyedia identitas

Banyak pelanggan kami memiliki akun pengguna yang dikelola dan disediakan oleh penyedia identitas di luar Google Cloud. Google Cloud mendukung penggabungan dengan sebagian besar penyedia identitas dan dengan direktori lokal seperti Active Directory.

Sebagian besar penyedia identitas memungkinkan Anda mengaktifkan Single Sign-On (SSO) untuk pengguna dan grup. Untuk aplikasi yang Anda deploy di Google Cloud dan yang menggunakan penyedia identitas eksternal Anda, Anda dapat memperluas penyedia identitas Anda ke Google Cloud. Untuk informasi selengkapnya, lihat Arsitektur referensi dan Pola untuk autentikasi pengguna perusahaan di lingkungan hybrid.

Jika belum memiliki penyedia identitas, Anda dapat menggunakan Cloud Identity Premium atau Google Workspace untuk mengelola identitas untuk karyawan Anda.

Melindungi akun admin super

Akun admin super (yang dikelola oleh Google Workspace atau Cloud Identity) memungkinkan Anda membuat organisasi Google Cloud. Oleh karena itu, akun admin ini memiliki hak istimewa yang tinggi. Praktik terbaik untuk akun ini mencakup hal berikut:

• Membuat akun baru untuk tujuan ini; tidak menggunakan akun pengguna yang sudah ada.
• Membuat dan melindungi akun pencadangan.
• Mengaktifkan MFA.

Untuk informasi selengkapnya, lihat Praktik terbaik akun administrator super.

Merencanakan penggunaan akun layanan

Akun layanan adalah Akun Google yang dapat digunakan aplikasi untuk memanggil Google API suatu layanan.

Tidak seperti akun pengguna, akun layanan dibuat dan dikelola di dalam Google Cloud. Akun layanan juga melakukan autentikasi secara berbeda dari akun pengguna:

• Agar aplikasi yang berjalan di Google Cloud dapat mengautentikasi menggunakan akun layanan, Anda dapat memasang akun layanan pada resource komputasi tempat aplikasi berjalan.
• Agar aplikasi yang berjalan di GKE dapat melakukan autentikasi menggunakan akun layanan, Anda dapat menggunakan Workload Identity.
• Agar aplikasi yang berjalan di luar Google Cloud dapat mengautentikasi menggunakan akun layanan, Anda dapat menggunakan Workload identity federation.

Saat menggunakan akun layanan, Anda harus mempertimbangkan pemisahan tugas yang sesuai selama proses desain. Perhatikan panggilan API yang harus Anda lakukan, serta tentukan akun layanan dan peran terkait yang diperlukan oleh panggilan API. Misalnya, jika Anda menyiapkan data warehouse BigQuery, Anda mungkin memerlukan identitas untuk setidaknya proses dan layanan berikut:

• Cloud Storage atau Pub/Sub, bergantung pada apakah Anda menyediakan file batch atau membuat layanan streaming.
• Dataflow dan Sensitive Data Protection untuk melakukan de-identifikasi data sensitif.

Untuk informasi selengkapnya, lihat Praktik terbaik untuk menggunakan akun layanan.

Memperbarui proses identitas Anda untuk cloud

Tata kelola identitas memungkinkan Anda melacak akses, risiko, dan pelanggaran kebijakan sehingga Anda dapat mendukung persyaratan peraturan Anda. Tata kelola ini mengharuskan Anda menerapkan proses dan kebijakan agar dapat memberikan dan mengaudit peran serta izin kontrol akses kepada pengguna. Proses dan kebijakan Anda harus mencerminkan persyaratan lingkungan Anda—misalnya, pengujian, pengembangan, dan produksi.

Sebelum men-deploy workload di Google Cloud, tinjau proses identitas Anda saat ini dan perbarui jika sesuai. Pastikan Anda merencanakan dengan tepat untuk jenis akun yang diperlukan organisasi dan memahami dengan baik peran serta persyaratan aksesnya.

Untuk membantu Anda mengaudit aktivitas IAM Google, Google Cloud membuat log audit, yang mencakup hal berikut:

• Aktivitas administrator. Logging ini tidak dapat dinonaktifkan.
• Aktivitas akses data. Anda harus enable logging ini.

Jika diperlukan untuk tujuan kepatuhan, atau jika ingin menyiapkan analisis log (misalnya, dengan sistem SIEM), Anda dapat mengekspor log. Karena log dapat meningkatkan persyaratan penyimpanan Anda, log tersebut dapat memengaruhi biaya Anda. Pastikan Anda hanya mencatat tindakan yang diperlukan ke dalam log, dan tetapkan jadwal retensi yang sesuai.

Siapkan SSO dan MFA

Penyedia identitas Anda mengelola autentikasi akun pengguna. Identitas gabungan dapat melakukan autentikasi ke Google Cloud menggunakan SSO. Untuk akun dengan hak istimewa, seperti admin super, Anda harus mengonfigurasi MFA. Kunci Keamanan Titan adalah token fisik yang dapat digunakan untuk autentikasi 2 langkah (2FA) guna membantu mencegah serangan phishing.

Cloud Identity mendukung MFA menggunakan berbagai metode. Untuk informasi selengkapnya, lihat Menerapkan MFA seragam untuk resource yang dimiliki perusahaan.

Google Cloud mendukung autentikasi untuk workload identity menggunakan protokol OAuth 2.0 atau Token Web JSON (JWT) yang ditandatangani. Untuk informasi selengkapnya tentang autentikasi workload, lihat Ringkasan autentikasi.

Terapkan hak istimewa terendah dan pemisahan tugas

Anda harus memastikan bahwa orang yang tepat hanya mendapatkan akses ke resource dan layanan yang mereka butuhkan untuk melakukan pekerjaannya. Artinya, Anda harus mengikuti prinsip hak istimewa terendah. Selain itu, Anda harus memastikan ada pemisahan tugas yang sesuai.

Penyediaan akses pengguna yang berlebihan dapat meningkatkan risiko ancaman orang dalam, resource yang salah dikonfigurasi, dan ketidakpatuhan terhadap audit. Penyediaan izin yang kurang dapat mencegah pengguna mengakses resource yang mereka perlukan untuk menyelesaikan tugas.

Salah satu cara untuk menghindari penyediaan yang berlebihan adalah dengan menerapkan akses dengan hak istimewa tepat waktu — yaitu, untuk menyediakan akses dengan hak istimewa hanya jika diperlukan, dan hanya memberikannya secara sementara.

Perhatikan bahwa saat organisasi Google Cloud dibuat, semua pengguna di domain Anda akan diberi peran Billing Account Creator dan Project Creator secara default. Identifikasi pengguna yang akan melakukan tugas ini, dan cabut peran ini dari pengguna lain. Untuk informasi selengkapnya, lihat Membuat dan mengelola organisasi.

Untuk informasi selengkapnya tentang cara kerja peran dan izin di Google Cloud, lihat Ringkasan dan Memahami peran dalam dokumentasi IAM. Untuk informasi selengkapnya tentang cara menerapkan hak istimewa terendah, lihat Menerapkan hak istimewa terendah dengan rekomendasi peran.

Mengaudit akses

Untuk memantau aktivitas akun dengan hak istimewa untuk penyimpangan dari kondisi yang disetujui, gunakan Cloud Audit Logs. Cloud Audit Logs mencatat tindakan yang telah dilakukan oleh anggota di organisasi Google Cloud Anda pada resource Google Cloud Anda. Anda dapat menggunakan berbagai jenis log audit di seluruh layanan Google. Untuk informasi lebih lanjut, lihat Menggunakan Cloud Audit Logs untuk Membantu Mengelola Risiko Orang Dalam (video).

Gunakan pemberi rekomendasi IAM untuk melacak penggunaan dan menyesuaikan izin jika perlu. Peran yang direkomendasikan oleh pemberi rekomendasi IAM dapat membantu Anda menentukan peran mana yang akan diberikan kepada pengguna berdasarkan perilaku sebelumnya dan kriteria lainnya. Untuk informasi selengkapnya, lihat Praktik terbaik untuk rekomendasi peran.

Untuk mengaudit dan mengontrol akses ke resource Anda oleh staf dukungan dan engineering Google, Anda dapat menggunakan Transparansi Akses. Transparansi Akses mencatat tindakan yang diambil oleh staf Google. Gunakan Persetujuan Akses, yang merupakan bagian dari Transparansi Akses, untuk memberikan persetujuan eksplisit setiap kali konten pelanggan diakses. Untuk informasi selengkapnya, lihat Mengontrol akses administrator cloud ke data Anda.

Mengotomatiskan kontrol kebijakan

Tetapkan izin akses secara terprogram jika memungkinkan. Untuk praktik terbaik, lihat Batasan kebijakan organisasi. Skrip Terraform untuk blueprint Enterprise Foundation ada di contoh repositori fondasi.

Google Cloud dilengkapi dengan Policy Intelligence, yang memungkinkan Anda meninjau dan memperbarui izin akses secara otomatis. Policy Intelligence mencakup alat Pemberi Rekomendasi, Pemecah Masalah Kebijakan, dan Penganalisis Kebijakan, yang melakukan hal berikut:

• Memberikan rekomendasi untuk penetapan peran IAM.
• Memantau dan membantu mencegah kebijakan IAM yang terlalu permisif.
• Membantu memecahkan masalah terkait kontrol akses.

Menetapkan batasan pada resource

Google IAM berfokus pada siapa, dan memungkinkan Anda memberikan otorisasi kepada siapa yang dapat bertindak atas resource tertentu berdasarkan izin. Layanan Kebijakan Organisasi berfokus pada apa, dan memungkinkan Anda menetapkan batasan pada resource untuk menentukan cara mengonfigurasinya. Misalnya, Anda dapat menggunakan kebijakan organisasi untuk melakukan hal berikut:

• Membatasi berbagi resource berdasarkan domain.
• Membatasi penggunaan akun layanan.
• Membatasi lokasi fisik resource yang baru dibuat.

Selain menggunakan kebijakan organisasi untuk tugas ini, Anda dapat membatasi akses ke resource menggunakan salah satu metode berikut:

• Gunakan tag untuk mengelola akses ke resource Anda tanpa menentukan izin akses di setiap resource. Sebagai gantinya, Anda menambahkan tag, lalu menetapkan definisi akses untuk tag itu sendiri.
• Gunakan IAM Conditions untuk kontrol kondisional berbasis atribut atas akses ke resource.
• Terapkan defense in depth menggunakan Kontrol Layanan VPC untuk lebih membatasi akses ke resource.

Untuk informasi selengkapnya tentang pengelolaan resource, lihat Pengelolaan resource.

Langkah selanjutnya

Pelajari IAM lebih lanjut dengan referensi berikut:

• Mengimplementasikan keamanan komputasi dan container (dokumen berikutnya dalam seri ini)

• Menggunakan IAM dengan aman

• Arsitektur referensi

• Pemberi Rekomendasi IAM: hak istimewa terendah dengan lebih sedikit upaya

• Privasi Data Cloud

• Ringkasan pengelolaan akses dan identitas

Mengimplementasikan keamanan komputasi dan container

Google Cloud mencakup kontrol untuk melindungi resource komputasi dan resource container Google Kubernetes Engine (GKE). Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan kontrol utama dan praktik terbaik untuk menggunakannya.

Gunakan image VM yang telah melalui proses hardening dan diseleksi

Google Cloud dilengkapi dengan Shielded VM, yang dapat Anda gunakan untuk melakukan hardening instance VM. Shielded VM dirancang untuk mencegah kode berbahaya dimuat selama siklus booting. Layanan ini memberikan keamanan booting, memantau integritas, dan menggunakan Virtual Trusted Platform Module (vTPM). Gunakan Shielded VM untuk workload yang sensitif.

Selain menggunakan Shielded VM, Anda dapat menggunakan solusi partner Google Cloud untuk melindungi VM Anda lebih lanjut. Banyak solusi partner yang ditawarkan di Google Cloud terintegrasi dengan Security Command Center, yang menyediakan deteksi ancaman peristiwa dan pemantauan kondisi. Anda dapat menggunakan partner untuk analisis ancaman lanjutan atau keamanan runtime tambahan.

Gunakan Confidential Computing untuk memproses data sensitif

Secara default, Google Cloud mengenkripsi data dalam penyimpanan dan dalam pengiriman di seluruh jaringan, tetapi data tidak dienkripsi saat digunakan dalam memori. Jika organisasi Anda menangani data rahasia, Anda harus mengurangi ancaman yang merusak kerahasiaan dan integritas aplikasi atau data dalam memori sistem. Data rahasia mencakup informasi identitas pribadi (PII), data keuangan, dan informasi kesehatan.

Confidential Computing dikembangkan di Shielded VM. Enkripsi ini melindungi data yang sedang digunakan dengan melakukan komputasi di lingkungan eksekusi tepercaya berbasis hardware. Jenis lingkungan yang aman dan terisolasi ini membantu mencegah akses tidak sah atau modifikasi aplikasi dan data saat data tersebut sedang digunakan. Lingkungan eksekusi yang tepercaya juga meningkatkan jaminan keamanan bagi organisasi yang mengelola data yang sensitif dan diregulasi.

Di Google Cloud, Anda dapat mengaktifkan Confidential Computing dengan menjalankan Confidential VMs atau node Confidential GKE. Aktifkan Confidential Computing saat Anda memproses workload rahasia, atau saat Anda memiliki data rahasia (misalnya, secret) yang harus terekspos saat diproses. Untuk informasi selengkapnya, lihat Confidential Computing Consortium.

Melindungi VM dan container

Login OS memungkinkan karyawan Anda terhubung ke VM menggunakan izin Identity and Access Management (IAM) sebagai sumber kebenaran, bukan mengandalkan Kunci SSH. Oleh karena itu Anda tidak perlu mengelola kunci SSH di seluruh organisasi Anda. Login OS mengikat akses administrator ke siklus proses karyawan mereka, yang berarti jika karyawan beralih ke peran lain atau keluar dari organisasi Anda, akses mereka akan dicabut dengan akun mereka. Login OS juga mendukung autentikasi 2 langkah, yang menambahkan lapisan keamanan ekstra dari serangan pengambilalihan akun.

Di GKE, App Engine menjalankan instance aplikasi dalam container Docker. Untuk mengaktifkan profil risiko yang ditentukan dan membatasi karyawan agar tidak melakukan perubahan pada container, pastikan container Anda bersifat stateless dan tidak dapat diubah. Prinsip ketetapan berarti bahwa karyawan Anda tidak memodifikasi container atau mengaksesnya secara interaktif. Jika harus diubah, Anda akan mem-build image baru dan men-deploy ulang. Aktifkan akses SSH ke penampung pokok hanya dalam skenario proses debug tertentu.

Menonaktifkan alamat IP eksternal kecuali jika diperlukan

Guna menonaktifkan alokasi alamat IP eksternal (video) untuk VM produksi dan untuk mencegah penggunaan load balancer eksternal, Anda dapat menggunakan kebijakan organisasi. Jika mengharuskan VM terhubung ke internet atau pusat data lokal, Anda dapat mengaktifkan gateway Cloud NAT.

Anda dapat men-deploy cluster pribadi di GKE. Di cluster pribadi, node hanya memiliki alamat IP internal, yang berarti node dan Pod diisolasi dari internet secara default. Anda juga dapat menentukan kebijakan jaringan untuk mengelola komunikasi Pod-ke-Pod di cluster. Untuk informasi selengkapnya, lihat Opsi akses pribadi untuk layanan.

Memantau instance komputasi dan penggunaan GKE

Cloud Audit Logs diaktifkan secara otomatis untuk Compute Engine dan GKE. Log audit memungkinkan Anda secara otomatis mencatat semua aktivitas dengan cluster dan memantau setiap aktivitas yang mencurigakan.

Anda dapat mengintegrasikan GKE dengan produk partner untuk keamanan runtime. Anda dapat mengintegrasikan solusi ini dengan Security Command Center untuk memberi Anda satu antarmuka guna memantau aplikasi Anda.

Selalu perbarui gambar dan cluster Anda

Google Cloud menyediakan gambar OS pilihan yang di-patch secara berkala. Anda dapat menggunakan image kustom dan menjalankannya di Compute Engine, tetapi jika melakukannya, Anda harus mem-patch sendiri. Google Cloud mengupdate image OS secara rutin untuk mengurangi kerentanan baru seperti yang dijelaskan dalam buletin keamanan dan menyediakan perbaikan untuk memperbaiki kerentanan deployment yang ada.

Jika Anda menggunakan GKE, sebaiknya aktifkan upgrade otomatis node agar Google mengupdate node cluster Anda dengan patch terbaru. Google mengelola bidang kontrol GKE, yang otomatis diperbarui dan di-patch. Selain itu, gunakan image yang dioptimalkan untuk container yang diseleksi Google untuk deployment Anda. Google secara rutin men-patch dan memperbarui gambar ini.

Mengontrol akses ke image dan cluster Anda

Penting untuk mengetahui siapa yang dapat membuat dan meluncurkan instance. Anda dapat mengontrol akses ini menggunakan IAM. Untuk informasi tentang cara menentukan akses yang diperlukan workload, lihat Merencanakan identitas workload.

Selain itu, Anda dapat menggunakan Kontrol Layanan VPC untuk menentukan kuota khusus pada project sehingga Anda dapat membatasi siapa yang dapat meluncurkan image. Untuk informasi selengkapnya, lihat bagian Mengamankan jaringan.

Agar dapat menyediakan keamanan infrastruktur untuk cluster Anda, GKE memungkinkan Anda menggunakan IAM dengan kontrol akses berbasis peran (RBAC) untuk mengelola akses ke cluster dan namespace Anda.

Mengisolasi container di sandbox

Gunakan GKE Sandbox untuk men-deploy aplikasi multi-tenant yang membutuhkan lapisan keamanan ekstra dan isolasi dari kernel host mereka. Misalnya, gunakan GKE Sandbox saat Anda menjalankan kode yang tidak dikenal atau tidak tepercaya. GKE Sandbox adalah solusi isolasi container yang menyediakan lapisan pertahanan kedua di antara berbagai workload dalam container di GKE.

GKE Sandbox dibuat untuk aplikasi yang memiliki persyaratan I/O rendah, tetapi dengan skala tinggi. Workload dalam container ini perlu mempertahankan kecepatan dan performanya, tetapi juga dapat menggunakan kode tidak tepercaya yang menuntut keamanan tambahan. Gunakan gVisor, sandbox runtime container, untuk memberikan isolasi keamanan tambahan antara aplikasi dan kernel host. gVisor memberikan pemeriksaan integritas tambahan dan membatasi cakupan akses untuk suatu layanan. Ini bukan layanan container hardening untuk melindungi dari ancaman eksternal. Untuk informasi selengkapnya tentang gVisor, lihat gVisor: Protected GKE and serverless users in the real world.

Langkah selanjutnya

Pelajari keamanan komputasi dan container lebih lanjut dengan referensi berikut:

• Amankan jaringan Anda (dokumen berikutnya dalam seri ini)
• Pentingnya keamanan container (PDF)
• Checklist peluncuran untuk Google Cloud
• Memverifikasi identitas instance
• Workload Identity
• Shieled VM
• Praktik terbaik untuk snapshot persistent disk
• Praktik terbaik pengelolaan gambar

Mengamankan jaringan Anda

Dokumen pada Framework Arsitektur Google Cloud memberikan praktik terbaik untuk mengamankan jaringan Anda.

Memperluas jaringan Anda yang sudah ada agar mencakup lingkungan cloud yang memiliki banyak implikasi untuk keamanan. Pendekatan lokal Anda terhadap pertahanan berlapis kemungkinan dapat melibatkan perimeter yang berbeda antara internet dan jaringan internal milik Anda. Anda mungkin melindungi perimeter dengan menggunakan firewall fisik, router, Intrusion Detection System, dan sebagainya. Anda dapat dengan mudah memantau intrusi dan respons yang sesuai, dikarenakan batas telah ditetapkan dengan jelas.

Anda akan dinyatakan melampaui perimeter lokal saat Anda berpindah ke cloud (baik sepenuhnya atau pun dengan pendekatan hybrid). Dokumen ini menjelaskan beberapa cara agar Anda dapat terus mengamankan data serta workload milik organisasi Anda di Google Cloud. Seperti yang telah disebutkan dalam Mengelola risiko dengan kontrol, cara menyiapkan dan mengamankan jaringan Google Cloud bergantung pada persyaratan bisnis dan selera risiko Anda.

Bagian ini mengasumsikan bahwa Anda telah membaca bagian Jaringan di kategori Desain sistem dan Anda telah membuat diagram arsitektur dasar dari komponen jaringan Google Cloud milik Anda. Lihat bagian Hub-and-spoke untuk melihat contoh diagram.

Men-deploy jaringan zero-trust

Pindah ke cloud berarti model kepercayaan jaringan Anda harus berubah. Anda tidak dapat menggunakan perlindungan perimeter dengan cara yang sama untuk membuat jaringan dalam yang tepercaya, karena pengguna dan workload Anda tidak lagi berada dalam perimeter lokal. Model keamanan zero-trust berarti bahwa tidak ada orang yang dapat dipercaya secara default, baik mereka berada di dalam maupun di luar jaringan organisasi Anda. Saat memverifikasi permintaan akses, model keamanan zero-trust mengharuskan Anda untuk memeriksa identitas dan konteks pengguna. Tidak seperti VPN, Anda memindahkan kontrol akses dari perimeter jaringan ke pengguna dan perangkat.

Di Google Cloud, Anda dapat menggunakan BeyondCorp Enterprise sebagai solusi zero-trust Anda. BeyondCorp Enterprise memberikan perlindungan data dan perlindungan terhadap ancaman serta tambahan kontrol akses. Untuk informasi selengkapnya mengenai cara menyiapkan BeyondCorp Enterprise, lihat Mulai menggunakan BeyondCorp Enterprise.

Selain BeyondCorp Enterprise, Identity-Aware Proxy (IAP) juga tersedia di Google Cloud. Dengan menggunakan IAP, Anda dapat memperluas keamanan zero-trust ke aplikasi Anda, baik di dalam Google Cloud maupun di infrastruktur lokal milik Anda. IAP menggunakan kebijakan kontrol akses untuk memberikan autentikasi dan otorisasi bagi pengguna yang mengakses aplikasi dan resource Anda.

Koneksi aman ke lingkungan lokal atau multi-cloud Anda

Banyak organisasi yang memiliki beberapa workload, baik di lingkungan cloud maupun di infrastruktur lokal. Selain itu, beberapa organisasi menggunakan solusi multi-cloud untuk menjaga ketahanan organisasi mereka. Dalam skenario ini, sangatlah penting untuk mengamankan konektivitas di seluruh lingkungan Anda.

Google Cloud menyertakan metode akses pribadi untuk VM yang didukung oleh Cloud VPN atau Cloud Interconnect, termasuk yang berikut:

• Menggunakan Cross-Cloud Interconnect, sebagai layanan yang terkelola untuk menautkan jaringan VPC Anda ke penyedia cloud yang didukung melalui koneksi langsung berkecepatan tinggi. Dengan menggunakan Cross-Cloud Interconnect, Anda tidak perlu menyediakan router sendiri atau bekerja sama dengan vendor pihak ketiga.
• Menggunakan Dedicated Interconnect dan Partner Interconnect untuk menautkan jaringan VPC ke jaringan pusat lokal Anda atau ke penyedia cloud lainnya melalui jaringan langsung berkecepatan tinggi.
• Menggunakan VPN IPsec untuk menautkan jaringan Virtual Private Cloud (VPC) ke pusat data lokal Anda atau ke penyedia cloud lainnya.
• Menggunakan endpoint Private Service Connect untuk mengakses layanan yang telah dipublikasikan yang disediakan oleh organisasi Anda atau penyedia lainnya.
• Menggunakan endpoint Private Service Connect agar VM Anda dapat mengakses Google API menggunakan alamat IP internal. Dengan menggunakan Private Service Connect, VM Anda tidak perlu memiliki alamat IP eksternal untuk mengakses layanan Google.
• Jika Anda menggunakan GKE Enterprise, pertimbangkan gateway keluar Anthos Service Mesh. Jika Anda tidak menggunakan GKE Enterprise, gunakan opsi pihak ketiga.

Untuk mengetahui perbandingan antara produk satu dengan produk lainnya, lihat Memilih produk Network Connectivity.

Menonaktifkan jaringan default

Saat Anda membuat project Google Cloud yang baru, jaringan default VPC Google Cloud dengan alamat IP mode otomatis dan aturan firewall yang telah terisi otomatis sebelumnya akan secara otomatis disediakan. Untuk deployment produksi, sebaiknya Anda menghapus jaringan default pada project yang sudah ada, dan menonaktifkan pembuatan jaringan default pada project baru.

Jaringan Virtual Private Cloud memungkinkan Anda untuk menggunakan alamat IP internal. Untuk menghindari pembentrokan alamat IP, sebaiknya rencanakan alokasi jaringan dan alamat IP Anda terlebih dahulu di seluruh project dan deployment yang telah terhubung. Sebuah project mengizinkan beberapa jaringan VPC, tetapi biasanya praktik terbaik yang dapat dilakukan adalah membatasi satu jaringan per project untuk menerapkan kontrol akses secara efektif.

Mengamankan perimeter Anda

Di Google Cloud, Anda dapat menggunakan berbagai metode untuk melakukan segmentasi dan mengamankan perimeter cloud Anda, termasuk firewall dan Kontrol Layanan VPC.

Menggunakan VPC Bersama untuk membuat deployment produksi yang memberi Anda sebuah jaringan bersama serta yang mengisolasi beberapa workload ke dalam project individual yang dapat dikelola oleh beberapa tim yang berbeda. VPC Bersama menyediakan deployment, pengelolaan, dan kontrol jaringan terpusat terhadap resource keamanan jaringan di beberapa project. VPC Bersama terdiri atas project host dan layanan yang melakukan fungsi berikut:

• Project host berisi jaringan dan resource terkait keamanan jaringan seperti, jaringan VPC, subnet, aturan firewall, dan konektivitas hybrid.
• Project layanan terlampir ke project host. Dengan menggunakan Identity and Access Management (IAM), Anda dapat mengisolasi workload dan pengguna di level project, sekaligus membagikan resource jaringan dari project host yang dikelola secara terpusat.

Menetapkan kebijakan dan aturan firewall di tingkat organisasi, folder, dan jaringan VPC. Anda dapat mengonfigurasi aturan firewall untuk mengizinkan atau menolak traffic ke atau dari instance VM. Untuk mengetahui contohnya, lihat Contoh kebijakan firewall jaringan global dan regional serta Contoh kebijakan firewall hierarkis. Selain menentukan aturan berdasarkan alamat IP, protokol, dan port, Anda juga dapat mengelola traffic serta menerapkan aturan firewall berdasarkan akun layanan yang digunakan oleh instance VM atau dengan menggunakan tag aman.

Untuk mengontrol perpindahan data di layanan Google dan untuk menyiapkan keamanan perimeter berbasis kontek, pertimbangkan Kontrol Layanan VPC. Kontrol Layanan VPC memberikan lapisan keamanan tambahan untuk layanan Google Cloud yang independen dari aturan serta kebijakan firewall dan IAM. Misalnya, Kontrol Layanan VPC memungkinkan Anda untuk menyiapkan perimeter antara data rahasia dan non-rahasia, sehingga Anda dapat menerapkan kontrol yang membantu mencegah pemindahan data yang tidak sah.

Menggunakan kebijakan keamanan Google Cloud Armor untuk mengizinkan, menolak, atau mengalihkan permintaan ke Load Balancer Aplikasi eksternal Anda di edge Google Cloud, sedekat mungkin dengan sumber traffic masuk. Kebijakan tersebut dapat mencegah traffic yang tidak diinginkan untuk menggunakan resource atau memasuki jaringan Anda.

Menggunakan Secure Web Proxy untuk menerapkan kebijakan akses terperinci ke traffic web keluar dan untuk memantau akses ke layanan web yang tidak tepercaya.

Memeriksa traffic jaringan Anda

Anda dapat menggunakan Cloud IDS dan Duplikasi Paket untuk membantu memastikan keamanan dan kepatuhan workload yang berjalan di Compute Engine dan Google Kubernetes Engine (GKE).

Menggunakan Cloud Intrusion Detection System (saat ini dalam pratinjau) untuk mendapatkan visibilitas ke traffic yang berpindah ke dan keluar dari jaringan VPC Anda. Cloud IDS membuat jaringan yang di-peering dan dikelola Google yang memiliki VM yang diduplikasi. Teknologi perlindungan terhadap ancaman Palo Alto Networks mencerminkan dan memeriksa traffic. Untuk informasi selengkapnya, lihat Ringkasan Cloud IDS.

Duplikasi Paket mengkloning traffic instance VM yang ditentukan di jaringan VPC Anda dan meneruskannya untuk pengumpulan, retensi, dan pemeriksaan. Setelah mengonfigurasi Duplikasi Paket, Anda dapat menggunakan Cloud IDS atau alat pihak ketiga untuk mengumpulkan dan memeriksa traffic jaringan dalam skala besar. Memeriksa traffic jaringan melalui cara ini dapat membantu memberikan deteksi penyusupan dan pemantauan performa aplikasi.

Menggunakan firewall aplikasi web

Untuk layanan dan aplikasi web eksternal Anda, Anda dapat mengaktifkan Google Cloud Armor untuk memberikan perlindungan terhadap Distributed Denial of Service (DDoS) dan kemampuan firewall aplikasi web (WAF). Google Cloud Armor mendukung workload Google Cloud yang diekspos menggunakan Load Balancing HTTP(S) eksternal, Load Balancing Proxy TCP, atau Load Balancing Proxy SSL.

Google Cloud Armor ditawarkan dalam dua paket layanan:, Standar dan Managed Protection Plus. Untuk memanfaatkan sepenuhnya kemampuan Google Cloud Armor yang canggih, Anda harus berinvestasi pada Managed Protection Plus untuk workload penting Anda.

Mengotomatiskan penyediaan infrastruktur

Otomatisasi memungkinkan Anda membuat infrastruktur yang tidak dapat diubah, yang berarti bahwa infrastruktur tersebut tidak dapat diubah setelah penyediaan. Pengukuran ini memberi tim operasi Anda keadaan yang baik, rollback yang cepat, dan kemampuan pemecahan masalah. Untuk otomatisasi, Anda dapat menggunakan beberapa alat seperti: Terraform, Jenkins, dan Cloud Build.

Untuk membantu Anda membangun lingkungan yang menggunakan otomatisasi, Google Cloud menyediakan serangkaian blueprint keamanan yang kemudian dikembangkan berdasarkan blueprint fondasi perusahaan. Blueprint security foundation memberikan desain berdasarkan opini Google untuk lingkungan aplikasi yang aman dan menjelaskan langkah demi langkah terkait cara mengonfigurasi serta men-deploy estate Google Cloud Anda. Dengan menggunakan petunjuk dan skrip yang merupakan bagian dari blueprint security foundation, Anda dapat mengonfigurasi sebuah lingkungan yang memenuhi pedoman dan praktik terbaik keamanan kami. Anda dapat mengembangkan blueprint tersebut dengan blueprint tambahan atau merancang otomatisasi Anda sendiri.

Untuk mengetahui informasi selengkapnya tentang otomatisasi, lihat Menggunakan pipeline CI/CD untuk alur kerja pemrosesan data.

Memantau jaringan Anda

Memantau jaringan dan traffic Anda menggunakan telemetri.

Log Aliran VPC dan Firewall Rules Logging memberikan visibilitas yang mendekati real-time ke traffic dan penggunaan firewall di lingkungan Google Cloud Anda. Misalnya, Firewall Rules Logging mencatat traffic ke dan dari Compute Engine instance VM. Saat Anda menggabungkan beberapa alat ini dengan Cloud Logging dan Cloud Monitoring, Anda dapat melacak, memberi tahu, serta memvisualisasikan traffic dan pola akses untuk meningkatkan keamanan operasional deployment Anda.

Analisis Firewall memungkinkan Anda untuk meninjau aturan firewall mana yang cocok dengan koneksi masuk dan keluar, serta apakah koneksi tersebut diizinkan atau ditolak. Fitur aturan yang dibayangi membantu Anda menyesuaikan konfigurasi firewall dengan menunjukkan aturan mana yang tidak pernah dipicu, karena aturan yang lain selalu dipicu terlebih dahulu.

Menggunakan Network Intelligence Center untuk melihat kinerja Topologi Jaringan dan arsitektur Anda. Anda dapat memperoleh insight terperinci tentang performa jaringan dan kemudian Anda dapat mengoptimalkan deployment milik Anda untuk menghilangkan kemacetan dalam layanan. Uji Konektivitas menyediakan insight tentang aturan dan kebijakan firewall yang diterapkan pada jalur jaringan.

Untuk mengetahui informasi selengkapnya tentang monitoring, lihat Menerapkan kontrol logging dan detektif.

Langkah selanjutnya

Mempelajari keamanan jaringan lebih lanjut dengan resource berikut:

• Menerapkan keamanan data (dokumen berikutnya dalam seri ini)
• Praktik terbaik dan arsitektur referensi untuk desain VPC
• Peran IAM untuk mengelola Kontrol Layanan VPC
• Melakukan orientasi sebagai partner Security Command Center
• Melihat kerentanan dan ancaman di Security Command Center
• Duplikasi Paket: Memvisualisasikan dan melindungi jaringan cloud Anda
• Menggunakan Duplikasi Paket untuk deteksi penyusupan
• Menggunakan Duplikasi Paket dengan solusi IDS partner

Menerapkan keamanan data

Dokumen dalam Framework Arsitektur Google Cloud ni memberikan praktik terbaik untuk menerapkan keamanan data.

Sebagai bagian dari arsitektur deployment, Anda harus mempertimbangkan data yang rencananya akan diproses dan disimpan dalam Google Cloud, serta sensitivitas data tersebut. Desain kontrol Anda untuk membantu mengamankan data selama siklus prosesnya, untuk mengidentifikasi kepemilikan dan klasifikasi data, dan untuk membantu melindungi data dari penggunaan yang tidak sah.

Untuk blueprint security yang men-deploy data warehouse BigQuery dengan praktik keamanan terbaik yang dijelaskan dalam dokumen ini, lihat Mengamankan data warehouse BigQuery yang menyimpan data rahasia.

Klasifikasikan data Anda secara otomatis

Lakukan klasifikasi data sedini mungkin dalam siklus pengelolaan data, idealnya saat data dibuat. Biasanya, upaya klasifikasi data hanya memerlukan beberapa kategori, seperti berikut:

• Publik: Data yang telah disetujui untuk diakses oleh publik.
• Internal: Data tidak sensitif yang tidak dirilis untuk publik.
• Rahasia: Data sensitif yang tersedia untuk distribusi internal umum.
• Dibatasi: Data yang sangat sensitif atau teregulasi yang memerlukan distribusi yang dibatasi.

Gunakan Sensitive Data Protection untuk menemukan dan mengklasifikasikan data di seluruh lingkungan Google Cloud Anda. Sensitive Data Protection memiliki dukungan bawaan untuk memindai dan mengklasifikasikan data sensitif pada data in Cloud Storage, BigQuery, dan Datastore. Platform ini juga memiliki streaming API untuk mendukung sumber data tambahan dan workload kustom.

Sensitive Data Protection dapat mengidentifikasi data sensitif menggunakan infotype bawaan. Layanan ini secara otomatis mengklasifikasikan, menyamarkan, membuat token, dan mengubah elemen sensitif (seperti data PII) agar Anda dapat mengelola risiko pengumpulan, penyimpanan, dan penggunaan data. Dengan kata lain, layanan ini dapat terintegrasi dengan proses siklus data Anda untuk memastikan bahwa data di setiap tahap terlindungi.

Untuk informasi selengkapnya, baca De-identifikasi dan identifikasi ulang PII dalam set data berskala besar menggunakan Sensitive Data Protection.

Atur tata kelola data menggunakan metadata

Tata kelola data adalah kombinasi proses yang memastikan bahwa data aman, bersifat pribadi, akurat, tersedia, dan dapat digunakan. Meskipun Anda bertanggung jawab untuk menentukan sebuah strategi tata kelola data untuk organisasi Anda, Google Cloud menyediakan alat dan teknologi untuk membantu Anda mempraktikkan strategi. Google Cloud juga menyediakan framework untuk tata kelola data (PDF) di cloud.

Gunakan Data Catalog untuk menemukan, menyeleksi, dan menggunakan metadata untuk menggambarkan aset data Anda dalam cloud. Anda dapat menggunakan Data Catalog untuk menelusuri aset data, lalu memberi tag pada aset dengan metadata. Untuk membantu mempercepat upaya klasifikasi data Anda, integrasikan Data Catalog dengan Sensitive Data Protection untuk mengidentifikasi data rahasia secara otomatis. Setelah data diberi tag, Anda dapat menggunakan Google Identity and Access Management (IAM) untuk membatasi data mana yang dapat dikueri atau digunakan oleh pengguna melalui tampilan Data Catalog.

Gunakan Dataproc Metastore atau Hive metastore untuk mengelola metadata untuk workload. Data Catalog memiliki sebuah konektor hive yang mengizinkan layanan untuk menemukan metadata dalam sebuah hive metastore.

Gunakan DataPrep by Trifacta untuk menentukan dan menerapkan aturan kualitas data melalui konsol. Anda dapat menggunakan Dataprep dari dalam Cloud Data Fusion atau menggunakan Dataprep sebagai layanan mandiri.

Lindungi data sesuai dengan fase siklus proses dan klasifikasinya

Setelah menentukan data dalam konteks siklus prosesnya dan mengklasifikasikan data berdasarkan sensitivitas dan risikonya, Anda dapat menetapkan kontrol keamanan yang tepat untuk melindunginya. Anda harus memastikan bahwa kontrol Anda memberikan perlindungan yang memadai, memenuhi persyaratan kepatuhan, dan mengurangi risiko. Saat beralih ke cloud, tinjau strategi Anda saat ini dan di mana Anda mungkin perlu mengubah proses saat ini.

Tabel berikut menjelaskan tiga karakteristik strategi keamanan data pada cloud.

Karakteristik	Deskripsi
Identifikasi	Pahami identitas pengguna, resource, dan aplikasi saat mereka membuat, mengubah, menyimpan, menggunakan, membagikan, dan menghapus data. Gunakan Cloud Identity dan IAM untuk mengontrol akses ke data. Jika identitas Anda memerlukan sertifikat, pertimbangkan Certificate Authority Service. Untuk informasi selengkapnya, lihat Mengelola identitas dan akses.
Batas dan akses	Siapkan kontrol terkait cara data diakses, oleh siapa, dan dalam keadaan apa. Batasan akses data dapat dikelola pada tingkat berikut ini: Akses lapisan jaringan menggunakan kontrol seperti Cloud Firewall. Untuk mendapatkan insight selengkapnya tentang lapisan jaringan Anda, gunakanlah Network Intelligence Center. Gunakan Kontrol Layanan VPC untuk membuat perimeter yang melindungi resource dan data layanan yang Anda tentukan. Kontrol akses IAM menggunakan IAM. Untuk informasi tentang cara mengelola peran IAM, baca Menggunakan hierarki resource untuk kontrol akses.
Visibilitas	Anda dapat mengaudit penggunaan dan membuat laporan yang menunjukkan cara data dikontrol dan diakses. Google Cloud Logging dan Transparansi Akses menyediakan insight tentang aktivitas administrator cloud dan personel Google Anda. Untuk informasi selengkapnya, baca Memantau data.

Mengenkripsi data Anda

Secara default, Google Cloud mengenkripsi data pelanggan yang disimpan dalam penyimpanan, tanpa memerlukan tindakan Anda. Selain melakukan enkripsi default, Google Cloud menyediakan opsi untuk amplop enkripsi dan pengelolaan kunci enkripsi. Misalnya, persistent disk Compute Engine secara otomatis dienkripsi, tetapi Anda dapat menyediakan atau mengelola kunci sendiri.

Anda harus mengidentifikasi solusi yang paling sesuai dengan persyaratan Anda sebagai kunci pembuatan, penyimpanan, dan rotasi, baik memilih kunci untuk penyimpanan Anda, untuk komputasi, atau untuk workload big data

Google Cloud mencakup opsi berikut untuk enkripsi dan pengelolaan kunci:

• Kunci enkripsi yang dikelola pelanggan (CMEK) Anda dapat membuat dan mengelola kunci enkripsi menggunakan Cloud Key Management Service (Cloud KMS). Gunakan opsi ini jika Anda memiliki persyaratan pengelolaan kunci tertentu, seperti perlu merotasi kunci enkripsi secara rutin.
• Kunci enkripsi yang disediakan pelanggan (CSEK) Anda dapat membuat dan mengelola kunci enkripsi Anda sendiri, lalu memberikannya ke Google Cloud jika diperlukan. Gunakan opsi ini jika Anda membuat kunci Anda sendiri menggunakan sistem pengelolaan kunci lokal untuk membawa kunci Anda sendiri (BYOK). Jika Anda menyediakan kunci Anda sendiri menggunakan CSEK, Google akan mereplikasi kunci tersebut dan membuatnya tersedia untuk workload Anda. Namun, keamanan dan ketersediaan CSEK adalah tanggung jawab Anda karena kunci yang disediakan pelanggan tidak disimpan dalam template instance atau di infrastruktur Google. Jika Anda kehilangan akses kunci tersebut, Google tidak dapat membantu Anda memulihkan data yang dienkripsi. Pikirkan baik-baik mengenai kunci mana yang ingin Anda buat dan kelola sendiri. Anda mungkin menggunakan CSEK hanya untuk informasi yang paling sensitif. Opsi lainnya adalah dengan melakukan enkripsi sisi klien pada data Anda, lalu menyimpan data terenkripsi di Google Cloud, tempat data tersebut dienkripsi kembali oleh Google.
• Sistem pengelolaan kunci pihak ketiga dengan Cloud External Key Manager (Cloud EKM). Cloud EKM melindungi data dalam penyimpanan menggunakan kunci enkripsi yang disimpan dan dikelola dalam sistem pengelolaan kunci pihak ketiga yang Anda kontrol di luar infrastruktur Google. Saat menggunakan metode ini, Anda memiliki jaminan tinggi bahwa data Anda tidak akan dapat diakses oleh siapa pun di luar organisasi Anda. Dengan Cloud EKM, ,memungkinkan Anda dapat mencapai model hold-your-key (HYOK) yang aman untuk pengelolaan kunci. Untuk mengetahui informasi kompatibilitas, baca Daftar layanan yang mendukung Cloud EKM.

Cloud KMS juga memungkinkan Anda untuk mengenkripsi data Anda dengan kunci enkripsi yang didukung software atau modul keamanan hardware (HSM) yang divalidasi FIPS 140-2 Level 3. Jika Anda menggunakan Cloud KMS, kunci kriptografis Anda disimpan pada region tempat Anda men-deploy resource. Cloud HSM mendistribusikan kebutuhan pengelolaan kunci Anda pada seluruh region, sehingga memberikan redundansi dan ketersediaan kunci secara global.

Untuk mengetahui informasi tentang cara kerja amplop enkripsi, lihat Enkripsi dalam penyimpanan di Google Cloud.

Kontrol akses administrator cloud ke data Anda

Anda dapat mengontrol akses oleh staf Dukungan Google dan engineering ke lingkungan Anda pada Google Cloud. Persetujuan Akses memungkinkan Anda menyetujui secara eksplisit sebelum karyawan Google mengakses data atau resource Anda pada Google Cloud. Produk ini melengkapi visibilitas yang disediakan oleh Transparansi Akses, yang menghasilkan log saat personel Google berinteraksi dengan data Anda. Log ini mencakup lokasi kantor dan alasan aksesnya.

Dengan menggunakan produk-produk ini bersamaan, Anda dapat menolak kemampuan Google untuk mendeskripsikan data Anda dengan alasan apa pun.

Konfigurasikan tempat data Anda disimpan dan dari mana pengguna dapat mengaksesnya

Anda dapat mengontrol lokasi jaringan dari tempat pengguna dapat mengakses data menggunakan Kontrol Layanan VPC. Produk ini memungkinkan Anda membatasi akses terhadap pengguna di wilayah tertentu. Anda dapat menerapkan batasan ini meskipun pengguna diberi otorisasi sesuai dengan kebijakan Google IAM Anda. Dengan menggunakan Kontrol Layanan VPC, Anda membuat sebuah perimeter layanan yang menentukan batas virtual tempat layanan dapat diakses, hal ini mencegah data dipindahkan ke luar batas tersebut.

Untuk informasi selengkapnya, lihat referensi berikut:

• Mengotomatiskan klasifikasi data yang diupload ke Cloud Storage
• Tata kelola data pada cloud
• Data warehouse ke tata kelola data BigQuery
• Metastore Cloud Hives tersedia saat ini

Kelola rahasia menggunakan Secret Manager

Secret Manager memungkinkan Anda dapat menyimpan semua secret di tempat terpusat. Secret adalah informasi konfigurasi seperti sandi database, kunci API, atau sertifikat TSL. Anda dapat merotasi secret secara otomatis, dan Anda dapat mengonfigurasi aplikasi agar otomatis menggunakan versi terbaru dari sebuah secret. Setiap interaksi dengan Secret Manager akan menghasilkan sebuah log audit, sehingga Anda dapat melihat setiap akses ke setiap secret.

Sensitive Data Protection juga memiliki sebuah kategori pendeteksi untuk membantu Anda mengidentifikasi kredensial dan secret dalam data yang dapat dilindungi dengan Secret Manager.

Pantau data Anda

Untuk menampilkan aktivitas administrator dan log penggunaan kunci, gunakan Cloud Audit Logs. Untuk membantu mengamankan data Anda, pantau log menggunakan Cloud Monitoring untuk memastikan penggunaan kunci Anda dilakukan dengan benar.

Cloud Logging menangkap peristiwa Google Cloud dan memungkinkan Anda menambahkan sumber lain jika perlu. Anda dapat melakukan segmentasi log berdasarkan region, menyimpannya di bucket, dan mengintegrasikan kode kustom untuk memproses log. Sebagai contoh, lihat Solusi khusus untuk analisis log otomatis.

Anda juga dapat mengekspor log ke BigQuery untuk menjalankan keamanan dan mengakses analisis guna membantu mengidentifikasi perubahan yang tidak sah dan akses yang tidak pantas ke data organisasi Anda.

Security Command Center dapat membantu Anda mengidentifikasi dan menyelesaikan masalah akses tidak aman terhadap data organisasi sensitif yang disimpan di cloud. Melalui satu grafis pengelolaan, Anda dapat memindai berbagai kerentanan dan risiko keamanan pada infrastruktur cloud. Misalnya, Anda dapat memantau pemindahan data yang tidak sah, memindai sistem penyimpanan untuk menemukan data rahasia, dan mendeteksi manakah bucket Cloud Storage yang terbuka untuk internet.

Langkah selanjutnya

Pelajari keamanan data lebih lanjut dengan referensi berikut:

• Deploy aplikasi dengan aman(dokumen berikutnya dalam seri ini)

• Amankan data warehouse BigQuery yang menyimpan data rahasia

• Mendesain dan men-deploy strategi keamanan data (PDF)

• Percayakan data Anda pada Google Cloud (PDF)

• Kebijakan retensi menggunakan Kunci Bucket

• Praktik terbaik untuk Cloud Storage

• Praktik terbaik untuk instance SQL Server

• Praktik terbaik Datastore

• Data Catalog

Deploy aplikasi secara aman

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk men-deploy aplikasi dengan aman.

Untuk men-deploy aplikasi yang aman, Anda harus memiliki siklus proses pengembangan software yang ditetapkan dengan baik, dengan pemeriksaan keamanan yang sesuai selama tahap desain, pengembangan, pengujian, dan deployment. Saat Anda mendesain aplikasi, sebaiknya Anda menggunakan arsitektur sistem berlapis yang menggunakan framework standar untuk identitas, otorisasi, dan kontrol akses.

Mengotomatiskan rilis aman

Tanpa alat otomatis, akan sulit untuk men-deploy, mengupdate, dan mem-patch lingkungan aplikasi yang kompleks guna memenuhi persyaratan keamanan yang konsisten. Oleh karena itu, sebaiknya Anda mem-build pipeline CI/CD untuk tugas ini, yang dapat menyelesaikan banyak masalah tersebut. Pipeline otomatis menghapus error manual, menyediakan feedback loop pengembangan standar, dan memungkinkan iterasi produk yang cepat. Misalnya, dengan kumpulan pribadi Cloud Build, Anda dapat men-deploy pipeline CI/CD terkelola yang sangat aman untuk industri yang diatur dengan regulasi ketat, termasuk keuangan dan layanan kesehatan.

Anda dapat menggunakan otomatisasi untuk memindai kerentanan keamanan saat artefak dibuat. Anda juga dapat menentukan kebijakan untuk lingkungan yang berbeda (pengembangan, pengujian, produksi, dan sebagainya) sehingga hanya artefak terverifikasi yang di-deploy.

Pastikan deployment aplikasi mengikuti proses yang disetujui

Jika penyerang menyusupi pipeline CI/CD Anda, seluruh stack Anda dapat terpengaruh. Untuk membantu mengamankan pipeline, Anda harus menerapkan proses persetujuan yang ditetapkan sebelum men-deploy kode ke produksi.

Jika berencana menggunakan Google Kubernetes Engine (GKE) atau GKE Enterprise, Anda dapat membuat check and balance ini menggunakan Otorisasi Biner. Otorisasi Biner melampirkan tanda tangan yang dapat dikonfigurasi ke image container. Tanda tangan ini (juga disebut attestations) membantu memvalidasi image. Saat deployment, Otorisasi Biner menggunakan pengesahan ini untuk menentukan bahwa proses telah diselesaikan lebih awal. Misalnya, Anda dapat menggunakan Otorisasi Biner untuk melakukan hal berikut:

• Pastikan bahwa sistem build atau pipeline continuous integration (CI) tertentu membuat image container.
• Validasi bahwa image container mematuhi kebijakan penandatanganan kerentanan.
• Pastikan bahwa image container lulus kriteria untuk promosi ke lingkungan deployment berikutnya, seperti dari pengembangan hingga UM (Uji Mutu).

Memindai kerentanan yang diketahui sebelum deployment

Sebaiknya gunakan alat otomatis yang dapat terus melakukan pemindaian kerentanan pada image container sebelum container di-deploy ke produksi.

Gunakan Artifact Analysis untuk otomatis memindai kerentanan untuk menemukan container yang disimpan di Artifact Registry dan Container Registry. Proses ini mencakup dua tugas: pemindaian dan analisis berkelanjutan.

Untuk memulai, Artifact Analysis akan memindai image baru ketika diupload ke Artifact Registry atau Container Registry. Pemindaian akan mengekstrak informasi tentang paket sistem dalam container.

Kemudian, Artifact Analysis akan mencari kerentanan saat Anda mengupload image. Setelah pemindaian awal, Artifact Analysis terus memantau metadata image yang dipindai di Artifact Registry dan Container Registry untuk mencari kerentanan baru. Saat Artifact Analysis menerima informasi kerentanan baru dan yang diperbarui dari sumber kerentanan, akan dilakukan hal berikut:

• Memperbarui metadata gambar yang dipindai agar tetap terbaru.
• Membuat kejadian kerentanan baru untuk catatan baru.
• Menghapus kemunculan kerentanan yang tidak lagi valid.

Pantau kode aplikasi Anda untuk kerentanan yang diketahui

Praktik terbaiknya adalah menggunakan alat otomatis yang dapat terus memantau kode aplikasi Anda untuk menemukan kerentanan umum, seperti OWASP Top 10. Untuk deskripsi tentang produk dan fitur Google Cloud yang mendukung teknik mitigasi Top 10 OWASP, lihat 10 opsi mitigasi teratas OWASP di Google Cloud.

Gunakan Web Security Scanner untuk membantu mengidentifikasi kerentanan keamanan di aplikasi web App Engine, Compute Engine, dan Google Kubernetes Engine Anda. Pemindai meng-crawl aplikasi Anda, mengikuti semua link dalam cakupan URL awal, dan mencoba menggunakan input pengguna dan pengendali peristiwa sebanyak mungkin. API ini dapat otomatis memindai dan mendeteksi kerentanan umum, termasuk pembuatan skrip lintas situs (XSS), injeksi Flash, konten campuran (HTTP di HTTPS), dan library yang usang atau tidak aman. Web Security Scanner memberi Anda identifikasi awal atas jenis kerentanan ini dengan rasio positif palsu yang rendah.

Mengontrol pergerakan data di seluruh perimeter

Untuk mengontrol pergerakan data di seluruh perimeter, Anda dapat mengonfigurasi perimeter keamanan di sekitar resource layanan yang dikelola Google. Gunakan Kontrol Layanan VPC untuk menempatkan semua komponen dan layanan di pipeline CI/CD Anda (misalnya, Container Registry, Artifact Registry, Artifact Analysis, dan Otorisasi Biner) di dalam perimeter keamanan.

Kontrol Layanan VPC meningkatkan kemampuan Anda untuk mengurangi risiko penyalinan atau transfer data tanpa izin (pemindahan data yang tidak sah) dari layanan yang dikelola Google. Dengan Kontrol Layanan VPC, Anda mengonfigurasi perimeter keamanan di sekitar resource layanan yang dikelola Google untuk mengontrol pergerakan data melintasi batas perimeter. Jika perimeter layanan diterapkan, permintaan yang melanggar kebijakan perimeter akan ditolak, seperti permintaan yang dibuat ke layanan yang dilindungi dari luar perimeter. Jika layanan dilindungi oleh perimeter yang diterapkan, Kontrol Layanan VPC memastikan hal berikut:

• Layanan tidak dapat mengirimkan data keluar dari perimeter. Layanan yang dilindungi berfungsi seperti biasa di dalam perimeter, tetapi tidak dapat mengirim resource dan data keluar dari perimeter. Pembatasan ini membantu mencegah orang dalam berniat jahat yang mungkin memiliki akses ke project di dalam perimeter agar tidak memindahkan data secara tidak sah.
• Permintaan yang berasal dari luar perimeter ke layanan yang dilindungi hanya akan diterima jika permintaan tersebut memenuhi kriteria tingkat akses yang ditetapkan ke perimeter.
• Layanan dapat dibuat dapat diakses oleh project di perimeter lain menggunakan jembatan perimeter.

Enkripsi image container Anda

Di Google Cloud, Anda dapat mengenkripsi image container menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Kunci CMEK dikelola di Cloud Key Management Service (Cloud KMS). Saat menggunakan CMEK, Anda dapat menonaktifkan akses ke image container terenkripsi untuk sementara atau secara permanen dengan menonaktifkan atau menghancurkan kunci tersebut.

Langkah selanjutnya

Pelajari lebih lanjut cara mengamankan keamanan supply chain dan aplikasi Anda dengan referensi berikut:

• Mengelola kewajiban kepatuhan (dokumen berikutnya dalam seri ini)
• Keunggulan Operasional
• Otorisasi Biner
• Analisis Artefak
• Artifact Registry

Kelola kewajiban kepatuhan

Dokumen dalam Framework Arsitektur Google Cloud ini menyediakan praktik terbaik untuk mengelola kewajiban kepatuhan.

Persyaratan peraturan cloud Anda bergantung pada kombinasi berbagai faktor, termasuk hal berikut:

• Hukum dan peraturan yang berlaku di lokasi fisik organisasi Anda.
• Hukum dan peraturan yang berlaku di lokasi fisik pelanggan.
• Persyaratan peraturan industri Anda.

Persyaratan ini memengaruhi banyak keputusan yang perlu Anda buat tentang kontrol keamanan mana yang perlu diaktifkan untuk workload Anda di Google Cloud.

Perjalanan kepatuhan biasanya melewati tiga tahap: penilaian, perbaikan kesenjangan, dan pemantauan berkelanjutan. Bagian ini membahas praktik terbaik yang dapat Anda gunakan selama setiap tahap.

Menilai kebutuhan kepatuhan Anda

Penilaian kepatuhan dimulai dengan peninjauan menyeluruh atas semua kewajiban peraturan Anda dan cara bisnis Anda menerapkannya. Untuk membantu Anda menilai layanan Google Cloud, gunakan Pusat referensi kepatuhan. Situs ini menyediakan detail tentang hal berikut:

• Dukungan layanan untuk berbagai peraturan
• Sertifikasi dan pengesahan Google Cloud

Anda dapat meminta interaksi dengan pakar kepatuhan Google untuk lebih memahami siklus proses kepatuhan di Google dan bagaimana persyaratan Anda dapat dipenuhi.

Untuk informasi selengkapnya, lihat Memastikan kepatuhan di cloud (PDF).

Men-deploy Assured Workloads

Assured Workloads adalah alat Google Cloud yang dibangun pada kontrol di dalam Google Cloud untuk membantu memenuhi kewajiban kepatuhan Anda. Assured Workloads memungkinkan Anda melakukan hal berikut:

• Memilih rezim kepatuhan Anda. Alat ini kemudian akan otomatis menetapkan kontrol akses personel dasar pengukuran.
• Menetapkan lokasi untuk data Anda menggunakan kebijakan organisasi sehingga data dalam penyimpanan dan resource Anda tetap berada di region tersebut.
• Memilih opsi pengelolaan kunci (seperti periode rotasi kunci) yang paling sesuai dengan persyaratan keamanan dan kepatuhan Anda.
• Untuk persyaratan peraturan tertentu seperti FedRAMP Moderate, memilih kriteria akses oleh staf dukungan Google (misalnya, apakah mereka telah menyelesaikan pemeriksaan latar belakang dengan tepat).
• Memastikan kunci enkripsi yang dikelola Google mematuhi FIPS-140-2 dan mendukung kepatuhan FedRAMP Moderate. Untuk memberi lapisan kontrol tambahan dan memisahkan tugas, Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Untuk informasi selengkapnya tentang kunci, lihat Mengenkripsi data Anda.

Tinjau blueprint untuk template dan praktik terbaik yang berlaku untuk rezim kepatuhan Anda

Google telah memublikasikan panduan blueprint dan solusi yang menjelaskan tentang praktik terbaik serta menyediakan modul Terraform agar Anda dapat meluncurkan lingkungan yang membantu Anda mencapai kepatuhan. Tabel berikut mencantumkan pilihan blueprint yang membahas keamanan dan keselarasan dengan persyaratan kepatuhan.

Standar	Deskripsi
PCI	Blueprint keamanan: PCI di GKE Kepatuhan Standar Keamanan Data PCI Membatasi cakupan kepatuhan untuk lingkungan PCI di Google Cloud Kepatuhan PCI DSS di GKE
FedRAMP	Panduan penerapan FedRAMP Google Cloud (PDF) Menyiapkan Workload Tiga Tingkat yang Selaras dengan FedRAMP di Google Cloud
HIPAA	Melindungi data layanan kesehatan di Google Cloud (PDF) Menyiapkan workload yang selaras dengan HIPAA menggunakan Toolkit Perlindungan Data (PDF)

Pantau kepatuhan Anda

Sebagian besar peraturan mengharuskan Anda untuk memantau aktivitas tertentu, termasuk kontrol akses. Untuk membantu Anda memantau, Anda dapat menggunakan hal berikut:

• Transparansi Akses, yang menyediakan log mendekati real-time saat admin Google Cloud mengakses konten Anda.
• Firewall Rules Logging untuk merekam koneksi TCP dan UDP di dalam jaringan VPC untuk setiap aturan yang Anda buat sendiri. Log ini dapat berguna untuk mengaudit akses jaringan atau memberikan peringatan awal bahwa jaringan sedang digunakan dengan cara yang tidak disetujui.
• Log Aliran VPC untuk mencatat alur traffic jaringan yang dikirim atau diterima oleh instance VM.
• Security Command Center Premium untuk memantau kepatuhan terhadap berbagai standar.
• OSSEC (atau alat open source lainnya) untuk mencatat aktivitas individu yang memiliki akses admin ke lingkungan Anda.
• Key Access Justifications untuk melihat alasan permintaan akses kunci.

Membuat kepatuhan Anda otomatis

Untuk membantu Anda tetap mematuhi peraturan yang terus berubah, tentukan apakah ada cara untuk mengotomatiskan kebijakan keamanan Anda dengan menyertakannya ke dalam infrastruktur Anda sebagai deployment kode. Misalnya, pertimbangkan hal berikut:

• Gunakan blueprint keamanan untuk menyertakan kebijakan keamanan Anda ke dalam deployment infrastruktur Anda.

• Konfigurasikan Security Command Center untuk memberi tahu ketika masalah ketidakpatuhan terjadi. Misalnya, pantau masalah seperti pengguna yang menonaktifkan verifikasi dua langkah atau akun layanan dengan hak istimewa berlebih. Untuk informasi selengkapnya, lihat Menyiapkan notifikasi temuan.

• Menyiapkan perbaikan otomatis untuk notifikasi tertentu. Untuk informasi selengkapnya, lihat Kode Cloud Functions.

Untuk informasi selengkapnya tentang otomatisasi kepatuhan, lihat Solusi Risiko dan Kepatuhan sebagai Kode (RCaC).

Langkah selanjutnya

Pelajari kepatuhan lebih lanjut dengan resource berikut:

• Mengimplementasikan persyaratan residensi dan kedaulatan data (dokumen berikutnya dalam seri ini)
• Pusat Referensi Kepatuhan
• Laporan resmi keamanan Google (PDF)
• Assured Workloads

Menerapkan persyaratan residensi dan kedaulatan data

Dokumen di Framework Arsitektur Google Cloud memberikan praktik terbaik untuk mengimplementasikan persyaratan residensi dan kedaulatan data.

Persyaratan residensi dan kedaulatan data didasarkan pada peraturan khusus region dan dan organisasi yang berbeda mungkin memiliki persyaratan kedaulatan data data yang berbeda. Contohnya, Anda mungkin memiliki persyaratan berikut:

• Pengendalian atas semua akses ke data Anda oleh Google Cloud, termasuk jenis personel yang dapat mengakses data dan dari region mana mereka dapat mengaksesnya.
• Kemampuan menginspeksi perubahan pada infrastruktur dan layanan cloud, yang dapat berdampak pada akses ke data atau keamanan data Anda. Insight tentang jenis perubahan ini membantu memastikan bahwa Google Cloud tidak dapat mengakali kontrol atau memindahkan data Anda keluar dari region.
• Kemampuan keberlangsungan workload Anda dalam jangka waktu yang lebih lama saat Anda tidak dapat menerima update software dari Google Cloud.

Mengelola kedaulatan data Anda

Kedaulatan data memberikan Anda mekanisme untuk mencegah Google mengakses data Anda. Anda hanya menyetujui akses bagi perilaku penyedia yang menurut Anda diperlukan.

Misalnya, Anda dapat mengelola kedaulatan data Anda dengan cara berikut:

• Simpan dan kelola kunci enkripsi di luar cloud.
• Hanya berikan akses ke kunci enkripsi berdasarkan justifikasi akses yang mendetail.
• Lindungi data aktif.

Mengelola kedaulatan operasional Anda

Kedaulatan operasional memberi Anda jaminan bahwa personel Google tidak dapat membahayakan workload Anda.

Misalnya, Anda dapat mengelola kedaulatan operasional dengan cara berikut:

• Batasi deployment resource baru ke region penyedia tertentu.
• Batasi akses personel Google berdasarkan atribut yang telah ditentukan sebelumnya seperti kewarganegaraan atau lokasi geografis mereka.

Mengelola kedaulatan software

Kedaulatan software memberi Anda jaminan bahwa Anda dapat mengontrol ketersediaan workload Anda dan menjalankannya di mana pun Anda inginkan, tanpa bergantung (atau terkunci) pada satu penyedia cloud. Kedaulatan software mencakup kemampuan untuk bertahan dari peristiwa yang mengharuskan Anda untuk dengan cepat mengubah lokasi deployment workload dan tingkat koneksi luar yang diizinkan.

Misalnya, Google Cloud mendukung deployment hybrid dan multicloud. Selain itu, GKE Enterprise dapat Anda gunakan untuk mengelola dan men-deploy aplikasi baik di lingkungan cloud maupun di lingkungan lokal.

Mengontrol residensi data

Residensi data menjelaskan lokasi penyimpanan data Anda saat data dalam kondisi tidak aktif. Persyaratan residensi data bervariasi berdasarkan tujuan desain sistem, masalah peraturan industri, hukum nasional, implikasi pajak, dan bahkan budaya.

Mengontrol residensi data dimulai dengan hal berikut:

• Memahami jenis data dan lokasinya.
• Menentukan risiko yang ada pada data Anda, serta hukum dan peraturan yang berlaku.
• Mengontrol lokasi penyimpanan data atau ke mana data tersebut pergi.

Untuk membantu mematuhi persyaratan residensi data, Google Cloud memungkinkan Anda mengontrol lokasi data Anda disimpan, bagaimana data diakses, serta bagaimana data diproses. Gunakan kebijakan lokasi resource untuk membatasi tempat pembuatan resource dan untuk membatasi tempat replikasi data antar region. Anda dapat menggunakan properti lokasi resource untuk mengidentifikasi lokasi layanan di-deploy dan siapa pengelolanya.

Untuk informasi dukungan, lihat Layanan yang didukung lokasi resource.

Langkah selanjutnya

Pelajari residensi dan kedaulatan data lebih lanjut dengan referensi berikut:

• Terapkan persyaratan privasi (dokumen berikutnya dalam seri ini)
• Residensi data, transparansi operasional, dan privasi untuk pelanggan Eropa di Google Cloud (PDF)
• Mendesain dan men-deploy strategi keamanan data (PDF)
• Cloud Key Management Service
• Percayakan data Anda pada Google Cloud (PDF)
• Akses dengan hak istimewa di Google
• Transparansi Akses Google Cloud

Menerapkan persyaratan privasi

Dokumen di Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk menerapkan persyaratan privasi.

Peraturan privasi membantu mengatur cara Anda mendapatkan, memproses, menyimpan, dan mengelola data pengguna Anda. Sebagian besar kontrol privasi (contohnya, kontrol untuk cookie, pengelolaan sesi, dan mendapatkan izin pengguna) adalah tanggung jawab Anda karena Anda adalah pemilik data (termasuk data yang Anda terima dari pengguna Anda).

Google Cloud memiliki beberapa kontrol berikut yang menunjang privasi:

• Enkripsi default ke semua data saat data tersebut dalam penyimpanan, dalam pengiriman, dan saat sedang diproses.
• Pengamanan dari akses orang dalam.
• Dukungan untuk berbagai peraturan privasi.

Untuk informasi selengkapnya, lihat Komitmen Privasi Google Cloud.

Mengklasifikasikan data rahasia

Anda harus menentukan data mana yang bersifat rahasia, kemudian pastikan bahwa data rahasia tersebut telah terlindungi dengan benar. Data rahasia dapat mencakup nomor kartu kredit, alamat, nomor telepon, dan informasi identitas pribadi (PII) lainnya.

Dengan menggunakan Sensitive Data Protection, Anda dapat menyiapkan klasifikasi yang sesuai. Anda kemudian dapat memberi tag dan men-token-kan data Anda sebelum menyimpannya di Google Cloud. Untuk informasi lebih lanjut, lihat Klasifikasikan data Anda secara otomatis.

Mengunci akses ke data sensitif

Tempatkan data sensitif di perimeter layanannya sendiri menggunakan Kontrol Layanan VPC, dan setel kontrol akses Identity and Access Management (IAM) Google untuk data tersebut. Konfigurasikan autentikasi multi-faktor (MFA) untuk semua pengguna yang memerlukan akses ke data sensitif.

Untuk informasi selengkapnya, lihat Mengontrol pergerakan data di seluruh perimeter dan Menyiapkan SSO dan MFA.

Memantau serangan phishing

Pastikan sistem email Anda telah terkonfigurasi untuk melindungi dari serangan phishing, yang mana sering digunakan untuk penipuan dan serangan malware.

Jika organisasi Anda menggunakan Gmail, Anda dapat menggunakan perlindungan lanjutan terhadap phishing dan malware. Kumpulan setelan ini memberikan kontrol untuk melakukan karantina email, melindungi dari jenis lampiran yang tidak wajar, dan membantu melindungi dari email spoofing yang masuk. Sandbox Keamanan dapat mendeteksi malware dalam lampiran. Gmail secara terus-menerus dan otomatis diperbarui dengan peningkatan dan perlindungan keamanan terbaru untuk membantu menjaga keamanan email organisasi Anda.

Memperluas keamanan zero-trust ke tenaga kerja hybrid Anda

Model keamanan zero-trust artinya tidak ada siapa pun yang dipercaya secara implisit, baik mereka berada di dalam maupun di luar jaringan organisasi Anda. Saat sistem IAM Anda memverifikasi permintaan akses, postur keamanan zero-trust berarti bahwa identitas dan konteks pengguna (misalnya, alamat IP atau lokasi mereka) akan diperiksa. Tidak seperti VPN, keamanan zero-trust mengalihkan kontrol akses dari perimeter jaringan ke pengguna dan perangkat mereka. Keamanan zero-trust memungkinkan pengguna bekerja lebih aman dari lokasi mana pun. Misalnya, pengguna dapat mengakses resource organisasi Anda dari laptop atau perangkat seluler mereka saat di rumah.

Di Google Cloud, Anda dapat mengonfigurasi BeyondCorp Enterprise dan Identity-Aware Proxy (IAP) untuk mengaktifkan zero-trust untuk Resource Google Cloud Anda. Jika pengguna Anda menggunakan Google Chrome dan Anda mengaktifkan BeyondCorp Enterprise, Anda dapat mengintegrasikan keamanan zero-trust ke dalam browser pengguna Anda.

Langkah selanjutnya

Pelajari lebih lanjut tentang keamanan dan privasi dengan referensi berikut:

• Menerapkan kontrol logging dan detektif (dokumen berikutnya dalam seri ini)
• Pusat Privasi

• Pemberitahuan Privasi Google Cloud

• Praktik terbaik privasi saat bekerja sama dengan Dukungan Google Cloud

• Cara Google melindungi keamanan dan privasi organisasi Anda

• FAQ Privasi

Mengimplementasikan kontrol logging dan detektif

Dokumen pada Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk menerapkan kendali detektif dan logging.

Kontrol detektif menggunakan telemetri untuk mendeteksi kesalahan konfigurasi, kerentanan, dan potensi aktivitas berbahaya di lingkungan cloud. Google Cloud membuat Anda dapat mengendalikan pemantauan dan detektif yang disesuaikan untuk lingkungan Anda. Bagian ini menjelaskan fitur dan rekomendasi tambahan ini untuk penggunaannya.

Memantau performa jaringan

Network Intelligence Center memberi Anda visibilitas tentang performa arsitektur dan topologi jaringan Anda. Anda dapat memperoleh insight terperinci tentang performa jaringan, lalu menggunakan informasi tersebut untuk mengoptimalkan deployment dengan menghilangkan bottleneck pada layanan. Uji Konektivitas memberi Anda insight tentang aturan dan kebijakan firewall yang diterapkan ke jalur jaringan.

Pantau dan cegah pemindahan data yang tidak sah

Pemindahan data yang tidak sah menjadi perhatian utama organisasi. Biasanya, hal ini terjadi saat orang yang memiliki izin mengekstrak data dari sistem yang diamankan, lalu membagikan data tersebut kepada pihak yang tidak berwenang atau memindahkannya ke sistem yang tidak aman.

Google Cloud menyediakan beberapa fitur dan alat yang membantu Anda mendeteksi serta mencegah pemindahan data yang tidak sah. Untuk informasi selengkapnya, baca Mencegah pemindahan data yang tidak sah.

Memusatkan pemantauan Anda

Security Command Center memberikan visibilitas ke resource yang Anda miliki di Google Cloud dan status keamanannya. Security Command Center membantu Anda mencegah, mendeteksi, dan merespons ancaman. Layanan ini menyediakan dasbor terpusat yang dapat Anda gunakan untuk membantu mengidentifikasi kesalahan konfigurasi keamanan di virtual machine, jaringan, aplikasi, dan bucket penyimpanan. Anda dapat mengatasi masalah ini sebelum menyebabkan kerusakan atau kerugian bisnis. Kemampuan bawaan Security Command Center dapat mengungkapkan aktivitas mencurigakan di log keamanan Cloud Logging Anda atau menunjukkan mesin virtual yang disusupi.

Anda dapat merespons ancaman dengan mengikuti rekomendasi yang dapat ditindaklanjuti atau dengan mengekspor log ke sistem SIEM Anda untuk penyelidikan lebih lanjut. Untuk mengetahui informasi tentang cara menggunakan sistem SIEM dengan Google Cloud, lihat Analisis log keamanan di Google Cloud.

Security Command Center juga menyediakan beberapa detektor yang membantu Anda menganalisis keamanan infrastruktur. Pendeteksi ini mencakup:

• Event Threat Detection
• Analisis Kondisi Keamanan (SHA)
• Layanan Tindakan Sensitif

Layanan Google Cloud lainnya, seperti log Google Cloud Armor, juga menyediakan temuan untuk ditampilkan di Security Command Center.

Aktifkan layanan yang Anda perlukan untuk workload Anda, lalu hanya pantau dan analisis data penting. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan logging pada layanan, lihat bagian mengaktifkan log dalam Analisis log keamanan di Google Cloud.

Memantau ancaman

Event Threat Detection adalah layanan terkelola opsional dari Security Command Center Premium yang mendeteksi ancaman di aliran log Anda. Dengan Event Threat Detection, Anda dapat mendeteksi ancaman yang berisiko tinggi dan mahal, seperti malware, cryptomining, akses tidak sah ke resource Google Cloud, serangan DDoS, dan serangan SSH brute force. Dengan menggunakan fitur alat ini untuk menyaring volume data log, tim keamanan Anda dapat dengan cepat mengidentifikasi insiden berisiko tinggi dan berfokus pada upaya perbaikan.

Untuk membantu mendeteksi akun pengguna yang berpotensi disusupi di organisasi Anda, gunakan Log Platform Cloud Action Sensitif untuk mengidentifikasi kapan tindakan sensitif dilakukan dan untuk mengonfirmasi bahwa pengguna yang valid mengambil tindakan tersebut untuk tujuan yang valid. Tindakan sensitif adalah tindakan, seperti penambahan peran dengan hak dilindungi, yang dapat merusak bisnis Anda jika pelaku kejahatan melakukan tindakan tersebut. Gunakan Cloud Logging untuk melihat, memantau, dan mengkueri log Cloud Platform Tindakan Sensitif. Anda juga dapat melihat entri log tindakan sensitif dengan Sensitive Actions Service, layanan bawaan Security Command Center Premium.

Chronicle dapat menyimpan dan menganalisis semua data keamanan Anda secara terpusat. Untuk membantu Anda melihat keseluruhan rentang serangan, Chronicle dapat memetakan log ke model umum, memperkayanya, lalu menautkannya bersama ke dalam linimasa. Selain itu, Anda dapat menggunakan Chronicle untuk membuat aturan deteksi, menyiapkan indikator pencocokan penyusupan (IoC), dan melakukan aktivitas perburuan ancaman. Anda menulis aturan deteksi dalam bahasa YARA-L. Untuk contoh aturan deteksi ancaman di YARA-L, lihat repositori Analisis Keamanan Komunitas (CSA). Selain menulis aturan sendiri, Anda dapat memanfaatkan deteksi yang diseleksi di Chronicle. Deteksi pilihan ini adalah sekumpulan aturan YARA-L yang telah ditetapkan dan terkelola yang dapat membantu Anda mengidentifikasi ancaman.

Opsi lain untuk memusatkan log untuk analisis, audit, dan investigasi keamanan adalah menggunakan BigQuery. Di BigQuery, Anda dapat memantau ancaman atau kesalahan konfigurasi umum menggunakan kueri SQL (misalnya yang ada di repositori CSA) untuk menganalisis perubahan izin, aktivitas penyediaan, penggunaan workload, akses data, dan aktivitas jaringan. Untuk informasi selengkapnya tentang analisis log keamanan di BigQuery dari penyiapan melalui analisis, lihat Analisis log keamanan di Google Cloud.

Diagram berikut menunjukkan cara memusatkan pemantauan menggunakan kemampuan deteksi ancaman bawaan Security Command Center dan deteksi ancaman yang Anda lakukan di BigQuery, Chronicle, atau SIEM pihak ketiga singkat ini.

Seperti yang ditunjukkan dalam diagram, ada berbagai sumber data keamanan yang harus Anda pantau. Sumber data ini mencakup log dari Cloud Logging, perubahan aset dari Inventaris Aset Cloud, log Google Workspace, atau peristiwa dari hypervisor atau kernel tamu. Diagram menunjukkan bahwa Anda dapat menggunakan Security Command Center untuk memantau sumber data ini. Pemantauan ini terjadi secara otomatis asalkan Anda telah mengaktifkan fitur dan detektor ancaman yang sesuai di Security Command Center. Diagram ini menunjukkan bahwa Anda juga dapat memantau ancaman dengan mengekspor data keamanan dan temuan Security Command Center ke alat analisis seperti BigQuery,Chronicle, atau SIEM pihak ketiga. Pada alat analisis, diagram menunjukkan bahwa Anda dapat melakukan analisis dan investigasi lebih lanjut dengan menggunakan dan memperluas kueri dan aturan seperti yang tersedia di CSA.

Langkah selanjutnya

Pelajari logging dan deteksi lebih lanjut dengan referensi berikut:

• Cloud Logging

• Memperkenalkan Chronicle Detect dari Google Cloud

• Membangun proses manajemen insiden kolaboratif

Framework Arsitektur Google Cloud: Keandalan

Kategori dalam Framework Arsitektur Google Cloud menunjukkan cara merancang dan mengoperasikan layanan yang andal di platform cloud. Anda juga akan mempelajari beberapa produk dan fitur Google Cloud yang mendukung keandalan.

Framework Arsitektur menjelaskan praktik terbaik, menyediakan rekomendasi implementasi, dan menjelaskan beberapa produk dan layanan yang tersedia. Framework ini bertujuan untuk membantu Anda mendesain deployment Google Cloud agar sesuai dengan kebutuhan bisnis Anda.

Untuk menjalankan layanan yang andal, arsitektur Anda harus menyertakan hal-hal berikut:

• Sasaran keandalan yang terukur, dengan penyimpangan yang segera Anda perbaiki.
• Desain pola untuk skalabilitas, ketersediaan tinggi, pemulihan dari bencana (disaster recovery), dan manajemen perubahan otomatis.
• Komponen yang dapat melakukan pemulihan mandiri jika memungkinkan, dan memberi kode yang mencakup instrumentasi untuk kemampuan observasi.
• Prosedur operasional yang menjalankan layanan dengan pekerjaan manual dan beban kognitif minimal pada operator, serta yang memungkinkan Anda mendeteksi dan memitigasi kegagalan dengan cepat.

Keandalan adalah tanggung jawab semua orang di bagian teknik, seperti tim pengembangan, pengelolaan produk, operasi, dan tim reliability engineering (SRE). Setiap orang harus bertanggung jawab dan memahami target keandalan aplikasi mereka, serta anggaran risiko dan error. Tim harus dapat memprioritaskan pekerjaan dengan tepat dan mengeskalasi konflik prioritas antara keandalan dan pengembangan fitur produk.

Dalam kategori keandalan Framework Arsitektur, Anda akan mempelajari cara melakukan hal-hal berikut:

• Memahami prinsip keandalan inti
• Tentukan sasaran keandalan Anda
• Menentukan SLO
• Mengadopsi SLO
• Bangun kemampuan observasi ke dalam infrastruktur dan aplikasi Anda
• Mendesain skala dan ketersediaan tinggi
• Menciptakan alat dan proses operasional yang andal
• Membuat pemberitahuan yang efisien
• Membangun proses manajemen insiden kolaboratif

Prinsip keandalan

Dokumen dalam Framework Arsitektur ini menjelaskan beberapa prinsip inti untuk menjalankan layanan yang andal di platform cloud. Prinsip-prinsip ini membantu menciptakan pemahaman umum saat Anda membaca bagian tambahan dari Framework Arsitektur yang menunjukkan cara beberapa produk dan fitur Google Cloud mendukung layanan yang andal.

Terminologi utama

Ada beberapa istilah umum yang terkait dengan praktik keandalan. Informasi ini mungkin tidak asing bagi banyak pembaca. Namun, untuk mengingat kembali, lihat deskripsi mendetail di halaman Terminologi.

Prinsip inti

Pendekatan Google terkait keandalan didasarkan pada prinsip-prinsip inti berikut.

Keandalan adalah fitur utama Anda

Fitur produk baru terkadang menjadi prioritas utama Anda dalam jangka pendek. Namun, keandalan merupakan fitur produk utama Anda dalam jangka panjang, sebab jika produk terlalu lambat atau tidak tersedia dalam jangka waktu yang lama, pengguna mungkin akan pergi, sehingga fitur produk lainnya tidak relevan.

Keandalan ditentukan oleh pengguna

Ukur pengalaman pengguna untuk workload yang dihadapi pengguna. Pengguna harus puas dengan performa layanan Anda. Misalnya, ukur rasio keberhasilan permintaan pengguna, bukan hanya metrik server seperti penggunaan CPU.

Untuk workload batch dan streaming, Anda mungkin perlu mengukur indikator performa utama (KPI) untuk throughput data, seperti baris yang dipindai per jangka waktu, bukan metrik server seperti penggunaan disk. KPI Throughput dapat membantu memastikan laporan harian atau kuartalan yang diperlukan oleh pengguna untuk selesai tepat waktu.

Keandalan 100% adalah target yang salah

Sistem Anda harus cukup dapat diandalkan sehingga pengguna puas, tetapi tidak terlalu dapat diandalkan sehingga investasinya tidak adil. Tentukan SLO yang menetapkan batas keandalan yang Anda inginkan, lalu gunakan anggaran error untuk mengelola tingkat perubahan yang sesuai.

Terapkan prinsip desain dan operasional dalam framework ini ke produk hanya jika SLO untuk produk atau aplikasi tersebut membenarkan biayanya.

Keandalan dan Inovasi cepat saling melengkapi

Gunakan anggaran error untuk mencapai keseimbangan antara stabilitas sistem dan ketangkasan developer. Panduan berikut membantu Anda menentukan kapan harus bergerak cepat atau lambat:

• Jika anggaran error yang memadai tersedia, Anda dapat berinovasi dengan cepat dan meningkatkan produk atau menambahkan fitur produk.
• Saat anggaran error berkurang, perlambat dan fokuskan pada fitur keandalan.

Prinsip desain dan operasional

Untuk memaksimalkan keandalan sistem, prinsip desain dan operasional berikut berlaku. Setiap prinsip ini dibahas secara mendetail dalam kategori keandalan Framework Arsitektur lainnya.

Tentukan sasaran keandalan Anda

Praktik terbaik yang dibahas pada bagian Framework Arsitektur ini meliputi:

• Pilih SLI yang sesuai.
• Tetapkan SLO berdasarkan pengalaman pengguna.
• Meningkatkan SLO secara iteratif.
• Gunakan SLO internal yang ketat.
• Gunakan anggaran error untuk mengelola kecepatan pengembangan.

Untuk informasi selengkapnya, lihat Menentukan sasaran keandalan Anda dalam kategori keandalan Framework Arsitektur.

Build kemampuan observasi ke dalam infrastruktur dan aplikasi Anda

Prinsip desain berikut tercakup dalam bagian Framework Arsitektur ini:

• Instrumentasikan kode Anda untuk memaksimalkan kemampuan observasi.

Untuk informasi selengkapnya, lihat Mem-build kemampuan observasi ke dalam infrastruktur dan aplikasi Anda dalam kategori keandalan Framework Arsitektur.

Mendesain skala dan ketersediaan tinggi

Prinsip desain berikut tercakup dalam bagian Framework Arsitektur ini:

• Buat redundansi untuk ketersediaan yang lebih tinggi.
• Replikasi data di seluruh region untuk pemulihan dari bencana.
• Desain arsitektur multi-region untuk ketahanan terhadap gangguan layanan regional.
• Hilangkan hambatan skalabilitas.
• Turunkan tingkat layanan dengan baik saat kelebihan beban.
• Cegah dan kurangi lonjakan traffic.
• Bersihkan dan validasi input.
• Fail Safe dengan tetap mempertahankan fungsi sistem.
• Desain panggilan API dan perintah agar dapat dicoba lagi.
• Identifikasi dan kelola dependensi sistem.
• Minimalkan dependensi kritis.
• Pastikan setiap perubahan dapat diroll back.

Untuk informasi selengkapnya, lihat Mendesain untuk skala dan ketersediaan tinggi dalam kategori keandalan Framework Arsitektur.

Menciptakan alat dan proses operasional yang andal

Prinsip operasional berikut tercakup di bagian Framework Arsitektur ini:

• Pilih nama yang bagus untuk aplikasi dan layanan.
• Terapkan peluncuran progresif dengan prosedur pengujian canary.
• Sebarkan traffic untuk promosi dan peluncuran dengan waktu.
• Otomatiskan proses build, pengujian, dan deployment.
• Bertahan dari error operator.
• Uji prosedur pemulihan kegagalan.
• Lakukan uji pemulihan dari bencana.
• Praktikkan rekayasa kekacauan.

Untuk informasi selengkapnya, lihat Membuat proses dan alat operasional yang andal dalam kategori keandalan Framework Arsitektur.

Membuat Pemberitahuan yang efisien

Prinsip operasional berikut tercakup di bagian Framework Arsitektur ini:

• Optimalkan penundaan pemberitahuan.
• Buat pemberitahuan untuk gejala, bukan penyebab.
• Buat pemberitahuan untuk pencilan, bukan rata-rata.

Untuk informasi selengkapnya, lihat Membuat pemberitahuan yang efisien dalam kategori keandalan Framework Arsitektur.

Buat proses manajemen insiden kolaboratif.

Prinsip operasional berikut tercakup di bagian Framework Arsitektur ini:

• Tetapkan kepemilikan layanan yang jelas.
• Kurangi waktu untuk mendeteksi (TTD) dengan Pemberitahuan yang disetel dengan baik.
• Kurangi waktu untuk memitigasi (TTM) dengan rencana manajemen insiden dan pelatihan.
• Desain tata letak dasbor dan konten untuk meminimalkan TTM.
• Dokumentasikan prosedur dan mitigasi diagnostik untuk skenario gangguan layanan yang diketahui.
• Gunakan postmortem blameless untuk belajar dari gangguan dan mencegah pengulangan.

Untuk informasi selengkapnya, lihat Membangun proses manajemen insiden kolaboratif dalam kategori keandalan Framework Arsitektur.

Langkah selanjutnya

• Tentukan sasaran keandalan Anda (dokumen berikutnya dalam seri ini)

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, keamanan, privasi, dan kepatuhan.

Tentukan sasaran keandalan Anda

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk menentukan cara yang tepat untuk mengukur pengalaman pelanggan atas layanan Anda, sehingga Anda dapat menjalankan layanan yang andal. Anda akan mempelajari cara melakukan iterasi pada tujuan tingkat layanan (SLO) yang Anda tentukan, dan menggunakan anggaran error untuk mengetahui kapan keandalan dapat menurun jika Anda merilis update tambahan.

Pilih SLI yang sesuai

Penting untuk memilih indikator tingkat layanan (SLI) yang tepat untuk sepenuhnya memahami performa layanan Anda. Misalnya, jika aplikasi Anda memiliki arsitektur multi-tenant yang khas dari aplikasi SaaS yang digunakan oleh beberapa pelanggan independen, tangkap SLI pada tingkat per tenant. Jika SLI Anda hanya diukur pada tingkat agregat global, Anda mungkin melewatkan masalah kritis dalam aplikasi yang memengaruhi satu pelanggan penting atau sebagian kecil pelanggan. Sebagai gantinya, desain aplikasi Anda agar menyertakan ID tenant dalam setiap permintaan pengguna, lalu menyebarkan ID tersebut melalui setiap lapisan stack. Dengan ID ini, sistem pemantauan Anda dapat menggabungkan statistik pada tingkat per tenant di setiap lapisan atau microservice di sepanjang jalur permintaan.

Jenis layanan yang Anda jalankan juga menentukan SLI yang akan dipantau, seperti yang ditunjukkan pada contoh berikut.

Sistem penayangan

SLI berikut umum digunakan dalam sistem yang menyalurkan data:

• Ketersediaan menunjukkan persentase waktu penggunaan layanan. Persentase ini sering kali didefinisikan dalam persentase permintaan yang dibuat dengan baik yang berhasil, seperti 99%.
• Latensi memberi tahu Anda seberapa cepat persentase permintaan tertentu dapat terpenuhi. Persentase ini sering kali ditentukan dalam persentil selain ke-50, seperti "persentil ke-99 pada 300 md".
• Kualitas menunjukkan seberapa baik respons tertentu. Definisi kualitas sering kali bersifat spesifik per layanan, dan menunjukkan sejauh mana konten respons terhadap permintaan bervariasi dari konten respons yang ideal. Kualitas respons dapat berupa biner (baik atau buruk) atau dinyatakan dalam skala dari 0% hingga 100%.

Sistem pemrosesan data

SLI berikut umum digunakan dalam sistem yang memproses data:

• Cakupan memberi tahu Anda fraksi data yang telah diproses, seperti 99,9%.
• Koreksi memberi tahu Anda fraksi data output yang dianggap benar, seperti 99,99%.
• Keaktualan menunjukkan seberapa baru data sumber atau data output gabungan. Biasanya, semakin baru diperbarui, semakin baik, misalnya 20 menit.
• Throughput menunjukkan jumlah data yang diproses, seperti 500 MiB/dtk atau bahkan 1.000 permintaan per detik (RPS).

Sistem penyimpanan

SLI berikut umum digunakan dalam sistem yang menyimpan data:

• Ketahanan memberi tahu Anda seberapa besar kemungkinan data yang ditulis ke sistem dapat diambil di masa mendatang, seperti 99,9999%. Setiap insiden kehilangan data permanen akan mengurangi metrik ketahanan.
• Throughput dan latensi juga merupakan SLI yang umum untuk sistem penyimpanan.

Pilih SLI dan tetapkan SLO berdasarkan pengalaman pengguna

Salah satu prinsip inti dalam bagian Framework Arsitektur ini adalah bahwa keandalan ditentukan oleh pengguna. Ukur metrik keandalan sedekat mungkin dengan pengguna, seperti opsi berikut:

• Jika memungkinkan, instrumentasikan klien seluler atau web.
  • Misalnya, gunakan Firebase Performance Monitoring untuk mendapatkan insight tentang karakteristik performa aplikasi iOS, Android, dan web Anda.
• Jika tidak memungkinkan, instrumentasikan load balancer.
  • Misalnya, gunakan Cloud Monitoring untuk logging dan pemantauan Load Balancer Aplikasi eksternal.
• Ukuran keandalan di server harus menjadi opsi terakhir.
  • Misalnya, memantau instance Compute Engine dengan Cloud Monitoring.

Tetapkan SLO Anda cukup tinggi sehingga hampir semua pengguna puas dengan layanan Anda, tidak lebih tinggi. Karena konektivitas jaringan atau masalah sisi klien sementara lainnya, pelanggan Anda mungkin tidak melihat masalah keandalan singkat pada aplikasi Anda, sehingga Anda dapat menurunkan SLO.

Untuk waktu beroperasi dan metrik vital lainnya, targetkan target yang lebih rendah dari 100%, tetapi mendekatinya. Pemilik layanan harus secara objektif menilai tingkat minimum performa dan ketersediaan layanan yang akan membuat sebagian besar pengguna senang, bukan hanya menetapkan target berdasarkan tingkat kontrak eksternal.

Tingkat perubahan yang Anda lakukan memengaruhi keandalan sistem. Namun, kemampuan untuk melakukan perubahan kecil yang sering dilakukan akan membantu Anda menghadirkan fitur lebih cepat dan dengan kualitas lebih tinggi. Sasaran keandalan yang dapat dicapai yang disesuaikan dengan pengalaman pelanggan membantu menentukan kecepatan dan cakupan maksimum perubahan (kecepatan fitur) yang dapat ditoleransi oleh pelanggan.

Jika tidak dapat mengukur pengalaman pelanggan dan menentukan sasaran terkait hal tersebut, Anda dapat menjalankan analisis tolok ukur kompetitif. Jika tidak ada persaingan yang dapat dibandingkan, ukur pengalaman pelanggan, bahkan jika Anda belum dapat menentukan tujuan. Misalnya, ukur ketersediaan sistem atau tingkat transaksi yang bermakna dan berhasil bagi pelanggan. Anda dapat menghubungkan data ini dengan metrik bisnis atau KPI seperti volume pesanan retail atau volume panggilan dan tiket dukungan pelanggan, serta tingkat keparahannya. Selama jangka waktu tertentu, Anda dapat menggunakan latihan korelasi tersebut untuk mencapai ambang batas kebahagiaan pelanggan yang wajar. Nilai minimum ini adalah SLO Anda.

Tingkatkan SLO secara iteratif

SLO tidak boleh bersifat permanen. Tinjau kembali SLO setiap tiga bulan, atau setidaknya setiap tahun, dan pastikan bahwa SLO terus mencerminkan kepuasan pengguna dan berhubungan baik dengan pemadaman layanan. Pastikan keduanya mencakup kebutuhan bisnis saat ini dan perjalanan penting pengguna yang baru. Revisi dan tingkatkan SLO Anda sesuai kebutuhan setelah peninjauan berkala ini.

Gunakan SLO internal yang ketat

Ini adalah praktik yang baik untuk memiliki SLO internal yang lebih ketat daripada SLA eksternal. Karena pelanggaran SLA cenderung mengharuskan penerbitan kredit keuangan atau pengembalian dana pelanggan, Anda ingin mengatasi masalah sebelum menimbulkan dampak finansial.

Sebaiknya gunakan SLO internal yang lebih ketat ini dengan proses postmortem dan peninjauan insiden tanpa menyalahkan. Untuk mengetahui informasi selengkapnya, lihat Membangun proses manajemen insiden kolaboratif dalam kategori keandalan Architecture Center.

Gunakan anggaran error untuk mengelola kecepatan pengembangan.

Anggaran error memberi tahu Anda apakah sistem Anda lebih atau kurang dapat diandalkan daripada yang diperlukan selama jangka waktu tertentu. Anggaran error dihitung sebagai 100% – SLO selama jangka waktu tertentu, misalnya 30 hari.

Jika memiliki sisa kapasitas pada anggaran error, Anda dapat terus meluncurkan peningkatan atau fitur baru dengan cepat. Jika anggaran error mendekati nol, bekukan atau perlambat perubahan layanan, dan investasikan resource engineering untuk meningkatkan fitur keandalan.

Kemampuan Observasi Google Cloud mencakup pemantauan SLO untuk meminimalkan upaya penyiapan SLO dan anggaran error. Layanan ini mencakup antarmuka pengguna grafis (GUI) untuk membantu Anda mengonfigurasi SLO secara manual, API untuk penyiapan SLO terprogram, dan dasbor bawaan untuk melacak laju pengeluaran anggaran error. Untuk informasi selengkapnya, lihat cara membuat SLO.

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, ikuti rekomendasi berikut:

• Menentukan dan mengukur SLI yang berfokus pada pelanggan, seperti ketersediaan atau latensi layanan.
• Tetapkan anggaran error yang berfokus pada pelanggan yang lebih ketat dibandingkan SLA eksternal Anda. Sertakan konsekuensi atas pelanggaran, seperti pembekuan produksi.
• Siapkan SLI latensi untuk mengambil nilai pencilan, seperti persentil ke-90 atau ke-99, untuk mendeteksi respons paling lambat.
• Tinjau SLO setidaknya setiap tahun dan konfirmasi bahwa SLO tersebut berkorelasi baik dengan kebahagiaan pengguna dan pemadaman layanan.

Langkah selanjutnya

Pelajari lebih lanjut cara menentukan sasaran keandalan dengan referensi berikut:

• Bangun kemampuan observasi ke dalam infrastruktur dan aplikasi Anda (dokumen berikutnya dalam seri ini)
• Coursera - SRE: Mengukur dan Mengelola Keandalan
• SRE bab buku SRE dan workbook SRE untuk mengimplementasikan SLO
• Menyesuaikan metrik SLI Anda

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Menentukan SLO

Dokumen ini adalah Bagian 1 dari dua bagian yang menunjukkan bagaimana tim yang mengoperasikan layanan online dapat mulai membangun dan mengadopsi budaya Site Reliability Engineering (SRE) menggunakan tujuan tingkat layanan (SLO). SLO adalah target tingkat keandalan untuk sebuah layanan.

Dalam software as a service (SaaS), ada ketegangan alami antara kecepatan pengembangan produk dan stabilitas operasional. Semakin sering Anda mengubah sistem, semakin besar kemungkinan rusak. Alat pemantauan dan kemampuan observasi dapat membantu Anda mempertahankan keyakinan terhadap stabilitas operasional saat Anda meningkatkan velositas pengembangan. Namun, meskipun alat tersebut—yang juga disebut sebagai alat pengelolaan performa aplikasi (APM)—penting, salah satu penerapan terpenting alat ini adalah dalam penyetelan SLO.

Jika ditentukan dengan benar, SLO dapat membantu tim membuat keputusan operasional berdasarkan data yang meningkatkan kecepatan pengembangan tanpa mengorbankan stabilitas. SLO juga dapat menyelaraskan tim pengembangan dan operasi berdasarkan satu tujuan yang disepakati, yang dapat mengurangi ketegangan alami yang ada di antara tujuan mereka—membuat dan melakukan iterasi produk (pengembangan) serta memelihara integritas sistem (operasi).

SLO dijelaskan secara mendetail dalam Buku SRE dan Workbook SRE, bersama praktik SRE lainnya. Rangkaian ini mencoba menyederhanakan proses memahami dan mengembangkan SLO agar Anda dapat mengadopsinya dengan lebih mudah. Setelah Anda membaca dan memahami artikel ini, Anda dapat menemukan artikel lain di buku-buku.

Rangkaian ini bertujuan untuk menunjukkan jalur yang jelas untuk menerapkan SLO di organisasi Anda:

• Dokumen ini meninjau pengertian SLO dan cara menentukannya untuk layanan Anda.
• Mengadopsi SLO mencakup berbagai jenis SLO berdasarkan jenis workload, cara mengukur SLO tersebut, dan cara mengembangkan pemberitahuan berdasarkan SLO.

Seri ini ditujukan untuk SRE, tim operasi, DevOps, administrator sistem, dan orang-orang yang bertanggung jawab atas stabilitas dan keandalan layanan online. Hal ini mengasumsikan bahwa Anda memahami cara layanan internet berkomunikasi dengan browser web dan perangkat seluler, dan memiliki pemahaman dasar tentang cara layanan web dipantau, di-deploy, dan menangani masalah.

Laporan State of DevOps mengidentifikasi kemampuan yang mendorong performa pengiriman software. Serial ini akan membantu Anda dengan kemampuan berikut:

• Kemampuan observasi dan pemantauan
• Sistem pemantauan untuk melandasi keputusan bisnis
• Notifikasi kegagalan proaktif

Mengapa SLO?

Saat Anda membangun budaya SRE, mengapa memulainya dengan SLO? Singkatnya, jika Anda tidak menentukan tingkat layanan, akan sulit untuk mengukur apakah pelanggan puas dengan layanan Anda. Meskipun Anda tahu bahwa Anda dapat meningkatkan kualitas layanan, kurangnya tingkat layanan yang ditetapkan akan menyulitkan Anda untuk menentukan di mana dan berapa banyak yang harus diinvestasikan dalam peningkatan.

Anda mungkin ingin mengembangkan SLO terpisah untuk setiap layanan, baik yang ditampilkan kepada pengguna maupun tidak. Misalnya, kesalahan umum adalah mengukur dua layanan atau lebih secara terpisah—misalnya, layanan frontend dan datastore backend—saat pengguna mengandalkan keduanya dan tidak menyadari perbedaannya. Pendekatan yang lebih baik adalah mengembangkan SLO yang didasarkan pada produk (kumpulan layanan) dan berfokus pada interaksi paling penting yang dialami pengguna dengan produk tersebut.

Oleh karena itu, untuk mengembangkan SLO yang efektif, sebaiknya Anda memahami interaksi pengguna dengan layanan Anda, yang disebut perjalanan penting pengguna (CUJ). CUJ mempertimbangkan tujuan pengguna, dan cara pengguna menggunakan layanan Anda untuk mencapai tujuan tersebut. CUJ didefinisikan dari perspektif pelanggan Anda tanpa mempertimbangkan batas layanan. Jika CUJ terpenuhi, pelanggan puas, dan pelanggan yang puas adalah kunci utama keberhasilan untuk suatu layanan.

Aspek kunci untuk kepuasan pelanggan dengan layanan adalah keandalan layanan. Tidak masalah apa yang dilakukan layanan jika tidak dapat diandalkan. Dengan demikian, keandalan adalah fitur terpenting dari setiap layanan. Metrik umum untuk keandalan adalah waktu beroperasi, yang secara konvensional berarti jumlah waktu suatu sistem telah aktif. Namun, kami memilih metrik yang lebih membantu dan akurat: ketersediaan. Ketersediaan masih menjawab pertanyaan apakah sistem aktif, tetapi dengan cara yang lebih akurat, bukan dengan mengukur waktu sejak sistem tidak aktif. Dalam sistem terdistribusi saat ini, layanan dapat mengalami gangguan sebagian, suatu faktor yang menyebabkan waktu beroperasi tidak bekerja dengan baik.

Ketersediaan sering dijelaskan dalam bentuk sembilan—seperti 99,9% tersedia (tiga sembilan), atau 99,99% tersedia (empat sembilan). Mengukur ketersediaan SLO adalah salah satu cara terbaik untuk mengukur keandalan sistem Anda.

Selain membantu menentukan keberhasilan operasional, SLO dapat membantu Anda memilih tempat untuk menginvestasikan resource. Misalnya, buku SRE sering kali mencatat bahwa setiap sembilan yang Anda rancang dapat menghasilkan biaya inkremental dengan utilitas marginal. Secara umum, diketahui bahwa mencapai sembilan berikutnya akan menimbulkan biaya ketersediaan sepuluh kali lebih tinggi dari sebelumnya.

Pilih SLI

Untuk menentukan apakah SLO terpenuhi (artinya, berhasil), Anda memerlukan pengukuran. Pengukuran tersebut disebut indikator tingkat layanan (SLI). SLI mengukur tingkat layanan tertentu yang diberikan kepada pelanggan Anda. Idealnya, SLI terikat dengan CUJ yang diterima.

Pilih metrik terbaik

Langkah pertama dalam mengembangkan SLI adalah memilih metrik yang akan diukur, seperti permintaan per detik, error per detik, panjang antrean, distribusi kode respons selama jangka waktu tertentu, atau jumlah byte ditransmisikan.

Metrik tersebut cenderung berupa jenis berikut:

• Counter. Misalnya, jumlah error yang terjadi hingga titik pengukuran tertentu. Jenis metrik ini dapat meningkat tetapi tidak dapat mengalami penurunan.
• Distribusi. Misalnya, jumlah peristiwa yang mengisi segmen pengukuran tertentu selama jangka waktu tertentu. Anda mungkin perlu mengukur banyaknya permintaan yang memerlukan waktu 0-10 md untuk diselesaikan, yang memerlukan waktu 11-30 md, dan yang memerlukan waktu 31-100 md. Hasilnya adalah jumlah untuk setiap bucket—misalnya, [0-10: 50], [11-30: 220], [31-100: 1103].
• Meteran. Misalnya, nilai sebenarnya dari bagian sistem yang dapat diukur (seperti panjang antrean). Jenis metrik ini dapat meningkat atau menurun.

Untuk mengetahui informasi selengkapnya tentang jenis ini, lihat dokumentasi project Prometheus dan jenis metrik Cloud Monitoring ValueType dan MetricKind.

Perbedaan penting tentang SLI adalah tidak semua metrik merupakan SLI. Bahkan, Workbook SRE menyatakan hal berikut (penekanan ditambahkan):

"...biasanya kami merekomendasikan untuk memperlakukan SLI sebagai rasio dua angka: jumlah peristiwa yang baik dibagi dengan jumlah total peristiwa..."

"SLI berkisar dari 0% hingga 100%, dengan 0% berarti tidak ada yang berfungsi, dan 100% berarti tidak ada yang rusak. Kami menganggap skala ini intuitif, dan gaya ini mudah cocok dengan konsep anggaran error."

Banyak perusahaan software melacak ratusan atau ribuan metrik; hanya sedikit metrik yang memenuhi syarat sebagai SLI. Jadi, selain rasio peristiwa yang baik terhadap total peristiwa, apa yang menentukan metrik memenuhi syarat sebagai SLI yang baik? Metrik SLI yang baik memiliki karakteristik sebagai berikut:

• Metrik ini berhubungan langsung dengan kepuasan pengguna. Umumnya, pengguna tidak akan puas jika layanan tidak berperilaku seperti yang mereka harapkan, gagal, atau lambat. Setiap SLO berdasarkan metrik ini dapat divalidasi dengan membandingkan SLI Anda dengan sinyal kepuasan pengguna lainnya—misalnya, jumlah tiket keluhan pelanggan, volume panggilan dukungan, sentimen media sosial, atau eskalasi. Jika metrik Anda tidak sesuai dengan metrik kepuasan pengguna lainnya, metrik tersebut mungkin bukan metrik yang baik untuk digunakan sebagai SLI.
• Penurunan metrik berkorelasi dengan pemadaman layanan. Metrik yang terlihat bagus selama pemadaman layanan adalah metrik yang salah untuk SLI. Metrik yang terlihat buruk selama operasi normal juga merupakan metrik yang salah untuk SLI.
• Metrik ini memberikan rasio sinyal terhadap noise yang baik. Setiap metrik yang menghasilkan negatif palsu atau positif palsu dalam jumlah besar bukanlah SLI yang baik.
• Metrik ini diskalakan secara monoton, dan kurang lebih secara linear, dengan kepuasan pelanggan. Seiring dengan meningkatnya metrik, kepuasan pelanggan juga meningkat.

Pertimbangkan grafik dalam diagram berikut. Dua metrik yang dapat digunakan sebagai SLI untuk layanan ditampilkan grafik dari waktu ke waktu. Periode saat penurunan layanan ditandai dengan warna merah, dan periode saat layanan baik ditandai dengan warna biru.

Dalam kasus SLI yang buruk, ketidakpuasan pengguna tidak berhubungan langsung dengan peristiwa negatif (seperti penurunan layanan, kelambatan, atau pemadaman layanan). Selain itu, SLI berfluktuasi berdasarkan tingkat kepuasan pengguna. Dengan SLI yang baik, SLI dan kepuasan pengguna berkorelasi, tingkat kepuasan yang berbeda terlihat jelas, dan jumlah fluktuasi yang tidak relevan jauh lebih sedikit.

Pilih jumlah metrik yang tepat

Biasanya, satu layanan memiliki beberapa SLI, terutama jika layanan tersebut melakukan berbagai jenis pekerjaan atau melayani jenis pengguna yang berbeda. Misalnya, memisahkan permintaan baca dari permintaan tulis adalah ide yang bagus, karena permintaan ini cenderung memiliki cara yang berbeda. Dalam hal ini, sebaiknya pilih metrik yang sesuai untuk setiap layanan.

Sebaliknya, banyak layanan melakukan jenis pekerjaan serupa di seluruh layanan, yang dapat dibandingkan secara langsung. Misalnya, jika Anda memiliki marketplace online, pengguna dapat melihat halaman beranda, melihat subkategori atau daftar 10 teratas, melihat halaman detail, atau menelusuri item. Daripada mengembangkan dan mengukur SLI terpisah untuk setiap tindakan ini, Anda dapat menggabungkannya ke dalam satu kategori SLI—misalnya, layanan jelajah.

Pada kenyataannya, harapan pengguna tidak banyak berubah di antara tindakan dari kategori serupa. Tingkat kepuasan mereka tidak bergantung pada struktur data yang dijelajahi, apakah data tersebut berasal dari daftar statis item yang dipromosikan atau merupakan hasil pencarian secara dinamis dari penelusuran berbantuan machine learning di seluruh dataset yang besar. Kepuasan pengguna dapat diukur dengan jawaban atas pertanyaan: "Apakah saya melihat item sehalaman penuh dengan cepat?"

Idealnya, Anda perlu menggunakan sesedikit mungkin SLI untuk menunjukkan toleransi suatu layanan secara akurat. Biasanya, sebuah layanan harus memiliki antara dua hingga enam SLI. Jika memiliki terlalu sedikit SLI, Anda dapat kehilangan sinyal yang berharga. Jika Anda memiliki terlalu banyak SLI, tim siaga Anda memiliki terlalu banyak hal untuk dilacak dengan hanya utilitas tambahan marginal. Ingat, SLI harus menyederhanakan pemahaman Anda terkait kondisi produksi dan memberikan gambaran cakupan.

Pilih SLO

SLO terdiri dari nilai-nilai berikut:

• SLI. Misalnya, rasio jumlah respons dengan kode HTTP 200 terhadap jumlah total respons.
• Durasi. Jangka waktu saat metrik diukur. Periode ini dapat berbasis kalender (misalnya, dari hari pertama suatu bulan hingga hari pertama berikutnya) atau periode berkelanjutan (misalnya, 30 hari terakhir).
• Target. Misalnya, persentase target peristiwa yang baik terhadap total peristiwa (seperti 99,9%) yang Anda harapkan akan dipenuhi selama durasi tertentu.

Saat Anda mengembangkan SLO, menentukan durasi dan target bisa jadi sulit. Salah satu cara untuk memulai proses ini adalah dengan mengidentifikasi SLI dan membuat diagramnya dari waktu ke waktu. Jika Anda tidak dapat menentukan durasi dan target yang akan digunakan, ingat bahwa SLO Anda tidak harus langsung sempurna. Anda mungkin perlu melakukan iterasi pada SLO untuk memastikannya selaras dengan kepuasan pelanggan dan memenuhi kebutuhan bisnis Anda. Anda dapat mencoba memulai dengan dua sembilan (99,0%) selama satu bulan.

Saat melacak kepatuhan SLO selama peristiwa seperti deployment, pemadaman, dan pola traffic harian, Anda bisa mendapatkan insight tentang target mana yang baik, buruk, atau bahkan masih dapat ditoleransi. Misalnya, dalam proses latar belakang, Anda dapat menetapkan 75% keberhasilan sebagai memadai. Namun, untuk permintaan yang sangat penting dan ditampilkan kepada pengguna, sebaiknya Anda menargetkan sesuatu yang lebih agresif, seperti 99,95%.

Tentu saja, tidak ada SLO yang dapat Anda terapkan untuk setiap kasus penggunaan. SLO bergantung pada beberapa faktor:

• ekspektasi pelanggan
• jenis workload
• infrastruktur untuk inferensi, eksekusi, dan pemantauan
• domain permasalahan

Bagian 2 dalam seri ini, Mengadopsi SLO, berfokus pada SLO yang tidak bergantung domain. SLO domain independen (seperti ketersediaan layanan) tidak menggantikan indikator tingkat tinggi (seperti widget yang dijual per menit). Namun, metrik ini dapat membantu mengukur apakah layanan berfungsi, terlepas dari kasus penggunaan bisnisnya.

Indikator domain-independen sering kali dapat dikurangi menjadi pertanyaan‐misalnya, "Apakah layanan tersedia?" atau "Apakah layanannya cukup cepat?" Jawabannya paling sering ditemukan pada SLO yang memperhitungkan dua faktor: ketersediaan dan latensi. Anda dapat menjelaskan SLO dalam istilah berikut, di mana X = 99,9% dan Y = 800 md:

X% permintaan yang valid berhasil dan berhasil lebih cepat daripada Y md.

Apa langkah selanjutnya?

• Baca Mengadopsi SLO, yang mempelajari definisi ini secara lebih mendetail dan memperkenalkan SLI lain yang mungkin lebih sesuai untuk berbagai jenis workload.
• Lihat referensi SRE lainnya:
  • Buku SRE
  • Workbook SRE
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.
• Baca referensi kami tentang DevOps.
• Pelajari lebih lanjut kemampuan DevOps yang terkait dengan rangkaian ini:
  • Kemampuan observasi dan pemantauan
  • Sistem pemantauan untuk melandasi keputusan bisnis
  • Notifikasi kegagalan proaktif
• Lakukan pemeriksaan cepat DevOps untuk memahami posisi Anda dibandingkan dengan industri lainnya.

Mengadopsi SLO

Dokumen ini menjelaskan beberapa tujuan tingkat layanan (SLO) yang berguna untuk berbagai jenis workload layanan umum. Dokumen ini adalah Bagian 2 dari dua bagian. Bagian 1, Menentukan SLO, memperkenalkan SLO, menunjukkan cara SLO berasal dari indikator tingkat layanan (SLI), dan menjelaskan apa yang membuat SLO yang baik.

Laporan State of DevOps mengidentifikasi kemampuan yang mendorong performa pengiriman software. Kedua dokumen ini akan membantu Anda dengan kemampuan berikut:

• Kemampuan observasi dan pemantauan
• Sistem pemantauan untuk melandasi keputusan bisnis
• Notifikasi kegagalan proaktif

Apa yang harus diukur

Terlepas dari domain Anda, banyak layanan memiliki fitur yang sama dan dapat menggunakan SLO umum. Pembahasan berikut tentang SLO umum diatur menurut jenis layanan dan memberikan penjelasan mendetail tentang SLI yang berlaku untuk setiap SLO.

Layanan berdasarkan permintaan

Layanan berdasarkan permintaan menerima permintaan dari klien (layanan lain atau pengguna), melakukan beberapa komputasi, mungkin mengirimkan permintaan jaringan ke backend, lalu menampilkan respons ke klien. Layanan berdasarkan permintaan paling sering diukur berdasarkan SLI ketersediaan dan latensi.

Ketersediaan sebagai SLI

SLI untuk ketersediaan menunjukkan apakah layanan berfungsi. SLI untuk ketersediaan ditentukan sebagai berikut:

Proporsi permintaan valid yang berhasil ditayangkan.

Anda harus terlebih dahulu mendefinisikan valid. Beberapa definisi dasar dapat berupa "tidak panjang nol" atau "mematuhi protokol klien-server", tetapi pemilik layanan bebas menentukan apa yang dimaksud dengan valid ini. Metode umum untuk mengukur validitas adalah dengan menggunakan kode respons HTTP (atau RPC). Misalnya, kita sering menganggap error HTTP 500 sebagai error server yang dihitung terhadap SLO, sedangkan error 400 adalah error klien yang tidak dihitung.

Setelah memutuskan hal yang akan diukur, Anda perlu memeriksa setiap kode respons yang ditampilkan oleh sistem untuk memastikan bahwa aplikasi menggunakan kode tersebut dengan benar dan konsisten. Saat menggunakan kode error untuk SLO, penting untuk menanyakan apakah sebuah kode merupakan indikator akurat dari pengalaman pengguna terhadap layanan Anda. Misalnya, jika pengguna mencoba memesan item yang stoknya habis, apakah situs rusak dan menampilkan pesan error, atau apakah situs tersebut menyarankan produk serupa? Untuk digunakan dengan SLO, kode error harus dikaitkan dengan ekspektasi pengguna.

Developer dapat menyalahgunakan error. Jika pengguna meminta produk yang stoknya habis untuk sementara, developer mungkin secara keliru memprogram error agar ditampilkan. Namun, sistem tersebut sebenarnya berfungsi dengan benar dan bukan error. Kode harus ditampilkan sebagai berhasil, meskipun pengguna tidak dapat membeli item yang mereka inginkan. Tentu saja, pemilik layanan ini perlu mengetahui bahwa stok produk habis, tetapi ketidakmampuan untuk melakukan penjualan bukanlah kesalahan dari sudut pandang pelanggan dan seharusnya tidak diperhitungkan terhadap SLO. Namun, jika layanan tidak dapat terhubung ke database untuk menentukan apakah item tersebut tersedia, ini adalah error yang mengurangi anggaran error Anda.

Layanan Anda mungkin lebih kompleks. Misalnya, mungkin layanan Anda menangani konten asinkron atau menyediakan proses yang berjalan lama untuk pelanggan. Dalam kasus ini, Anda mungkin menampilkan ketersediaan dengan cara lain. Namun, sebaiknya tetap mewakili ketersediaan sebagai proporsi permintaan valid yang berhasil. Anda dapat mendefinisikan ketersediaan sebagai jumlah menit saat workload pelanggan berjalan seperti yang diminta. (Pendekatan ini terkadang disebut sebagai metode "menit yang baik" untuk mengukur ketersediaan.) Untuk virtual machine, Anda dapat mengukur ketersediaan dalam proporsi menit setelah permintaan awal untuk VM yang mana VM dapat diakses melalui SSH.

Latensi sebagai SLI

SLI untuk latensi (terkadang disebut kecepatan) menunjukkan apakah layanan cukup cepat. SLI untuk latensi didefinisikan mirip dengan ketersediaan:

Proporsi permintaan valid yang ditayangkan lebih cepat daripada nilai minimum.

Anda dapat mengukur latensi dengan menghitung perbedaan antara saat timer dimulai dan berhenti untuk jenis permintaan tertentu. Kuncinya adalah persepsi pengguna terhadap latensi. Kesalahan umumnya adalah pengukuran latensi yang terlalu presisi. Pada kenyataannya, pengguna tidak dapat membedakan antara refresh 100 milidetik (md) dan refresh 300 md, serta dapat menerima titik apa pun antara 300 milidetik dan 1000 milidetik.

Sebagai gantinya, sebaiknya kembangkan metrik yang berfokus pada aktivitas yang menjaga fokus pengguna, misalnya, dalam proses berikut:

• Interaktif: 1.000 md untuk waktu pengguna menunggu hasil setelah mengklik elemen.
• Menulis: 1500 md untuk mengubah sistem terdistribusi yang mendasarinya. Meskipun durasi waktu ini dianggap lambat untuk sistem, pengguna cenderung menerimanya. Sebaiknya Anda membedakan antara operasi tulis dan baca secara eksplisit dalam metrik Anda.
• Latar belakang: 5.000 md untuk tindakan yang tidak terlihat oleh pengguna, seperti pemuatan ulang data secara berkala atau konten asinkron lainnya.

Latensi biasanya diukur sebagai distribusi (lihat Memilih SLI di Bagian 1 dari seri ini). Dengan mempertimbangkan distribusi, Anda dapat mengukur berbagai persentil. Misalnya, Anda mungkin mengukur jumlah permintaan yang lebih lambat daripada persentil ke-99 historis. Dalam hal ini, kita menganggap peristiwa yang baik sebagai peristiwa yang lebih cepat dari nilai minimum ini, yang ditetapkan dengan memeriksa distribusi historis. Anda juga dapat menetapkan nilai minimum ini berdasarkan persyaratan produk. Anda bahkan dapat menetapkan beberapa SLO latensi, misalnya latensi standar versus latensi tail.

Sebaiknya jangan hanya menggunakan latensi rata-rata (atau median) sebagai SIP Anda. Menemukan bahwa latensi median terlalu lambat berarti setengah dari pengguna sudah tidak puas. Dengan kata lain, Anda dapat memiliki latensi buruk selama berhari-hari sebelum menemukan ancaman nyata bagi anggaran error jangka panjang Anda. Oleh karena itu, sebaiknya tentukan SLO untuk latensi tail (persentil ke-95) dan untuk latensi median (persentil ke-50).

Dalam artikel ACM Metrics That Matter, Benjamin Treynor Sloss menulis hal berikut:

"Aturan praktis yang baik ... adalah bahwa latensi persentil ke-99 tidak boleh lebih dari tiga hingga lima kali latensi median."

Treynor Sloss melanjutkan:

"Kami mendapati bahwa ukuran latensi persentil ke-50, ke-95, dan ke-99 untuk setiap layanan masing-masing berharga secara individual, dan idealnya kami akan menetapkan SLO untuk setiap layanan tersebut."

Model yang bagus untuk diikuti adalah menentukan batas latensi berdasarkan persentil historis, lalu mengukur jumlah permintaan yang masuk ke setiap bucket. Untuk mengetahui detail selengkapnya, lihat bagian tentang pemberitahuan latensi nanti dalam dokumen ini.

Kualitas sebagai bagian SLI

Kualitas adalah SLI yang berguna untuk layanan kompleks yang dirancang untuk gagal secara wajar dengan melakukan downgrade saat dependensi lambat atau tidak tersedia. SLI untuk kualitas ditentukan sebagai berikut:

Proporsi permintaan valid yang ditayangkan tanpa penurunan layanan.

Misalnya, halaman web mungkin memuat konten utamanya dari satu datastore dan memuat aset opsional tambahan dari 100 layanan dan datastore lainnya. Jika satu layanan opsional tidak aktif atau terlalu lambat, halaman masih dapat dirender tanpa elemen tambahan. Dengan mengukur jumlah permintaan yang disalurkan respons yang buruk (yaitu, respons yang tidak memiliki setidaknya satu respons layanan backend), Anda dapat melaporkan rasio permintaan yang buruk. Anda bahkan dapat melacak jumlah respons kepada pengguna yang tidak memiliki respons dari satu backend, atau respons dari beberapa backend yang hilang.

Layanan pemrosesan data

Beberapa layanan tidak dibuat untuk merespons permintaan pengguna, tetapi menggunakan data dari input, memproses data tersebut, dan menghasilkan output. Performa layanan ini pada langkah menengah tidak sepenting hasil akhir. Dengan layanan seperti ini, SLI terkuat Anda adalah keaktualan, cakupan, ketepatan, dan throughput, bukan latensi dan ketersediaan.

Keaktualan sebagai bagian SLI

SLI untuk keaktualan ditentukan sebagai berikut:

Proporsi data valid yang diperbarui lebih baru daripada nilai minimum.

Misalnya, dalam sistem batch processing, keaktualan dapat diukur sebagai waktu yang berlalu sejak proses berhasil diselesaikan untuk output tertentu. Dalam sistem pemrosesan yang lebih kompleks atau real-time, Anda dapat melacak usia data terbaru yang diproses dalam pipeline.

Misalnya, bayangkan sebuah game online yang membuat ubin peta secara real time. Pengguna mungkin tidak menyadari seberapa cepat ubin peta dibuat, tetapi mereka mungkin menyadari saat data peta tidak ada atau tidak baru.

Atau, pertimbangkan sistem yang membaca data dari sistem pelacakan yang tersedia untuk menghasilkan pesan "Item X tersedia" untuk situs e-commerce. Anda dapat menentukan SLI untuk keaktualan sebagai berikut:

Persentase penayangan yang menggunakan informasi saham yang diperbarui dalam satu menit terakhir.

Anda juga dapat menggunakan metrik untuk menayangkan data non-baru sebagai informasi yang menentukan SLI untuk mengetahui kualitas.

Cakupan sebagai SLI

SLI untuk cakupan ditentukan sebagai berikut:

Proporsi data valid yang berhasil diproses.

Untuk menentukan cakupan, pertama-tama Anda harus menentukan apakah akan menerima input sebagai valid atau melewatinya. Misalnya, jika catatan input rusak atau panjang nol dan tidak dapat diproses, Anda dapat menganggap catatan tersebut tidak valid untuk mengukur sistem Anda.

Selanjutnya, Anda menghitung jumlah catatan yang valid. Anda dapat melakukan langkah ini dengan metode count() sederhana atau metode lain. Angka ini adalah total jumlah catatan Anda.

Terakhir, untuk membuat SLI untuk cakupan, Anda menghitung jumlah data yang berhasil diproses dan membandingkannya dengan total jumlah catatan yang valid.

Ketepatan sebagai bagian SLI

SLI untuk ketepatan ditentukan sebagai berikut:

Proporsi data valid yang menghasilkan output benar.

Dalam beberapa kasus, ada metode untuk menentukan ketepatan output yang dapat digunakan untuk memvalidasi pemrosesan output. Misalnya, sistem yang memutar atau mewarnai gambar tidak boleh menghasilkan gambar zero-byte, atau gambar dengan panjang atau lebar nol. Penting untuk memisahkan logika validasi ini dari logika pemrosesan itu sendiri.

Salah satu metode untuk mengukur SLI kebenaran adalah dengan menggunakan data input pengujian yang diketahui bagus, yaitu data yang memiliki output benar yang diketahui. Data input harus mewakili data pengguna. Dalam kasus lain, pemeriksaan matematis atau logika dapat dilakukan terhadap output, seperti dalam contoh sebelumnya tentang memutar gambar. Contoh lain mungkin adalah sistem penagihan yang menentukan validitas sebuah transaksi dengan memeriksa apakah perbedaan antara saldo sebelum transaksi dan saldo setelah transaksi sama dengan nilai transaksi itu sendiri.

Throughput sebagai bagian SLI

SLI untuk throughput ditentukan sebagai berikut:

Proporsi waktu ketika kecepatan pemrosesan data lebih cepat dari batas.

Dalam sistem pemrosesan data, throughput sering kali lebih mewakili kebahagiaan pengguna daripada, misalnya, pengukuran latensi tunggal untuk bagian pekerjaan tertentu. Misalnya, jika ukuran setiap input sangat bervariasi, mungkin tidak masuk akal untuk membandingkan waktu yang diperlukan untuk menyelesaikan setiap elemen jika tugas berlangsung pada kecepatan yang dapat diterima.

Byte per detik adalah cara umum untuk mengukur jumlah pekerjaan yang diperlukan untuk memproses data, terlepas dari ukuran set data. Namun, metrik apa pun yang kira-kira diskalakan secara linear sehubungan dengan biaya pemrosesan dapat berfungsi.

Mungkin akan bermanfaat untuk mempartisi sistem pemrosesan data Anda berdasarkan tingkat throughput yang diharapkan, atau menerapkan sistem kualitas layanan untuk memastikan bahwa input prioritas tinggi ditangani dan input prioritas rendah dimasukkan ke dalam antrean. Apa pun itu, mengukur throughput seperti yang ditentukan di bagian ini dapat membantu Anda menentukan apakah sistem berfungsi seperti yang diharapkan.

Layanan eksekusi terjadwal

Untuk layanan yang perlu melakukan tindakan pada interval yang teratur, seperti cron job Kubernetes, Anda dapat mengukur skew dan durasi eksekusi. Berikut adalah contoh cron job Kubernetes terjadwal:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Skew sebagai bagian SLI

Sebagai SLI, skew didefinisikan sebagai berikut:

Proporsi eksekusi yang dimulai dalam jangka waktu yang dapat diterima dari waktu mulai yang diharapkan.

Skew mengukur perbedaan waktu antara kapan tugas dijadwalkan untuk dimulai dan saat tugas itu dimulai. Misalnya, jika cron job Kubernetes sebelumnya, yang disiapkan untuk dimulai pada menit nol setiap jam, dimulai pada tiga menit setelah satu jam, maka kemiringannya adalah tiga menit. Saat pekerjaan berjalan lebih awal, Anda memiliki bias negatif.

Anda dapat mengukur kemiringan sebagai distribusi dari waktu ke waktu, dengan rentang sesuai yang dapat diterima dan menentukan kemiringan yang baik. Untuk menentukan SLI, Anda perlu membandingkan jumlah operasi yang berada dalam rentang yang baik.

Durasi eksekusi sebagai SLI

Sebagai SLI, durasi eksekusi ditentukan sebagai berikut:

Proporsi eksekusi yang selesai dalam jangka waktu durasi yang dapat diterima.

Durasi eksekusi adalah waktu yang diperlukan untuk menyelesaikan tugas. Untuk eksekusi tertentu, mode kegagalan yang umum adalah agar durasi sebenarnya melebihi durasi yang dijadwalkan.

Salah satu kasus yang menarik adalah cara menerapkan SLI ini untuk menangkap tugas yang tidak pernah berakhir. Karena tugas ini tidak selesai, Anda perlu mencatat waktu yang dihabiskan pada pekerjaan tertentu, bukan menunggu tugas selesai. Pendekatan ini memberikan distribusi yang akurat tentang waktu yang diperlukan untuk menyelesaikan pekerjaan, bahkan dalam skenario terburuk.

Seperti halnya kemiringan, Anda dapat melacak durasi eksekusi sebagai distribusi dan menentukan batas atas dan bawah yang dapat diterima untuk peristiwa yang baik.

Jenis metrik untuk sistem lainnya

Banyak workload lain memiliki metriknya sendiri yang dapat Anda gunakan untuk menghasilkan SLI dan SLO. Perhatikan contoh berikut:

• Sistem penyimpanan: ketahanan, throughput, waktu ke byte pertama, ketersediaan blob
• Media/video: kontinuitas pemutaran klien, waktu untuk memulai pemutaran, transcode kelengkapan eksekusi grafik
• Game: saatnya mencocokkan pemain aktif, saatnya membuat peta

Cara mengukur

Setelah mengetahui hal yang diukur, Anda dapat memutuskan cara melakukan pengukuran. Anda dapat mengumpulkan SLI dengan beberapa cara.

Logging sisi server

Metode untuk membuat SLI

Memproses log permintaan sisi server atau data yang diproses.

Pertimbangan

Kelebihan:

• Log yang sudah ada dapat diproses ulang untuk mengisi ulang data SLI historis.
• Pengidentifikasi sesi lintas layanan dapat merekonstruksi perjalanan pengguna yang kompleks di berbagai layanan.

Kekurangan:

• Permintaan yang tidak sampai di server tidak akan dicatat.
• Permintaan yang menyebabkan server error mungkin tidak dicatat.
• Lamanya waktu untuk memproses log dapat menyebabkan SLI yang tidak berlaku lagi, yang mungkin menjadi data yang tidak memadai untuk respons operasional.
• Menulis kode untuk memproses log bisa menjadi tugas yang rentan error dan memakan waktu.

Metode dan alat implementasi:

• BigQuery
• Dataflow, Apache Spark
• Splunk

Metrik server aplikasi

Metode untuk membuat SLI

Mengekspor metrik SLI dari kode yang melayani permintaan dari pengguna atau memproses data mereka.

Pertimbangan

Keuntungan:

• Menambahkan metrik baru ke kode biasanya cepat dan murah.

Kekurangan:

• Permintaan yang tidak sampai ke server aplikasi tidak akan dicatat.
• Permintaan multi-layanan mungkin sulit dilacak.

Metode dan alat implementasi:

• Cloud Monitoring
• Prometheus
• Produk APM pihak ketiga

Metrik infrastruktur frontend

Metode untuk membuat SLI

Memanfaatkan metrik dari infrastruktur load balancing (misalnya, load balancer Lapisan 7 global Google Cloud).

Pertimbangan

Kelebihan:

• Metrik dan data historis sering kali sudah ada, sehingga mengurangi upaya engineer untuk memulai.
• Pengukuran diambil pada titik yang paling dekat dengan pelanggan, tetapi masih dalam infrastruktur penayangan.

Kekurangan:

• Tidak valid untuk SLI pemrosesan data.
• Hanya dapat memperkirakan perjalanan pengguna multi-permintaan.

Metode dan alat implementasi:

• Cloud Monitoring
• Metrik CDN/LB atau Reporting API (Cloudflare, Akamai, Fastly)

Klien atau data sintetis

Metode untuk membuat SLI

Membuat klien yang mengirim permintaan buatan secara berkala dan memvalidasi respons. Untuk pipeline pemrosesan data, membuat data input sintetis yang terkenal dan bagus dan memvalidasi output.

Pertimbangan

Kelebihan:

• Mengukur semua langkah perjalanan pengguna multi-permintaan.
• Mengirim permintaan dari luar infrastruktur Anda menangkap lebih banyak jalur permintaan secara keseluruhan di SLI.

Kekurangan:

• Memperkirakan pengalaman pengguna dengan permintaan sintetis, yang mungkin menyesatkan (baik positif palsu maupun negatif palsu).
• Mencakup semua corner case sulit dan dapat berubah menjadi pengujian integrasi.
• Target keandalan tinggi memerlukan pemeriksaan yang sering untuk pengukuran yang akurat.
• Menyelidiki lalu lintas dapat menutupi lalu lintas yang sebenarnya.

Metode dan alat implementasi:

• Cek uptime Cloud Monitoring
• Solusi open source:
  • Cloudprober
  • blackbox_exporter
• Solusi vendor:
  • Pemantauan Sintetis Catchpoint
  • Sintetis New Relic
  • Pemantauan Sintetis Datadog

Instrumentasi klien

Metode untuk membuat SLI

Menambahkan fitur kemampuan observasi ke klien yang berinteraksi dengan pengguna, dan mencatat kembali peristiwa ke infrastruktur penyaluran Anda yang melacak SLI.

Pertimbangan

Kelebihan:

• Memberikan ukuran pengalaman pengguna yang paling akurat.
• Dapat mengukur keandalan pihak ketiga, misalnya, CDN atau penyedia pembayaran.

Kekurangan:

• Penyerapan log klien dan latensi pemrosesan membuat SLI ini tidak cocok untuk memicu respons operasional.
• Pengukuran SLI akan berisi sejumlah faktor yang sangat bervariasi yang kemungkinan berada di luar kontrol langsung.
• Membangun instrumentasi ke klien dapat melibatkan banyak pekerjaan teknik.

Metode dan alat implementasi:

• Google Analytics, Firebase
• Analisis pengguna: Amplitude dan alat serupa
• Pemantauan seluler/frontend: New Relic Browser, Raygun Real User Monitoring, Sentry
• Klien kustom dan server kustom untuk merekam dan melacak

Pilih metode pengukuran

Idealnya, pilih metode pengukuran yang paling sesuai dengan pengalaman pelanggan terkait layanan Anda dan menuntut upaya paling sedikit dari pihak Anda. Untuk mencapai ideal ini, Anda mungkin perlu menggunakan kombinasi metode-metode dalam tabel sebelumnya. Berikut adalah pendekatan yang disarankan yang dapat Anda terapkan dari waktu ke waktu, yang dicantumkan dalam urutan peningkatan upaya:

1. Menggunakan ekspor server aplikasi dan metrik infrastruktur. Biasanya, Anda dapat langsung mengakses metrik ini, dan metrik tersebut akan memberikan nilai dengan cepat. Beberapa alat APM menyertakan alat SLO bawaan.
2. Menggunakan instrumentasi klien. Karena sistem lama biasanya tidak memiliki instrumentasi klien pengguna akhir bawaan, penyiapan instrumentasi mungkin memerlukan investasi yang signifikan. Namun, jika menggunakan suite APM atau framework frontend yang menyediakan instrumentasi klien, Anda dapat dengan cepat mendapatkan insight tentang kepuasan pelanggan.
3. Menggunakan pemrosesan log. Jika Anda tidak dapat menerapkan ekspor server atau instrumentasi klien, tetapi log masih ada, mungkin pemrosesan log adalah nilai terbaik Anda. Pendekatan lainnya adalah menggabungkan ekspor dan pemrosesan log, menggunakan ekspor sebagai sumber langsung untuk beberapa SLI (seperti ketersediaan langsung) dan pemrosesan log untuk sinyal jangka panjang (seperti pemberitahuan lambat yang akan dibahas nanti dalam panduan SLO dan Pemberitahuan).
4. Menerapkan pengujian sintetis. Setelah memiliki pemahaman dasar tentang cara pelanggan menggunakan layanan, Anda menguji tingkat layanan. Misalnya, Anda dapat melakukan seed akun pengujian dengan data yang diketahui berkualitas dan membuat kueri untuk akun tersebut. Pengujian ini dapat membantu menandai mode kegagalan yang sulit diamati, seperti dalam kasus layanan dengan traffic rendah.

Tetapkan tujuan

Salah satu cara terbaik untuk menetapkan tujuan adalah dengan membuat dokumen bersama yang menjelaskan SLO Anda dan cara Anda mengembangkannya. Tim Anda dapat melakukan iterasi pada dokumen saat mengimplementasikan dan melakukan iterasi pada SLO dari waktu ke waktu.

Sebaiknya pemilik bisnis, pemilik produk, dan eksekutif meninjau dokumen ini. Pemangku kepentingan tersebut dapat menawarkan insight tentang harapan layanan dan kompromi keandalan produk Anda.

Untuk perjalanan penting pengguna (CUJ) perusahaan Anda yang paling penting, berikut ini template untuk mengembangkan SLO:

1. Pilih spesifikasi SLI (misalnya, ketersediaan atau keaktualan).
2. Tentukan cara menerapkan spesifikasi SLI.
3. Baca rencana Anda untuk memastikan bahwa CUJ Anda tercakup.
4. Tetapkan SLO berdasarkan performa atau kebutuhan bisnis sebelumnya.

CUJ tidak boleh dibatasi pada satu layanan, maupun terbatas pada satu tim atau organisasi pengembangan. Jika pengguna Anda bergantung pada ratusan microservice yang beroperasi pada tingkat 99,5%, tetapi tidak ada yang melacak ketersediaan secara menyeluruh, pelanggan Anda kemungkinan tidak akan puas.

Misalkan Anda memiliki kueri yang bergantung pada lima layanan yang berfungsi secara berurutan: load balancer, frontend, mixer, backend, dan database.

Jika setiap komponen memiliki ketersediaan 99,5%, ketersediaan terburuk yang ditampilkan kepada pengguna adalah sebagai berikut:

99.5% * 99.5% * 99.5% * 99.5% * 99.5% = 97.52%

Ini adalah ketersediaan terburuk yang dilihat pengguna karena keseluruhan sistem gagal jika salah satu dari lima layanan gagal. Hal ini hanya akan berlaku jika semua lapisan stack harus selalu tersedia untuk menangani setiap permintaan pengguna, tanpa faktor ketahanan seperti percobaan ulang perantara, cache, atau antrean. Sistem dengan pengaitan erat antarlayanan merupakan desain yang buruk dan menentang model microservice.

Hanya mengukur performa terhadap SLO sistem yang terdistribusi dengan cara yang tidak konsisten ini (layanan berdasarkan layanan) tidak mencerminkan pengalaman pelanggan secara akurat dan dapat menyebabkan interpretasi yang terlalu sensitif.

Sebagai gantinya, Anda harus mengukur performa terhadap SLO di frontend untuk memahami apa yang dialami pengguna. Pengguna tidak peduli jika layanan komponen gagal, yang menyebabkan kueri secara otomatis dan berhasil dicoba ulang, jika kueri pengguna masih berhasil. Jika Anda telah membagikan layanan internal, layanan ini dapat mengukur performa secara terpisah terhadap SLO-nya, dengan layanan yang ditampilkan kepada pengguna bertindak sebagai pelanggan mereka. Anda harus menangani SLO ini secara terpisah dari satu sama lain.

Anda dapat membuat layanan dengan ketersediaan tinggi (misalnya, 99,99%) di atas layanan yang kurang tersedia (misalnya, 99,9%) menggunakan faktor ketahanan seperti percobaan ulang cerdas, caching, dan antrean singkat ini.

Sebagai aturan umum, siapa pun yang memiliki pengetahuan statistik yang memadai harus dapat membaca dan memahami SLO Anda tanpa memahami layanan atau tata letak organisasi yang mendasarinya.

Contoh lembar kerja SLO

Saat mengembangkan SLO, ingatlah untuk melakukan hal-hal berikut:

• Pastikan SLI Anda menentukan peristiwa, kriteria keberhasilan, serta tempat dan cara Anda mencatat keberhasilan atau kegagalan.
• Tentukan spesifikasi SLI dalam hal proporsi peristiwa yang baik.
• Pastikan SLO Anda menentukan tingkat target dan jendela pengukuran.
• Jelaskan kelebihan dan kekurangan pendekatan Anda agar pihak yang tertarik dapat memahami kelebihan dan kekurangan pendekatan tersebut.

Misalnya, perhatikan lembar kerja SLO berikut.

CUJ: Pemuatan halaman beranda

Jenis SLI: Latensi Spesifikasi SIP: Proporsi permintaan halaman beranda yang ditayangkan dalam waktu kurang dari 100 milidetik Implementasi SLI: Proporsi permintaan halaman beranda yang ditayangkan dalam waktu kurang dari 100 milidetik yang diukur dari kolom latensi log server. (Kelemahan: Pengukuran ini tidak menyertakan permintaan yang gagal mencapai backend.) Proporsi permintaan halaman beranda yang ditayangkan dalam waktu kurang dari 100 milidetik sebagaimana diukur oleh prober yang mengeksekusi JavaScript di browser yang berjalan di mesin virtual. (Kelebihan dan kekurangan: Pengukuran ini mendeteksi error saat permintaan tidak dapat menjangkau jaringan tetapi mungkin melewatkan masalah yang hanya memengaruhi sebagian pengguna.) SLO: 99% permintaan halaman beranda dalam 28 hari terakhir ditayangkan dalam waktu kurang dari 100 milidetik

Catatan: Jika sebagai tim Anda tidak dapat menyepakati level target, pilih beberapa level dan setujui untuk membukanya kembali dalam enam bulan. Memilih nomor yang salah lebih baik daripada tidak memilih nomor.

Apa langkah selanjutnya?

• Baca The Art of SLOs, workshop yang dikembangkan oleh tim Customer Reliability Engineering Google.
• Cobalah Site Reliability Engineering: Mengukur dan Mengelola Keandalan, kursus online tentang cara membangun SLO.
• Baca Site Reliability Engineering: Menerapkan SLO.
• Baca Konsep dalam pemantauan layanan.
• Baca tentang mengembangkan SLO dengan Cloud Monitoring.
• Cobalah SLO Generator yang fleksibel dari Professional Services Organization (PSO) Google.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.
• Baca referensi kami tentang DevOps.
• Pelajari lebih lanjut kemampuan DevOps yang terkait dengan rangkaian ini:
  • Kemampuan observasi dan pemantauan
  • Sistem pemantauan untuk melandasi keputusan bisnis
  • Notifikasi kegagalan proaktif
• Lakukan pemeriksaan cepat DevOps untuk memahami posisi Anda dibandingkan dengan industri lainnya.

Terminologi

Dokumen ini memberikan definisi umum untuk istilah terkait SLO yang digunakan di bagian Framework Arsitektur Google Cloud: Keandalan.

• tingkat layanan: pengukuran seberapa baik layanan tertentu melakukan pekerjaan yang diharapkan pengguna. Anda dapat mendeskripsikan pengukuran ini dari segi kebahagiaan pengguna dan mengukurnya dengan berbagai metode, bergantung pada apa yang dilakukan layanan dan apa yang diharapkan pengguna untuk dilakukan atau diberi tahu dapat dilakukan.

  Contoh: "Pengguna mengharapkan layanan kami tersedia dan cepat".

• perjalanan penting pengguna (CUJ): sekumpulan interaksi yang dilakukan pengguna dengan layanan untuk mencapai satu sasaran—misalnya, satu klik atau pipeline multi-langkah.

  Contoh: "Pengguna mengklik checkout button dan menunggu respons bahwa keranjang diproses dan tanda terima ditampilkan".

• indikator tingkat layanan (SLI): ukuran kebahagiaan pengguna yang dapat diukur secara kuantitatif untuk tingkat layanan. Dengan kata lain, untuk mengukur tingkat layanan, Anda harus mengukur indikator yang menunjukkan kepuasan pengguna atas tingkat layanan tersebut—misalnya, ketersediaan layanan. SLI dapat dianggap sebagai garis pada grafik yang berubah dari waktu ke waktu, seiring peningkatan atau penurunan layanan. Ini cenderung menjadi radio "baik" / "total" yang dinyatakan sebagai persentase tanpa unit. Dengan menggunakan persentase ini secara konsisten, tim dapat memahami SLI tanpa pengetahuan mendalam tentang penerapannya

  Contoh: "Ukur jumlah permintaan yang berhasil dalam 10 menit terakhir dibagi dengan jumlah semua permintaan yang valid dalam 10 menit terakhir".

• tujuan tingkat layanan (SLO): tingkat yang Anda harapkan akan dicapai oleh layanan hampir sepanjang waktu dan yang digunakan untuk mengukur SLI.

  Contoh: "Respons layanan lebih cepat dari 400 milidetik (md) untuk 95% dari semua permintaan valid yang diukur selama 14 hari".

  

• perjanjian tingkat layanan (SLA): deskripsi mengenai hal yang harus terjadi jika SLO tidak terpenuhi. Secara umum, SLA adalah perjanjian hukum antara penyedia dan pelanggan, dan bahkan mungkin menyertakan persyaratan kompensasi. Dalam diskusi teknis tentang SRE, istilah ini sering dihindari.

  Contoh: "Jika layanan tidak memberikan ketersediaan 99,95% selama satu bulan kalender, penyedia layanan memberikan kompensasi kepada pelanggan untuk setiap menit yang tidak dipatuhi".

• anggaran error: berapa banyak waktu atau jumlah peristiwa negatif yang dapat Anda tahan sebelum melanggar SLO. Pengukuran ini memberi tahu Anda berapa banyak error yang dapat terjadi atau ditoleransi oleh bisnis Anda. Anggaran error sangat penting dalam membantu Anda membuat keputusan yang berpotensi berisiko.

  Contoh: "Jika SLO kami 99,9% tersedia, kami mengizinkan 0,1% dari permintaan kami untuk menayangkan error, baik melalui insiden, kecelakaan, atau eksperimen."

SLO dan pemberitahuan

Dokumen di bagian Framework Arsitektur Google Cloud: Keandalan ini memberikan detail tentang pemberitahuan terkait SLO.

Pendekatan yang keliru untuk memperkenalkan sistem kemampuan observasi baru seperti SLO adalah dengan menggunakan sistem tersebut untuk sepenuhnya mengganti sistem sebelumnya. Sebaliknya, Anda akan melihat SLO sebagai sistem pelengkap. Misalnya, daripada menghapus pemberitahuan yang sudah ada, sebaiknya jalankan pemberitahuan tersebut secara paralel dengan pemberitahuan SLO yang diperkenalkan di sini. Dengan pendekatan ini, Anda dapat menemukan pemberitahuan lama mana yang bersifat prediktif dari pemberitahuan SLO, yang diaktifkan secara paralel dengan pemberitahuan SLO Anda, dan pemberitahuan mana yang tidak pernah diaktifkan.

Prinsip SRE adalah memberi tahu berdasarkan gejala, bukan penyebab. SLO, pada dasarnya adalah pengukuran gejala. Saat mengadopsi pemberitahuan SLO, Anda mungkin menemukan bahwa pemberitahuan gejala diaktifkan bersama pemberitahuan lainnya. Jika Anda menemukan bahwa pemberitahuan berbasis penyebab yang lama diaktifkan tanpa SLO atau gejala, hal ini sebaiknya dinonaktifkan sepenuhnya, diubah menjadi pemberitahuan tiket, atau dicatat dalam log untuk referensi di lain waktu.

Untuk informasi selengkapnya, lihat Workbook SRE, Bab 5.

Laju pengeluaran SLO

Laju pengeluaran SLO adalah pengukuran seberapa cepat pemadaman layanan mengekspos pengguna terhadap error dan menghabiskan anggaran error. Dengan mengukur laju pengeluaran, Anda dapat menentukan waktu hingga layanan melanggar SLO-nya. Pemberitahuan berdasarkan laju pengeluaran SLO adalah pendekatan yang berharga. Ingat bahwa SLO Anda didasarkan pada durasi, yang mungkin cukup lama (minggu atau bahkan bulan). Namun, tujuannya adalah untuk dengan cepat mendeteksi kondisi yang menyebabkan pelanggaran SLO sebelum pelanggaran tersebut benar-benar terjadi.

Tabel berikut menunjukkan waktu yang diperlukan untuk melampaui tujuan jika 100% permintaan gagal pada interval tertentu, dengan asumsi kueri per detik (QPS) adalah konstan. Misalnya, jika Anda memiliki SLO 99,9% yang diukur selama 30 hari, Anda dapat menahan 43,2 menit periode nonaktif penuh selama 30 hari tersebut. Misalnya, periode nonaktif dapat terjadi sekaligus, atau memerlukan beberapa insiden.

Tujuan	90 hari	30 hari	7 hari	1 hari
90%	9 hari	3 hari	16,8 jam	2,4 jam
99%	21,6 jam	7,2 jam	1,7 jam	14,4 menit
99,9%	2,2 jam	43,2 menit	10,1 menit	1,4 menit
99,99%	13 menit	4,3 menit	1 menit	8,6 detik
99,999%	1,3 menit	25,9 detik	6 detik	0,9 detik

Dalam praktiknya, Anda tidak dapat membeli insiden pemadaman 100% jika ingin mencapai persentase keberhasilan yang tinggi. Namun, banyak sistem terdistribusi yang dapat mengalami kegagalan atau menurun dengan baik. Di kasus semacam itu, Anda tetap perlu mengetahui apakah manusia perlu turun tangan, bahkan dalam kegagalan parsial. Pemberitahuan SLO memberi Anda cara untuk menentukannya.

Kapan harus memberi tahu

Pertanyaan penting adalah kapan harus bertindak berdasarkan laju pengeluaran SLO Anda. Biasanya, jika anggaran error Anda habis dalam waktu 24 jam, waktunya untuk meminta seseorang memperbaiki masalahnya sekarang.

Mengukur tingkat kegagalan tidak selalu mudah. Serangkaian error kecil mungkin terlihat mengerikan pada saat itu, tetapi ternyata hanya berlangsung sebentar dan memiliki dampak yang tidak penting pada SLO Anda. Demikian pula, jika sistem sedikit rusak dalam waktu yang lama, error ini dapat menyebabkan pelanggaran SLO.

Idealnya, tim Anda akan bereaksi terhadap sinyal ini sehingga Anda menghabiskan hampir semua anggaran error (tetapi tidak melebihinya) selama jangka waktu tertentu. Jika Anda membelanjakan terlalu banyak, Anda dapat melanggar SLO Anda. Jika pembelanjaan terlalu sedikit, Anda tidak mengambil risiko yang cukup atau mungkin akan menguras tenaga tim Anda.

Anda memerlukan cara untuk menentukan kapan sistem mengalami kerusakan yang cukup sehingga perlu intervensi oleh manusia. Bagian berikut membahas beberapa pendekatan terhadap pertanyaan tersebut.

Pengeluaran cepat

Salah satu jenis pengeluaran SLO adalah fast SLO burn karena menghabiskan anggaran error Anda dengan cepat dan menuntut Anda untuk campur tangan untuk menghindari pelanggaran SLO.

Misalnya layanan Anda beroperasi secara normal pada 1.000 kueri per detik (QPS), dan Anda ingin mempertahankan ketersediaan 99% seperti yang diukur selama tujuh hari seminggu. Anggaran error Anda adalah sekitar 6 juta error yang diizinkan (dari sekitar 600 juta permintaan). Misalnya, jika Anda memiliki waktu 24 jam sebelum anggaran error habis, batas tersebut dibatasi sekitar 70 error per detik atau 252.000 error dalam satu jam. Parameter ini didasarkan pada aturan umum bahwa insiden yang dapat di-pageable harus memakai setidaknya 1% dari anggaran error triwulanan.

Anda dapat memilih untuk mendeteksi tingkat error ini sebelum satu jam berlalu. Misalnya, setelah mengamati rasio 70 error per detik selama 15 menit, Anda dapat memutuskan untuk memanggil teknisi panggilan, seperti yang ditunjukkan dalam diagram berikut.

Idealnya, masalah akan diselesaikan sebelum Anda menghabiskan satu jam dari anggaran 24 jam Anda. Memilih untuk mendeteksi rasio ini dalam periode yang lebih singkat (misalnya, satu menit) cenderung terlalu rentan terhadap error. Jika waktu deteksi target Anda kurang dari 15 menit, jumlah ini dapat disesuaikan.

Pengeluaran lambat

Jenis laju pengeluaran lainnya adalah pengeluaran lambat. Misalkan Anda memperkenalkan bug yang memakan anggaran error mingguan pada hari kelima atau keenam, atau anggaran bulanan pada minggu kedua? Apa respons terbaik Anda?

Dalam hal ini, Anda mungkin memperkenalkan pemberitahuan slow SLO burn yang memungkinkan Anda mengetahui bahwa Anda akan menghabiskan seluruh anggaran error sebelum periode pemberitahuan berakhir. Tentu saja, pemberitahuan tersebut mungkin menampilkan banyak positif palsu (PP). Misalnya, mungkin sering ada kondisi ketika error terjadi sebentar, tetapi pada tingkat yang cepat menghabiskan anggaran error Anda. Dalam kasus ini, kondisinya adalah positif palsu (PP) karena hanya berlangsung dalam waktu singkat dan tidak mengancam anggaran error Anda dalam jangka panjang. Ingat, tujuannya bukan untuk menghilangkan semua sumber kesalahan; tetap dalam rentang yang dapat diterima agar tidak melebihi anggaran error. Sebaiknya hindari mengingatkan manusia untuk mengintervensi peristiwa yang tidak secara sah mengancam anggaran error Anda.

Sebaiknya beri tahu antrean tiket (bukan paging atau pengiriman email) untuk peristiwa pengeluaran lambat. Peristiwa pengeluaran lambat bukanlah keadaan darurat, tetapi memerlukan perhatian manusia sebelum anggaran berakhir. Pemberitahuan ini tidak boleh berupa email ke daftar tim, yang dengan cepat menjadi mengganggu jika diabaikan. Tiket harus dapat dilacak, ditetapkan, dan ditransfer. Tim harus mengembangkan laporan untuk muatan tiket, tingkat penutupan, kemampuan untuk ditindaklanjuti, dan duplikat. Tiket yang berlebihan dan tidak dapat ditindaklanjuti adalah contoh toil yang bagus.

Penggunaan pemberitahuan SLO secara tepat dapat memerlukan waktu dan bergantung pada budaya dan ekspektasi tim Anda. Ingatlah bahwa Anda dapat menyesuaikan pemberitahuan SLO dari waktu ke waktu. Anda juga dapat memiliki beberapa metode pemberitahuan, dengan berbagai jendela pemberitahuan, bergantung pada kebutuhan Anda.

Pemberitahuan latensi

Selain pemberitahuan ketersediaan, Anda juga dapat memiliki pemberitahuan latensi. Dengan SLO latensi, Anda mengukur persentase permintaan yang tidak memenuhi target latensi. Dengan model ini, Anda dapat menggunakan model pemberitahuan yang sama dengan yang digunakan untuk mendeteksi pengeluaran anggaran error yang cepat atau lambat.

Seperti yang disebutkan sebelumnya tentang SLO latensi median, sepenuhnya setengah permintaan Anda dapat keluar dari SLO. Dengan kata lain, pengguna dapat mengalami latensi buruk selama berhari-hari sebelum Anda mendeteksi dampaknya pada anggaran error jangka panjang. Sebagai gantinya, layanan harus menentukan tujuan latensi tail dan tujuan latensi standar. Sebaiknya gunakan persentil ke-90 historis untuk menentukan persentil ke-99 standar dan ke-99 untuk tail. Setelah menetapkan target ini, Anda dapat menentukan SLO berdasarkan jumlah permintaan yang Anda harapkan untuk diterima di setiap kategori latensi dan berapa banyak permintaan yang terlalu lambat. Pendekatan ini adalah konsep yang sama dengan anggaran error dan harus diperlakukan sama. Dengan demikian, Anda mungkin akan mendapatkan pernyataan seperti "90% permintaan akan ditangani dalam latensi standar dan 99,9% dalam target latensi tail". Target ini memastikan sebagian besar pengguna mengalami latensi standar dan tetap memungkinkan Anda melacak jumlah permintaan yang lebih lambat dari target latensi tail.

Beberapa layanan mungkin memiliki runtime yang diharapkan memiliki varian yang sangat tinggi. Misalnya, Anda mungkin memiliki ekspektasi performa yang sangat berbeda untuk membaca dari sistem datastore dibandingkan dengan menulis ke sistem. Daripada menghitung setiap kemungkinan harapan, Anda dapat memperkenalkan bucket performa runtime, seperti yang ditampilkan dalam tabel berikut. Pendekatan ini menganggap bahwa jenis permintaan ini dapat diidentifikasi dan telah dikategorikan ke dalam setiap bucket. Anda tidak boleh mengategorikan permintaan dengan cepat.

Situs yang ditampilkan kepada pengguna
Bucket	Runtime maksimum yang diharapkan
Melihat	1 detik
Tulis / perbarui	3 detik

Sistem pemrosesan data
Bucket	Runtime maksimum yang diharapkan
Kecil	10 detik
Sedang	1 menit
Besar	5 menit
Paling Besar	1 jam
Super Besar	8 jam

Dengan mengukur sistem seperti saat ini, Anda dapat memahami berapa lama waktu biasanya untuk menjalankan permintaan ini. Sebagai contoh, pertimbangkan sistem untuk memproses upload video. Jika video berdurasi sangat panjang, waktu pemrosesannya diperkirakan akan memakan waktu lebih lama. Kita dapat menggunakan durasi video dalam hitungan detik untuk mengategorikan pekerjaan ini ke dalam bucket, seperti yang ditampilkan dalam tabel berikut. Tabel ini mencatat jumlah permintaan per bucket serta berbagai persentil untuk distribusi runtime selama seminggu.

Durasi video	Jumlah permintaan yang diukur dalam satu minggu	10%	90%	99,95%
Kecil	0	-	-	-
Sedang	1.9 juta	864 milidetik	17 detik	86 detik
Besar	25 juta	1.8 detik	52 detik	9.6 menit
Paling Besar	4.3 juta	2 detik	43 detik	23.8 menit
Super Besar	81,000	36 detik	1.2 menit	41 menit

Dari analisis tersebut, Anda dapat memperoleh beberapa parameter untuk pemberitahuan:

• fast_typical: Maksimal 10% permintaan lebih cepat dari saat ini. Jika terlalu banyak permintaan yang lebih cepat dari waktu ini, target Anda mungkin salah, atau sesuatu tentang sistem Anda mungkin telah berubah.
• slow_typical: Setidaknya 90% permintaan lebih cepat dari saat ini. Batas ini mendorong SLO latensi utama Anda. Parameter ini menunjukkan apakah sebagian besar permintaan cukup cepat.
• slow_tail: Setidaknya 99,95% permintaan lebih cepat dari saat ini. Batas ini memastikan bahwa tidak ada terlalu banyak permintaan lambat.
• deadline: Titik saat waktu pemrosesan RPC pengguna atau latar belakang habis dan gagal (batas yang biasanya sudah di-hard code ke dalam sistem). Permintaan ini sebenarnya tidak akan lambat tetapi sebenarnya akan gagal dengan error dan sebagai gantinya dihitung terhadap SLO ketersediaan Anda.

Pedoman dalam menentukan bucket adalah menjaga bucket fast_typical, slow_typical, dan slow_tail dalam urutan magnitudo satu sama lain. Panduan ini memastikan Anda tidak memiliki bucket yang terlalu luas. Sebaiknya Anda tidak mencoba mencegah tumpang-tindih atau celah di antara bucket.

Bucket	fast_typical	slow_typical	slow_tail	deadline
Kecil	100 milidetik	1 detik	10 detik	30 seconds
Sedang	600 milidetik	6 detik	60 detik (1 menit)	300 detik
Besar	3 detik	30 seconds	300 detik (5 menit)	10 menit
Paling Besar	30 seconds	6 menit	60 menit (1 jam)	3 jam
Super Besar	5 menit	50 menit	500 menit (8 jam)	12 jam

Tindakan ini menghasilkan aturan seperti api.method: SMALL => [1s, 10s]. Dalam hal ini, sistem pelacakan SLO akan melihat permintaan, menentukan bucket-nya (mungkin dengan menganalisis nama metode atau URI-nya dan membandingkan namanya dengan tabel pencarian), lalu memperbarui statistik berdasarkan runtime permintaan tersebut. Jika perlu waktu 700 milidetik, berarti proses ini berada dalam target slow_typical. Jika 3 detik, ID ini berada dalam slow_tail. Jika berdurasi 22 detik, berarti melebihi slow_tail, tetapi belum menjadi error.

Dalam hal kepuasan pengguna, Anda dapat menganggap latensi tail yang hilang sebagai hal yang sama dengan tidak tersedia. (Artinya, responsnya sangat lambat sehingga harus dianggap sebagai kegagalan.) Oleh karena itu, sebaiknya gunakan persentase yang sama dengan yang Anda gunakan untuk ketersediaan, misalnya:

99,95% dari semua permintaan terpenuhi dalam 10 detik.

Apa yang Anda anggap sebagai latensi standar adalah terserah Anda. Beberapa tim di Google menganggap 90% sebagai target yang baik. Hal ini terkait dengan analisis Anda dan cara Anda memilih durasi untuk slow_typical. Contoh:

90% dari semua permintaan ditangani dalam 1 detik.

Pemberitahuan yang disarankan

Dengan panduan ini, tabel berikut menyertakan kumpulan dasar pemberitahuan SLO yang disarankan.

SLO	Periode pengukuran	Laju pengeluaran	Tindakan
Ketersediaan, pengeluaran cepat Latensi umum Latensi tail	Periode 1 jam	Kurang dari 24 jam menuju pelanggaran SLO	Halaman seseorang
Ketersediaan, pengeluaran lambat Latensi umum, pengeluaran lambat Latensi akhir, pengeluaran lambat	Periode 7 hari	Lebih dari 24 jam menuju pelanggaran SLO	Buat tiket

Pemberitahuan SLO adalah keterampilan yang memerlukan waktu untuk dikembangkan. Durasi di bagian ini adalah saran; Anda dapat menyesuaikannya dengan kebutuhan dan tingkat presisi. Memasukkan pemberitahuan ke periode pengukuran atau pengeluaran anggaran error mungkin akan membantu, atau Anda dapat menambahkan lapisan pemberitahuan lain antara proses pengeluaran cepat dan pengeluaran lambat.

Build kemampuan observasi ke dalam infrastruktur dan aplikasi Anda

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan praktik terbaik untuk menambahkan kemampuan observasi ke dalam layanan, sehingga Anda dapat lebih memahami performa layanan dan mengidentifikasi masalah dengan cepat. Kemampuan observasi mencakup pemantauan, logging, pelacakan, profiling, proses debug, dan sistem yang serupa.

Pemantauan merupakan dasar dari hierarki keandalan layanan dalam Buku Panduan Google SRE. Tanpa pemantauan yang tepat, Anda tidak dapat mengetahui apakah aplikasi berfungsi dengan benar.

Instrumentasikan kode Anda untuk memaksimalkan kemampuan observasi

Sistem yang dirancang dengan baik bertujuan untuk memiliki jumlah kemampuan observasi yang tepat yang dimulai pada fase pengembangannya. Jangan menunggu sampai aplikasi berada dalam produksi sebelum Anda mulai mengamatinya. Lengkapi kode Anda dan pertimbangkan panduan berikut:

• Untuk melakukan debug dan memecahkan masalah secara efisien, pikirkan entri log dan trace apa yang harus ditulis, serta metrik apa yang harus dipantau dan diekspor. Prioritaskan berdasarkan mode kegagalan yang paling mungkin atau sering terjadi dari sistem.
• Lakukan audit secara berkala dan pangkas pemantauan Anda. Menghapus dasbor, grafik, pemberitahuan, pelacakan, dan logging yang tidak digunakan atau tidak berguna untuk menghilangkan kekacauan.

Kemampuan Observasi Google Cloud menyediakan pemantauan real-time, pemantauan dan logging multi-cloud hybrid (seperti untuk AWS dan Azure), plus perekaman aktivitas, pembuatan profil, dan proses debug. Kemampuan observasi Google Cloud juga dapat menemukan dan memantau microservice yang berjalan secara otomatis di App Engine atau dalam mesh layanan seperti Istio.

Jika membuat banyak data aplikasi, Anda dapat mengoptimalkan penyerapan log peristiwa analisis berskala besar dengan BigQuery. BigQuery juga cocok untuk mempertahankan dan menganalisis data deret waktu berkardinalitas tinggi dari framework pemantauan Anda. Pendekatan ini berguna karena memungkinkan Anda menjalankan kueri arbitrer dengan biaya lebih rendah daripada mencoba mendesain pemantauan dengan sempurna sejak awal, dan memisahkan pelaporan dari pemantauan. Anda dapat membuat laporan dari data menggunakan Looker Studio atau Looker.

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, ikuti rekomendasi berikut:

• Implementasikan pemantauan lebih awal, seperti sebelum memulai migrasi atau sebelum men-deploy aplikasi baru ke lingkungan produksi.
• Membedakan antara masalah aplikasi dan masalah cloud yang mendasarinya. Gunakan Monitoring API, atau produk Cloud Monitoring lainnya dan Dasbor Status Google Cloud.
• Tentukan strategi kemampuan observasi di luar pemantauan yang mencakup pelacakan, pembuatan profil, dan proses debug.
• Bersihkan artefak kemampuan observasi yang tidak Anda digunakan atau yang tidak memberikan nilai secara rutin, seperti pemberitahuan yang tidak dapat ditindaklanjuti.
• Jika Anda menghasilkan data kemampuan observasi dalam jumlah besar, kirim peristiwa aplikasi ke sistem data warehouse seperti BigQuery.

Langkah selanjutnya

• Mendesain skala dan ketersediaan tinggi (dokumen berikutnya dalam seri ini)

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, keamanan, privasi, dan kepatuhan.

Mendesain skala dan ketersediaan tinggi

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan prinsip-prinsip desain untuk merancang layanan Anda, sehingga layanan tersebut dapat menoleransi kegagalan dan skala sebagai respons terhadap permintaan pelanggan. Layanan yang andal akan terus merespons permintaan pelanggan saat ada permintaan yang tinggi atas layanan atau saat ada aktivitas pemeliharaan. Prinsip desain keandalan dan praktik terbaik berikut harus menjadi bagian dari rencana deployment dan arsitektur sistem Anda.

Membuat redundansi untuk ketersediaan yang lebih tinggi

Sistem dengan kebutuhan keandalan tinggi tidak boleh memiliki titik kegagalan tunggal, dan resource-nya harus direplikasi ke beberapa domain gagal. Domain gagal adalah kumpulan resource yang dapat gagal secara independen, seperti instance VM, zona, atau region. Saat mereplikasi di seluruh domain gagal, Anda akan mendapatkan level ketersediaan gabungan yang lebih tinggi daripada yang dapat dicapai oleh setiap instance. Untuk informasi selengkapnya, lihat Region dan zona.

Sebagai contoh spesifik redundansi yang mungkin menjadi bagian dari arsitektur sistem Anda, untuk mengisolasi kegagalan dalam pendaftaran DNS ke masing-masing zona, gunakan nama DNS zona untuk instance pada jaringan yang sama agar dapat saling mengakses.

Desain arsitektur multi-zona dengan failover untuk ketersediaan tinggi

Jadikan aplikasi Anda tahan terhadap kegagalan di level zona dengan merancangnya untuk menggunakan kumpulan resource yang didistribusikan di beberapa zona, dengan replikasi data, load balancing, dan failover otomatis antarzona. Jalankan replika zona setiap lapisan stack aplikasi, dan hilangkan semua dependensi lintas zona dalam arsitektur.

Replikasi data di seluruh region untuk pemulihan dari bencana

Replikasikan atau arsipkan data ke region remote untuk mengaktifkan pemulihan dari bencana jika terjadi pemadaman layanan atau kehilangan data regional. Saat replikasi digunakan, pemulihan akan lebih cepat karena sistem penyimpanan di region remote sudah memiliki data yang hampir terbaru, selain kemungkinan hilangnya sejumlah kecil data karena penundaan replikasi. Saat Anda menggunakan pengarsipan berkala, bukan replikasi berkelanjutan, pemulihan dari bencana melibatkan pemulihan data dari cadangan atau arsip di region baru. Prosedur ini biasanya menyebabkan periode nonaktif layanan yang lebih lama daripada mengaktifkan replika database yang terus-menerus diupdate, dan dapat menyebabkan lebih banyak kehilangan data karena jeda waktu antara operasi pencadangan berturut-turut. Apa pun pendekatan yang digunakan, seluruh stack aplikasi harus di-deploy ulang dan dimulai di region baru, dan layanan tidak akan tersedia saat hal ini terjadi.

Untuk pembahasan mendetail tentang konsep dan teknik pemulihan dari bencana, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.

Desain arsitektur multi-region untuk ketahanan terhadap pemadaman layanan regional

Jika layanan perlu berjalan secara terus-menerus, bahkan dalam kasus yang jarang terjadi saat seluruh region gagal, desain layanan tersebut untuk menggunakan kumpulan resource komputasi yang didistribusikan di berbagai region. Menjalankan replika regional setiap lapisan stack aplikasi.

Menggunakan replikasi data di seluruh region dan failover otomatis saat satu region mengalami penurunan. Beberapa layanan Google Cloud memiliki varian multi-regional, seperti Spanner. Agar tidak terganggu oleh kegagalan regional, gunakan layanan multi-regional ini dalam desain Anda jika memungkinkan. Untuk mengetahui informasi selengkapnya tentang region dan ketersediaan layanan, lihat lokasi Google Cloud.

Pastikan tidak ada dependensi lintas region sehingga jangkauan dampak kegagalan tingkat region terbatas pada region tersebut.

Menghilangkan titik tunggal kegagalan regional, seperti database utama satu region yang dapat menyebabkan pemadaman layanan global jika tidak dapat dijangkau. Perlu diperhatikan bahwa arsitektur multi-region sering kali memerlukan biaya yang lebih mahal, jadi pertimbangkan kebutuhan bisnis dibandingkan biayanya sebelum Anda menerapkan pendekatan ini.

Untuk panduan lebih lanjut tentang cara menerapkan redundansi di seluruh domain gagal, lihat makalah survei Arsitektur Deployment untuk Aplikasi Cloud (PDF).

Menghilangkan hambatan skalabilitas.

Identifikasi komponen sistem yang tidak dapat berkembang melebihi batas resource satu VM atau satu zona. Beberapa aplikasi melakukan penskalaan secara vertikal, tempat Anda menambahkan lebih banyak core CPU, memori, atau bandwidth jaringan pada satu instance VM untuk menangani peningkatan beban. Aplikasi ini memiliki batasan ketat pada skalabilitasnya, dan Anda sering kali harus mengonfigurasinya secara manual untuk menangani pertumbuhan.

Jika memungkinkan, desain ulang komponen tersebut untuk melakukan penskalaan secara horizontal, seperti dengan sharding, atau partisi, di seluruh VM atau zona. Untuk menangani pertumbuhan traffic atau penggunaan, Anda menambahkan lebih banyak shard. Gunakan jenis VM standar yang dapat ditambahkan secara otomatis untuk menangani peningkatan beban per shard. Untuk informasi selengkapnya, lihat Pola untuk aplikasi yang skalabel dan tangguh.

Jika tidak dapat mendesain ulang aplikasi, Anda dapat mengganti komponen yang dikelola oleh Anda dengan layanan cloud terkelola sepenuhnya yang didesain untuk diskalakan secara horizontal tanpa tindakan pengguna.

Menurunkan level layanan dengan baik saat kelebihan beban

Desain layanan Anda agar dapat menoleransi kelebihan beban. Layanan harus mendeteksi kelebihan beban dan menampilkan respons berkualitas lebih rendah kepada pengguna atau menurunkan traffic sebagian, bukan gagal sepenuhnya karena kelebihan beban.

Misalnya, layanan dapat merespons permintaan pengguna dengan halaman web statis dan untuk sementara menonaktifkan perilaku dinamis yang lebih mahal untuk diproses. Perilaku ini dijelaskan dalam pola failover pemanasan dari Compute Engine ke Cloud Storage. Atau, layanan dapat mengizinkan operasi hanya baca dan menonaktifkan update data untuk sementara.

Operator harus diberi tahu untuk memperbaiki kondisi error saat layanan mengalami penurunan.

Mencegah dan mengurangi lonjakan traffic

Jangan sinkronkan permintaan lintas klien. Terlalu banyak klien yang mengirim traffic secara instan akan menyebabkan lonjakan traffic yang mungkin menyebabkan kegagalan beruntun.

Terapkan strategi mitigasi lonjakan pada sisi server seperti throttling, queueing, penghentian beban, atau pemutusan sirkuit, degradasi halus, dan memprioritaskan permintaan penting.

Strategi mitigasi pada klien mencakup throttling sisi klien dan backoff eksponensial dengan jitter.

Membersihkan dan memvalidasi input

Untuk mencegah input yang salah, acak, atau berbahaya dan menyebabkan pemadaman layanan atau pelanggaran keamanan, bersihkan dan validasi parameter input untuk API dan alat operasional. Misalnya, Apigee dan Google Cloud Armor dapat membantu melindungi dari serangan injection.

Gunakan pengujian fuzz secara teratur jika tes otomatis sengaja memanggil API dengan input acak, kosong, atau terlalu besar. Lakukan pengujian ini di lingkungan pengujian yang terisolasi.

Alat operasional harus otomatis memvalidasi perubahan konfigurasi sebelum perubahan diluncurkan, dan harus menolak perubahan jika validasi gagal.

Fail safe dengan tetap mempertahankan fungsi

Jika terjadi kegagalan karena suatu masalah, komponen sistem akan gagal dengan cara yang memungkinkan keseluruhan sistem untuk terus berfungsi. Masalah ini dapat berupa bug software, input atau konfigurasi yang buruk, pemadaman instance yang tidak direncanakan, atau error manusia. Proses layanan Anda akan membantu menentukan apakah Anda harus terlalu permisif atau terlalu sederhana, bukan terlalu ketat.

Pertimbangkan contoh skenario berikut dan cara merespons kegagalan:

• Biasanya lebih baik jika komponen firewall dengan konfigurasi yang buruk atau kosong tidak terbuka dan memungkinkan traffic jaringan yang tidak sah melewati dalam waktu singkat sementara operator memperbaiki error tersebut. Perilaku ini membuat layanan tetap tersedia, bukan mengalami kegagalan tertutup dan memblokir 100% traffic. Layanan harus mengandalkan pemeriksaan autentikasi dan otorisasi yang lebih dalam pada stack aplikasi untuk melindungi area sensitif saat semua traffic melewatinya.
• Namun, sebaiknya komponen server izin yang mengontrol akses ke data pengguna gagal ditutup dan memblokir semua akses. Perilaku ini menyebabkan pemadaman layanan saat konfigurasinya rusak, tetapi menghindari risiko kebocoran data rahasia pengguna jika gagal dibuka.

Dalam kedua kasus tersebut, kegagalan akan memunculkan pemberitahuan berprioritas tinggi sehingga operator dapat memperbaiki kondisi error. Komponen layanan harus mencegah terjadinya kegagalan operasi kecuali jika hal ini menimbulkan risiko ekstrem bagi bisnis.

Desain panggilan API dan perintah agar dapat dicoba lagi

API dan alat operasional harus membuat pemanggilan aman untuk dicoba ulang sejauh mungkin. Pendekatan alami untuk banyak kondisi error adalah mencoba kembali tindakan sebelumnya, tetapi Anda mungkin tidak tahu apakah percobaan pertama berhasil.

Arsitektur sistem Anda harus membuat tindakan yang idempoten - jika Anda melakukan tindakan yang identik pada sebuah objek dua kali atau lebih secara berturut-turut, tindakan tersebut akan memberikan hasil yang sama dengan satu pemanggilan. Tindakan non-idempoten memerlukan kode yang lebih kompleks untuk menghindari kerusakan status sistem.

Mengidentifikasi dan mengelola dependensi layanan

Desainer dan pemilik layanan harus mempertahankan daftar lengkap dependensi pada komponen sistem lainnya. Desain layanan juga harus menyertakan pemulihan dari kegagalan dependensi, atau degradasi halus jika pemulihan penuh tidak memungkinkan. Hitung dependensi pada layanan cloud yang digunakan oleh sistem Anda dan dependensi eksternal, seperti API layanan pihak ketiga, yang memahami bahwa setiap dependensi sistem memiliki tingkat kegagalan yang bukan nol.

Saat Anda menetapkan target keandalan, ketahuilah bahwa SLO untuk layanan dibatasi secara matematis oleh SLO semua dependensi pentingnya. Anda tidak boleh lebih andal daripada SLO terendah salah satu dependensi. Untuk informasi selengkapnya, lihat kalkulus ketersediaan layanan.

Dependensi startup

Layanan berperilaku berbeda saat dimulai dibandingkan dengan perilaku status stabil. Dependensi startup dapat berbeda secara signifikan dengan dependensi runtime stabil.

Misalnya, saat startup, layanan mungkin perlu memuat informasi pengguna atau akun dari layanan metadata pengguna yang jarang dipanggil lagi. Jika banyak replika layanan dimulai ulang setelah error atau pemeliharaan rutin, replika dapat secara tajam meningkatkan beban pada dependensi startup, terutama jika cache kosong dan perlu diisi ulang.

Menguji startup layanan saat dimuat, dan menyediakan dependensi startup sebagaimana mestinya. Pertimbangkan desain untuk melakukan degradasi halus dengan menyimpan salinan data yang diambil dari dependensi startup penting. Perilaku ini memungkinkan layanan Anda memulai ulang dengan data yang berpotensi tidak berlaku, bukan tidak dapat dimulai saat dependensi penting mengalami pemadaman. Nantinya, layanan Anda dapat memuat data baru, jika memungkinkan, untuk dikembalikan ke operasi normal.

Dependensi startup juga penting saat Anda mem-bootstrap layanan di lingkungan baru. Desain stack aplikasi Anda dengan arsitektur berlapis, tanpa dependensi siklik antarlapisan. Dependensi siklik mungkin tampak dapat dipertahankan karena tidak memblokir perubahan inkremental pada satu aplikasi. Namun, dependensi siklik dapat menyulitkan atau tidak memungkinkan untuk memulai ulang setelah bencana menghapus seluruh stack layanan.

Meminimalkan dependensi kritis.

Minimalkan jumlah dependensi penting untuk layanan Anda, yaitu komponen lain yang kegagalannya pasti akan menyebabkan pemadaman layanan untuk layanan Anda. Agar layanan lebih tahan terhadap kegagalan atau kelambatan dalam komponen lain yang menjadi tempatnya bergantung, pertimbangkan contoh teknik dan prinsip desain berikut untuk mengonversi dependensi penting menjadi dependensi yang tidak begitu penting:

• Tingkatkan level redundansi dalam dependensi kritis. Dengan menambahkan lebih banyak replika akan mengurangi kemungkinan seluruh komponen tidak tersedia.
• Gunakan permintaan asinkron ke layanan lain, bukan memblokir respons atau menggunakan pesan publikasikan/berlangganan untuk memisahkan permintaan dari respons.
• Simpan respons dari layanan lain ke dalam cache untuk pulih dari tidak tersedianya dependensi dalam jangka pendek.

Untuk merender kegagalan atau kelambatan dalam layanan Anda agar tidak terlalu berbahaya bagi komponen lain yang bergantung padanya, pertimbangkan contoh teknik dan prinsip desain berikut:

• Gunakan antrean permintaan yang diprioritaskan dan berikan prioritas yang lebih tinggi untuk permintaan yang sedang ditunggu responsnya oleh pengguna.
• Sajikan respons dari cache untuk mengurangi latensi dan beban.
• Fail safe dengan tetap mempertahankan fungsi
• Turunkan kualitas dengan baik saat terjadi kelebihan beban.

Memastikan setiap perubahan dapat di-roll back

Jika tidak ada cara yang jelas untuk mengurungkan jenis perubahan tertentu pada layanan, ubah desain layanan untuk mendukung rollback. Uji proses rollback secara berkala. API untuk setiap komponen atau microservice harus diberi versi, dengan kompatibilitas mundur sehingga klien generasi sebelumnya terus berfungsi dengan benar seiring berkembangnya API. Prinsip desain ini sangat penting untuk mengizinkan peluncuran bertahap perubahan API, dengan rollback cepat jika diperlukan.

Rollback dapat memerlukan banyak biaya untuk diterapkan pada aplikasi seluler. Firebase Remote Config adalah layanan Google Cloud untuk mempermudah rollback fitur.

Anda tidak dapat melakukan roll back perubahan skema database dengan mudah, jadi jalankan perubahan dalam beberapa fase. Desain setiap fase untuk mengizinkan pembacaan dan update skema yang aman berdasarkan versi terbaru aplikasi Anda, dan versi sebelumnya. Pendekatan desain ini memungkinkan Anda melakukan roll back dengan aman jika ada masalah dengan versi terbaru.

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, ikuti rekomendasi berikut:

• Terapkan backoff eksponensial dengan pengacakan dalam logika percobaan ulang error aplikasi klien.
• Implementasikan arsitektur multi-region dengan failover otomatis untuk ketersediaan tinggi.
• Gunakan load balancing untuk mendistribusikan permintaan pengguna di seluruh shard dan region.
• Desain aplikasi untuk menurunkan tingkat secara halus saat terjadi overload. Sajikan respons sebagian atau sediakan fungsi terbatas, bukan gagal sepenuhnya.
• Jalankan proses berbasis data untuk perencanaan kapasitas, dan gunakan uji beban dan perkiraan traffic untuk menentukan kapan harus menyediakan resource.
• Tetapkan prosedur pemulihan dari bencana (disaster recovery), dan lakukan pengujian secara berkala.

Langkah selanjutnya

• Membuat alat dan proses operasional yang andal (dokumen berikutnya dalam seri ini)

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Menciptakan alat dan proses operasional yang andal

Dokumen di Framework Arsitektur Google Cloud ini memberikan prinsip-prinsip operasional untuk menjalankan layanan Anda dengan cara yang andal, seperti cara men-deploy update, menjalankan layanan di lingkungan produksi, dan menguji kegagalan. Merancang untuk keandalan harus mencangkup keseluruhan dari siklus proses layanan Anda, bukan hanya desain software.

Pilih nama yang bagus untuk aplikasi dan layanan.

Hindari penggunaan nama kode internal dalam file konfigurasi produksi, karena dapat membingungkan, terutama bagi karyawan baru, yang berpotensi meningkatkan waktu mitigasi (TTM) untuk pemadaman. Sebisa mungkin, pilih nama yang bagus untuk semua layanan aplikasi, dan resource sistem penting Anda seperti VM, cluster, dan instance database, sesuai dengan batas panjang nama. Nama yang baik menjelaskan tujuan entitas; akurat, spesifik, dan berbeda; dan berarti bagi siapa saja yang melihatnya. Nama yang baik menghindari akronim, nama kode, singkatan, dan terminologi yang berpotensi menyinggung, dan tidak akan menciptakan respons publik negatif meskipun dipublikasikan secara eksternal.

Terapkan peluncuran progresif dengan pengujian canary

Perubahan global seketika pada biner atau konfigurasi layanan sangat berisiko. Luncurkan versi file baru yang dapat dieksekusi dan perubahan konfigurasi secara bertahap. Mulailah dengan cakupan kecil, seperti beberapa instance VM dalam satu zona, dan perluas cakupannya secara bertahap. Melakukan roll back dengan cepat jika perubahan tidak berjalan seperti yang Anda harapkan, atau berdampak negatif terhadap pengguna di setiap tahap peluncuran. Tujuan Anda adalah mengidentifikasi dan mengatasi bug jika hanya memengaruhi sebagian kecil traffic pengguna, sebelum Anda meluncurkan perubahan secara global.

Siapkan sebuah pengujian canary sistem yang mengetahui perubahan layanan dan melakukan perbandingan A/B dari metrik server yang diubah dengan server lainnya. Sistem harus menandai perilaku yang tidak terduga atau tidak wajar. Jika perubahan tidak berjalan seperti yang Anda harapkan, sistem pengujian canary akan otomatis menghentikan peluncuran. Masalahnya dapat menjadi jelas, seperti error pengguna, atau halus, seperti peningkatan penggunaan CPU atau penggelembungan memori.

Sebaiknya hentikan dan lakukan roll back pada saat ada masalah pertama dan masalah diagnosis tanpa menimbulkan tekanan waktu untuk pemadaman. Setelah perubahan lulus pengujian canary, sebarkan ke cakupan yang lebih besar secara bertahap, seperti ke zona penuh, kemudian kemudian zona kedua. Beri waktu bagi sistem yang diubah untuk menangani volume traffic pengguna yang semakin besar guna mengekspos bug laten.

Untuk informasi selengkapnya, lihat Strategi deployment dan pengujian aplikasi.

Sebarkan traffic untuk promosi dan peluncuran dengan waktu

Anda mungkin memiliki acara promosi, seperti penjualan yang dimulai pada waktu yang tepat dan mendorong banyak pengguna untuk terhubung ke layanan secara bersamaan. Jika demikian, desain kode klien untuk penyebaran traffic selama beberapa detik lebih. Gunakan penundaan acak sebelum mereka memulai permintaan.

Anda juga dapat melakukan pra-penyiapan pada sistem. Saat melakukan pra-penyiapan sistem, Anda mengirim traffic pengguna yang Anda antisipasi terlebih dahulu untuk memastikan sistem berfungsi seperti yang Anda harapkan. Pendekatan ini mencegah lonjakan traffic seketika yang dapat menyebabkan server Anda error pada waktu mulai yang dijadwalkan.

Mengotomatiskan build, pengujian, dan deployment

Hilangkan upaya manual dari proses rilis Anda dengan menggunakan pipeline continuous integration dan continuous delivery (CI/CD). Lakukan pengujian dan deployment integrasi otomatis. Misalnya, buat proses CI/CD modern dengan GKE.

Untuk mengetahui informasi selengkapnya, lihat continuous integration, continuous delivery, otomatisasi pengujian, dan otomatisasi deployment.

Bertahan dari error operator

Desain alat operasional Anda untuk menolak konfigurasi yang berpotensi tidak valid. Mendeteksi dan mengirimkan pemberitahuan saat versi konfigurasi kosong, sebagian atau terpotong, rusak, secara logis salah atau tidak terduga, atau tidak diterima dalam waktu yang diharapkan. Alat-alat juga harus menolak versi konfigurasi yang terlalu berbeda dari versi sebelumnya.

Melarang perubahan atau perintah dengan cakupan yang terlalu luas yang berpotensi merusak. Perintah umum ini dapat berupa "Cabut perizinan untuk semua pengguna", "Mulai ulang semua VM di region ini", atau "Format ulang semua disk di zona ini. Perubahan tersebut hanya boleh diterapkan jika operator menambahkan tanda command line atau setelan opsi penggantian darurat saat operator men-deploy konfigurasi.

Alat harus menampilkan cakupan dampak perintah yang berisiko, seperti jumlah VM yang terkena dampak perubahan, dan memerlukan konfirmasi operator eksplisit sebelum alat tersebut dilanjutkan. Anda juga dapat menggunakan fitur untuk mengunci resource penting dan mencegah penghapusan yang tidak disengaja atau tidak sah, seperti penguncian kebijakan retensi Cloud Storage.

Uji Pemulihan Kegagalan

Uji prosedur operasional Anda secara rutin agar pulih dari kegagalan di layanan Anda. Tanpa pengujian reguler, prosedur Anda mungkin tidak berfungsi saat Anda membutuhkannya jika terjadi kegagalan nyata. Item yang akan diuji secara berkala mencakup failover regional cara melakukan roll back rilis, dan cara memulihkan data dari pencadangan.

Lakukan pengujian disaster recovery

Seperti halnya tes pemulihan kegagalan, jangan menunggu bencana terjadi. Uji dan verifikasi prosedur dan proses pemulihan dari bencana Anda secara berkala.

Anda dapat membuat arsitektur sistem untuk memberikan ketersediaan tinggi (HA). Arsitektur ini tidak sepenuhnya tumpang tindih dengan pemulihan bencana (DR), tetapi sering kali perlu untuk mempertimbangkan HA kedalam akun saat Anda memikirkan nilai objektif waktu pemulihan (RTO) dan objektif titik pemulihan (RPO) nilai.

HA membantu Anda memenuhi atau melampaui tingkat performa operasional yang disepakati, seperti waktu beroperasi. Saat menjalankan workload produksi di Google Cloud, Anda dapat men-deploy instance standby pasif atau aktif di region kedua. Dengan arsitektur ini, aplikasi tersebut akan terus menyediakan layanan dari region yang tidak terpengaruh jika terjadi bencana di region utama. Untuk informasi selengkapnya, lihat Merancang pemulihan dari bencana untuk pemadaman layanan cloud.

Praktikkan rekayasa kekacauan.

Pertimbangkan penggunaan rekayasa kekacauan dalam praktik pengujian Anda. Munculkan kegagalan yang sesungguhnya ke berbagai komponen sistem produksi dengan beban di lingkungan yang aman. Pendekatan ini membantu memastikan bahwa tidak ada dampak sistem secara keseluruhan karena layanan Anda menangani kegagalan dengan benar di setiap level.

Kegagalan yang Anda masukkan kedalam sistem dapat mencakup tugas error, error dan waktu tunggu pada RPC, atau pengurangan ketersediaan resource. Gunakan injeksi kesalahan acak untuk menguji kegagalan sesekali (flapping) didalam dependensi layanan. Perilaku ini sulit dideteksi dan dimitigasi dalam produksi.

Rekayasa kekacauan memastikan bahwa dampak dari eksperimen tersebut diminimalkan dan ditanggulangi. Perlakukan pengujian tersebut sebagai praktik untuk pemadaman layanan yang sebenarnya dan penggunaan semua informasi yang dikumpulkan untuk meningkatkan respons pemadaman layanan Anda.

Langkah selanjutnya

• Membuat pemberitahuan yang efisien (dokumen berikutnya dalam seri ini)

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Membuat Pemberitahuan yang efisien

Dokumen dalam Framework Arsitektur Google Cloud memberikan prinsip operasional untuk membuat pemberitahuan yang membantu Anda menjalankan layanan yang andal. Semakin banyak informasi yang Anda miliki mengenai performa layanan, semakin tepat keputusan yang Anda ambil saat terjadi masalah. Desain pemberitahuan Anda untuk mendeteksi permasalahan sistem yang berdampak bagi pengguna lebih awal dan akurat serta meminimalkan positif palsu.

Optimalkan penundaan pemberitahuan

Ada keseimbangan antara pemberitahuan yang dikirim terlalu cepat sehingga membebani tim operasi dan pemberitahuan yang dikirim terlalu lambat serta menyebabkan pemadaman layanan yang lama. Sesuaikan penundaan pemberitahuan sebelum sistem pemantauan memberi tahu manusia tentang masalah tersebut untuk meminimalkan waktu deteksi, sekaligus memaksimalkan sinyal versus derau. Gunakan tingkat konsumsi anggaran error untuk mendapatkan konfigurasi pemberitahuan yang optimal.

Buat pemberitahuan untuk gejala, bukan penyebab

Picu pemberitahuan berdasarkan dampak langsung terhadap pengalaman pengguna. Ketidakpatuhan dengan SLO global atau per pelanggan dapat menunjukkan dampak langsung. Jangan membuat peringatan pada setiap kemungkinan penyebab kegagalan, terutama apabila dampaknya hanya terbatas pada satu replika. Sistem yang terdistribusi dengan baik dapat memulihkan kegagalan replika tunggal dengan lancar.

Buat pemberitahuan untuk nilai pencilan, bukan rata-rata

Saat memantau latensi tentukan SLO dan setel pemberitahuan menjadi (pilih dua dari tiga) yaitu persentil 90, 95, atau 99, bukan untuk latensi persentil 50 atau rata-rata. Nilai latensi rata-rata atau median yang baik dapat menyembunyikan nilai tinggi yang tidak dapat diterima pada persentil 90 atau lebih tinggi yang menyebabkan pengalaman sangat buruk bagi pengguna. Oleh karena itu, Anda harus menerapkan prinsip pemberitahuan nilai pencilan ini saat memantau latensi pada setiap operasi penting, seperti interaksi permintaan-respons dengan server web, penyelesaian batch di pipeline pemrosesan data, atau pembacaan maupun operasi tulis pada layanan penyimpanan.

Buat proses manajemen insiden kolaboratif.

Dokumen dalam Framework Arsitektur Google Cloud memberikan praktik terbaik untuk mengelola layanan dan menentukan proses untuk merespons insiden. Insiden dapat terjadi pada semua layanan, jadi Anda perlu proses yang terdokumentasi dengan baik untuk dapat secara efisien menanggapi masalah ini dan melakukan mitigasi.

Ringkasan manajemen insiden

Tidak dapat dipungkiri bahwa sistem yang Anda desain dengan baik pada akhirnya gagal memenuhi SLO-nya. Tanpa adanya SLO, pelanggan Anda secara longgar menentukan tingkat layanan yang dapat diterima dari pengalaman mereka sebelumnya. Pelanggan mengeskalasi ke dukungan teknis atau grup serupa, terlepas dari apa yang ada dalam SLA Anda.

Untuk melayani pelanggan Anda dengan tepat, buat dan uji rencana manajemen insiden secara teratur. Rencana ini bisa sesingkat checklist satu halaman yang berisi sepuluh item. Proses ini membantu tim Anda mengurangi Waktu Untuk Mendeteksi (TTD) dan Waktu Untuk Memitigasi (TTM).

TTM lebih disukai dibandingkan TTR, yang mengharuskan R untuk perbaikan atau pemulihan sering digunakan untuk menunjukkan perbaikan penuh versus mitigasi. TTM menekankan mitigasi yang cepat untuk mengakhiri dampak pemadaman layanan pada pelanggan dengan cepat, lalu memulai proses yang sering kali lebih lama untuk memperbaiki masalah sepenuhnya.

Sistem yang dirancang dengan baik dengan operasi yang berjalan sangat baik akan meningkatkan waktu antara kegagalan (TBF). Dengan kata lain, prinsip operasional keandalan, termasuk manajemen insiden yang baik, bertujuan untuk mengurangi frekuensi kegagalan.

Untuk menjalankan layanan yang andal, terapkan praktik terbaik berikut dalam proses manajemen insiden Anda.

Tetapkan kepemilikan layanan yang jelas

Semua layanan dan dependensi pentingnya harus memiliki pemilik yang jelas yang bertanggung jawab untuk mematuhi SLO mereka. Jika ada reorganisasi atau pengurangan tim, pimpinan engineer harus memastikan bahwa kepemilikan secara eksplisit diserahkan kepada tim baru, beserta dokumentasi dan pelatihan yang diperlukan. Pemilik layanan harus mudah ditemukan oleh tim lain.

Kurangi waktu untuk mendeteksi (TTD) dengan pemberitahuan yang disetel dengan baik

Sebelum Anda dapat mengurangi TTD, tinjau dan terapkan rekomendasi di build kemampuan observasi ke dalam infrastruktur dan aplikasi Anda serta Bagiantentukan sasaran keandalan Anda dari kategori keandalan Framework Arsitektur. Misalnya, membedakan antara masalah aplikasi dan masalah cloud yang mendasarinya.

Serangkaian SLI yang disesuaikan dengan baik akan memberi tahu tim Anda pada waktu yang tepat tanpa kelebihan beban pemberitahuan. Untuk mengetahui informasi selengkapnya, lihat bagian membuat pemberitahuan yang efisien dari kategori keandalan Framework Arsitektur atau Menyiapkan metrik SLI Anda: CRE life lessons.

Kurangi waktu untuk memitigasi (TTM) dengan pelatihan manajemen insiden

Untuk mengurangi TTM, tentukan rencana manajemen insiden yang terdokumentasi dan dilakukan dengan baik. Memiliki data yang tersedia tentang apa yang berubah di lingkungan. Pastikan bahwa tim mengetahui mitigasi generik yang dapat dengan cepat mereka terapkan untuk meminimalkan TTM. Teknik mitigasi ini mencakup pengosongan, roll back perubahan, penambahan resource, dan penurunan kualitas layanan.

Seperti yang telah dibahas dalam dokumen kategori keandalan Framework Arsitektur lainnya, buat alat dan proses operasional yang andal untuk mendukung rollback perubahan yang aman dan cepat.

Desain tata letak dasbor dan konten untuk meminimalkan TTM

Atur tata letak dan navigasi dasbor layanan Anda sehingga operator dapat menentukan dalam waktu satu atau dua menit apakah layanan dan semua dependensi pentingnya sedang berjalan. Untuk menemukan penyebab potensial masalah dengan cepat, operator harus dapat memindai semua bagan di dasbor agar dapat dengan cepat mencari grafik yang berubah secara signifikan pada saat pemberitahuan muncul.

Daftar contoh grafik berikut mungkin ada di dasbor Anda untuk membantu memecahkan masalah. Responden insiden harus dapat melihatnya dalam satu tampilan:

• Indikator tingkat layanan, seperti permintaan yang berhasil dibagi dengan total permintaan yang valid
• Konfigurasi dan peluncuran biner
• Permintaan per detik ke sistem
• Respons error per detik dari sistem
• Permintaan per detik dari sistem ke dependensi-dependensinya
• Respons error per detik ke sistem dari dependensi-dependensinya

Grafik umum lainnya untuk membantu memecahkan masalah mencakup latensi, saturasi, ukuran permintaan, ukuran respons, biaya kueri, penggunaan kumpulan thread, dan metrik Java virtual machine (JVM) (jika berlaku). Saturasi mengacu pada kapasitas penuh oleh beberapa batas, seperti kuota atau ukuran memori sistem. Penggunaan kumpulan thread mencari regresi karena kehabisan kumpulan.

Uji penempatan grafik ini terhadap beberapa skenario pemadaman layanan untuk memastikan bahwa grafik yang paling penting berada di dekat bagian atas, dan urutan grafik sesuai dengan alur kerja diagnostik standar Anda. Anda juga dapat menerapkan machine learning dan deteksi anomali statistik untuk menampilkan subset yang tepat dari grafik ini.

Mendokumentasikan prosedur diagnostik dan mitigasi untuk skenario gangguan yang diketahui

Tulis playbook dan link ke playbook tersebut dari notifikasi pemberitahuan. Jika dokumen ini dapat diakses dari notifikasi pemberitahuan, operator bisa dengan cepat mendapatkan informasi yang diperlukan untuk memecahkan dan mengurangi masalah.

Gunakan postmortem blameless untuk belajar dari gangguan dan mencegah pengulangan

Membangun budaya postmortem blameless dan proses peninjauan insiden. Blameless berarti tim Anda mengevaluasi dan mendokumentasikan kesalahan secara objektif, tanpa perlu menyalahkan.

Kesalahan adalah peluang untuk belajar, bukan alasan untuk dikritik, Selalu berupaya untuk membuat sistem lebih tangguh sehingga dapat pulih dengan cepat dari kesalahan manusia, atau bahkan lebih baik lagi, mendeteksi dan mencegah kesalahan manusia. Ekstrak sebanyak mungkin pembelajaran dari setiap postmortem dan tindak lanjuti dengan cermat setiap item tindakan postmortem untuk mengurangi frekuensi gangguan, sehingga meningkatkan TBF.

Contoh rencana manajemen insiden

Masalah produksi telah terdeteksi, melalui pemberitahuan atau halaman, atau dilaporkan kepada saya:

• Haruskah saya mendelegasikan kepada orang lain?
  • Ya, jika Anda dan tim Anda tidak dapat menyelesaikan masalah tersebut.
• Apakah masalah ini merupakan pelanggaran privasi atau keamanan?
  • Jika ya, delegasikan ke tim privasi atau keamanan.
• Apakah masalah ini bersifat darurat atau apakah SLO berisiko?
  • Jika ragu, perlakukan hal ini sebagai keadaan darurat.
• Haruskah saya melibatkan lebih banyak orang?
  • Ya, jika masalah memengaruhi lebih dari X% pelanggan atau jika penyelesaian masalah memerlukan waktu lebih dari Y menit. Jika ragu, selalu libatkan lebih banyak orang, terutama dalam jam kerja.
• Menentukan saluran komunikasi utama, seperti IRC, Hangouts Chat, atau Slack.
• Delegasikan peran yang telah ditentukan sebelumnya, seperti berikut:
  • Komandan insiden yang bertanggung jawab atas koordinasi keseluruhan.
  • Pemimpin komunikasi yang bertanggung jawab atas komunikasi internal dan eksternal.
  • Pemimpin operasi yang bertanggung jawab untuk mengurangi masalah.
• Tentukan kapan insiden berakhir. Keputusan ini mungkin memerlukan konfirmasi dari perwakilan dukungan atau tim serupa lainnya.
• Berkolaborasilah dalam postmortem tanpa menyalahkan.
• Menghadiri rapat peninjauan insiden postmortem untuk mendiskusikan dan mengelola item tindakan.

Rekomendasi

Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, ikuti rekomendasi berikut:

• Membuat rencana manajemen insiden, dan melatih tim Anda untuk menggunakannya.
• Untuk mengurangi TTD, terapkan rekomendasi untuk membangun kemampuan observasi ke dalam infrastruktur dan aplikasi Anda.
• Membuat dasbor "Apa yang berubah?" yang dapat Anda lihat sekilas ketika terjadi suatu insiden.
• Dokumentasikan cuplikan kueri atau buat dasbor Looker Studio dengan kueri log yang sering digunakan.
• Evaluasi Firebase Remote Config untuk memitigasi masalah peluncuran aplikasi seluler.
• Uji pemulihan kegagalan, termasuk memulihkan data dari cadangan, untuk mengurangi TTM sebagian insiden Anda.
• Desain dan uji konfigurasi serta rollback biner.
• Replikasi data di seluruh region untuk pemulihan dari bencana dan gunakan uji pemulihan dari bencana untuk mengurangi TTM setelah pemadaman layanan regional.
• Desain arsitektur multi-region untuk ketahanan terhadap pemadaman layanan regional jika kebutuhan bisnis akan ketersediaan tinggi sesuai biaya, untuk meningkatkan TBF.

Langkah selanjutnya

Pelajari lebih lanjut cara membangun proses manajemen insiden kolaboratif dengan referensi berikut:

• Dasbor Status Google Cloud
• Manajemen insiden di Google
• Proses respons insiden data
• Bab buku SRE tentang pengelolaan insiden

Pelajari kategori lain di Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.

Framework Arsitektur Google Cloud: Panduan keandalan produk

Bagian dalam Framework Arsitektur ini memiliki panduan praktik terbaik khusus produk untuk keandalan, ketersediaan, dan konsistensi beberapa produk Google Cloud. Panduan ini juga memberikan rekomendasi untuk meminimalkan dan memulihkan dari kegagalan, serta untuk menskalakan aplikasi dengan baik saat sedang dimuat.

Catatan: Untuk mempelajari elemen penyusun keandalan tingkat platform di Google Cloud (zona, region, dan resource cakupan lokasi) dan tingkat ketersediaan yang mereka sediakan, lihat panduan keandalan infrastruktur Google Cloud. Panduan ini juga memberikan panduan untuk menilai persyaratan keandalan workload Anda, dan menyajikan rekomendasi arsitektur untuk membangun serta mengelola infrastruktur yang andal di Google Cloud.

Panduan keandalan produk disusun berdasarkan area berikut:

• Compute
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• Penyimpanan dan database
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• Jaringan
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• Analisis data
  • BigQuery
  • Dataflow
  • Dataproc

Panduan keandalan Compute Engine

Compute Engine layanan komputasi yang dapat disesuaikan dan memungkinkan pengguna untuk membuat dan menjalankan virtual machine on demand di infrastruktur Google.

Praktik terbaik

• Praktik terbaik Compute Engine API - praktik terbaik yang direkomendasikan untuk menggunakan Compute Engine API dan memitigasikan efek batas kapasitas API.
• Mendesain sistem yang tangguh - panduan mendetail tentang cara merancang aplikasi Compute Engine Anda untuk pulih dari kegagalan atau pengulangan VM tunggal, dan kegagalan zonal atau regional.
• Cara meningkatkan ketersediaan dengan penyediaan berlebih - tambahkan resources redundan untuk menjaga aplikasi Anda tetap aktif dan berjalan ketika menghadapi hilangnya kapasitas akibat gangguan zonal atau regional.
• Menggunakan load balancing pada aplikasi yang sangat mudah diakses - cara menggunakan Cloud Load Balancing dengan Compute Engine untuk memberikan ketersediaan tinggi, bahkan ketika terjadi pemadaman layanan di zona tertentu.
• Praktik terbaik untuk pemilihan region Compute Engine - cara memilih region Google Cloud yang akan digunakan untuk resource Compute Engine Anda guna mengoptimalkan latensi bagi aplikasi sekaligus melakukan pencatatan kompromi harga/performa.
• Praktik terbaik untuk memigrasikan VM, menggunakan Migrate to Virtual Machines - cara memigrasikan VM dari lingkungan sumber yang didukung ke Compute Engine dengan Migrate to Virtual Machines, termasuk penilaian, perencanaan, dan pelaksanaan migrasi. Selain itu, cara mengatasi masalah umum yang mungkin muncul terkait dengan migrasi.
• Pola penggunaan alamat IP mengambang pada Compute Engine - cara mengimplementasikan alamat IP bersama atau virtual di lingkungan Compute Engine dengan mengubah arsitektur menjadi pola untuk kasus penggunaan Anda. Pola ini mencakup pola yang menggunakan load balancing, rute Google Cloud, dan autohealing.
• Praktik terbaik untuk snapshot persistent disk - buat snapshot dengan lebih cepat dan dengan keandalan yang lebih baik.
• Persistent disk dan replikasi - bagaimana persistent disk menggunakan Colossus untuk backend penyimpanan, dan mengakses persistent disk dari VM. Selain itu, memantau latensi persistent disk, mereplikasi persistent disk antar-region atau zona, serta menangani permintaan baca dan tulis untuk replika.
• Mengonfigurasi disk untuk memenuhi persyaratan performa - faktor yang memengaruhi performa volume block storage yang terpasang ke instance VM.
• Praktik terbaik pengelolaan image - panduan mendetail tentang cara mengelola image Compute Engine seperti memilih boot image, menyesuaikan image, siklus proses image, dan berbagi image antar-project.
• Praktik terbaik kelompok image - pentingnya menguji image terbaru dalam kelompok image sebelum menggunakannya dalam produksi, dan cara menyiapkan prosedur pengujian.
• Praktik terbaik untuk instance SQL Server - praktik terbaik untuk mengoptimalkan instance Compute Engine yang menjalankan Microsoft SQL Server, dan mengoptimalkan SQL Server Enterprise Edition. Selain itu, cara menggunakan setelan jaringan default sistem operasi, dan aktivitas operasional untuk meningkatkan performa dan stabilitas.

Panduan keandalan Cloud Run

Cloud Run adalah platform komputasi terkelola yang cocok untuk men-deploy aplikasi dalam container dan serverless. Cloud Run menghilangkan semua infrastruktur sehingga pengguna dapat fokus mem-build aplikasi.

Praktik terbaik

• Tips umum Cloud Run - cara mengimplementasikan layanan Cloud Run, memulai container dengan cepat, menggunakan variabel global, dan meningkatkan keamanan container.
• Praktik terbaik pengujian beban - cara memuat layanan pengujian Cloud Run, termasuk mengatasi masalah serentak sebelum pengujian beban, mengelola jumlah maksimum instance, memilih wilayah terbaik untuk pengujian beban, dan memastikan layanan diskalakan sesuai dengan beban.
• Penskalaan instance - cara menskalakan dan membatasi instance container serta meminimalkan waktu respons dengan membuat beberapa instance tetap tidak ada aktivitas, bukan menghentikannya.
• Menggunakan instance minimum - tentukan jumlah minimum instance container yang siap ditayangkan, dan jika ditetapkan dengan jumlah yang tinggi, meminimalkan waktu respons rata-rata dengan mengurangi jumlah cold start.
• Mengoptimalkan aplikasi Java untuk Cloud Run - memahami konsekuensi beberapa pengoptimalan untuk layanan Cloud Run yang ditulis dalam Java, serta kurangi waktu startup dan penggunaan memori.
• Mengoptimalkan aplikasi Python untuk Cloud Run - mengoptimalkan image container dengan meningkatkan efisiensi server WSGI, dan mengoptimalkan aplikasi dengan mengurangi jumlah thread dan menjalankan tugas startup secara paralel.

Panduan keandalan Cloud Functions

Cloud Functions adalah platform serverless untuk membangun dan menghubungkan layanan yang skalabel dan berbasis peristiwa. Cloud Functions dapat dipanggil melalui permintaan HTTP atau dipicu berdasarkan peristiwa latar belakang.

Praktik terbaik

• Praktik terbaik Cloud Functions - panduan tentang cara menggunakan dan berinteraksi dengan Cloud Function, menerapkan idempotensi, men-deploy fungsi, dan mengoptimalkan performa.

Panduan keandalan Google Kubernetes Engine

Google Kubernetes Engine (GKE) adalah sistem untuk mengoperasikan aplikasi dalam container di cloud dalam skala besar. GKE men-deploy, mengelola, dan menyediakan resource untuk aplikasi dalam container Anda. Lingkungan GKE terdiri dari instance Compute Engine yang dikelompokkan bersama untuk membentuk cluster.

Praktik terbaik

• Praktik terbaik untuk mengoperasikan container - cara menggunakan mekanisme logging, memastikan container bersifat stateless dan tidak dapat diubah, memantau aplikasi, serta melakukan pemeriksaan keaktifan dan kesiapan.
• Praktik terbaik untuk membangun container - cara mengemas satu aplikasi per container, menangani ID proses (PID), mengoptimalkan cache build Docker, dan membangun image yang lebih kecil untuk mempercepat waktu upload dan download.
• Praktik terbaik untuk jaringan Google Kubernetes Engine - menggunakan cluster VPC native untuk memudahkan penskalaan, merencanakan alamat IP, menskalakan konektivitas cluster, menggunakan Google Cloud Armor untuk memblokir serangan Distributed Denial-of-Service (DDoS), menerapkan Load balancing container native untuk latensi yang lebih rendah, menggunakan fungsi health check Load Balancer Aplikasi eksternal untuk failover yang lancar, dan menggunakan cluster regional untuk meningkatkan ketersediaan aplikasi di cluster.
• Menyiapkan aplikasi Kubernetes berbasis cloud - pelajari praktik terbaik untuk merencanakan kapasitas aplikasi, mengembangkan aplikasi secara horizontal atau vertikal, menetapkan batas resource sesuai dengan permintaan resource untuk memori versus CPU, membuat container lebih ramping guna mempercepat startup aplikasi, dan membatasi gangguan Pod dengan menyetel Pod Disruption Budget (PDB). Selain itu, pahami cara menyiapkan pemeriksaan keaktifan dan kesiapan untuk startup aplikasi yang lancar, memastikan penonaktifan tanpa gangguan, dan menerapkan backoff eksponensial pada permintaan yang dicoba lagi untuk mencegah lonjakan traffic yang membebani aplikasi Anda.
• Praktik terbaik multi-tenancy GKE - cara mendesain arsitektur cluster multi-tenant untuk ketersediaan dan keandalan tinggi, menggunakan pengukuran penggunaan Google Kubernetes Engine (GKE) untuk metrik penggunaan per tenant, menyediakan log khusus tenant, dan menyediakan pemantauan khusus tenant.

Panduan keandalan Cloud Storage

Cloud Storage adalah repositori objek yang tahan lama dan sangat tersedia dengan kemampuan keamanan dan berbagi yang terdepan. Layanan ini digunakan untuk menyimpan dan mengakses data pada infrastruktur Google Cloud.

Praktik terbaik

• Praktik terbaik untuk Cloud Storage - praktik terbaik umum untuk Cloud Storage, termasuk tips untuk memaksimalkan ketersediaan dan meminimalkan latensi aplikasi Anda, meningkatkan keandalan operasi upload, dan meningkatkan performa penghapusan data berskala besar.
• Pedoman pendistribusian akses dan rasio permintaan - cara meminimalkan latensi dan respons error pada operasi baca, tulis, dan hapus pada tingkat permintaan yang sangat tinggi dengan memahami cara kerja penskalaan otomatis Cloud Storage.

Panduan keandalan Firestore

Firestore adalah database dokumen NoSQL yang memungkinkan Anda menyimpan, menyinkronkan, dan membuat kueri data untuk aplikasi seluler dan web Anda, dalam skala global.

Praktik terbaik

• Praktik terbaik Firestore - cara memilih lokasi database untuk meningkatkan keandalan, meminimalkan hambatan performa dalam pengindeksan, meningkatkan performa operasi baca dan tulis, mengurangi latensi untuk notifikasi perubahan, dan mendesain untuk penskalaan.

Panduan keandalan Bigtable

Bigtable adalah database NoSQL yang skalabel dan terkelola sepenuhnya untuk workload analisis dan operasional yang besar. Fungsi ini dirancang sebagai tabel yang diisi secara tersebar dan dapat diskalakan hingga miliaran baris dan ribuan kolom, serta mendukung throughput baca dan tulis yang tinggi pada latensi rendah.

Praktik terbaik

• Memahami performa Bigtable - memperkirakan throughput untuk Bigtable, cara merencanakan kapasitas Bigtable dengan mengamati penggunaan throughput dan penyimpanan, pengaruh pengaktifan replikasi terhadap throughput baca dan tulis, serta cara Bigtable mengoptimalkan data dari waktu ke waktu.
• Desain skema Bigtable - panduan untuk mendesain skema Bigtable, termasuk konsep penyimpanan kunci/nilai, mendesain kunci baris berdasarkan permintaan baca yang direncanakan, menangani kolom dan baris, serta kasus penggunaan khusus.
• Ringkasan replikasi Bigtable - cara mereplikasi Bigtable di beberapa zona atau region, memahami implikasi performa replikasi, dan cara Bigtable mengatasi konflik serta menangani failover.
• Tentang cadangan Bigtable - cara menyimpan salinan skema dan data tabel dengan Cadangan Bigtable, yang dapat membantu Anda memulihkan dari kerusakan data tingkat aplikasi atau dari error operator, seperti menghapus tabel secara tidak sengaja.

Panduan keandalan Cloud SQL

Cloud SQL adalah layanan database relasional yang terkelola sepenuhnya untuk MySQL, PostgreSQL, dan SQL Server. Cloud SQL mudah diintegrasikan dengan aplikasi dan layanan Google Cloud yang sudah ada, seperti Google Kubernetes Engine dan BigQuery.

Praktik terbaik

• Ketersediaan tinggi Cloud SQL - ringkasan konfigurasi ketersediaan tinggi untuk Cloud SQL, termasuk menangani replika baca dan proses failover. Juga mencakup cara mengontrol waktu peristiwa pemeliharaan database, dan bagaimana penggunaan persistent disk regional dalam konfigurasi HA memengaruhi performa database. Konten ini dibagi menjadi tiga bagian:

  • Ketersediaan tinggi MySQL
  • Ketersediaan tinggi PostgreSQL
  • Ketersediaan tinggi SQL Server

• Pemulihan dari bencana database Cloud SQL - ringkasan konfigurasi pemulihan dari bencana untuk Cloud SQL menggunakan replika baca lintas region.

  • Pemulihan dari bencana pada MySQL
  • Pemulihan dari bencana pada PostgreSQL
  • Pemulihan dari bencana pada SQL Server

• Praktik terbaik umum untuk Cloud SQL - panduan tentang mengonfigurasi instance, arsitektur data, mengimpor dan mengekspor data, serta pencadangan dan pemulihan. Konten ini dibagi menjadi tiga bagian:

  • Praktik terbaik MySQL
  • Praktik terbaik PostgreSQL
  • Praktik terbaik SQL Server

• Praktik terbaik untuk mengimpor dan mengekspor data - dalam keadaan apa bucket Cloud Storage tidak dapat digunakan, mengompresi data untuk mengurangi biaya, batasan yang diketahui dalam mengimpor dan mengekspor data, cara mengotomatiskan operasi ekspor, serta memecahkan masalah impor dan ekspor operasional bisnis.

  • Praktik terbaik MySQL
  • Praktik terbaik PostgreSQL
  • Praktik terbaik SQL Server

Panduan keandalan Spanner

Spanner adalah layanan pengelolaan dan penyimpanan database SQL terdistribusi, dengan fitur seperti transaksi global, serta penskalaan horizontal dan konsistensi transaksional yang sangat tersedia.

Praktik terbaik

• Pencadangan dan pemulihan Spanner - fitur utama Pencadangan dan Pemulihan Spanner, perbandingan Pencadangan dan Pemulihan dengan Impor dan Ekspor, detail implementasi, serta cara mengontrol akses ke resource Spanner.
• Konfigurasi regional dan multi-region - deskripsi dua jenis konfigurasi instance yang ditawarkan Spanner: konfigurasi regional dan konfigurasi multi-region. Deskripsi mencakup perbedaan dan kompromi antara setiap konfigurasi.
• Autoscaling Spanner - pengantar alat Autoscaler untuk Spanner (Autoscaler), sebuah alat open source yang dapat Anda gunakan sebagai alat pendamping untuk Cloud Spanner. Alat ini memungkinkan Anda meningkatkan atau mengurangi jumlah node atau unit pemrosesan secara otomatis di satu atau beberapa instance Spanner berdasarkan metrik penggunaan setiap instance Spanner.
• Tentang pemulihan point-in-time (PITR) - deskripsi pemulihan point-in-time (PITR) Spanner, fitur yang melindungi dari penghapusan atau penulisan data Spanner secara tidak sengaja. Misalnya, operator tidak sengaja menulis data atau peluncuran aplikasi merusak database. Dengan PITR, Anda dapat memulihkan data dari satu titik waktu di masa lalu (hingga maksimum tujuh hari) dengan lancar.
• Praktik terbaik Spanner - panduan tentang pemuatan massal, menggunakan Bahasa Manipulasi Data (DML), merancang skema untuk menghindari hotspot, dan praktik terbaik SQL.

Panduan keandalan Filestore

Filestore adalah layanan penyimpanan file terkelola untuk aplikasi Google Cloud, dengan antarmuka filesystem dan filesystem bersama untuk data. Filestore menawarkan Network Attached Storage (NAS) online berskala petabyte untuk instance Compute Engine dan Google Kubernetes Engine.

Praktik terbaik

• Performa filestore - rekomendasi setelan performa dan jenis mesin Compute Engine, opsi pemasangan NFS untuk mendapatkan performa terbaik pada instance VM klien Linux, dan menggunakan alat fio untuk menguji performa. Mencakup rekomendasi untuk peningkatan performa di beberapa resource Google Cloud.

• Cadangan Filestore - deskripsi cadangan Filestore, kasus penggunaan umum, dan praktik terbaik untuk membuat dan menggunakan cadangan.

• Snapshot Filestore - deskripsi snapshot Filestore, kasus penggunaan umum, dan praktik terbaik untuk membuat dan menggunakan snapshot.

• Jaringan Filestore - persyaratan jaringan dan resource IP yang diperlukan untuk menggunakan Filestore.

Panduan keandalan Memorystore

Memorystore adalah penyimpanan dalam memori yang terkelola sepenuhnya dan menyediakan versi terkelola dari dua solusi cache open source: Redis dan Memcached. Memorystore bersifat skalabel, dan mengotomatiskan tugas-tugas kompleks seperti penyediaan, replikasi, failover, dan patching.

Praktik terbaik

• Praktik terbaik umum Redis - panduan tentang mengekspor cadangan Redis Database (RDB), operasi yang menggunakan banyak resource, dan operasi yang memerlukan percobaan ulang koneksi. Selain itu, informasi tentang pemeliharaan, pengelolaan memori, dan penyiapan konektor Akses VPC serverless, serta mode koneksi akses layanan pribadi, serta pemantauan dan pemberitahuan.
• Praktik terbaik pengelolaan memori redis - konsep pengelolaan memori seperti kapasitas instance dan konfigurasi Maxmemory, ekspor, penskalaan, dan operasi upgrade versi, metrik pengelolaan memori, serta cara mengatasi kehabisan memori kondisi.
• Backoff eksponensial redis - cara kerja backoff eksponensial, algoritme contoh, dan cara kerja backoff maksimum serta jumlah maksimum percobaan ulang.
• Praktik terbaik memcache - cara mendesain aplikasi untuk cache yang tidak ditemukan, terhubung langsung ke alamat IP node, dan layanan Discovery Auto Memcache. Selain itu, panduan tentang cara mengonfigurasi parameter max-item-size, menyeimbangkan cluster, dan menggunakan Cloud Monitoring untuk memantau metrik penting.
• Praktik terbaik pengelolaan memori memcache - mengonfigurasi memori untuk instance Memcached, konfigurasi Reserved Memory, kapan harus meningkatkan Reserved Memory, dan metrik untuk penggunaan memori.

Panduan keandalan Cloud DNS

Cloud DNS adalah sistem nama domain berlatensi rendah yang membantu mendaftarkan, mengelola, dan melayani domain Anda. Cloud DNS dapat diskalakan ke sejumlah besar zona dan data DNS, serta jutaan data DNS dapat dibuat dan diperbarui melalui antarmuka pengguna.

Praktik terbaik

• Praktik terbaik Cloud DNS - mempelajari cara mengelola zona pribadi, mengonfigurasi penerusan DNS, dan membuat kebijakan server DNS. Termasuk panduan tentang cara menggunakan Cloud DNS di lingkungan hybrid.

Panduan keandalan Cloud Load Balancing

Cloud Load Balancing adalah sebuah layanan terkelola yang terdistribusi sepenuhnya, serta software-defined untuk semua traffic Anda. Cloud Load Balancing juga menyediakan penskalaan otomatis tanpa hambatan, load balancing Lapisan 4 dan Lapisan 7, serta dukungan untuk berbagai fitur, seperti load balancing global untuk IPv6.

Praktik terbaik

• Praktik terbaik performa - cara menyebarkan muatan ke seluruh instance aplikasi untuk menghasilkan performa yang optimal. Strategi mencakup penempatan backend di region yang paling dekat dengan traffic, pembuatan cache, pemilihan protokol aturan penerusan, dan konfigurasi afinitas sesi.
• Menggunakan load balancing pada aplikasi yang sangat mudah diakses - cara menggunakan Cloud Load Balancing dengan Compute Engine untuk memberikan ketersediaan tinggi, bahkan ketika terjadi pemadaman layanan di zona tertentu.

Panduan keandalan Cloud CDN

Cloud CDN (Jaringan Penayangan Konten) adalah layanan yang mempercepat penayangan konten internet dengan menggunakan jaringan edge Google untuk membawa konten sedekat mungkin ke pengguna. Cloud CDN membantu mengurangi latensi, biaya, dan beban, sehingga memudahkan penskalaan layanan kepada pengguna.

Praktik terbaik

• Praktik terbaik pengiriman konten - cara mengoptimalkan rasio cache ditemukan menggunakan kunci cache, memastikan HTTP/3 diaktifkan untuk performa terbaik, dan meninjau metrik pemantauan menggunakan dasbor pemantauan kustom Cloud CDN. Selain itu, cara meninjau laporan tentang ketersediaan, latensi, dan throughput dari pengujian performa pihak ketiga.

Panduan keandalan BigQuery

BigQuery adalah platform data warehouse Google Cloud untuk menyimpan dan menganalisis data dalam skala besar.

Praktik terbaik

• Pengantar keandalan - praktik terbaik keandalan dan pengenalan konsep seperti ketersediaan, ketahanan, dan konsistensi data.
• Ketersediaan dan ketahanan - jenis domain gagal yang dapat terjadi di pusat data Google Cloud, cara BigQuery menyediakan redundansi penyimpanan berdasarkan lokasi penyimpanan data, dan alasan set data lintas region meningkatkan pemulihan dari bencana.
• Praktik terbaik untuk workload multi-tenant di BigQuery - pola umum yang digunakan di platform data multi-tenant. Pola ini meliputi, memastikan keandalan dan isolasi bagi pelanggan vendor software as a service (SaaS), kuota dan batas BigQuery penting untuk perencanaan kapasitas, menggunakan BigQuery Data Transfer Service untuk menyalin set data yang relevan ke region lain, dan banyak lagi.
• Menggunakan Tampilan Terwujud - cara menggunakan Tampilan Terwujud BigQuery untuk kueri yang lebih cepat dengan biaya lebih rendah, meliputi membuat kueri tampilan terwujud, menyelaraskan partisi, dan memahami smart-tuning (penulisan ulang kueri secara otomatis).

Panduan keandalan Dataflow

Dataflow merupakan layanan pemrosesan data yang terkelola sepenuhnya yang memungkinkan pengembangan pipeline data streaming yang cepat dan sederhana dengan menggunakan library Apache Beam open source. Dataflow meminimalkan latensi, waktu pemrosesan, serta biaya melalui penskalaan otomatis dan batch processing.

Praktik terbaik

Membangun pipeline data siap produksi menggunakan Dataflow - serangkaian dokumen mengenai penggunaan Dataflow termasuk perencanaan, pengembangan, deployment, dan pemantauan pipeline Dataflow.

• Ringkasan - pengantar pipeline Dataflow.
• Perencanaan - mengukur SLO, memahami dampak dari sumber data dan sink terhadap skalabilitas dan performa pipeline, mempertimbangkan ketersediaan tinggi, pemulihan dari bencana (disaster recovery), dan performa jaringan saat menentukan region untuk menjalankan tugas Dataflow Anda.
• Pengembangan dan pengujian - menyiapkan lingkungan deployment, mencegah hilangnya data dengan menggunakan antrean yang dihentikan pengirimannya untuk penanganan error, serta mengurangi latensi dan biaya dengan meminimalkan operasi per-elemen yang mahal. Selain itu, menggunakan batch untuk mengurangi overhead performa tanpa membebani layanan eksternal, memisahkan penggabungan langkah-langkah yang tidak tepat sehingga langkah-langkah tersebut terpisah demi performa yang lebih baik, serta menjalankan pengujian end-to-end dalam praproduksi untuk memastikan jika pipeline terus memenuhi SLO Anda dan persyaratan produksi lainnya.
• Deployment - continuous integration (CI) serta continuous delivery dan deployment (CD), dengan pertimbangan khusus untuk men-deploy versi baru pipeline streaming. Selain itu, contoh pipeline CI/CD, dan beberapa fitur untuk mengoptimalkan penggunaan resource. Terakhir, pembahasan tentang ketersediaan tinggi, redundansi geografis, dan praktik terbaik untuk keandalan pipeline, termasuk isolasi regional, penggunaan banyak snapshot, penanganan pengiriman tugas yang error, serta pemulihan dari error dan gangguan layanan yang berdampak pada pengoperasian pipeline.
• Pemantauan - pengamatan indikator tingkat layanan (SLI) yang merupakan indikator penting bagi performa pipeline, serta menentukan dan mengukur tujuan tingkat layanan (SLO).

Panduan keandalan Dataproc

Dataproc adalah layanan skalabel dan terkelola sepenuhnya yang digunakan untuk menjalankan tugas Apache Hadoop dan Spark. Dengan Dataproc, mesin virtual dapat disesuaikan serta ditingkat turunkan skalanya sesuai kebutuhan. Dataproc terintegrasi secara erat dengan Cloud Storage, BigQuery, Bigtable, dan layanan Google Cloud lainnya.

Praktik terbaik

• Mode Ketersediaan Tinggi Dataproc - membandingkan mode Ketersediaan Tinggi Hadoop/High Availability (HA) dengan mode non-HA default dalam hal nama instance, Apache ZooKeeper, Hadoop Distributed File System (HDFS), dan Yet Another Resource Negotiator (YARN). Pelajari juga cara membuat cluster ketersediaan tinggi.
• Cluster penskalaan otomatis - kapan harus menggunakan penskalaan otomatis Dataproc, cara membuat kebijakan penskalaan otomatis, penggunaan kebijakan multi-cluster, praktik keandalan terbaik untuk konfigurasi penskalaan otomatis, serta metrik dan log.
• Mode Fleksibilitas yang Ditingkatkan/Enhanced Flexibility Mode (EFM) Dataflow - contoh penggunaan Mode Fleksibilitas yang Ditingkatkan untuk meminimalisir penundaan progres tugas, konfigurasi lanjutan seperti partisi dan paralelisme, serta penghentian halus YARN pada cluster EFM.
• Penghentian tuntas - menggunakan penghentian tuntas untuk meminimalkan dampak penghapusan worker dari cluster, cara menggunakan fitur ini dengan worker sekunder, dan contoh perintah untuk penghentian tuntas.
• Tugas yang dapat dimulai ulang - dengan menggunakan setelan opsional, Anda dapat menyetel tugas untuk dimulai ulang jika gagal memitigasi jenis kegagalan tugas yang umum, termasuk masalah kehabisan memori dan reboot mesin virtual Compute Engine yang tidak terduga.

Framework Arsitektur Google Cloud: Pengoptimalan biaya

Kategori dalam Framework Arsitektur Google Cloud memberi rekomendasi desain dan menjelaskan praktik terbaik untuk membantu arsitek, developer, administrator, dan praktisi cloud lainnya mengoptimalkan biaya workload di Google Cloud.

Memindahkan workload IT ke cloud dapat membantu Anda berinovasi dalam skala besar, menghadirkan fitur lebih cepat, dan merespon kebutuhan pelanggan yang terus berubah. Untuk memigrasikan workload atau men-deploy aplikasi yang di-build untuk cloud, Anda memerlukan topologi yang dioptimalkan untuk keamanan, ketahanan, keunggulan operasional, biaya, dan performa.

Dalam kategori pengoptimalan biaya Framework Arsitektur, Anda akan mempelajari cara melakukan hal berikut:

• Mengadopsi dan menerapkan FinOps: Strategi untuk membantu Anda mendorong karyawan agar mempertimbangkan dampak biaya saat menyediakan dan mengelola resource di Google Cloud.
• Memantau dan mengontrol biaya: Praktik terbaik, alat, dan teknik untuk memantau dan mengontrol biaya resource Anda di Google Cloud.
• Mengoptimalkan biaya: Komputasi, container, dan serverless: Biaya spesifik per layanan untuk Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions, dan App Engine.
• Mengoptimalkan biaya: Penyimpanan: Kontrol pengoptimalan biaya untuk Cloud Storage, Persistent Disk, and Filestore.
• Mengoptimalkan biaya: Database dan analisis smart: Kontrol pengoptimalan biaya untuk BigQuery, Bigtable, Spanner, Cloud SQL, Dataflow, dan Dataproc.
• Mengoptimalkan biaya: Networking: Kontrol pengoptimalan biaya untuk resource jaringan Anda di Google Cloud.
• Mengoptimalkan biaya: Operasi cloud: Rekomendasi untuk membantu Anda mengoptimalkan biaya pemantauan dan pengelolaan resource di Google Cloud.

Mengadopsi dan menerapkan FinOps

Dalam dokumen ini Framework Arsitektur Google Cloud ini menguraikan strategi untuk membantu Anda mempertimbangkan dampak biaya dari tindakan dan keputusan Anda saat penyediaaan dan mengelola aset di Google Cloud. Laporan ini membahas FinOps, praktik yang menggabungkan orang, proses, dan teknologi untuk mempromosikan keuangan akuntabilitas dan disiplin pengoptimalan biaya dalam organisasi, terlepas dari ukuran atau kematangannya di cloud.

Panduan di bagian ini ditujukan bagi CTO, CIO, dan eksekutif yang bertanggung jawab mengontrol pengeluaran organisasi mereka di cloud. Panduan ini juga membantu setiap operator cloud memahami dan mengadopsi FinOps.

Setiap karyawan di organisasi Anda dapat membantu mengurangi biaya resource di Google Cloud, apa pun perannya (analis, arsitek, developer, atau administrator). Dalam tim yang sebelumnya tidak perlu melacak biaya infrastruktur, Anda mungkin harus mengedukasi karyawan tentang perlunya tanggung jawab bersama.

Model yang umum digunakan adalah tim FinOps pusat atau Cloud Center of Excellence (CCoE) untuk menstandarkan proses pengoptimalan biaya di semua workload cloud. Model ini mengasumsikan bahwa tim pusat memiliki pengetahuan dan keahlian yang diperlukan untuk mengidentifikasi peluang bernilai tinggi guna meningkatkan efisiensi.

Meskipun kontrol biaya terpusat mungkin berfungsi dengan baik pada tahap awal adopsi cloud saat penggunaan rendah, kontrol ini tidak diskalakan dengan baik saat adopsi dan penggunaan cloud meningkat. Tim pusat mungkin kesulitan dalam melakukan penskalaan, dan tim proyek mungkin tidak menerima keputusan yang dibuat oleh siapa pun di luar tim mereka.

Sebaiknya tim pusat mendelegasikan pengambilan keputusan untuk pengoptimalan resource kepada tim project. Tim pusat dapat mendorong upaya yang lebih luas untuk mendorong adopsi FinOps di seluruh organisasi. Agar setiap tim project dapat mempraktikkan FinOps, tim pusat harus menstandarkan proses, pelaporan, dan alat untuk pengoptimalan biaya. Tim pusat harus bekerja sama dengan tim yang tidak memahami praktik FinOps, dan membantu mereka mempertimbangkan biaya dalam proses pengambilan keputusan. Tim pusat juga harus bertindak sebagai perantara antara tim keuangan dan setiap tim proyek.

Bagian berikutnya menjelaskan prinsip-prinsip desain yang kami rekomendasikan untuk dipromosikan oleh tim pusat Anda.

Mendorong akuntabilitas perorangan

Setiap karyawan yang membuat dan menggunakan resource cloud akan memengaruhi penggunaan dan biaya resource tersebut. Agar organisasi berhasil mengimplementasikan FinOps, tim pusat harus membantu karyawan beralih dari memandang biaya sebagai tanggung jawab orang lain, menjadi tanggung jawab mereka sendiri. Dengan transisi ini, karyawan memiliki dan membuat keputusan biaya yang sesuai untuk workload, tim, dan organisasi mereka. Kepemilikan ini mencakup penerapan tindakan pengoptimalan biaya berbasis data.

Untuk mendorong akuntabilitas biaya, tim pusat dapat melakukan tindakan berikut:

• Ajarkan pengguna tentang peluang dan teknik pengoptimalan biaya.
• Beri hadiah kepada karyawan yang mengoptimalkan biaya, dan rayakan kesuksesan.
• Buat biaya transparan di seluruh organisasi.

Menampilkan Biaya

Agar karyawan dapat mempertimbangkan biaya ketika menyediakan dan mengelola resource di cloud, mereka memerlukan gambaran lengkap tentang data yang relevan, sedekat mungkin secara real time. Data dalam laporan dan dasbor harus menunjukkan biaya dan dampak bisnis dari keputusan anggota tim saat dampak yang relevan terjadi. Data penggunaan dan biaya tim lain dapat berfungsi sebagai dasar pengukuran untuk mengidentifikasi pola deployment yang efisien. Data ini dapat membantu meningkatkan pemahaman bersama tentang cara terbaik untuk menggunakan layanan cloud.

Jika organisasi tidak mendorong dan tidak mempromosikan berbagi data biaya, karyawan mungkin enggan membagikan data. Terkadang, karena alasan bisnis, organisasi mungkin tidak mengizinkan pembagian data biaya mentah. Bahkan dalam kasus ini, sebaiknya hindari kebijakan default yang membatasi akses ke informasi biaya.

Agar biaya terlihat di seluruh organisasi, tim pusat dapat melakukan tindakan berikut:

• Gunakan satu metode yang telah teruji dengan baik untuk menghitung biaya resource cloud sepenuhnya. Misalnya, metode ini dapat mempertimbangkan total pembelanjaan cloud yang disesuaikan untuk diskon yang dibeli dan biaya bersama, seperti biaya database bersama.
• Siapkan dasbor yang memungkinkan karyawan melihat pembelanjaan cloud mereka mendekati real time.
• Guna memotivasi individu dalam tim untuk menghitung biaya mereka sendiri, upayakan visibilitas pembelanjaan cloud oleh seluruh tim.

Meangaktifkan perilaku kolaboratif

Pengelolaan biaya resource cloud yang efektif mengharuskan tim berkolaborasi untuk peningkatkan proses teknis dan operasional mereka. Budaya kolaboratif membantu tim mendesain pola deployment yang hemat biaya berdasarkan serangkaian tujuan dan faktor bisnis yang konsisten.

Untuk memungkinkan perilaku kolaboratif, tim pusat dapat mengambil tindakan berikut:

• Buat proses orientasi workload yang membantu memastikan efisiensi biaya pada tahap desain melalui peninjauan sejawat untuk arsitektur yang diusulkan oleh engineer lain.
• Buat pusat informasi lintas tim tentang pola arsitektur yang hemat biaya.

Menciptakan budaya blameless

Promosikan budaya pembelajaran dan pertumbuhanyang aman untuk mengambil risiko, melakukan koreksi jika diperlukan, dan berinovasi. Pahami bahwa kesalahan, yang terkadang membutuhkan biaya besar, dapat terjadi di tahap mana pun selama siklus proses deployment dan desain IT, seperti di bagian bisnis lainnya.

Daripada menyalahkan dan mempermalukan individu yang telah mengeluarkan terlalu banyak atau memperkenalkan pemborosan, sebaiknya promosikan budaya blameless yang membantu mengidentifikasi penyebab kelebihan biaya dan salah penghitungan. Dalam lingkungan ini, anggota tim lebih suka untuk membagikan pandangan dan pengalaman mereka. Kesalahan dianonimkan dan dibagikan ke seluruh bisnis untuk mencegah pengulangan.

Jangan salah membedakan budaya blameless dengan kurangnya akuntabilitas. Karyawan tetap bertanggung jawab atas keputusan yang mereka buat dan uang yang mereka keluarkan. Namun, ketika kesalahan terjadi, penekanannya adalah pada kesempatan belajar untuk mencegah error tersebut terjadi lagi.

Untuk membangun budaya blameless, tim pusat dapat mengambil tindakan berikut:

• Menjalankan postmortem blameless untuk masalah biaya besar, dengan fokus pada akar penyebab sistemik, bukan orang-orang yang terlibat.
• Apresiasi anggota tim yang merespons pembengkakan biaya dan berbagi pelajaran yang mereka dapatkan. Dorong anggota lain dalam tim untuk berbagi kesalahan, tindakan yang diambil, dan pelajaran yang dipetik.

Fokus pada nilai bisnis

Meskipun praktik FinOps sering difokuskan pada pengurangan biaya, fokus tim pusat harus memungkinkan tim rencana untuk membuat keputusan yang memaksimalkan nilai bisnis resource cloud mereka. Anda mungkin berpikir untuk membuat keputusan yang mengurangi biaya ke titik di mana tingkat layanan minimum terpenuhi. Namun, keputusan semacam itu sering kali memindahkan biaya ke resource lain, sehingga dapat mengakibatkan biaya pemeliharaan yang lebih tinggi, dan dapat meningkatkan total biaya kepemilikan Anda. Misalnya, untuk mengurangi biaya, Anda mungkin memutuskan untuk menggunakan virtual machine (VM) dan bukan layanan terkelola. Namun, solusi berbasis VM memerlukan lebih banyak upaya pemeliharaan jika dibandingkan dengan layanan terkelola, sehingga layanan terkelola mungkin menawarkan nilai bisnis bersih yang lebih tinggi.

Praktik FinOps dapat memberi tim project visibilitas dan insight, data, laporan, analisis yang diperlukan untuk membuat keputusan arsitektur dan operasional yang memaksimalkan nilai bisnis dari resource cloud mereka.

Untuk membantu karyawan berfokus pada nilai bisnis, tim pusat dapat melakukan tindakan berikut:

• Gunakan layanan terkelola dan arsitektur serverless untuk mengurangi total biaya kepemilikan resource komputasi Anda. Untuk informasi selengkapnya, lihat Memilih platform komputasi.

• Hubungkan penggunaan cloud dengan metrik nilai bisnis seperti efisiensi biaya, ketahanan, fitur velocity, dan inovasi yang mendorong keputusan pengoptimalan biaya. Untuk mempelajari tentang metrik nilai bisnis lebih lanjut, lihat laporan resmi Cloud FinOps.

• Terapkan biaya unit untuk semua aplikasi dan layanan Anda yang berjalan di cloud.

Langkah selanjutnya

• Pelajari FinOps lebih lanjut:
  • Memaksimalkan Nilai Bisnis dengan Cloud FinOps
  • Memulai FinOps dengan Google Cloud
  • Dasar FinOps
  • Biaya unit di cloud
• Memantau dan mengontrol biaya
• Mengoptimalkan biaya untuk layanan Google Cloud:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Networking
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Memantau dan mengontrol biaya

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan praktik terbaik, alat, dan teknik untuk membantu Anda melacak dan mengontrol biaya resource di Google Cloud.

Panduan di bagian ini ditujukan bagi pengguna yang menyediakan atau mengelola resource di cloud.

Area fokus pengelolaan biaya

Biaya resource Anda di Google Cloud bergantung pada jumlah resource yang Anda gunakan serta tarif yang ditagih untuk resource.

Untuk mengelola biaya resource cloud, sebaiknya Anda berfokus pada area berikut:

• Visibilitas biaya
• Pengoptimalan resource
• Pengoptimalan tarif

Visibilitas biaya

Lacak jumlah pembelanjaan Anda dan bagaimana resource serta layanan Anda ditagih, sehingga Anda dapat menganalisis pengaruh biaya pada hasil bisnis. Sebaiknya Anda mengikuti model operasi FinOps, yang menyarankan tindakan berikut agar informasi biaya terlihat di seluruh organisasi Anda:

• Alokasi: Menetapkan pemilik untuk setiap item biaya.
• Laporan: Membuat data biaya tersedia, dapat digunakan, dan dapat ditindaklanjuti.
• Perkiraan: Memperkirakan dan melacak pembelanjaan berikutnya.

Pengoptimalan resource

Sesuaikan jumlah dan ukuran resource cloud Anda dengan persyaratan beban workload. Jika memungkinkan, pertimbangkan untuk menggunakan layanan terkelola atau mendesain ulang aplikasi Anda. Biasanya, tim engineering individu memiliki lebih banyak konteks daripada tim FinOps pusat (operasi keuangan) terkait peluang dan teknik untuk mengoptimalkan deployment resource. Sebaiknya tim FinOps bekerja sama dengan setiap tim engineering untuk mengidentifikasi peluang pengoptimalan resource yang dapat diterapkan di seluruh organisasi.

Pengoptimalan tarif

Tim FinOps sering membuat keputusan pengoptimalan tarif secara terpusat. Sebaiknya, setiap tim engineering bekerja sama dengan tim FinOps pusat untuk memanfaatkan diskon besar-besaran untuk reservasi, penggunaan sesuai komitmen, Spot VM, harga tetap, serta diskon volume dan kontrak.

Rekomendasi desain

Bagian ini menyarankan pendekatan yang dapat Anda gunakan untuk memantau dan mengontrol biaya.

Penagihan gabungan dan pengelolaan resource

Untuk mengelola penagihan dan resource di Google Cloud secara efisien, sebaiknya gunakan satu akun penagihan untuk organisasi Anda, serta gunakan mekanisme penagihan balik internal untuk mengalokasikan biaya. Gunakan beberapa akun penagihan untuk organisasi dan perusahaan yang berstruktur longgar dengan entitas yang tidak saling memengaruhi. Misalnya, reseller mungkin memerlukan akun berbeda untuk setiap pelanggan. Menggunakan akun penagihan terpisah juga dapat membantu Anda memenuhi peraturan pajak spesifik per negara.

Praktik terbaik lainnya yang direkomendasikan adalah memindahkan semua project yang Anda kelola ke dalam organisasi Anda. Sebaiknya gunakan Resource Manager untuk membuat hierarki resource yang membantu Anda mencapai sasaran berikut:

• Buat hierarki kepemilikan resource berdasarkan hubungan setiap resource dengan induk langsungnya.
• Kontrol cara kebijakan akses dan tag atau label alokasi biaya dilampirkan dan diwarisi oleh resource di organisasi Anda.

Selain itu, sebaiknya alokasikan biaya layanan bersama secara proporsional berdasarkan konsumsi. Tinjau dan sesuaikan parameter alokasi biaya secara berkala berdasarkan perubahan sasaran dan prioritas bisnis Anda.

Lacak atau alokasikan biaya menggunakan tag atau label

Tag dan label adalah dua metode berbeda yang dapat Anda gunakan untuk menganotasi resource Google Cloud. Tag memberikan lebih banyak kemampuan daripada label. Misalnya, Anda dapat mengimplementasikan kontrol terperinci atas resource dengan membuat kebijakan Identity and Access Management (IAM) yang kondisional berdasarkan apakah tag dilampirkan ke resource yang didukung. Selain itu, tag yang terkait dengan resource diwarisi oleh semua resource turunan dalam hierarki. Untuk informasi selengkapnya tentang perbedaan antara tag dan label, lihat Ringkasan tag.

Jika Anda membuat framework baru untuk alokasi dan pelacakan biaya, sebaiknya gunakan tag.

Untuk mengategorikan data biaya pada tingkat perincian yang diperlukan, tetapkan skema pemberian tag atau pelabelan yang sesuai dengan mekanisme penagihan balik organisasi Anda dan membantu Anda mengalokasikan biaya dengan tepat. Anda dapat menentukan tag di level organisasi atau project. Anda dapat menetapkan label di level project, dan menentukan sekumpulan label yang dapat diterapkan secara default ke semua project.

Tentukan proses untuk mendeteksi dan memperbaiki anomali pemberian tag dan pelabelan serta project tidak berlabel. Misalnya, dari Inventaris Aset Cloud, Anda dapat mendownload inventaris (file .csv) yang berisi semua resource dalam sebuah project dan menganalisis inventaris tersebut untuk mengidentifikasi resource yang tidak diberi tag atau label apa pun.

Untuk memantau biaya resource dan layanan bersama (misalnya, datastore umum, cluster multi-tenant, dan langganan dukungan), pertimbangkan untuk menggunakan tag atau label khusus untuk mengidentifikasi project yang berisi resource bersama.

Mengonfigurasi kontrol akses penagihan

Untuk mengontrol akses ke Penagihan Cloud, sebaiknya Anda menetapkan peran Billing Account Administrator hanya kepada pengguna yang mengelola informasi kontak penagihan. Misalnya, karyawan di bidang keuangan, akuntansi, dan operasi mungkin memerlukan peran ini.

Untuk menghindari titik tunggal kegagalan untuk dukungan penagihan, tetapkan peran Billing Account Administrator ke beberapa pengguna atau ke grup. Hanya pengguna dengan peran Billing Account Administrator yang dapat menghubungi dukungan. Untuk panduan mendetail, lihat Contoh kontrol akses Penagihan Cloud dan Peran Penting.

Buat konfigurasi berikut untuk mengelola akses ke penagihan:

• Untuk mengaitkan akun penagihan dengan project, anggota memerlukan peran Billing Account User di akun penagihan dan peran Project Billing Manager di project tersebut.
• Agar tim dapat mengaitkan akun penagihan dengan project secara manual, Anda dapat menetapkan peran Project Billing Manager di tingkat organisasi dan peran Billing Account User di akun penagihan. Anda dapat mengotomatiskan pengaitan akun penagihan selama pembuatan project dengan menetapkan peran Project Billing Manager dan Billing Account User ke akun layanan. Sebaiknya batasi peran Billing Account Creator atau hapus semua penetapan peran ini.
• Untuk mencegah pemadaman layanan yang disebabkan oleh perubahan yang tidak disengaja pada status penagihan project, Anda dapat mengunci penautan antara project dan akun penagihannya. Untuk informasi selengkapnya, lihat Mengamankan link antara project dan akun penagihannya.

Mengonfigurasi laporan penagihan

Siapkan laporan penagihan untuk menyediakan data bagi metrik utama yang perlu Anda lacak. Sebaiknya Anda melacak metrik berikut:

• Tren biaya
• Konsumen terbesar (menurut project dan produk)
• Area pengeluaran yang tidak teratur
• Insight utama dari seluruh organisasi sebagai berikut:
  • Deteksi anomali
  • Tren dari waktu ke waktu
  • Tren yang terjadi dalam pola yang ditetapkan (misalnya, bulan ke bulan)
  • Perbandingan biaya dan analisis tolok ukur antara workload internal dan eksternal
  • Pelacakan kasus bisnis dan realisasi nilai (misalnya, biaya cloud dibandingkan dengan biaya resource lokal yang serupa)
  • Memvalidasi yang ditagih Google Cloud sesuai harapan dan akurat

Menganalisis tren dan memperkirakan biaya

Sesuaikan dan analisis laporan biaya menggunakan Ekspor Penagihan BigQuery dan visualisasikan data biaya menggunakan Looker Studio. Nilai tren biaya sebenarnya dan jumlah yang mungkin Anda keluarkan dengan menggunakan alat perkiraan.

Mengoptimalkan penggunaan dan biaya resource

Bagian ini merekomendasikan praktik terbaik untuk membantu Anda mengoptimalkan penggunaan dan biaya resource di seluruh layanan Google Cloud.

Untuk mencegah pengeluaran berlebih, pertimbangkan untuk mengonfigurasi anggaran dan pemberitahuan default dengan batas tinggi untuk semua project Anda. Agar tetap sesuai dengan anggaran, sebaiknya Anda melakukan hal berikut:

• Konfigurasikan anggaran dan pemberitahuan untuk project yang memerlukan batas penggunaan absolut (misalnya, project pelatihan atau sandbox).

• Tentukan anggaran berdasarkan anggaran keuangan yang perlu Anda lacak. Misalnya, jika suatu departemen memiliki anggaran cloud secara keseluruhan, tetapkan cakupan anggaran Google Cloud untuk menyertakan project tertentu yang perlu Anda lacak.

• Untuk memastikan anggaran dipertahankan, delegasikan tanggung jawab untuk mengonfigurasi anggaran dan pemberitahuan kepada tim yang memiliki workload.

Untuk membantu mengoptimalkan biaya, sebaiknya Anda juga melakukan hal berikut:

• Batasi penggunaan API jika memiliki dampak bisnis minimal atau tidak berdampak sama sekali. Pembatasan dapat berguna untuk project pelatihan atau sandbox dan untuk project dengan anggaran tetap (misalnya, analisis ad-hoc di BigQuery). Pembatasan tidak menghapus semua resource dan data dari project terkait.
• Gunakan quotas untuk menetapkan batas ketat yang membatasi deployment resource. Kuota membantu Anda mengontrol biaya dan mencegah penggunaan yang berbahaya atau penyalahgunaan resource. Kuota diterapkan di level project, per jenis resource dan lokasi.
• Lihat dan terapkan rekomendasi pengoptimalan biaya di Hub Rekomendasi.
• Beli diskon abonemen (CUD) guna menghemat biaya resource untuk workload dengan kebutuhan resource yang dapat diprediksi.

Alat dan teknik

Karakteristik penyediaan on demand dan bayar per penggunaan cloud membantu Anda mengoptimalkan pembelanjaan IT Anda. Bagian ini menjelaskan alat yang disediakan oleh Google Cloud dan teknik yang dapat Anda gunakan untuk melacak dan mengontrol biaya resource di cloud. Sebelum Anda menggunakan alat dan teknik ini, tinjau konsep dasar Penagihan Cloud.

Laporan penagihan

Google Cloud menyediakan laporan penagihan dalam Konsol Google Cloud untuk membantu Anda melihat pengeluaran saat ini dan yang diperkirakan. Dengan laporan penagihan, Anda dapat melihat data biaya di satu halaman, menemukan dan menganalisis tren, memperkirakan biaya akhir periode, serta mengambil tindakan korektif jika diperlukan.

Laporan penagihan menyediakan data berikut:

• Biaya dan tren biaya untuk periode tertentu, disusun sebagai berikut:
  • Menurut akun penagihan
  • Menurut project
  • Menurut produk (misalnya, Compute Engine)
  • Menurut SKU (misalnya, alamat IP statis)
• Potensi biaya jika diskon atau kredit promo dikecualikan
• Perkiraan pembelanjaan

Ekspor data ke BigQuery

Anda dapat mengekspor laporan penagihan ke BigQuery, dan menganalisis biaya menggunakan tampilan data historis dan terperinci, termasuk data yang dikategorikan menggunakan label. Anda dapat melakukan analisis yang lebih canggih menggunakan BigQuery ML. Sebaiknya aktifkan ekspor laporan penagihan ke BigQuery saat Anda membuat akun Penagihan Cloud. Set data BigQuery Anda berisi data penagihan dari tanggal Anda menyiapkan ekspor Penagihan Cloud. Set data tidak mencakup data untuk periode sebelum Anda mengaktifkan ekspor.

Catatan: Data penagihan yang diekspor mungkin berbeda dengan data di invoice penagihan, dikarenakan data yang terlambat dilaporkan, variasi stempel waktu, error dan penyesuaian, serta pajak. Untuk informasi selengkapnya, lihat Perbedaan antara data yang diekspor dan invoice.

Untuk memvisualisasikan data biaya, Anda dapat membuat dasbor kustom yang terintegrasi dengan BigQuery (contoh template: Looker, Looker Studio).

Anda dapat menggunakan tag dan label sebagai kriteria untuk memfilter data penagihan yang diekspor. Jumlah label yang disertakan dalam ekspor penagihan dibatasi. Hingga 1.000 peta label dalam jangka waktu satu jam akan dipertahankan. Label tidak akan muncul di invoice PDF atau CSV. Pertimbangkan untuk membuat anotasi resource menggunakan tag atau label yang menunjukkan unit bisnis, unit penagihan balik internal, dan metadata lain yang relevan.

Kontrol akses penagihan

Anda dapat mengontrol akses ke Penagihan Cloud untuk resource tertentu dengan menentukan kebijakan Identity and Access Management (IAM) untuk resource tersebut. Untuk memberikan atau membatasi akses ke Penagihan Cloud, Anda dapat menetapkan kebijakan IAM di level organisasi, level akun penagihan, atau level project.

Catatan: Meskipun akun penagihan ditautkan ke project, akun penagihan bukanlah induk dari project di IAM. Project tidak mewarisi izin dari akun penagihan yang tertaut.

Kontrol akses untuk penagihan dan pengelolaan resource mengikuti prinsip pemisahan tugas. Setiap pengguna hanya memiliki izin yang diperlukan untuk peran bisnisnya. Peran Administrator Organisasi dan Administrator Penagihan tidak memiliki izin yang sama.

Anda dapat menetapkan izin terkait penagihan di tingkat akun penagihan dan tingkat organisasi. Peran yang umum adalah Billing Account Administrator, Billing Account User, dan Billing Account Viewer.

Sebaiknya gunakan penagihan dengan invoice, atau konfigurasikan metode pembayaran cadangan. Pertahankan setelan kontak dan notifikasi untuk penagihan dan pembayaran.

Anggaran, pemberitahuan, dan kuota

Anggaran membantu Anda melacak biaya Google Cloud sebenarnya terhadap pembelanjaan yang direncanakan. Saat membuat anggaran, Anda dapat mengonfigurasi aturan pemberitahuan untuk memicu notifikasi email saat pengeluaran aktual atau yang diperkirakan melebihi batas yang ditentukan. Anda juga dapat menggunakan anggaran untuk mengotomatiskan respons pengendalian biaya.

Anggaran dapat memicu pemberitahuan untuk memberi tahu Anda tentang penggunaan resource dan tren biaya, serta meminta Anda untuk mengambil tindakan pengoptimalan biaya. Namun, anggaran tidak akan mencegah penggunaan atau penagihan layanan Anda jika biaya sebenarnya mencapai atau melebihi anggaran atau nilai minimum. Untuk mengontrol biaya secara otomatis, Anda dapat menggunakan notifikasi anggaran guna menonaktifkan Penagihan Cloud secara terprogram untuk sebuah project. Anda juga dapat membatasi penggunaan API untuk menghentikan tagihan setelah batas penggunaan yang ditentukan.

Anda dapat mengonfigurasi pemberitahuan untuk akun penagihan dan project. Konfigurasi setidaknya satu anggaran untuk satu akun.

Untuk mencegah penyediaan resource di luar level yang ditentukan atau untuk membatasi volume operasi tertentu, Anda dapat menetapkan quotas pada resource atau level API. Berikut adalah contoh cara menggunakan kuota:

• Mengontrol jumlah panggilan API per detik.
• Batasi jumlah VM yang dibuat.
• Batasi jumlah data yang dikueri per hari di BigQuery.

Pemilik project dapat mengurangi jumlah kuota yang dapat ditagihkan terhadap batas kuota, dengan menggunakan Service Usage API untuk menerapkan penggantian konsumen ke batas kuota tertentu. Untuk informasi selengkapnya, lihat Membuat penggantian kuota konsumen.

Peningkatan efisiensi workload

Kami merekomendasikan strategi berikut untuk membantu membuat workload Anda di Google Cloud hemat biaya:

• Optimalkan penggunaan resource dengan meningkatkan efisiensi produk.
• Mengurangi tingkat yang ditagih untuk resource.
• Mengontrol dan membatasi penggunaan dan pengeluaran resource.

Saat memilih teknik pengurangan biaya dan fitur Google Cloud, pertimbangkan upaya yang diperlukan dan penghematan yang diharapkan, seperti yang ditunjukkan pada grafik berikut:

Berikut adalah ringkasan teknik yang ditampilkan dalam grafik sebelumnya:

• Teknik berikut berpotensi menghasilkan penghematan yang tinggi dengan sedikit upaya:
  • Diskon abonemen
  • Penskalaan otomatis
  • Slot BigQuery
• Teknik berikut berpotensi menghasilkan penghematan yang tinggi dengan upaya tingkat menengah hingga tinggi:
  • Spot VM
  • Merancang ulang sebagai aplikasi serverless atau dalam container
  • Peralihan ke platform baru untuk menggunakan layanan terkelola
• Teknik berikut berpotensi menghasilkan penghematan sedang dengan upaya sedang:
  • Jenis mesin kustom
  • Pengelolaan siklus proses Cloud Storage
  • Penyesuaian ukuran
  • Mengklaim kembali resource nonaktif

Teknik yang dijelaskan di bagian berikut dapat membantu Anda meningkatkan efisiensi workload.

Pemfaktoran ulang atau perancangan ulang

Anda dapat menghemat biaya yang signifikan dengan memfaktorkan ulang atau merancang ulang workload Anda untuk menggunakan produk Google Cloud. Misalnya, beralih ke layanan serverless (seperti Cloud Storage, Cloud Run, BigQuery, dan Cloud Functions) yang mendukung penskalaan hingga nol dapat membantu meningkatkan efisiensi. Untuk menghitung dan membandingkan biaya produk tersebut, Anda dapat menggunakan kalkulator harga.

Penyesuaian ukuran

Teknik ini membantu Anda memastikan bahwa skala infrastruktur sesuai dengan penggunaan yang dimaksudkan. Strategi ini relevan terutama untuk solusi infrastructure-as-a-service (IaaS), di mana Anda membayar untuk infrastruktur yang mendasarinya. Misalnya, Anda telah men-deploy 50 VM, tetapi VM tersebut tidak sepenuhnya digunakan, dan Anda memutuskan bahwa workload dapat berjalan secara efektif pada lebih sedikit VM (atau lebih kecil). Dalam hal ini, Anda dapat menghapus atau mengubah ukuran beberapa VM. Google Cloud memberikan rekomendasi penyesuaian guna membantu Anda mendeteksi peluang untuk menghemat uang tanpa memengaruhi performa dengan menyediakan VM yang lebih kecil. Penyesuaian ukuran memerlukan lebih sedikit upaya jika dilakukan selama fase desain dibandingkan setelah men-deploy resource ke produksi.

Penskalaan otomatis

Jika produk yang Anda gunakan mendukung penskalaan otomatis dinamis, pertimbangkan untuk merancang workload guna memanfaatkan penskalaan otomatis untuk mendapatkan manfaat dari segi biaya dan performa. Misalnya, untuk workload yang membutuhkan komputasi intensif, Anda dapat menggunakan grup instance terkelola di Compute Engine atau memasukkan aplikasi dalam container dan men-deploy-nya ke cluster Google Kubernetes Engine.

Rekomendasi Active Assist

Active Assist menggunakan data, kecerdasan, dan machine learning untuk mengurangi kompleksitas cloud dan upaya administratif. Active Assist memudahkan pengoptimalan keamanan, performa, dan biaya topologi cloud Anda. Solusi ini memberikan rekomendasi cerdas untuk mengoptimalkan biaya dan penggunaan Anda. Anda dapat menerapkan rekomendasi ini agar dapat langsung menghemat biaya dan meningkatkan efisiensi.

Berikut adalah contoh rekomendasi yang diberikan oleh Active Assist:

• Penyesuaian ukuran resource Compute Engine: Ubah ukuran instance VM Anda untuk mengoptimalkan biaya dan performa berdasarkan penggunaan. Identifikasi dan hapus atau cadangkan VM nonaktif dan persistent disk untuk mengoptimalkan biaya infrastruktur Anda.
• Diskon abonemen (CUD): Google Cloud menganalisis penggunaan historis, menemukan jumlah komitmen yang optimal untuk workload Anda, dan memberikan rekomendasi yang mudah dipahami dan dapat ditindaklanjuti untuk menghemat biaya. Untuk informasi selengkapnya, lihat Pemberi rekomendasi diskon abonemen.
• Project tanpa pengawasan: Temukan project tanpa pengawasan di organisasi Anda, lalu hapus atau klaim kembali project tersebut. Untuk informasi selengkapnya, lihat Pemberi rekomendasi project tanpa pengawasan.

Untuk mengetahui daftar lengkapnya, lihat Pemberi rekomendasi.

Langkah selanjutnya

• Pelajari konsep Penagihan Cloud
• Menetapkan anggaran dan pemberitahuan anggaran
• Optimalkan biaya untuk layanan komputasi, penyimpanan, database, jaringan, dan operasi:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Networking
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Mengoptimalkan biaya: Compute, container, dan serverless

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan biaya virtual machine (VM), container, dan resource serverless di Google Cloud.

Panduan di bagian ini ditujukan bagi arsitek, developer, dan administrator yang bertanggung jawab untuk menyediakan dan mengelola resource komputasi untuk workload di cloud.

Resource komputasi merupakan bagian terpenting dari infrastruktur cloud Anda. Saat Anda memigrasikan workload ke Google Cloud, pilihan pertama yang umum adalah Compute Engine, yang memungkinkan Anda menyediakan dan mengelola VM secara efisien di cloud. Compute Engine menawarkan berbagai jenis mesin, dan tersedia secara global di semua region Google Cloud. Dengan jenis mesin kustom dan bawaan Compute Engine, Anda dapat menyediakan VM yang menawarkan kapasitas komputasi serupa dengan infrastruktur lokal, sehingga Anda dapat mempercepat proses migrasi. Compute Engine memberi Anda keuntungan harga dengan membayar hanya untuk infrastruktur yang Anda gunakan dan memberikan penghematan signifikan saat Anda menggunakan resource komputasi lebih banyak dengan diskon untuk penggunaan berkelanjutan.

Selain Compute Engine, Google Cloud menawarkan container dan layanan komputasi serverless. Pendekatan serverless dapat lebih hemat biaya untuk layanan baru yang tidak selalu berjalan (misalnya, API, pemrosesan data, dan pemrosesan peristiwa).

Bersama dengan rekomendasi umum, dokumen ini memberikan panduan untuk membantu Anda mengoptimalkan biaya resource komputasi saat menggunakan produk berikut:

• Compute Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• App Engine

Rekomendasi umum

Rekomendasi berikut berlaku untuk semua komputasi, container, dan layanan serverless di Google Cloud yang dibahas di bagian ini.

Lacak penggunaan dan biaya

Gunakan alat dan teknik berikut untuk memantau penggunaan dan biaya resource:

• Lihat dan respons rekomendasi pengoptimalan biaya di Hub Rekomendasi.
• Dapatkan notifikasi email untuk potensi peningkatan penggunaan dan biaya resource dengan mengonfigurasi pemberitahuan anggaran.
• Kelola dan tanggapi pemberitahuan secara terprogram menggunakan layanan Pub/Sub dan Cloud Functions.

Mengontrol penyediaan resource

Gunakan rekomendasi berikut untuk mengontrol jumlah resource yang disediakan di cloud dan lokasi tempat resource dibuat:

• Untuk membantu memastikan konsumsi dan biaya resource tidak melebihi perkiraan, gunakan quotas resource.
• Sediakan resource di region berbiaya terendah yang memenuhi persyaratan latensi workload Anda. Untuk mengontrol tempat resource disediakan, Anda dapat menggunakan batasan kebijakan organisasi gcp.resourceLocations.

Dapatkan diskon untuk abonemen

Diskon abonemen (CUD) ideal untuk workload dengan kebutuhan resource yang dapat diprediksi. Setelah memigrasikan workload Anda ke Google Cloud, temukan dasar pengukuran untuk resource yang diperlukan, dan dapatkan diskon yang lebih besar untuk komitmen penggunaan. Misalnya, beli komitmen satu atau tiga tahun, dan dapatkan diskon besar untuk harga VM Compute Engine.

Mengotomatiskan pelacakan biaya menggunakan label

Menentukan dan menetapkan label secara konsisten. Berikut adalah contoh cara menggunakan label untuk mengotomatiskan pelacakan biaya:

• Untuk VM yang hanya digunakan developer selama jam kerja, tetapkan label env: development. Anda dapat menggunakan Cloud Scheduler untuk menyiapkan Cloud Function serverless untuk mematikan VM ini setelah jam kerja, dan memulai ulang jika diperlukan.

• Untuk aplikasi yang memiliki beberapa layanan Cloud Run dan instance Cloud Functions, tetapkan label yang konsisten ke semua resource Cloud Run dan Cloud Functions. Identifikasi area berbiaya tinggi, dan ambil tindakan untuk mengurangi biaya.

Menyesuaikan laporan penagihan

Konfigurasikan laporan Penagihan Cloud Anda dengan menyiapkan filter yang diperlukan dan mengelompokkan data sesuai kebutuhan (misalnya, berdasarkan project, layanan, atau label).

Mempromosikan budaya hemat biaya

Latih developer dan operator Anda tentang infrastruktur cloud. Buat dan promosikan program pembelajaran menggunakan kelas tradisional atau online, grup diskusi, ulasan sejawat, pemrograman berpasangan, dan game hemat biaya. Seperti yang ditunjukkan dalam riset DORA Google, budaya organisasi adalah pendorong utama untuk meningkatkan performa, mengurangi pengerjaan ulang dan kejenuhan, serta mengoptimalkan biaya. Dengan memberi karyawan visibilitas tentang biaya sumber daya mereka, Anda membantu mereka menyelaraskan prioritas dan aktivitas dengan tujuan serta batasan bisnis.

Compute Engine

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya resource Compute Engine. Selain panduan ini, sebaiknya ikuti rekomendasi umum yang dibahas sebelumnya.

Memahami model penagihan

Guna mempelajari opsi penagihan untuk Compute Engine, lihat Harga.

Menganalisis konsumsi resource

Untuk membantu Anda memahami konsumsi resource di Compute Engine, ekspor data penggunaan ke BigQuery. Buat kueri datastore BigQuery untuk menganalisis tren penggunaan CPU virtual (vCPU) project Anda, dan menentukan jumlah vCPU yang dapat Anda peroleh kembali. Jika Anda telah menentukan batas jumlah core per project, analisis tren penggunaan untuk menemukan anomali dan mengambil tindakan korektif.

Mendapatkan kembali resource yang tidak ada aktivitas

Gunakan rekomendasi berikut untuk mengidentifikasi dan mendapatkan kembali VM dan disk yang tidak digunakan, seperti VM untuk project bukti konsep yang tidak diprioritaskan:

• Gunakan rekomendasi VM yang tidak aktif untuk mengidentifikasi persistent disk dan VM yang tidak aktif berdasarkan metrik penggunaan.
• Sebelum menghapus resource, nilai potensi dampak tindakan dan rencanakan untuk membuat ulang resource jika diperlukan.
• Sebelum menghapus VM, pertimbangkan untuk mengambil snapshot. Saat Anda menghapus VM, disk yang terpasang akan dihapus, kecuali jika Anda telah memilih opsi Keep disk.
• Jika memungkinkan, pertimbangkan untuk menghentikan VM, bukan menghapusnya. Ketika Anda menghentikan VM, instance akan dihentikan, tetapi disk dan alamat IP akan dipertahankan hingga Anda melepaskan atau menghapusnya.

Menyesuaikan kapasitas agar cocok dengan permintaan

Menjadwalkan VM Anda untuk memulai dan berhenti secara otomatis. Misalnya, jika VM hanya digunakan delapan jam sehari selama lima hari dalam seminggu (artinya 40 jam dalam seminggu), Anda berpotensi mengurangi biaya hingga 75 persen dengan menghentikan VM selama 128 jam dalam seminggu saat VM tidak digunakan.

Skalakan kapasitas komputasi secara otomatis on-demand menggunakan grup instance terkelola. Anda dapat menskalakan kapasitas secara otomatis berdasarkan parameter yang penting bagi bisnis Anda (misalnya, penggunaan CPU atau kapasitas load balancing).

Memilih jenis mesin yang sesuai

Sesuaikan ukuran VM agar sesuai dengan persyaratan komputasi workload Anda menggunakan pemberi rekomendasi jenis mesin VM.

Untuk workload dengan persyaratan resource yang dapat diprediksi, sesuaikan jenis mesin dengan kebutuhan Anda dan hemat uang dengan menggunakan VM kustom.

Untuk workload pemrosesan batch yang fault-tolerant, pertimbangkan untuk menggunakan Spot VM. Komputasi berperforma tinggi (HPC), big data, transcoding media, pipeline (CI/CD) continuous integration dan continuous delivery, serta aplikasi web stateless adalah contoh workload yang dapat di-deploy di Spot VM. Untuk contoh cara Descartes Labs mengurangi biaya analisisnya dengan menggunakan preemptible VM (versi lama Spot VM) untuk memproses citra satelit, lihat studi kasus Descartes Labs.

Mengevaluasi opsi lisensi

Saat memigrasikan workload pihak ketiga ke Google Cloud, Anda mungkin dapat mengurangi biaya dengan menggunakan bring your own license (BYOL). Misalnya, untuk men-deploy VM Server Microsoft Windows, daripada menggunakan image premium yang menimbulkan biaya tambahan untuk lisensi pihak ketiga, Anda dapat membuat dan menggunakan image BYOL Windows kustom. Kemudian, Anda hanya membayar infrastruktur VM yang digunakan di Google Cloud. Strategi ini membantu Anda terus merealisasikan nilai dari investasi yang ada dalam lisensi pihak ketiga.

Jika Anda memutuskan untuk menggunakan pendekatan BYOL, sebaiknya lakukan hal berikut:

• Sediakan jumlah core CPU komputasi yang diperlukan secara terpisah dari memori dengan menggunakan jenis mesin kustom, dan batasi biaya lisensi pihak ketiga untuk jumlah core CPU yang Anda butuhkan.
• Kurangi jumlah vCPU per inti dari 2 menjadi 1 dengan menonaktifkan multithreading simultan (SMT), dan kurangi biaya lisensi Anda hingga 50 persen.

Jika workload pihak ketiga Anda memerlukan hardware khusus untuk memenuhi persyaratan keamanan atau kepatuhan, Anda dapat menggunakan bring your own license (BYOL) ke sole-tenant node.

Google Kubernetes Engine

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya resource GKE.

Selain rekomendasi berikut, lihat rekomendasi umum yang dibahas sebelumnya:

• Gunakan GKE Autopilot agar GKE memaksimalkan efisiensi infrastruktur cluster Anda. Anda tidak perlu memantau kondisi node, menangani pengemasan berkelompok, atau menghitung kapasitas yang dibutuhkan workload Anda.
• Sesuaikan penskalaan otomatis GKE menggunakan Horizontal Pod Autoscaler (HPA), Penskalaan Otomatis Pod Vertikal (VPA), Cluster Autoscaler (CA), atau penyediaan otomatis node berdasarkan persyaratan workload Anda.
• Untuk workload batch yang tidak sensitif terhadap latensi saat memulai, gunakan profil penskalaan otomatis pengoptimalan-utilisasi untuk membantu meningkatkan pemanfaatan cluster.
• Gunakan penyediaan otomatis node untuk memperluas autoscaler cluster GKE, serta membuat dan menghapus node pool secara efisien berdasarkan spesifikasi pod yang tertunda tanpa penyediaan yang berlebihan.
• Gunakan kumpulan node terpisah: node pool statis untuk beban statis, dan node pool dinamis dengan grup penskalaan otomatis cluster untuk beban dinamis.
• Gunakan Spot VM untuk kumpulan node Kubernetes jika pod Anda fault-tolerant dan dapat berhenti dengan baik dalam waktu kurang dari 25 detik. Dikombinasikan dengan autoscaler cluster GKE, strategi ini membantu Anda memastikan bahwa kumpulan node dengan VM berbiaya lebih rendah (dalam hal ini, kumpulan node dengan VM Spot) diskalakan terlebih dahulu.
• Pilih jenis mesin yang hemat biaya (misalnya: E2, N2D, T2D), yang memberikan performa ke harga 20–40% lebih tinggi.
• Gunakan pengukuran penggunaan GKE untuk menganalisis profil penggunaan cluster Anda berdasarkan namespace dan label. Identifikasi tim atau aplikasi yang paling banyak menghabiskan waktu, lingkungan atau komponen yang menyebabkan lonjakan penggunaan atau biaya, dan tim yang menghabiskan resource.
• Gunakan kuota resource dalam cluster multi-tenant untuk mencegah tenant menggunakan lebih banyak dari pangsa resource cluster yang ditetapkan.
• Jadwalkan penurunan skala otomatis lingkungan pengembangan dan pengujian setelah jam kerja.
• Ikuti praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE.

Cloud Run

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya resource Cloud Run.

Selain rekomendasi berikut, lihat rekomendasi umum yang dibahas sebelumnya:

• Sesuaikan setelan serentak (default: 80) untuk mengurangi biaya. Cloud Run menentukan jumlah permintaan yang akan dikirim ke instance berdasarkan penggunaan CPU dan memori. Dengan meningkatkan permintaan serentak, Anda dapat mengurangi jumlah instance yang diperlukan.
• Tetapkan batas untuk jumlah instance yang dapat di-deploy.
• Perkirakan jumlah instance yang diperlukan menggunakan metrik Waktu Instance yang Dapat Ditagih. Misalnya, jika metrik menampilkan 100s/s, sekitar 100 instance telah dijadwalkan. Menambahkan buffering 30% untuk mempertahankan performa; yaitu, 130 instance untuk 100 detik lalu lintas.
• Untuk mengurangi dampak cold start, konfigurasikan jumlah minimum instance. Jika tidak ada aktivitas, instance ini akan ditagih sepersepuluh dari harga aslinya.
• Pantau penggunaan CPU, dan sesuaikan batas CPU sesuai kebutuhan.
• Gunakan pengelolaan traffic untuk menentukan konfigurasi yang hemat biaya.
• Sebaiknya gunakan Cloud CDN atau Firebase Hosting untuk menayangkan aset statis.
• Untuk aplikasi Cloud Run yang menangani permintaan secara global, pertimbangkan untuk men-deploy aplikasi ke beberapa region, karena transfer data lintas benua bisa mahal. Desain ini direkomendasikan jika Anda menggunakan load balancer dan CDN.
• Kurangi waktu startup untuk instance Anda, karena waktu startup juga dapat ditagih.
• Beli Diskon Abonemen, dan hemat hingga 17% dari harga sesuai permintaan untuk komitmen satu tahun.

Cloud Functions

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya resource Cloud Functions.

Selain rekomendasi berikut, lihat rekomendasi umum yang dibahas sebelumnya:

• Amati waktu eksekusi fungsi Anda. Lakukan eksperimen dan benchmark untuk merancang fungsi terkecil yang masih memenuhi nilai minimum performa yang Anda perlukan.
• Jika workload Cloud Functions Anda berjalan terus-menerus, pertimbangkan untuk menggunakan GKE atau Compute Engine untuk menangani workload tersebut. Container atau VM dapat menjadi opsi hemat biaya untuk workload yang selalu berjalan.
• Batasi jumlah instance fungsi yang dapat berdampingan.
• Bandingkan performa runtime bahasa pemrograman Cloud Functions dengan workload fungsi Anda. Program dalam bahasa yang dikompilasi memiliki cold start yang lebih lama, tetapi berjalan lebih cepat. Program dalam bahasa pemrograman tafsiran berjalan lebih lambat, tetapi memiliki overhead cold start yang lebih rendah. Fungsi sederhana dan singkat yang sering dijalankan mungkin lebih hemat dalam bahasa pemrograman tafsiran.
• Menghapus file sementara yang ditulis ke disk lokal, yang merupakan sistem file dalam memori. File sementara menggunakan memori yang dialokasikan untuk fungsi Anda, dan terkadang tetap dipertahankan di antara pemanggilan. Jika Anda tidak menghapus file ini, error kehabisan memori mungkin akan terjadi dan memicu cold start, yang meningkatkan waktu dan biaya eksekusi.

App Engine

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya resource App Engine.

Selain rekomendasi berikut, lihat rekomendasi umum yang dibahas sebelumnya:

• Menetapkan instance maksimum berdasarkan lalu lintas dan latensi permintaan Anda. App Engine biasanya menskalakan kapasitas berdasarkan traffic yang diterima aplikasi. Anda dapat mengontrol biaya dengan membatasi jumlah instance yang dapat dibuat oleh App Engine.
• Untuk membatasi memori atau CPU yang tersedia untuk aplikasi Anda, tetapkan class instance. Untuk aplikasi yang menggunakan CPU secara intensif, alokasikan lebih banyak CPU. Uji beberapa konfigurasi untuk menentukan ukuran yang optimal.
• Bandingkan workload App Engine Anda dalam beberapa bahasa pemrograman. Misalnya, workload yang diterapkan dalam satu bahasa mungkin memerlukan lebih sedikit instance dan hemat biaya untuk menyelesaikan tugas tepat waktu dibandingkan workload sama yang diprogram dalam bahasa lain.
• Melakukan pengoptimalan agar cold start lebih sedikit terjadi. Jika memungkinkan, kurangi tugas intensif CPU atau tugas yang berjalan lama yang terjadi dalam cakupan global. Coba uraikan tugas menjadi operasi lebih kecil yang dapat "dimuat dengan lambat" ke dalam konteks permintaan.
• Jika Anda mengharapkan traffic burst, konfigurasikan jumlah minimum instance tidak ada aktivitas yang telah di-pra-penyiapan. Jika tidak mengharapkan traffic, Anda dapat mengonfigurasi instance tidak ada aktivitas minimum ke nol.
• Untuk menyeimbangkan performa dan biaya, jalankan pengujian A/B dengan membagi traffic antara dua versi, masing-masing dengan konfigurasi yang berbeda. Pantau performa dan biaya setiap versi, sesuaikan dengan kebutuhan, dan tentukan konfigurasi yang harus dikirim untuk traffic mana.
• Konfigurasikan permintaan serentak, dan tetapkan permintaan serentak maksimum lebih tinggi daripada default. Makin banyak permintaan yang dapat ditangani setiap instance secara serentak, makin efisien Anda dapat menggunakan instance yang ada untuk menyalurkan lalu lintas.

Langkah selanjutnya

• Pelajari cara mengoptimalkan biaya resource GKE:
  • Menjalankan aplikasi Kubernetes yang hemat biaya di GKE: praktik terbaik
  • Praktik terbaik untuk mengurangi penyediaan GKE yang berlebihan
  • Mengoptimalkan penggunaan resource di cluster GKE multi-tenant menggunakan penyediaan otomatis node
  • Mengurangi biaya dengan memperkecil cluster GKE di luar jam sibuk
  • Menjalankan aplikasi web di GKE menggunakan Spot VM yang hemat biaya
  • Perkirakan biaya GKE Anda di awal siklus pengembangan menggunakan GitLab
  • Seri video: Pengoptimalan Biaya GKE
  • Pelatihan: Mengoptimalkan Biaya untuk GKE
• Pelajari cara mengoptimalkan biaya resource Cloud Run dan Cloud Functions:
  • Mengelola biaya dan keandalan dalam aplikasi yang terkelola sepenuhnya
  • Mengoptimalkan pengelolaan biaya jangka panjang pada aplikasi yang terkelola sepenuhnya
  • Maksimalkan investasi Cloud Run Anda dengan diskon abonemen baru
• Optimalkan biaya untuk penyimpanan, database, jaringan, dan operasi:
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Networking
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Mengoptimalkan biaya: Penyimpanan

Dokumen pada Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan penggunaan dan biaya resource Cloud Storage, Persistent Disk, and Filestore milik Anda.

Panduan pada bagian ini ditujukan bagi para arsitek dan administrator yang bertanggung jawab untuk menyediakan dan mengelola penyimpanan untuk workload di cloud.

Catatan: Untuk mendapatkan panduan tentang cara memilih layanan penyimpanan yang sesuai untuk workload Anda, lihat Rancang strategi penyimpanan untuk workload Cloud Anda.

Cloud Storage

Saat Anda merencanakan Cloud Storage untuk workload Anda, pertimbangkan kebutuhan Anda terkait performa, retensi data, dan pola aksesnya.

Kelas penyimpanan

Pilih kelas penyimpanan yang sesuai dengan kebutuhan retensi-data dan frekuensi-akses workload Anda, seperti yang direkomendasikan pada tabel berikut:

Kebutuhan penyimpanan	Rekomendasi
Data yang sering diakses (analisis throughput tinggi atau data lake, situs, video streaming, dan aplikasi seluler).	Standard Storage
Penyimpanan dengan biaya rendah untuk data yang jarang diakses yang dapat disimpan setidaknya selama 30 hari (misalnya, cadangan dan konten multimedia longtail).	Nearline Storage
Data yang jarang diakses yang bisa disimpan setidaknya selama 90 hari (misalnya, replika data untuk pemulihan dari bencana).	Coldline Storage
Penyimpanan dengan biaya paling rendah untuk data yang jarang diakses yang bisa disimpan setidaknya selama 365 hari (misalnya, arsip hukum dan peraturan).	Archive Storage

Catatan: Kelas Nearline, Coldline, dan Archive Storage lebih hemat daripada Standard Storage, tetapi mereka akan dikenai biaya pengambilan data yang lebih tinggi dan denda penghapusan awal.

Location

Pilih lokasi untuk bucket Anda berdasarkan kebutuhan Anda terkait performa, ketersediaan, dan redundansi data.

• Region direkomendasikan saat region mendekati pengguna akhir Anda. Anda dapat memilih region tertentu, dan mendapatkan redundansi data yang terjamin di dalam region tersebut. Region menawarkan penyimpanan yang cepat, redundan, dan terjangkau untuk banyak set data yang sering diakses oleh pengguna dalam wilayah geografis tertentu.
• Multi-region memberikan ketersediaan tinggi untuk pengguna yang terdistribusi. Namun, biaya penyimpanannya lebih tinggi daripada region. Bucket multi-region direkomendasikan untuk kasus penggunaan penayangan konten dan untuk workload analisis berkinerja rendah.
• Dual-region memberikan ketersediaan tinggi dan redundansi data. Google merekomendasikan bucket dual-region untuk workload analisis berperforma tinggi dan untuk kasus penggunaan yang memerlukan bucket aktif-aktif murni dengan komputasi dan penyimpanan berada di beberapa lokasi yang sama. Dual-region memungkinkan Anda memilih di mana data Anda akan disimpan, yang dapat membantu Anda memenuhi persyaratan kepatuhan. Misalnya, Anda dapat menggunakan bucket dual-region untuk memenuhi kebutuhan spesifik industri terkait jarak fisik antara salinan data Anda yang berada dalam cloud.

Kebijakan siklus proses

Mengoptimalkan biaya penyimpanan untuk objek Anda yang berada dalam Cloud Storage dengan menentukan kebijakan siklus proses. Kebijakan ini membantu menghemat biaya Anda dengan secara otomatis mendowngrade kelas penyimpanan objek tertentu atau menghapus objek tersebut berdasarkan conditions yang Anda tetapkan.

Konfigurasi kebijakan siklus proses berdasarkan seberapa sering objek diakses dan seberapa lama Anda perlu menyimpannya. Berikut ini merupakan contoh kebijakan siklus proses:

• Kebijakan downgrade: Anda memperkirakan suatu set data sering diakses hanya untuk sekitar tiga bulan. Guna mengoptimalkan biaya penyimpanan untuk set data ini, gunakan Standard Storage, dan mengonfigurasi kebijakan siklus proses untuk men-downgrade objek yang lebih lama dari 90 hari ke Coldline storage.

• Kebijakan penghapusan: Suatu set data harus disimpan selama 365 hari untuk memenuhi persyaratan hukum tertentu dan dapat dihapus setelah jangka waktu tersebut. Konfigurasikan kebijakan untuk menghapus objek apa pun yang lebih lama dari 365 hari.

  Untuk membantu Anda memastikan bahwa data yang perlu disimpan untuk jangka waktu tertentu (untuk kepatuhan terhadap hukum atau peraturan) tidak dihapus sebelum tanggal atau waktu tersebut, konfigurasikan kunci kebijakan retensi.

Catatan: Kelas penyimpanan jangka panjang (Nearline, Coldline, dan Archive) akan dikenai biaya pengambilan data yang lebih tinggi dan denda penghapusan awal jika dibandingkan dengan Standard Storage. Jika data yang disimpan dalam kelas penyimpanan jangka panjang perlu sering diakses, Anda dapat menyalin data tersebut ke bucket Standard Storage untuk menghindari peningkatan biaya akses.

Akuntabilitas

Untuk meningkatkan akuntabilitas atas biaya operasional, biaya jaringan, dan biaya pengambilan data, gunakan konfigurasi Requester Pays yang sesuai. Dengan konfigurasi ini, maka biaya akan dibebankan ke departemen atau tim yang menggunakan data tersebut, bukan ke pemilik data.

Tentukan dan tetapkan label pelacakan biaya secara konsisten untuk seluruh bucket dan objek Anda. Mengotomatiskan pelabelan jika memungkinkan.

Redundansi

Gunakan teknik berikut untuk mempertahankan redundansi penyimpanan yang diperlukan tanpa duplikasi data:

• Untuk mempertahankan ketahanan data dengan satu sumber tepercaya, gunakan bucket dual-region atau multi-region bukan salinan data redundan di berbagai bucket. Bucket dual-region dan multi-region menyediakan redundansi di seluruh region. Data Anda direplikasi secara asinkron ke dua atau beberapa lokasi, dan dilindungi dari gangguan regional.
• Jika Anda mengaktifkan pembuatan versi objek, pertimbangkan untuk menetapkan kebijakan siklus proses guna menghapus versi terlama dari suatu objek karena versi yang lebih baru menjadi tidak terbaru. Setiap objek dengan versi lama akan dikenai biaya dengan tarif yang sama seperti objek dengan versi aktif.
• Nonaktifkan kebijakan pembuatan versi objek saat tidak diperlukan lagi.
• Tinjau dan sesuaikan kebijakan retensi pencadangan dan snapshot Anda secara berkala untuk menghindari pencadangan dan retensi data yang tidak perlu.

Persistent Disk

Setiap VM instance yang Anda deploy di Compute Engine memiliki boot disk, dan satu atau beberapa disk data (opsional). Setiap disk akan dikenai biaya tergantung pada ukuran, region, dan jenis disk yang telah disediakan. Setiap snapshot yang Anda ambil dari disk akan dikenai biaya berdasarkan ukuran snapshot tersebut.

Gunakan rekomendasi desain dan operasional berikut untuk membantu Anda mengoptimalkan biaya dari persistent disk milik Anda:

• Jangan mengalokasikan kapasitas disk secara berlebihan. Anda tidak dapat mengurangi kapasitas disk setelah penyediaan. Mulailah dengan disk berukuran kecil, dan tingkatkan ukurannya jika diperlukan. Persistent disk ditagih untuk kapasitas yang disediakan, bukan data yang disimpan di disk.

• Pilih jenis disk yang cocok dengan karakteristik performa workload Anda. SSD menyediakan IOPS dan throughput yang tinggi, tetapi harganya lebih mahal daripada persistent disk standar.

• Gunakan persistent disk regional hanya ketika melindungi data dari gangguan zona dianggap penting. Persistent disk regional direplika ke zona lainnya di dalam region tersebut, sehingga Anda dikenai biaya dua kali lipat untuk disk zona yang setara.

• Lacak penggunaan persistent disk Anda dengan menggunakan Cloud Monitoring, dan siapkan pemberitahuan untuk disk dengan penggunaan rendah.

• Hapus disk yang tidak lagi Anda perlukan.

• Untuk disk yang berisi data yang mungkin Anda perlukan di masa mendatang, pertimbangkan untuk mengarsipkan data ke Cloud Storage berbiaya rendah lalu menghapus disk tersebut.

• Cari dan tanggapi rekomendasi di Hub Rekomendasi.

Pertimbangkan juga untuk menggunakan Hyperdisk sebagai tempat penyimpanan berperforma tinggi dan Ephemeral disk (SSD lokal) sebagai tempat penyimpanan sementara.

Snapshot disk bersifat inkremental secara default dan dikompresi secara otomatis. Pertimbangkan rekomendasi berikut untuk mengoptimalkan biaya snapshot disk Anda:

• Jika memungkinkan, atur data Anda di persistent disk terpisah. Kemudian, Anda dapat memilih untuk mencadangkan disk secara selektif, dan mengurangi biaya disk snapshot.
• Saat Anda membuat snapshot, pilih lokasi berdasarkan persyaratan ketersediaan Anda dan biaya jaringan terkait.
• Jika Anda ingin menggunakan snapshot boot-disk untuk membuat multi-VM, buatlah image dari snapshot, lalu gunakan image tersebut untuk membuat VM Anda. Pendekatan ini membantu Anda menghindari biaya jaringan untuk data yang melintas antara lokasi snapshot dan lokasi di mana Anda memulihkannya.
• Pertimbangkan untuk menyiapkan kebijakan retensi guna meminimalkan biaya penyimpanan jangka panjang untuk snapshot disk.
• Hapus snapshot disk yang tidak lagi Anda perlukan. Setiap snapshot yang berada dalam rantai mungkin bergantung pada data yang disimpan dalam snapshot sebelumnya. Jadi, menghapus sebuah snapshot tidak berarti menghapus seluruh data yang berada dalam snapshot Untuk menghapus data dari snapshot secara definitif, Anda harus menghapus seluruh snapshot yang berada dalam rantai.

Filestore

Biaya instance Filestore bergantung pada tingkat layanan, kapasitas yang disediakan, dan region tempat instance tersebut disediakan. Berikut merupakan rekomendasi desain dan operasional untuk mengoptimalkan biaya instance Filestore Anda:

• Pilih tingkat layanan dan tipe penyimpanan (HDD atau SSD) yang sesuai dengan kebutuhan penyimpanan Anda.
• Jangan mengalokasikan kapasitas secara berlebihan. Mulailah dengan ukuran yang kecil dan tingkatkan ukurannya nanti saat diperlukan. Penagihan Filestore didasarkan pada kapasitas yang disediakan, bukan berdasarkan data yang disimpan.
• Jika memungkinkan, atur data Anda di instance Filestore terpisah. Kemudian, Anda dapat memilih untuk mencadangkan instance secara selektif, dan mengurangi biaya pencadangan Filestore.
• Saat memilih region dan zona, pertimbangkan untuk membuat instance di zona yang sama dengan klien. Anda akan ditagih untuk traffic transfer data dari zona instance Filestore.
• Saat Anda menentukan region tempat cadangan Filestore sebaiknya disimpan, pertimbangkan biaya transfer data untuk menyimpan cadangan di region yang berbeda dari instance sumber.
• Lacak penggunaan instance Filestore dengan menggunakan Cloud Monitoring, dan siapkan pemberitahuan untuk instance dengan penggunaan rendah.
• Perkecil skala kapasitas yang dialokasikan untuk instance Filestore yang memiliki penggunaan rendah. Anda dapat mengurangi kapasitas instance, kecuali untuk paket Dasar.

Langkah selanjutnya

• Tinjau praktik terbaik untuk pengoptimalan biaya Cloud Storage (blog)
• Mengoptimalkan biaya untuk layanan komputasi, database, jaringan, dan operasi:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Networking
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Mengoptimalkan biaya: Database dan analisis smart

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan biaya database dan workload analisis di Google Cloud.

Panduan di bagian ini ditujukan untuk arsitek, developer, dan administrator yang bertanggung jawab untuk penyediaan dan pengelolaan database serta workload analisis di cloud.

Bagian ini mencakup rekomendasi pengoptimalan biaya untuk produk berikut:

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

Cloud SQL adalah database relasional yang terkelola sepenuhnya untuk MySQL, PostgreSQL, dan SQL Server.

Memantau penggunaan

Tinjau metrik di dasbor pemantauan, dan validasikan bahwa deployment memenuhi persyaratan workload Anda.

Mengoptimalkan sumber daya

Berikut ini beberapa rekomendasi untuk membantu Anda mengoptimalkan resource Cloud SQL:

• Desain strategi dengan ketersediaan tinggi dan pemulihan dari bencana yang selaras dengan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) Anda. Bergantung pada workload Anda, sebaiknya lakukan tindakan berikut:
  • Untuk workload yang memerlukan RTO dan RPO yang singkat, gunakan konfigurasi ketersediaan tinggi dan replika untuk failover regional.
  • Untuk workload yang dapat bertahan dari RTO dan RPO yang lebih lama, gunakan cadangan otomatis dan on-demand, yang memerlukan waktu sedikit lebih lama untuk dipulihkan setelah terjadi kegagalan.
• Menyediakan database dengan kapasitas penyimpanan minimum yang diperlukan.
• Untuk menskalakan kapasitas penyimpanan secara otomatis seiring pertumbuhan data Anda, aktifkan fitur peningkatan penyimpanan otomatis.
• Pilih jenis penyimpanan, solid-state drive (SSD) atau hard disk drive (HDD), yang sesuai untuk kasus penggunaan Anda. SSD adalah pilihan paling efisien dan hemat biaya untuk sebagian besar kasus penggunaan. HDD mungkin cocok untuk set data besar (>10 TB) yang tidak sensitif terhadap latensi atau jarang diakses.

Mengoptimalkan tarif

Pertimbangkan untuk membeli diskon abonemen untuk workload dengan kebutuhan resource yang dapat diprediksi. Anda dapat menghemat 25% dari harga on demand untuk komitmen 1 tahun dan 52% untuk komitmen 3 tahun.

Spanner

Spanner adalah database berbasis cloud dengan skala tidak terbatas dan konsistensi kuat yang menawarkan ketersediaan hingga 99,999%.

Memantau penggunaan

Berikut adalah rekomendasi untuk membantu Anda melacak penggunaan resource Spanner:

• Pantau deployment Anda, dan konfigurasikan jumlah node berdasarkan rekomendasi CPU.
• Tetapkan pemberitahuan tentang deployment Anda untuk mengoptimalkan resource penyimpanan. Untuk menentukan konfigurasi yang sesuai, lihat batas per node yang direkomendasikan.

Mengoptimalkan sumber daya

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan resource Spanner:

• Menjalankan workload yang lebih kecil di Spanner dengan biaya yang jauh lebih rendah dengan menyediakan resource menggunakan Unit Pemrosesan (PU) dibandingkan node; satu node Spanner sama dengan 1.000 PU.
• Tingkatkan performa eksekusi kueri dengan menggunakan pengoptimal kueri.
• Buat Pernyataan SQL menggunakan praktik terbaik untuk membuat rencana eksekusi yang efisien.
• Kelola penggunaan dan performa deployment Spanner menggunakan alat Autoscaler. Alat ini memantau instance, menambahkan atau menghapus node secara otomatis, dan membantu Anda memastikan bahwa instance tetap berada dalam batas CPU dan penyimpanan yang direkomendasikan.
• Lindungi dari penghapusan atau penulisan yang tidak disengaja: pemulihan point-in-time (PITR). Database dengan periode retensi data yang lebih lama (terutama database yang sering menimpa data) menggunakan lebih banyak resource sistem dan memerlukan lebih banyak node.
• Tinjau strategi pencadangan Anda, dan pilih di antara opsi berikut:
  • Pencadangan dan pemulihan
  • Mengekspor dan mengimpor

Mengoptimalkan tarif

Saat memutuskan lokasi node Spanner Anda, pertimbangkan perbedaan biaya antara region Google Cloud. Misalnya, node yang di-deploy di region us-central1 memiliki biaya per jam yang jauh lebih rendah dibandingkan node di region southamerica-east1.

Bigtable

Bigtable adalah penyimpanan NoSQL kolom lebar dan berbasis cloud untuk workload berlatensi rendah dan berskala besar.

Memantau penggunaan

Berikut adalah rekomendasi untuk membantu Anda melacak penggunaan resource Bigtable:

• Analisis metrik penggunaan untuk mengidentifikasi peluang pengoptimalan resource.
• Identifikasi hotspot dan hotkey di cluster Bigtable Anda dengan menggunakan alat diagnostik Key Visualizer.

Mengoptimalkan sumber daya

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan resource Bigtable:

• Untuk membantu memastikan penggunaan CPU dan disk yang menyeimbangkan latensi dan kapasitas penyimpanan, evaluasi dan sesuaikan jumlah node dan ukuran cluster Bigtable Anda.
• Pertahankan performa serendah mungkin dengan menskalakan secara terprogram cluster Bigtable Anda untuk menyesuaikan jumlah node secara otomatis.

• Evaluasi jenis penyimpanan (HDD atau SSD) yang paling hemat biaya untuk kasus penggunaan Anda, berdasarkan pertimbangan berikut:

  • Harga penyimpanan HDD lebih murah daripada SSD, tetapi performanya lebih rendah.
  • Harga penyimpanan SSD lebih mahal daripada HDD, tetapi memberikan performa yang lebih cepat dan dapat diprediksi.

  Penghematan biaya dari HDD minimal, relatif terhadap biaya node di cluster Bigtable Anda, kecuali jika Anda menyimpan data dalam jumlah besar. Penyimpanan HDD terkadang sesuai untuk set data besar (>10 TB) yang tidak sensitif terhadap latensi atau jarang diakses.

• Menghapus data yang telah habis masa berlakunya dan tidak digunakan lagi menggunakan pembersihan sampah memori.

• Untuk menghindari hotspot, terapkan praktik terbaik untuk desain row key.

• Desain rencana pencadangan hemat biaya yang sesuai dengan RPO Anda.

• Untuk menurunkan penggunaan cluster dan mengurangi jumlah node, pertimbangkan untuk menambahkan cache kapasitas untuk kueri yang dapat di-cache menggunakan Memorystore.

Bacaan tambahan

• Blog: Panduan dasar tentang pengoptimalan biaya Bigtable
• Blog: Praktik terbaik untuk performa dan pengoptimalan biaya Bigtable

BigQuery

BigQuery adalah data warehouse multicloud serverless, sangat skalabel, dan hemat biaya yang dirancang untuk fleksibilitas bisnis.

Memantau penggunaan

Berikut adalah rekomendasi untuk membantu Anda melacak penggunaan resource BigQuery:

• Visualisasikan biaya BigQuery yang disegmentasi berdasarkan project dan pengguna. Identifikasi kueri yang paling mahal dan mengoptimalkannya.
• Analisis penggunaan slot di seluruh project, tugas, dan reservasi menggunakan tabel metadata INFORMATION_SCHEMA.

Mengoptimalkan sumber daya

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan resource BigQuery:

• Siapkan masa berlaku tingkat set data, tingkat tabel, atau tingkat partisi untuk data berdasarkan strategi kepatuhan Anda.
• Batasi biaya kueri dengan membatasi jumlah byte yang ditagih per kueri. Untuk mencegah error manusia yang tidak disengaja, aktifkan kontrol biaya di level pengguna dan level project.
• Hanya kueri data yang Anda butuhkan. Hindari pemindaian kueri penuh. Untuk menjelajahi dan memahami semantik data, gunakan opsi pratinjau data tanpa biaya.
• Untuk mengurangi biaya pemrosesan dan meningkatkan performa, lakukan partisi dan cluster tabel Anda bila memungkinkan.
• Filter kueri Anda sedini dan sesering mungkin.
• Saat memproses data dari berbagai sumber (seperti Bigtable, Cloud Storage, Google Drive, dan Cloud SQL), hindari duplikasi data, dengan menggunakan model data akses gabungan dan mengkueri data langsung dari sumbernya.
• Manfaatkan Cadangan BigQuery daripada menduplikasi data. Lihat Skenario pemulihan dari bencana (disaster recovery) untuk data.

Mengoptimalkan tarif

Berikut adalah rekomendasi untuk membantu Anda mengurangi tarif penagihan untuk resource BigQuery:

• Evaluasi cara Anda mengedit data, dan manfaatkan harga penyimpanan jangka panjang yang lebih rendah.
• Tinjau perbedaan antara pricing tarif tetap dan on-demand, lalu pilih opsi yang sesuai dengan kebutuhan Anda.
• Pertimbangkan apakah Anda dapat menggunakan pemuatan batch, bukan streaming insert, untuk alur kerja data Anda. Gunakan streaming insert jika data yang dimuat ke BigQuery langsung dipakai.
• Untuk meningkatkan performa dan mengurangi biaya pengambilan data, gunakan hasil kueri yang disimpan dalam cache.

Bacaan tambahan

• Mengontrol biaya BigQuery
• Praktik terbaik pengoptimalan biaya untuk BigQuery
• Memahami prinsip pengoptimalan biaya (PDF)

Dataflow

Dataflow adalah layanan serverless yang cepat dan hemat biaya untuk pemrosesan data batch dan streaming terpadu.

Memantau penggunaan

Berikut adalah rekomendasi untuk membantu Anda melacak penggunaan resource Dataflow:

• Prediksi biaya tugas Dataflow dengan menjalankan eksperimen beban kecil, menemukan performa optimal tugas Anda, dan memperkirakan faktor throughput.
• Dapatkan peningkatan visibilitas ke throughput dan penggunaan CPU dengan menggunakan dasbor kemampuan observasi.
• Amati metrik pipeline terkait performa, eksekusi, dan kondisi kesehatan menggunakan Antarmuka pemantauan Dataflow.

Mengoptimalkan sumber daya

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan resource Dataflow:

• Pertimbangkan Dataflow Prime untuk memproses big data secara efisien.
• Kurangi biaya batch processing menggunakan Flexible Resource Scheduling (FlexRS), untuk pipeline batch yang diskalakan secara otomatis. FlexRS menggunakan penjadwalan lanjutan, Dataflow Shuffle, serta kombinasi VM preemptible dan VM reguler untuk mengurangi biaya pipeline batch.
• Tingkatkan performa dengan menggunakan layanan shuffle dalam memori daripada Persistent Disk dan worker node.
• Agar penskalaan otomatis lebih responsif, dan untuk mengurangi konsumsi resource, gunakan Streaming Engine, yang memindahkan eksekusi pipeline dari worker VM ke backend layanan Dataflow.
• Jika pipeline tidak memerlukan akses ke dan dari internet serta jaringan Google Cloud lainnya, nonaktifkan alamat IP publik. Menonaktifkan akses internet membantu Anda mengurangi biaya jaringan dan meningkatkan keamanan pipeline.
• Ikuti praktik terbaik untuk pipeline yang efisien dengan Dataflow.

Dataproc

Dataproc adalah layanan Apache Spark dan Apache Hadoop terkelola untuk batch processing, pembuatan kueri, streaming, dan machine learning.

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan biaya resource Dataproc:

• Pilih jenis mesin yang sesuai dengan workload Anda.
• Skalakan secara otomatis agar sesuai dengan permintaan menggunakan cluster penskalaan otomatis, dan hanya bayar resource yang Anda butuhkan.
• Jika sebuah cluster dapat dihapus setelah tugas selesai, pertimbangkan untuk menyediakan cluster sementara menggunakan template alur kerja cluster terkelola.
• Untuk menghindari biaya bagi cluster yang tidak aktif, gunakan penghapusan terjadwal, yang memungkinkan Anda menghapus cluster setelah periode nonaktif tertentu, pada waktu tertentu, atau setelah periode tertentu
• Ikuti praktik terbaik untuk membangun cluster yang berjalan lama di Dataproc.
• Beli diskon abonemen untuk workload yang selalu aktif.

Langkah selanjutnya

• Mengoptimalkan biaya untuk layanan komputasi, penyimpanan, jaringan, dan operasi:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Networking
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Mengoptimalkan biaya: Networking

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan biaya resource jaringan di Google Cloud.

Panduan di bagian ini ditujukan bagi arsitek dan administrator yang bertanggung jawab atas penyediaan dan pengelolaan jaringan untuk workload di cloud.

Pertimbangan desain

Perbedaan mendasar antara jaringan lokal dan cloud adalah model biaya dinamis berbasis penggunaan di cloud, dibandingkan dengan biaya jaringan yang tetap di pusat data tradisional.

Saat merencanakan jaringan cloud, penting untuk memahami model pricing yang didasarkan pada rute traffic, sebagai berikut:

• Anda tidak dikenai biaya untuk traffic masuk ke Google Cloud. Resource yang memproses traffic masuk, seperti Cloud Load Balancing, akan dikenai biaya.
• Untuk traffic transfer data, yang mencakup traffic antara virtual machine (VM) di Google Cloud dan traffic dari Google Cloud ke internet dan ke host lokal, harga didasarkan pada faktor berikut:
  • Apakah traffic menggunakan alamat IP eksternal atau internal
  • Apakah traffic melintasi batas zona atau region
  • Apakah traffic meninggalkan Google Cloud
  • Jarak yang ditempuh traffic sebelum meninggalkan Google Cloud

Saat dua VM atau resource cloud dalam Google Cloud berkomunikasi, traffic di setiap arah ditetapkan sebagai transfer data keluar di sumbernya dan transfer data masuk di tujuan, serta diberi harga yang sesuai.

Pertimbangkan faktor-faktor berikut untuk mendesain jaringan cloud yang hemat biaya:

• Geo-lokasi
• Tata letak jaringan
• Opsi konektivitas
• Network Service Tiers
• Logging

Faktor-faktor ini dibahas lebih detail di bagian berikut.

Geo-lokasi

Biaya jaringan dapat bervariasi, bergantung pada region Google Cloud tempat resource Anda disediakan. Untuk menganalisis bandwidth jaringan antar-region, Anda dapat menggunakan VPC Flow Logs dan Network Intelligence Center. Untuk traffic yang mengalir antar-region Google Cloud, biaya dapat bervariasi bergantung pada lokasi region meskipun traffic tidak melewati internet.

Selain region Google Cloud, pertimbangkan zona tempat resource Anda di-deploy. Bergantung pada persyaratan ketersediaan, Anda mungkin dapat mendesain aplikasi untuk berkomunikasi tanpa biaya dalam suatu zona melalui alamat IP internal. Saat mempertimbangkan arsitektur zona tunggal, pertimbangkan potensi penghematan biaya jaringan yang berpengaruh pada ketersediaan.

Tata letak jaringan

Analisis tata letak jaringan, alur traffic antara aplikasi dan pengguna, serta bandwidth yang digunakan oleh setiap aplikasi atau pengguna. Alat Topologi Jaringan memberikan visibilitas komprehensif ke deployment Google Cloud global Anda dan interaksinya dengan internet publik, termasuk tampilan topologi seluruh organisasi, dan metrik performa jaringan yang terkait. Anda dapat mengidentifikasi deployment yang tidak efisien, dan mengambil tindakan yang diperlukan untuk mengoptimalkan biaya transfer data regional dan antarbenua.

Opsi konektivitas

Jika Anda sering mengirimkan data dalam jumlah besar (TB atau PB) dari lingkungan lokal ke Google Cloud, pertimbangkan untuk menggunakan Dedicated Interconnect atau Partner Interconnect. Koneksi khusus bisa lebih murah dibandingkan dengan biaya yang terkait dengan perjalanan internet publik atau penggunaan VPN.

Gunakan Akses Google Pribadi jika memungkinkan untuk mengurangi biaya dan meningkatkan postur keamanan Anda.

Network Service Tiers

Infrastruktur jaringan premium Google (Paket Premium), digunakan secara default untuk semua layanan. Untuk resource yang tidak memerlukan performa tinggi dan latensi rendah yang ditawarkan Paket Premium, Anda dapat memilih Paket Standar, yang lebih murah.

Saat memilih tingkat layanan, pertimbangkanperbedaan antara berbagai tingkat dan batasan Tingkat Standar. Sesuaikan jaringan dengan kebutuhan aplikasi Anda, dan kurangi potensi biaya jaringan untuk layanan yang dapat menoleransi lebih banyak latensi dan tidak memerlukan SLA.

Logging

VPC Flow Logs, Firewall Rule Logging, dan Cloud NAT Logging memungkinkan Anda menganalisis log jaringan dan mengidentifikasi peluang untuk mengoptimalkan biaya.

Untuk VPC Flow Logs dan Cloud Load Balancing, Anda juga dapat mengaktifkan pengambilan sampel, yang dapat mengurangi volume log yang ditulis ke database. Anda dapat memvariasikan frekuensi sampling dari 1.0 (semua entri log dipertahankan) hingga 0.0 (tidak ada log yang disimpan). Untuk pemecahan masalah atau kasus penggunaan kustom, Anda dapat memilih untuk selalu mengumpulkan telemetri untuk jaringan atau subnet VPC tertentu, atau memantau Instance VM atau antarmuka virtual tertentu.

Rekomendasi desain

Untuk mengoptimalkan traffic jaringan, sebaiknya lakukan hal berikut:

• Rancang solusi Anda untuk membawa aplikasi lebih dekat ke basis pengguna Anda. Gunakan Cloud CDN untuk mengurangi volume traffic dan latensi, serta manfaatkan harga CDN yang lebih rendah untuk menayangkan konten yang Anda harapkan akan sering diakses oleh banyak pengguna.
• Hindari menyinkronkan data secara global di seluruh region yang jauh dari pengguna akhir atau yang dapat menimbulkan biaya jaringan yang tinggi. Jika aplikasi hanya digunakan dalam satu region, hindari pemrosesan data lintas-region.
• Pastikan komunikasi antara VM dalam suatu zona dirutekan melalui alamat IP internalnya, dan bukan diarahkan secara eksternal.
• Kurangi biaya transfer data dan latensi klien dengan mengompresi output data.
• Lakukan analisis pola pengeluaran dan identifikasi peluang untuk mengontrol biaya dengan mengamati alur traffic keluar dan masuk untuk project penting menggunakan VPC Flow Logs.
• Saat mendesain jaringan di cloud, pertimbangkan kompromi antara ketersediaan tinggi yang ditawarkan jaringan terdistribusi dan penghematan biaya karena memusatkan traffic dalam satu zona atau region.

Untuk mengoptimalkan harga yang Anda bayar untuk layanan jaringan, sebaiknya lakukan hal berikut:

• Jika lokasi server tidak menjadi kendala, nilai biaya di region yang berbeda, lalu pilih region yang paling hemat biaya. Untuk traffic keluar umum, seperti konten yang disalurkan oleh sekelompok server web, harga dapat bervariasi, tergantung pada region tempat server disediakan.
• Untuk mengurangi biaya pemindahan data dengan volume tinggi ke cloud, gunakan koneksi langsung antara jaringan lokal dan Google Cloud. Pertimbangkan untuk menggunakan Dedicated Interconnect atau Partner Interconnect.
• Pilih tingkat layanan yang sesuai untuk setiap lingkungan: yaitu, Paket Standar untuk lingkungan pengembangan dan pengujian, serta Paket Premium untuk produksi.

Langkah selanjutnya

• Meninjau informasi harga jaringan
• Meninjau praktik terbaik untuk pengoptimalan biaya jaringan
• Mengoptimalkan biaya untuk layanan komputasi, penyimpanan, database, dan operasi:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Cloud Operations
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Mengoptimalkan biaya: Cloud Operations

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan biaya pemantauan dan pengelolaan resource di Google Cloud.

Panduan di bagian ini ditujukan bagi pengguna cloud yang bertanggung jawab untuk memantau dan mengontrol penggunaan serta biaya resource organisasi mereka di cloud.

Kemampuan observasi Google Cloud adalah kumpulan layanan terkelola yang dapat Anda gunakan untuk memantau, memecahkan masalah, dan meningkatkan performa workload di Google Cloud. Layanan ini termasuk Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace, dan Cloud Profiler. Salah satu manfaat dari layanan terkelola di Google Cloud adalah layanannya berbasis penggunaan. Anda hanya membayar sesuai penggunaan dan volume data, dengan alokasi penggunaan data bulanan gratis, serta akses tak terbatas ke metrik Google Cloud dan audit log.

Cloud Logging

Berikut merupakan rekomendasi untuk membantu Anda mengoptimalkan biaya dari operasi Logging:

• Memfilter laporan penagihan untuk menampilkan biaya Logging.
• Kurangi volume log yang diserap dan disimpan, dengan mengecualikan atau memfilter entri log yang tidak diperlukan.
• Verifikasi apakah filter pengecualian memadai dengan monitoring metrik billing/bytes_ingested dan billing/monthly_bytes_ingested di konsol Google Cloud.
• Menyimpan dan mengekspor log ke penyimpanan berbiaya lebih rendah.
• Ketika menjalankan streaming log dari aplikasi pihak ketiga, kurangi volume log dengan menggunakan agen logging hanya pada instance produksi atau dengan mengonfigurasinya untuk mengirim lebih sedikit data.

Cloud Monitoring

Berikut adalah rekomendasi untuk membantu Anda mengoptimalkan biaya operasi Monitoring:

• Optimalkan metrik dan penggunaan label dengan membatasi jumlah label. Menghindari label dengan kardinalitas tinggi. Misalnya, jika Anda menggunakan alamat IP sebagai label, setiap alamat IP akan memiliki rangkaian label satu item, sehingga menghasilkan banyak label saat Anda memiliki banyak VM.
• Kurangi volume metrik mendetail untuk aplikasi yang tidak memerlukan metrik ini, atau hapus agen pemantauan, terutama untuk lingkungan yang tidak penting.
• Minimalkan volume penyerapan dengan mengurangi jumlah metrik kustom yang dikirim aplikasi Anda.

Cloud Trace

Berikut merupakan rekomendasi untuk membantu Anda mengoptimalkan biaya dari operasi Trace Anda:

• Jika Anda menggunakan Trace sebagai tujuan ekspor untuk trace OpenCensus Anda, kurangi volume trace yang diserap, dengan menggunakan fitur pengambilan sampel di OpenCensus.
• Batasi penggunaan Trace, dan kontrol biaya dengan menggunakan kuota. Anda dapat menerapkan durasi kuota menggunakan halaman kuota khusus API di Konsol Google Cloud.

Langkah selanjutnya

• Mengoptimalkan biaya untuk Kemampuan Observasi Google Cloud
• Video: Mengelola biaya untuk Kemampuan Observasi Google Cloud
• Optimalkan biaya untuk layanan komputasi, penyimpanan, database, dan jaringan:
  • Mengoptimalkan biaya: Compute, container, dan serverless
  • Mengoptimalkan biaya: Penyimpanan
  • Mengoptimalkan biaya: Database dan analisis smart
  • Mengoptimalkan biaya: Networking
• Jelajahi kategori lain dari Framework Arsitektur Google Cloud

Framework Arsitektur Google Cloud: Pengoptimalan performa

Kategori dalam Framework Arsitektur Google Cloud menjelaskan proses optimalisasi performa dan praktik terbaik dari untuk mengoptimalkan performa workload pada Google Cloud.

Informasi ini ditujukan untuk arsitek, developer, dan administrator yang merencanakan, mendesain, men-deploy, dan mengelola workload pada Google Cloud.

Mengoptimalkan performa workload pada cloud dapat membantu organisasi Anda beroperasi secara efisien, meningkatkan kepuasan pelanggan, meningkatkan pendapatan, dan mengurangi biaya. Misalnya, pada saat waktu pemrosesan backend aplikasi menurun pengguna akan mengalami respons yang lebih cepat, yang dapat menyebabkan retensi pengguna yang lebih tinggi dan peningkatan pendapatan.

Kemungkinan ada kompromi antara performa dan biaya. Namun, terkadang, mengoptimalkan performa dapat membantu Anda mengurangi biaya. ​​Misalnya, penskalaan otomatis membantu memberikan performa yang dapat diprediksi sebelum meningkat dengan memastikan bahwa resource tidak kelebihan beban. Penskalaan otomatis juga membantu Anda mengurangi biaya selama periode beban rendah dengan menghapus resource yang tidak digunakan.

Dalam kategori Framework Arsitektur ini, Anda akan mempelajari cara melakukan hal-hal berikut:

• Menerapkan proses pengoptimalan performa.
• Memantau dan menganalisis performa.
• Mengoptimalkan performa komputasi.
• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa database.
• Mengoptimalkan performa analisis.

Proses pengoptimalan performa

Dokumen dalam Framework Arsitektur Google Cloud ini memberikan ringkasan tentang proses pengoptimalan performa.

Pengoptimalan performa adalah proses berkelanjutan, bukan aktivitas satu kali. Diagram berikut ini menampilkan tahapan dalam proses pengoptimalan performa:

Berikut adalah ringkasan tahapan dalam proses pengoptimalan performa:

Menentukan persyaratan performa

Sebelum Anda mulai mendesain dan mengembangkan aplikasi yang ingin di-deploy atau dimigrasikan ke cloud, tentukan persyaratan performa. Tetapkan persyaratan sedetail mungkin untuk setiap lapisan stack aplikasi: load balancing frontend, server web atau aplikasi, database, dan penyimpanan. Misalnya, untuk lapisan penyimpanan stack, tentukan throughput dan operasi I/O per detik (IOPS) yang dibutuhkan aplikasi Anda.

Mendesain dan men-deploy aplikasi Anda

Desain aplikasi Anda menggunakan pola desain yang elastis dan skalabel yang dapat membantu Anda memenuhi persyaratan performa. Pertimbangkan pedoman berikut untuk mendesain aplikasi yang elastis dan skalabel:

• Merancang workload untuk penempatan konten yang optimal.
• Mengisolasi traffic baca dan tulis.
• Mengisolasi traffic statis dan dinamis.
• Mengimplementasikan cache konten. Menggunakan cache data untuk lapisan internal.
• Gunakan layanan terkelola dan arsitektur serverless.

Google Cloud menyediakan alat open source yang dapat Anda gunakan untuk membandingkan performa layanan Google Cloud dengan platform cloud lainnya.

Memantau dan menganalisis performa

Setelah Anda men-deploy aplikasi, terus pantau performa dengan menggunakan log dan pemberitahuan, analisis data, serta identifikasi masalah performa. Seiring aplikasi Anda tumbuh dan berkembang, nilai ulang persyaratan performa Anda. Anda mungkin harus mendesain ulang beberapa bagian aplikasi untuk mempertahankan atau meningkatkan performa.

Mengoptimalkan performa

Berdasarkan performa aplikasi Anda dan perubahan di persyaratan, konfigurasikan resource cloud untuk memenuhi persyaratan performa saat ini. Misalnya, mengubah ukuran resource atau menyiapkan penskalaan otomatis. Saat mengonfigurasi resource, evaluasi peluang untuk menggunakan fitur dan layanan Google Cloud yang baru saja dirilis yang dapat membantu mengoptimalkan performa lebih lanjut.

Proses pengoptimalan performa tidak berakhir pada tahap ini. Melanjutkan siklus pemantauan performa, menilai ulang persyaratan jika diperlukan, dan menyesuaikan resource cloud untuk mempertahankan dan meningkatkan performa.

Langkah selanjutnya

• Memantau dan menganalisis performa.
• Mengoptimalkan performa komputasi.
• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa database.
• Mengoptimalkan performa analisis.

Memantau dan menganalisis performa

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan layanan dalam Kemampuan Observasi Google Cloud yang dapat Anda gunakan untuk merekam, memantau, dan menganalisis performa beban kerja Anda.

Memantau metrik performa

Gunakan Cloud Monitoring untuk menganalisis tren metrik performa, menganalisis efek eksperimen, menentukan pemberitahuan untuk metrik penting, dan melakukan analisis retrospektif.

Mencatat peristiwa dan data penting ke dalam log

Cloud Logging adalah layanan logging terintegrasi yang dapat Anda gunakan untuk menyimpan, menganalisis, memantau, dan menyetel pemberitahuan untuk data log dan peristiwa. Cloud Logging dapat mengumpulkan log dari layanan Google Cloud dan penyedia cloud lainnya.

Menganalisis performa kode

Kode yang berperforma buruk dapat meningkatkan latensi aplikasi dan biaya untuk menjalankannya. Cloud Profiler membantu Anda mengidentifikasi dan mengatasi masalah performa dengan terus menganalisis performa fungsi yang menggunakan memori atau CPU secara intensif yang digunakan aplikasi.

Mengumpulkan data latensi

Pada stack aplikasi yang kompleks dan arsitektur berbasis microservice, mengukur latensi dalam komunikasi antarlayanan dan mengidentifikasi bottleneck performa bisa jadi sulit. Alat Cloud Trace dan OpenTelemetry membantu Anda mengumpulkan data latensi dari deployment Anda dalam skala besar. Alat-alat ini juga membantu Anda menganalisis data latensi secara efisien.

Memantau performa jaringan

Dasbor Performa pada Network Intelligence Center memberikan tampilan yang komprehensif tentang metrik performa untuk jaringan Google dan resource dalam project Anda. Metrik ini dapat membantu Anda menentukan penyebab masalah performa yang berhubungan dengan jaringan. Misalnya, Anda dapat mengidentifikasi apakah masalah performa disebabkan oleh masalah dalam project Anda atau jaringan Google.

Langkah selanjutnya

• Pelajari praktik terbaik untuk memantau resource cloud Anda.
• Tinjau praktik terbaik untuk mengoptimalkan performa resource Google Cloud Anda:
  • Mengoptimalkan performa komputasi.
  • Mengoptimalkan performa penyimpanan.
  • Mengoptimalkan performa jaringan.
  • Mengoptimalkan performa database.
  • Mengoptimalkan performa analisis.

Mengoptimalkan performa komputasi

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa Compute Engine, Google Kubernetes Engine (GKE), dan resource serverless.

Compute Engine

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan performa resource Compute Engine.

Melakukan penskalaan otomatis resource

Dengan grup instance terkelola (MIG), Anda dapat menskalakan aplikasi stateless yang di-deploy pada VM Compute Engine secara efisien. Dengan penskalaan otomatis, aplikasi Anda dapat terus memberikan performa yang dapat diprediksi saat beban meningkat. Dalam MIG, sekelompok VM Compute Engine diluncurkan berdasarkan template yang Anda tentukan. Di template, Anda mengonfigurasi kebijakan penskalaan otomatis yang menentukan satu atau beberapa sinyal yang digunakan autoscaler untuk menskalakan grup. Sinyal penskalaan otomatis dapat dibuat berdasarkan jadwal, seperti waktu mulai atau durasi, atau berdasarkan metrik target seperti penggunaan CPU rata-rata. Untuk informasi selengkapnya, lihat Penskalaan otomatis grup instance.

Nonaktifkan SMT

Setiap CPU virtual (vCPU) yang Anda alokasikan ke VM Compute Engine diimplementasikan sebagai hardware multithread tunggal. Secara default, dua vCPU berbagi core CPU fisik. Arsitektur ini disebut simultaneous multi-threading (SMT).

Untuk workload dengan paralel tingkat tinggi atau yang melakukan penghitungan floating point (seperti transcoding, simulasi Monte Carlo, analisis urutan genetik, dan pemodelan risiko keuangan), Anda dapat meningkatkan performa dengan menonaktifkan SMT. Untuk informasi selengkapnya, lihat Menetapkan jumlah thread per core.

Menggunakan GPU

Untuk workload seperti machine learning dan visualisasi, Anda dapat menambahkan unit pemrosesan grafis (GPU) ke VM. Compute Engine memberikan GPU NVIDIA dalam mode passthrough sehingga VM Anda memiliki kontrol langsung atas GPU dan memori terkait. Untuk workload yang membutuhkan banyak grafis seperti visualisasi 3D, Anda dapat menggunakan workstation virtual NVIDIA RTX. Setelah Anda men-deploy workload, pantau penggunaan GPU dan tinjau opsi untuk mengoptimalkan performa GPU.

Gunakan jenis mesin yang dioptimalkan untuk komputasi

Workload seperti game, transcoding media, dan komputasi berperforma tinggi (HPC) memerlukan performa tinggi yang konsisten per core CPU. Google merekomendasikan agar Anda menggunakan jenis mesin yang dioptimalkan untuk komputasi bagi VM yang menjalankan workload tersebut. VM yang dioptimalkan untuk komputasi dibangun pada arsitektur yang menggunakan fitur seperti akses memori tidak seragam (NUMA) untuk performa yang optimal dan andal.

Workload HPC yang dikaitkan erat memiliki serangkaian persyaratan unik untuk mencapai efisiensi performa tertinggi. Untuk informasi selengkapnya, lihat dokumentasi berikut:

• Sistem file paralel untuk workload HPC
• Arsitektur: Sistem file Lustre di Google Cloud menggunakan DDN EXAScaler

Pilih penyimpanan yang sesuai

Google Cloud menawarkan berbagai opsi penyimpanan untuk VM Compute Engine: Persistent disk, disk solid state drive (SSD) lokal, Filestore, dan Cloud Storage. Untuk rekomendasi desain dan praktik terbaik dalam mengoptimalkan performa setiap opsi penyimpanan ini, lihat Mengoptimalkan performa penyimpanan.

Google Kubernetes Engine

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan performa resource Google Kubernetes Engine (GKE).

Melakukan penskalaan otomatis resource

Anda dapat secara otomatis mengubah ukuran node pool dalam cluster GKE agar sesuai dengan beban saat ini menggunakan fitur autoscaler cluster. Dengan penskalaan otomatis, aplikasi Anda dapat terus memberikan performa yang dapat diprediksi saat beban meningkat. Autoscaler cluster mengubah ukuran node pool secara otomatis berdasarkan permintaan resource (bukan penggunaan resource sebenarnya) Pod yang berjalan di node. Saat Anda menggunakan penskalaan otomatis, mungkin ada kompromi antara performa dan biaya. Tinjau praktik terbaik untuk mengonfigurasi penskalaan otomatis cluster secara efisien.

Catatan: Dengan Cluster autopilot, Anda tidak perlu khawatir tentang penyediaan node atau pengelolaan node pool. Node pool disediakan dan diskalakan secara otomatis berdasarkan persyaratan workload Anda.

Menggunakan VM C2D

Anda dapat meningkatkan performa workload dalam container yang membutuhkan komputasi intensif menggunakan jenis mesin C2D. Anda dapat menambahkan node C2D ke cluster GKE dengan memilih jenis mesin C2D di node pool Anda.

Nonaktifkan SMT

Multi-threading simultan (SMT) dapat meningkatkan throughput aplikasi secara signifikan untuk tugas komputasi umum dan untuk workload yang membutuhkan I/O tinggi. Namun, untuk workload yang kedua core virtualnya terikat komputasi, SMT dapat menyebabkan performa yang tidak konsisten. Untuk mendapatkan performa yang lebih baik dan lebih dapat diprediksi, Anda dapat menonaktifkan SMT untuk node GKE dengan menetapkan jumlah vCPU per core ke 1.

Menggunakan GPU

Untuk workload yang membutuhkan komputasi intensif seperti pengenalan image dan transcoding video, Anda dapat mempercepat performa dengan membuat node pool yang menggunakan GPU. Untuk informasi selengkapnya, lihat Menjalankan GPU.

Menggunakan load balancing berbasis container

Load balancing asal container memungkinkan load balancer mendistribusikan traffic secara langsung dan merata ke Pod. Pendekatan ini memberikan performa jaringan yang lebih baik dan peningkatan visibilitas pada latensi jaringan antara load balancer dan Pod. Manfaat ini menjadikan load balancing asal container sebagai solusi yang direkomendasikan untuk melakukan load balancing melalui Ingress.

Menentukan kebijakan penempatan rapat

Workload batch yang dikaitkan erat memerlukan latensi jaringan yang rendah antar-node dalam node pool GKE. ​​Anda dapat men-deploy workload tersebut ke node pool zona tunggal, dan memastikan bahwa node saling berdekatan secara fisik dengan menetapkan kebijakan penempatan rapat. Untuk mengetahui informasi selengkapnya, lihat Menentukan penempatan rapat untuk node GKE.

Layanan komputasi serverless

Bagian ini berisi panduan untuk membantu Anda mengoptimalkan performa layanan komputasi serverless di Google Cloud: Cloud Run dan Cloud Functions. Layanan ini menyediakan kemampuan penskalaan otomatis, sementara infrastruktur dasar menangani penskalaan secara otomatis. Berkat layanan serverless ini, Anda dapat mengurangi upaya penskalaan microservice dan fungsi Anda, serta berfokus pada pengoptimalan performa di level aplikasi.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

• Mengoptimalkan performa untuk layanan Cloud Run
• Mengoptimalkan aplikasi Java untuk Cloud Run
• Mengoptimalkan performa di Cloud Functions

Langkah selanjutnya

Tinjau praktik terbaik untuk mengoptimalkan performa resource penyimpanan, jaringan, database, dan analisis Anda:

• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa database.
• Mengoptimalkan performa analisis.

Mengoptimalkan performa penyimpanan

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa resource penyimpanan di Google Cloud.

Cloud Storage

Bagian ini memberikan praktik terbaik untuk membantu mengoptimalkan performa operasi Cloud Storage Anda.

Menilai performa bucket

Menilai performa bucket Cloud Storage Anda menggunakan perintah gsutil perfdiag . Perintah ini menguji performa bucket yang ditentukan dengan mengirimkan serangkaian permintaan baca dan tulis yang berisi berbagai ukuran file. Anda dapat menyesuaikan pengujian agar cocok dengan pola penggunaan aplikasi. Gunakan laporan diagnostik yang dihasilkan oleh perintah untuk menetapkan ekspektasi performa dan mengidentifikasi potensi bottleneck.

Meng-cache objek yang sering diakses

Guna memperbaiki latensi baca untuk objek yang sering dan dapat diakses oleh publik, Anda dapat mengonfigurasi objek tersebut untuk di-cache. Meskipun caching dapat meningkatkan kinerja, konten usang dapat disajikan jika cache memiliki versi lama dari suatu objek.

Menskalakan permintaan secara efisien

Seiring peningkatan rasio permintaan untuk bucket, Cloud Storage secara otomatis meningkatkan kapasitas I/O untuk bucket dengan mendistribusikan beban permintaan ke beberapa server. Untuk mencapai performa optimal saat penskalaan permintaan, ikuti praktik terbaik untuk meningkatkan rasio permintaan dan mendistribusikan beban secara merata.

Mengaktifkan multithreading dan multiprocessing

Saat menggunakan gsutil untuk mengupload banyak file kecil, Anda dapat meningkatkan performa operasi menggunakan opsi -m. Opsi ini menyebabkan permintaan upload diterapkan sebagai operasi batch, paralel (yaitu, multi-thread dan multiprocessing). Gunakan opsi ini hanya jika Anda melakukan operasi melalui koneksi jaringan yang cepat. Untuk informasi selengkapnya, lihat dokumentasi untuk opsi -m di Opsi Command Line Global.

Mengupload file besar sebagai komposit

Untuk mengupload file besar, Anda dapat menggunakan strategi yang disebut upload komposit paralel. Dengan strategi ini, file besar dibagi menjadi beberapa bagian, yang diupload secara paralel lalu dikomposisi ulang di cloud. Upload komposit paralel dapat lebih cepat daripada operasi upload reguler jika bandwidth jaringan dan kecepatan disk tidak menjadi faktor yang membatasi. Namun, strategi ini memiliki beberapa keterbatasan dan implikasi biaya. Untuk mengetahui informasi selengkapnya, lihat Upload komposit paralel.

Persistent disk dan SSD lokal

Bagian ini memberikan praktik terbaik untuk membantu Anda mengoptimalkan performa Persistent Disk dan SSD Lokal yang terpasang ke VM Compute Engine.

Performa persistent disk dan SSD lokal bergantung pada jenis dan ukuran disk, jenis mesin VM, dan jumlah vCPU. Gunakan panduan berikut untuk mengelola performa persistent disk dan SSD lokal Anda:

• Saat menyediakan block storage untuk VM Anda, pilih jenis disk dan ukuran disk yang sesuai dengan workload Anda. Untuk informasi lebih lanjut, lihat Mengonfigurasi disk untuk memenuhi persyaratan performa.
• Lakukan tolok ukur performa block storage. Untuk informasi selengkapnya, lihat dokumentasi berikut:
  • Menjalankan tolok ukur performa persistent disk
  • Menjalankan tolok ukur performa SSD lokal
• Optimalkan performa persistent disk dan SSD lokal Anda. Untuk informasi selengkapnya, lihat dokumentasi berikut:
  • Mengoptimalkan performa persistent disk
  • Mengoptimalkan performa SSD Lokal

Filestore

Bagian ini memberikan praktik terbaik untuk membantu mengoptimalkan performa instance Filestore Anda. Anda dapat menggunakan Filestore untuk menyediakan server file Network File System (NFS) yang terkelola sepenuhnya untuk VM Compute Engine dan cluster GKE.

• Saat menyediakan instance Filestore, pilih tingkat layanan yang memenuhi persyaratan performa dan kapasitas workload Anda.
• Untuk VM klien yang menjalankan workload yang tergantung pada cache, sebaiknya gunakan jenis mesin yang dapat membantu mengoptimalkan kinerja jaringan dengan instance Filestore. Untuk informasi selengkapnya, lihat Jenis mesin klien yang direkomendasikan.
• Untuk mengoptimalkan kinerja instance Filestore untuk VM klien yang menjalankan Linux, Google merekomendasikan pengaturan khusus untuk pengaitan NFS. Untuk informasi selengkapnya, lihat Opsi pengaitan klien Linux.
• Untuk meminimalkan latensi jaringan, sediakan instance Filestore Anda di region dan zona yang dekat dengan tempat Anda akan menggunakan instance.
• Pantau performa instance Filestore Anda, dan siapkan peringatan menggunakan Cloud Monitoring.

Langkah selanjutnya

Tinjau praktik terbaik untuk mengoptimalkan performa resource komputasi, jaringan, database, dan analisis:

• Mengoptimalkan performa komputasi.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa database.
• Mengoptimalkan performa analisis.

Mengoptimalkan performa jaringan dan API

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa resource dan API jaringan Anda di Google Cloud.

Network Service Tiers

Dengan Network Service Tiers, Anda dapat mengoptimalkan biaya dan performa jaringan untuk workload Anda. Anda dapat memilih dari tingkat berikut:

• Paket Premium menggunakan backbone global Google yang sangat andal untuk membantu Anda mencapai latensi dan kehilangan paket yang minimal. Traffic masuk dan keluar dari jaringan Google di titik kehadiran edge global (PoP) yang dekat dengan pengguna akhir Anda. Sebaiknya gunakan Paket Premium sebagai paket default untuk performa yang optimal. Paket Premium mendukung alamat IP eksternal regional dan global untuk VM dan load balancer.
• Tingkat Standar hanya tersedia untuk resource yang menggunakan alamat IP eksternal regional. Traffic masuk dan keluar dari jaringan Google di PoP edge yang terdekat dengan lokasi Google Cloud tempat workload Anda dijalankan. Harga untuk Paket Standar lebih rendah daripada Paket Premium. Paket Standar cocok untuk traffic yang tidak sensitif terhadap paket yang hilang dan yang tidak memiliki persyaratan latensi rendah.

Anda dapat melihat latensi jaringan untuk Paket Standar dan Paket Premium untuk setiap region cloud di Network Intelligence Center Performance Dashboard.

Bingkai jumbo

Jaringan Virtual Private Cloud (VPC) memiliki unit transmisi maksimum (MTU) default sebesar 1.460 byte. Namun, Anda dapat mengonfigurasi jaringan VPC agar dapat mendukung MTU hingga 8896 (frame jumbo).

Dengan MTU yang lebih tinggi, jaringan memerlukan lebih sedikit paket untuk mengirim data dalam jumlah yang sama, sehingga mengurangi penggunaan bandwidth oleh header TCP/IP. Hal ini menghasilkan bandwidth jaringan yang lebih tinggi.

Untuk mengetahui informasi selengkapnya tentang MTU intra-VPC dan MTU maksimum koneksi lainnya, lihat halaman Unit transmisi maksimum dalam dokumentasi VPC.

Performa VM

VM Compute Engine memiliki bandwidth traffic keluar maksimum yang sebagian bergantung pada jenis mesin. Salah satu aspek pemilihan jenis mesin yang tepat adalah mempertimbangkan jumlah traffic yang Anda harapkan akan dihasilkan oleh VM.

Halaman Bandwidth jaringan berisi diskusi dan tabel bandwidth jaringan untuk jenis mesin Compute Engine.

Jika persyaratan bandwidth inter-VM Anda sangat tinggi, pertimbangkan VM yang mendukung jaringan Tier_1.

Cloud Load Balancing

Bagian ini memberikan praktik terbaik untuk membantu Anda mengoptimalkan performa instance Cloud Load Balancing.

Men-deploy aplikasi yang dekat dengan pengguna Anda

Sediakan backend aplikasi Anda di dekat lokasi tempat traffic pengguna diperkirakan akan tiba di load balancer. Semakin dekat pengguna atau aplikasi klien dengan server workload Anda, semakin rendah latensi jaringan antara pengguna dan workload. Untuk meminimalkan latensi untuk klien di berbagai belahan dunia, Anda mungkin harus men-deploy backend di beberapa region. Untuk informasi selengkapnya, baca Praktik terbaik untuk pemilihan region Compute Engine.

Memilih jenis load balancer yang sesuai

Jenis load balancer yang Anda pilih untuk aplikasi dapat menentukan latensi yang dialami pengguna. Untuk informasi tentang cara mengukur dan mengoptimalkan latensi aplikasi untuk berbagai jenis load balancer, baca Mengoptimalkan latensi aplikasi dengan load balancing.

Aktifkan caching

Untuk mempercepat penayangan konten, aktifkan caching dan Cloud CDN sebagai bagian dari konfigurasi load balancer HTTP eksternal default Anda. Pastikan server backend dikonfigurasi untuk mengirim header respons yang diperlukan agar respons statis di-cache.

Gunakan HTTP ketika HTTPS tidak diperlukan

Google secara otomatis mengenkripsi traffic antara load balancer proxy dan backend di tingkat paket. Enkripsi tingkat paket membuat enkripsi Lapisan 7 menggunakan HTTPS antara load balancer dan backend menjadi redundan untuk sebagian besar tujuan. Sebaiknya gunakan HTTP, bukan HTTPS atau HTTP/2 untuk traffic antara load balancer dan backend Anda. Dengan menggunakan HTTP, Anda juga dapat mengurangi penggunaan CPU VM backend. Namun, jika backend adalah grup endpoint jaringan internet (NEG), gunakan HTTPS atau HTTP/2 untuk traffic antara load balancer dan backend. Hal ini membantu memastikan traffic Anda aman di internet publik. Untuk performa yang optimal, sebaiknya ukur pola traffic aplikasi Anda.

Network Intelligence Center

Network Intelligence Center Google Cloud memberikan gambaran menyeluruh tentang performa jaringan Google Cloud di semua region. Network Intelligence Center membantu Anda menentukan apakah masalah latensi disebabkan oleh masalah dalam project Anda atau di jaringan. Anda juga dapat menggunakan informasi ini untuk memilih region dan zona tempat Anda harus men-deploy workload untuk mengoptimalkan performa jaringan.

Gunakan alat yang disediakan oleh Network Intelligence Center berikut untuk memantau dan menganalisis performa jaringan untuk workload Anda di Google Cloud:

• Dasbor Performa menampilkan latensi antara region Google Cloud serta antara masing-masing region dan lokasi di internet. Dasbor Performa dapat membantu Anda menentukan tempat untuk menempatkan workload untuk latensi terbaik dan membantu menentukan kapan masalah aplikasi mungkin disebabkan oleh masalah jaringan yang mendasarinya.

• Topologi Jaringan menampilkan tampilan visual jaringan Virtual Private Cloud (VPC) Anda, konektivitas hybrid dengan jaringan lokal Anda, dan konektivitas ke layanan yang dikelola Google. Topologi Jaringan memberikan metrik operasional real time yang dapat Anda gunakan untuk menganalisis dan memahami performa jaringan serta mengidentifikasi pola traffic yang tidak biasa.

• Network Analyzer adalah alat pemantauan dan diagnostik konfigurasi otomatis. Cloud Monitoring memverifikasi konfigurasi jaringan VPC untuk aturan firewall, rute, dependensi konfigurasi, dan konektivitas untuk layanan dan aplikasi. Hal ini membantu Anda mengidentifikasi kegagalan jaringan, serta memberikan analisis akar masalah dan rekomendasi. Network Analyzer memberikan insight yang diprioritaskan untuk membantu Anda menganalisis masalah pada konfigurasi jaringan, seperti pemanfaatan alamat IP yang tinggi di subnet.

Gateway API dan Apigee

Bagian ini berisi rekomendasi untuk membantu Anda mengoptimalkan performa API yang di-deploy di Google Cloud menggunakan API Gateway dan Apigee ini.

Dengan API Gateway, Anda dapat membuat dan mengelola API untuk backend serverless Google Cloud, termasuk Cloud Functions, Cloud Run, dan App Engine. Layanan ini adalah layanan terkelola dan diskalakan secara otomatis. Namun, seiring aplikasi yang di-deploy pada skala layanan ini, Anda mungkin perlu meningkatkan kuota dan batas kapasitas untuk API Gateway.

Catatan: Mengekspos aplikasi atau infrastruktur ke lebih banyak traffic dapat menyebabkan bottleneck performa pada lapisan berikutnya dalam stack aplikasi.

Apigee menyediakan dasbor analisis berikut untuk membantu Anda memantau performa API terkelola:

• Dasbor Performa Proxy API: Pantau pola traffic proxy dan waktu pemrosesan API.
• Dasbor Performa Target: Memvisualisasikan pola traffic dan metrik performa untuk target backend proxy API.
• Dasbor Performa Cache: Pantau metrik performa untuk cache Apigee, seperti rasio cache-hit rata-rata dan waktu rata-rata dalam cache.

Jika Anda menggunakan Apigee Integration, pertimbangkan batas konfigurasi sistem saat membangun dan mengelola integrasi Anda.

Langkah selanjutnya

Tinjau praktik terbaik untuk mengoptimalkan performa resource komputasi, penyimpanan, database, dan analisis:

• Mengoptimalkan performa komputasi.
• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa database.
• Mengoptimalkan performa analisis.

Mengoptimalkan performa database

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa database di Google Cloud.

Cloud SQL

Rekomendasi berikut akan membantu Anda mengoptimalkan performa instance Cloud SQL yang menjalankan database SQL Server, MySQL, dan PostgreSQL.

• Untuk database SQL Server, Google merekomendasikan agar Anda mengubah parameter tertentu dan mempertahankan nilai default untuk beberapa parameter.
• Saat memilih jenis penyimpanan untuk database MySQL atau PostgreSQL, pertimbangkan kompromi performa biaya antara penyimpanan SSD dan HDD.
• Untuk mengidentifikasi dan menganalisis masalah performa dengan database PostgreSQL, gunakan dasbor Insight Cloud SQL.
• Untuk mendiagnosis performa yang buruk saat menjalankan kueri SQL, gunakan pernyataan EXPLAIN.

Untuk informasi selengkapnya, lihat dokumentasi berikut:

• Mengoptimalkan performa: SQL Server
• Mengoptimalkan performa: MySQL
• Mengoptimalkan performa: PostgreSQL

Bigtable

Bagian ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa instance Bigtable.

Merencanakan kapasitas berdasarkan persyaratan performa

Anda dapat menggunakan Bigtable dalam spektrum aplikasi yang luas, masing-masing dengan sasaran pengoptimalan yang berbeda. Misalnya, untuk tugas pemrosesan data batch, throughput mungkin lebih penting daripada latensi. Untuk layanan online yang melayani permintaan pengguna, Anda mungkin perlu memprioritaskan latensi yang lebih rendah daripada throughput. Saat Anda merencanakan kapasitas untuk cluster Bigtable, pertimbangkan keseimbangan antara throughput dan latensi. Untuk informasi selengkapnya, lihat Merencanakan kapasitas Bigtable.

Mengikuti praktik terbaik desain skema

Tabel Anda dapat diskalakan hingga miliaran baris dan ribuan kolom, sehingga Anda dapat menyimpan data berukuran petabyte. Saat mendesain skema untuk tabel Bigtable Anda, pertimbangkan praktik terbaik desain skema.

Memantau performa dan melakukan penyesuaian

Pantau penggunaan CPU dan disk untuk instance Anda, analisis performa setiap cluster, dan tinjau rekomendasi ukuran yang ditampilkan dalam diagram pemantauan.

Spanner

Bagian ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa instance Spanner Anda.

Pilih kunci utama yang mencegah hotspot

Hotspot adalah server tunggal yang dipaksa untuk menangani banyak permintaan. Saat Anda memilih kunci utama untuk database, ikuti praktik terbaik desain skema untuk mencegah hotspot.

Ikuti praktik terbaik untuk coding SQL

Compiler SQL di Spanner mengonversi setiap pernyataan SQL deklaratif yang Anda tulis menjadi rencana eksekusi kueri imperatif. Spanner menggunakan rencana eksekusi untuk menjalankan pernyataan SQL. Saat membuat pernyataan SQL, ikuti praktik terbaik SQL untuk memastikan Spanner menggunakan rencana eksekusi yang menghasilkan performa yang optimal.

Menggunakan opsi kueri untuk mengelola pengoptimal kueri SQL

Spanner menggunakan pengoptimal kueri SQL untuk mengubah pernyataan SQL menjadi rencana eksekusi kueri yang efisien. Rencana eksekusi kueri yang dihasilkan pengoptimal mungkin sedikit berubah ketika pengoptimal kueri itu sendiri berkembang, atau ketika statistik database diperbarui. Anda dapat meminimalkan potensi regresi performa ketika pengoptimal kueri atau statistik database berubah dengan menggunakan opsi kueri.

Memvisualisasikan dan menyesuaikan struktur rencana eksekusi kueri

Untuk menganalisis masalah performa kueri, Anda dapat memvisualisasikan dan menyesuaikan struktur rencana eksekusi kueri menggunakan visualisasi paket kueri.

Menggunakan API operasi untuk mengelola operasi yang berjalan lama

Untuk panggilan metode tertentu, Spanner akan membuat operasi yang berjalan lama, yang mungkin memerlukan waktu lama untuk diselesaikan. Misalnya, saat Anda memulihkan database, Spanner akan membuat operasi yang berjalan lama untuk melacak progres pemulihan. Untuk membantu Anda memantau dan mengelola operasi yang berjalan lama, Spanner menyediakan API operasi. Untuk informasi selengkapnya, lihat Mengelola operasi yang berjalan lama.

Ikuti praktik terbaik untuk pemuatan massal

Spanner mendukung beberapa opsi untuk memuat data dalam jumlah besar secara massal. Performa operasi pemuatan massal bergantung pada faktor-faktor seperti partisi, jumlah permintaan tulis, dan ukuran setiap permintaan. Untuk memuat data dalam jumlah besar secara efisien, ikuti praktik terbaik pemuatan massal.

Memantau dan mengontrol pemakaian CPU

Pemakaian CPU instance Spanner dapat memengaruhi latensi permintaan. Server backend yang kelebihan beban dapat menyebabkan latensi permintaan yang lebih tinggi. Spanner memberikan metrik penggunaan CPU untuk membantu Anda menyelidiki penggunaan CPU yang tinggi. Untuk aplikasi yang sensitif terhadap performa, Anda mungkin perlu mengurangi pemakaian CPU dengan meningkatkan kapasitas komputasi.

Menganalisis dan mengatasi masalah latensi

Saat klien melakukan panggilan prosedur jarak jauh ke Spanner, permintaan API akan disiapkan terlebih dahulu oleh library klien. Kemudian, permintaan akan melewati Google Front End dan frontend Cloud Spanner API sebelum mencapai database Spanner. Untuk menganalisis dan mengatasi masalah latensi, Anda harus mengukur dan menganalisis latensi untuk setiap segmen jalur yang dilalui permintaan API. Untuk mengetahui informasi selengkapnya, lihat Panduan latensi menyeluruh Spanner.

Meluncurkan aplikasi setelah database mencapai status warm

Seiring dengan berkembangnya database Spanner, database ini membagi ruang kunci data Anda menjadi bagian. Setiap pemisahan adalah rentang baris yang berisi subset dari tabel Anda. Untuk menyeimbangkan keseluruhan beban pada database, Spanner secara dinamis memindahkan setiap bagian secara independen dan menetapkannya ke server yang berbeda. Jika bagian didistribusikan di beberapa server, database dianggap dalam status warm. Database yang hangat dapat memaksimalkan paralelisme dan memberikan peningkatan performa. Sebelum meluncurkan aplikasi, kami merekomendasikan Anda untuk memanaskan database dengan pemuatan data uji.

Langkah selanjutnya

Tinjau praktik terbaik untuk mengoptimalkan performa resource komputasi, penyimpanan, jaringan, dan analisis Anda:

• Mengoptimalkan performa komputasi.
• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa analisis.

Mengoptimalkan performa analisis

Dokumen di Framework Arsitektur Google Cloud ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa workload analisis Anda di Google Cloud.

BigQuery

Bagian ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa kueri di BigQuery.

Mengoptimalkan desain kueri

Performa kueri bergantung pada beberapa faktor seperti jumlah byte yang dibaca dan ditulis oleh kueri Anda, dan volume data yang diteruskan di antara slot. Untuk mengoptimalkan performa kueri Anda di BigQuery, terapkan praktik terbaik yang dijelaskan dalam dokumentasi berikut:

• Pengantar untuk mengoptimalkan performa kueri
• Mengelola input data dan sumber data
• Mengoptimalkan komunikasi antar-slot
• Mengoptimalkan komputasi kueri
• Mengelola output kueri
• Menghindari anti-pola SQL

Menentukan dan menggunakan tampilan terwujud secara efisien

Untuk meningkatkan performa workload yang menggunakan kueri umum dan berulang, Anda dapat menggunakan tampilan terwujud. Terdapat batasan jumlah tampilan terwujud yang dapat Anda buat. Jangan membuat tampilan terwujud terpisah untuk setiap permutasi kueri. Sebagai gantinya, tentukan tampilan terwujud yang dapat Anda gunakan untuk beberapa pola kueri.

Meningkatkan performa JOIN

Anda dapat menggunakan tampilan terwujud untuk mengurangi biaya dan latensi kueri yang melakukan agregasi pada bagian atas JOIN. Pertimbangkan suatu kasus saat Anda menggabungkan tabel fakta besar dengan beberapa tabel dimensi kecil, lalu melakukan sebuah agregasi di atas gabungan tersebut. Mungkin akan lebih praktis jika Anda menulis ulang kueri untuk melakukan agregasi terlebih dahulu di atas tabel fakta dengan kunci asing sebagai kunci pengelompokan. Kemudian, gabungkan hasilnya dengan tabel dimensi. Terakhir, lakukan post-aggregation.

Dataflow

Bagian ini memberikan rekomendasi untuk membantu Anda mengoptimalkan performa kueri di pipeline Dataflow.

Saat membuat dan men-deploy pipeline, Anda dapat mengonfigurasi parameter eksekusi, seperti jenis mesin Compute Engine yang harus digunakan untuk worker VM Dataflow. Untuk informasi lebih lanjut, lihat Opsi pipeline.

Setelah Anda men-deploy pipeline, Dataflow akan mengelola resource Compute Engine dan Cloud Storage yang diperlukan untuk menjalankan tugas Anda. Selain itu, fitur Dataflow berikut membantu mengoptimalkan performa pipeline:

• Paralelisasi: Dataflow secara otomatis membagi data Anda dan mendistribusikan kode worker ke instance Compute Engine untuk pemrosesan paralel. Untuk informasi selengkapnya, lihat paralelisasi dan distribusi.
• Pengoptimalan: Dataflow menggunakan kode pipeline untuk membuat grafik eksekusi yang mewakili PCollection objek dan transforms dalam proses pengembangan. Kemudian, versi ini akan mengoptimalkan grafik untuk mendapatkan performa dan penggunaan resource yang paling efisien. Dataflow juga secara otomatis mengoptimalkan operasi yang berpotensi mahal, seperti agregasi data. Untuk informasi selengkapnya, lihat Pengoptimalan Fusion dan Kombinasi pengoptimalan.
• Penyesuaian otomatis: Dataflow mengoptimalkan tugas secara dinamis saat tugas berjalan dengan menggunakan Penskalaan Otomatis Horizontal, Penskalaan Otomatis Vertikal, dan Penyeimbangan Ulang Pekerjaan Dinamis.

Anda dapat memantau performa pipeline Dataflow menggunakan antarmuka pemantauan berbasis web atau gcloud CLI Dataflow.

Catatan: Anda juga dapat menggunakan Cloud Profiler untuk mengidentifikasi bagian-bagian kode pipeline yang paling banyak menggunakan resource. Untuk informasi selengkapnya, lihat Memantau performa pipeline.

Dataproc

Bagian ini menjelaskan praktik terbaik untuk mengoptimalkan performa dari cluster Dataproc Anda.

Melakukan penskalaan otomatis cluster

Untuk memastikan cluster Dataproc Anda memberikan performa yang dapat diprediksi, Anda dapat mengaktifkan penskalaan otomatis. Dataproc menggunakan metrik memori Hadoop YARN dan kebijakan penskalaan otomatis yang Anda tentukan untuk menyesuaikan otomatis jumlah worker VM dalam cluster. Untuk mengetahui informasi selengkapnya tentang cara menggunakan dan mengonfigurasi penskalaan otomatis, lihat Cluster penskalaan otomatis.

Penyediaan penyimpanan yang sesuai

Pilih opsi penyimpanan yang sesuai untuk cluster Dataproc Anda berdasarkan performa dan persyaratan biaya Anda:

• Jika Anda memerlukan sistem file (HCFS) yang kompatibel dengan Hadoop murah dan dapat dibaca serta ditulis oleh tugas Hadoop dan Spark dengan sedikit perubahan, gunakan Cloud Storage. Data yang disimpan di Cloud Storage bersifat persisten, dan dapat diakses oleh cluster Dataproc lain serta produk lainnya seperti BigQuery.
• Jika Anda memerlukan Hadoop Distributed File System (HDFS) berlatensi rendah untuk cluster Dataproc, gunakan persistent disk Compute Engine yang terpasang ke worker node. Data yang disimpan dalam penyimpanan HDFS bersifat sementara, dan biaya penyimpanannya lebih tinggi daripada opsi Cloud Storage.
• Untuk mendapatkan keunggulan performa dari persistent disk Compute Engine serta manfaat biaya dan ketahanan Cloud Storage, Anda dapat menggabungkan kedua opsi penyimpanan. Misalnya, Anda dapat menyimpan set data sumber dan akhir di Cloud Storage, serta menyediakan kapasitas HDFS terbatas untuk set data perantara. Saat Anda menentukan ukuran dan jenis disk untuk penyimpanan HDFS, pertimbangkan rekomendasi di bagian Persistent disk dan SSD lokal.

Mengurangi latensi saat menggunakan Cloud Storage

Untuk mengurangi latensi saat Anda mengakses data yang disimpan di Cloud Storage, sebaiknya lakukan hal berikut:

• Buat bucket Cloud Storage di region yang sama dengan cluster Dataproc.
• Nonaktifkan auto.purge untuk tabel yang dikelola Apache Hive yang disimpan di Cloud Storage.
• Saat menggunakan Spark SQL, pertimbangkan untuk membuat cluster Dataproc dengan versi terbaru dari image yang tersedia. Dengan menggunakan versi terbaru, Anda dapat menghindari masalah performa yang mungkin masih ada di versi lama, seperti performa INSERT OVERWRITE lambat di Spark 2.x.
• Untuk meminimalkan kemungkinan penulisan pada banyak file dengan ukuran yang bervariasi atau kecil ke Cloud Storage, Anda dapat mengonfigurasi parameter Spark SQL spark.sql.shuffle.partitions dan spark.default.parallelism, atau mapreduce.job.reduces parameter Hadoop.

Memantau dan menyesuaikan beban dan kapasitas penyimpanan

Persistent disk yang dipasang ke worker node di cluster Dataproc menyimpan data shuffle. Agar dapat berperforma optimal, worker node memerlukan kapasitas disk yang memadai. Jika node tidak memiliki ruang disk yang memadai, node akan ditandai sebagai UNHEALTHY di log YARN NodeManager. Jika masalah ini muncul, tingkatkan ukuran disk untuk node yang terpengaruh, atau jalankan lebih sedikit tugas secara bersamaan.

Aktifkan EFM

Jika worker node dihapus dari cluster Dataproc yang sedang berjalan, misalnya karena downscaling atau preemption, data acak kemungkinan akan hilang. Untuk meminimalkan penundaan tugas dalam skenario tersebut, sebaiknya aktifkan Mode Fleksibilitas yang Ditingkatkan (EFM) untuk cluster yang menggunakan preemptible VM atau hanya melakukan skala otomatis grup worker sekunder.

Langkah selanjutnya

Tinjau praktik terbaik untuk mengoptimalkan performa resource compute, penyimpanan, jaringan, dan database Anda:

• Optimalkan performa compute.
• Mengoptimalkan performa penyimpanan.
• Mengoptimalkan performa jaringan.
• Mengoptimalkan performa database.

Yang baru di Framework Arsitektur

Dokumen ini berisi perubahan signifikan pada Framework Arsitektur Google Cloud

28 November 2023

• Kategori keandalan:
  • Mengatur ulang konten untuk meningkatkan keterbacaan dan konsistensi:
  • Menentukan SLO: Memindahkan bagian "Terminology" ke halaman baru: Terminology
  • Menggunakan SLO: Memindahkan bagian "SLO dan Alerts" ke halaman baru: SLO dan Alerts

9 November 2023

• Kategori desain sistem:
  • Menambahkan panduan untuk membantu arsitek cloud memilih arketipe deployment untuk workload di Google Cloud.

8 September 2023

• Kategori pengoptimalan biaya:

  • Menambahkan informasi tentang penggunaan tag untuk alokasi biaya dan tata kelola.
  • Memperbarui panduan untuk mengidentifikasi anomali pelabelan.

  Untuk informasi selengkapnya, lihat Melacak dan mengalokasikan biaya menggunakan tag atau label.

28 Agustus 2023

• Kategori desain sistem:
  • Memperbarui daftar dari layanan AI dan ML di Google Cloud.

23 Agustus 2023

• Kategori pengoptimalan biaya:
  • Menambahkan panduan tentang pengoptimalan penggunaan resource Spanner untuk workload kecil dengan menggunakan Unit Pemrosesan, bukan node.

18 Agustus 2023

• Kategori keamanan, privasi, dan kepatuhan:
  • Menambahkan panduan terkait HIPAA.
• Kategori keunggulan operasional:
  • Memperbarui praktik terbaik untuk merencanakan peristiwa traffic puncak.

9 Agustus 2023

• Kategori keandalan:
  • Menambahkan link ke dokumentasi terkait keandalan untuk produk berikut:
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

13 Juli 2023

• Desain sistem:
  • Menambahkan AlloyDB untuk PostgreSQL ke daftar layanan database di Google Cloud.
• Pengoptimalan biaya:
  • Menambahkan panduan tentang Google Cloud Hyperdisk dan SSD lokal di bagian Persistent Disk.

23 Juni 2023

• Pengoptimalan performa:
  • Menambahkan panduan tentang cara mengoptimalkan penggunaan bandwidth menggunakan frame jumbo dan jenis mesin yang sesuai untuk VM.

15 Juni 2023

• Keamanan, privasi, dan kepatuhan:
  • Menambahkan panduan tentang mengamankan koneksi ke lingkungan lokal dan multicloud dengan menggunakan Cross-Cloud Interconnect.
  • Menambahkan panduan tentang mengamankan perimeter workload cloud dengan menggunakan aturan dan kebijakan firewall serta Secure Web Proxy.

30 Maret 2023

• Menambahkan dua artikel SLO tambahan ke framework:
  • Menentukan SLO
  • Mengadopsi SLO

16 September 2022

• Perluasan besar dari kategori pengoptimalan performa.

10 Agustus 2022

• Perubahan dalam kategori Desain sistem:
  • Menambahkan prinsip inti desain sistem.
  • Menambahkan rekomendasi untuk menggunakan layanan konsultasi Google Cloud dan berinteraksi dengan partner kami.

4 Agustus 2022

• Menambahkan informasi tentang kemampuan berikut dalam kategori pengoptimalan biaya:

  • Mencegah pemadaman layanan karena masalah penagihan dengan mengunci penautan antara project dan akun penagihannya. Untuk informasi lebih lanjut, lihat Mengonfigurasi kontrol akses penagihan.

  • Mengurangi kuota menggunakan Service Usage API. Untuk informasi selengkapnya, lihat Anggaran, pemberitahuan, dan kuota.

  • Mengidentifikasi dan menghapus proyek yang tidak diawasi. Untuk informasi selengkapnya, lihat rekomendasi Active Assist.

13 Juli 2022

• Perubahan dalam kategori keunggulan operasional:

  • Menambahkan praktik terbaik tentang cara membangun pusat keunggulan.
  • Menambahkan praktik terbaik tentang cara menyiapkan jejak audit.

27 Juni 2022

• Menambahkan informasi tentang tanggung jawab bersama dan konsekuensi bersama di Google Cloud dalam kategori Keamanan.

13 Juni 2022

• Menambahkan rekomendasi untuk membantu Anda mendesain workload cloud untuk keberlanjutan lingkungan dalam kategori desain sistem.

1 Juni 2022

• Menambahkan informasi tentang Spot VM di bagian Mengoptimalkan biaya: Compute, container, dan serverless.

7 Mei 2022

• Menambahkan informasi tentang lokasi dual-region dalam praktik terbaik pengoptimalan biaya untuk Cloud Storage.

4 Mei 2022

• Menambahkan panduan keandalan produk. Panduan ini mencakup praktik terbaik keandalan untuk produk berikut:

  • Compute: Compute Engine, Cloud Run, Cloud Functions, dan Google Kubernetes Engine

  • Penyimpanan dan database: Cloud Storage, Firestore

  • Networking: Cloud DNS dan Cloud Load Balancing

  • Analisis data: BigQuery

25 Februari 2022

• Perubahan pada kategori keamanan:

  • Memperbarui praktik terbaik kepatuhan untuk membahas otomatisasi.

15 Desember 2021

• Peluncuran ruang Framework Arsitektur di Komunitas Google Cloud.

25 Oktober 2021

• Perubahan dalam kategori keandalan:

  • Menambahkan praktik terbaik untuk mereplikasi data di seluruh region untuk pemulihan dari bencana dan merancang arsitektur multi-region untuk ketahanan terhadap pemadaman layanan regional.
  • Menambahkan contoh cara menghitung anggaran error.
  • Menambahkan praktik terbaik untuk memilih nama yang bagus untuk aplikasi dan layanan.

7 Oktober 2021

• Pembaruan besar dari semua kategori.

---

1. Anna Berenberg dan Brad Calder, Arsitektur Deployment untuk Aplikasi Cloud, Survei ACM Computing, Volume 55, Edisi 3, Artikel No.: 61, hlm 1-48 ↩