Bermigrasi di berbagai 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 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 mendesain dan menerapkan lingkungan satu region. Jika saat ini Anda menggunakan lingkungan satu region, di masa mendatang, Anda dapat bermigrasi ke lingkungan multi-region. Jika Anda mempertimbangkan migrasi dan evolusi lingkungan zonal dan satu region Anda ke lingkungan multi-region pada masa mendatang, lihat Bermigrasi di berbagai region Google Cloud: Memulai.

Properti berbagai jenis arsitektur deployment

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

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

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

Archetype deployment sebelumnya memiliki properti keandalan yang berbeda, dan Anda dapat menggunakannya untuk memberikan jaminan keandalan yang diperlukan lingkungan Anda. Misalnya, lingkungan multi-region lebih cenderung bertahan dari pemadaman layanan regional dibandingkan dengan lingkungan satu region atau zona. Untuk informasi selengkapnya tentang properti keandalan setiap arketipe arsitektur, lihat 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 dirancang, diterapkan, dan dioperasikan dibandingkan dengan lingkungan regional atau multi-region. Upaya dan biaya yang berpotensi lebih rendah dari lingkungan zonal disebabkan oleh overhead tambahan yang harus Anda kelola untuk mengoordinasikan beban kerja, data, dan proses yang berada di berbagai region.

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

Nama arketipe arsitektur 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, pemadaman 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

Memilih jenis arsitektur deployment untuk lingkungan Anda

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

  1. Tentukan model kegagalan yang ingin Anda lindungi.
  2. Evaluasi arketipe deployment untuk menentukan mana 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 ke apa pun yang Anda sediakan atau deploy di Google Cloud. Model kegagalan dapat diterapkan ke individu, atau Anda dapat menerapkan model kegagalan ke semua resource di seluruh zona atau region. Sebaiknya terapkan model kegagalan ke apa pun yang memberikan nilai kepada Anda, seperti workload, data, proses, dan resource Google Cloud apa pun.
  • Apa persyaratan ketersediaan tinggi, kelangsungan bisnis, dan pemulihan dari bencana (disaster recovery) 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 disaster recovery-nya sendiri. Misalnya, SLA Compute Engine menunjukkan bahwa jika Anda perlu mencapai waktu aktif bulanan lebih dari 99,5%, Anda perlu menyediakan instance di beberapa zona di satu region. Untuk informasi selengkapnya, lihat Panduan perencanaan pemulihan dari bencana.
  • Berapa banyak model kegagalan yang perlu Anda tentukan? Dalam lingkungan biasa, tidak semua komponen harus memberikan jaminan keandalan yang sama. Jika menawarkan jaminan waktu beroperasi yang lebih tinggi dan ketahanan yang lebih baik, Anda biasanya harus mengeluarkan lebih banyak upaya dan resource. Saat menentukan model kegagalan, sebaiknya pertimbangkan pendekatan yang menentukan beberapa model kegagalan untuk setiap komponen, bukan hanya satu untuk semua komponen. Misalnya, beban kerja yang 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 diperlukan model kegagalan untuk mencegah kegagalan? Untuk mencegah model kegagalan yang Anda tentukan, Anda akan menghabiskan resource seperti waktu dan biaya yang diperlukan orang untuk mendesain, menyediakan, dan mengonfigurasi mekanisme perlindungan dan proses otomatis. Sebaiknya Anda menilai jumlah resource yang diperlukan untuk melindungi dari setiap model kegagalan yang Anda tentukan.
  • Bagaimana cara Anda mendeteksi bahwa kegagalan terjadi? Kemampuan untuk mendeteksi bahwa kegagalan sedang terjadi atau akan terjadi sangatlah penting sehingga 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 menentukan model kegagalan, sebaiknya pikirkan cara terus menguji setiap model untuk memverifikasi bahwa model tersebut secara efektif melindungi dari kegagalan yang menjadi sasaran model. Misalnya, Anda dapat memasukkan error di lingkungan, atau untuk menilai kemampuan lingkungan Anda dalam mentoleransi kegagalan, Anda dapat mengadopsi chaos engineering.
  • Berapa besar dampak yang Anda harapkan jika model kegagalan tertentu terjadi? Untuk mendapatkan pemahaman tentang dampak kegagalan terhadap bisnis Anda, sebaiknya, untuk setiap model kegagalan, Anda memperkirakan konsekuensi dari setiap kegagalan yang dirancang model. Pemahaman ini berguna dalam menetapkan prioritas dan urutan pemulihan sehingga Anda dan proses Anda menangani komponen yang paling penting terlebih dahulu.
  • Berapa lama Anda memperkirakan kegagalan akan berlangsung dalam model kegagalan yang Anda tentukan? Durasi kegagalan dapat sangat memengaruhi rencana mitigasi dan pemulihan. Oleh karena itu, saat menentukan model kegagalan, sebaiknya pertimbangkan berapa lama kegagalan dapat berlangsung. Saat Anda mempertimbangkan berapa lama kegagalan dapat berlangsung, pertimbangkan juga berapa lama waktu yang diperlukan untuk: mengidentifikasi kegagalan, merekonsiliasi kegagalan, dan memulihkan resource yang gagal.

Untuk pertimbangan selengkapnya tentang model kegagalan dan cara mendesain 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 lindungi, Anda akan 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 untuk menyesuaikan semua lingkungan Anda. Sebagai gantinya, Anda dapat menerapkan pendekatan campuran dengan memilih beberapa arketipe deployment sesuai dengan jaminan keandalan yang diperlukan untuk mencegah model kegagalan yang Anda tentukan. Misalnya, jika Anda menentukan dua model kegagalan—satu yang memerlukan lingkungan zona, dan satu lagi yang memerlukan lingkungan regional—Anda dapat 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 perlukan untuk mendesain dan menerapkan lingkungan berdasarkan arketipe deployment? Mendesain dan menerapkan berbagai jenis lingkungan memerlukan resource dan upaya. Sebaiknya Anda menilai jumlah resource yang menurut Anda diperlukan untuk mendesain dan menerapkan setiap lingkungan berdasarkan arketipe yang Anda pilih. Jika memiliki pemahaman lengkap tentang jumlah resource yang diperlukan, Anda dapat menyeimbangkan kompromi antara jaminan keandalan yang ditawarkan setiap arketipe arsitektur, serta biaya dan kompleksitas dalam mendesain, menerapkan, dan mengoperasikan lingkungan berdasarkan arketipe tersebut.
  • Apakah Anda ingin memigrasikan lingkungan berdasarkan satu arketipe arsitektur ke lingkungan berdasarkan arketipe yang berbeda? Di masa mendatang, Anda mungkin memigrasikan workload, data, dan proses dari satu lingkungan Google Cloud ke lingkungan Google Cloud yang berbeda. 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 besar. 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 arsitektur tertentu untuk lingkungan tertentu? Selain jaminan keandalan yang ditawarkan oleh setiap arketipe arsitektur, arketipe 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 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 bagi 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 wilayah 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 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 terdekat dengan pengguna atau lingkungan lain untuk meminimalkan latensi tersebut.
  • Kriteria non-fungsional. Kriteria ini berkaitan dengan harga produk yang dikaitkan dengan wilayah tertentu, persyaratan jejak karbon, serta persyaratan dan peraturan wajib yang berlaku untuk bisnis Anda. Misalnya, pasar yang diatur dengan ketat seperti perbankan dan sektor publik memiliki persyaratan yang sangat ketat dan spesifik tentang lokalitas data dan beban kerja, serta cara mereka berbagi infrastruktur penyedia cloud dengan pelanggan lain.

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

Mengevaluasi kriteria fungsional

Untuk mengevaluasi kriteria fungsional, pertimbangkan pertanyaan berikut:

  • Apa persyaratan kedekatan geografis Anda? Saat memilih wilayah Google Cloud, Anda mungkin perlu menempatkan beban kerja, data, dan proses di dekat pengguna atau lingkungan Anda di luar Google Cloud, seperti lingkungan lokal. Misalnya, jika Anda menargetkan basis pengguna yang terkonsentrasi di area geografis tertentu, sebaiknya pilih region Google Cloud yang paling dekat dengan area geografis tersebut. Memilih region Google Cloud yang paling sesuai dengan persyaratan kedekatan geografis Anda memungkinkan lingkungan Anda 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 serta Pemilih Region Google Cloud dapat memberi Anda gambaran umum tentang karakteristik latensi region Google Cloud. Namun, sebaiknya Anda melakukan penilaian menyeluruh untuk mengevaluasi apakah properti latensi sesuai dengan persyaratan, beban kerja, data, dan proses Anda.
  • Manakah dari region yang ingin Anda gunakan yang 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 mendesain dan menerapkan lingkungan. 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 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, sedangkan kuota lainnya 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 meningkatkannya, lihat Mengelola kuota.

Mengevaluasi kriteria non-fungsional

Untuk mengevaluasi kriteria non-fungsional, pertimbangkan pertanyaan berikut:

  • Apakah Anda lebih memilih jejak karbon yang rendah? Google Cloud terus berinvestasi dalam keberlanjutan dan energi bebas karbon untuk region Google Cloud, dan berkomitmen untuk menggunakan 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 menyertakan energi bebas karbon dalam strategi lokasi Anda, lihat Energi bebas karbon untuk region Google Cloud.
  • Apakah lingkungan Anda harus memenuhi peraturan tertentu? Pemerintah dan entitas nasional dan supranasional sering kali mengatur pasar dan area bisnis tertentu dengan ketat, seperti perbankan dan sektor publik. Peraturan ini mungkin mewajibkan agar beban kerja, 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 sensitif dan beban kerja yang berjalan di cloud. Sebaiknya Anda menilai persyaratan peraturan saat ini dan mendatang saat memilih region Google Cloud untuk lingkungan Anda, dan pilih region Google Cloud yang paling sesuai dengan persyaratan peraturan Anda.

Mendesain dan mem-build lingkungan satu region

Untuk mendesain lingkungan satu region, lakukan hal berikut:

  1. Membangun 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 desain umum berikut:

  • Menyediakan referensi 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 zonaonal 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 layanan Google Cloud.
  • Verifikasi bahwa lingkungan berfungsi seperti yang diharapkan dengan asumsi model kegagalan. Saat mendesain dan menerapkan lingkungan satu wilayah, sebaiknya verifikasi apakah lingkungan tersebut memenuhi persyaratan untuk mencegah 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 prinsip desain yang lebih umum dalam mendesain lingkungan satu dan multi-region yang andal serta informasi tentang cara Google mencapai keandalan yang lebih baik dengan layanan regional dan multi-region, lihat Mendesain disaster recovery untuk pemadaman layanan infrastruktur cloud: Tema umum.

Membangun fondasi Anda di Google Cloud

Untuk membangun fondasi lingkungan satu region, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda. Panduan dalam dokumen tersebut bertujuan untuk membangun fondasi guna 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 akan mendesain dan menerapkan kontrol dan batasan keamanan. Langkah-langkah keamanan tersebut membantu memastikan bahwa workload, data, dan proses Anda tetap berada di dalam region masing-masing. Langkah-langkah keamanan 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 harus menyediakan dan mengonfigurasi resource komputasi. Bagian berikut menjelaskan produk komputasi Google Cloud yang mendukung deployment regional.

Compute Engine

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

Resource Compute Engine bersifat zonal, seperti virtual machine atau Persistent Disk zonal; 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 yang lebih baik terhadap resource fisik, Compute Engine memisahkan zona dari resource fisiknya. Untuk informasi selengkapnya tentang abstraksi ini dan dampaknya bagi Anda, lihat Zona dan cluster.

Untuk meningkatkan keandalan lingkungan Anda 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 mengurangi masalah ini, Compute Engine memungkinkan Anda membuat MIG regional yang menyediakan virtual machine di beberapa zona dalam satu region secara otomatis, sesuai dengan permintaan dan ketersediaan regional. Jika beban kerja Anda bersifat stateful, Anda juga dapat membuat MIG stateful regional untuk mempertahankan data dan konfigurasi stateful. MIG regional mendukung simulasi kegagalan zona. Untuk 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 virtual machine sesuai dengan bentuk distribusi target. Untuk memastikan bahwa distribusi virtual machine tidak berbeda lebih dari satu unit antara dua zona dalam suatu region, sebaiknya pilih bentuk distribusi EVEN saat 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 template instance adalah resource global, template tersebut dapat mereferensikan resource zona atau regional. Saat membuat template instance, sebaiknya Anda mereferensikan resource regional daripada resource zona jika memungkinkan. Jika Anda menggunakan resource zona, sebaiknya Anda menilai dampak penggunaannya. 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.
  • Mengonfigurasi load balancing dan penskalaan. Compute Engine mendukung traffic load balancing di antara instance Compute Engine, dan mendukung penskalaan otomatis untuk secara otomatis menambahkan atau menghapus virtual machine dari MIG, sesuai permintaan. Untuk meningkatkan keandalan dan fleksibilitas lingkungan Anda, serta menghindari beban pengelolaan solusi mandiri, sebaiknya konfigurasikan load balancing dan penskalaan otomatis. Untuk 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 reservasi resource untuk memberikan jaminan dalam mendapatkan kapasitas untuk resource Compute Engine zona. Misalnya, jika terjadi pemadaman layanan zona, Anda mungkin perlu menyediakan virtual machine di zona lain untuk menyediakan kapasitas yang diperlukan guna mengganti virtual machine 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 pemadaman layanan lintas wilayah, 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 VM Compute Engine secara default. Untuk mengetahui informasi selengkapnya tentang cara kerja DNS internal Compute Engine, lihat DNS Internal. Untuk memfasilitasi migrasi di masa mendatang di seluruh wilayah, dan agar konfigurasi Anda lebih mudah dikelola, sebaiknya pertimbangkan nama DNS zonal sebagai parameter konfigurasi yang pada akhirnya 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 volume tersebut ditempatkan secara terpisah dari virtual machine Anda. Persistent disk dapat bersifat zonal atau regional. Persistent disk zona menyimpan data dalam satu zona, sedangkan persistent disk regional mereplikasi data di dua zona yang berbeda. Saat memilih opsi penyimpanan untuk lingkungan satu region, sebaiknya pilih persistent disk regional karena menyediakan 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 yang tahan lama dan dapat diakses virtual machine seperti disk fisik.
  • Buat desain dan terapkan mekanisme untuk perlindungan data. Saat mendesain lingkungan satu region, sebaiknya terapkan 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.

GKE

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

Untuk meningkatkan keandalan lingkungan Anda 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 perlukan. 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, 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 mengorbankan peningkatan 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, 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 sekelompok cluster GKE, infrastrukturnya, dan beban kerja 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, serta memulihkannya di cluster GKE target. Untuk melindungi konfigurasi dan data workload dari kemungkinan kehilangan, sebaiknya aktifkan dan konfigurasikan 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 memberi Anda infrastruktur guna menjalankan workload. Layanan Cloud Run adalah resource regional, dan layanan tersebut direplikasi di beberapa zona di 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 pemadaman zona.

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, sebaiknya lakukan tindakan berikut:

  • Menyediakan 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 di node hardware bare metal khusus dan terisolasi, dan dikonfigurasi untuk menghilangkan titik tunggal kegagalan. VMware Engine mendukung cloud pribadi satu node, tetapi kami hanya merekomendasikan penggunaan cloud pribadi satu node untuk tujuan uji coba dan pengujian. Untuk lingkungan produksi, sebaiknya gunakan cloud pribadi multi-node default.
  • Menyediakan cloud pribadi yang diperluas VMware Engine. Cloud pribadi yang diperluas adalah cloud pribadi multi-node yang node-nya didistribusikan di seluruh zona dalam suatu region. Cloud pribadi yang diperluas melindungi lingkungan Anda dari penghentian zona.

Untuk 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 akan 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, dalam bucket, yang merupakan penampung dasar untuk menyimpan data Anda. Saat membuat bucket, Anda memilih jenis lokasi bucket yang paling sesuai dengan persyaratan ketersediaan, peraturan, dan 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 jika terjadi pemadaman layanan zonal, Anda dapat menyediakannya dengan jenis lokasi region.

Untuk mengetahui informasi selengkapnya tentang cara mendesain mekanisme penanggulangan 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 on-premise Anda. Filestore menawarkan beberapa paket layanan. Setiap tingkat menawarkan ketersediaan, skalabilitas, performa, kapasitas, dan fitur pemulihan data yang unik. Saat 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 lain adalah resource zona.

Bigtable

Bigtable adalah layanan database berperforma tinggi, skalabel, dan 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 penghentian layanan, Bigtable akan otomatis menolak 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 di Firebase serta Google Cloud. Saat menyediakan database Firestore, Anda memilih lokasinya. Lokasi dapat bersifat 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 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 dan Memcached.

Saat menyediakan instance Memorystore for 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 kedua 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:

  • Pilihan zona. Saat menyediakan instance Memorystore for Memcached, Anda memilih region tempat Anda ingin men-deploy instance. Kemudian, Anda dapat memilih zona dalam region tempat Anda ingin men-deploy node instance tersebut, atau Anda dapat mengizinkan Memorystore untuk Memcached mendistribusikan node secara otomatis di seluruh zona. Untuk menempatkan instance secara optimal, dan menghindari masalah penyediaan seperti menempatkan semua node di dalam zona yang sama, sebaiknya Anda mengizinkan Memorystore untuk Memcached mendistribusikan node secara otomatis di seluruh zona dalam 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 layanan 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 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 akan 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 region. Instance yang memiliki konfigurasi multi-region akan 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 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 satu region, Anda akan 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 penampung 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, konfigurasikan lokasi set data. Lokasi dapat bersifat regional atau multi-regional. 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 bencana. BigQuery adalah layanan regional, dan menangani kegagalan zona secara otomatis, untuk komputasi dan data. Namun, ada skenario tertentu yang harus Anda rencanakan sendiri, seperti pemadaman layanan regional. Sebaiknya pertimbangkan skenario tersebut saat Anda mendesain lingkungan.

Untuk informasi selengkapnya tentang perencanaan dan fitur disaster recovery BigQuery, lihat Memahami keandalan: Perencanaan disaster recovery dalam dokumentasi BigQuery, dan lihat Membangun disaster recovery untuk pemadaman infrastruktur cloud: BigQuery.

Dataproc

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

Untuk menggunakan Dataproc, Anda 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 memerlukan cluster yang tahan terhadap kegagalan satu node koordinator, atau pemadaman layanan zona sebagian. Cluster Dataproc dengan ketersediaan tinggi adalah resource zonal.

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

Dataflow

Dataflow adalah layanan terkelola sepenuhnya untuk menjalankan pipeline pemrosesan data streaming dan batch. 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-hal berikut:

  • Endpoint regional. Saat membuat tugas, Dataflow mengharuskan Anda mengonfigurasi endpoint regional. Dengan mengonfigurasi endpoint regional untuk tugas, Anda membatasi penempatan resource data dan komputasi ke region tertentu.
  • Penempatan zona. Dataflow secara otomatis mendistribusikan node pekerja di semua zona dalam satu region atau di zona terbaik dalam satu region, sesuai dengan jenis tugas. Dataflow memungkinkan Anda mengganti penempatan zona node pekerja dengan menempatkan semua node pekerja di zona yang sama dalam suatu region. Untuk mengurangi masalah yang disebabkan oleh pemadaman layanan 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 reaksi Dataproc terhadap pemadaman 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. Penayang (layanan yang membuat pesan) mengirim pesan ke topik, dan pelanggan menerima pesan dari topik. Pub/Sub menyimpan setiap pesan di satu region, dan mereplikanya 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 penayang mengirim pesan ke endpoint global, Pub/Sub akan otomatis memilih region terdekat untuk memproses pesan tersebut. Saat produsen mengirim pesan ke endpoint regional, Pub/Sub akan memproses pesan di region tersebut.
  • Kebijakan penyimpanan pesan. Dengan Pub/Sub, Anda dapat 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 pemadaman layanan zonal dan regional, lihat Merancang pemulihan dari bencana untuk pemadaman layanan infrastruktur cloud: Pub/Sub.

Menyesuaikan workload Anda dengan lingkungan region tunggal

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

  • Terapkan praktik dan prinsip Site Reliability Engineering (SRE). Otomatisasi dan pemantauan yang 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 beban kerja.
  • Mendesain untuk skalabilitas dan ketahanan. Saat mendesain workload yang ditujukan untuk lingkungan cloud, sebaiknya pertimbangkan skalabilitas dan resiliensi sebagai persyaratan inheren yang harus dipatuhi oleh workload Anda. Untuk informasi selengkapnya tentang jenis desain ini, lihat Pola untuk aplikasi yang skalabel dan tangguh.
  • Desain untuk memulihkan dari pemadaman infrastruktur cloud. Jaminan ketersediaan Google Cloud ditentukan oleh Perjanjian Tingkat Layanan Google Cloud. Jika terjadi kegagalan zona atau regional, sebaiknya desain workload Anda agar tahan terhadap kegagalan zona dan regional.
  • Terapkan pengurangan beban dan degradasi halus. Jika ada kegagalan infrastruktur cloud, atau kegagalan dalam dependensi beban kerja Anda yang lain, sebaiknya rancang beban kerja Anda agar tangguh. Workload Anda harus mempertahankan tingkat fungsi tertentu dan yang ditentukan dengan baik meskipun ada kegagalan (degradasi yang halus) dan harus dapat menurunkan beberapa proporsi bebannya 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 reguler lingkungan Anda. Pemeliharaan rutin harus mencakup aktivitas seperti menerapkan update dan perubahan konfigurasi pada workload dan dependensinya, serta cara aktivitas tersebut dapat memengaruhi ketersediaan lingkungan Anda. Misalnya, Anda dapat mengonfigurasi kebijakan pemeliharaan host untuk instance Compute Engine.
  • Menggunakan pendekatan pengembangan berbasis pengujian. Saat mendesain beban kerja, sebaiknya Anda mengadopsi pendekatan pengembangan berbasis pengujian untuk memastikan bahwa 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 selanjutnya

Kontributor

Penulis: Marco Ferrari | Cloud Solutions Architect

Kontributor lainnya: