Merencanakan arsitektur workload

Last reviewed 2024-07-24 UTC

Dokumen ini membantu Anda mendesain workload dengan cara yang meminimalkan dampak ekspansi dan migrasi workload mendatang ke region Google Cloud lainnya, atau dampak migrasi workload di seluruh region. Dokumen ini berguna jika Anda berencana melakukan salah satu aktivitas ini atau jika Anda mengevaluasi peluang untuk melakukannya di masa mendatang dan ingin mempelajari seperti apa tampilan pekerjaannya.

Dokumen ini adalah bagian dari rangkaian:

Panduan dalam seri ini juga berguna jika Anda tidak merencanakan migrasi di seluruh region atau perluasan ke beberapa region terlebih dahulu. Dalam hal ini, Anda mungkin perlu melakukan upaya tambahan untuk menyiapkan infrastruktur, workload, dan data untuk migrasi di seluruh region dan untuk perluasan ke beberapa region.

Dokumen ini membantu Anda melakukan hal berikut:

  1. Menyiapkan zona landing
  2. Menyiapkan workload untuk migrasi di berbagai region
  3. Menyiapkan resource komputasi
  4. Menyiapkan resource penyimpanan data
  5. Bersiap untuk menghentikan lingkungan sumber

Menyiapkan zona landing

Bagian ini berfokus pada pertimbangan yang harus Anda buat untuk memperluas zona landing (juga disebut fondasi cloud) saat melakukan migrasi di seluruh region.

Langkah pertama adalah mengevaluasi kembali berbagai aspek zona landing yang ada. Sebelum dapat memigrasikan beban kerja apa pun, Anda harus sudah memiliki zona landing. Meskipun Anda mungkin sudah memiliki zona landing untuk region yang menghosting workload, zona landing mungkin tidak mendukung deployment workload di region lain, sehingga harus diperluas ke region target. Beberapa zona landing yang sudah ada mungkin memiliki desain yang dapat mendukung region lain tanpa perlu melakukan pengerjaan ulang yang signifikan pada zona landing (misalnya, manajemen identitas dan akses atau pengelolaan resource). Namun, faktor tambahan seperti jaringan atau data mungkin mengharuskan Anda melakukan beberapa perencanaan untuk ekstensi. Proses evaluasi ulang harus mempertimbangkan persyaratan utama beban kerja Anda agar Anda dapat menyiapkan fondasi umum yang dapat dikhususkan nanti selama migrasi.

Pertimbangan perusahaan

Dalam hal aspek seperti standar, peraturan, dan sertifikasi industri dan pemerintah, memindahkan beban kerja ke region lain dapat memiliki persyaratan yang berbeda. Workload yang berjalan di region Google yang secara fisik berada di negara yang berbeda harus mematuhi hukum dan peraturan negara tersebut. Selain itu, standar industri yang berbeda mungkin memiliki persyaratan tertentu untuk workload yang berjalan di luar negeri (terutama dalam hal keamanan). Karena region Google Cloud dibuat untuk menjalankan resource di satu negara, terkadang beban kerja dimigrasikan dari region Google lain ke negara tersebut untuk mematuhi peraturan tertentu. Saat Anda melakukan migrasi "dalam negeri" ini, Anda harus mengevaluasi ulang data yang berjalan di lokal untuk memeriksa apakah wilayah baru mengizinkan migrasi data Anda ke Google Cloud.

Pengelolaan akses dan identitas

Saat merencanakan migrasi, Anda mungkin tidak perlu merencanakan banyak perubahan identitas dan akses untuk region yang sudah ada di Google Cloud. Keputusan identitas di Google Cloud dan akses ke resource biasanya didasarkan pada sifat resource, bukan region tempat resource berjalan. Beberapa pertimbangan yang mungkin perlu Anda buat adalah sebagai berikut:

  • Desain tim: Beberapa perusahaan disusun agar memiliki tim yang berbeda untuk menangani resource yang berbeda. Saat workload dimigrasikan ke region lain, karena perubahan struktur resource, tim lain mungkin merupakan kandidat terbaik untuk bertanggung jawab atas resource tertentu, dalam hal ini, akses harus disesuaikan.
  • Konvensi penamaan: Meskipun konvensi penamaan mungkin tidak memiliki dampak teknis pada fungsi, beberapa pertimbangan mungkin diperlukan jika ada resource yang ditentukan dengan konvensi nama yang merujuk ke wilayah tertentu. Salah satu contoh umum adalah saat sudah ada beberapa region yang direplikasi, seperti virtual machine (VM) Compute Engine, yang diberi nama dengan region sebagai awalan, misalnya, europe-west1-backend-1. Selama proses migrasi, untuk menghindari kebingungan atau, lebih buruk lagi, merusak pipeline yang mengandalkan konvensi penamaan tertentu, Anda harus mengubah nama untuk mencerminkan region baru.

Konektivitas dan jaringan

Desain jaringan Anda memengaruhi beberapa aspek cara migrasi dijalankan, jadi penting untuk mengatasi desain ini sebelum Anda merencanakan cara memindahkan beban kerja.

Perlu diingat bahwa konektivitas on-premise dengan Google Cloud adalah salah satu faktor yang harus Anda evaluasi ulang dalam migrasi, karena dapat dirancang untuk bersifat khusus per region. Salah satu contoh faktor ini adalah Cloud Interconnect, yang terhubung ke Google Cloud melalui lampiran VLAN ke region tertentu. Anda harus mengubah region tempat lampiran VLAN terhubung sebelum menutup region tersebut untuk menghindari traffic antar-region. Faktor lain yang perlu dipertimbangkan adalah jika Anda menggunakan Partner Interconnect, memigrasikan region dapat membantu Anda memilih lokasi fisik yang berbeda untuk menghubungkan lampiran VLAN ke Google Cloud. Pertimbangan ini juga relevan jika Anda menggunakan Cloud VPN dan memutuskan untuk mengubah alamat subnet dalam migrasi: Anda harus mengonfigurasi ulang router untuk mencerminkan jaringan baru.

Meskipun virtual private cloud (VPC) di Google Cloud adalah resource global, satu subnet selalu terikat ke region, yang berarti Anda tidak dapat menggunakan subnet yang sama untuk workload setelah migrasi. Karena subnet tidak boleh memiliki IP yang tumpang-tindih, untuk mempertahankan alamat yang sama, Anda harus membuat VPC baru. Proses ini disederhanakan jika Anda menggunakan Cloud DNS, yang dapat memanfaatkan fitur seperti peering DNS untuk merutekan traffic untuk workload yang dimigrasikan sebelum menghapus region lama.

Untuk mengetahui informasi selengkapnya tentang cara membangun fondasi di Google Cloud, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Menyiapkan workload untuk migrasi di seluruh region

Baik Anda menyiapkan infrastruktur di Google Cloud dan berencana untuk bermigrasi ke region lain nanti, atau sudah menggunakan Google Cloud dan perlu bermigrasi ke region lain, Anda harus memastikan bahwa workload dapat dimigrasikan dengan cara yang paling mudah untuk mengurangi upaya dan meminimalkan risiko. Untuk membantu Anda memastikan bahwa semua workload berada dalam status yang memungkinkan jalur ke migrasi, sebaiknya lakukan pendekatan berikut:

  • Pilih desain jaringan yang mudah direplikasi dan tidak terikat erat dari topologi jaringan tertentu. Google Cloud menawarkan berbagai produk yang dapat membantu Anda memisahkan konfigurasi jaringan saat ini dari resource yang menggunakan jaringan tersebut. Contoh produk tersebut adalah Cloud DNS, yang memungkinkan Anda memisahkan IP subnet internal dari VM.
  • Menyiapkan produk yang mendukung konfigurasi multi-region atau global. Produk yang mendukung konfigurasi yang melibatkan lebih dari satu region, biasanya menyederhanakan proses migrasinya ke region lain.
  • Pertimbangkan layanan terkelola dengan replika lintas region terkelola untuk data. Seperti yang dijelaskan di bagian berikut dalam dokumen ini, beberapa layanan terkelola memungkinkan Anda membuat replika di region yang berbeda, biasanya untuk tujuan cadangan atau ketersediaan tinggi. Fitur ini dapat menjadi penting untuk memigrasikan data dari satu region ke region lainnya.

Beberapa layanan Google Cloud dirancang untuk mendukung deployment multi-region atau deployment global. Anda tidak perlu memigrasikan layanan ini, meskipun Anda mungkin perlu menyesuaikan beberapa konfigurasi.

Menyiapkan resource komputasi

Bagian ini memberikan ringkasan tentang resource komputasi di Google Cloud dan prinsip desain untuk mempersiapkan migrasi ke region lain.

Dokumen ini berfokus pada produk komputasi Google Cloud berikut:

Compute Engine

Compute Engine adalah layanan Google Cloud yang menyediakan VM kepada pelanggan.

Untuk memigrasikan resource Compute Engine dari satu region ke region lain, Anda harus mengevaluasi berbagai faktor selain pertimbangan jaringan.

Sebaiknya Anda melakukan hal berikut:

  • Periksa resource komputasi: Salah satu batasan pertama yang dapat Anda hadapi saat mengubah region hosting VM adalah ketersediaan platform CPU di region target baru. Jika Anda harus mengubah seri mesin selama migrasi, pastikan sistem operasi VM saat ini didukung untuk seri tersebut. Secara umum, masalah ini dapat diperluas ke setiap layanan komputasi Google Cloud (beberapa region baru mungkin tidak memiliki layanan seperti Cloud Run atau Cloud GPU), jadi sebelum Anda merencanakan migrasi, pastikan semua layanan komputasi yang Anda perlukan tersedia di region tujuan.
  • Mengonfigurasi load balancing dan penskalaan: Compute Engine mendukung traffic load balancing antara instance Compute Engine dan penskalaan otomatis untuk secara otomatis menambahkan atau menghapus virtual machine dari MIG, sesuai permintaan. Sebaiknya konfigurasikan load balancing dan penskalaan otomatis untuk meningkatkan keandalan dan fleksibilitas lingkungan Anda, sehingga menghindari beban pengelolaan solusi mandiri. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi load balancing dan penskalaan untuk Compute Engine, lihat Load balancing dan penskalaan.
  • Gunakan nama DNS zona: Untuk mengurangi risiko pemadaman layanan lintas wilayah, sebaiknya gunakan nama DNS zona untuk mengidentifikasi virtual machine secara unik menggunakan nama DNS di lingkungan Anda. Google Cloud menggunakan nama DNS zona untuk VM Compute Engine secara default. Untuk mengetahui informasi selengkapnya tentang cara kerja DNS internal Compute Engine, lihat Ringkasan DNS internal. Untuk memfasilitasi migrasi di masa mendatang di seluruh wilayah, dan agar konfigurasi Anda lebih mudah dikelola, sebaiknya pertimbangkan nama DNS zona sebagai parameter konfigurasi yang pada akhirnya dapat Anda ubah di masa mendatang.
  • Gunakan template grup instance terkelola (MIG) yang sama: Compute Engine memungkinkan Anda membuat MIG regional yang secara otomatis menyediakan virtual machine di beberapa zona dalam region secara otomatis. Jika menggunakan template di region lama, Anda dapat menggunakan template yang sama untuk men-deploy MIG di region baru.

GKE

Google Kubernetes Engine (GKE) membantu Anda men-deploy, mengelola, dan menskalakan workload dalam container di Kubernetes.

Untuk menyiapkan workload GKE Anda untuk migrasi, pertimbangkan titik desain dan fitur GKE berikut:

  • Cloud Service Mesh: Implementasi mesh Istio yang dikelola. Dengan mengadopsi Cloud Service Mesh untuk cluster, Anda dapat memiliki tingkat kontrol yang lebih besar atas traffic jaringan ke dalam cluster. Salah satu fitur utama Cloud Service Mesh adalah Anda dapat membuat mesh layanan di antara dua cluster. Anda dapat menggunakan fitur ini untuk merencanakan migrasi dari satu region ke region lain dengan membuat cluster GKE di region baru dan menambahkannya ke mesh layanan. Dengan menggunakan pendekatan ini, Anda dapat mulai men-deploy workload di cluster baru dan merutekan traffic ke cluster tersebut secara bertahap, sehingga Anda dapat menguji deployment baru sekaligus memiliki opsi untuk melakukan rollback dengan mengedit perutean mesh.
  • Config Sync: Layanan GitOps yang dibuat berdasarkan inti open source yang memungkinkan operator cluster dan administrator platform men-deploy konfigurasi dari satu sumber. Config Sync dapat mendukung satu atau beberapa cluster, sehingga Anda dapat menggunakan satu sumber tepercaya untuk mengonfigurasi cluster. Anda dapat menggunakan fungsi Sinkronisasi Konfigurasi ini untuk mereplikasi konfigurasi cluster yang ada di cluster untuk region baru, dan berpotensi menyesuaikan resource tertentu untuk region tersebut.
  • Pencadangan untuk GKE: Fitur ini memungkinkan Anda mencadangkan data persisten cluster secara berkala dan memulihkan data ke cluster yang sama atau ke cluster baru.

Cloud Run

Cloud Run menawarkan pendekatan ringan untuk men-deploy container di Google Cloud. Layanan Cloud Run adalah resource regional, dan direplikasi di beberapa zona di region tempatnya berada. Saat men-deploy layanan Cloud Run, Anda dapat memilih region tempat instance akan di-deploy, lalu menggunakan fitur ini untuk men-deploy workload di region lain.

VMware Engine

Google Cloud VMware Engine adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjalankan platform VMware di Google Cloud. Lingkungan VMware berjalan secara native di infrastruktur bare metal Google Cloud di lokasi Google Cloud, termasuk vSphere, vCenter, vSAN, NSX-T, HCX, dan alat terkait.

Untuk memigrasikan instance VMware Engine ke region lain, Anda harus membuat cloud pribadi di region baru, lalu menggunakan alat VMware untuk memindahkan instance.

Anda juga harus mempertimbangkan DNS dan load balancing di lingkungan Compute Engine saat merencanakan migrasi. VMware Engine menggunakan Google Cloud DNS, yaitu layanan hosting DNS terkelola yang menyediakan hosting DNS resmi yang dipublikasikan ke internet publik, zona pribadi yang terlihat oleh jaringan VPC, serta penerusan dan peering DNS untuk mengelola resolusi nama di jaringan VPC. Rencana migrasi
Anda dapat mendukung pengujian konfigurasi DNS dan load balancing multi-region.

Menyiapkan resource penyimpanan data

Bagian ini memberikan ringkasan tentang resource penyimpanan data di Google Cloud dan dasar-dasar tentang cara mempersiapkan migrasi ke region lain.

Kehadiran data yang sudah ada di Google Cloud menyederhanakan migrasi, karena menyiratkan bahwa solusi untuk menghostingnya tanpa transformasi ada atau dapat dihosting di Google Cloud.

Kemampuan untuk menyalin data database ke region lain dan memulihkan data di tempat lain adalah pola umum dalam Pemulihan dari Bencana (DR). Oleh karena itu, beberapa pola yang dijelaskan dalam dokumen ini mengandalkan mekanisme DR seperti pencadangan dan pemulihan database.

Layanan terkelola berikut dijelaskan dalam dokumen ini:

Dokumen ini mengasumsikan bahwa solusi penyimpanan yang Anda gunakan adalah instance regional yang berlokasi bersama dengan resource komputasi.

Cloud Storage

Cloud Storage menawarkan Storage Transfer Service, yang mengotomatiskan transfer file dari berbagai sistem ke Cloud Storage. Replikasi dapat digunakan untuk mereplikasi data ke region lain untuk pencadangan, dan juga untuk migrasi region ke region.

Cloud SQL

Cloud SQL menawarkan layanan database relasional untuk menghosting berbagai jenis database. Cloud SQL menawarkan fungsi replikasi lintas region yang memungkinkan data instance direplikasi di region yang berbeda. Fitur ini adalah pola umum untuk pencadangan dan pemulihan instance Cloud SQL, tetapi juga memungkinkan Anda mempromosikan replika kedua di region lain ke replika utama. Anda dapat menggunakan fitur ini untuk membuat replika baca di region kedua, lalu mempromosikannya ke replika utama setelah memigrasikan beban kerja. Secara umum, untuk database, layanan terkelola menyederhanakan proses replikasi data, untuk mempermudah pembuatan replika di region baru selama migrasi.

Cara lain untuk menangani migrasi adalah dengan menggunakan Database Migration Service, yang memungkinkan Anda memigrasikan database SQL dari sumber yang berbeda ke Google Cloud. Di antara sumber yang didukung, ada juga instance Cloud SQL lain, dengan satu-satunya batasan bahwa Anda dapat melakukan migrasi ke region yang berbeda, tetapi tidak ke project yang berbeda.

Filestore

Seperti yang dijelaskan sebelumnya dalam dokumen ini, fitur pencadangan dan pemulihan Filestore memungkinkan Anda membuat cadangan berbagi file yang dapat dipulihkan ke region lain. Fitur ini dapat digunakan untuk melakukan migrasi region ke region.

Bigtable

Seperti halnya Cloud SQL, Bigtable mendukung replikasi. Anda dapat menggunakan fitur ini untuk mereplikasi pola yang sama seperti yang dijelaskan. Periksa di daftar lokasi Bigtable apakah layanan tersedia di region tujuan.

Selain itu, seperti halnya Filestore, Bigtable mendukung pencadangan dan pemulihan. Fitur ini dapat digunakan, seperti halnya Filestore, untuk menerapkan migrasi dengan membuat cadangan dan memulihkannya di instance lain di region baru.

Opsi terakhir adalah mengekspor tabel, misalnya, di Cloud Storage. Ekspor ini akan menghosting data di layanan lain, dan data tersebut kemudian tersedia untuk diimpor ke instance di region.

Firestore

Lokasi Firestore mungkin terikat dengan keberadaan App Engine di project Anda, yang dalam beberapa skenario memaksa instance Firestore menjadi multi-region. Dalam skenario migrasi ini, Anda juga perlu mempertimbangkan App Engine untuk mendesain solusi yang tepat bagi Firestore. Bahkan, jika Anda sudah memiliki aplikasi App Engine dengan lokasi us-central atau
europe-west, database Firestore Anda dianggap multi-regional.

Jika Anda memiliki lokasi regional dan ingin bermigrasi ke lokasi lain, layanan ekspor dan impor terkelola memungkinkan Anda mengimpor dan mengekspor entity Firestore menggunakan bucket Cloud Storage. Metode ini dapat digunakan untuk memindahkan instance dari satu region ke region lain. Opsi lainnya adalah menggunakan fitur pencadangan dan pemulihan Firestore. Opsi ini lebih murah dan lebih mudah dibandingkan impor dan ekspor.

Bersiap untuk menghentikan lingkungan sumber

Anda harus melakukan persiapan terlebih dahulu sebelum menghentikan lingkungan sumber dan beralih ke lingkungan baru.

Pada level yang tinggi, Anda harus mempertimbangkan hal berikut sebelum menghentikan lingkungan sumber:

  • Pengujian lingkungan baru: Sebelum mengalihkan traffic dari lingkungan lama ke lingkungan baru, Anda dapat melakukan pengujian untuk memvalidasi kebenaran aplikasi. Selain pengujian unit dan integrasi klasik yang dapat dilakukan pada aplikasi yang baru dimigrasikan, ada strategi pengujian yang berbeda. Lingkungan baru dapat diperlakukan sebagai versi baru software dan migrasi traffic dapat diterapkan dengan pola umum seperti pengujian A/B yang digunakan untuk validasi. Pendekatan lainnya adalah mereplikasi traffic masuk di lingkungan sumber dan di lingkungan baru untuk memeriksa apakah fungsi tetap dipertahankan.
  • Perencanaan periode nonaktif: Jika Anda memilih strategi migrasi seperti blue-green, yang mengalihkan traffic dari satu lingkungan ke lingkungan lain, pertimbangkan untuk menerapkan periode nonaktif terencana. Periode nonaktif memungkinkan transisi dipantau dengan lebih baik dan menghindari error yang tidak dapat diprediksi di sisi klien.
  • Rollback: Bergantung pada strategi yang diterapkan untuk memigrasikan traffic, Anda mungkin perlu menerapkan rollback jika terjadi error atau konfigurasi yang salah pada lingkungan baru. Agar dapat melakukan rollback lingkungan, Anda harus memiliki infrastruktur pemantauan untuk mendeteksi status lingkungan baru.

Anda hanya dapat menonaktifkan layanan di wilayah pertama setelah melakukan pengujian yang diperpanjang di wilayah baru dan melakukan live di wilayah baru tanpa error. Sebaiknya simpan cadangan region pertama selama waktu terbatas, hingga Anda yakin tidak ada masalah di region yang baru dimigrasikan.

Anda juga harus mempertimbangkan apakah ingin mempromosikan region lama ke situs pemulihan dari bencana, dengan asumsi belum ada solusi yang diterapkan. Pendekatan ini memerlukan desain tambahan untuk memastikan situs tersebut dapat diandalkan. Untuk informasi selengkapnya tentang cara mendesain dan merencanakan DR dengan benar, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).

Langkah Berikutnya

Kontributor

Penulis: Valerio Ponza | Technical Solution Consultant

Kontributor lainnya: