Deployment global dengan Compute Engine dan Spanner

Last reviewed 2024-05-12 UTC

Dokumen ini menyediakan arsitektur referensi untuk aplikasi multi-tingkat 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. Panduan ini menjelaskan faktor-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 dan keandalan tinggi terhadap pemadaman layanan di beberapa region. Arsitektur ini mendukung penskalaan elastis di tingkat jaringan, aplikasi, dan database. Hal ini memungkinkan Anda 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 region Google Cloud.

Arsitektur deployment global menggunakan Compute Engine dan Spanner.

Dalam arsitektur ini, load balancer global mendistribusikan permintaan yang 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 proxy dalam jumlah besar di Google Front End (GFE). Permintaan klien diarahkan ke GFE yang terdekat dengan klien.

Bergantung pada persyaratan, Anda dapat menggunakan Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal global. Untuk mengetahui informasi selengkapnya, lihat bagian Memilih load balancer.

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.

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 berbeda. Setiap VM ini menghosting instance independen di tingkat web aplikasi.

Lapisan load balancing internal lintas region

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

Bergantung pada persyaratan, Anda dapat menggunakan Load Balancer Aplikasi internal lintas region atau Load Balancer Jaringan proxy internal lintas region. Untuk mengetahui informasi selengkapnya, lihat bagian 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 berbeda. Setiap VM menghosting instance independen pada tingkat aplikasi.

Instance multi-region Spanner

Aplikasi ini 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 wilayah ketiga.
Jaringan Virtual Private Cloud (VPC) dan subnet

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

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

Daripada menggunakan jaringan VPC tunggal, Anda dapat membuat jaringan VPC terpisah di setiap region dan menghubungkan jaringan tersebut menggunakan Pusat Konektivitas Jaringan.

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

Pertimbangan desain

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

Desain sistem

Bagian ini memberikan panduan guna membantu Anda memilih region Google Cloud untuk deployment global 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 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 melibatkan kompromi. Misalnya, region yang paling hemat biaya mungkin tidak memiliki jejak karbon terendah. Untuk 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 tingkat web dan aplikasi. Bergantung pada persyaratan aplikasi Anda, 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 apakah akan menggunakan VM, container, atau layanan serverless melibatkan kompromi antara fleksibilitas konfigurasi dan upaya pengelolaan. VM dan container menyediakan lebih banyak fleksibilitas konfigurasi, tetapi Anda bertanggung jawab untuk mengelola resource. Dalam arsitektur serverless, Anda men-deploy workload ke platform yang telah dikonfigurasi sebelumnya dan memerlukan upaya pengelolaan minimal. Untuk 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 VM. Volume Persistent Disk regional menyediakan replikasi data sinkron di dua zona dalam satu region. Data dalam volume Persistent Disk tidak direplikasi di berbagai region.

Opsi penyimpanan lain untuk deployment multi-regional mencakup bucket Cloud Storage dengan dual-region atau multi-region. Objek yang disimpan dalam bucket dual-region atau multi-region disimpan secara redundan di setidaknya dua lokasi geografis 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 keandalan terhadap gangguan zona. Anda dapat menyimpan file konfigurasi bersama, alat dan utilitas umum, serta log terpusat di instance Filestore, dan memasang instance pada 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, yakni database yang terkelola sepenuhnya, skalabel secara horizontal, terdistribusi secara global, dan direplikasi secara sinkron. Sebaiknya gunakan konfigurasi Spanner multi-regional untuk deployment yang sangat penting yang memerlukan konsistensi lintas region yang kuat. Spanner mendukung replikasi lintas region sinkron tanpa periode nonaktif untuk failover, pemeliharaan, atau pengubahan ukuran.

Untuk mengetahui informasi tentang layanan database terkelola lainnya yang dapat Anda pilih berdasarkan kebutuhan Anda, lihat Database Google Cloud. Saat memilih dan mengonfigurasi database untuk deployment multi-regional, pertimbangkan persyaratan aplikasi Anda untuk konsistensi data lintas region, dan perhatikan kompromi performa dan biayanya.

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. Misalnya, jika Anda menggunakan Load Balancer Aplikasi eksternal global, Anda dapat mengimplementasikan edge caching menggunakan Cloud CDN.

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

Keamanan dan kepatuhan

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

Perlindungan terhadap ancaman

Untuk melindungi aplikasi Anda dari ancaman seperti serangan DDoS dan XSS, Anda dapat menggunakan kebijakan keamanan Google Cloud Armor. Setiap kebijakan merupakan kumpulan aturan yang menentukan kondisi tertentu yang harus dievaluasi dan tindakan yang akan diambil saat kondisi tersebut terpenuhi. Misalnya, sebuah aturan dapat menentukan bahwa jika alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu, 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 yang menghosting tingkat aplikasi dan tingkat web 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 aman dari resource Google Cloud yang hanya memiliki alamat IP pribadi, seperti VM Compute Engine dalam arsitektur referensi ini, Anda dapat menggunakan Proxy Web Aman atau 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 dapat menentukan kebijakan organisasi yang membatasi penggunaan image dalam project image publik tertentu. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan kebijakan image tepercaya.

Hak istimewa akun layanan

Di project Google Cloud yang mengaktifkan Compute Engine API, akun layanan default akan otomatis dibuat. Untuk organisasi Google Cloud yang dibuat sebelum 3 Mei 2024, akun layanan default ini diberi peran IAM Editor (roles/editor) kecuali jika perilaku ini dinonaktifkan.

Secara default, akun layanan default terhubung ke semua VM yang Anda buat menggunakan Google Cloud CLI atau Konsol Google Cloud. Peran Editor mencakup berbagai izin. Jadi, 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 oleh akun layanan, gunakan kebijakan terperinci. Untuk informasi selengkapnya, lihat Membatasi hak istimewa akun layanan di "Praktik terbaik untuk menggunakan akun layanan".

Pertimbangan keamanan lainnya

Saat membangun arsitektur untuk workload Anda, pertimbangkan praktik terbaik keamanan tingkat platform dan rekomendasi yang disediakan dalam blueprint dasar perusahaan.

Keandalan

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

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi di beberapa MIG regional, aplikasi tersebut akan tetap tersedia selama gangguan zona terisolasi atau gangguan region. Kemampuan penskalaan otomatis MIG stateless memungkinkan Anda menjaga 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. Stateful MIG tidak dapat diskalakan secara otomatis. Untuk informasi selengkapnya, lihat Penskalaan otomatis grup instance.

Autohealing VM

Terkadang, VM yang menghosting aplikasi Anda mungkin sedang berjalan dan tersedia, tetapi mungkin ada masalah pada aplikasinya sendiri. Perangkat mungkin berhenti berfungsi, 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 pemulihan otomatis MIG Anda. Jika aplikasi di VM tertentu tidak merespons, MIG akan otomatis menyembuhkan (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 berjalan di VM Compute Engine yang didistribusikan di berbagai zona. Distribusi ini memastikan aplikasi Anda andal terhadap pemadaman zona. Untuk meningkatkan keandalan ini lebih lanjut, Anda dapat membuat kebijakan penempatan sebar 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 kuat terhadap kegagalan host individu. Untuk mengetahui informasi selengkapnya, lihat Menerapkan kebijakan penempatan tersebar ke VM.

Perencanaan kapasitas VM

Guna memastikan kapasitas untuk VM Compute Engine tersedia saat diperlukan untuk penskalaan otomatis MIG, Anda dapat membuat reservasi. Reservasi memberikan jaminan kapasitas di zona tertentu untuk sejumlah VM dari jenis mesin tertentu yang Anda pilih. Reservasi bisa spesifik untuk sebuah project, atau dibagikan ke 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 stateful untuk memastikan data dipertahankan saat VM diperbaiki atau dibuat ulang. Namun, sebaiknya pertahankan boot disk agar tetap stateless, sehingga Anda dapat mengupdatenya dengan mudah ke image terbaru dengan versi dan patch keamanan baru. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi persistent disk stateful di MIG.

Ketahanan data

Anda dapat menggunakan Pencadangan dan Layanan DR untuk membuat, menyimpan, dan mengelola cadangan VM Compute Engine. Cadangan dan DR menyimpan data cadangan dalam format aslinya yang dapat dibaca aplikasi. Jika diperlukan, Anda dapat memulihkan workload ke produksi dengan langsung menggunakan data dari penyimpanan cadangan jangka panjang tanpa pemindahan data atau aktivitas persiapan yang memakan waktu.

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

  • Snapshot standar memungkinkan Anda merekam 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 mengetahui rekomendasi selengkapnya tentang penggunaan dan pengelolaan snapshot, baca artikel 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 menyimpan replika disk di zona 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.

Anda dapat menggunakan fitur pencadangan dan pemulihan di Spanner untuk membantu melindungi data dari kerusakan data yang disebabkan oleh error operator dan masalah aplikasi. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pencadangan dan pemulihan Spanner.

Keandalan database

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

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

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

Spanner menggunakan penyimpanan yang terpisah, tempat resource komputasi dan penyimpanan dipisahkan. Anda tidak perlu memindahkan data saat menambahkan kapasitas komputasi untuk HA atau penskalaan. Resource komputasi yang baru mendapatkan data saat mereka membutuhkannya dari node Colossus terdekat. Hal ini membuat failover dan penskalaan menjadi lebih cepat dan tidak terlalu berisiko.

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

Pertimbangan keandalan lainnya

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

Pengoptimalan biaya

Bagian ini berisi 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 VM, Compute Engine memberikan rekomendasi jenis mesin. Gunakan rekomendasi ini 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 dalam tingkat aplikasi dan web. Biaya Spot VM jauh lebih rendah dibandingkan VM biasa. Namun, Compute Engine dapat menghentikan atau menghapus Spot VM secara preemtif untuk mengklaim kembali kapasitas. Spot VM cocok untuk tugas batch yang dapat menoleransi preemption dan tidak memiliki persyaratan ketersediaan yang tinggi. Spot VM menawarkan jenis, opsi, dan performa mesin yang sama dengan VM biasa. 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 kembali tersedia.

Pemanfaatan resource VM

Kemampuan penskalaan otomatis MIG stateless memungkinkan aplikasi Anda menangani peningkatan traffic dengan lancar, dan membantu Anda mengurangi biaya saat kebutuhan resource rendah. Stateful MIG tidak dapat diskalakan secara 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 linear sesuai kapasitas komputasi. Anda hanya membayar sesuai penggunaan. Jika 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, sebaiknya lakukan hal berikut:

  • Sediakan jumlah core CPU komputasi yang diperlukan secara terpisah dari memori menggunakan jenis mesin kustom. Dengan begitu, Anda membatasi biaya pemberian lisensi pihak ketiga ke jumlah core CPU yang Anda perlukan.
  • Kurangi jumlah vCPU per inti dari 2 menjadi 1 dengan menonaktifkan multithreading simultan (SMT), dan kurangi biaya lisensi Anda sebesar 50%.

Pertimbangan biaya lainnya

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

Efisiensi operasional

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

Update konfigurasi VM

Untuk mengupdate konfigurasi VM dalam MIG (seperti jenis mesin atau image boot-disk), buat template instance baru dengan konfigurasi yang diperlukan, lalu terapkan template baru ke MIG. MIG akan mengupdate VM menggunakan metode update yang Anda pilih: otomatis atau selektif. Pilih metode yang sesuai berdasarkan persyaratan 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, 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 Anda 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 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, Proses migrasi bergantung pada sejumlah faktor seperti database sumber, ukuran data, batasan periode nonaktif, dan kompleksitas kode aplikasi. Untuk membantu Anda merencanakan dan mengimplementasikan migrasi ke Spanner secara efisien, kami menyediakan berbagai alat Google Cloud dan pihak ketiga. Untuk mengetahui informasi selengkapnya, lihat Ringkasan migrasi.

Administrasi database

Dengan Spanner, Anda tidak perlu mengonfigurasi atau memantau replikasi atau failover. Replikasi sinkron dan failover otomatis merupakan fitur bawaan. Aplikasi Anda tidak akan mengalami periode nonaktif untuk pemeliharaan database dan failover. Untuk mengurangi kompleksitas operasional lebih lanjut, Anda dapat mengonfigurasi penskalaan otomatis. Dengan mengaktifkan penskalaan otomatis, 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 Framework Arsitektur Google Cloud: Keunggulan operasional.

Pengoptimalan performa

Bagian ini menjelaskan faktor-faktor yang harus dipertimbangkan saat menggunakan arsitektur referensi ini untuk merancang dan membangun topologi global di Google Cloud yang memenuhi persyaratan performa workload 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 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 sesuai dengan persyaratan biaya dan performa. Jenis mesin dikelompokkan ke dalam seri dan kelompok mesin. Tabel berikut berisi ringkasan grup mesin yang direkomendasikan untuk berbagai jenis workload:

Persyaratan Kelompok mesin yang direkomendasikan
Rasio harga-performa terbaik untuk berbagai workload Kelompok mesin tujuan umum
Performa tertinggi per inti dan dioptimalkan untuk workload yang sarat komputasi Kelompok mesin yang dioptimalkan untuk komputasi
Rasio memori terhadap vCPU tinggi untuk workload yang menggunakan banyak memori Kelompok mesin yang dioptimalkan untuk memori
GPU untuk workload yang diparalelkan secara masif Kelompok mesin yang dioptimalkan akselerator
Penggunaan inti rendah dan kepadatan penyimpanan tinggi Kelompok mesin yang dioptimalkan untuk penyimpanan

Untuk mengetahui informasi selengkapnya, lihat Panduan perbandingan dan referensi 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 workload yang sangat paralel 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.

Network Service Tiers

Dengan Tingkat Layanan Jaringan, Anda dapat mengoptimalkan biaya dan performa jaringan workload. Bergantung pada persyaratan, Anda dapat memilih Paket Premium atau 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 mencapai kehilangan dan latensi paket minimal.

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

Performa Spanner

Saat menyediakan instance Spanner, Anda menentukan kapasitas komputasi instance dari segi jumlah node atau unit pemrosesan. Pantau pemanfaatan resource pada instance Spanner, dan skalakan kapasitas berdasarkan beban yang diharapkan dan persyaratan performa aplikasi Anda. Anda dapat menskalakan kapasitas instance Spanner secara manual atau otomatis. Untuk mengetahui informasi selengkapnya, baca Ringkasan penskalaan otomatis.

Dengan konfigurasi multi-region, Spanner mereplikasi data secara sinkron di beberapa region. Replikasi ini memungkinkan operasi read berlatensi rendah dari beberapa lokasi. Konsekuensinya adalah latensi yang lebih tinggi untuk operasi tulis, karena replika kuorum tersebar di beberapa region. Untuk meminimalkan latensi transaksi baca-tulis dalam konfigurasi multi-region, Spanner menggunakan perutean berbasis pemimpin (diaktifkan secara default).

Untuk mendapatkan rekomendasi terkait cara mengoptimalkan performa instance dan database Spanner, baca dokumentasi berikut:

Menyimpan data ke dalam cache

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 sering diakses ke dalam cache lebih dekat ke pengguna Anda. Cloud CDN dapat membantu meningkatkan performa untuk 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 workload, pertimbangkan praktik terbaik dan rekomendasi umum yang disediakan di Google Cloud Architecture Framework: Pengoptimalan performa.

Langkah selanjutnya

Kontributor

Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk

Kontributor lainnya: