Memigrasikan di seluruh region Google Cloud: Menyiapkan data dan workload batch untuk migrasi di seluruh region

Last reviewed 2024-12-02 UTC

Dokumen ini menjelaskan cara mendesain platform data di Google Cloud untuk meminimalkan dampak perluasan pada masa mendatang ke region lain atau migrasi antar-region. Dokumen ini adalah bagian dari rangkaian yang membantu Anda memahami dampak perluasan platform data ke region lain. Hal ini membantu Anda mempelajari cara melakukan hal berikut:

  • Bersiap untuk memindahkan data dan pipeline data.
  • Siapkan pemeriksaan selama fase migrasi.
  • Buat strategi migrasi yang fleksibel dengan memisahkan penyimpanan data dan komputasi data.

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

Dokumen ini adalah bagian dari rangkaian:

Rangkaian ini mengasumsikan bahwa Anda telah membaca dan memahami dokumen-dokumen berikut:

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Selama setiap langkah migrasi, Anda harus mengikuti fase yang ditentukan dalam Migrasi ke Google Cloud: Memulai:

  1. Menilai dan menemukan workload Anda.
  2. Merencanakan dan membangun fondasi.
  3. Men-deploy workload Anda.
  4. Mengoptimalkan lingkungan Anda.

Platform data modern di Google Cloud

Bagian ini menjelaskan berbagai bagian platform data modern, dan cara pembuatannya di Google Cloud. Platform data sebagai konsep umum dapat dibagi menjadi dua bagian:

  • Lapisan penyimpanan data adalah tempat data disimpan. Data yang Anda simpan dapat berupa file tempat Anda mengelola byte aktual pada sistem file seperti Hadoop Distributed File System (HDFS) atau Cloud Storage, atau Anda dapat menggunakan bahasa khusus domain (DSL) untuk mengelola data dalam sistem pengelolaan database.
  • Lapisan komputasi data adalah pemrosesan data apa pun yang mungkin Anda aktifkan di atas sistem penyimpanan. Seperti halnya lapisan penyimpanan, ada banyak kemungkinan penerapan, dan beberapa alat penyimpanan data juga menangani komputasi data. Peran lapisan komputasi data dalam platform adalah memuat data dari lapisan penyimpanan, memproses data, lalu menyimpan hasilnya ke sistem target. Sistem target dapat berupa lapisan penyimpanan sumber.

Beberapa platform data menggunakan beberapa sistem penyimpanan untuk lapisan penyimpanan data mereka, dan beberapa sistem komputasi data untuk lapisan pemrosesan data mereka. Dalam sebagian besar kasus, lapisan penyimpanan data dan lapisan komputasi data dipisahkan. Misalnya, Anda mungkin telah menerapkan lapisan penyimpanan data menggunakan layananGoogle Cloud berikut:

Anda mungkin telah menerapkan lapisan komputasi data menggunakan layananGoogle Cloud lain seperti:

Untuk mengurangi waktu dan latensi komunikasi, biaya transfer data keluar, dan jumlah operasi I/O antara lapisan penyimpanan dan lapisan komputasi, sebaiknya simpan data di zona yang sama dengan tempat Anda memproses data.

Sebaiknya Anda juga memisahkan lapisan penyimpanan data dari lapisan komputasi data. Memisahkan lapisan ini akan meningkatkan fleksibilitas Anda dalam mengubah lapisan komputasi dan memigrasikan data. Memisahkan lapisan juga akan mengurangi penggunaan resource karena Anda tidak perlu menjalankan lapisan komputasi sepanjang waktu. Oleh karena itu, sebaiknya Anda men-deploy penyimpanan data dan komputasi data di platform terpisah dalam zona dan region yang sama. Misalnya, Anda dapat memindahkan penyimpanan data dari HDFS ke Cloud Storage dan menggunakan cluster Dataproc untuk komputasi.

Mengevaluasi lingkungan Anda

Pada fase penilaian, Anda akan menentukan persyaratan dan dependensi untuk memigrasikan pipeline data batch yang telah Anda deploy:

  1. Buat inventaris pipeline data yang komprehensif.
  2. Buat katalog pipeline Anda sesuai dengan properti dan dependensinya.
  3. Latih dan ajari tim Anda tentang Google Cloud.
  4. Buat eksperimen dan bukti konsep di Google Cloud.
  5. Hitung total biaya kepemilikan (TCO) lingkungan target.
  6. Pilih beban kerja yang ingin Anda migrasikan terlebih dahulu.

Untuk mengetahui informasi selengkapnya tentang fase penilaian dan tugas ini, lihat Migrasi ke Google Cloud: Menilai dan menemukan workload Anda. Bagian berikut didasarkan pada informasi dalam dokumen tersebut.

Membangun inventaris Anda

Untuk menentukan cakupan migrasi, Anda harus memahami lingkungan platform data tempat pipeline data Anda di-deploy:

  1. Buat inventaris infrastruktur data Anda—berbagai lapisan penyimpanan dan lapisan komputasi yang berbeda yang Anda gunakan untuk penyimpanan data dan pemrosesan data batch.
  2. Buat inventaris pipeline data yang dijadwalkan untuk dimigrasikan.
  3. Buat inventaris set data yang dibaca oleh pipeline data dan yang perlu dimigrasikan.

Untuk membuat inventaris platform data Anda, pertimbangkan hal berikut untuk setiap bagian infrastruktur data:

  • Lapisan penyimpanan. Selain platform penyimpanan standar seperti Cloud Storage, pertimbangkan lapisan penyimpanan lain seperti database seperti Firebase, BigQuery, Bigtable, dan Postgres, atau cluster lain seperti Apache Kafka. Setiap platform penyimpanan memiliki strategi dan metode sendiri untuk menyelesaikan migrasi. Misalnya, Cloud Storage memiliki layanan migrasi data, dan database mungkin memiliki alat migrasi bawaan. Pastikan setiap produk yang Anda gunakan untuk penyimpanan data tersedia untuk Anda di lingkungan target, atau Anda memiliki pengganti yang kompatibel. Latih dan verifikasi proses transfer data teknis untuk setiap platform penyimpanan yang terlibat.
  • Lapisan komputasi. Untuk setiap platform komputasi, verifikasi rencana deployment dan verifikasi setiap perubahan konfigurasi yang mungkin telah Anda lakukan pada platform yang berbeda.
  • Latensi jaringan. Uji dan verifikasi latensi jaringan antara lingkungan sumber dan lingkungan target. Anda harus memahami berapa lama waktu yang dibutuhkan untuk menyalin data. Anda juga perlu menguji latensi jaringan dari klien dan lingkungan eksternal (seperti lingkungan lokal) ke lingkungan target dibandingkan dengan lingkungan sumber.

  • Konfigurasi dan deployment. Setiap produk infrastruktur data memiliki metode penyiapannya sendiri. Buat inventaris konfigurasi kustom yang telah Anda buat untuk setiap komponen, dan komponen mana yang Anda gunakan versi defaultnya untuk setiap platform (misalnya, versi Dataproc atau versi Apache Kafka yang Anda gunakan). Pastikan konfigurasi tersebut dapat di-deploy sebagai bagian dari proses deployment otomatis Anda.

    Anda perlu mengetahui cara mengonfigurasi setiap komponen karena mesin komputasi mungkin berperilaku berbeda jika dikonfigurasi secara berbeda—terutama jika framework lapisan pemrosesan berubah selama migrasi. Misalnya, jika lingkungan target menjalankan Apache Spark versi yang berbeda, beberapa konfigurasi framework Spark mungkin telah berubah antarversi. Perubahan konfigurasi semacam ini dapat menyebabkan perubahan pada output, serialisasi, dan komputasi.

    Selama migrasi, sebaiknya gunakan deployment otomatis untuk memastikan versi dan konfigurasi tetap sama. Jika Anda tidak dapat mempertahankan versi dan konfigurasi yang sama, pastikan untuk melakukan pengujian yang memvalidasi output data yang dihitung oleh framework.

  • Ukuran cluster. Untuk cluster yang dikelola sendiri, seperti cluster Dataproc yang berjalan lama atau cluster Apache Kafka yang berjalan di Compute Engine, catat jumlah node dan CPU, serta memori untuk setiap node dalam cluster. Bermigrasi ke region lain dapat menyebabkan perubahan pada prosesor yang digunakan deployment Anda. Oleh karena itu, sebaiknya buat profil dan optimalkan beban kerja Anda setelah men-deploy infrastruktur yang dimigrasikan ke produksi. Jika komponen dikelola sepenuhnya atau serverless (misalnya Dataflow), penentuan ukurannya akan menjadi bagian dari setiap tugas individual, dan bukan bagian dari cluster itu sendiri.

Item berikut yang Anda nilai dalam inventaris berfokus pada pipeline data:

  • Sumber dan tujuan data. Pastikan untuk memperhitungkan sumber dan tujuan yang digunakan setiap pipeline data untuk membaca dan menulis data.
  • Perjanjian Tingkat Layanan (SLA) dan Tujuan Tingkat Layanan (SLO). SLA dan SLO pipeline data batch biasanya diukur dalam waktu hingga selesai, tetapi juga dapat diukur dengan cara lain, seperti daya komputasi yang digunakan. Metadata bisnis ini penting dalam mendorong proses rencana pemulihan dari bencana dan kelangsungan bisnis (BCDR), seperti melakukan failover pada subset pipeline paling penting ke region lain jika terjadi kegagalan zonal atau regional.
  • Dependensi pipeline data. Beberapa pipeline data mengandalkan data yang dihasilkan oleh pipeline data lain. Saat membagi pipeline menjadi sprint migrasi, pastikan untuk mempertimbangkan dependensi data.
  • Set data yang dibuat dan digunakan. Untuk setiap pipeline data, identifikasi set data yang digunakan pipeline, dan set data yang dihasilkan. Dengan melakukannya, Anda dapat mengidentifikasi dependensi antara pipeline dan antara sistem atau komponen lain dalam arsitektur keseluruhan Anda.

Item berikut yang Anda nilai dalam inventaris berfokus pada set data yang akan dimigrasikan:

  • Dataset. Identifikasi set data yang perlu dimigrasikan ke lingkungan target. Anda dapat menganggap beberapa data historis tidak diperlukan untuk migrasi, atau akan dimigrasikan pada waktu yang berbeda, jika data tersebut diarsipkan dan tidak digunakan secara aktif. Dengan menentukan cakupan untuk proses migrasi dan sprint migrasi, Anda dapat mengurangi risiko dalam migrasi.
  • Ukuran data. Jika Anda berencana mengompresi file sebelum mentransfernya, pastikan untuk mencatat ukuran file sebelum dan sesudah kompresi. Ukuran data Anda akan memengaruhi waktu dan biaya yang diperlukan untuk menyalin data dari sumber ke tujuan. Mempertimbangkan faktor-faktor ini akan membantu Anda memilih di antara strategi periode nonaktif, seperti yang dijelaskan nanti dalam dokumen ini.
  • Struktur data. Klasifikasikan setiap set data yang akan dimigrasikan dan pastikan Anda memahami apakah data tersebut terstruktur, semi-terstruktur, atau tidak terstruktur. Memahami struktur data dapat memengaruhi strategi Anda dalam cara memverifikasi bahwa data dimigrasikan dengan benar dan lengkap.

Menyelesaikan penilaian

Setelah Anda mem-build inventaris yang terkait dengan cluster dan workload Kubernetes, selesaikan aktivitas fase penilaian lainnya di bagian Migrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Merencanakan dan membangun fondasi Anda

Fase perencanaan dan build untuk migrasi Anda ke Google Cloud terdiri dari tugas-tugas berikut:

  1. Mem-build hierarki resource.
  2. Konfigurasi Identity and Access Management (IAM).
  3. Menyiapkan penagihan.
  4. Menyiapkan konektivitas jaringan.
  5. Perketat keamanan Anda.
  6. Siapkan logging, pemantauan, dan pemberitahuan.

Untuk mengetahui informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Memigrasikan data dan pipeline data

Bagian berikut menjelaskan beberapa aspek rencana untuk memigrasikan data dan pipeline data batch. Bagian ini mendefinisikan beberapa konsep seputar karakteristik pipeline data yang penting untuk dipahami saat Anda membuat rencana migrasi. Dokumen ini juga membahas beberapa konsep pengujian data yang dapat membantu meningkatkan keyakinan Anda terhadap migrasi data.

Rencana migrasi

Dalam rencana migrasi, Anda harus menyertakan waktu untuk menyelesaikan transfer data. Rencana Anda harus memperhitungkan latensi jaringan, waktu untuk menguji kelengkapan data dan mendapatkan data yang gagal dimigrasikan, serta biaya jaringan. Karena data akan disalin dari satu region ke region lain, rencana biaya jaringan Anda harus mencakup biaya jaringan antar-region.

Sebaiknya bagi berbagai pipeline dan set data ke dalam sprint dan migrasikan secara terpisah. Pendekatan ini membantu mengurangi risiko untuk setiap sprint migrasi, dan memungkinkan peningkatan di setiap sprint. Untuk meningkatkan strategi migrasi dan menemukan masalah lebih awal, sebaiknya prioritaskan workload yang lebih kecil dan tidak penting, sebelum memigrasikan workload yang lebih besar dan lebih penting.

Bagian penting lain dari rencana migrasi adalah menjelaskan strategi, dependensi, dan sifat berbagai pipeline data dari lapisan komputasi. Jika lapisan penyimpanan data dan lapisan komputasi data Anda dibangun di sistem yang sama, sebaiknya Anda memantau performa sistem saat data disalin. Biasanya, tindakan menyalin data dalam jumlah besar dapat menyebabkan overhead I/O pada sistem dan menurunkan performa di lapisan komputasi. Misalnya, jika Anda menjalankan beban kerja untuk mengekstrak data dari cluster Kafka secara batch, operasi I/O tambahan untuk membaca data dalam jumlah besar dapat menyebabkan penurunan performa pada pipeline data aktif yang masih berjalan di lingkungan sumber. Dalam skenario semacam itu, Anda harus memantau performa sistem menggunakan metrik bawaan atau kustom. Untuk menghindari membebani sistem, sebaiknya Anda memiliki rencana untuk menonaktifkan beberapa beban kerja selama proses penyalinan data, atau untuk membatasi fase penyalinan.

Karena penyalinan data membuat migrasi menjadi proses yang berjalan lama, sebaiknya Anda memiliki rencana darurat untuk mengatasi apa pun yang mungkin salah selama migrasi. Misalnya, jika pergerakan data membutuhkan waktu lebih lama dari yang diharapkan atau jika pengujian integritas gagal sebelum Anda mengaktifkan sistem baru, pertimbangkan apakah Anda ingin melakukan roll back atau mencoba memperbaiki dan mencoba lagi operasi yang gagal. Meskipun pengembalian ke versi sebelumnya dapat menjadi solusi yang lebih bersih, menyalin set data besar beberapa kali dapat memakan waktu dan biaya. Sebaiknya Anda memiliki pemahaman yang jelas dan pengujian yang telah ditentukan sebelumnya untuk menentukan tindakan yang harus diambil dalam kondisi tertentu, berapa banyak waktu yang diperlukan untuk mencoba membuat patch, dan kapan harus melakukan rollback sepenuhnya.

Anda harus membedakan antara alat dan skrip yang Anda gunakan untuk migrasi, dan data yang Anda salin. Mengembalikan pergerakan data berarti Anda harus menyalin ulang data dan mengganti atau menghapus data yang telah Anda salin. Mengembalikan perubahan pada alat dan skrip berpotensi lebih mudah dan lebih murah, tetapi perubahan pada alat dapat memaksa Anda menyalin ulang data. Misalnya, Anda mungkin harus menyalin ulang data jika membuat jalur target baru dalam skrip yang menghasilkan lokasi Cloud Storage secara dinamis. Untuk membantu menghindari penyalinan ulang data, buat skrip Anda agar dapat dilanjutkan dan bersifat idempoten.

Karakteristik pipeline data

Untuk membuat rencana migrasi yang optimal, Anda perlu memahami karakteristik berbagai pipeline data. Penting untuk diingat bahwa pipeline batch yang menulis data berbeda dengan pipeline batch yang membaca data:

  • Pipeline data yang menulis data: Karena mengubah status sistem sumber, penulisan data ke lingkungan sumber pada saat yang sama dengan penyalinan data ke lingkungan target dapat menjadi sulit. Pertimbangkan runtime pipeline yang menulis data, dan coba prioritaskan migrasinya lebih awal dalam keseluruhan proses. Dengan melakukannya, Anda dapat menyiapkan data di lingkungan target sebelum memigrasikan pipeline yang membaca data.
  • Pipeline data yang membaca data: Pipeline yang membaca data mungkin memiliki persyaratan yang berbeda untuk keaktualan data. Jika pipeline yang menghasilkan data dihentikan di sistem sumber, pipeline yang membaca data mungkin dapat berjalan saat data disalin ke lingkungan target.

Data adalah status, dan menyalin data antar-region bukanlah operasi atomik. Oleh karena itu, Anda harus mengetahui perubahan status saat data sedang disalin.

Penting juga dalam rencana migrasi untuk membedakan antara sistem. Sistem Anda mungkin memiliki persyaratan fungsional dan non-fungsional yang berbeda (misalnya, satu sistem untuk batch dan sistem lainnya untuk streaming). Oleh karena itu, rencana Anda harus mencakup berbagai strategi untuk memigrasikan setiap sistem. Pastikan Anda menentukan dependensi antar-sistem dan menentukan cara mengurangi waktu nonaktif untuk setiap sistem selama setiap fase migrasi.

Rencana umum untuk sprint migrasi harus mencakup hal berikut:

  • Strategi umum. Jelaskan strategi untuk menangani migrasi dalam sprint ini. Untuk mengetahui strategi umum, lihat Men-deploy workload Anda.
  • Daftar alat dan metode untuk penyalinan data dan deployment resource. Tentukan alat apa pun yang akan Anda gunakan untuk menyalin data atau men-deploy resource ke lingkungan target. Daftar ini harus mencakup skrip kustom yang digunakan untuk menyalin aset Cloud Storage, alat standar seperti Google Cloud CLI, dan alat Google Cloud seperti Layanan Migrasi.
  • Daftar resource yang akan di-deploy ke lingkungan target. Mencantumkan semua resource yang perlu di-deploy di lingkungan target. Daftar ini harus mencakup semua komponen infrastruktur data seperti bucket Cloud Storage, set data BigQuery, dan cluster Dataproc. Dalam beberapa kasus, sprint migrasi awal akan mencakup deployment cluster yang disesuaikan ukurannya (seperti cluster Dataproc) dengan kapasitas yang lebih kecil, sementara sprint selanjutnya akan mencakup pengubahan ukuran agar sesuai dengan workload baru. Pastikan rencana Anda mencakup potensi pengubahan ukuran.
  • Daftar set data yang akan disalin. Untuk setiap set data, pastikan untuk menentukan informasi berikut:
    • Urutan dalam penyalinan (jika berlaku): Untuk sebagian besar strategi, urutan operasi mungkin penting. Pengecualiannya adalah strategi pemeliharaan terjadwal yang dijelaskan nanti dalam dokumen ini.
    • Ukuran
    • Statistik utama: Buat diagram statistik utama, seperti nomor baris, yang dapat membantu Anda memverifikasi bahwa set data berhasil disalin.
    • Perkiraan waktu untuk menyalin: Waktu untuk menyelesaikan transfer data Anda, berdasarkan rencana migrasi.
    • Metode untuk menyalin: Lihat daftar alat dan metode yang dijelaskan sebelumnya dalam dokumen ini.
    • Uji verifikasi: Cantumkan secara eksplisit pengujian yang akan Anda selesaikan untuk memverifikasi bahwa data telah disalin sepenuhnya.
    • Rencana darurat: Jelaskan apa yang harus dilakukan jika ada pengujian verifikasi yang gagal. Rencana darurat Anda harus menentukan kapan harus mencoba lagi dan melanjutkan penyalinan atau mengisi kesenjangan, dan kapan harus melakukan rollback lengkap dan menyalin ulang seluruh set data.

Pengujian

Bagian ini menjelaskan beberapa jenis pengujian umum yang dapat Anda rencanakan. Pengujian ini dapat membantu Anda memastikan integritas dan kelengkapan data. Mereka juga dapat membantu Anda memastikan bahwa lapisan komputasi berfungsi seperti yang diharapkan dan siap untuk menjalankan pipeline data Anda.

  • Perbandingan ringkasan atau hashing: Untuk memvalidasi kelengkapan data setelah menyalin data, Anda harus membandingkan set data asli dengan salinan baru di lingkungan target. Jika data disusun di dalam tabel BigQuery, Anda tidak dapat menggabungkan kedua tabel dalam kueri untuk melihat apakah semua data ada, karena tabel berada di region yang berbeda. Karena biaya dan latensi, BigQuery tidak mengizinkan kueri untuk menggabungkan data lintas region. Sebagai gantinya, metode perbandingan harus meringkas setiap {i>dataset<i} dan membandingkan hasilnya. Bergantung pada struktur set data, metode untuk meringkas mungkin berbeda. Misalnya, tabel BigQuery dapat menggunakan kueri agregasi, tetapi sekumpulan file di Cloud Storage dapat menggunakan pipeline Spark untuk menghitung hash setiap file, lalu menggabungkan hash tersebut.

  • Alur canary: Alur canary mengaktifkan tugas yang dibuat untuk memvalidasi integritas dan kelengkapan data. Sebelum Anda melanjutkan ke kasus penggunaan bisnis seperti analisis data, sebaiknya jalankan tugas alur canary untuk memastikan bahwa data input mematuhi serangkaian prasyarat. Anda dapat menerapkan alur canary sebagai pipeline data buatan khusus, atau sebagai alur dalam DAG berdasarkan Cloud Composer. Alur kanari dapat membantu Anda menyelesaikan tugas seperti memverifikasi bahwa tidak ada nilai yang hilang untuk kolom tertentu, atau memvalidasi bahwa jumlah baris set data tertentu cocok dengan jumlah yang diharapkan.

    Anda juga dapat menggunakan alur uji coba untuk membuat ringkasan atau agregasi lain dari kolom atau subset data. Kemudian, Anda dapat menggunakan alur uji coba untuk membandingkan data dengan ringkasan atau agregasi serupa yang diambil dari salinan data.

    Metode alur canary berguna saat Anda perlu mengevaluasi akurasi data yang disimpan dan disalin dalam format file, seperti file Avro di atas Cloud Storage. Alur canary biasanya tidak menghasilkan data baru, tetapi akan gagal jika serangkaian aturan tidak terpenuhi dalam data input.

  • Lingkungan pengujian: Setelah menyelesaikan rencana migrasi, Anda harus menguji rencana tersebut di lingkungan pengujian. Lingkungan pengujian harus mencakup penyalinan data yang diambil sampelnya atau data staging ke region lain, untuk memperkirakan waktu yang diperlukan untuk menyalin data melalui jaringan. Pengujian ini membantu Anda mengidentifikasi masalah apa pun pada rencana migrasi, dan membantu memverifikasi bahwa data dapat dimigrasikan dengan berhasil. Pengujian harus mencakup pengujian fungsional dan non-fungsional. Pengujian fungsional memastikan bahwa data dimigrasikan dengan benar. Pengujian non-fungsional memverifikasi bahwa migrasi memenuhi performa, keamanan, dan persyaratan non-fungsional lainnya. Setiap langkah migrasi dalam rencana Anda harus mencakup kriteria validasi yang menjelaskan kapan langkah tersebut dapat dianggap selesai.

Untuk membantu validasi data, Anda dapat menggunakan Alat Validasi Data (DVT). Alat ini menjalankan fungsi validasi data multi-level, dari tingkat tabel hingga tingkat baris, dan membantu Anda membandingkan hasil dari sistem sumber dan target.

Pengujian Anda harus memverifikasi deployment lapisan komputasi, dan menguji set data yang disalin. Salah satu cara untuk melakukannya adalah dengan membuat pipeline pengujian yang dapat menghitung beberapa agregasi set data yang disalin, dan memastikan set data sumber dan set data target cocok. Ketidakcocokan antara set data sumber dan target lebih sering terjadi saat file yang Anda salin antar-region bukan representasi salinan byte yang persis sama antara sistem sumber dan target (seperti saat Anda mengubah format file atau kompresi file).

Misalnya, pertimbangkan set data yang terdiri dari file JSON yang dibatasi baris baru. File disimpan di bucket Cloud Storage, dan dipasang sebagai tabel eksternal di BigQuery. Untuk mengurangi jumlah data yang dipindahkan melalui jaringan, Anda dapat melakukan kompresi Avro sebagai bagian dari migrasi, sebelum Anda menyalin file ke lingkungan target. Konversi ini memiliki banyak kelebihan, tetapi juga memiliki beberapa risiko, karena file yang ditulis ke lingkungan target bukanlah representasi salinan byte dari file di lingkungan sumber.

Untuk mengurangi risiko dari skenario konversi, Anda dapat membuat tugas Dataflow, atau menggunakan BigQuery untuk menghitung beberapa agregasi dan hash checksum set data (seperti dengan menghitung jumlah, rata-rata, atau kuantil untuk setiap kolom numerik). Untuk kolom string, Anda dapat menghitung agregasi di atas panjang string, atau di kode hash string tersebut. Untuk setiap baris, Anda dapat menghitung hash gabungan dari kombinasi semua kolom lainnya, yang dapat memverifikasi dengan akurasi tinggi bahwa satu baris sama dengan asalnya. Penghitungan ini dilakukan di lingkungan sumber dan target, lalu dibandingkan. Dalam beberapa kasus, seperti jika set data Anda disimpan di BigQuery, Anda tidak dapat menggabungkan tabel dari lingkungan sumber dan target karena berada di region yang berbeda, sehingga Anda perlu menggunakan klien yang dapat terhubung ke kedua lingkungan.

Anda dapat menerapkan metode pengujian sebelumnya di BigQuery atau sebagai tugas batch (seperti di Dataflow). Kemudian, Anda dapat menjalankan tugas agregasi dan membandingkan hasil yang dihitung untuk lingkungan sumber dengan hasil yang dihitung untuk lingkungan target. Pendekatan ini dapat membantu Anda memastikan bahwa data sudah lengkap dan akurat.

Aspek penting lainnya dalam menguji lapisan komputasi adalah menjalankan pipeline yang mencakup semua variasi mesin pemrosesan dan metode komputasi. Pengujian pipeline kurang penting untuk mesin komputasi terkelola seperti BigQuery atau Dataflow. Namun, penting untuk menguji pipeline untuk mesin komputasi yang tidak dikelola seperti Dataproc. Misalnya, jika Anda memiliki cluster Dataproc yang menangani beberapa jenis komputasi yang berbeda, seperti Apache Spark, Apache Hive, Apache Flink, atau Apache MapReduce, Anda harus menguji setiap runtime untuk memastikan bahwa berbagai jenis workload siap ditransfer.

Strategi migrasi

Setelah memverifikasi rencana migrasi dengan pengujian yang tepat, Anda dapat memigrasikan data. Saat memigrasikan data, Anda dapat menggunakan berbagai strategi untuk berbagai beban kerja. Berikut adalah contoh strategi migrasi yang dapat Anda gunakan apa adanya atau sesuaikan dengan kebutuhan Anda:

  • Pemeliharaan terjadwal: Anda merencanakan kapan periode migrasi sistem terjadi. Strategi ini bagus jika data sering diubah, tetapi SLO dan SLA dapat menahan beberapa periode nonaktif. Strategi ini menawarkan keyakinan tinggi terhadap data yang ditransfer karena data benar-benar tidak berlaku saat disalin. Untuk mengetahui informasi selengkapnya, lihat Pemeliharaan terjadwal di "Migrasi ke Google Cloud: Mentransfer set data besar Anda".
  • Pengalihan hanya baca: Sedikit variasi dari strategi pemeliharaan terjadwal, di mana platform data sistem sumber memungkinkan pipeline data hanya baca untuk terus membaca data saat data sedang disalin. Strategi ini berguna karena beberapa pipeline data dapat terus berfungsi dan memberikan insight ke sistem akhir. Kelemahan strategi ini adalah data yang dihasilkan menjadi tidak valid selama migrasi, karena data sumber tidak diperbarui. Oleh karena itu, Anda mungkin perlu menerapkan strategi mengejar ketertinggalan setelah migrasi, untuk memperhitungkan data yang tidak valid di sistem akhir.
  • Aktif sepenuhnya: Anda menyalin data pada stempel waktu tertentu, sementara lingkungan sumber masih aktif untuk pipeline data baca dan tulis. Setelah menyalin data dan beralih ke deployment baru, Anda melakukan fase penyalinan delta untuk mendapatkan data yang dihasilkan setelah stempel waktu migrasi di lingkungan sumber. Pendekatan ini memerlukan lebih banyak koordinasi dan pertimbangan dibandingkan strategi lainnya. Oleh karena itu, rencana migrasi Anda harus mencakup cara Anda akan menangani operasi update dan hapus pada data sumber.
  • Penulisan ganda: Data pipeline dapat berjalan di lingkungan sumber dan target, saat data sedang disalin. Strategi ini menghindari fase penyalinan delta yang diperlukan untuk mengisi ulang data jika Anda menggunakan strategi aktif sepenuhnya atau hanya baca. Namun, untuk membantu memastikan bahwa pipeline data menghasilkan hasil yang identik, strategi penulisan ganda memerlukan lebih banyak pengujian sebelum migrasi. Jika Anda tidak melakukan pengujian lanjutan, Anda akan mengalami masalah saat mencoba menggabungkan skenario split-brain. Strategi penulisan ganda juga menimbulkan potensi biaya untuk menjalankan workload yang sama dua kali di region yang berbeda. Strategi ini berpotensi memigrasikan platform Anda tanpa waktu henti, tetapi memerlukan koordinasi yang lebih besar untuk melaksanakannya dengan benar.

Pengujian pascamigrasi

Setelah migrasi selesai, Anda harus menguji kelengkapan data dan menguji pipeline data untuk mengetahui validitasnya. Jika Anda menyelesaikan migrasi dalam sprint, Anda harus melakukan pengujian ini setelah setiap sprint. Pengujian yang Anda lakukan pada tahap ini serupa dengan pengujian integrasi: Anda menguji validitas pipeline data yang menjalankan kasus penggunaan bisnis dengan data tingkat produksi penuh sebagai input, lalu Anda memeriksa validitas output. Anda dapat membandingkan output pengujian integrasi dengan output dari lingkungan sumber dengan menjalankan pipeline data yang sama di lingkungan sumber dan di lingkungan target. Jenis pengujian ini hanya berfungsi jika pipeline data bersifat deterministik, dan jika Anda dapat memastikan bahwa input ke kedua lingkungan tersebut identik.

Anda dapat mengonfirmasi bahwa data sudah lengkap jika memenuhi serangkaian kriteria yang telah ditentukan sebelumnya, dengan data di lingkungan sumber sama (atau cukup mirip) dengan data di lingkungan target. Bergantung pada strategi yang Anda gunakan dari bagian sebelumnya, data mungkin tidak cocok satu per satu. Oleh karena itu, Anda perlu menentukan kriteria terlebih dahulu untuk mendeskripsikan kelengkapan data untuk kasus penggunaan Anda. Misalnya, untuk data deret waktu, Anda dapat menganggap data sudah lengkap jika catatan terbaru tidak lebih dari lima menit di belakang stempel waktu saat ini.

Migrasi sistem

Setelah memverifikasi dan menguji data serta pipeline data di lingkungan target, Anda dapat memulai fase peralihan. Memulai fase ini berarti klien mungkin perlu mengubah konfigurasinya untuk mereferensikan sistem baru. Dalam beberapa kasus, konfigurasi tidak boleh sama dengan konfigurasi yang menunjuk ke sistem sumber. Misalnya, jika layanan perlu membaca data dari bucket Cloud Storage, klien perlu mengubah konfigurasi bucket yang akan digunakan. Nama bucket Cloud Storage bersifat unik secara global, sehingga bucket Cloud Storage lingkungan target akan berbeda dengan lingkungan sumber.

Selama fase pengalihan, Anda harus menonaktifkan dan membatalkan jadwal beban kerja lingkungan sumber. Sebaiknya Anda menyimpan data lingkungan sumber untuk beberapa waktu, jika Anda perlu membatalkan perubahan.

Fase pengujian pra-migrasi tidak selengkap proses produksi pipeline data. Oleh karena itu, setelah peralihan selesai dan sistem target beroperasi, Anda perlu memantau metrik, runtime, dan output semantik pipeline data. Pemantauan ini akan membantu Anda menemukan error yang mungkin terlewatkan selama fase pengujian, dan akan membantu memastikan keberhasilan migrasi.

Mengoptimalkan lingkungan Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda membuat lingkungan Anda lebih efisien dengan menjalankan beberapa iterasi dari loop berulang hingga lingkungan Anda memenuhi persyaratan pengoptimalan:

  1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
  2. Tetapkan persyaratan dan sasaran pengoptimalan Anda.
  3. Optimalkan lingkungan dan tim Anda.
  4. Sesuaikan loop pengoptimalan.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan lingkungan Google Cloud Anda, lihat Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Siapkan Google Cloud data dan sumber daya komputasi Anda untuk migrasi di berbagai region

Bagian ini memberikan ringkasan tentang data dan resource komputasi di Google Cloud serta prinsip desain untuk bersiap melakukan migrasi di berbagai region.

BigQuery

Karena BigQuery adalah data warehouse SQL serverless, Anda tidak perlu men-deploy lapisan komputasi. Jika beberapa klien BigQuery Anda menentukan region untuk pemrosesan, Anda harus menyesuaikan klien tersebut. Jika tidak, BigQuery sama di lingkungan sumber dan lingkungan target. Data BigQuery disimpan dalam dua jenis tabel:

  • Tabel BigQuery: Tabel dalam format BigQuery. BigQuery mengelola file data untuk Anda. Untuk mengetahui informasi selengkapnya tentang cara memigrasikan data dalam format BigQuery, lihat Mengelola set data.
  • Tabel eksternal BigQuery: Tabel yang datanya disimpan di luar BigQuery. Setelah data dipindahkan, Anda harus membuat ulang tabel eksternal di tujuan baru. Untuk mengetahui informasi selengkapnya tentang memigrasikan tabel eksternal, lihat Pengantar tabel eksternal.

Cloud Storage

Cloud Storage menawarkan Storage Transfer Service yang dapat membantu Anda memigrasikan data.

Dataflow (Batch)

Dataflow adalah mesin pemrosesan data yang dikelola Google. Untuk membantu menyederhanakan migrasi Dataflow dan memastikan tugas Anda dapat di-deploy ke region mana pun, Anda harus menyuntikkan semua input dan output sebagai parameter ke tugas Anda. Daripada menulis lokasi data input dan output dalam kode sumber, sebaiknya teruskan jalur Cloud Storage dan string koneksi database sebagai argumen atau parameter.

Dataproc

Dataproc adalah lingkungan Apache Hadoop terkelola yang dapat menjalankan beban kerja apa pun yang kompatibel dengan framework Apache Hadoop. Layanan ini kompatibel dengan framework seperti Apache Spark, Apache Flink, dan Apache Hive.

Anda dapat menggunakan Dataproc dengan cara berikut, yang memengaruhi cara Anda memigrasikan lingkungan Dataproc di seluruh region:

  • Cluster efemeral dengan data di Cloud Storage: Cluster dibuat untuk menjalankan tugas tertentu, dan akan dihancurkan setelah tugas selesai. Artinya, lapisan HDFS atau status cluster lainnya juga dihancurkan. Jika konfigurasi Anda memenuhi kriteria berikut, jenis penggunaan ini lebih mudah dimigrasikan dibandingkan dengan jenis penggunaan lainnya:
    • Input dan output ke tugas Anda tidak dikodekan secara permanen dalam kode sumber. Sebagai gantinya, tugas Anda menerima input dan output sebagai argumen.
    • Penyediaan lingkungan Dataproc dilakukan secara otomatis, termasuk konfigurasi untuk setiap framework yang digunakan lingkungan Anda.
  • Cluster yang berjalan lama dengan data eksternal: Anda memiliki satu atau beberapa cluster, tetapi cluster tersebut adalah cluster yang berjalan lama—meskipun tidak ada tugas yang berjalan di cluster, cluster tersebut tetap aktif dan berjalan. Data dan komputasi terpisah karena data disimpan di luar cluster pada solusi seperti Cloud Storage atau BigQuery.Google Cloud Model ini biasanya efektif jika selalu ada tugas yang berjalan di cluster, sehingga tidak masuk akal untuk menghentikan dan menyiapkan cluster seperti pada model sementara. Karena data dan komputasi terpisah, migrasi ini mirip dengan migrasi model sementara.
  • Cluster yang berjalan lama dengan data di dalam cluster: Cluster berjalan lama, tetapi cluster juga menyimpan status, data, atau keduanya, di dalam cluster, yang paling umum sebagai data di HDFS. Jenis penggunaan ini mempersulit upaya migrasi karena data dan komputasi tidak terpisah; jika Anda memigrasikan salah satunya tanpa yang lain, ada risiko tinggi terjadinya inkonsistensi. Dalam skenario ini, pertimbangkan untuk memindahkan data dan status di luar cluster sebelum migrasi, untuk memisahkan keduanya. Jika hal tersebut tidak memungkinkan, sebaiknya Anda menggunakan strategi pemeliharaan terjadwal untuk mengurangi risiko terjadinya inkonsistensi pada data Anda.

Karena ada banyak framework yang berpotensi, serta banyak versi dan konfigurasi framework tersebut, Anda harus melakukan pengujian secara menyeluruh sebelum menjalankan rencana migrasi.

Cloud Composer

Cloud Composer adalah versi terkelola Apache Airflow untuk orkestrasi dan penjadwalan alur kerja. Google CloudDAG, konfigurasi, dan log dikelola di bucket Cloud Storage yang harus dimigrasikan dengan deployment Cloud Composer Anda. Untuk memigrasikan status deployment Cloud Composer, Anda dapat menyimpan dan memuat snapshot lingkungan.

Jika Anda telah men-deploy plugin kustom ke instance Cloud Composer, sebaiknya terapkan metodologi infrastruktur sebagai code untuk membuat ulang lingkungan secara otomatis sepenuhnya.

Cloud Composer tidak mengelola data, tetapi mengaktifkan framework dan platform pemrosesan data lainnya. Oleh karena itu, migrasi Cloud Composer dapat sepenuhnya diisolasi dari data. Cloud Composer juga tidak memproses data, sehingga deployment Anda tidak perlu berada di region yang sama dengan data. Oleh karena itu, Anda dapat membuat deployment Cloud Composer di lingkungan target, dan tetap menjalankan pipeline di lingkungan sumber. Dalam beberapa kasus, tindakan ini dapat berguna untuk mengoperasikan pipeline yang berbeda di region yang berbeda saat seluruh platform dimigrasikan.

Cloud Data Fusion

Cloud Data Fusion adalah alat integrasi visual yang membantu Anda membangun pipeline data menggunakan editor visual. Cloud Data Fusion didasarkan pada project open source CDAP. Seperti Cloud Composer, Cloud Data Fusion tidak mengelola data itu sendiri, tetapi mengaktifkan framework dan platform pemrosesan data lainnya. Pipeline Cloud Data Fusion Anda harus diekspor dari lingkungan sumber dan diimpor ke lingkungan target dengan salah satu cara berikut:

Bergantung pada jumlah alur yang perlu Anda migrasikan, Anda mungkin lebih memilih satu metode daripada metode lainnya. Menggunakan CDAP API untuk membuat skrip migrasi mungkin sulit, dan memerlukan lebih banyak keterampilan rekayasa software. Namun, jika Anda memiliki banyak alur, atau jika alur berubah cukup sering, proses otomatis mungkin merupakan pendekatan terbaik.

Langkah Berikutnya

Kontributor

Penulis: Eyal Ben Ivri | Cloud Solutions Architect

Kontributor lain: Marco Ferrari | Cloud Solutions Architect