Deployment regional di Compute Engine

Last reviewed 2024-01-31 UTC

Dokumen ini berisi 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 menghosting ulang (lift-and-shift) aplikasi lokal ke cloud secara efisien dengan melakukan perubahan minimal pada aplikasi. Dokumen ini juga menjelaskan faktor desain yang harus Anda pertimbangkan saat membangun arsitektur regional untuk aplikasi cloud. Audiens yang dituju untuk dokumen ini adalah arsitek cloud.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk aplikasi yang berjalan dalam mode aktif-aktif dalam stack terisolasi yang di-deploy di tiga zona Google Cloud dalam suatu region. Arsitektur ini selaras dengan arketipe deployment regional, yang memastikan bahwa topologi Google Cloud Anda kuat terhadap gangguan zona.

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

Arsitekturnya didasarkan pada model cloud Infrastructure as a Service (IaaS). Anda menyediakan resource infrastruktur yang diperlukan (komputasi, jaringan, dan penyimpanan) di Google Cloud. Anda tetap memiliki kontrol 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 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 tepat, 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 melakukan load balancing terhadap traffic TCP, gunakan Load Balancer Jaringan. 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 yang 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 yang berbeda. Setiap VM menghosting instance independen dari tingkat aplikasi.

Database pihak ketiga yang di-deploy di VM Compute Engine

Arsitektur dalam dokumen ini menunjukkan 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 menginstal dan mengelola database pihak ketiga serta memanfaatkan fitur ketersediaan tinggi (HA) bawaan dengan menggunakan layanan database 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 ini menggunakan satu subnet dan jaringan VPC.

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

Bucket dual-region Cloud Storage

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

Atau, Anda dapat menggunakan Layanan Pencadangan dan DR 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 yang berperforma tinggi, skalabel, global, dan regional.
  • Cloud Storage: Penyimpanan objek tanpa batas dan hemat biaya untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi ke berbagai lokasi untuk redundansi.
  • Virtual Private Cloud: Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk workload Google Cloud Anda.

Kasus penggunaan

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

Migrasi aplikasi lokal yang efisien

Anda dapat menggunakan arsitektur referensi ini untuk membangun topologi Google Cloud untuk 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 keunggulan biaya, keandalan, performa, dan kemudahan operasional yang disediakan Google Cloud.

Aplikasi yang sangat tersedia dengan pengguna dalam area geografis

Kami merekomendasikan arsitektur deployment regional untuk aplikasi yang memerlukan keandalan terhadap pemadaman zona, tetapi dapat menoleransi beberapa periode nonaktif yang disebabkan oleh pemadaman region. Jika salah satu bagian dari stack aplikasi gagal, aplikasi akan terus berjalan jika setidaknya ada satu komponen yang berfungsi dengan kapasitas yang memadai di setiap tingkat. Jika terjadi pemadaman 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 terdekat dengan pengguna Anda.

Networking berlatensi rendah antar-komponen aplikasi

Arsitektur region tunggal mungkin sangat cocok untuk aplikasi seperti komputasi batch yang memerlukan koneksi jaringan berlatensi 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 tetap berlaku.

Kepatuhan terhadap persyaratan residensi data

Anda dapat menggunakan arsitektur satu region untuk membuat topologi yang membantu Anda memenuhi persyaratan residensi data. Misalnya, sebuah negara di Eropa mungkin mengharuskan semua data pengguna disimpan dan diakses di pusat data yang secara fisik berada di dalam Eropa. Untuk memenuhi persyaratan ini, Anda dapat menjalankan aplikasi di region Google Cloud di Eropa.

Pertimbangan desain

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

Desain sistem

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

Pilihan wilayah

Saat memilih region Google Cloud untuk aplikasi Anda, pertimbangkan faktor dan persyaratan berikut:

  • Ketersediaan layanan Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Produk yang tersedia berdasarkan lokasi.
  • Ketersediaan jenis mesin Compute Engine. Untuk informasi selengkapnya, lihat Region dan zona.
  • Persyaratan latensi pengguna akhir.
  • Biaya resource Google Cloud.
  • Persyaratan peraturan.

Beberapa faktor dan persyaratan ini mungkin membutuhkan kompromi. Misalnya, wilayah yang paling hemat biaya mungkin tidak memiliki jejak karbon terendah. Untuk mengetahui informasi selengkapnya, lihat Memilih zona dan region geografis di Framework Arsitektur Google Cloud.

Layanan komputasi

Arsitektur referensi dalam dokumen ini menggunakan VM Compute Engine untuk semua tingkat aplikasi. Panduan desain dalam dokumen ini khusus untuk Compute Engine kecuali jika dinyatakan lain.

Bergantung pada persyaratan aplikasi, Anda dapat memilih dari layanan komputasi Google Cloud lainnya berikut. Panduan desain untuk layanan tersebut berada di luar cakupan dokumen ini.

  • 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.
  • 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 dan Cloud Functions.

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 hanya memerlukan sedikit upaya pengelolaan. Untuk mengetahui informasi selengkapnya tentang cara memilih layanan komputasi yang sesuai untuk workload Anda di Google Cloud, lihat Memilih dan mengelola komputasi di Framework Arsitektur 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.

Untuk penyimpanan berbiaya rendah yang redundan di seluruh zona dalam suatu region, Anda dapat menggunakan bucket regional Cloud Storage.

Untuk menyimpan data yang dibagikan ke beberapa VM dalam satu region, seperti di semua VM di tingkat web atau tingkat aplikasi, Anda dapat menggunakan instance Filestore Enterprise. Data yang Anda simpan di instance Filestore Enterprise direplikasi secara sinkron di tiga zona dalam region. Replikasi ini memastikan HA dan keandalan terhadap pemadaman zona. Anda dapat menyimpan file konfigurasi bersama, utilitas dan alat umum, serta log terpusat dalam instance Filestore, dan memasang instance pada beberapa VM.

Jika database Anda adalah Microsoft SQL Server, sebaiknya gunakan Cloud SQL untuk SQL Server. Jika Cloud SQL tidak mendukung persyaratan konfigurasi Anda, atau jika Anda memerlukan akses ke sistem operasi, Anda dapat men-deploy instance cluster failover (FCI). 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 regional, pertimbangkan karakteristik fungsional beban kerja, persyaratan ketahanan, ekspektasi performa, dan sasaran biaya. Untuk mengetahui informasi selengkapnya, lihat Mendesain strategi penyimpanan yang optimal untuk beban kerja cloud Anda.

Layanan database

Arsitektur referensi dalam dokumen ini menggunakan database pihak ketiga, seperti PostgreSQL, 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, dan memulihkan dari kegagalan.

Untuk menghindari upaya dan biaya penginstalan serta pengelolaan database pihak ketiga, gunakan 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 kemampuan observasi. Jika beban kerja Anda memerlukan database Oracle, Anda dapat menggunakan Solusi Bare Metal yang disediakan oleh Google Cloud. Untuk ringkasan kasus penggunaan yang sesuai untuk setiap layanan database Google Cloud, lihat Database Google Cloud.

Keamanan dan kepatuhan

Bagian ini menjelaskan faktor-faktor yang harus dipertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membangun topologi regional di Google Cloud yang memenuhi persyaratan keamanan dan kepatuhan beban kerja Anda.

Perlindungan terhadap ancaman eksternal

Untuk melindungi aplikasi Anda dari ancaman eksternal, seperti serangan distributed denial of service (DDoS) dan pembuatan skrip lintas situs (XSS), Anda dapat menggunakan kebijakan keamanan Google Cloud Armor. Kebijakan keamanan diterapkan di perimeter—yaitu, sebelum traffic mencapai tingkat web. Setiap kebijakan adalah kumpulan aturan yang menetapkan kondisi tertentu yang harus dievaluasi dan tindakan yang akan diambil jika kondisi terpenuhi. Misalnya, sebuah aturan dapat menentukan bahwa jika alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu, traffic tersebut harus ditolak. Selain itu, Anda 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 yang menghosting tingkat aplikasi, tingkat web, dan database tidak memerlukan akses masuk dari internet. Jangan menetapkan alamat IP eksternal ke VM tersebut. Resource Google Cloud yang hanya memiliki alamat IP internal pribadi masih dapat mengakses Google API dan layanan Google tertentu menggunakan Private Service Connect atau Akses Google Pribadi. Untuk mengetahui informasi selengkapnya, lihat Opsi akses pribadi untuk layanan.

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

Keamanan image VM

Untuk memastikan VM Anda hanya menggunakan image yang disetujui (yaitu, image dengan software yang memenuhi persyaratan kebijakan atau keamanan Anda), Anda dapat menentukan kebijakan organisasi yang membatasi penggunaan image dalam project image publik tertentu. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan kebijakan image tepercaya.

Hak istimewa akun layanan

Dalam project Google Cloud yang mengaktifkan Compute Engine API, akun layanan default akan dibuat secara otomatis. Akun layanan default diberi peran IAM Editor (roles/editor) kecuali jika perilaku ini dinonaktifkan. Secara default, akun layanan default dikaitkan ke semua VM yang Anda buat menggunakan Google Cloud CLI atau Konsol Google Cloud. Peran Editor mencakup berbagai izin, sehingga menambahkan akun layanan default ke VM akan menimbulkan risiko keamanan. Untuk menghindari risiko ini, Anda dapat membuat dan menggunakan akun layanan khusus untuk setiap aplikasi. Untuk menentukan resource yang dapat diakses akun layanan, gunakan kebijakan yang terperinci. Untuk informasi selengkapnya, lihat Membatasi hak istimewa akun layanan di "Praktik terbaik untuk menggunakan akun layanan".

Keamanan jaringan

Untuk mengontrol traffic jaringan antar-resource dalam arsitektur, Anda harus menyiapkan aturan Firewall Cloud Next Generation yang sesuai. Setiap aturan firewall memungkinkan Anda mengontrol traffic berdasarkan parameter seperti protokol, alamat IP, dan port. Misalnya, Anda dapat mengonfigurasi aturan firewall untuk mengizinkan traffic TCP dari VM server web ke port VM database tertentu, dan memblokir semua traffic lainnya.

Pertimbangan keamanan lainnya

Saat Anda membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik dan rekomendasi keamanan tingkat platform yang diberikan dalam blueprint Security Foundation.

Keandalan

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

Pemadaman infrastruktur

Dalam arsitektur regional, jika ada komponen individual dalam stack infrastruktur gagal, aplikasi dapat memproses permintaan jika ada setidaknya satu komponen yang berfungsi dengan kapasitas memadai di setiap tingkat. Misalnya, jika ada 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 mengalami error, MIG akan membuat ulang VM secara otomatis.

Jika terjadi pemadaman zona, load balancer tidak akan terpengaruh karena merupakan resource regional. Gangguan zona dapat memengaruhi setiap VM Compute Engine. Namun, aplikasi 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 mengatasi gangguan zona, Anda harus memverifikasi bahwa aplikasi berjalan seperti yang diharapkan di semua zona tempat aplikasi di-deploy.

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

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

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

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi pada VM di MIG regional, aplikasi akan tetap tersedia selama pemadaman layanan zona terisolasi. Kemampuan penskalaan otomatis pada MIG stateless memungkinkan Anda mempertahankan ketersediaan dan performa aplikasi pada tingkat yang dapat diprediksi. MIG stateful tidak dapat diskalakan otomatis.

Untuk mengontrol perilaku penskalaan otomatis MIG, Anda dapat menentukan metrik utilisasi target, seperti pemakaian CPU rata-rata. Anda juga dapat mengonfigurasi penskalaan otomatis berbasis jadwal. Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis grup instance.

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 cukup memori. 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 memulihkan (memperbaiki) VM. Untuk mengetahui informasi selengkapnya tentang mengonfigurasi autohealing, lihat Menyiapkan health check dan autohealing aplikasi.

Penempatan VM

Dalam arsitektur yang dijelaskan dalam dokumen ini, tingkat aplikasi dan tingkat web dijalankan di VM Compute Engine yang didistribusikan di berbagai zona. Distribusi ini memastikan aplikasi Anda andal terhadap gangguan zona. Untuk meningkatkan keandalan ini lebih lanjut, Anda dapat membuat kebijakan penempatan penyebaran dan menerapkannya ke template MIG. Saat membuat VM, MIG akan menempatkan VM di dalam setiap zona di server fisik yang berbeda (disebut host), sehingga VM Anda andal terhadap kegagalan host individual. Untuk mengetahui informasi selengkapnya, baca artikel Menerapkan kebijakan penempatan selisih pada VM.

Perencanaan kapasitas VM

Guna memastikan kapasitas untuk VM Compute Engine tersedia saat diperlukan untuk penskalaan otomatis MIG, Anda dapat membuat reservasi. Reservasi menyediakan kapasitas terjamin di zona tertentu untuk sejumlah VM tertentu dari jenis mesin yang Anda pilih. Reservasi dapat bersifat spesifik untuk sebuah project, atau dibagikan ke beberapa project. Anda dikenai biaya untuk resource yang dicadangkan meskipun resource tersebut tidak disediakan atau digunakan. Untuk mengetahui informasi selengkapnya tentang reservasi, termasuk pertimbangan penagihan, lihat Reservasi resource zona Compute Engine.

Status persistent disk

Praktik terbaik dalam desain aplikasi adalah menghindari kebutuhan akan disk lokal berstatus. Namun, jika persyaratan tersebut ada, Anda dapat mengonfigurasi persistent disk agar berstatus stateful untuk memastikan data dipertahankan saat VM diperbaiki atau dibuat ulang. Namun, sebaiknya biarkan boot disk tetap stateless, agar Anda dapat mengupdatenya dengan mudah 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 Pencadangan dan DR untuk membuat, menyimpan, dan mengelola cadangan VM Compute Engine. Cadangan dan 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 tanpa memakan waktu pada pemindahan data atau aktivitas persiapan.

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.

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

  • Anda dapat menggunakan snapshot untuk merekam status titik waktu volume Persistent Disk. Snapshot standar disimpan secara redundan di beberapa region, dengan checksum otomatis untuk memastikan integritas data. Snapshot bersifat inkremental secara default, sehingga menggunakan lebih sedikit ruang penyimpanan dan menghemat uang. Snapshot disimpan di lokasi Cloud Storage yang dapat Anda konfigurasi. Untuk rekomendasi lebih lanjut mengenai cara menggunakan dan mengelola snapshot, lihat Praktik terbaik untuk snapshot disk Compute Engine.
  • Volume Persistent Disk Regional memungkinkan Anda menjalankan aplikasi dengan ketersediaan tinggi yang tidak terpengaruh oleh kegagalan di persistent disk. Saat Anda membuat volume Persistent Disk regional, Compute Engine mempertahankan replika disk di zona berbeda di region yang sama. Data direplikasi secara sinkron ke disk di kedua zona. Jika salah satu dari kedua zona tersebut mengalami pemadaman, data akan tetap tersedia.

Ketersediaan database

Jika Anda menggunakan layanan database terkelola, seperti Cloud SQL dengan konfigurasi HA, maka jika terjadi kegagalan database utama, Cloud SQL akan beralih secara otomatis 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 tersebut dapat terhubung ke database lain jika database utama tidak tersedia.

Agar dapat menerapkan failover lintas zona untuk database yang di-deploy di VM Compute Engine, Anda memerlukan mekanisme untuk mengidentifikasi kegagalan database utama dan proses untuk mengalihkan 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 mengetahui contoh arsitektur yang dapat Anda gunakan untuk mengimplementasikan failover untuk database PostgreSQL, lihat Arsitektur untuk ketersediaan tinggi cluster PostgreSQL di Compute Engine.

Pertimbangan keandalan lainnya

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

Pengoptimalan biaya

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

Jenis mesin VM

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