Deployment regional di Compute Engine

Last reviewed 2025-08-12 UTC

Dokumen ini memberikan arsitektur referensi untuk aplikasi multi-tingkat yang berjalan di VM Compute Engine di beberapa zona dalam satu region Google Cloud. Anda dapat menggunakan arsitektur referensi ini untuk meng-hosting ulang (lift and shift) aplikasi lokal ke cloud secara efisien dengan perubahan minimal pada aplikasi. Dokumen ini juga menjelaskan faktor desain yang harus Anda pertimbangkan saat membangun arsitektur regional untuk aplikasi cloud Anda. Audiens yang dituju untuk dokumen ini adalah cloud architect.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk aplikasi yang berjalan dalam mode aktif-aktif di stack terisolasi yang di-deploy di tiga zonaGoogle Cloud dalam satu region. Arsitektur ini selaras dengan arketipe deployment regional.

Aplikasi berjalan dalam mode aktif-aktif di stack terisolasi yang di-deploy di tiga zona Google Cloud dalam satu region.

Arsitektur ini didasarkan pada model cloud infrastructure as a service (IaaS). Anda menyediakan resource infrastruktur yang diperlukan (komputasi, jaringan, dan penyimpanan) di Google Cloud. Anda tetap memegang kendali penuh atas infrastruktur dan tanggung jawab atas sistem operasi, middleware, dan lapisan stack aplikasi yang lebih tinggi. Untuk mempelajari lebih lanjut IaaS dan model cloud lainnya, lihat PaaS vs. IaaS vs. SaaS vs. CaaS: Apa saja perbedaannya?.

Diagram sebelumnya mencakup komponen berikut:

Komponen Tujuan
Load balancer eksternal regional

Load balancer eksternal regional menerima dan mendistribusikan permintaan pengguna ke VM tingkat web.

Gunakan jenis load balancer yang sesuai, bergantung pada jenis traffic dan persyaratan lainnya. Misalnya, jika backend terdiri dari server web (seperti yang ditunjukkan dalam arsitektur sebelumnya), gunakan Load Balancer Aplikasi untuk meneruskan traffic HTTP(S). Untuk menyeimbangkan beban traffic TCP, gunakan Network Load Balancer. Untuk mengetahui informasi selengkapnya, lihat Memilih load balancer.

Grup instance terkelola (MIG) regional untuk tingkat web

Tingkat web aplikasi di-deploy di VM Compute Engine yang merupakan bagian dari MIG regional. MIG adalah backend untuk load balancer eksternal regional.

MIG berisi VM Compute Engine di tiga zona berbeda. Setiap VM ini menghosting instance independen dari tingkat web aplikasi.

Load balancer internal regional

Load balancer internal regional mendistribusikan traffic dari VM tingkat web ke VM tingkat aplikasi.

Bergantung pada persyaratan Anda, Anda dapat menggunakan Load Balancer Aplikasi internal regional atau Load Balancer Jaringan. Untuk mengetahui informasi selengkapnya, lihat Memilih load balancer.

MIG regional untuk tingkat aplikasi

Tingkat aplikasi di-deploy di VM Compute Engine yang merupakan bagian dari MIG regional, yang merupakan backend untuk load balancer internal.

MIG berisi VM Compute Engine di tiga zona berbeda. Setiap VM menghosting instance independen dari tingkat aplikasi.

Database pihak ketiga yang di-deploy di VM Compute Engine

Arsitektur dalam dokumen ini menampilkan database pihak ketiga (seperti PostgreSQL) yang di-deploy di VM Compute Engine. Anda dapat men-deploy database standby di zona lain. Kemampuan replikasi dan failover database bergantung pada database yang Anda gunakan.

Menginstal dan mengelola database pihak ketiga memerlukan upaya dan biaya operasional tambahan untuk menerapkan update, memantau, dan memastikan ketersediaan. Anda dapat menghindari overhead penginstalan dan pengelolaan database pihak ketiga serta memanfaatkan fitur ketersediaan tinggi (HA) bawaan dengan menggunakan layanan database yang terkelola sepenuhnya seperti Cloud SQL atau AlloyDB untuk PostgreSQL. Untuk mengetahui informasi selengkapnya tentang opsi database terkelola, lihat Layanan database nanti dalam panduan ini.

Jaringan Virtual Private Cloud dan subnet

Semua resource Google Cloud dalam arsitektur menggunakan satu jaringan VPC dan subnet.

Bergantung pada kebutuhan, Anda dapat memilih untuk membangun arsitektur yang menggunakan beberapa jaringan VPC atau beberapa subnet. Untuk mengetahui informasi selengkapnya, lihat Menentukan apakah akan membuat beberapa jaringan VPC atau tidak di "Praktik terbaik dan arsitektur referensi untuk desain VPC".

Bucket dual-region Cloud Storage

Cadangan aplikasi dan database disimpan di bucket Cloud Storage dual-region. Jika terjadi pemadaman layanan zona atau region, aplikasi dan data Anda tidak akan hilang.

Atau, Anda dapat menggunakan Backup and DR Service untuk membuat, menyimpan, dan mengelola cadangan database.

Produk yang digunakan

Arsitektur referensi ini menggunakan produk Google Cloud berikut:

  • Compute Engine: Layanan komputasi yang aman dan dapat disesuaikan yang memungkinkan Anda membuat dan menjalankan VM di infrastruktur Google.
  • Cloud Load Balancing: Portofolio load balancer berperforma tinggi, skalabel, global, dan regional.
  • Cloud Storage: Penyimpanan objek berbiaya rendah dan tanpa batas untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di berbagai lokasi untuk redundansi.
  • Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsionalitas jaringan global yang skalabel untuk workload Google Cloud Anda. VPC mencakup Peering Jaringan VPC, Private Service Connect, akses layanan pribadi, dan VPC Bersama.

Kasus penggunaan

Bagian ini menjelaskan kasus penggunaan yang menjadikan deployment regional di Compute Engine sebagai pilihan yang tepat.

Migrasi aplikasi lokal yang efisien

Anda dapat menggunakan arsitektur referensi ini untuk membangun topologi Google Cloud guna menghosting ulang (lift and shift) aplikasi lokal ke cloud dengan perubahan minimal pada aplikasi. Semua tingkat aplikasi dalam arsitektur referensi ini dihosting di VM Compute Engine. Pendekatan ini memungkinkan Anda memigrasikan aplikasi lokal secara efisien ke cloud dan memanfaatkan manfaat biaya, keandalan, performa, dan kemudahan operasional yang disediakanGoogle Cloud .

Aplikasi dengan tingkat ketersediaan tinggi dengan pengguna dalam area geografis

Sebaiknya gunakan arsitektur deployment regional untuk aplikasi yang memerlukan ketahanan terhadap pemadaman layanan zona, tetapi dapat menoleransi periode nonaktif yang disebabkan oleh pemadaman layanan region. Jika ada bagian dari stack aplikasi yang gagal, aplikasi akan tetap berjalan jika setidaknya ada satu komponen yang berfungsi dengan kapasitas yang memadai di setiap tingkat. Jika terjadi pemadaman layanan zona, stack aplikasi akan terus berjalan di zona lain.

Latensi rendah untuk pengguna aplikasi

Jika semua pengguna aplikasi berada dalam satu area geografis, seperti satu negara, arsitektur deployment regional dapat membantu meningkatkan performa aplikasi yang dirasakan pengguna. Anda dapat mengoptimalkan latensi jaringan untuk permintaan pengguna dengan men-deploy aplikasi di region Google Cloud yang paling dekat dengan pengguna Anda.

Jaringan latensi rendah antarkomponen aplikasi

Arsitektur satu region mungkin sangat cocok untuk aplikasi seperti komputasi batch yang memerlukan koneksi jaringan latensi rendah dan bandwidth tinggi di antara node komputasi. Semua resource berada dalam satu region Google Cloud, sehingga traffic jaringan antar-resource tetap berada dalam region tersebut. Latensi jaringan antar-resource rendah, dan Anda tidak dikenai biaya transfer data lintas region. Biaya jaringan intra-region masih berlaku.

Kepatuhan terhadap persyaratan residensi data

Anda dapat menggunakan arsitektur satu region untuk membangun topologi yang membantu Anda memenuhi persyaratan residensi data. Misalnya, suatu negara di Eropa mungkin mewajibkan semua data pengguna disimpan dan diakses di pusat data yang berlokasi secara fisik di Eropa. Untuk memenuhi persyaratan ini, Anda dapat menjalankan aplikasi di regionGoogle Cloud di Eropa.

Pertimbangan desain

Bagian ini berisi panduan untuk membantu Anda menggunakan arsitektur referensi ini guna mengembangkan arsitektur yang memenuhi persyaratan spesifik Anda terkait desain sistem, keamanan dan kepatuhan, keandalan, efisiensi operasional, biaya, dan performa.

Desain sistem

Bagian ini memberikan panduan untuk membantu Anda memilih Google Cloud region untuk deployment regional dan memilih layanan Google Cloud yang sesuai.

Pemilihan wilayah

Saat Anda memilih region Google Cloud tempat aplikasi Anda harus di-deploy, pertimbangkan faktor dan persyaratan berikut:

Beberapa faktor dan persyaratan ini mungkin melibatkan konsekuensi negatif. Misalnya, wilayah yang paling hemat biaya mungkin tidak memiliki jejak karbon terendah. Untuk informasi selengkapnya, baca Praktik terbaik untuk pemilihan region Compute Engine.

Infrastruktur komputasi

Arsitektur referensi dalam dokumen ini menggunakan VM Compute Engine untuk tingkat aplikasi tertentu. Bergantung pada persyaratan aplikasi, Anda dapat memilih dari layanan komputasi Google Cloud lainnya:

  • Container: Anda dapat menjalankan aplikasi dalam container di cluster Google Kubernetes Engine (GKE). GKE adalah mesin orkestrasi container yang mengotomatiskan deployment, penskalaan, dan pengelolaan aplikasi dalam container.
  • Serverless: Jika Anda lebih suka memfokuskan upaya IT pada data dan aplikasi, bukan menyiapkan dan mengoperasikan resource infrastruktur, Anda dapat menggunakan layanan serverless seperti Cloud Run.

Keputusan untuk menggunakan VM, container, atau layanan serverless melibatkan kompromi antara fleksibilitas konfigurasi dan upaya pengelolaan. VM dan container memberikan fleksibilitas konfigurasi yang lebih besar, tetapi Anda bertanggung jawab untuk mengelola resource. Dalam arsitektur serverless, Anda men-deploy workload ke platform yang telah dikonfigurasi sebelumnya dan memerlukan upaya pengelolaan minimal. Untuk mengetahui informasi selengkapnya tentang cara memilih layanan komputasi yang sesuai untuk workload Anda diGoogle Cloud, lihat Menghosting Aplikasi di Google Cloud.

Layanan penyimpanan

Arsitektur yang ditampilkan dalam dokumen ini menggunakan volume Persistent Disk regional untuk semua tingkat. Persistent disk menyediakan replikasi data sinkron di dua zona dalam satu region.

Google Cloud Hyperdisk memberikan performa, fleksibilitas, dan efisiensi yang lebih baik daripada Persistent Disk. Dengan Google Cloud Hyperdisk Balanced, Anda dapat menyediakan IOPS dan throughput secara terpisah dan dinamis, sehingga Anda dapat menyesuaikan volume dengan berbagai workload.

Untuk penyimpanan berbiaya rendah yang direplikasi di beberapa lokasi, Anda dapat menggunakan bucket regional, dual-region, atau multi-region Cloud Storage.

  • Data dalam bucket regional direplikasi secara sinkron di seluruh zona dalam region.
  • Data dalam bucket dual-region atau multi-region disimpan secara redundan di setidaknya dua lokasi geografis yang terpisah. Metadata ditulis secara sinkron di seluruh region, dan data direplikasi secara asinkron. Untuk bucket dual-region, Anda dapat menggunakan replikasi turbo, yang memastikan bahwa objek direplikasi di seluruh pasangan region, dengan recovery point objective (RPO) 15 menit. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan dan ketahanan data.

Untuk menyimpan data yang dibagikan di beberapa VM dalam satu region, seperti di semua VM di tingkat web atau tingkat aplikasi, Anda dapat menggunakan instance regional Filestore. Data yang Anda simpan di instance regional Filestore direplikasi secara sinkron di tiga zona dalam region tersebut. Replikasi ini memastikan ketersediaan tinggi dan ketahanan terhadap pemadaman layanan zona. Anda dapat menyimpan file konfigurasi bersama, alat dan utilitas umum, serta pencatatan terpusat di instance Filestore, dan memasang instance tersebut di beberapa VM. Untuk ketahanan terhadap pemadaman layanan region, Anda dapat mereplikasi instance Filestore ke region lain. Untuk mengetahui informasi selengkapnya, lihat Replikasi instance.

Jika database Anda adalah Microsoft SQL Server, sebaiknya gunakan Cloud SQL untuk SQL Server. Dalam skenario saat Cloud SQL tidak mendukung persyaratan konfigurasi Anda, atau jika Anda memerlukan akses ke sistem operasi, Anda dapat men-deploy instance cluster failover (FCI) Microsoft SQL Server. Dalam skenario ini, Anda dapat menggunakan Google Cloud NetApp Volumes yang terkelola sepenuhnya untuk menyediakan penyimpanan SMB ketersediaan berkelanjutan (CA) untuk database.

Saat Anda mendesain penyimpanan untuk workload, pertimbangkan karakteristik fungsional, persyaratan ketahanan, ekspektasi performa, dan sasaran biaya. Untuk informasi selengkapnya, lihat Mendesain strategi penyimpanan yang optimal untuk workload cloud Anda.

Layanan database

Arsitektur referensi dalam dokumen ini menggunakan database pihak ketiga yang di-deploy di VM Compute Engine. Menginstal dan mengelola database pihak ketiga memerlukan upaya dan biaya untuk operasi seperti menerapkan update, memantau dan memastikan ketersediaan, melakukan pencadangan, serta memulihkan dari kegagalan.

Anda dapat menghindari upaya dan biaya penginstalan dan pengelolaan database pihak ketiga dengan menggunakan layanan database yang terkelola sepenuhnya seperti Cloud SQL, AlloyDB untuk PostgreSQL, Bigtable, Spanner, atau Firestore. Layanan database Google Cloud ini menyediakan perjanjian tingkat layanan (SLA) waktu beroperasi, dan mencakup kemampuan default untuk skalabilitas dan visibilitas.

Jika workload Anda memerlukan database Oracle, Anda dapat men-deploy database di VM Compute Engine atau menggunakan Oracle Database@Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Workload Oracle di Google Cloud.

Desain jaringan

Pilih desain jaringan yang memenuhi persyaratan bisnis dan teknis Anda. Anda dapat menggunakan satu jaringan VPC atau beberapa jaringan VPC. Untuk informasi selengkapnya, lihat dokumentasi berikut:

Keamanan, privasi, dan kepatuhan

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membangun topologi regional diGoogle Cloud yang memenuhi persyaratan keamanan, privasi, dan kepatuhan workload Anda.

Perlindungan dari ancaman eksternal

Untuk melindungi aplikasi Anda dari ancaman seperti serangan distributed-denial-of-service (DDoS) dan pembuatan skrip lintas situs (XSS), Anda dapat menggunakan kebijakan keamanan Google Cloud Armor. Setiap kebijakan adalah sekumpulan aturan yang menentukan kondisi tertentu yang harus dievaluasi dan tindakan yang harus diambil saat kondisi tersebut terpenuhi. Misalnya, aturan dapat menentukan bahwa jika alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu, traffic tersebut harus ditolak. Anda juga dapat menerapkan aturan firewall aplikasi web (WAF) yang telah dikonfigurasi sebelumnya. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan keamanan.

Akses eksternal untuk VM

Dalam arsitektur referensi yang dijelaskan dalam dokumen ini, VM Compute Engine tidak memerlukan akses masuk dari internet. Jangan tetapkan alamat IP eksternal ke VM. Google Cloud resource yang hanya memiliki alamat IP internal pribadi masih dapat mengakses API dan layanan Google tertentu menggunakan Private Service Connect atau Akses Google Pribadi. Untuk informasi selengkapnya, lihat Opsi akses pribadi untuk layanan.

Untuk mengaktifkan koneksi keluar yang aman dari resource Google Cloud yang hanya memiliki alamat IP pribadi, seperti VM Compute Engine dalam arsitektur referensi ini, Anda dapat menggunakan Secure Web Proxy atau Cloud NAT.

Hak istimewa akun layanan

Untuk VM Compute Engine dalam arsitektur, sebaiknya buat akun layanan khusus dan tentukan resource yang dapat diakses oleh akun layanan tersebut, bukan menggunakan akun layanan default. Akun layanan default memiliki berbagai izin, termasuk beberapa izin yang mungkin tidak diperlukan. Anda dapat menyesuaikan akun layanan khusus agar hanya memiliki izin yang diperlukan. Untuk mengetahui informasi selengkapnya, lihat Membatasi hak istimewa akun layanan.

Keamanan SSH

Untuk meningkatkan keamanan koneksi SSH ke VM Compute Engine dalam arsitektur Anda, terapkan Identity-Aware Proxy (IAP) dan Cloud OS Login API. IAP memungkinkan Anda mengontrol akses jaringan berdasarkan identitas pengguna dan kebijakan Identity and Access Management (IAM). Cloud OS Login API memungkinkan Anda mengontrol akses SSH Linux berdasarkan identitas pengguna dan kebijakan IAM. Untuk mengetahui informasi selengkapnya tentang mengelola akses jaringan, lihat Praktik terbaik untuk mengontrol akses login SSH.

Keamanan jaringan

Untuk mengontrol traffic jaringan antar-resource dalam arsitektur, Anda harus mengonfigurasi kebijakan Cloud Next Generation Firewall (NGFW) yang sesuai.

Pertimbangan keamanan lainnya

Saat Anda membangun arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi keamanan tingkat platform yang disediakan dalam Blueprint fondasi perusahaan dan Google Cloud Well-Architected Framework: Keamanan, privasi, dan kepatuhan.

Keandalan

Bagian ini menjelaskan faktor desain yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk membangun dan mengoperasikan infrastruktur yang andal untuk deployment regional Anda di Google Cloud.

Pemadaman layanan infrastruktur

Dalam arsitektur regional, jika ada komponen individual dalam stack infrastruktur yang gagal, aplikasi dapat memproses permintaan jika setidaknya ada satu komponen yang berfungsi dengan kapasitas yang memadai di setiap tingkat. Misalnya, jika instance server web gagal, load balancer akan meneruskan permintaan pengguna ke instance server web lain yang tersedia. Jika VM yang menghosting server web atau instance server aplikasi tidak bekerja, MIG akan membuat ulang VM secara otomatis.

Jika terjadi pemadaman layanan zona, load balancer tidak akan terpengaruh karena merupakan resource regional. Pemadaman layanan zona dapat memengaruhi setiap VM Compute Engine. Namun, aplikasinya tetap tersedia dan responsif karena VM berada di MIG regional. MIG regional memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi. Setelah Google menyelesaikan pemadaman layanan zona, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di semua zona tempat aplikasi di-deploy.

Jika semua zona dalam arsitektur ini mengalami pemadaman layanan atau jika terjadi pemadaman layanan di region, aplikasi tidak akan tersedia. Anda harus menunggu Google menyelesaikan pemadaman layanan, lalu pastikan bahwa aplikasi berfungsi seperti yang diharapkan.

Anda dapat mengurangi periode nonaktif yang disebabkan oleh pemadaman layanan region dengan mempertahankan replika pasif (failover) stack infrastruktur di region Google Cloud lain. Jika terjadi pemadaman layanan di region utama, Anda dapat mengaktifkan stack di region failover dan menggunakan kebijakan perutean DNS untuk merutekan traffic ke load balancer di region failover.

Untuk aplikasi yang memerlukan ketahanan terhadap pemadaman layanan region, pertimbangkan untuk menggunakan arsitektur multi-regional. Untuk mengetahui informasi selengkapnya, lihat Deployment multi-regional di Compute Engine.

Penskalaan otomatis MIG

Untuk mengontrol perilaku penskalaan otomatis MIG stateless, Anda dapat menentukan metrik pemakaian target, seperti pemakaian CPU rata-rata. Anda juga dapat mengonfigurasi penskalaan otomatis berbasis jadwal untuk MIG stateless. MIG stateful tidak dapat diskalakan secara otomatis. Untuk informasi selengkapnya, lihat Penskalaan otomatis grup instance.

Batas ukuran MIG

Saat Anda menentukan ukuran MIG, pertimbangkan batas default dan maksimum jumlah VM yang dapat dibuat di MIG. Untuk mengetahui informasi selengkapnya, lihat Menambahkan dan menghapus VM dari MIG.

Autohealing VM

Terkadang VM yang menghosting aplikasi Anda mungkin berjalan dan tersedia, tetapi mungkin ada masalah dengan aplikasi itu sendiri. Aplikasi mungkin berhenti berfungsi, error, atau tidak memiliki memori yang cukup. Untuk memverifikasi apakah aplikasi merespons seperti yang diharapkan, Anda dapat mengonfigurasi health check berbasis aplikasi sebagai bagian dari kebijakan autohealing MIG Anda. Jika aplikasi pada VM tertentu tidak merespons, MIG akan otomatis memperbaiki VM tersebut. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi autohealing, lihat Tentang memperbaiki VM untuk ketersediaan tinggi.

Penempatan VM

Dalam arsitektur yang dijelaskan dalam dokumen ini, tingkat aplikasi dan tingkat web berjalan di VM Compute Engine yang didistribusikan di beberapa zona. Distribusi ini memastikan aplikasi Anda tangguh terhadap pemadaman layanan zona.

Untuk meningkatkan ketahanan arsitektur, Anda dapat membuat kebijakan penempatan tersebar dan menerapkannya ke template MIG. Saat membuat VM, MIG menempatkan VM dalam setiap zona di server fisik yang berbeda (disebut host), sehingga VM Anda tahan terhadap kegagalan setiap host. Untuk mengetahui informasi selengkapnya, lihat Membuat dan menerapkan kebijakan penempatan tersebar ke VM.

Perencanaan kapasitas VM

Untuk memastikan kapasitas VM Compute Engine tersedia saat VM perlu disediakan, Anda dapat membuat reservasi. Reservasi memberikan kapasitas yang pasti di zona tertentu untuk jumlah VM yang ditentukan dari jenis mesin yang Anda pilih. Pemesanan dapat bersifat khusus untuk satu project, atau dibagikan di beberapa project. Untuk mengetahui informasi selengkapnya tentang pemesanan, lihat Memilih jenis pemesanan.

Penyimpanan stateful

Praktik terbaik dalam desain aplikasi adalah menghindari kebutuhan akan disk lokal stateful. Namun, jika persyaratan tersebut ada, Anda dapat mengonfigurasi persistent disk menjadi stateful untuk memastikan data dipertahankan saat VM diperbaiki atau dibuat ulang. Namun, sebaiknya Anda membuat boot disk tetap stateless, sehingga Anda dapat mengupdatenya ke image terbaru dengan versi baru dan patch keamanan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi persistent disk stateful di MIG.

Ketahanan data

Anda dapat menggunakan Backup and DR Service untuk membuat, menyimpan, dan mengelola cadangan VM Compute Engine. Backup and DR menyimpan data cadangan dalam format aslinya yang dapat dibaca aplikasi. Jika diperlukan, Anda dapat memulihkan workload ke produksi dengan langsung menggunakan data dari penyimpanan cadangan jangka panjang dan menghindari kebutuhan untuk menyiapkan atau memindahkan data.

Compute Engine menyediakan opsi berikut untuk membantu Anda memastikan ketahanan data yang disimpan di volume Persistent Disk:

  • Anda dapat menggunakan snapshot untuk mengambil status point-in-time volume Persistent Disk. Snapshot disimpan secara redundan di beberapa region, dengan checksum otomatis untuk memastikan integritas data Anda. Snapshot bersifat inkremental secara default, sehingga menggunakan lebih sedikit ruang penyimpanan dan menghemat biaya. Snapshot disimpan di lokasi Cloud Storage yang dapat Anda konfigurasi. Untuk rekomendasi selengkapnya tentang penggunaan dan pengelolaan snapshot, lihat Praktik terbaik untuk snapshot disk Compute Engine.
  • Untuk memastikan data di Persistent Disk tetap tersedia jika terjadi pemadaman layanan di zona, Anda dapat menggunakan Regional Persistent Disk atau Google Cloud Hyperdisk Balanced High Availability. Data dalam jenis disk ini direplikasi secara sinkron antara dua zona di region yang sama. Untuk mengetahui informasi selengkapnya, lihat Tentang replikasi disk sinkron.

Jika Anda menggunakan layanan database terkelola seperti Cloud SQL, pencadangan akan dilakukan secara otomatis berdasarkan kebijakan retensi yang Anda tentukan. Anda dapat melengkapi strategi pencadangan dengan pencadangan logis tambahan untuk memenuhi persyaratan peraturan, alur kerja, atau bisnis.

Jika Anda menggunakan database pihak ketiga dan perlu menyimpan cadangan database dan log transaksi, Anda dapat menggunakan bucket Cloud Storage regional. Bucket Cloud Storage regional menyediakan penyimpanan cadangan berbiaya rendah yang redundan di seluruh zona.

Ketersediaan database

Jika Anda menggunakan layanan database terkelola seperti Cloud SQL dalam konfigurasi HA, maka jika terjadi kegagalan database utama, Cloud SQL akan otomatis gagal beralih ke database standby. Anda tidak perlu mengubah alamat IP untuk endpoint database. Jika Anda menggunakan database pihak ketiga yang dikelola sendiri dan di-deploy di VM Compute Engine, Anda harus menggunakan load balancer internal atau mekanisme lain untuk memastikan bahwa aplikasi dapat terhubung ke database lain jika database utama tidak tersedia.

Untuk menerapkan failover lintas zona untuk database yang di-deploy di VM Compute Engine, Anda memerlukan mekanisme untuk mengidentifikasi kegagalan database utama dan proses untuk melakukan failover ke database standby. Detail mekanisme failover bergantung pada database yang Anda gunakan. Anda dapat menyiapkan instance observer untuk mendeteksi kegagalan database utama dan mengorkestrasi failover. Anda harus mengonfigurasi aturan failover dengan tepat untuk menghindari situasi split-brain dan mencegah failover yang tidak perlu. Untuk contoh arsitektur yang dapat Anda gunakan untuk menerapkan failover pada database PostgreSQL, lihat Arsitektur untuk ketersediaan tinggi cluster PostgreSQL di Compute Engine.

Pertimbangan keandalan lainnya

Saat Anda membangun arsitektur cloud untuk workload, tinjau praktik terbaik dan rekomendasi terkait keandalan yang disediakan dalam dokumentasi berikut:

Pengoptimalan biaya

Bagian ini memberikan panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian topologi Google Cloud regional yang Anda bangun menggunakan arsitektur referensi ini.

Jenis mesin VM

Untuk membantu Anda mengoptimalkan penggunaan resource instance VM, Compute Engine memberikan rekomendasi jenis mesin. Gunakan rekomendasi untuk memilih jenis mesin yang sesuai dengan persyaratan komputasi workload Anda. Untuk workload dengan persyaratan resource yang dapat diprediksi, Anda dapat menyesuaikan jenis mesin dengan kebutuhan Anda dan menghemat uang dengan menggunakan jenis mesin kustom.

Model penyediaan VM

Jika aplikasi Anda fault-tolerant, Spot VM dapat membantu mengurangi biaya Compute Engine untuk VM di tingkat aplikasi dan web. Biaya Spot VM jauh lebih rendah daripada VM reguler. Namun, Compute Engine dapat menghentikan atau menghapus Spot VM secara preemptive untuk mengklaim kembali kapasitas.

Spot VM cocok untuk tugas batch yang dapat menoleransi preemption dan tidak memiliki persyaratan ketersediaan tinggi. Spot VM menawarkan jenis, opsi, dan performa mesin yang sama dengan VM reguler. Namun, jika kapasitas resource di suatu zona terbatas, MIG mungkin tidak dapat melakukan penyebaran skala (yaitu, membuat VM) secara otomatis ke ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia kembali.

Pemakaian resource VM

Kemampuan penskalaan otomatis MIG stateless memungkinkan aplikasi Anda menangani peningkatan traffic dengan baik, dan membantu Anda mengurangi biaya saat kebutuhan resource rendah. MIG stateful tidak dapat diskalakan secara otomatis.

Pemberian lisensi pihak ketiga

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, rekomendasi berikut mungkin dapat membantu mengurangi biaya:

  • Sediakan jumlah core CPU komputasi yang diperlukan secara terpisah dari memori dengan menggunakan jenis mesin kustom. Dengan melakukan ini, Anda membatasi 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).

Jika Anda men-deploy database pihak ketiga seperti Microsoft SQL Server di VM Compute Engine, Anda harus mempertimbangkan biaya lisensi untuk software pihak ketiga. Saat Anda menggunakan layanan database terkelola seperti Cloud SQL, biaya lisensi database sudah termasuk dalam biaya layanan.

Pertimbangan biaya lainnya

Saat membangun arsitektur untuk workload Anda, pertimbangkan juga praktik terbaik dan rekomendasi umum yang disediakan dalam Google Cloud Well-Architected Framework: Pengoptimalan biaya.

Efisiensi operasional

Bagian ini menjelaskan faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membangun topologi Google Cloudregional yang dapat Anda operasikan secara efisien.

Pembaruan konfigurasi VM

Untuk memperbarui konfigurasi VM di MIG (seperti jenis mesin atau image boot disk), buat template instance baru dengan konfigurasi yang diperlukan, lalu terapkan template baru ke MIG. MIG mengupdate VM menggunakan metode update yang Anda pilih: otomatis atau selektif. Pilih metode yang sesuai berdasarkan kebutuhan Anda akan ketersediaan dan efisiensi operasional. Untuk mengetahui informasi selengkapnya tentang metode update MIG ini, baca Menerapkan konfigurasi VM baru di MIG.

Image VM

Untuk VM Anda, sebaiknya buat dan gunakan OS image kustom yang berisi konfigurasi dan software yang diperlukan aplikasi Anda, bukan menggunakan image publik yang disediakan Google. Anda dapat mengelompokkan image kustom ke dalam kelompok image kustom. Kelompok image selalu mengarah ke image terbaru dalam kelompok tersebut, sehingga template instance dan skrip dapat menggunakan image tersebut tanpa Anda harus memperbarui referensi ke versi image tertentu. Anda harus mengupdate image kustom secara rutin untuk menyertakan update dan patch keamanan yang disediakan oleh vendor OS.

Template instance deterministik

Jika template instance yang Anda gunakan untuk MIG menyertakan skrip startup untuk menginstal software pihak ketiga, pastikan skrip tersebut secara eksplisit menentukan parameter penginstalan software seperti versi software. Jika tidak, saat MIG membuat VM, software yang diinstal di VM mungkin tidak konsisten. Misalnya, jika template instance Anda menyertakan skrip startup untuk menginstal Apache HTTP Server 2.4 (paket apache2), pastikan skrip tersebut menentukan versi apache2 yang tepat yang harus diinstal, seperti versi 2.4.69. Untuk mengetahui informasi selengkapnya, lihat Template instance deterministik.

Pertimbangan operasional lainnya

Saat membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik umum dan rekomendasi untuk efisiensi operasional yang dijelaskan dalam Google Cloud Well-Architected Framework: Keunggulan operasional.

Pengoptimalan performa

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membangun topologi regional di Google Cloud yang memenuhi persyaratan performa workload Anda.

Performa compute

Compute Engine menawarkan berbagai jenis mesin yang telah ditetapkan dan dapat disesuaikan untuk workload yang Anda jalankan di VM. Pilih jenis mesin yang sesuai berdasarkan persyaratan performa Anda. Untuk mengetahui informasi selengkapnya, lihat Panduan perbandingan dan resource kelompok mesin.

Multithreading VM

Setiap CPU virtual (vCPU) yang Anda alokasikan ke VM Compute Engine diimplementasikan sebagai hardware multithread tunggal. Secara default, dua vCPU berbagi core CPU fisik. Untuk aplikasi yang melibatkan operasi yang sangat paralel atau yang melakukan penghitungan floating point (seperti analisis urutan genetik, dan pemodelan risiko keuangan), Anda dapat meningkatkan performa dengan mengurangi jumlah thread yang berjalan pada setiap inti CPU fisik. Untuk informasi selengkapnya, lihat Menetapkan jumlah thread per core.

Multithreading VM mungkin memiliki implikasi pemberian lisensi untuk beberapa software pihak ketiga, seperti database. Untuk mengetahui informasi selengkapnya, baca dokumentasi pemberian lisensi untuk software pihak ketiga.

Network Service Tiers

Dengan Network Service Tiers, Anda dapat mengoptimalkan biaya jaringan dan performa workload. Anda dapat memilih Paket Premium atau Paket Standar. Paket Premium mengirimkan traffic di backbone global Google untuk mencapai kehilangan paket minimal dan latensi rendah. Paket Standar mengirimkan traffic menggunakan peering, internet service provider (ISP), atau jaringan transit di titik kehadiran (PoP) edge yang paling dekat dengan region tempat workload Google Cloud Anda berjalan. Untuk mengoptimalkan performa, sebaiknya gunakan Paket Premium. Untuk mengoptimalkan biaya, sebaiknya gunakan Paket Standar.

Performa jaringan

Untuk workload yang memerlukan latensi jaringan antar-VM yang rendah dalam tingkat aplikasi dan web, Anda dapat membuat kebijakan penempatan rapat dan menerapkannya ke template MIG yang digunakan untuk tingkat tersebut. Saat membuat VM, MIG menempatkan VM di server fisik yang berdekatan satu sama lain. Meskipun kebijakan penempatan rapat membantu meningkatkan performa jaringan antar-VM, kebijakan penempatan tersebar dapat membantu meningkatkan ketersediaan VM seperti yang dijelaskan sebelumnya. Untuk mencapai keseimbangan yang optimal antara performa dan ketersediaan jaringan, saat membuat kebijakan penempatan rapat, Anda dapat menentukan seberapa jauh VM harus ditempatkan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan penempatan.

Compute Engine memiliki batas per VM untuk bandwidth jaringan egress. Batas ini bergantung pada jenis mesin VM dan apakah traffic dirutekan melalui jaringan VPC yang sama dengan VM sumber. Untuk VM dengan jenis mesin tertentu, guna meningkatkan performa jaringan, Anda bisa mendapatkan bandwidth egress maksimum yang lebih tinggi dengan mengaktifkan jaringan Tier_1.

Pertimbangan performa lainnya

Saat membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik dan rekomendasi umum yang disediakan dalam Google Cloud Well-Architected Framework: Pengoptimalan performa.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: