Deployment zona tunggal di Compute Engine

Last reviewed 2024-02-08 UTC

Dokumen ini memberikan arsitektur referensi untuk aplikasi multi-lapisan yang berjalan di VM Compute Engine dalam satu zona di Google Cloud. Anda dapat menggunakan arsitektur referensi ini untuk menghosting ulang (lift and shift) aplikasi on-premise ke cloud secara efisien dengan perubahan minimal pada aplikasi. Dokumen ini juga menjelaskan faktor desain yang harus Anda pertimbangkan saat mem-build arsitektur zonal untuk aplikasi cloud. Audiens yang dituju untuk dokumen ini adalah arsitek cloud.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk aplikasi yang berjalan di satu zona Google Cloud. Arsitektur ini selaras dengan arketipe deployment zonal Google Cloud.

Arsitektur zona tunggal menggunakan Compute Engine.

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 mempertahankan kontrol penuh atas infrastruktur dan tanggung jawab atas sistem operasi, middleware, dan lapisan yang lebih tinggi dari stack aplikasi. Untuk mempelajari IaaS dan model cloud lainnya lebih lanjut, 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 melakukan load balancing traffic TCP, gunakan Load Balancer Jaringan. Untuk mengetahui informasi selengkapnya, lihat Memilih load balancer.

Grup instance terkelola (MIG) zona untuk tingkat web Tingkat web aplikasi di-deploy di VM Compute Engine yang merupakan bagian dari MIG zonal. MIG adalah backend untuk load balancer eksternal regional. Setiap VM dalam MIG 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 atau Load Balancer Jaringan regional. Untuk mengetahui informasi selengkapnya, lihat Memilih load balancer.

MIG zona untuk tingkat aplikasi Tingkat aplikasi di-deploy di VM Compute Engine yang merupakan bagian dari MIG zona, yang merupakan backend untuk load balancer internal. Setiap VM di MIG menghosting instance independen 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 penginstalan dan pengelolaan 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.

Jaringan Virtual Private Cloud dan subnet

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

Bergantung pada persyaratan Anda, Anda dapat memilih untuk mem-build 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 regional Cloud Storage

Pencadangan aplikasi dan database disimpan di bucket Cloud Storage regional. Jika pemadaman zona terjadi, aplikasi dan data Anda tidak akan hilang.

Atau, Anda dapat menggunakan Layanan Pencadangan dan DR untuk membuat, menyimpan, dan mengelola pencadangan 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 global dan regional yang skalabel, berperforma tinggi, dan andal.
  • Cloud Storage: Penyimpanan objek berbiaya rendah tanpa batas untuk berbagai jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di seluruh lokasi untuk redundansi.
  • Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk beban kerja 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 sesuai untuk deployment zona tunggal di Compute Engine.

  • Pengembangan dan pengujian cloud: Anda dapat menggunakan arsitektur deployment zona tunggal untuk membuat lingkungan cloud berbiaya rendah untuk pengembangan dan pengujian.
  • Aplikasi yang tidak memerlukan HA: Arsitektur zona tunggal mungkin cukup untuk aplikasi yang dapat mentolerir periode nonaktif karena pemadaman layanan infrastruktur.
  • Jaringan latensi rendah dan hemat biaya di antara komponen aplikasi: Arsitektur zona tunggal mungkin sangat cocok untuk aplikasi seperti komputasi batch yang memerlukan koneksi jaringan latensi rendah dan bandwidth tinggi di antara node komputasi. Dengan deployment zona tunggal, tidak ada traffic jaringan lintas zona, dan Anda tidak dikenai biaya untuk traffic intra-zona.
  • Migrasi workload komoditas: Arsitektur deployment zona menyediakan jalur migrasi cloud sederhana untuk aplikasi komoditas lokal yang kodenya tidak dapat Anda kontrol atau yang tidak dapat mendukung arsitektur di luar topologi aktif-pasif dasar.
  • Menjalankan software yang dibatasi lisensi: Arsitektur zona tunggal mungkin sangat cocok untuk sistem yang dibatasi lisensi, yang menjalankan lebih dari satu instance sekaligus terlalu mahal atau tidak diizinkan.

Pertimbangan desain

Bagian ini berisi panduan untuk membantu Anda menggunakan arsitektur referensi ini untuk 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 region dan zona Google Cloud untuk deployment zonal dan memilih layanan Google Cloud yang sesuai.

Pemilihan region

Saat memilih region dan zona 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 melibatkan konsekuensi negatif. Misalnya, wilayah yang paling hemat biaya mungkin tidak memiliki jejak karbon terendah.

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 disebutkan lain.

Bergantung pada persyaratan aplikasi Anda, 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 memilih untuk memfokuskan upaya IT pada data dan aplikasi, bukan menyiapkan dan mengoperasikan resource infrastruktur, Anda dapat menggunakan layanan serverless seperti Cloud Run dan fungsi Cloud Run.

Keputusan untuk menggunakan VM, penampung, atau layanan serverless melibatkan kompromi antara fleksibilitas konfigurasi dan upaya pengelolaan. VM dan penampung 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 yang memerlukan upaya pengelolaan minimal. Untuk mengetahui informasi selengkapnya tentang cara memilih layanan komputasi yang sesuai untuk workload Anda di Google Cloud, lihat Menghosting Aplikasi di Google Cloud dalam Framework Arsitektur Google Cloud.

Layanan penyimpanan

Arsitektur yang ditampilkan dalam dokumen ini menggunakan volume Persistent Disk zonal untuk semua tingkat. Untuk penyimpanan persisten yang lebih tahan lama, Anda dapat menggunakan volume Persistent Disk regional, yang menyediakan replikasi data secara 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 di beberapa VM dalam satu region, seperti di semua VM di tingkat web atau tingkat aplikasi, Anda dapat menggunakan Filestore. Data yang Anda simpan di instance Filestore Enterprise direplikasi secara sinkron di tiga zona dalam region. Replikasi ini memastikan ketersediaan tinggi dan ketahanan terhadap pemadaman layanan zona. Anda dapat menyimpan file konfigurasi bersama, alat dan utilitas umum, serta log terpusat di instance Filestore, dan memasang instance di beberapa VM.

Jika database Anda adalah Microsoft SQL Server, sebaiknya gunakan Cloud SQL untuk SQL Server. Dalam skenario saat Cloud SQL tidak mendukung persyaratan konfigurasi, atau jika Anda memerlukan akses ke sistem operasi, Anda dapat men-deploy instance cluster failover (FCI). Dalam skenario ini, Anda dapat menggunakan Volume NetApp Google Cloud 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, 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.

Anda dapat menghindari upaya dan biaya untuk menginstal dan mengelola 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) uptime, dan menyertakan kemampuan default untuk skalabilitas dan visibilitas. Jika workload Anda memerlukan database Oracle, Anda dapat menggunakan Solusi Bare Metal yang disediakan oleh Google Cloud. Untuk ringkasan kasus penggunaan yang sesuai dengan setiap layanan database Google Cloud, lihat database Google Cloud.

Keamanan dan kepatuhan

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membuat topologi zonal 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 denial of service (DDoS) terdistribusi 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 menentukan kondisi tertentu yang harus dievaluasi dan tindakan yang harus dilakukan jika kondisi terpenuhi. Misalnya, aturan dapat menentukan bahwa jika alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu, traffic 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 lapisan aplikasi, lapisan 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 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 internal, seperti VM Compute Engine dalam arsitektur referensi ini, Anda dapat menggunakan Cloud NAT.

Keamanan image VM

Untuk memastikan bahwa VM Anda hanya menggunakan image yang disetujui (yaitu, image dengan software yang memenuhi kebijakan atau persyaratan 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

Di project Google Cloud tempat Compute Engine API diaktifkan, 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 dilampirkan ke semua VM yang Anda buat menggunakan Google Cloud CLI atau Konsol Google Cloud. Peran Editor menyertakan berbagai izin, sehingga melampirkan 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 terperinci. Untuk informasi selengkapnya, lihat Membatasi hak istimewa akun layanan di "Praktik terbaik untuk menggunakan akun layanan".

Keamanan jaringan

Untuk mengontrol traffic jaringan di antara resource dalam arsitektur, Anda harus menyiapkan aturan Cloud Next Generation Firewall 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 tertentu dari VM database, dan memblokir semua traffic lainnya.

Pertimbangan keamanan lainnya

Saat membuat arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi keamanan tingkat platform yang diberikan dalam Blueprint fondasi perusahaan.

Keandalan

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

Pemadaman infrastruktur

Dalam arsitektur deployment zona tunggal, jika ada komponen dalam stack infrastruktur yang gagal, aplikasi dapat memproses permintaan jika setiap tingkat berisi setidaknya satu komponen yang berfungsi dengan kapasitas yang memadai. 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 mengalami error, MIG akan membuat ulang VM secara otomatis. Jika database tidak bekerja, Anda harus mengaktifkan database kedua secara manual dan memperbarui instance server aplikasi agar dapat terhubung ke database.

Pemadaman layanan zona atau pemadaman layanan region akan memengaruhi semua VM Compute Engine dalam deployment zona tunggal. Pemadaman layanan zona tidak memengaruhi load balancer dalam arsitektur ini karena merupakan resource regional. Namun, load balancer tidak dapat mendistribusikan traffic karena tidak ada backend yang tersedia. Jika terjadi pemadaman layanan zona atau region, Anda harus menunggu Google menyelesaikan pemadaman layanan tersebut, lalu pastikan aplikasi berfungsi seperti yang diharapkan.

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

Untuk aplikasi yang memerlukan ketahanan terhadap pemadaman layanan zona atau region, pertimbangkan untuk menggunakan arsitektur regional atau multi-regional. Lihat arsitektur referensi berikut:

Penskalaan otomatis MIG

Kemampuan penskalaan otomatis MIG stateless memungkinkan Anda mempertahankan ketersediaan dan performa aplikasi pada tingkat yang dapat diprediksi. MIG stateful tidak dapat diskalakan secara otomatis.

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

Batas ukuran MIG

Secara default, MIG zona dapat memiliki hingga 1.000 VM. Anda dapat meningkatkan batas ukuran MIG menjadi 2.000 VM.

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 memadai. Untuk memverifikasi apakah aplikasi merespons seperti yang diharapkan, Anda dapat mengonfigurasi health check berbasis aplikasi sebagai bagian dari kebijakan autohealing MIG. Jika aplikasi di VM tertentu tidak merespons, MIG akan memperbaiki (memulihkan) VM secara otomatis. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi autohealing, lihat Menyiapkan health check dan autohealing aplikasi.

Penempatan VM

Dalam arsitektur yang dijelaskan dalam dokumen ini, tingkat aplikasi dan tingkat web berjalan di VM Compute Engine dalam satu zona. Untuk meningkatkan keandalan arsitektur, Anda dapat membuat kebijakan penempatan spread dan menerapkannya ke template MIG. Saat membuat VM, MIG menempatkan VM di server fisik yang berbeda (disebut host), sehingga VM Anda tahan terhadap kegagalan setiap host. Untuk mengetahui informasi selengkapnya, lihat Menerapkan kebijakan penempatan spread ke VM.

Perencanaan kapasitas VM

Untuk memastikan kapasitas VM Compute Engine tersedia saat diperlukan untuk penskalaan otomatis MIG, Anda dapat membuat reservasi. Reservasi memberikan kapasitas yang pasti di zona tertentu untuk jumlah VM yang ditentukan dari jenis mesin yang Anda pilih. Reservasi dapat bersifat khusus untuk satu project, atau dibagikan di beberapa project. Anda akan dikenai biaya untuk resource yang dipesan 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 stateful. Namun, jika persyaratannya ada, Anda dapat mengonfigurasi persistent disk agar bersifat stateful untuk memastikan data dipertahankan saat VM diperbaiki atau dibuat ulang. Namun, sebaiknya Anda tetap membuat boot disk 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 Pencadangan dan DR untuk membuat, menyimpan, dan mengelola pencadangan VM Compute Engine. Pencadangan dan DR menyimpan data cadangan dalam format aslinya yang dapat dibaca aplikasi. Jika diperlukan, Anda dapat memulihkan beban kerja ke produksi dengan langsung menggunakan data dari penyimpanan cadangan jangka panjang tanpa aktivitas persiapan atau pemindahan data yang memakan waktu.

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 menggunakan database pihak ketiga dan perlu menyimpan cadangan database serta 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 menyediakan opsi berikut untuk membantu Anda memastikan ketahanan data yang disimpan dalam volume Persistent Disk:

  • Anda dapat menggunakan snapshot untuk mengambil status point-in-time volume Persistent Disk. Snapshot standar 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 Anda menghemat uang. 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.
  • 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 yang berbeda di region yang sama. Data direplikasi secara sinkron ke disk di kedua zona. Jika salah satu dari dua zona mengalami pemadaman layanan, data tetap tersedia.

Ketersediaan database

Jika Anda menggunakan layanan database terkelola seperti Cloud SQL dalam konfigurasi HA, saat terjadi kegagalan database utama, Cloud SQL akan otomatis gagal terhubung ke database standby. Anda tidak perlu mengubah alamat IP untuk endpoint database. Jika 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 aplikasi dapat terhubung ke database lain jika database utama tidak tersedia.

Untuk menerapkan failover lintas zona bagi 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 mengelola 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 untuk database PostgreSQL, lihat Arsitektur untuk ketersediaan tinggi cluster PostgreSQL di Compute Engine.

Pertimbangan keandalan lainnya

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

Pengoptimalan biaya

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

Jenis mesin VM

Untuk membantu Anda mengoptimalkan penggunaan resource pada 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 VM Spot secara preemptive untuk mengklaim kembali kapasitas. Spot VM cocok untuk tugas batch yang dapat menoleransi preemption dan tidak memiliki persyaratan HA. Spot VM menawarkan jenis, opsi, dan performa mesin yang sama dengan VM reguler. Namun, jika kapasitas resource di zona terbatas, MIG mungkin tidak dapat menskalakan (yaitu, membuat VM) secara otomatis ke ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia lagi.

Memanfaatkan sumber daya

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, sebaiknya Anda melakukan hal berikut:

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

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 disertakan dalam tagihan untuk layanan tersebut.

Pertimbangan biaya lainnya

Saat Anda mem-build arsitektur untuk workload, pertimbangkan juga praktik terbaik dan rekomendasi umum yang diberikan dalam Framework Arsitektur Google Cloud: Pengoptimalan biaya.

Efisiensi operasional

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

Pembaruan konfigurasi VM

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

Image VM

Untuk template instance MIG, sebaiknya buat dan gunakan 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 dan skrip instance dapat menggunakan image tersebut tanpa harus memperbarui referensi ke versi image tertentu.

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.0 (paket apache2), pastikan skrip tersebut menentukan versi apache2 yang tepat yang harus diinstal, seperti versi 2.4.53. Untuk mengetahui informasi selengkapnya, lihat Template instance deterministik.

Pertimbangan operasional lainnya

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

Pengoptimalan performa

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membuat topologi zonal di Google Cloud yang memenuhi persyaratan performa beban kerja Anda.

Penempatan VM

Untuk workload yang memerlukan latensi jaringan antar-VM yang rendah, Anda dapat membuat kebijakan penempatan yang ringkas dan menerapkannya ke template MIG. Saat membuat VM, MIG menempatkan VM di server fisik yang berdekatan satu sama lain. Untuk mengetahui informasi selengkapnya, lihat Mengurangi latensi dengan menggunakan kebijakan penempatan yang ringkas.

Jenis mesin VM

Compute Engine menawarkan berbagai jenis mesin yang telah ditetapkan dan dapat disesuaikan yang dapat Anda pilih, bergantung pada persyaratan biaya dan performa Anda. Jenis mesin dikelompokkan ke dalam seri dan kelompok mesin. Tabel berikut memberikan ringkasan tentang seri dan grup mesin yang direkomendasikan untuk berbagai jenis workload:

Persyaratan Kelompok mesin yang direkomendasikan Contoh seri mesin
Rasio harga-performa terbaik untuk berbagai workload Kelompok mesin tujuan umum C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Performa tertinggi per core dan dioptimalkan untuk workload yang membutuhkan komputasi intens Kelompok mesin yang dioptimalkan untuk komputasi C2, C2D, H3
Rasio memori-ke-vCPU tinggi untuk workload dengan kerja memori intensif Kelompok mesin yang dioptimalkan untuk memori M3, M2, M1
GPU untuk workload yang diparalelkan secara masif Kelompok mesin yang dioptimalkan akselerator A2, G2

Untuk informasi selengkapnya, lihat Panduan perbandingan dan resource beberapa tipe 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 workload dengan paralel tingkat tinggi atau yang melakukan penghitungan floating point (seperti analisis urutan genetik dan pemodelan risiko keuangan), Anda dapat meningkatkan performa dengan mengurangi jumlah thread yang berjalan di setiap core 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 menggunakan backbone global Google yang sangat andal untuk membantu Anda meminimalkan kehilangan paket dan latensi. Traffic masuk dan keluar dari jaringan Google di titik kehadiran (PoP) edge global yang dekat dengan pengguna akhir Anda. Sebaiknya gunakan Paket Premium sebagai paket default untuk performa yang optimal.
  • Dengan Paket Standar, traffic memasuki dan keluar dari jaringan Google di PoP tepi yang paling dekat dengan lokasi Google Cloud tempat beban kerja Anda berjalan. Harga untuk Paket Standar lebih rendah daripada Paket Premium. Paket Standar cocok untuk traffic yang tidak sensitif terhadap kehilangan paket dan tidak memiliki persyaratan latensi rendah.

Pertimbangan performa lainnya

Saat Anda membuat arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi umum yang diberikan dalam Framework Arsitektur Google Cloud: Optimalisasi performa.

Langkah selanjutnya

Kontributor

Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk

Kontributor lainnya: