Deployment multi-regional di Compute Engine

Last reviewed 2024-02-20 UTC

Dokumen ini memberikan arsitektur referensi untuk aplikasi multi-tingkat yang berjalan di VM Compute Engine di beberapa region di Google Cloud. Dokumen ini juga memberikan panduan untuk membantu Anda membangun arsitektur yang menggunakan layanan infrastruktur Google Cloud lainnya. Panduan ini menjelaskan faktor-faktor desain yang harus Anda pertimbangkan saat membangun arsitektur multi-regional untuk aplikasi cloud. Audiens yang dituju untuk dokumen ini adalah arsitek cloud.

Arsitektur

Gambar 1 menunjukkan arsitektur untuk aplikasi yang berjalan dalam mode aktif-aktif di stack terisolasi yang di-deploy di dua region Google Cloud. Di setiap region, aplikasi berjalan secara independen di tiga zona. Arsitektur ini selaras dengan arketipe deployment multi-regional, yang memastikan topologi Google Cloud Anda kuat terhadap gangguan zona dan region, serta memberikan latensi rendah bagi pengguna aplikasi.

Arsitektur multi-regional menggunakan load balancer global

Gambar 1. Load balancer global merutekan permintaan pengguna ke stack aplikasi yang terisolasi secara regional.

Arsitekturnya didasarkan pada model cloud Infrastructure as a Service (IaaS). Anda menyediakan resource infrastruktur yang diperlukan (komputasi, jaringan, dan penyimpanan) di Google Cloud, dan Anda juga mempertahankan kontrol dan tanggung jawab penuh atas sistem operasi, middleware, dan lapisan stack aplikasi yang lebih tinggi. Untuk mempelajari IaaS dan model cloud lainnya lebih lanjut, lihat PaaS vs. IaaS vs. SaaS vs. CaaS: Apa 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 mencantumkan satu alamat IP anycast, tetapi diterapkan sebagai sejumlah besar proxy di Google Front Ends (GFE). Permintaan klien diarahkan ke GFE yang terdekat dengan klien.

Bergantung pada persyaratan Anda, Anda dapat menggunakan Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal global. 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 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 tingkat 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.

Bergantung pada persyaratan, 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. 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

Database pihak ketiga (seperti PostgreSQL) di-deploy pada VM Compute Engine di dua region. Anda dapat menyiapkan replikasi lintas region untuk database dan mengonfigurasi database di setiap region agar beralih ke database di region lain. 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 menginstal dan mengelola database pihak ketiga serta memanfaatkan fitur ketersediaan tinggi (HA) bawaan dengan menggunakan database yang terkelola 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 berbeda.
Bucket dual-region Cloud Storage Cadangan data aplikasi disimpan di bucket Cloud Storage dengan region ganda. Atau, Anda dapat menggunakan Layanan Pencadangan dan DR untuk membuat, menyimpan, dan mengelola cadangan database.

Kasus penggunaan

Bagian ini menjelaskan kasus penggunaan yang menjadikan deployment multi-regional di Compute Engine adalah 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.

Ketersediaan tinggi untuk pengguna yang tersebar di wilayah geografis

Kami merekomendasikan deployment multi-regional untuk aplikasi yang sangat penting bagi bisnis dan jika ketersediaan tinggi dan keandalan terhadap gangguan region sangatlah penting. Jika suatu region menjadi tidak tersedia karena alasan apa pun (bahkan gangguan berskala besar yang disebabkan oleh bencana alam), pengguna aplikasi tidak akan mengalami periode nonaktif. Traffic dirutekan ke aplikasi di region lain yang tersedia. Jika data direplikasi secara sinkron, target waktu pemulihan (RTO) akan 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 optimal antara ketersediaan dan performa. Saat salah satu region mengalami pemadaman, load balancer global akan mengirimkan permintaan yang berasal dari region tersebut ke region lain. Pengguna tidak akan merasakan dampak performa yang signifikan karena region berada dalam area geografis.

Alternatif desain

Arsitektur yang menggunakan load balancer global (gambar 1) mendukung fitur tertentu yang membantu Anda meningkatkan keandalan deployment Anda, seperti edge caching menggunakan Cloud CDN. Bagian ini menampilkan arsitektur alternatif yang menggunakan load balancer regional dan Cloud DNS, seperti yang ditunjukkan pada gambar 2. 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 dengan performa terbaik pada waktu tertentu.
  • 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 dokumentasi berikut:

Arsitektur multi-regional menggunakan load balancer regional dan DNS.

Gambar 2. Cloud DNS merutekan permintaan pengguna ke load balancer regional.

Seperti arsitektur pada gambar 1, arsitektur di gambar 2 mampu mengatasi gangguan zona dan region. Zona publik Cloud DNS mengarahkan permintaan pengguna ke region yang sesuai. Load balancer eksternal regional menerima permintaan pengguna dan mendistribusikannya ke seluruh instance tingkat web aplikasi di setiap region. Komponen lain dalam arsitektur ini identik dengan komponen dalam arsitektur berbasis load balancer global.

Untuk mengetahui informasi selengkapnya tentang cara membangun arsitektur multi-regional yang menggunakan beberapa load balancer regional dan Cloud DNS, lihat Arsitektur load balancing global menggunakan kebijakan perutean DNS.

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 bagi deployment multi-regional dan memilih layanan Google Cloud yang sesuai.

Pilihan wilayah

Saat memilih region Google Cloud tempat aplikasi Anda 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 resource Google Cloud
  • Biaya transfer data lintas regional
  • 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. Bergantung pada persyaratan aplikasi, Anda dapat memilih dari layanan komputasi Google Cloud lainnya:

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

Opsi penyimpanan lainnya untuk deployment multi-regional mencakup bucket dual-region atau multi-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 bahwa objek direplikasi di seluruh pasangan region, dengan toleransi titik pemulihan (RPO) selama 15 menit. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan dan ketahanan data.

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 ketersediaan tinggi 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, Anda dapat men-deploy instance cluster failover (FCI) dan menggunakan Google Cloud NetApp Volumes yang terkelola sepenuhnya untuk menyediakan penyimpanan SMB ketersediaan berkelanjutan (CA) untuk database.

Saat Anda mendesain penyimpanan untuk workload multi-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.

Saat 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 membutuhkan konsistensi yang kuat (semua pengguna harus membaca data yang sama setiap saat), data tersebut harus direplikasi secara sinkron di semua region dalam arsitektur. Namun, replikasi sinkron dapat menyebabkan biaya yang lebih tinggi dan penurunan performa karena data apa pun yang ditulis harus direplikasi secara real time di seluruh region sebelum data tersebut tersedia untuk operasi baca.
  • Jika aplikasi Anda dapat menoleransi konsistensi tertunda, 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 region yang berbeda mungkin membaca data yang berbeda karena data mungkin belum direplikasi sepenuhnya pada saat permintaan.

Keamanan dan kepatuhan

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

Perlindungan terhadap ancaman

Untuk melindungi aplikasi Anda dari ancaman, seperti serangan distributed denial of service (DDoS) dan pembuatan skrip lintas situs (XSS), Anda dapat menggunakan kebijakan keamanan Google Cloud Armor. Setiap kebijakan adalah kumpulan aturan yang menentukan 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 pribadi, 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".

Pertimbangan residensi data

Anda dapat menggunakan load balancer regional untuk membangun arsitektur multi-regional yang membantu Anda memenuhi persyaratan residensi data. Misalnya, negara di Eropa mungkin mengharuskan semua data pengguna disimpan dan diakses di pusat data yang secara fisik berlokasi di Eropa. Untuk memenuhi persyaratan ini, Anda dapat menggunakan arsitektur berbasis load balancer regional pada gambar 2. Dalam arsitektur tersebut, aplikasi berjalan di region Google Cloud di Eropa dan Anda menggunakan Cloud DNS dengan kebijakan pemilihan rute yang dibatasi wilayah untuk mengarahkan traffic melalui load balancer regional. Guna memenuhi persyaratan residensi data untuk tingkat database, gunakan arsitektur shard, bukan replikasi lintas region. Dengan pendekatan ini, data di setiap region diisolasi, tetapi Anda tidak dapat menerapkan ketersediaan tinggi dan failover lintas region untuk database.

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 multi-regional Anda di Google Cloud.

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi di beberapa MIG regional, aplikasi akan tetap tersedia selama pemadaman zona terisolasi atau pemadaman region. Kemampuan penskalaan otomatis pada MIG stateless memungkinkan Anda mempertahankan ketersediaan dan performa aplikasi pada tingkat yang dapat diprediksi. Untuk mengontrol perilaku penskalaan otomatis pada MIG stateless, Anda dapat menentukan metrik pemanfaatan target, seperti pemakaian CPU rata-rata. Anda juga dapat mengonfigurasi penskalaan otomatis berbasis jadwal untuk MIG stateless. MIG stateful tidak dapat diskalakan otomatis. Untuk 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 bahwa kapasitas untuk VM Compute Engine tersedia saat diperlukan, Anda dapat membuat reservasi. Reservasi memberikan kapasitas pasti di zona tertentu untuk sejumlah VM tertentu dari jenis mesin yang Anda pilih. Reservasi dapat bersifat spesifik untuk sebuah project, atau dibagikan di beberapa project. 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 pencadangan 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 menghabiskan waktu pemindahan data atau aktivitas persiapan.

Untuk menyimpan cadangan database dan log transaksi, Anda dapat menggunakan bucket Cloud Storage regional, yang menyediakan penyimpanan cadangan dengan biaya terendah yang redundan di berbagai zona.

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

  • Anda dapat menggunakan snapshot standar untuk merekam status titik waktu volume Persistent Disk. Snapshot 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 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. 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 memberikan panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian topologi Google Cloud multi-regional yang Anda build 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 jenis mesin kustom.

Model penyediaan VM

Jika aplikasi Anda fault-tolerant, Spot VM dapat membantu mengurangi biaya Compute Engine untuk VM dalam tingkat aplikasi dan web. Biaya Spot VM jauh lebih rendah dibandingkan VM biasa. 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 suatu zona terbatas, MIG mungkin tidak dapat melakukan penyebaran skala (yaitu, membuat VM) secara otomatis ke ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia lagi.

Memanfaatkan sumber daya

Kemampuan penskalaan otomatis pada MIG stateless memungkinkan aplikasi Anda menangani peningkatan traffic dengan lancar, dan membantu Anda mengurangi biaya saat kebutuhan resource rendah. MIG stateful tidak dapat diskalakan 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 menggunakan jenis mesin kustom. Dengan begitu, Anda membatasi biaya lisensi pihak ketiga untuk jumlah inti CPU yang Anda butuhkan.
  • Kurangi jumlah vCPU per inti dari 2 menjadi 1 dengan menonaktifkan simultaneous multithreading (SMT), dan mengurangi biaya lisensi Anda sebesar 50%.

Pertimbangan biaya lainnya

Saat Anda membangun arsitektur untuk beban kerja Anda, pertimbangkan juga praktik terbaik dan rekomendasi umum yang disediakan dalam Framework Arsitektur Google Cloud: Pengoptimalan biaya.

Efisiensi operasional

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

Update konfigurasi VM

Untuk memperbarui konfigurasi VM di MIG (seperti jenis mesin atau image boot-disk), buat template instance baru dengan konfigurasi yang diperlukan, lalu terapkan template baru ke MIG. MIG mengupdate VM dengan menggunakan metode update yang Anda pilih: otomatis atau selektif. Pilih metode yang tepat berdasarkan kebutuhan Anda untuk 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 Anda, daripada menggunakan image publik yang disediakan Google, sebaiknya buat dan gunakan image kustom yang berisi konfigurasi dan software yang diperlukan aplikasi Anda. Anda dapat mengelompokkan gambar kustom ke dalam kelompok gambar kustom. Kelompok gambar selalu mengarah ke gambar terbaru dalam kelompok tersebut, sehingga template dan skrip instance dapat menggunakan gambar tersebut tanpa harus memperbarui referensi ke versi gambar 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 pada 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 membangun arsitektur untuk beban kerja Anda, pertimbangkan rekomendasi dan praktik terbaik umum untuk efisiensi operasional yang dijelaskan dalam Framework Arsitektur Google Cloud: Keunggulan operasional.

Pengoptimalan performa

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

Penempatan VM

Untuk workload yang memerlukan latensi jaringan antar-VM rendah, Anda dapat membuat kebijakan penempatan ringkas dan menerapkannya ke template MIG. Ketika MIG 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 biaya dan persyaratan performa Anda. Jenis mesin dikelompokkan ke dalam seri dan kelompok mesin. Tabel berikut memberikan ringkasan rangkaian dan kelompok 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 inti dan dioptimalkan untuk beban kerja yang sarat komputasi Kelompok mesin yang dioptimalkan untuk komputasi C2, C2D, H3
Rasio memori-ke-vCPU yang tinggi untuk workload yang sarat memori Kelompok mesin yang dioptimalkan untuk memori M3, M2, M1
GPU untuk workload yang diparalelkan secara massal Kelompok mesin yang dioptimalkan akselerator A2, G2

Untuk informasi selengkapnya, lihat Panduan perbandingan dan resource kelompok mesin.

Multithreading VM

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

Network Service Tiers

Dengan Network Service Tiers, Anda dapat mengoptimalkan biaya dan performa jaringan untuk workload Anda. Anda dapat memilih dari tingkat berikut:

  • Paket Premium menggunakan backbone global Google yang sangat andal untuk membantu Anda mencapai latensi dan kehilangan paket yang minimal. Traffic masuk dan keluar dari jaringan Google di titik kehadiran edge global (PoP) yang terdekat dengan ISP pengguna akhir Anda. Sebaiknya gunakan Paket Premium sebagai paket default untuk performa yang optimal. Paket Premium mendukung alamat IP eksternal regional dan alamat IP eksternal global untuk VM dan load balancer.
  • Tingkat Standar hanya tersedia untuk resource yang menggunakan alamat IP eksternal regional. Traffic masuk dan keluar dari jaringan Google di PoP edge yang terdekat dengan region tempat workload Google Cloud Anda dijalankan. Harga untuk Paket Standar lebih rendah daripada Paket Premium. Paket Standar cocok untuk traffic yang tidak sensitif terhadap paket yang hilang dan yang tidak memiliki persyaratan latensi rendah.

Menyimpan data ke dalam cache

Jika aplikasi Anda menyalurkan aset situs statis dan jika arsitektur Anda menyertakan Load Balancer Aplikasi eksternal global (seperti yang ditunjukkan pada gambar 1), Anda dapat menggunakan Cloud CDN untuk menyimpan konten statis yang diakses secara rutin ke dalam cache, agar lebih dekat kepada pengguna. Cloud CDN dapat membantu meningkatkan performa bagi pengguna Anda, mengurangi penggunaan resource infrastruktur di backend, dan mengurangi biaya pengiriman jaringan Anda. Untuk mengetahui informasi selengkapnya, lihat Performa web yang lebih cepat dan perlindungan web yang lebih baik untuk load balancing.

Pertimbangan performa lainnya

Saat Anda membangun arsitektur untuk beban kerja Anda, pertimbangkan praktik terbaik dan rekomendasi umum yang disediakan dalam Framework Arsitektur Google Cloud: Pengoptimalan performa.

Langkah selanjutnya

Kontributor

Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk

Kontributor lainnya: