Bermigrasi di seluruh region Google Cloud: Mendesain lingkungan satu region yang tangguh di Google Cloud

Last reviewed 2024-12-08 UTC

Dokumen ini membantu Anda mendesain lingkungan satu region yang tangguh di Google Cloud. Dokumen ini berguna jika Anda berencana memigrasikan lingkungan satu region atau jika Anda mengevaluasi peluang untuk melakukannya di masa mendatang dan ingin mempelajari seperti apa tampilannya.

Dokumen ini adalah bagian dari rangkaian:

Dokumen ini bertujuan untuk memberikan panduan tentang cara mendesain lingkungan satu region yang tangguh di Google Cloud, dan berfokus pada komponen arsitektur berikut:

Panduan dalam dokumen ini mengasumsikan bahwa Anda sedang mendesain dan menerapkan lingkungan satu region. Jika menggunakan lingkungan satu region sekarang, Anda dapat bermigrasi ke lingkungan multi-region pada masa mendatang. Jika Anda mempertimbangkan migrasi dan evolusi lingkungan zona dan satu region ke lingkungan multi-region pada masa mendatang, lihat Memigrasikan di seluruh region: Memulai. Google Cloud

Properti berbagai jenis arsitektur deployment

Google Cloud produk disediakan di banyak region dan zona.

Saat mendesain lingkungan Google Cloud , Anda dapat memilih antara pola dasar deployment berikut, yang disajikan dalam urutan peningkatan keandalan dan overhead operasional:

  • Zonal: Anda menyediakan resource Google Cloud di satu zona dalam suatu region, dan Anda menggunakan layanan zonal jika tersedia. Jika layanan zonal tidak tersedia, Anda menggunakan layanan regional.
  • Regional: Anda menyediakan Google Cloud resource di beberapa zona dalam suatu region, dan Anda menggunakan layanan regional jika memungkinkan.
  • Multi-regional: Anda menyediakan Google Cloud resource di beberapa zona di berbagai region. Resource zona disediakan di satu atau beberapa zona di setiap region.
  • Global: Anda menyediakan Google Cloud resource di beberapa zona di berbagai region di seluruh dunia. Resource zona di-provisioning di satu atau beberapa zona di setiap region.

Arketipe deployment sebelumnya memiliki properti keandalan yang berbeda, dan Anda dapat menggunakannya untuk memberikan jaminan keandalan yang dibutuhkan lingkungan Anda. Misalnya, lingkungan multi-region lebih mungkin bertahan dari pemadaman layanan regional dibandingkan dengan lingkungan zona atau region tunggal. Untuk mengetahui informasi selengkapnya tentang properti keandalan setiap arketipe deployment, lihat Cara memanfaatkan zona dan region untuk mencapai keandalan dan Google Cloud panduan keandalan infrastruktur.

Mendesain, menerapkan, dan mengoperasikan lingkungan berdasarkan arketipe deployment ini memerlukan tingkat upaya yang berbeda karena properti biaya dan kompleksitas setiap arketipe deployment. Misalnya, lingkungan zona mungkin lebih murah dan lebih mudah didesain, diterapkan, dan dioperasikan dibandingkan dengan lingkungan regional atau multi-region. Potensi upaya dan biaya yang lebih rendah di lingkungan zonal disebabkan oleh overhead tambahan yang harus Anda kelola untuk mengoordinasikan workload, data, dan proses yang berada di region yang berbeda.

Tabel berikut merangkum distribusi resource, properti keandalan, dan kompleksitas setiap arketipe deployment. Bagian ini juga menggambarkan upaya yang diperlukan untuk mendesain dan menerapkan lingkungan berdasarkan setiap opsi.

Nama jenis arsitektur deployment Distribusi resource Membantu menahan Kompleksitas desain
Lingkungan zona Dalam satu zona Kegagalan resource Memerlukan koordinasi di dalam satu zona
Lingkungan satu region Di beberapa zona, dalam satu region Kegagalan resource, gangguan tingkat zona Memerlukan koordinasi di beberapa zona, dalam satu region
Lingkungan multi-region Di beberapa zona, di beberapa region Kegagalan resource, pemadaman layanan zona, pemadaman layanan regional, pemadaman layanan multi-region Memerlukan koordinasi di beberapa zona, di beberapa region
Lingkungan global Di beberapa zona, di beberapa region secara global Kegagalan resource, pemadaman layanan zona, pemadaman layanan regional, pemadaman layanan multi-region Memerlukan koordinasi di beberapa zona, di beberapa region

Untuk mengetahui informasi selengkapnya tentang jenis deployment ini dan lainnya, lihat Jenis deploymentGoogle Cloud .

Memilih jenis arsitektur deployment untuk lingkungan Anda

Untuk memilih arketipe deployment yang paling sesuai dengan kebutuhan Anda, lakukan hal berikut:

  1. Tentukan model kegagalan yang ingin Anda hindari.
  2. Evaluasi arketipe deployment untuk menentukan arketipe yang paling sesuai dengan kebutuhan Anda.

Menentukan model kegagalan

Untuk menentukan model kegagalan, pertimbangkan pertanyaan berikut:

  • Komponen lingkungan mana yang memerlukan model kegagalan? Model kegagalan dapat diterapkan pada apa pun yang Anda sediakan atau deploy di Google Cloud. Model kegagalan dapat diterapkan ke setiap individu, atau Anda dapat menerapkan model kegagalan ke semua resource di seluruh zona atau region. Sebaiknya Anda menerapkan model kegagalan pada apa pun yang memberikan nilai bagi Anda, seperti beban kerja, data, proses, dan resource Google Cloud.
  • Apa persyaratan ketersediaan tinggi, kelangsungan bisnis, dan pemulihan dari bencana untuk komponen ini? Setiap komponen lingkungan Anda mungkin memiliki tujuan tingkat layanan (SLO) sendiri yang menentukan tingkat layanan yang dapat diterima untuk komponen tersebut, dan persyaratan pemulihan dari bencana sendiri. Misalnya, SLA Compute Engine menunjukkan bahwa jika Anda perlu mencapai waktu aktif bulanan lebih dari 99,5%, Anda harus menyediakan instance di beberapa zona di satu region. Untuk mengetahui informasi selengkapnya, lihat Panduan perencanaan pemulihan dari bencana.
  • Berapa banyak model kegagalan yang perlu Anda tentukan? Dalam lingkungan yang umum, tidak semua komponen harus memberikan jaminan keandalan yang sama. Jika Anda menawarkan jaminan untuk waktu beroperasi yang lebih tinggi dan ketahanan yang lebih kuat, Anda biasanya harus mengeluarkan lebih banyak upaya dan sumber daya. Saat Anda menentukan model kegagalan, sebaiknya pertimbangkan pendekatan dengan menentukan beberapa model kegagalan untuk setiap komponen, dan bukan hanya satu untuk semua komponen. Misalnya, beban kerja penting bagi bisnis biasanya perlu menawarkan keandalan yang lebih tinggi, meskipun mungkin dapat diterima untuk menawarkan jaminan keandalan yang lebih rendah untuk beban kerja lain yang kurang penting.
  • Berapa banyak resource yang dibutuhkan model kegagalan untuk mencegah kegagalan? Untuk melindungi dari model kegagalan yang Anda tentukan, Anda mengeluarkan sumber daya seperti waktu dan biaya yang diperlukan bagi orang-orang untuk merancang, menyediakan, dan mengonfigurasi mekanisme perlindungan dan proses otomatis. Sebaiknya Anda menilai jumlah resource yang diperlukan untuk melindungi diri dari setiap model kegagalan yang Anda tentukan.
  • Bagaimana cara Anda mendeteksi terjadinya kegagalan? Kemampuan untuk mendeteksi bahwa kegagalan sedang terjadi atau akan terjadi sangat penting agar Anda dapat memulai proses mitigasi, pemulihan, dan rekonsiliasi. Misalnya, Anda dapat mengonfigurasi Google Cloud Observability untuk memberi tahu Anda tentang penurunan performa.
  • Bagaimana cara menguji model kegagalan yang Anda tentukan? Saat Anda menentukan model kegagalan, sebaiknya pikirkan cara untuk terus-menerus menguji setiap model guna memverifikasi bahwa model tersebut secara efektif mencegah kegagalan yang menjadi tujuan model. Misalnya, Anda dapat menyuntikkan kesalahan di lingkungan Anda, atau untuk menilai kemampuan lingkungan Anda dalam menangani kegagalan, Anda dapat menerapkan chaos engineering.
  • Seberapa besar dampak yang Anda harapkan jika model kegagalan tertentu terjadi? Untuk memahami dampak kegagalan terhadap bisnis Anda, sebaiknya untuk setiap model kegagalan, Anda memperkirakan konsekuensi setiap kegagalan yang dirancang oleh model. Pemahaman ini berguna dalam menetapkan prioritas dan urutan pemulihan sehingga Anda dan proses Anda dapat menangani komponen yang paling penting terlebih dahulu.
  • Berapa lama perkiraan kegagalan akan terjadi dalam model kegagalan yang Anda tentukan? Durasi kegagalan dapat sangat memengaruhi rencana mitigasi dan pemulihan. Oleh karena itu, saat menentukan model kegagalan, sebaiknya Anda memperhitungkan berapa lama kegagalan dapat terjadi. Saat Anda mempertimbangkan berapa lama kegagalan dapat terjadi, pertimbangkan juga berapa lama waktu yang diperlukan untuk: mengidentifikasi kegagalan, merekonsiliasi kegagalan, dan memulihkan resource yang gagal.

Untuk mengetahui pertimbangan lainnya tentang model kegagalan dan cara merancang rencana pemulihan dari bencana yang andal, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.

Mengevaluasi jenis arsitektur deployment

Setelah menentukan model kegagalan yang ingin Anda hindari, Anda mengevaluasi arketipe deployment untuk menentukan apa yang paling sesuai dengan kebutuhan Anda. Saat Anda mengevaluasi arketipe deployment, pertimbangkan pertanyaan berikut:

  • Berapa banyak arketipe deployment yang Anda butuhkan? Anda tidak perlu memilih hanya satu arketipe deployment agar sesuai dengan semua lingkungan Anda. Sebagai gantinya, Anda dapat menerapkan pendekatan hibrida dengan memilih beberapa tipe deployment sesuai dengan jaminan keandalan yang Anda butuhkan untuk melindungi diri dari model kegagalan yang Anda tentukan. Misalnya, jika Anda menentukan dua model kegagalan—satu yang memerlukan lingkungan zonal, dan satu yang memerlukan lingkungan regional—Anda mungkin ingin memilih arketipe deployment terpisah untuk melindungi dari setiap model kegagalan. Jika Anda memilih beberapa arketipe deployment, sebaiknya Anda mengevaluasi potensi peningkatan kompleksitas dalam mendesain, menerapkan, dan mengoperasikan beberapa lingkungan.
  • Berapa banyak resource yang Anda butuhkan untuk mendesain dan menerapkan lingkungan berdasarkan arketipe deployment? Mendesain dan menerapkan jenis lingkungan apa pun memerlukan sumber daya dan upaya. Sebaiknya Anda menilai jumlah resource yang Anda perlukan untuk mendesain dan menerapkan setiap lingkungan berdasarkan arketipe yang Anda pilih. Jika Anda telah memahami sepenuhnya jumlah resource yang Anda butuhkan, Anda dapat menyeimbangkan kompromi antara jaminan keandalan yang ditawarkan setiap arketipe deployment, serta biaya dan kompleksitas desain, penerapan, dan pengoperasian lingkungan berdasarkan arketipe tersebut.
  • Apakah Anda berencana memigrasikan lingkungan berdasarkan satu arketipe deployment ke lingkungan berdasarkan arketipe yang berbeda? Pada masa mendatang, Anda dapat memigrasikan workload, data, dan proses dari satu Google Cloud lingkungan ke lingkungan Google Cloud lain. Misalnya, Anda dapat bermigrasi dari lingkungan zona ke lingkungan regional.
  • Seberapa penting lingkungan yang Anda desain dan terapkan bagi bisnis? Lingkungan yang penting bagi bisnis kemungkinan memerlukan jaminan keandalan yang lebih tinggi. Misalnya, Anda dapat memilih untuk mendesain dan menerapkan lingkungan multi-region untuk beban kerja, data, dan proses yang penting bagi bisnis, serta mendesain lingkungan zonal atau regional untuk beban kerja, data, dan proses yang kurang penting.
  • Apakah Anda memerlukan fitur yang ditawarkan oleh arketipe deployment tertentu untuk lingkungan tertentu? Selain jaminan keandalan yang ditawarkan setiap arketipe deployment, arketipe juga menawarkan jaminan skalabilitas, kedekatan geografis, latensi, dan lokalitas data yang berbeda. Sebaiknya Anda mempertimbangkan jaminan tersebut saat memilih arketipe deployment untuk lingkungan Anda.

Selain aspek teknis mode kegagalan yang Anda tentukan dengan mengikuti panduan sebelumnya, sebaiknya pertimbangkan persyaratan non-fungsional seperti persyaratan peraturan, lokalitas, dan kedaulatan. Persyaratan tersebut dapat membatasi opsi yang tersedia untuk Anda. Misalnya, jika Anda perlu memenuhi persyaratan peraturan yang mewajibkan penggunaan region tertentu, Anda harus mendesain dan menerapkan lingkungan satu region, atau lingkungan zonal di region tersebut.

Pilih Google Cloud region untuk lingkungan Anda

Saat mulai mendesain lingkungan satu region, Anda harus menentukan region yang paling sesuai dengan persyaratan setiap lingkungan. Bagian berikut menjelaskan dua kategori kriteria seleksi ini:

  • Kriteria fungsional. Kriteria ini berkaitan dengan Google Cloud produk yang ditawarkan wilayah tertentu, dan apakah wilayah tertentu memenuhi persyaratan latensi dan kedekatan geografis Anda dengan pengguna dan lingkungan lain di luar Google Cloud. Misalnya, jika beban kerja dan data Anda memiliki persyaratan latensi untuk pengguna atau lingkungan lain di luar Google Cloud, Anda mungkin perlu memilih region yang paling dekat dengan pengguna atau lingkungan lain untuk meminimalkan latensi tersebut. Google Cloud
  • Kriteria tidak berfungsi. Kriteria ini terkait dengan harga produk yang dikaitkan dengan wilayah tertentu, persyaratan jejak karbon, serta persyaratan dan peraturan wajib yang berlaku untuk bisnis Anda. Misalnya, pasar yang sangat diatur seperti sektor perbankan dan publik memiliki persyaratan yang sangat ketat dan spesifik tentang lokalitas data dan workload, serta cara mereka berbagi infrastruktur penyedia cloud dengan pelanggan lain.

Jika Anda memilih region Google Cloud tertentu sekarang, pada masa mendatang Anda dapat bermigrasi ke region lain atau ke lingkungan multi-region. Jika Anda mempertimbangkan migrasi ke region lain pada masa mendatang, lihat Memigrasikan data di seluruh region: Mulai Google Cloud .

Mengevaluasi kriteria fungsional

Untuk mengevaluasi kriteria fungsional, pertimbangkan pertanyaan berikut:

  • Apa persyaratan kedekatan geografis Anda? Saat memilih Google Cloud region, Anda mungkin perlu menempatkan workload, data, dan proses di dekat pengguna atau lingkungan Anda di luar Google Cloud, seperti lingkungan lokal Anda. Misalnya, jika Anda menargetkan basis pengguna yang terkonsentrasi di area geografis tertentu, sebaiknya pilih Google Cloud region yang paling dekat dengan area geografis tersebut. Memilih Google Cloud region yang paling sesuai dengan persyaratan kedekatan geografis memungkinkan lingkungan Anda menjamin latensi yang lebih rendah dan waktu reaksi yang lebih cepat terhadap permintaan dari pengguna dan dari lingkungan Anda di luar Google Cloud. Alat seperti Google Cloud dasbor latensi, dan alat tidak resmi seperti GCPing dan Google Cloud Pemilih Region dapat memberi Anda gambaran umum tentang karakteristik latensi Google Cloud region. Namun, sebaiknya lakukan penilaian komprehensif untuk mengevaluasi apakah properti latensi sesuai dengan persyaratan, beban kerja, data, dan proses Anda.
  • Region mana yang ingin Anda gunakan dan menawarkan produk yang Anda butuhkan? Sebaiknya Anda menilai produk yang tersedia di setiap wilayah, dan wilayah mana yang menyediakan layanan yang Anda butuhkan untuk mendesain dan menerapkan lingkungan Anda. Google Cloud Untuk mengetahui informasi selengkapnya tentang produk yang tersedia di setiap region dan linimasa ketersediaannya, lihat Lokasi cloud. Selain itu, beberapa produk mungkin tidak menawarkan semua fiturnya di setiap wilayah tempat produk tersebut tersedia. Misalnya, region dan zona yang tersedia untuk Compute Engine menawarkan jenis mesin tertentu di Google Cloud region tertentu. Untuk mengetahui informasi selengkapnya tentang fitur yang ditawarkan setiap produk di setiap wilayah, lihat dokumentasi produk.
  • Apakah resource yang Anda butuhkan di setiap Google Cloud region berada dalam batas kuota per region? Google Cloud menggunakan kuota untuk membatasi jumlah resource Google Cloud bersama yang dapat Anda gunakan. Beberapa kuota bersifat global dan berlaku untuk penggunaan resource di mana saja di Google Cloud, sementara yang lain bersifat regional atau zonal dan berlaku untuk penggunaan resource di region Google Cloud tertentu. Misalnya, sebagian besar kuota penggunaan resource Compute Engine, seperti jumlah virtual machine yang dapat Anda buat, bersifat regional. Untuk mengetahui informasi selengkapnya tentang kuota dan cara menambahnya, lihat Mengelola kuota.

Mengevaluasi kriteria non-fungsional

Untuk mengevaluasi kriteria non-fungsional, pertimbangkan pertanyaan berikut:

  • Apakah Anda lebih memilih jejak karbon yang rendah? Google Cloudterus berinvestasi dalam keberlanjutan dan dalam energi bebas karbon untuk region Google Cloud , dan berkomitmen terhadap energi bebas karbon untuk semua region cloud. RegionGoogle Cloud memiliki jejak karbon yang berbeda-beda. Untuk informasi tentang jejak karbon setiap Google Cloud region, dan cara memasukkan energi bebas karbon dalam strategi lokasi Anda, lihat Energi bebas karbon untuk Google Cloud region.
  • Apakah lingkungan Anda harus mematuhi peraturan tertentu? Pemerintah serta entitas nasional dan supranasional sering kali mengatur secara ketat pasar dan area bisnis tertentu, seperti perbankan dan sektor publik. Peraturan ini mungkin mewajibkan workload, data, dan proses berada hanya di wilayah geografis tertentu. Misalnya, lingkungan Anda mungkin perlu mematuhi persyaratan kedaulatan data, operasional, dan software untuk menjamin tingkat kontrol dan transparansi tertentu untuk data sensitif dan beban kerja yang berjalan di cloud. Sebaiknya Anda menilai persyaratan peraturan saat ini dan yang akan datang saat memilihGoogle Cloud region untuk lingkungan Anda, dan memilihGoogle Cloud region yang paling sesuai dengan persyaratan peraturan Anda.

Mendesain dan membangun lingkungan satu region

Untuk mendesain lingkungan satu region, lakukan hal berikut:

  1. Bangun fondasi Anda di Google Cloud.
  2. Menyediakan dan mengonfigurasi resource komputasi.
  3. Sediakan dan konfigurasi resource penyimpanan data.
  4. Menyediakan dan mengonfigurasi resource analisis data.

Saat mendesain lingkungan, pertimbangkan prinsip desain umum berikut:

  • Sediakan resource regional. Banyak Google Cloud produk mendukung penyediaan resource di beberapa zona di seluruh region. Sebaiknya Anda menyediakan resource regional, bukan resource zona, jika memungkinkan. Secara teoretis, Anda dapat menyediakan resource zonal di beberapa zona di seluruh region dan mengelolanya sendiri untuk mencapai keandalan yang lebih tinggi. Namun, konfigurasi tersebut tidak akan sepenuhnya mendapatkan manfaat dari semua fitur keandalan infrastruktur Google yang mendasari Google Cloud layanan.
  • Verifikasi bahwa lingkungan berfungsi seperti yang diharapkan dengan asumsi model kegagalan. Saat mendesain dan menerapkan lingkungan satu region, sebaiknya Anda memverifikasi apakah lingkungan tersebut memenuhi persyaratan untuk melindungi dari model kegagalan yang Anda pertimbangkan, sebelum mempromosikan lingkungan tersebut sebagai bagian dari lingkungan produksi Anda. Misalnya, Anda dapat menyimulasikan pemadaman layanan zona untuk memverifikasi bahwa lingkungan satu region Anda dapat bertahan dengan gangguan minimal.

Untuk mengetahui prinsip desain yang lebih umum dalam mendesain lingkungan single-region dan multi-region yang andal serta informasi tentang cara Google mencapai keandalan yang lebih baik dengan layanan regional dan multi-region, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Tema umum.

Membangun fondasi Anda di Google Cloud

Untuk membangun fondasi lingkungan satu region, lihat Migrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda. Panduan dalam dokumen tersebut bertujuan untuk membangun fondasi untuk memigrasikan workload, data, dan proses ke Google Cloud, tetapi juga berlaku untuk membangun fondasi bagi lingkungan satu region Anda. Setelah Anda membaca dokumen tersebut, lanjutkan membaca dokumen ini.

Setelah membangun fondasi di Google Cloud, Anda mendesain dan menerapkan kontrol dan batas keamanan. Langkah-langkah keamanan tersebut membantu memastikan bahwa workload, data, dan proses Anda tetap berada di dalam region masing-masing. Tindakan pengamanan ini juga membantu memastikan bahwa resource Anda tidak membocorkan apa pun ke region lain karena bug, kesalahan konfigurasi, atau serangan berbahaya.

Menyediakan dan mengonfigurasi resource komputasi

Setelah membangun fondasi lingkungan region tunggal, Anda akan menyediakan dan mengonfigurasi resource komputasi. Bagian berikut menjelaskan produk komputasiGoogle Cloud yang mendukung deployment regional.

Compute Engine

Compute Engine adalah infrastructure as a service (IaaS) Google Cloud. Compute Engine menggunakan infrastruktur Google di seluruh dunia untuk menawarkan virtual machine dan layanan terkait kepada pelanggan.

Resource Compute Engine bersifat zonal, seperti virtual machine atau Persistent Disk zona; regional, seperti alamat IP eksternal statis; atau global, seperti snapshot Persistent Disk. Untuk mengetahui informasi selengkapnya tentang resource zona, regional, dan global yang didukung Compute Engine, lihat Resource global, regional, dan zona.

Untuk memungkinkan fleksibilitas dan pengelolaan resource fisik yang lebih baik, Compute Engine memisahkan zona dari resource fisiknya. Untuk mengetahui informasi selengkapnya tentang abstraksi ini dan implikasinya bagi Anda, lihat Zona dan cluster.

Untuk meningkatkan keandalan lingkungan yang menggunakan Compute Engine, pertimbangkan hal berikut:

  • Grup instance terkelola (MIG) regional. Virtual machine Compute Engine adalah resource zona, sehingga tidak akan tersedia jika terjadi pemadaman layanan zona. Untuk mengatasi masalah ini, Compute Engine memungkinkan Anda membuat MIG regional yang menyediakan mesin virtual di beberapa zona dalam satu region secara otomatis, sesuai dengan permintaan dan ketersediaan regional.

    Jika workload Anda berstatus stateful, Anda juga dapat membuat MIG stateful regional untuk mempertahankan data dan konfigurasi stateful. MIG regional mendukung simulasi kegagalan tingkat zona. Untuk mengetahui informasi tentang cara menyimulasikan kegagalan zona saat menggunakan MIG regional, lihat Menyimulasikan pemadaman layanan zona untuk MIG regional. Untuk mengetahui informasi tentang perbandingan MIG regional dengan opsi deployment lainnya, lihat Memilih strategi deployment Compute Engine untuk workload Anda.

  • Bentuk distribusi target. MIG regional mendistribusikan mesin virtual sesuai dengan bentuk distribusi target. Untuk memastikan distribusi virtual machine tidak berbeda lebih dari satu unit antara dua zona mana pun dalam suatu region, sebaiknya pilih bentuk distribusi EVEN saat membuat MIG regional. Untuk mengetahui informasi tentang perbedaan antara bentuk distribusi target, lihat Perbandingan bentuk.

  • Template instance. Untuk menentukan mesin virtual yang akan disediakan, MIG menggunakan jenis resource global yang disebut template instance. Meskipun template instance adalah resource global, template tersebut dapat mereferensikan resource zonal atau regional. Saat membuat template instance, sebaiknya Anda mereferensikan resource regional daripada resource zona jika memungkinkan. Jika Anda menggunakan resource zonal, sebaiknya Anda menilai dampak penggunaan resource tersebut. Misalnya, jika Anda membuat template instance yang mereferensikan volume Persistent Disk yang hanya tersedia di zona tertentu, Anda tidak dapat menggunakan template tersebut di zona lain karena volume Persistent Disk tidak tersedia di zona lain tersebut.

  • Konfigurasi load balancing dan penskalaan. Compute Engine mendukung traffic load balancing di antara instance Compute Engine, dan mendukung penskalaan otomatis untuk menambahkan atau menghapus virtual machine dari MIG secara otomatis, sesuai permintaan. Untuk meningkatkan keandalan dan fleksibilitas lingkungan Anda, serta menghindari beban pengelolaan solusi yang dikelola sendiri, sebaiknya konfigurasi load balancing dan penskalaan otomatis. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi load balancing dan penskalaan untuk Compute Engine, lihat Load balancing dan penskalaan.

  • Mengonfigurasi reservasi resource. Untuk memastikan lingkungan Anda memiliki resource yang diperlukan saat Anda membutuhkannya, sebaiknya Anda mengonfigurasi pemesanan resource untuk memberikan jaminan dalam mendapatkan kapasitas untuk resource Compute Engine zona. Misalnya, jika terjadi pemadaman layanan zona, Anda mungkin perlu menyediakan mesin virtual di zona lain untuk menyediakan kapasitas yang diperlukan guna menggantikan mesin virtual yang tidak tersedia karena pemadaman layanan. Reservasi resource memastikan bahwa Anda memiliki resource yang tersedia untuk menyediakan virtual machine tambahan.

  • Gunakan nama DNS zona. Untuk mengurangi risiko gangguan lintas regional, sebaiknya gunakan nama DNS zona untuk mengidentifikasi secara unik mesin virtual yang menggunakan nama DNS di lingkungan Anda. Google Cloud menggunakan nama DNS zona untuk mesin virtual Compute Engine secara default. Untuk mengetahui informasi selengkapnya tentang cara kerja DNS internal Compute Engine, lihat DNS internal. Untuk memfasilitasi migrasi lintas region pada masa mendatang, dan agar konfigurasi Anda lebih mudah dikelola, sebaiknya pertimbangkan nama DNS zona sebagai parameter konfigurasi yang dapat Anda ubah pada masa mendatang.

  • Pilih opsi penyimpanan yang sesuai. Compute Engine mendukung beberapa opsi penyimpanan untuk virtual machine Anda, seperti volume Persistent Disk dan solid state drive (SSD) lokal:

    • Volume Persistent Disk didistribusikan ke beberapa disk fisik, dan ditempatkan secara terpisah dari virtual machine Anda. Persistent disk dapat bersifat zonal atau regional. Persistent disk zonal menyimpan data di satu zona, sedangkan persistent disk regional mereplikasi data di dua zona yang berbeda. Saat memilih opsi penyimpanan untuk lingkungan single-region, sebaiknya pilih persistent disk regional karena opsi ini memberi Anda opsi failover jika terjadi kegagalan zonal. Untuk mengetahui informasi selengkapnya tentang cara merespons kegagalan zona saat Anda menggunakan persistent disk regional, lihat Opsi ketersediaan tinggi menggunakan Persistent Disk regional dan Failover Persistent Disk regional.
    • SSD lokal memiliki throughput yang tinggi, tetapi hanya menyimpan data hingga instance dihentikan atau dihapus. Oleh karena itu, SSD lokal ideal untuk menyimpan data sementara, cache, dan data yang dapat Anda rekonstruksi dengan cara lain. Persistent disk adalah perangkat penyimpanan tahan lama yang dapat diakses virtual machine seperti disk fisik.

  • Merancang dan menerapkan mekanisme untuk perlindungan data. Saat mendesain lingkungan satu region, sebaiknya Anda menerapkan mekanisme otomatis untuk melindungi data Anda jika terjadi peristiwa yang merugikan, seperti kegagalan zona, regional, atau multi-regional, atau serangan yang disengaja oleh pihak ketiga yang berbahaya. Compute Engine menyediakan beberapa opsi untuk melindungi data Anda. Anda dapat menggunakan fitur opsi data tersebut sebagai elemen penyusun untuk mendesain dan menerapkan proses perlindungan data Anda.

GKE

GKE membantu Anda men-deploy, mengelola, dan menskalakan workload dalam container di Kubernetes. GKE dibangun di atas Compute Engine, sehingga rekomendasi di bagian sebelumnya tentang Compute Engine sebagian berlaku untuk GKE.

Untuk meningkatkan keandalan lingkungan yang menggunakan GKE, pertimbangkan poin desain dan fitur GKE berikut:

  • Gunakan cluster GKE regional untuk meningkatkan ketersediaan. GKE mendukung berbagai jenis ketersediaan untuk cluster Anda, bergantung pada jenis cluster yang Anda butuhkan. Cluster GKE dapat memiliki bidang kontrol zona atau regional, dan dapat memiliki node yang berjalan di satu zona atau di beberapa zona dalam satu region. Jenis cluster yang berbeda juga menawarkan perjanjian tingkat layanan (SLA) yang berbeda. Untuk meningkatkan keandalan lingkungan Anda, sebaiknya pilih cluster regional.

    Jika menggunakan fitur GKE Autopilot, Anda hanya dapat menyediakan cluster regional.

  • Pertimbangkan lingkungan multi-cluster. Men-deploy beberapa cluster GKE dapat meningkatkan fleksibilitas dan properti ketersediaan lingkungan Anda, dengan biaya peningkatan kompleksitas. Misalnya, jika Anda perlu menggunakan fitur GKE baru yang hanya dapat diaktifkan saat membuat cluster GKE, Anda dapat menghindari periode nonaktif dan mengurangi kompleksitas migrasi dengan menambahkan cluster GKE baru ke lingkungan multi-cluster, men-deploy workload di cluster baru, dan menghancurkan cluster lama. Untuk mengetahui informasi selengkapnya tentang manfaat lingkungan GKE multi-cluster, lihat Kasus penggunaan multi-cluster. Untuk membantu Anda mengelola kompleksitas migrasi, Google Cloud menawarkan Pengelolaan fleet, serangkaian kemampuan untuk mengelola grup cluster GKE, infrastrukturnya, dan workload yang di-deploy di cluster tersebut.

  • Siapkan Pencadangan untuk GKE. Pencadangan untuk GKE adalah layanan regional untuk mencadangkan konfigurasi dan volume workload di cluster GKE sumber, dan memulihkannya di cluster GKE target. Untuk melindungi konfigurasi dan data workload dari kemungkinan kehilangan, sebaiknya aktifkan dan konfigurasi Pencadangan untuk GKE. Untuk mengetahui informasi selengkapnya, lihat Ringkasan Pencadangan untuk GKE.

Cloud Run

Cloud Run adalah platform komputasi terkelola untuk menjalankan workload dalam container. Cloud Run menggunakan layanan untuk menyediakan infrastruktur bagi Anda untuk menjalankan workload. Layanan Cloud Run adalah resource regional, dan layanan tersebut direplikasi di beberapa zona dalam region tempat layanan tersebut berada. Saat men-deploy layanan Cloud Run, Anda dapat memilih region. Kemudian, Cloud Run akan otomatis memilih zona di dalam region tersebut untuk men-deploy instance layanan. Cloud Run secara otomatis menyeimbangkan traffic di seluruh instance layanan, dan dirancang untuk sangat mengurangi efek gangguan zona.

VMware Engine

VMware Engine adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjalankan platform VMware di Google Cloud. Untuk meningkatkan keandalan lingkungan yang menggunakan VMware Engine, sebaiknya lakukan tindakan berikut:

  • Sediakan cloud pribadi VMware Engine multi-node. VMware Engine mendukung penyediaan stack VMware terisolasi yang disebut cloud pribadi, dan semua node yang membentuk cloud pribadi berada di region yang sama. Node cloud pribadi berjalan di node hardware bare metal khusus yang terisolasi, dan dikonfigurasi untuk menghilangkan titik tunggal kegagalan. VMware Engine mendukung cloud pribadi node tunggal, tetapi kami hanya merekomendasikan penggunaan cloud pribadi node tunggal untuk tujuan pembuktian konsep dan pengujian. Untuk lingkungan produksi, sebaiknya gunakan cloud pribadi multi-node default.
  • Sediakan cloud pribadi yang diperluas VMware Engine. Cloud pribadi yang diperluas adalah cloud pribadi multi-node yang nodenya didistribusikan di seluruh zona dalam suatu region. Private cloud yang diperluas melindungi lingkungan Anda dari gangguan per zona.

Untuk mengetahui informasi selengkapnya tentang fitur ketersediaan tinggi dan redundansi VMware Engine, lihat Ketersediaan dan redundansi.

Menyediakan dan mengonfigurasi resource penyimpanan data

Setelah menyediakan dan mengonfigurasi resource komputasi untuk lingkungan satu region, Anda menyediakan dan mengonfigurasi resource untuk menyimpan dan mengelola data. Bagian berikut menjelaskan produk penyimpanan dan pengelolaan data Google Cloud yang mendukung konfigurasi regional dan multi-regional.

Cloud Storage

Cloud Storage adalah layanan untuk menyimpan objek, yang merupakan bagian data yang tidak dapat diubah, di bucket, yang merupakan container dasar untuk menyimpan data Anda. Saat Anda membuat bucket, Anda memilih jenis lokasi bucket yang paling sesuai dengan ketersediaan, peraturan, dan persyaratan lainnya. Jenis lokasi memiliki jaminan ketersediaan yang berbeda-beda. Untuk melindungi data Anda dari kegagalan dan pemadaman layanan, Cloud Storage membuat data Anda redundan di setidaknya dua zona untuk bucket yang memiliki jenis lokasi region, di dua region untuk bucket yang memiliki jenis lokasi dual-region, dan di dua region atau lebih untuk bucket yang memiliki jenis lokasi multi-region. Misalnya, jika Anda perlu membuat bucket Cloud Storage tersedia jika terjadi pemadaman layanan zonal, Anda dapat menyediakannya dengan jenis lokasi region.

Untuk mengetahui informasi selengkapnya tentang cara merancang mekanisme pemulihan dari bencana untuk data yang disimpan di Cloud Storage, dan tentang cara Cloud Storage bereaksi terhadap pemadaman zonal dan regional, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Cloud Storage.

Filestore

Filestore menyediakan server file yang terkelola sepenuhnya di Google Cloud yang dapat dihubungkan ke instance Compute Engine, cluster GKE, dan mesin lokal Anda. Google Cloud Filestore menawarkan beberapa tingkat layanan. Setiap tingkat menawarkan ketersediaan, skalabilitas, performa, kapasitas, dan fitur pemulihan data yang unik. Saat Anda menyediakan instance Filestore, sebaiknya pilih tingkat Enterprise karena mendukung ketersediaan tinggi dan redundansi data di beberapa zona dalam satu region; instance yang berada di tingkat lainnya adalah resource zona.

Bigtable

Bigtable adalah layanan database berperforma tinggi dan berskalabilitas tinggi yang terkelola sepenuhnya untuk workload analisis dan operasional yang besar. Instance Bigtable adalah resource zonal. Untuk meningkatkan keandalan instance, Anda dapat mengonfigurasi Bigtable untuk mereplikasi data di beberapa zona dalam region yang sama atau di beberapa region.

Jika replikasi diaktifkan, jika terjadi gangguan, Bigtable akan otomatis mengalihkan permintaan ke instance lain yang tersedia tempat Anda mereplikasi data.

Untuk mengetahui informasi selengkapnya tentang cara kerja replikasi di Bigtable, lihat Tentang replikasi dan Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Bigtable.

Firestore

Firestore adalah database yang fleksibel dan skalabel untuk pengembangan seluler, web, dan server dari Firebase dan Google Cloud. Saat Anda menyediakan database Firestore, Anda memilih lokasinya. Lokasi dapat berupa multi-region atau regional, dan menawarkan jaminan keandalan yang berbeda. Jika memiliki lokasi regional, database akan mereplikasi data di berbagai zona dalam suatu region. Database multi-region mereplikasi data di lebih dari satu region.

Untuk mengetahui informasi tentang cara kerja replikasi di Firestore, dan tentang cara Firestore bereaksi terhadap pemadaman zonal dan regional, lihat Lokasi Firestore dan Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Firestore.

Memorystore

Memorystore memungkinkan Anda mengonfigurasi layanan penyimpanan data dalam memori yang skalabel, aman, dan sangat tersedia. Layanan ini mendukung backend data untuk Redis, Memcached, dan Valkey.

Saat menyediakan instance Memorystore untuk Redis, Anda memilih tingkat layanan untuk instance tersebut. Memorystore for Redis mendukung beberapa tingkat layanan instance, dan setiap tingkat menawarkan fitur ketersediaan, ukuran node, dan bandwidth yang unik. Saat Anda menyediakan instance Memorystore for Redis, sebaiknya pilih tingkat Standar atau tingkat Standar dengan replika baca. Instance Memorystore di dua tingkat tersebut secara otomatis mereplikasi data di beberapa zona dalam satu region.

Untuk mengetahui informasi selengkapnya tentang cara Memorystore for Redis mencapai ketersediaan tinggi, lihat Ketersediaan tinggi untuk Memorystore for Redis.

Saat Anda menyediakan instance Memorystore for Memcached, pertimbangkan hal berikut:

  • Pemilihan zona. Saat menyediakan instance Memorystore for Memcached, Anda memilih region tempat Anda ingin men-deploy instance. Kemudian, Anda dapat memilih zona dalam region tersebut tempat Anda ingin men-deploy node instance tersebut, atau Anda dapat membiarkan Memorystore for Memcached mendistribusikan node secara otomatis di seluruh zona. Untuk menempatkan instance secara optimal, dan untuk menghindari masalah penyediaan seperti menempatkan semua node di dalam zona yang sama, sebaiknya izinkan Memorystore untuk Memcached mendistribusikan node secara otomatis di seluruh zona dalam suatu region.
  • Replikasi data di seluruh zona. Instance Memorystore for Memcached tidak mereplikasi data di seluruh zona atau region. Untuk mengetahui informasi selengkapnya tentang cara kerja instance Memorystore for Memcached jika terjadi pemadaman layanan zonal atau regional, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Memorystore for Memcached.

Saat menyediakan instance Memorystore for Valkey, Anda memilih opsi ketersediaan dan keandalan. Memorystore for Valkey mendukung beberapa konfigurasi, seperti instance zonal dan multi-zonal. Untuk mengetahui informasi selengkapnya tentang ketersediaan dan keandalan Memorystore for Valkey, lihat Memorystore for Valkey: Ketersediaan tinggi dan replika.

Spanner

Spanner adalah database relasional terkelola sepenuhnya dengan skala tanpa batas, konsistensi kuat, dan ketersediaan hingga 99,999%. Untuk menggunakan Spanner, Anda harus menyediakan instance Spanner. Saat Anda menyediakan instance Spanner, pertimbangkan hal berikut:

  • Konfigurasi instance. Konfigurasi instance menentukan penempatan geografis dan replikasi database dalam instance Spanner. Saat membuat instance Spanner, Anda mengonfigurasinya sebagai regional atau multi-region.
  • Replikasi. Spanner mendukung replikasi otomatis tingkat byte, dan mendukung pembuatan replika sesuai dengan kebutuhan ketersediaan, keandalan, dan skalabilitas Anda. Anda dapat mendistribusikan replika di seluruh region dan lingkungan. Instance Spanner yang memiliki konfigurasi regional mempertahankan satu replika baca-tulis untuk setiap zona dalam suatu region. Instance yang memiliki konfigurasi multi-region mereplikasi data di beberapa zona di beberapa region.
  • Memindahkan instance. Spanner memungkinkan Anda memindahkan instance dari konfigurasi instance mana pun ke konfigurasi instance lainnya tanpa menyebabkan periode nonaktif atau gangguan pada jaminan transaksi selama pemindahan.

Untuk mengetahui informasi selengkapnya tentang replikasi Spanner, dan tentang cara Spanner bereaksi terhadap pemadaman layanan zonal dan regional, lihat Replikasi Spanner dan Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Spanner.

Menyediakan dan mengonfigurasi resource analisis data

Setelah menyediakan dan mengonfigurasi resource penyimpanan data untuk lingkungan satu region, Anda menyediakan dan mengonfigurasi resource analisis data. Bagian berikut menjelaskan produk analisis data Google Cloud yang mendukung konfigurasi regional.

BigQuery

BigQuery adalah data warehouse perusahaan yang terkelola sepenuhnya yang membantu Anda mengelola dan menganalisis data dengan fitur bawaan seperti machine learning, analisis geospasial, dan business intelligence.

Untuk mengatur dan mengontrol akses ke data di BigQuery, Anda menyediakan container tingkat teratas yang disebut set data. Saat Anda menyediakan set data BigQuery, pertimbangkan hal-hal berikut:

  • Lokasi set data. Untuk memilih lokasi BigQuery tempat Anda ingin menyimpan data, Anda mengonfigurasi lokasi set data. Lokasi dapat bersifat regional atau multi-region. Untuk kedua jenis lokasi tersebut, BigQuery menyimpan salinan data Anda di dua zona yang berbeda dalam lokasi yang dipilih. Anda tidak dapat mengubah lokasi set data setelah membuat set data.
  • Perencanaan menghadapi bencana. BigQuery adalah layanan regional, dan BigQuery menangani kegagalan zona secara otomatis, untuk komputasi dan data. Namun, ada skenario tertentu yang harus Anda rencanakan sendiri, seperti gangguan regional. Sebaiknya pertimbangkan skenario tersebut saat Anda mendesain lingkungan.

Untuk mengetahui informasi selengkapnya tentang perencanaan pemulihan dari bencana dan fitur BigQuery, lihat Memahami keandalan: Perencanaan pemulihan dari bencana dalam dokumentasi BigQuery, dan lihat Merancang pemulihan dari bencana untuk gangguan infrastruktur cloud: BigQuery.

Dataproc

Dataproc adalah layanan terkelola yang memungkinkan Anda memanfaatkan alat data open source untuk batch processing, pembuatan kueri, streaming, dan machine learning. Dataproc dibangun di atas Compute Engine, sehingga rekomendasi di bagian sebelumnya tentang Compute Engine sebagian berlaku juga untuk Dataproc.

Untuk menggunakan Dataproc, Anda harus membuat cluster Dataproc. Cluster Dataproc adalah resource zona. Saat Anda membuat cluster Dataproc, pertimbangkan hal berikut:

  • Penempatan zona otomatis. Saat membuat cluster, Anda dapat menentukan zona dalam region tempat Anda ingin menyediakan node cluster, atau membiarkan penempatan zona otomatis Dataproc memilih zona secara otomatis. Sebaiknya gunakan penempatan zona otomatis, kecuali jika Anda perlu menyesuaikan penempatan zona node cluster di dalam region.
  • Mode ketersediaan tinggi. Saat membuat cluster, Anda dapat mengaktifkan mode ketersediaan tinggi. Anda tidak dapat mengaktifkan mode ketersediaan tinggi setelah membuat cluster. Sebaiknya aktifkan mode ketersediaan tinggi jika Anda ingin cluster tahan terhadap kegagalan satu node koordinator, atau terhadap pemadaman layanan sebagian di zona. Cluster Dataproc dengan ketersediaan tinggi adalah resource zonal.

Untuk mengetahui informasi selengkapnya tentang cara Dataproc bereaksi terhadap pemadaman layanan zonal dan regional serta cara meningkatkan keandalan cluster Dataproc jika terjadi kegagalan, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Dataproc.

Dataflow

Dataflow adalah layanan terkelola sepenuhnya untuk menjalankan pipeline pemrosesan data batch dan streaming. Untuk menggunakan Dataflow, Anda membuat pipeline Dataflow, lalu Dataflow menjalankan tugas, yang merupakan instance dari pipeline tersebut, di node pekerja. Karena tugas adalah resource zonal, saat menggunakan resource Dataflow, Anda harus mempertimbangkan hal berikut:

  • Endpoint regional. Saat Anda membuat tugas, Dataflow mengharuskan Anda mengonfigurasi endpoint regional. Dengan mengonfigurasi endpoint regional untuk tugas, Anda membatasi penempatan resource komputasi dan data ke region tertentu.
  • Penempatan zona. Dataflow otomatis mendistribusikan node pekerja di semua zona dalam suatu region atau di zona terbaik dalam suatu region, sesuai dengan jenis tugas. Dataflow memungkinkan Anda mengganti penempatan zonal node pekerja dengan menempatkan semua node pekerja di zona yang sama dalam suatu region. Untuk memitigasi masalah yang disebabkan oleh pemadaman layanan per zona, sebaiknya Anda mengizinkan Dataflow memilih penempatan zona terbaik secara otomatis, kecuali jika Anda perlu menempatkan node pekerja di zona tertentu.

Untuk mengetahui informasi selengkapnya tentang cara Dataproc bereaksi terhadap pemadaman layanan zonal dan regional serta cara meningkatkan keandalan cluster Dataproc jika terjadi kegagalan, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Dataflow.

Pub/Sub

Pub/Sub adalah layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memproses pesan tersebut. Pub/Sub mengatur pesan dalam topik. Penerbit (layanan yang membuat pesan) mengirim pesan ke topik, dan pelanggan menerima pesan dari topik. Pub/Sub menyimpan setiap pesan di satu region, dan mereplikasinya di setidaknya dua zona dalam region tersebut. Untuk mengetahui informasi selengkapnya, lihat Ringkasan arsitektur Pub/Sub.

Saat mengonfigurasi lingkungan Pub/Sub, pertimbangkan hal-hal berikut:

  • Endpoint global dan regional. Pub/Sub mendukung endpoint global dan regional untuk memublikasikan pesan. Saat penerbit mengirim pesan ke endpoint global, Pub/Sub akan otomatis memilih region terdekat untuk memproses pesan tersebut. Saat produser mengirim pesan ke endpoint regional, Pub/Sub memproses pesan di region tersebut.
  • Kebijakan penyimpanan pesan. Pub/Sub memungkinkan Anda mengonfigurasi kebijakan penyimpanan pesan untuk membatasi tempat Pub/Sub memproses dan menyimpan pesan, terlepas dari asal permintaan dan endpoint yang digunakan penerbit untuk memublikasikan pesan. Sebaiknya konfigurasikan kebijakan penyimpanan pesan untuk memastikan pesan tidak keluar dari lingkungan satu region Anda.

Untuk mengetahui informasi selengkapnya tentang cara Pub/Sub menangani pemadaman zonal dan regional, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Pub/Sub.

Menyesuaikan workload Anda dengan lingkungan satu region

Setelah menyelesaikan penyediaan dan konfigurasi lingkungan, Anda perlu mempertimbangkan cara membuat workload lebih tangguh terhadap kegagalan zonal dan regional. Setiap beban kerja dapat memiliki persyaratan dan properti ketersediaan serta keandalannya sendiri, tetapi ada beberapa prinsip desain yang dapat Anda terapkan, dan strategi yang dapat Anda terapkan untuk meningkatkan postur ketahanan Anda secara keseluruhan jika terjadi kegagalan zona dan regional yang tidak mungkin terjadi. Saat Anda mendesain dan menerapkan workload, pertimbangkan hal berikut:

  • Menerapkan praktik dan prinsip Site Reliability Engineering (SRE). Otomatisasi dan pemantauan ekstensif adalah bagian dari prinsip inti SRE. Google Cloud menyediakan alat dan layanan profesional untuk menerapkan SRE guna meningkatkan ketahanan dan keandalan lingkungan Anda serta mengurangi toil.
  • Mendesain untuk skalabilitas dan ketahanan. Saat mendesain workload yang ditujukan untuk lingkungan cloud, sebaiknya pertimbangkan skalabilitas dan ketahanan sebagai persyaratan inheren yang harus dipatuhi oleh workload Anda. Untuk mengetahui informasi selengkapnya tentang jenis desain ini, lihat Pola untuk aplikasi yang skalabel dan tangguh.
  • Desain untuk pemulihan dari gangguan infrastruktur cloud. Jaminan ketersediaanGoogle Cloud ditetapkan oleh Google Cloud Perjanjian Tingkat Layanan. Jika terjadi kegagalan tingkat zona atau regional, sebaiknya Anda mendesain workload agar tahan terhadap kegagalan tingkat zona dan regional.
  • Terapkan pengurangan beban dan degradasi halus. Jika terjadi kegagalan infrastruktur cloud, atau kegagalan pada dependensi lain dari workload Anda, sebaiknya rancang workload Anda agar tangguh. Workload Anda harus mempertahankan tingkat fungsionalitas tertentu dan yang ditentukan dengan baik meskipun terjadi kegagalan (penurunan kualitas yang lancar) dan harus dapat mengurangi sebagian proporsi beban saat mendekati kondisi kelebihan beban (pengurangan beban).
  • Rencanakan pemeliharaan rutin. Saat mendesain proses deployment dan proses operasional, sebaiknya Anda juga memikirkan semua aktivitas yang perlu dilakukan sebagai bagian dari pemeliharaan rutin lingkungan Anda. Pemeliharaan rutin harus mencakup aktivitas seperti menerapkan update dan perubahan konfigurasi pada workload dan dependensinya, serta bagaimana aktivitas tersebut dapat memengaruhi ketersediaan lingkungan Anda. Misalnya, Anda dapat mengonfigurasi kebijakan pemeliharaan host untuk instance Compute Engine Anda.
  • Gunakan pendekatan pengembangan berbasis pengujian. Saat mendesain beban kerja, sebaiknya terapkan pendekatan pengembangan berbasis pengujian untuk memastikan beban kerja Anda berperilaku seperti yang diinginkan dari semua sudut. Misalnya, Anda dapat menguji apakah workload dan infrastruktur cloud Anda memenuhi persyaratan fungsional, non-fungsional, dan keamanan yang Anda perlukan.

Langkah berikutnya

Kontributor

Penulis: Marco Ferrari | Cloud Solutions Architect

Kontributor lainnya: