Deployment multi-regional di Compute Engine

Dokumen ini memberikan arsitektur referensi untuk aplikasi multi-lapisan yang berjalan di VM Compute Engine di beberapa region 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 membuat arsitektur multi-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 di stack terisolasi yang di-deploy di dua Google Cloud region. Di setiap region, aplikasi berjalan secara independen di tiga zona. Arsitektur ini selaras dengan Google Cloud arketipe deployment multi-regional, yang memastikan bahwa topologi Google Cloud Anda tangguh terhadap gangguan zona dan wilayah serta memberikan latensi rendah bagi pengguna aplikasi.

Arsitektur multi-region menggunakan load balancer global

Arsitektur ini didasarkan pada model cloud Infrastructure as a Service (IaaS). Anda menyediakan resource infrastruktur yang diperlukan (komputasi, jaringan, dan penyimpanan) di Google Cloud, dan Anda mempertahankan kontrol penuh atas 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 global

Load balancer eksternal global menerima dan mendistribusikan permintaan pengguna ke aplikasi. Load balancer eksternal global mengumumkan satu alamat IP anycast, tetapi diterapkan sebagai proxy dalam jumlah besar di Google Front End (GFE). Permintaan klien diarahkan ke GFE yang paling dekat dengan klien.
Grup instance terkelola (MIG) regional untuk lapisan web

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

Setiap MIG berisi VM Compute Engine di tiga zona yang berbeda. Setiap VM ini menghosting instance independen dari lapisan web aplikasi.
Load balancer internal regional

Load balancer internal di setiap region mendistribusikan traffic dari VM tingkat web ke VM tingkat aplikasi di region tersebut.
MIG regional untuk tingkat aplikasi

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

Setiap 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 di kedua region. Anda dapat menyiapkan replikasi lintas region untuk database dan mengonfigurasi database di setiap region agar beralih ke database di region lain jika terjadi kegagalan. Kemampuan replikasi dan failover bergantung pada database yang Anda gunakan.

Menginstal dan mengelola database pihak ketiga memerlukan upaya tambahan dan biaya operasional untuk replikasi, 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 database yang dikelola sepenuhnya seperti instance Spanner multi-region.
Jaringan Virtual Private Cloud dan subnet

Semua resource Google Cloud dalam arsitektur menggunakan satu jaringan VPC yang memiliki subnet di dua region yang berbeda.

Bergantung pada persyaratan Anda, Anda dapat memilih untuk membuat arsitektur yang menggunakan beberapa jaringan dan subnet VPC. Untuk informasi selengkapnya, lihat Menentukan apakah akan membuat beberapa jaringan VPC atau tidak.
Bucket dua region Cloud Storage

Pencadangan database disimpan di bucket Cloud Storage dua region. 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 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 fungsi jaringan global dan skalabel untuk Google Cloud workload Anda. VPC mencakup Peering Jaringan VPC, Private Service Connect, akses layanan pribadi, dan VPC Bersama.

Kasus penggunaan

Bagian ini menjelaskan kasus penggunaan yang memerlukan deployment multi-regional di Compute Engine.

Migrasi aplikasi lokal yang efisien

Anda dapat menggunakan arsitektur referensi ini untuk membuat 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 kesederhanaan operasional yang disediakan Google Cloud.

Ketersediaan tinggi untuk pengguna yang tersebar secara geografis

Sebaiknya lakukan deployment multi-region untuk aplikasi yang penting bagi bisnis dan jika ketersediaan tinggi serta ketahanan terhadap pemadaman layanan regional sangat diperlukan. Jika region tidak tersedia karena alasan apa pun (bahkan gangguan berskala besar yang disebabkan oleh bencana alam), pengguna aplikasi tidak akan mengalami periode nonaktif. Traffic akan dirutekan ke aplikasi di region lain yang tersedia. Jika data direplikasi secara sinkron, batas waktu pemulihan (RTO) mendekati nol.

Latensi rendah untuk pengguna aplikasi

Jika pengguna berada dalam area geografis tertentu, seperti benua, Anda dapat menggunakan deployment multi-regional untuk mencapai keseimbangan yang optimal antara ketersediaan dan performa. Jika salah satu region mengalami pemadaman layanan, load balancer global akan mengirimkan permintaan yang berasal dari region tersebut ke region lain. Pengguna tidak merasakan dampak performa yang signifikan karena wilayah tersebut berada dalam area geografis.

Alternatif desain

Arsitektur sebelumnya menggunakan load balancer global, yang mendukung fitur tertentu untuk meningkatkan keandalan deployment Anda, seperti caching edge menggunakan Cloud CDN. Bagian ini menyajikan arsitektur alternatif yang menggunakan load balancer regional dan Cloud DNS. Arsitektur alternatif ini mendukung fitur tambahan berikut:

  • Penghentian Transport Layer Security (TLS) di region tertentu.
  • Kemampuan untuk menayangkan konten dari wilayah yang Anda tentukan. Namun, region tersebut mungkin bukan region berperforma terbaik pada waktu tertentu.
  • Rentang protokol koneksi yang lebih luas jika Anda menggunakan Load Balancer Jaringan Passthrough.

Untuk mengetahui informasi selengkapnya tentang perbedaan antara load balancer regional dan global, lihat Load balancing global versus regional dan Mode operasi.

Arsitektur multi-region menggunakan load balancer dan DNS regional.

Arsitektur alternatif dalam diagram sebelumnya tangguh terhadap pemadaman layanan zona dan region. Zona publik Cloud DNS merutekan permintaan pengguna ke region yang sesuai. Load balancer eksternal regional menerima permintaan pengguna dan mendistribusikannya di seluruh instance tingkat web aplikasi dalam setiap region. Komponen lain dalam arsitektur ini identik dengan komponen dalam arsitektur berbasis load balancer global.

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, keandalan, efisiensi operasional, biaya, dan performa.

Saat Anda membuat arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi dalam Google Cloud Framework dengan Arsitektur yang Baik.

Desain sistem

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

Pilihan wilayah

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

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

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

Layanan komputasi

Arsitektur referensi dalam dokumen ini menggunakan VM Compute Engine untuk semua tingkat aplikasi. 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 memilih untuk 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 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 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 secara sinkron di antara dua zona dalam satu region.

Opsi penyimpanan lainnya untuk deployment multi-region mencakup bucket multi-region atau dual-region Cloud Storage. Objek yang disimpan di 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 objek direplikasi di seluruh pasangan region, dengan tujuan titik pemulihan (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 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 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 terkelola sepenuhnya untuk menyediakan penyimpanan SMB ketersediaan berkelanjutan (CA) untuk database.

Saat Anda mendesain penyimpanan untuk workload multi-regional, pertimbangkan karakteristik fungsional workload, 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 dikelola sepenuhnya seperti Cloud SQL, AlloyDB untuk PostgreSQL, Bigtable, Spanner, atau Firestore. Layanan database Google Cloud ini memberikan perjanjian tingkat layanan (SLA) uptime, dan menyertakan kemampuan default untuk skalabilitas dan pengamatan.

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

Saat Anda memilih dan menyiapkan database untuk deployment multi-regional, pertimbangkan persyaratan aplikasi Anda untuk konsistensi data lintas region, dan perhatikan kompromi performa dan biaya.

  • Jika aplikasi memerlukan konsistensi yang kuat (semua pengguna harus membaca data yang sama setiap saat), data harus direplikasi secara sinkron di semua region dalam arsitektur. Namun, replikasi sinkron dapat menyebabkan biaya yang lebih tinggi dan penurunan performa, karena setiap data yang ditulis harus direplikasi secara real time di seluruh region sebelum data tersedia untuk operasi baca.
  • Jika aplikasi Anda dapat menoleransi konsistensi akhir, Anda dapat mereplikasi data secara asinkron. Hal ini dapat membantu meningkatkan performa karena data tidak perlu direplikasi secara sinkron di seluruh region. Namun, pengguna di berbagai region mungkin membaca data yang berbeda karena data tersebut mungkin belum direplikasi sepenuhnya pada saat permintaan.

Keamanan, privasi, dan kepatuhan

Bagian ini menjelaskan faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membuat topologi multi-regional di Google Cloud yang memenuhi persyaratan keamanan, privasi, dan kepatuhan beban kerja Anda.

Perlindungan terhadap ancaman eksternal

Untuk melindungi aplikasi dari ancaman seperti serangan denial of service (DDoS) dan pembuatan skrip lintas situs (XSS), Anda dapat menggunakan kebijakan keamanan Google Cloud Armor. Setiap kebijakan adalah serangkaian aturan yang menentukan kondisi tertentu yang harus dievaluasi dan tindakan yang harus dilakukan 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 yang menghosting lapisan aplikasi, lapisan web, dan database tidak memerlukan akses masuk dari internet. Jangan tetapkan alamat IP eksternal ke VM tersebut. 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 Google Cloud resource yang hanya memiliki alamat IP pribadi, seperti VM Compute Engine dalam arsitektur referensi ini, Anda dapat menggunakan Secure Web Proxy atau Cloud NAT.

Keamanan image VM

Untuk membantu memastikan keamanan image VM, Anda dapat menggunakan image tepercaya. Image tepercaya adalah image dengan software yang memenuhi kebijakan atau persyaratan keamanan Anda. Untuk memastikan bahwa VM Anda hanya menggunakan image tepercaya, 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

Untuk VM Compute Engine dalam arsitektur, sebaiknya buat akun layanan khusus, bukan menggunakan akun layanan default, dan tentukan resource yang dapat diakses akun layanan tersebut. Akun layanan default mencakup berbagai izin yang tidak diperlukan dalam skenario ini. 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 ini, terapkan penerusan Identity-Aware Proxy (IAP) dengan Cloud OS Login API. Dengan IAP, Anda dapat 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 cara mengelola akses jaringan, lihat Praktik terbaik untuk mengontrol akses login SSH.

Enkripsi disk

Secara default, data yang disimpan dalam volume Persistent Disk dienkripsi menggunakan Google-owned and Google-managed encryption keys. Sebagai lapisan perlindungan tambahan, Anda dapat memilih untuk mengenkripsi Google-owned and managed key dengan menggunakan kunci yang Anda miliki dan kelola di Cloud Key Management Service (Cloud KMS). Untuk informasi selengkapnya, lihat Tentang enkripsi disk untuk volume Hyperdisk dan Mengenkripsi data dengan kunci enkripsi yang dikelola pelanggan.

Keamanan jaringan

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

Pertimbangan residensi data

Anda dapat menggunakan load balancer regional untuk membuat arsitektur multi-region yang membantu Anda memenuhi persyaratan retensi data. Misalnya, negara di Eropa mungkin mewajibkan agar semua data pengguna disimpan dan diakses di pusat data yang berlokasi secara fisik di Eropa. Untuk memenuhi persyaratan ini, Anda dapat menggunakan arsitektur berbasis load balancer regional. Dalam arsitektur tersebut, aplikasi berjalan di regionGoogle Cloud di Eropa dan Anda menggunakan Cloud DNS dengan kebijakan perutean dengan pembatasan wilayah geografis untuk merutekan traffic melalui load balancer regional. Untuk memenuhi persyaratan retensi data untuk tingkat database, gunakan arsitektur ter-shard, bukan replikasi di seluruh region. Dengan pendekatan ini, data di setiap region akan terisolasi, tetapi Anda tidak dapat menerapkan ketersediaan tinggi dan failover lintas region untuk database.

Pertimbangan keamanan lainnya

Saat Anda mem-build arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi keamanan tingkat platform yang diberikan dalam Blueprint fondasi Enterprise Keamanan dan Google Cloud Framework dengan Arsitektur yang Baik: Keamanan, privasi, dan kepatuhan.

Keandalan

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

Ketahanan terhadap pemadaman infrastruktur

Dalam arsitektur deployment multi-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 mengalami error, MIG akan membuat ulang VM secara otomatis.

Jika pemadaman layanan zona terjadi, load balancer tidak akan terpengaruh, karena merupakan resource regional. Pemadaman layanan 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 menyelesaikan pemadaman layanan zona, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di semua zona tempat aplikasi di-deploy.

Jika semua zona di salah satu region mengalami pemadaman layanan atau jika terjadi pemadaman layanan di seluruh region, aplikasi di region lain akan tetap tersedia dan responsif. Load balancer eksternal global mengarahkan traffic ke region yang tidak terpengaruh oleh pemadaman layanan. Setelah Google menyelesaikan pemadaman layanan region, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di region yang mengalami pemadaman layanan.

Jika kedua region dalam arsitektur ini mengalami pemadaman layanan, aplikasi tidak akan tersedia. Anda harus menunggu Google menyelesaikan pemadaman layanan, lalu memastikan bahwa aplikasi berfungsi seperti yang diharapkan.

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi di beberapa MIG regional, aplikasi tersebut akan tetap tersedia selama pemadaman layanan zona terisolasi atau pemadaman layanan region. Kemampuan penskalaan otomatis MIG stateless memungkinkan Anda mempertahankan ketersediaan dan performa aplikasi pada tingkat yang dapat diprediksi. Untuk mengontrol perilaku penskalaan otomatis MIG stateless, Anda dapat menentukan metrik penggunaan target, seperti penggunaan CPU rata-rata. Anda juga dapat mengonfigurasi penskalaan otomatis berbasis jadwal untuk MIG stateless. MIG stateful tidak dapat diskalakan secara otomatis. Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis grup instance.

Batas ukuran MIG

Saat 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 tingkat web dan tingkat 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. Dalam skenario ini, VM tidak akan merespons health check load balancer dan load balancer tidak akan merutekan traffic ke VM yang tidak responsif. Untuk membantu memastikan 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 informasi selengkapnya tentang cara mengonfigurasi perbaikan otomatis, 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 bahwa aplikasi Anda tahan terhadap pemadaman layanan zona. Untuk meningkatkan keandalan ini lebih lanjut, Anda dapat membuat kebijakan penempatan spread 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 Menerapkan kebijakan penempatan spread ke VM.

Perencanaan kapasitas VM

Untuk memastikan kapasitas VM Compute Engine tersedia saat diperlukan, 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. Untuk mengetahui informasi selengkapnya tentang reservasi, termasuk pertimbangan penagihan, lihat Reservasi resource zona Compute Engine.

Penyimpanan stateful

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 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 pencadangan VM Compute Engine. Backup and DR menyimpan data cadangan dalam format asli 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 dalam 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 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 akan tetap tersedia.

Ketersediaan database

Untuk menerapkan failover lintas zona untuk database di setiap region, 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 mengatur failover. Anda harus mengonfigurasi aturan failover dengan tepat untuk menghindari situasi split-brain dan mencegah failover yang tidak perlu. Misalnya, 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 multi-regional 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 ketersediaan tinggi. Spot VM menawarkan jenis, opsi, dan performa mesin yang sama dengan VM reguler. Namun, jika kapasitas resource di zona terbatas, MIG mungkin tidak dapat diskalakan (yaitu, membuat VM) secara otomatis ke ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia lagi.

Penggunaan 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, sebaiknya lakukan 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%.

Pertimbangan biaya lainnya

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

Efisiensi operasional

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membuat topologi Google Cloud multi-regional 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 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 OS 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. 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.0 (paket apache2), pastikan skrip 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 umum dan rekomendasi untuk efisiensi operasional yang dijelaskan dalam Google Cloud Framework dengan Arsitektur yang Baik: Keunggulan operasional.

Pengoptimalan performa

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

Penempatan VM

Untuk beban kerja 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. Untuk mengetahui informasi selengkapnya, lihat Mengurangi latensi dengan menggunakan kebijakan penempatan yang ringkas.

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

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 meminimalkan kehilangan paket dan latensi rendah. Tingkat Standar mengirimkan traffic menggunakan peering, internet service provider (ISP), atau jaringan transit di titik kehadiran (PoP) edge yang terdekat dengan region tempat Google Cloud beban kerja Anda berjalan. Untuk mengoptimalkan performa, sebaiknya gunakan Paket Premium. Untuk mengoptimalkan biaya, sebaiknya gunakan Paket Standar.

Performa jaringan

Untuk beban kerja yang memerlukan latensi jaringan antar-VM yang rendah dalam tingkat aplikasi dan web, Anda dapat membuat kebijakan penempatan yang ringkas dan menerapkannya ke template MIG yang digunakan untuk tingkat tersebut. Saat membuat VM, MIG akan menempatkan VM di server fisik yang berdekatan. Meskipun kebijakan penempatan rapat membantu meningkatkan performa jaringan antar-VM, kebijakan penempatan spread 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 jarak VM yang harus ditempatkan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan penempatan.

Compute Engine memiliki batas per VM untuk bandwidth jaringan traffic keluar. 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 keluar maksimum yang lebih tinggi dengan mengaktifkan jaringan Tingkat_1.

Caching

Jika aplikasi Anda menayangkan aset situs statis dan jika arsitektur Anda menyertakan Load Balancer Aplikasi eksternal global, Anda dapat menggunakan Cloud CDN untuk menyimpan konten statis yang diakses secara rutin ke dalam cache yang lebih dekat dengan pengguna. Cloud CDN dapat membantu meningkatkan performa untuk pengguna, mengurangi penggunaan resource infrastruktur di backend, dan mengurangi biaya penayangan jaringan. Untuk mengetahui informasi selengkapnya, lihat Performa web yang lebih cepat dan perlindungan web yang lebih baik untuk load balancing.

Pertimbangan performa lainnya

Saat Anda mem-build arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi umum yang diberikan di Google Cloud Framework dengan Arsitektur yang Baik: Pengoptimalan performa.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: