Deployment global dengan Compute Engine dan Spanner

Last reviewed 2025-05-27 UTC

Dokumen ini memberikan arsitektur referensi untuk aplikasi multi-tingkatan yang berjalan di VM Compute Engine dan Spanner dalam topologi global di Google Cloud. Dokumen ini juga memberikan panduan untuk membantu Anda membangun arsitektur yang menggunakan layanan infrastruktur Google Cloud lainnya. Dokumen ini menjelaskan faktor desain yang harus Anda pertimbangkan saat membangun arsitektur global untuk aplikasi cloud Anda. Audiens yang dituju untuk dokumen ini adalah arsitek cloud.

Arsitektur ini selaras dengan arketipe deployment global. Kami merekomendasikan arketipe ini untuk aplikasi yang melayani pengguna di seluruh dunia dan memerlukan ketersediaan tinggi serta ketahanan terhadap pemadaman layanan di beberapa region. Arsitektur ini mendukung penskalaan elastis di tingkat jaringan, aplikasi, dan database. Dengan begitu, Anda dapat menyelaraskan biaya dengan penggunaan tanpa harus mengorbankan performa, ketersediaan, atau skalabilitas.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk aplikasi yang berjalan di infrastruktur yang didistribusikan secara global di beberapa Google Cloud region.

Arsitektur deployment global menggunakan Compute Engine dan Spanner.

Dalam arsitektur ini, load balancer global mendistribusikan permintaan masuk ke server web di region yang sesuai berdasarkan ketersediaan, kapasitas, dan kedekatannya dengan sumber traffic. Lapisan load balancing internal lintas regional menangani distribusi traffic dari server web ke server aplikasi yang sesuai berdasarkan ketersediaan dan kapasitasnya. Server aplikasi menulis data ke, dan membaca dari, database yang direplikasi secara sinkron yang tersedia di semua region.

Arsitektur ini mencakup resource Google Cloud berikut:

Komponen Tujuan
Load balancer eksternal global

Load balancer eksternal global menerima dan mendistribusikan permintaan pengguna ke aplikasi. Load balancer eksternal global mengiklankan satu alamat IP anycast, tetapi load balancer diterapkan sebagai sejumlah besar proxy di Google Front End (GFE). Permintaan klien diarahkan ke GFE yang paling dekat 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.

Untuk melindungi aplikasi Anda dari ancaman seperti serangan distributed denial-of-service (DDoS) dan cross-site scripting (XSS), Anda dapat menggunakan kebijakan keamanan Google Cloud Armor.

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.

Lapisan load balancing internal lintas region

Load balancer internal dengan backend lintas region menangani distribusi traffic dari VM tingkat web di region mana pun ke VM tingkat aplikasi di semua region.

Bergantung pada persyaratan Anda, Anda dapat menggunakan Load Balancer Aplikasi internal lintas region atau Load Balancer Jaringan proxy internal lintas region. 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 ini adalah backend untuk lapisan load balancing internal.

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

Instance multi-region Spanner

Aplikasi menulis data ke dan membaca dari instance Spanner multi-region. Konfigurasi multi-region dalam arsitektur ini mencakup replika berikut:

  • Empat replika baca-tulis di zona terpisah di dua region.
  • Replika saksi di region ketiga.
Jaringan Virtual Private Cloud (VPC) dan subnet

Semua resource dalam arsitektur menggunakan satu jaringan VPC. Jaringan VPC memiliki subnet berikut:

  • Subnet di setiap region untuk VM server web.
  • Subnet di setiap region untuk VM server aplikasi.
  • (Tidak ditampilkan dalam diagram arsitektur) Subnet khusus proxy di setiap region untuk load balancer internal lintas-region.

Daripada menggunakan satu jaringan VPC, Anda dapat membuat jaringan VPC terpisah di setiap region dan menghubungkan jaringan menggunakan Network Connectivity Center.

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 berperforma tinggi dan skalabel.
  • Spanner: Layanan database relasional yang sangat skalabel dan konsisten secara global.

Pertimbangan desain

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

Desain sistem

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

Pemilihan wilayah

Saat Anda memilih Google Cloud region 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 Google Cloud sumber daya.
  • Biaya transfer data lintas region.
  • Persyaratan peraturan.

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

Infrastruktur komputasi

Arsitektur referensi dalam dokumen ini menggunakan VM Compute Engine untuk tingkat tertentu dari 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 suka memfokuskan upaya IT pada data dan aplikasi, bukan menyiapkan dan mengoperasikan resource infrastruktur, Anda dapat menggunakan layanan serverless seperti Cloud Run.

Keputusan apakah akan 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 dan hanya memerlukan sedikit upaya pengelolaan. Untuk mengetahui informasi selengkapnya tentang memilih layanan komputasi yang sesuai untuk workload Anda diGoogle Cloud, lihat Menghosting Aplikasi di Google Cloud.

Layanan penyimpanan

Arsitektur yang ditunjukkan dalam dokumen ini menggunakan volume Persistent Disk regional untuk VM. Volume Persistent Disk Regional menyediakan replikasi data secara sinkron di dua zona dalam satu region. Data dalam volume Persistent Disk tidak direplikasi di seluruh region.

Opsi penyimpanan lain untuk deployment multi-regional mencakup bucket Cloud Storage dual-region atau multi-region. 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 replikasi lebih cepat di seluruh region. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan dan ketahanan data.

Untuk menyimpan file yang dibagikan di beberapa VM dalam satu region, seperti di semua VM di tingkat web atau tingkat aplikasi, Anda dapat menggunakan instance Filestore Enterprise. File 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 tersebut di beberapa VM.

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

Layanan database

Arsitektur referensi dalam dokumen ini menggunakan Spanner, yaitu database yang terkelola sepenuhnya, dapat diskalakan secara horizontal, didistribusikan secara global, dan direplikasi secara sinkron. Sebaiknya gunakan konfigurasi Spanner multi-region untuk deployment penting yang memerlukan konsistensi lintas region yang kuat. Spanner mendukung replikasi lintas region sinkron tanpa periode istirahat untuk failover, pemeliharaan, atau pengubahan ukuran.

Untuk mengetahui informasi tentang layanan database terkelola lainnya yang dapat Anda pilih berdasarkan kebutuhan Anda, lihat Google Cloud database. Saat Anda memilih dan mengonfigurasi database untuk deployment multiregional, pertimbangkan persyaratan aplikasi Anda untuk konsistensi data lintas region, dan pahami kompromi performa dan biaya.

Opsi load balancing eksternal

Arsitektur yang menggunakan load balancer eksternal global, seperti arsitektur dalam dokumen ini, mendukung fitur tertentu yang membantu Anda meningkatkan keandalan deployment Anda. Misalnya, jika Anda menggunakan Load Balancer Aplikasi eksternal global, Anda dapat menerapkan caching edge menggunakan Cloud CDN.

Jika aplikasi Anda memerlukan Transport Layer Security (TLS) untuk dihentikan di region tertentu, atau jika Anda memerlukan kemampuan untuk menyajikan konten dari region tertentu, Anda dapat menggunakan load balancer regional dengan Cloud DNS untuk merutekan traffic ke region yang berbeda. Untuk mengetahui informasi tentang perbedaan antara load balancer regional dan global, lihat dokumentasi berikut:

Keamanan, privasi, dan kepatuhan

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

Perlindungan terhadap ancaman eksternal

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

Akses eksternal untuk VM

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

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

Hak istimewa akun layanan

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

Keamanan SSH

Untuk meningkatkan keamanan koneksi SSH ke VM Compute Engine dalam arsitektur Anda, terapkan Identity-Aware Proxy (IAP) dan Cloud OS Login API. 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 pengelolaan akses jaringan, lihat Praktik terbaik untuk mengontrol akses login SSH.

Pertimbangan keamanan lainnya

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

Keandalan

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

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi di beberapa MIG regional, aplikasi akan tetap tersedia selama pemadaman layanan zona yang 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 pemakaian 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.

Batas ukuran MIG

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

Autohealing VM

Terkadang VM yang menghosting aplikasi Anda mungkin berjalan dan tersedia, tetapi mungkin ada masalah dengan aplikasi itu sendiri. Aplikasi mungkin berhenti merespons, error, atau tidak memiliki memori yang cukup. Untuk memverifikasi apakah aplikasi merespons seperti yang diharapkan, Anda dapat mengonfigurasi health check berbasis aplikasi sebagai bagian dari kebijakan autohealing MIG. Jika aplikasi pada VM tertentu tidak merespons, MIG akan melakukan pemulihan otomatis (perbaikan) pada VM tersebut. Untuk mengetahui informasi selengkapnya tentang mengonfigurasi penyembuhan 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 aplikasi Anda andal saat terjadi gangguan zona.

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

Perencanaan kapasitas VM

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

Penyimpanan berstatus

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

Ketahanan data

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

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

  • Anda dapat menggunakan snapshot untuk merekam status volume Persistent Disk pada waktu tertentu. 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 dapat 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.
  • Untuk memastikan data di Persistent Disk tetap tersedia jika terjadi pemadaman zona, Anda dapat menggunakan Regional Persistent Disk atau Hyperdisk Balanced High Availability. Data dalam jenis disk ini direplikasi secara sinkron antara dua zona di region yang sama. Untuk mengetahui informasi selengkapnya, lihat Tentang replikasi disk sinkron.

Keandalan database

Data yang disimpan di instance Spanner multi-region direplikasi secara sinkron di beberapa region. Konfigurasi Spanner yang ditampilkan dalam diagram arsitektur sebelumnya mencakup replika berikut:

  • Empat replika baca-tulis di zona terpisah di dua region.
  • Replika saksi di region ketiga.

Operasi tulis ke instance Spanner multi-region dikonfirmasi setelah setidaknya tiga replika—di zona terpisah di dua region—telah meng-commit operasi. Jika terjadi kegagalan zona atau region, Spanner memiliki akses ke semua data, termasuk data dari operasi tulis terbaru, dan terus melayani permintaan baca dan tulis.

Spanner menggunakan penyimpanan yang tidak digabungkan dengan resource komputasi dan penyimpanan yang tidak digabungkan. Anda tidak perlu memindahkan data saat menambahkan kapasitas komputasi untuk HA atau penskalaan. Resource komputasi baru mendapatkan data saat dibutuhkan dari node Colossus terdekat. Hal ini membuat failover dan penskalaan lebih cepat dan tidak terlalu berisiko.

Spanner menyediakan konsistensi eksternal, yang merupakan properti yang lebih ketat daripada serialisabilitas untuk sistem pemrosesan transaksi. Untuk informasi selengkapnya, lihat referensi berikut:

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 global yang Anda bangun menggunakan arsitektur referensi ini.

Jenis mesin VM

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

Model penyediaan VM

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

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

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

Biaya database

Spanner membantu memastikan biaya database Anda dapat diprediksi. Kapasitas komputasi yang Anda tentukan (jumlah node atau unit pemrosesan) menentukan kapasitas penyimpanan. Throughput baca dan tulis diskalakan secara linier dengan kapasitas komputasi. Anda hanya membayar sesuai penggunaan. Saat Anda perlu menyelaraskan biaya dengan kebutuhan workload, Anda dapat menyesuaikan ukuran instance Spanner.

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 Microsoft Windows Server, daripada menggunakan image premium yang menimbulkan biaya tambahan untuk lisensi pihak ketiga, Anda dapat membuat dan menggunakan image BYOL Windows kustom. Kemudian, Anda hanya membayar infrastruktur VM yang digunakan di Google Cloud. Strategi ini membantu Anda terus merealisasikan nilai dari investasi yang ada dalam lisensi pihak ketiga. Jika Anda memutuskan untuk menggunakan pendekatan BYOL, rekomendasi berikut dapat membantu mengurangi biaya:

  • Sediakan jumlah core CPU komputasi yang diperlukan secara terpisah dari memori dengan menggunakan jenis mesin kustom. Dengan melakukannya, Anda membatasi biaya lisensi pihak ketiga untuk jumlah core CPU yang Anda butuhkan.
  • Kurangi jumlah vCPU per inti dari 2 menjadi 1 dengan menonaktifkan multithreading simultan (SMT).

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

Pertimbangan biaya lainnya

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

Efisiensi operasional

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

Pembaruan konfigurasi VM

Untuk memperbarui konfigurasi VM di MIG (seperti jenis mesin atau image boot disk), 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 VM Anda, daripada menggunakan image publik yang disediakan Google, sebaiknya buat dan gunakan image OS kustom yang berisi konfigurasi dan software yang diperlukan aplikasi Anda. 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 Anda harus memperbarui referensi ke versi image tertentu. Anda harus mengupdate image kustom secara rutin untuk menyertakan update dan patch keamanan yang disediakan oleh vendor OS.

Template instance deterministik

Jika template instance yang Anda gunakan untuk MIG menyertakan skrip startup untuk menginstal software pihak ketiga, pastikan skrip tersebut secara eksplisit menentukan parameter penginstalan software seperti versi software. Jika tidak, saat MIG membuat VM, software yang diinstal di VM mungkin tidak konsisten. Misalnya, jika template instance Anda menyertakan skrip startup untuk menginstal Apache HTTP Server 2.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.

Migrasi ke Spanner

Anda dapat memigrasikan data ke Spanner dari database lain seperti MySQL, SQL Server, dan Oracle Database. Proses migrasi bergantung pada faktor-faktor seperti database sumber, ukuran data, batasan periode nonaktif, dan kompleksitas kode aplikasi. Untuk membantu Anda merencanakan dan menerapkan migrasi ke Spanner secara efisien, kami menyediakan berbagai alat pihak pertama dan pihak ketiga. Google CloudUntuk mengetahui informasi selengkapnya, lihat Ringkasan migrasi.

Administrasi database

Dengan Spanner, Anda tidak perlu mengonfigurasi atau memantau replikasi atau failover. Replikasi sinkron dan failover otomatis sudah terintegrasi. Aplikasi Anda tidak mengalami periode nonaktif untuk pemeliharaan dan failover database. Untuk lebih mengurangi kerumitan operasional, Anda dapat mengonfigurasi penskalaan otomatis. Dengan penskalaan otomatis yang diaktifkan, Anda tidak perlu memantau dan menskalakan ukuran instance secara manual.

Pertimbangan operasional lainnya

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

Pengoptimalan performa

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

Performa jaringan

Untuk workload 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 satu sama lain. 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 seberapa jauh VM 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 Tier_1.

Performa compute

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

Multithreading VM

Setiap CPU virtual (vCPU) yang Anda alokasikan ke VM Compute Engine diimplementasikan sebagai hardware multithread tunggal. Secara default, dua vCPU berbagi core CPU fisik. Untuk aplikasi yang melibatkan operasi 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 pada setiap inti CPU fisik. Untuk informasi selengkapnya, lihat Menetapkan jumlah thread per core.

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

Network Service Tiers

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

Arsitektur dalam dokumen ini menggunakan load balancer eksternal global dengan alamat IP eksternal dan backend di beberapa region. Arsitektur ini mengharuskan Anda menggunakan Paket Premium, yang menggunakan backbone global Google yang sangat andal untuk membantu Anda meminimalkan kehilangan paket dan latensi.

Jika Anda menggunakan load balancer eksternal regional dan merutekan traffic ke region menggunakan Cloud DNS, Anda dapat memilih Paket Premium atau Paket Standar, bergantung pada persyaratan Anda. Harga Paket Standar lebih rendah daripada Paket Premium. Paket Standar cocok untuk traffic yang tidak sensitif terhadap kehilangan paket dan tidak memiliki persyaratan latensi rendah.

Performa Spanner

Saat menyediakan instance Spanner, Anda menentukan kapasitas komputasi instance dalam hal jumlah node atau unit pemrosesan. Pantau pemakaian resource instance Spanner Anda, dan menskalakan kapasitas berdasarkan beban yang diharapkan dan persyaratan performa aplikasi Anda. Anda dapat menskalakan kapasitas instance Spanner secara manual atau otomatis. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penskalaan otomatis.

Dengan konfigurasi multi-region, Spanner mereplikasi data secara sinkron di beberapa region. Replikasi ini memungkinkan operasi baca berlatensi rendah dari beberapa lokasi. Sebagai gantinya, operasi penulisan memiliki latensi yang lebih tinggi karena replika kuorum tersebar di beberapa region. Untuk meminimalkan latensi transaksi baca-tulis dalam konfigurasi multi-region, Spanner menggunakan perutean yang mendukung pemilihan pemimpin (diaktifkan secara default).

Untuk rekomendasi dalam mengoptimalkan performa instance dan database Spanner, lihat dokumentasi berikut:

Caching

Jika aplikasi Anda menyajikan aset situs statis dan jika arsitektur Anda mencakup Load Balancer Aplikasi eksternal global, Anda dapat menggunakan Cloud CDN untuk menyimpan konten statis yang sering diakses ke cache secara lebih dekat dengan pengguna Anda. 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 membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik dan rekomendasi umum yang diberikan dalam Google Cloud Framework yang Dirancang dengan Baik: Pengoptimalan performa.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: