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

Last reviewed 2023-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 lingkungannya.

Dokumen ini adalah bagian dari rangkaian:

Dokumen ini bertujuan 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 sekarang menggunakan lingkungan satu region, Anda dapat bermigrasi ke lingkungan multi-region di masa mendatang. Jika Anda mempertimbangkan migrasi dan evolusi lingkungan zona dan satu region ke lingkungan multi-region, lihat Melakukan migrasi lintas region Google Cloud: Memulai.

Properti berbagai arketipe deployment

Google Cloud menyediakan layanan dari berbagai region di seluruh dunia. Setiap region adalah area geografis independen secara fisik yang terdiri dari area deployment yang disebut zona. Untuk mengetahui informasi selengkapnya tentang region dan zona Google Cloud, baca artikel Geografi dan lokasi.

Saat mendesain lingkungan Google Cloud, Anda dapat memilih antara arketipe deployment berikut, yang ditampilkan untuk meningkatkan keandalan dan overhead operasional:

  • arketipe zona: Anda menyediakan resource Google Cloud di satu zona dalam suatu region, dan menggunakan layanan zona jika tersedia. Jika layanan zona tidak tersedia, Anda dapat menggunakan layanan regional.
  • arketipe region tunggal: Anda menyediakan resource Google Cloud di beberapa zona dalam satu region, dan menggunakan layanan regional jika memungkinkan.
  • ARketipe multi-region: Anda menyediakan resource Google Cloud di beberapa zona di berbagai region. Resource zona disediakan dalam satu atau beberapa zona di setiap region.

Arketipe deployment sebelumnya memiliki properti keandalan yang berbeda, dan Anda dapat menggunakannya untuk memberikan jaminan keandalan yang diperlukan 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 arsitektur, baca Cara memanfaatkan zona dan region untuk mencapai keandalan dan panduan keandalan infrastruktur Google Cloud.

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

Tabel berikut merangkum distribusi resource, properti keandalan, dan kompleksitas setiap arketipe arsitektur. Bagian ini juga menjelaskan upaya yang diperlukan untuk merancang dan mengimplementasikan lingkungan berdasarkan masing-masing solusi.

Nama arketipe arsitektur Distribusi resource Membantu melawan Kompleksitas desain
Lingkungan zona Dalam satu zona Kegagalan resource Memerlukan koordinasi di dalam satu zona
Lingkungan satu region Di beberapa zona, di satu region Kegagalan resource, pemadaman layanan zona Memerlukan koordinasi di beberapa zona, dalam satu region
Lingkungan multi-region Di beberapa zona, di beberapa region Kegagalan resource, pemadaman layanan di zona, pemadaman layanan regional, gangguan multi-region Memerlukan koordinasi di beberapa zona, di beberapa region

Memilih arketipe deployment untuk lingkungan Anda

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

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

Menentukan model kegagalan

Untuk mendefinisikan model kegagalan, pertimbangkan pertanyaan-pertanyaan berikut:

  • Komponen lingkungan mana yang memerlukan model kegagalan? Model kegagalan dapat berlaku untuk apa pun yang Anda sediakan atau deploy di Google Cloud. Model kegagalan dapat berlaku untuk satu individu, atau Anda dapat menerapkan model kegagalan ke semua resource di seluruh zona atau region. Sebaiknya terapkan model kegagalan pada apa pun yang memberi Anda nilai, seperti workload, data, proses, dan resource Google Cloud apa pun.
  • Apa persyaratan ketersediaan tinggi, kelangsungan bisnis, dan pemulihan dari bencana (disaster recovery) untuk komponen-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 pemulihannya dari bencana. Misalnya, SLA Compute Engine menunjukkan bahwa jika Anda perlu mencapai lebih dari 99,5% waktu beroperasi bulanan, Anda perlu menyediakan instance di beberapa zona di satu region. Untuk informasi selengkapnya, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).
  • Berapa banyak model kegagalan yang perlu Anda tentukan? Dalam lingkungan 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, biasanya Anda harus mengerahkan lebih banyak upaya dan resource. Saat menentukan model kegagalan, sebaiknya pertimbangkan pendekatan yang memungkinkan Anda menentukan beberapa model kegagalan untuk setiap komponen, bukan hanya satu untuk semua komponen. Misalnya, workload bisnis yang penting biasanya harus menawarkan keandalan yang lebih tinggi, meskipun mungkin dapat diterima untuk menawarkan jaminan keandalan yang lebih rendah untuk workload lain yang kurang penting.
  • Berapa banyak resource yang diperlukan model kegagalan untuk mencegah kegagalan? Untuk melindungi dari model kegagalan yang Anda tentukan, Anda mengeluarkan resource seperti waktu dan biaya yang diperlukan orang untuk merancang, menyediakan, serta mengonfigurasi mekanisme perlindungan dan proses otomatis. Sebaiknya Anda menilai jumlah resource yang diperlukan untuk mencegah setiap model kegagalan yang Anda tentukan.
  • Bagaimana Anda mendeteksi bahwa sedang terjadi kegagalan? Dapat mendeteksi bahwa kegagalan sedang terjadi atau akan terjadi sangat penting agar Anda dapat memulai proses mitigasi, pemulihan, dan rekonsiliasi. Misalnya, Anda dapat mengonfigurasi Kemampuan Observasi Google Cloud 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 menguji setiap model guna memverifikasi bahwa model tersebut secara efektif melindungi dari kegagalan yang menjadi target model. Misalnya, Anda dapat memasukkan kesalahan di lingkungan, atau untuk menilai kemampuan lingkungan Anda dalam menoleransi kegagalan, Anda dapat mengadopsi rekayasa kekacauan.
  • 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 dari 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 Anda menentukan model kegagalan, sebaiknya Anda memperhitungkan berapa lama kegagalan dapat berlangsung. Saat mempertimbangkan berapa lama sebuah kegagalan dapat berlangsung, pertimbangkan juga berapa lama waktu yang diperlukan untuk: mengidentifikasi kegagalan, merekonsiliasi kegagalan, dan memulihkan resource yang gagal.

Untuk pertimbangan lebih lanjut tentang model kegagalan dan cara mendesain rencana pemulihan dari bencana yang andal, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.

Mengevaluasi arketipe deployment

Setelah menentukan model kegagalan yang ingin diwaspadai, Anda harus mengevaluasi arketipe deployment untuk menentukan model 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 arsitektur yang sesuai dengan semua lingkungan. Sebagai gantinya, Anda dapat menerapkan pendekatan hybrid untuk memilih beberapa arketipe deployment sesuai dengan jaminan keandalan yang Anda perlukan untuk mencegah model kegagalan yang Anda tentukan. Misalnya, jika Anda menentukan dua model kegagalan, yaitu model yang memerlukan lingkungan zona, dan model yang memerlukan lingkungan regional, sebaiknya pilih arketipe deployment terpisah untuk mencegah setiap model kegagalan. Jika Anda memilih beberapa arketipe deployment, sebaiknya Anda mengevaluasi potensi kompleksitas yang makin tinggi dalam mendesain, menerapkan, dan mengoperasikan beberapa lingkungan.
  • Berapa banyak resource yang Anda butuhkan untuk mendesain dan menerapkan lingkungan berdasarkan arketipe deployment? Merancang dan mengimplementasikan segala jenis lingkungan membutuhkan sumber daya dan upaya. Sebaiknya Anda menilai jumlah resource yang menurut Anda akan diperlukan untuk merancang dan menerapkan setiap lingkungan berdasarkan arketipe yang Anda pilih. Jika telah memahami sepenuhnya jumlah resource yang dibutuhkan, Anda dapat menyeimbangkan keseimbangan antara jaminan keandalan yang ditawarkan oleh setiap arketipe arsitektur, serta biaya dan kompleksitas desain, penerapan, dan lingkungan pengoperasian berdasarkan arketipe tersebut.
  • Apakah Anda ingin memigrasikan lingkungan berdasarkan satu arketipe arsitektur ke lingkungan berdasarkan arketipe yang berbeda? Di masa mendatang, Anda mungkin akan memigrasikan workload, data, dan proses dari satu lingkungan Google Cloud ke lingkungan Google Cloud yang berbeda. Misalnya, Anda dapat melakukan migrasi dari lingkungan zona ke lingkungan regional.
  • Seberapa penting bagi lingkungan yang Anda rancang dan terapkan? Lingkungan yang penting bagi bisnis mungkin memerlukan lebih banyak jaminan keandalan. Misalnya, Anda dapat memilih untuk mendesain dan menerapkan lingkungan multi-region untuk workload, data, dan proses yang penting bagi bisnis, serta mendesain lingkungan zona atau regional untuk beban kerja, data, dan proses yang tidak terlalu penting.
  • Apakah Anda memerlukan fitur yang ditawarkan oleh arketipe arsitektur tertentu untuk lingkungan tertentu? Selain jaminan keandalan yang ditawarkan oleh setiap arketipe arsitektur, arketipe tersebut juga menawarkan skalabilitas, kedekatan geografis, latensi, dan jaminan lokalitas data yang berbeda. Sebaiknya pertimbangkan jaminan tersebut saat Anda memilih arketipe deployment untuk lingkungan Anda.

Bersama dengan aspek teknis dari mode kegagalan yang Anda tentukan dengan mengikuti panduan sebelumnya, sebaiknya Anda mempertimbangkan 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 zona di region tersebut.

Memilih region Google Cloud 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 pemilihan ini:

  • Kriteria fungsional. Kriteria ini berkaitan dengan produk Google Cloud yang ditawarkan oleh region tertentu, dan apakah region tertentu memenuhi latensi dan kedekatan geografis Anda dengan pengguna dan lingkungan lainnya 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 harus memilih region yang paling dekat dengan pengguna atau lingkungan lain untuk meminimalkan latensi tersebut.
  • Kriteria non-fungsional. Kriteria ini berkaitan dengan harga produk yang terkait dengan wilayah tertentu, persyaratan jejak karbon, serta persyaratan dan peraturan wajib yang ada untuk bisnis Anda. Misalnya, pasar yang diatur dengan regulasi ketat seperti perbankan dan sektor publik memiliki persyaratan yang sangat ketat dan spesifik terkait lokalitas data dan beban kerja, serta caranya berbagi infrastruktur penyedia cloud dengan pelanggan lain.

Jika memilih region Google Cloud tertentu sekarang, Anda dapat bermigrasi ke region berbeda atau ke lingkungan multi-region di masa mendatang. Jika Anda mempertimbangkan migrasi mendatang ke region lain, lihat Bermigrasi di region Google Cloud: Memulai.

Mengevaluasi kriteria fungsional

Untuk mengevaluasi kriteria fungsional, pertimbangkan pertanyaan-pertanyaan berikut:

  • Apa persyaratan kedekatan geografis Anda? Saat memilih region Google Cloud, Anda mungkin perlu menempatkan workload, data, dan proses di dekat pengguna atau lingkungan di luar Google Cloud, seperti lingkungan lokal. Misalnya, jika Anda menarget basis pengguna yang terpusat di area geografis tertentu, sebaiknya pilih region Google Cloud yang paling dekat dengan area geografis tersebut. Dengan memilih region Google Cloud yang paling sesuai dengan persyaratan kedekatan geografis Anda, lingkungan Anda dapat menjamin latensi yang lebih rendah dan waktu reaksi yang lebih rendah terhadap permintaan dari pengguna dan dari lingkungan Anda di luar Google Cloud. Alat seperti dasbor latensi Google Cloud, dan alat tidak resmi seperti GCPing dan Alat Pilih Region Google Cloud dapat memberi Anda gambaran umum tentang karakteristik latensi region Google Cloud. Namun, sebaiknya lakukan penilaian komprehensif untuk mengevaluasi apakah properti latensi sesuai dengan persyaratan, workload, data, dan proses Anda.
  • Wilayah mana yang ingin Anda gunakan menawarkan produk yang Anda butuhkan? Sebaiknya Anda menilai produk yang tersedia di setiap region Google Cloud, dan region mana yang menyediakan layanan yang Anda perlukan untuk merancang dan menerapkan lingkungan Anda. 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 region Google Cloud tertentu. Untuk mengetahui informasi selengkapnya tentang fitur yang ditawarkan setiap produk di setiap wilayah, lihat dokumentasi produk.
  • Apakah resource yang Anda perlukan di setiap region Google Cloud 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 kuota lainnya bersifat regional atau zona dan berlaku untuk penggunaan resource oleh Anda 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 meningkatkannya, lihat Bekerja dengan kuota.

Mengevaluasi kriteria non-fungsional

Untuk mengevaluasi kriteria non-fungsional, pertimbangkan pertanyaan-pertanyaan berikut:

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

Desain dan bangun 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. Menyediakan dan mengonfigurasi resource penyimpanan data.
  4. Menyediakan dan mengonfigurasi resource analisis data.

Saat mendesain lingkungan, pertimbangkan prinsip-prinsip desain umum berikut:

  • Menyediakan resource regional. Banyak produk Google Cloud mendukung penyediaan resource di beberapa zona di seluruh region. Sebaiknya Anda menyediakan resource regional, bukan resource zona jika memungkinkan. Secara teoritis, Anda mungkin dapat menyediakan resource zona di beberapa zona di seluruh region dan mengelolanya sendiri untuk mendapatkan keandalan yang lebih tinggi. Namun, konfigurasi tersebut tidak akan sepenuhnya mendapatkan manfaat dari semua fitur keandalan infrastruktur Google yang mendasari layanan Google Cloud.
  • Memverifikasi 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 atau tidak untuk mencegah model kegagalan yang Anda pertimbangkan, sebelum mempromosikan lingkungan tersebut sebagai bagian dari lingkungan produksi. Misalnya, Anda dapat menyimulasikan pemadaman layanan zona untuk memverifikasi bahwa lingkungan satu region Anda dapat bertahan dengan sedikit gangguan.

Untuk mengetahui prinsip desain yang lebih umum tentang mendesain lingkungan satu dan multi-region yang andal serta untuk mengetahui 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 dengan region tunggal, lihat Migrasi ke Google Cloud: Membangun fondasi Anda. Panduan dalam dokumen tersebut ditujukan untuk membangun fondasi bagi migrasi beban kerja, data, dan proses ke Google Cloud. Selain itu, panduan ini juga dapat digunakan untuk membangun fondasi bagi lingkungan satu region. Setelah Anda membaca dokumen tersebut, lanjutkan membaca dokumen ini.

Setelah membangun fondasi di Google Cloud, Anda akan mendesain dan menerapkan batas dan kontrol keamanan. Langkah-langkah keamanan tersebut membantu memastikan bahwa beban kerja, data, dan proses Anda tetap berada di dalam region masing-masing. Tindakan keamanan 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 satu region, Anda harus menyediakan dan mengonfigurasi resource komputasi. Bagian berikut ini menjelaskan produk komputasi Google Cloud yang mendukung deployment regional.

Compute Engine

Compute Engine adalah Infrastructure as a Service (IaaS) Google Cloud. Smart Bidding menggunakan infrastruktur Google yang mencakup seluruh dunia untuk menawarkan virtual machine dan layanan terkait kepada pelanggan.

Resource Compute Engine dapat berdasarkan zona, 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.

Guna memberikan fleksibilitas dan pengelolaan resource yang lebih baik untuk resource fisik, Compute Engine memisahkan zona dari resource fisiknya. Untuk mengetahui informasi selengkapnya tentang abstraksi ini dan apa yang dapat diartikannya bagi Anda, lihat Zona dan cluster.

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

  • Grup instance terkelola regional (MIG). Virtual machine Compute Engine adalah resource zona, sehingga tidak akan tersedia saat terjadi pemadaman layanan di zona tertentu. Untuk mengurangi masalah ini, Compute Engine memungkinkan Anda membuat MIG regional yang menyediakan virtual machine di beberapa zona di suatu region secara otomatis, sesuai dengan permintaan dan ketersediaan regional. Jika workload bersifat stateful, Anda juga dapat membuat MIG stateful regional untuk mempertahankan data dan konfigurasi stateful. MIG regional mendukung simulasi kegagalan zona. Untuk mengetahui informasi tentang cara menyimulasikan kegagalan zona saat menggunakan MIG regional, lihat Menyimulasikan pemadaman 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 virtual machine sesuai dengan bentuk distribusi target. Untuk memastikan distribusi virtual machine tidak berbeda lebih dari satu unit antara dua zona di suatu region, sebaiknya pilih bentuk distribusi EVEN saat Anda membuat MIG regional. Untuk informasi tentang perbedaan antara bentuk distribusi target, lihat Perbandingan bentuk.
  • Template instance. Untuk menentukan virtual machine yang akan disediakan, MIG menggunakan jenis resource global yang disebut template instance. Meskipun merupakan resource global, template instance dapat mereferensikan resource zona atau regional. Saat Anda membuat template instance, sebaiknya Anda mereferensikan resource regional daripada resource zona jika memungkinkan. Jika Anda menggunakan resource zona, 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 tersebut.
  • Mengonfigurasi load balancing dan penskalaan. Compute Engine mendukung traffic load balancing antara instance Compute Engine, dan mendukung penskalaan otomatis untuk otomatis menambahkan atau menghapus virtual machine dari MIG, sesuai dengan permintaan. Untuk meningkatkan keandalan dan fleksibilitas lingkungan Anda, serta untuk menghindari beban pengelolaan solusi yang dikelola sendiri, sebaiknya konfigurasikan 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 membutuhkannya, sebaiknya Anda mengonfigurasi pencadangan resource untuk memberikan jaminan dalam memperoleh kapasitas resource Compute Engine menurut zona. Misalnya, jika terjadi pemadaman layanan di zona tertentu, Anda mungkin perlu menyediakan virtual machine di zona lain untuk menyediakan kapasitas yang diperlukan untuk mengompensasi kapasitas yang tidak tersedia akibat pemadaman layanan. Reservasi resource memastikan bahwa Anda memiliki resource yang tersedia untuk menyediakan virtual machine tambahan.
  • Gunakan nama DNS zona. Untuk mengurangi risiko pemadaman layanan lintas regional, sebaiknya gunakan nama DNS zona untuk mengidentifikasi virtual machine yang menggunakan nama DNS di lingkungan Anda secara unik. Google Cloud menggunakan nama DNS zona untuk virtual machine Compute Engine secara default. Untuk mengetahui informasi selengkapnya tentang cara kerja DNS internal Compute Engine, lihat DNS Internal. Untuk memfasilitasi migrasi mendatang lintas region, dan membuat konfigurasi Anda lebih mudah dikelola, sebaiknya pertimbangkan nama DNS zona sebagai parameter konfigurasi yang nantinya dapat Anda ubah di 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 berupa zona atau regional. Persistent disk zona menyimpan data dalam satu zona, sementara persistent disk regional mereplikasi data di dua zona yang berbeda. Saat memilih opsi penyimpanan untuk lingkungan region tunggal, sebaiknya pilih persistent disk regional karena persistent disk menyediakan opsi failover jika terjadi kegagalan zona. 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 cocok untuk menyimpan data sementara, cache, dan data yang dapat Anda buat ulang dengan cara lain. {i>Persistent disk<i} adalah perangkat penyimpanan tahan lama yang dapat diakses mesin virtual seperti {i>disk<i} fisik.
  • Rancang dan implementasikan mekanisme untuk perlindungan data. Saat mendesain lingkungan dengan satu region, sebaiknya Anda menerapkan mekanisme otomatis untuk melindungi data jika terdapat peristiwa 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 mengimplementasikan proses perlindungan data.

GKE

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

Untuk meningkatkan keandalan lingkungan yang menggunakan GKE, pertimbangkan titik 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, serta dapat memiliki node yang berjalan di satu zona atau di beberapa zona dalam suatu region. Berbagai jenis cluster 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, tetapi akan meningkatkan kompleksitas. Misalnya, jika 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 Anda, men-deploy workload di cluster baru, dan menghancurkan cluster lama. Untuk mengetahui informasi selengkapnya tentang manfaat lingkungan GKE multi-cluster, lihat Memigrasikan container ke Google Cloud: Bermigrasi ke lingkungan GKE multi-cluster. Untuk membantu Anda mengelola kompleksitas migrasi, Google Cloud menawarkan Pengelolaan perangkat, 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 beban kerja di cluster GKE sumber, dan memulihkannya dalam cluster GKE target. Untuk melindungi konfigurasi workload dan data dari kemungkinan kerugian, 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 guna menyediakan infrastruktur untuk menjalankan workload Anda. Layanan Cloud Run adalah resource regional, dan layanan direplikasi ke beberapa zona di region tempatnya berada. Saat men-deploy layanan Cloud Run, Anda dapat memilih region. Selanjutnya, Cloud Run secara 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 mengurangi efek pemadaman layanan di zona secara signifikan.

VMware Engine

VMware Engine adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjalankan platform VMware di Google Cloud. Untuk meningkatkan keandalan lingkungan Anda yang menggunakan VMware Engine, kami merekomendasikan hal berikut:

  • Sediakan cloud pribadi VMware Engine multi-node. VMware Engine mendukung penyediaan stack VMware terisolasi yang disebut cloud pribadi, dan semua node yang menyusun cloud pribadi berada di region yang sama. Node cloud pribadi berjalan pada node hardware bare-metal khusus yang terisolasi, dan dikonfigurasi untuk menghilangkan titik tunggal kegagalan. VMware Engine mendukung cloud pribadi node tunggal, tetapi sebaiknya gunakan cloud pribadi node tunggal sebagai bukti konsep dan tujuan pengujian. Untuk lingkungan produksi, sebaiknya gunakan cloud pribadi multi-node default.
  • Menyediakan cloud pribadi VMware Engine yang diperluas. Cloud pribadi yang direntangkan adalah cloud pribadi multi-node yang node-nya didistribusikan di seluruh zona dalam suatu region. Private cloud yang diperluas melindungi lingkungan Anda dari pemadaman zona.

Untuk informasi lebih lanjut 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 region tunggal, Anda perlu menyediakan dan mengonfigurasi resource untuk menyimpan dan mengelola data. Bagian berikut menjelaskan tentang produk pengelolaan dan penyimpanan 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, dalam bucket, yang merupakan penampung dasar untuk menyimpan data Anda. Saat membuat bucket, Anda memilih jenis lokasi bucket yang paling memenuhi ketersediaan, peraturan, dan persyaratan lainnya. Jenis lokasi memiliki jaminan ketersediaan yang berbeda. 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 menyediakan bucket Cloud Storage saat terjadi pemadaman layanan zona, Anda dapat menyediakannya dengan jenis lokasi region.

Untuk mengetahui informasi selengkapnya tentang cara merancang mekanisme bencana untuk data yang disimpan di Cloud Storage, serta reaksi Cloud Storage terhadap pemadaman layanan zona 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 terhubung ke instance Compute Engine, cluster GKE, dan mesin lokal Anda. Filestore menawarkan beberapa tingkat layanan. Setiap tingkat menawarkan fitur ketersediaan, skalabilitas, performa, kapasitas, dan 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 ada di tingkat lain adalah resource zona.

Bigtable

Bigtable adalah layanan database yang terkelola sepenuhnya, berperforma tinggi, dan skalabel tinggi untuk beban kerja analisis dan operasional yang besar. Instance Bigtable adalah resource zona. Untuk meningkatkan keandalan instance, Anda dapat mengonfigurasi Bigtable untuk mereplikasi data di beberapa zona dalam region yang sama atau di beberapa region. Saat replikasi diaktifkan, dan jika ada gangguan, Bigtable akan menggagalkan permintaan secara otomatis 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 di Firebase serta Google Cloud. Saat 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 satu region. Database multi-region mereplikasi data di lebih dari satu region.

Untuk mengetahui informasi tentang cara kerja replikasi di Firestore, dan reaksi Firestore terhadap pemadaman layanan zona 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. Alat ini mendukung backend data untuk Redis dan Memcached.

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 ketersediaan, ukuran node, dan fitur bandwidth yang unik. Saat menyediakan instance Memorystore for Redis, sebaiknya Anda memilih 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 untuk Redis mencapai ketersediaan tinggi, lihat Ketersediaan tinggi untuk Memorystore for Redis.

Saat Anda menyediakan Memorystore untuk instance Memcached, pertimbangkan hal-hal berikut:

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

Spanner

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

  • Konfigurasi instance. Konfigurasi instance menentukan penempatan geografis dan replikasi database di instance Spanner. Saat membuat instance Spanner, Anda dapat mengonfigurasinya sebagai regional atau multi-region.
  • Replikasi. Spanner mendukung replikasi otomatis tingkat byte, dan mendukung pembuatan replicas sesuai dengan kebutuhan ketersediaan, keandalan, dan skalabilitas Anda. Anda dapat mendistribusikan replika di berbagai 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 apa pun ke konfigurasi instance lainnya tanpa menyebabkan periode nonaktif, atau gangguan pada jaminan transaksi selama pemindahan.

Untuk mengetahui informasi selengkapnya tentang replikasi Spanner, serta reaksi Spanner terhadap pemadaman layanan zona 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 region tunggal, Anda perlu 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 untuk 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 harus menyediakan penampung level teratas yang disebut set data. Saat menyediakan set data BigQuery, pertimbangkan hal berikut:

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

Untuk mengetahui informasi selengkapnya tentang perencanaan dan fitur pemulihan dari bencana BigQuery, lihat Memahami keandalan: Perencanaan bencana dalam dokumentasi BigQuery, dan lihat Merancang pemulihan dari bencana untuk pemadaman 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 dibuat berdasarkan Compute Engine, sehingga rekomendasi di bagian sebelumnya tentang Compute Engine juga berlaku sebagian untuk Dataproc.

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

  • Penempatan zona otomatis. Saat membuat cluster, Anda dapat menentukan zona dalam region tempat Anda ingin menyediakan node cluster, atau mengizinkan 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 perlu cluster agar tahan terhadap kegagalan node koordinator tunggal, atau pemadaman zona parsial. Cluster Dataproc ketersediaan tinggi merupakan resource zona.

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

Dataflow

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

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

Untuk mengetahui informasi selengkapnya tentang reaksi Dataproc terhadap pemadaman layanan zona dan regional serta cara meningkatkan keandalan cluster Dataproc Anda 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 menghasilkan 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 berikut:

  • Endpoint global dan regional. Pub/Sub mendukung endpoint global dan regional untuk memublikasikan pesan. Saat penerbit mengirim pesan ke endpoint global, Pub/Sub secara otomatis memilih region terdekat untuk memproses pesan tersebut. Saat produser mengirim pesan ke endpoint regional, Pub/Sub akan 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 penayang 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 gangguan zona dan regional, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Pub/Sub.

Menyesuaikan workload Anda dengan lingkungan region tunggal

Saat menyelesaikan penyediaan dan konfigurasi lingkungan, Anda harus mempertimbangkan cara membuat workload lebih tahan terhadap kegagalan zona dan regional. Setiap workload dapat memiliki persyaratan serta properti ketersediaan dan keandalannya sendiri, tetapi ada beberapa prinsip desain yang dapat Anda terapkan dan strategi yang dapat diterapkan untuk meningkatkan postur ketahanan keseluruhan Anda jika terjadi kegagalan zona dan regional. Saat Anda mendesain dan mengimplementasikan workload, pertimbangkan hal-hal berikut:

  • Menerapkan praktik dan prinsip Site Reliability Engineering (SRE). Otomatisasi dan pemantauan ekstensif merupakan 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.
  • Buat desain untuk skalabilitas dan ketahanan. Saat Anda mendesain workload yang ditujukan untuk lingkungan cloud, sebaiknya pertimbangkan skalabilitas dan ketahanan sebagai persyaratan inheren yang harus dipenuhi workload Anda. Untuk mengetahui informasi selengkapnya tentang desain semacam ini, lihat Pola untuk aplikasi yang skalabel dan tangguh.
  • Desain untuk pemulihan dari pemadaman infrastruktur cloud. Jaminan ketersediaan Google Cloud ditentukan dalam Perjanjian Tingkat Layanan Google Cloud. Jika terjadi kegagalan zona atau regional, sebaiknya desain workload Anda agar tahan terhadap kegagalan zona dan regional.
  • Terapkan pelepasan beban dan degradasi halus. Jika ada kegagalan infrastruktur cloud, atau kegagalan dalam dependensi lain dari workload Anda, sebaiknya desain workload Anda agar tangguh. Beban kerja Anda harus mempertahankan tingkat fungsi tertentu yang ditentukan dengan baik meskipun terjadi kegagalan (degradasi halus) dan harus dapat menurunkan beberapa proporsi bebannya saat mendekati kondisi kelebihan beban (pelepasan beban).
  • Rencanakan pemeliharaan rutin. Saat mendesain proses deployment dan proses operasional, sebaiknya pertimbangkan juga 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.
  • Gunakan pendekatan pengembangan berbasis pengujian. Saat mendesain workload, sebaiknya gunakan pendekatan pengembangan berbasis pengujian untuk memastikan beban kerja Anda berfungsi sebagaimana mestinya dari semua sudut. Misalnya, Anda dapat menguji apakah workload dan infrastruktur cloud Anda memenuhi persyaratan fungsional, non-fungsional, dan keamanan yang Anda perlukan.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, login ke LinkedIn.