Dokumen ini menjelaskan praktik terbaik untuk memvalidasi rencana untuk memigrasikan workload Anda ke Google Cloud. Dokumen ini tidak mencantumkan semua kemungkinan praktik terbaik untuk memvalidasi rencana migrasi, dan tidak memberi Anda jaminan keberhasilan. Sebaliknya, ini membantu Anda menstimulasi diskusi tentang potensi perubahan dan peningkatan pada rencana migrasi Anda.
Dokumen ini berguna jika Anda merencanakan migrasi dari lingkungan lokal, dari lingkungan hosting pribadi, atau dari penyedia cloud lain ke Google Cloud. Dokumen ini juga berguna jika Anda mengevaluasi peluang untuk bermigrasi dan ingin mempelajari seperti apa tampilannya.
Dokumen ini adalah bagian dari rangkaian multi-bagian berikut tentang migrasi ke Google Cloud:
- Bermigrasi ke Google Cloud: Memulai
- Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda
- Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda
- Bermigrasi ke Google Cloud: Mentransfer set data besar Anda
- Bermigrasi ke Google Cloud: Men-deploy workload Anda
- Bermigrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment otomatis dalam container
- Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda
- Migrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi (dokumen ini)
- Bermigrasi ke Google Cloud: Meminimalkan biaya
Penilaian
Penilaian lengkap atas workload dan lingkungan Anda dapat membantu memastikan Anda memiliki pemahaman mendalam tentang workload dan lingkungan Anda. Mengembangkan pemahaman ini akan membantu Anda meminimalkan risiko masalah yang terjadi selama dan setelah migrasi ke Google Cloud.
Membuat penilaian lengkap
Sebelum melanjutkan ke langkah-langkah yang mengikuti fase penilaian, selesaikan penilaian workload dan lingkungan Anda. Untuk membuat penilaian lengkap, pertimbangkan item-item berikut, yang sering diabaikan:
- Inventaris: Pastikan inventaris workload yang akan dimigrasikan sudah yang terbaru dan Anda telah menyelesaikan penilaian. Misalnya, pertimbangkan seberapa baru dan akurat data sumber untuk penilaian Anda, dan kesenjangan apa yang mungkin ada dalam data tersebut.
Periode nonaktif: Menilai workload mana yang dapat menyebabkan periode nonaktif, dan jangka waktu maksimum untuk periode nonaktif tersebut. Melakukan migrasi workload saat mengalami nol atau hampir nol periode nonaktif lebih sulit dibandingkan memigrasikan workload yang dapat mengatasi periode nonaktif. Untuk menyelesaikan migrasi tanpa periode nonaktif, Anda harus merancang dan menerapkan redundansi untuk setiap workload yang akan dimigrasikan. Anda juga perlu mengkoordinasikan instance redundan ini.
Saat menilai seberapa banyak periode nonaktif yang dapat ditoleransi oleh workload, nilailah apakah manfaat bisnis dari migrasi tanpa periode nonaktif lebih besar daripada kompleksitas migrasi tambahan. Jika memungkinkan, hindari membuat persyaratan nol periode nonaktif untuk workload.
Pengelompokan dan redundansi: Menilai workload mana yang mendukung pengelompokan dan redundansi. Jika workload mendukung pengelompokan dan redundansi, Anda dapat men-deploy beberapa instance workload tersebut, bahkan di lingkungan yang berbeda, seperti lingkungan sumber dan lingkungan target. Deployment cluster dan redundan dapat menyederhanakan migrasi karena workload tersebut berkoordinasi satu sama lain dengan intervensi terbatas.
Update konfigurasi: Menilai cara Anda mengupdate konfigurasi workload. Misalnya, pertimbangkan cara Anda mengirimkan update ke konfigurasi setiap workload yang ingin Anda migrasikan. Pertimbangan ini sangat penting untuk keberhasilan migrasi Anda karena Anda mungkin harus memperbarui konfigurasi workload saat memigrasikannya ke lingkungan target.
Buat beberapa laporan penilaian: Selama fase penilaian, sebaiknya buat lebih dari satu laporan penilaian untuk memperhitungkan skenario yang berbeda. Misalnya, Anda dapat membuat laporan untuk memperhitungkan profil beban yang berbeda untuk beban kerja Anda, seperti pada waktu puncak dan non-puncak.
Menilai mode kegagalan yang didukung workload Anda
Mengetahui perilaku workload dalam keadaan yang luar biasa akan membantu memastikan bahwa Anda tidak mengekspos beban kerja tersebut pada kondisi yang tidak dapat dipulihkan. Sebagai bagian dari penilaian, kumpulkan informasi tentang mode kegagalan dan efeknya yang didukung workload Anda dan dapat dipulihkan secara otomatis, serta mode kegagalan mana yang memerlukan intervensi Anda. Misalnya, Anda dapat mulai dengan mempertimbangkan pertanyaan tentang kemungkinan mode kegagalan, seperti berikut:
- Apa yang terjadi jika workload kehilangan konektivitas ke jaringan?
- Apakah workload dapat melanjutkan pekerjaannya dari posisi terakhir setelah dihentikan?
- Apa yang terjadi jika performa workload atau dependensinya tidak memadai?
- Apa yang terjadi jika ada dua workload yang memiliki ID yang sama dalam arsitektur?
- Apa yang terjadi jika tugas terjadwal tidak berjalan?
- Apa yang terjadi jika dua workload memproses permintaan yang sama?
Sumber lain untuk mode kegagalan yang tidak didukung mungkin dari rencana migrasi itu sendiri. Tentukan apakah rencana migrasi Anda menyertakan langkah-langkah yang bergantung pada keberhasilan kondisi tertentu, dan apakah rencana migrasi menyertakan kemungkinan jika kondisi tidak terpenuhi. Rencana yang menyertakan jenis kondisi ini dapat menunjukkan bahwa rencana itu sendiri mungkin gagal atau komponen individual mungkin gagal selama migrasi.
Setelah Anda menilai mode kegagalan tersebut dan efeknya, validasi temuan Anda di lingkungan nonkritis dengan menyimulasikan kegagalan dan memasukkan kegagalan yang mengemulasi mode kegagalan tersebut. Misalnya, jika beban kerja dirancang untuk pulih secara otomatis setelah konektivitas jaringan terputus, validasikan pemulihan otomatis dengan mengganggu konektivitasnya secara paksa dan memulihkannya setelahnya.
Menilai pipeline pemrosesan data Anda
Penilaian workload Anda harus dapat menjawab pertanyaan berikut:
- Apakah ukuran resource sudah benar untuk migrasi?
- Berapa lama waktu yang diperlukan untuk memigrasikan data yang diperlukan workload Anda?
- Dapatkah lingkungan target mengakomodasi seluruh volume data?
- Bagaimana workload kerja Anda saat harus mengakomodasi lonjakan permintaan atau lonjakan jumlah data yang dihasilkan dalam jangka waktu tertentu?
- Jika ada lonjakan permintaan atau lonjakan jumlah data yang dihasilkan oleh workload Anda, apakah ada efek buruk, seperti peningkatan latensi atau keterlambatan respons?
- Setelah workload Anda dimulai, apakah workload tersebut memerlukan waktu untuk meningkatkan ke tingkat performa yang diharapkan?
Hasil penilaian ini sering kali merupakan model permintaan yang dipenuhi oleh workload Anda dan data yang dihasilkan oleh workload dalam jangka waktu tertentu. Ketika Anda mengumpulkan titik data untuk menghasilkan model tersebut, pertimbangkan bahwa titik data tersebut mungkin bervariasi secara signifikan antara periode waktu puncak dan non-puncak. Untuk mengetahui informasi selengkapnya tentang cara dan hal yang harus dipantau, lihat Tujuan Tingkat Layanan di buku Site Reliability Engineering.
Pastikan Anda dapat memperbarui dan men-deploy setiap workload untuk dimigrasikan
Selama migrasi, Anda mungkin perlu mengupdate beberapa workload yang sedang dimigrasikan. Misalnya, Anda mungkin perlu men-deploy perbaikan untuk suatu masalah, atau melakukan roll back perubahan terbaru yang menyebabkan masalah. Untuk setiap workload yang Anda migrasikan, pastikan Anda dapat menerapkan dan men-deploy perubahan. Misalnya, jika Anda memigrasikan workload yang kode sumbernya Anda miliki, pastikan Anda dapat mengakses kode sumber tersebut, dan Anda dapat membuat, mengemas, serta men-deploy kode sumber yang diperlukan.
Migrasi Anda mungkin mencakup workload yang tidak dapat Anda terapkan dan men-deploy perubahannya (seperti software eksklusif). Dalam skenario tersebut, faktorkan ulang rencana migrasi Anda untuk mempertimbangkan upaya tambahan untuk mengurangi masalah yang mungkin terjadi setelah Anda memigrasikan workload tersebut.
Menilai infrastruktur jaringan Anda
Infrastruktur jaringan yang fungsional adalah hal mendasar untuk migrasi. Anda dapat menggunakan infrastruktur jaringan sebagai bagian dari alat migrasi. Misalnya, Anda dapat menggunakan load balancer dan server DNS untuk mengarahkan traffic sesuai dengan rencana migrasi Anda.
Untuk menghindari masalah selama migrasi, penting untuk menilai infrastruktur jaringan Anda dan mengevaluasi sejauh mana infrastruktur tersebut dapat mendukung migrasi Anda. Misalnya, Anda dapat memulai dengan mempertimbangkan pertanyaan tentang infrastruktur load balancing, seperti berikut:
- Apa yang terjadi jika Anda mengonfigurasi ulang load balancer?
- Berapa lama waktu yang diperlukan hingga konfigurasi yang diperbarui diterapkan?
- Saat melakukan migrasi tanpa periode nonaktif, apa yang terjadi jika Anda mendapatkan lonjakan traffic sebelum konfigurasi yang diperbarui diterapkan?
Setelah mempertimbangkan pertanyaan tentang infrastruktur load balancing, selanjutnya pertimbangkan pertanyaan tentang infrastruktur DNS Anda, seperti berikut ini:
- Data DNS mana yang harus Anda perbarui untuk mengarahkannya ke lingkungan target, dan kapan harus memperbaruinya?
- Klien mana yang menggunakan data DNS tersebut?
- Bagaimana time to live (TTL) yang dikonfigurasi untuk data DNS untuk diperbarui?
- Dapatkah Anda menetapkan TTL data DNS ke minimum selama migrasi?
- Apakah klien DNS Anda mematuhi TTL data DNS untuk diperbarui? Misalnya, apakah aplikasi Anda memiliki caching DNS sisi klien yang mengabaikan TTL yang telah dikonfigurasi untuk migrasi?
- Apakah Anda mendeteksi traffic yang diarahkan ke lingkungan sumber bahkan setelah menyelesaikan migrasi?
Perencanaan migrasi
Merencanakan migrasi dengan cermat akan membantu Anda menghindari masalah selama dan setelah migrasi. Perencanaan juga membantu Anda menghindari upaya untuk menangani tugas-tugas yang tidak terduga.
Mengembangkan strategi rollback untuk setiap langkah rencana migrasi
Selama migrasi, setiap langkah dari rencana migrasi yang Anda jalankan dapat menyebabkan masalah yang tidak terduga. Untuk memastikan Anda dapat pulih dari masalah tersebut, siapkan strategi rollback untuk setiap langkah rencana migrasi. Untuk menghindari kehilangan waktu selama pemadaman, lakukan hal berikut:
- Pastikan strategi rollback Anda berfungsi dengan meninjau dan menguji setiap strategi rollback secara berkala.
- Menetapkan waktu eksekusi maksimum yang diizinkan untuk setiap langkah migrasi. Setelah waktu eksekusi yang diizinkan ini berakhir, tim Anda akan mulai me-roll back langkah migrasi.
Meskipun Anda sudah menyiapkan strategi rollback untuk setiap langkah rencana migrasi, beberapa langkah tersebut mungkin masih berpotensi mengganggu. Langkah yang berpotensi mengganggu dapat menyebabkan semacam kerugian, meskipun Anda melakukan roll back, seperti kehilangan data. Menentukan langkah rencana migrasi mana yang berpotensi mengganggu.
Jika Anda mengotomatiskan langkah apa pun dalam rencana migrasi, pastikan Anda memiliki prosedur standar untuk setiap langkah otomatis jika terjadi kegagalan dalam otomatisasi. Seperti strategi rollback, tinjau dan uji setiap prosedur yang telah direncanakan secara berkala.
Jika Anda menyiapkan saluran komunikasi sebagai bagian dari migrasi, untuk memastikan Anda tidak terkunci dari lingkungan, sediakan saluran cadangan yang dapat digunakan untuk pulih dari kegagalan. Misalnya, jika menyiapkan Partner Interconnect, selama migrasi, Anda juga dapat menyiapkan akses cadangan melalui internet publik jika mengalami masalah selama penyediaan dan konfigurasi.
Rencanakan peluncuran dan deployment bertahap
Untuk mengurangi cakupan masalah dan masalah yang mungkin terjadi selama migrasi, hindari perubahan berskala besar, dan desain rencana migrasi Anda untuk men-deploy perubahan secara bertahap. Misalnya, buat rencana untuk deployment bertahap dan perubahan konfigurasi.
Jika Anda merencanakan peluncuran bertahap, untuk menurunkan risiko masalah tak terduga yang disebabkan oleh penerapan perubahan, minimalkan jumlah dan ukuran perubahan tersebut. Setelah mengidentifikasi dan menyelesaikan masalah dalam peluncuran kecil pertama, Anda dapat melakukan peluncuran berikutnya untuk perubahan serupa dalam skala yang lebih besar.
Pemberitahuan tim pengembangan dan operasi
Untuk mengurangi dampak masalah yang mungkin terjadi selama migrasi, beri tahu tim yang bertanggung jawab atas workload apa pun yang akan dimigrasikan. Selain itu, beri tahu tim yang bertanggung jawab atas infrastruktur lingkungan sumber dan target.
Jika tim Anda bekerja di zona waktu yang berbeda, pastikan hal-hal berikut:
- Tim Anda mencakup zona waktu tersebut dengan benar dan mereka mencakup beberapa shift berturut-turut, karena mereka mungkin tidak dapat menyelesaikan masalah dalam satu shift.
- Tim Anda siap mengumpulkan informasi terperinci tentang masalah yang mungkin mereka hadapi. Koleksi ini memberikan pemahaman lengkap kepada para engineer tentang pergeseran sebelumnya, dan alasannya.
- Orang-orang tertentu dalam tim Anda bertanggung jawab atas setiap shift tertentu.
Menghapus bukti-konsep resource dari lingkungan produksi target
Sebagai bagian dari penilaian, Anda mungkin telah menggunakan lingkungan target untuk menghosting eksperimen dan bukti konsep. Sebelum migrasi, hapus semua resource yang Anda buat selama eksperimen dan bukti konsep tersebut dari area produksi lingkungan target.
Anda dapat menyimpan resource di area non-produksi dari lingkungan target saat migrasi sedang berlangsung karena resource tersebut dapat membantu Anda mengumpulkan informasi tentang masalah apa pun yang mungkin muncul selama migrasi. Misalnya, untuk mendiagnosis masalah yang memengaruhi beban kerja produksi setelah migrasi, Anda dapat membandingkan log data dan konfigurasi workload produksi dengan log data dan bukti konsep dan eksperimen.
Setelah menyelesaikan migrasi dan memvalidasi bahwa lingkungan target berfungsi seperti yang diharapkan, Anda dapat menghapus resource di area non-produksi lingkungan target.
Tentukan kriteria untuk menghentikan lingkungan sumber dengan aman
Untuk menghindari biaya menjalankan dua lingkungan tanpa batas waktu, tentukan kondisi yang harus dipenuhi agar Anda dapat menghentikan lingkungan sumber dengan aman, seperti berikut:
- Semua workload, termasuk pencadangannya, ketersediaan tinggi, dan mekanisme pemulihan dari bencana, berhasil dimigrasikan ke lingkungan target.
- Data yang dimigrasikan di lingkungan target konsisten, dapat diakses, dan dapat digunakan.
- Keakuratan dan kelengkapan data yang dimigrasikan memenuhi standar yang ditentukan.
- Resource yang tetap berada di lingkungan sumber bukanlah dependensi untuk beban kerja yang berada di luar cakupan migrasi.
- Performa workload Anda di lingkungan target memenuhi target SLA Anda.
- Sistem pemantauan Anda melaporkan bahwa tidak ada traffic jaringan ke lingkungan sumber yang harus diarahkan ke lingkungan target.
- Setelah workload berjalan tanpa masalah di lingkungan target selama periode yang Anda tentukan, Anda yakin bahwa Anda tidak lagi memerlukan kemampuan untuk melakukan penggantian ke lingkungan sumber.
Operasi
Untuk mengelola lingkungan sumber dan lingkungan target secara efisien selama migrasi, Anda juga perlu merekayasa proses operasional Anda.
Memantau lingkungan Anda
Untuk mengamati bagaimana lingkungan sumber dan target berperilaku serta membantu Anda mendiagnosis masalah yang terjadi, siapkan hal berikut:
- Sistem pemantauan untuk mengumpulkan metrik yang berguna untuk skenario Anda.
- Sistem logging untuk mengamati alur operasi yang dilakukan oleh beban kerja dan komponen lain di lingkungan Anda.
- Sistem pemberitahuan yang memperingatkan Anda sebelum terjadi peristiwa yang bermasalah.
Google Cloud Observability mendukung pemantauan, logging, dan pemberitahuan terintegrasi untuk lingkungan Google Cloud Anda.
Karena beban kerja dan dependensinya mencakup beberapa lingkungan, Anda mungkin perlu mempertimbangkan untuk menggunakan beberapa alat pemantauan dan pemberitahuan untuk lingkungan yang berbeda. Pertimbangkan waktu saat Anda memigrasikan kebijakan pemantauan dan pemberitahuan yang mendukung workload. Misalnya, jika lingkungan sumber dikonfigurasi untuk memberi tahu saat server tertentu nonaktif, pemberitahuan akan dipicu saat Anda sengaja menonaktifkan server tersebut. Pemicu pemberitahuan memang diharapkan, tetapi aksi ini tidak membantu. Sebagai bagian dari migrasi, Anda perlu terus menyesuaikan pemberitahuan untuk lingkungan sumber dan mengonfigurasi ulang pemberitahuan untuk lingkungan target.
Kelola migrasi
Untuk mengelola migrasi, Anda perlu meninjau performa migrasi untuk mengumpulkan informasi yang dapat digunakan sebagai retrospektif setelah migrasi selesai. Setelah mengumpulkan informasi, Anda menggunakannya untuk menganalisis performa migrasi dan menyiapkan titik data tentang potensi peningkatan pada lingkungan Anda.
Misalnya, untuk mulai berencana mengelola migrasi, pertimbangkan pertanyaan berikut:
- Berapa lama waktu yang dibutuhkan untuk setiap langkah dalam rencana migrasi?
- Apakah ada langkah-langkah dalam rencana migrasi yang memerlukan waktu lebih lama untuk diselesaikan dari yang diperkirakan?
- Apakah ada langkah atau pemeriksaan yang hilang?
- Apakah ada peristiwa buruk yang terjadi selama migrasi?
Langkah selanjutnya
- Pelajari kapan harus menemukan bantuan untuk migrasi.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Marco Ferrari | Cloud Solutions Architect