Bermigrasi di berbagai region Google Cloud: Menyiapkan workload data dan batch untuk migrasi di berbagai region

Last reviewed 2023-12-08 UTC

Dokumen ini menjelaskan cara mendesain platform data di Google Cloud untuk meminimalkan dampak perluasan di masa mendatang ke region lain atau migrasi antar-region. Dokumen ini adalah bagian dari rangkaian yang membantu Anda memahami dampak perluasan platform data ke wilayah lain. Tutorial 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 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 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 artikel 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 platform tersebut biasanya dibuat di Google Cloud. Platform data sebagai konsep umum dapat dibagi menjadi dua bagian:

  • Lapisan penyimpanan data adalah tempat data disimpan. Data yang Anda simpan mungkin dalam bentuk file tempat Anda mengelola byte sebenarnya di sistem file seperti Hadoop Distributed File System (HDFS) atau Cloud Storage, atau Anda dapat menggunakan bahasa khusus domain (DSL) untuk mengelola data di sistem pengelolaan database.
  • Lapisan komputasi data adalah pemrosesan data apa pun yang mungkin Andaaktifkan di atas sistem penyimpanan. Seperti halnya lapisan penyimpanan, ada banyak kemungkinan implementasi, dan beberapa alat penyimpanan data juga menangani komputasi data. Peran lapisan komputasi data di platform ini adalah untuk 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 datanya, dan beberapa sistem komputasi data untuk lapisan pemrosesan datanya. Pada umumnya, lapisan penyimpanan data dan lapisan komputasi data dipisahkan. Misalnya, Anda mungkin telah menerapkan lapisan penyimpanan data menggunakan layanan Google Cloud berikut:

Anda mungkin telah menerapkan lapisan komputasi data menggunakan layanan Google Cloud lainnya seperti ini:

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 mengurangi penggunaan resource karena Anda tidak perlu terus menjalankan lapisan komputasi sepanjang waktu. Oleh karena itu, sebaiknya Anda men-deploy penyimpanan data dan komputasi data di platform terpisah di 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 yang komprehensif untuk pipeline data Anda.
  2. Buat katalog pipeline Anda sesuai dengan properti dan dependensinya.
  3. Latih dan ajari tim Anda di 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 Bermigrasi 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 di-deploy:

  1. Buat inventaris infrastruktur data—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 sedang dibaca oleh pipeline data dan yang perlu dimigrasikan.

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

  • Lapisan penyimpanan. Bersama dengan platform penyimpanan standar seperti Cloud Storage, pertimbangkan lapisan penyimpanan lainnya seperti database seperti Firebase, BigQuery, Bigtable, dan Postgres, atau cluster lainnya seperti Apache Kafka. Setiap platform penyimpanan memiliki strategi dan metodenya 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. Praktikkan dan verifikasi proses transfer data teknis untuk setiap platform penyimpanan yang terlibat.
  • Lapisan komputasi. Untuk setiap platform komputasi, verifikasi rencana deployment dan verifikasi perubahan konfigurasi apa pun yang mungkin telah Anda lakukan pada berbagai platform.
  • Latensi jaringan. Uji dan verifikasi latensi jaringan antara lingkungan sumber dan lingkungan target. Anda harus memahami berapa lama waktu yang diperlukan 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 Anda buat untuk setiap komponen, dan komponen mana yang versi defaultnya Anda gunakan 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 setiap komponen dikonfigurasi karena mesin komputasi mungkin berperilaku berbeda jika dikonfigurasi secara berbeda—terutama jika framework lapisan pemrosesan berubah selama migrasi. Misalnya, jika lingkungan target menjalankan versi Apache Spark yang berbeda, beberapa konfigurasi framework Spark mungkin telah berubah antarversi. Jenis perubahan konfigurasi 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 memiliki pengujian yang memvalidasi output data yang dihitung framework.

  • Ukuran cluster. Untuk cluster yang dikelola sendiri, seperti cluster Dataproc yang berumur panjang 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 mengakibatkan perubahan pada prosesor yang digunakan deployment Anda. Oleh karena itu, sebaiknya Anda membuat profil dan mengoptimalkan beban kerja setelah men-deploy infrastruktur yang dimigrasikan ke produksi. Jika komponen dikelola sepenuhnya atau tanpa server (misalnya Dataflow), 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 data dan sink. Pastikan untuk memperhitungkan sumber dan sink 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 kekuatan komputasi yang digunakan. Metadata bisnis ini penting dalam mendorong proses kontinuitas bisnis dan rencana pemulihan dari bencana (BCDR), seperti kegagalan sebagian pipeline yang 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 Anda membagi pipeline menjadi sprint migrasi, pastikan untuk mempertimbangkan dependensi data.
  • Set data yang dihasilkan dan digunakan. Untuk setiap pipeline data, identifikasi set data yang digunakan pipeline, dan set data yang dihasilkannya. Tindakan tersebut dapat membantu Anda mengidentifikasi dependensi antara pipeline dan antara sistem atau komponen lain dalam arsitektur secara keseluruhan.

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

  • Set data. Identifikasi set data yang perlu dimigrasikan ke lingkungan target. Anda mungkin menganggap beberapa data historis tidak diperlukan untuk migrasi, atau untuk 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 antara strategi downtime, seperti yang akan dijelaskan nanti dalam dokumen ini.
  • Struktur data. Klasifikasikan setiap set data yang akan dimigrasikan dan pastikan bahwa Anda memahami apakah data tersebut terstruktur, semi-terstruktur, atau tidak terstruktur. Memahami struktur data dapat menginformasikan strategi Anda tentang 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. Mengonfigurasi 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. Panduan ini menentukan beberapa konsep seputar karakteristik pipeline data yang penting untuk dipahami saat Anda membuat rencana migrasi. Panduan ini juga membahas beberapa konsep pengujian data yang dapat membantu meningkatkan kepercayaan Anda pada migrasi data.

Rencana migrasi

Dalam rencana migrasi, Anda perlu 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 apa pun. Karena data akan disalin dari satu region ke region lain, rencana biaya jaringan Anda harus menyertakan biaya jaringan antar-region.

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

Bagian penting lainnya dari rencana migrasi adalah menjelaskan strategi, dependensi, dan sifat berbagai pipeline data dari lapisan komputasi. Jika lapisan penyimpanan data dan lapisan komputasi data Anda dibuat di sistem yang sama, sebaiknya pantau performa sistem saat data sedang 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 kelebihan beban sistem, sebaiknya Anda memiliki rencana untuk menonaktifkan beberapa beban kerja selama proses penyalinan data, atau untuk mengurangi fase penyalinan.

Karena menyalin data membuat migrasi menjadi proses yang berjalan lama, sebaiknya Anda memiliki rencana cadangan untuk mengatasi masalah yang mungkin terjadi selama migrasi. Misalnya, jika pemindahan data memerlukan waktu lebih lama dari yang diperkirakan atau jika pengujian integritas gagal sebelum Anda mengaktifkan sistem baru, pertimbangkan apakah Anda ingin melakukan rollback atau mencoba memperbaiki dan mencoba kembali operasi yang gagal. Meskipun rollback 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 standar untuk menentukan tindakan yang akan dilakukan dalam kondisi tertentu, berapa lama waktu yang diizinkan untuk mencoba membuat patch, dan kapan harus melakukan rollback lengkap.

Anda harus membedakan antara alat dan skrip yang Anda gunakan untuk migrasi, dan data yang Anda salin. Dengan melakukan rollback pergerakan data, Anda harus menyalin ulang data dan mengganti atau menghapus data yang telah disalin. Melakukan rollback perubahan pada alat dan skrip mungkin lebih mudah dan lebih murah, tetapi perubahan pada alat mungkin memaksa Anda untuk 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, build skrip Anda agar memungkinkan lanjutan dan idempotensi.

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, akan sulit untuk menulis data ke lingkungan sumber saat data disalin ke lingkungan target. Pertimbangkan runtime pipeline yang menulis data, dan coba prioritaskan migrasinya lebih awal dalam keseluruhan proses. Dengan demikian, Anda akan memiliki data yang siap di lingkungan target sebelum memigrasikan pipeline yang membaca data.
  • Data pipeline 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 perlu mengetahui perubahan status saat data disalin.

Dalam rencana migrasi, Anda juga harus 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 menyertakan strategi yang berbeda untuk memigrasikan setiap sistem. Pastikan Anda menentukan dependensi antarsistem dan menentukan cara mengurangi downtime 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 strategi umum, lihat Men-deploy workload Anda.
  • Daftar alat dan metode untuk penyalinan data dan deployment resource. Tentukan alat yang ingin Anda gunakan untuk menyalin data atau men-deploy resource ke lingkungan target. Daftar ini harus menyertakan 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. Cantumkan semua resource yang perlu di-deploy di lingkungan target. Daftar ini harus menyertakan semua komponen infrastruktur data seperti bucket Cloud Storage, set data BigQuery, dan cluster Dataproc. Dalam beberapa kasus, sprint migrasi awal akan mencakup deployment cluster berukuran (seperti cluster Dataproc) dalam kapasitas yang lebih kecil, sedangkan sprint berikutnya 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. Pengecualian adalah strategi pemeliharaan terjadwal yang dijelaskan nanti dalam dokumen ini.
    • Ukuran
    • Statistik utama: Diagram statistik utama, seperti nomor baris, yang dapat membantu Anda memverifikasi bahwa set data berhasil disalin.
    • Estimasi waktu untuk menyalin: Waktu untuk menyelesaikan transfer data, berdasarkan rencana migrasi.
    • Metode yang akan disalin: Lihat daftar alat dan metode yang dijelaskan sebelumnya dalam dokumen ini.
    • Pengujian verifikasi: Cantumkan secara eksplisit pengujian yang ingin Anda selesaikan untuk memverifikasi bahwa data disalin sepenuhnya.
    • Rencana darurat: Jelaskan tindakan yang harus dilakukan jika pengujian verifikasi gagal. Rencana cadangan 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. Hal ini juga dapat membantu Anda memastikan bahwa lapisan komputasi berfungsi seperti yang diharapkan dan siap menjalankan pipeline data Anda.

  • Perbandingan ringkasan atau hashing: Untuk memvalidasi kelengkapan data setelah menyalin data, Anda perlu membandingkan set data asli dengan salinan baru di lingkungan target. Jika data terstruktur 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 di seluruh region. Sebagai gantinya, metode perbandingan harus meringkas setiap set data dan membandingkan hasilnya. Bergantung pada struktur set data, metode untuk meringkas mungkin berbeda. Misalnya, tabel BigQuery mungkin menggunakan kueri agregasi, tetapi kumpulan file di Cloud Storage mungkin menggunakan pipeline Spark untuk menghitung hash setiap file, lalu menggabungkan hash.

  • Alur canary: Alur canary mengaktifkan tugas yang dibuat untuk memvalidasi integritas dan kelengkapan data. Sebelum melanjutkan ke kasus penggunaan bisnis seperti analisis data, sebaiknya jalankan tugas alur canary untuk memastikan data input mematuhi serangkaian prasyarat. Anda dapat menerapkan alur canary sebagai pipeline data buatan khusus, atau sebagai alur dalam DAG berdasarkan Cloud Composer. Alur Canary 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 canary untuk membuat ringkasan atau agregasi lain dari kolom atau subkumpulan data. Kemudian, Anda dapat menggunakan alur canary untuk membandingkan data dengan ringkasan atau agregasi serupa yang diambil dari salinan data.

    Metode alur Canary sangat berharga 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 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 sampel atau data staging ke region lain, untuk memperkirakan waktu yang diperlukan untuk menyalin data melalui jaringan. Pengujian ini membantu Anda mengidentifikasi masalah pada rencana migrasi, dan membantu memverifikasi bahwa data dapat dimigrasikan dengan sukses. Pengujian harus menyertakan pengujian fungsional dan non-fungsional. Pengujian fungsional memverifikasi bahwa data dimigrasikan dengan benar. Pengujian non-fungsional memverifikasi bahwa migrasi memenuhi persyaratan performa, keamanan, dan non-fungsional lainnya. Setiap langkah migrasi dalam rencana Anda harus menyertakan 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 ke 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 pendekatan untuk melakukannya adalah 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 umum terjadi jika file yang Anda salin di antara region bukan representasi salinan byte yang tepat antara sistem sumber dan target (seperti saat Anda mengubah format file atau kompresi file).

Misalnya, pertimbangkan set data yang terdiri dari file JSON yang dipisahkan 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 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 pada 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 tersebut.

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 beban kerja siap untuk ditransfer.

Strategi migrasi

Setelah memverifikasi rencana migrasi dengan pengujian yang tepat, Anda dapat memigrasikan data. Saat memigrasikan data, Anda dapat menggunakan strategi yang berbeda untuk beban kerja yang berbeda. 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 sudah tidak berlaku saat disalin. Untuk mengetahui informasi selengkapnya, lihat Pemeliharaan terjadwal dalam "Migrasi ke Google Cloud: Mentransfer set data besar".
  • Pemindahan hanya baca: Sedikit variasi dari strategi pemeliharaan terjadwal, dengan 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 sudah tidak berlaku selama migrasi, karena data sumber tidak diperbarui. Oleh karena itu, Anda mungkin perlu menerapkan strategi mengejar setelah migrasi, untuk memperhitungkan data yang sudah tidak berlaku di sistem akhir.
  • Sempurna aktif: 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 akan melakukan fase salinan 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 menyertakan cara Anda menangani operasi update dan penghapusan pada data sumber.
  • Penulisan ganda: Data pipeline dapat berjalan di lingkungan sumber dan target, saat data sedang disalin. Strategi ini menghindari fase salinan delta yang diperlukan untuk mengisi ulang data jika Anda menggunakan strategi yang sepenuhnya aktif atau hanya baca. Namun, untuk membantu memastikan bahwa pipeline data menghasilkan hasil yang identik, strategi penulisan ganda memerlukan pengujian lebih lanjut sebelum migrasi. Jika 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 memiliki potensi untuk memigrasikan platform Anda tanpa downtime, tetapi memerlukan lebih banyak koordinasi untuk menjalankannya dengan benar.

Pengujian pasca-migrasi

Setelah migrasi selesai, Anda harus menguji kelengkapan data dan menguji validitas pipeline data. Jika menyelesaikan migrasi dalam sprint, Anda perlu melakukan pengujian ini setelah setiap sprint. Pengujian yang Anda lakukan pada tahap ini mirip dengan pengujian integrasi: Anda menguji validitas pipeline data yang menjalankan kasus penggunaan bisnis dengan data tingkat produksi penuh sebagai input, lalu 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, 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 harus menentukan kriteria sebelumnya untuk mendeskripsikan kelengkapan data untuk kasus penggunaan Anda. Misalnya, untuk data deret waktu, Anda dapat menganggap data sudah lengkap jika data terbaru tidak lebih dari lima menit setelah stempel waktu saat ini.

Migrasi sistem

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

Selama fase peralihan, Anda harus menghentikan dan membatalkan penjadwalan workload lingkungan sumber. Sebaiknya simpan data lingkungan sumber selama beberapa waktu, jika Anda perlu melakukan rollback.

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

Mengoptimalkan lingkungan Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda membuat lingkungan lebih efisien dengan menjalankan beberapa iterasi 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, lihat Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Menyiapkan data dan resource komputasi Google Cloud Anda untuk migrasi di berbagai region

Bagian ini memberikan ringkasan tentang resource data dan komputasi di Google Cloud serta prinsip desain untuk mempersiapkan migrasi di seluruh 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 akan 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 informasi selengkapnya tentang cara 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 dapat di-deploy dengan mudah ke region mana pun, Anda harus memasukkan semua input dan output sebagai parameter ke tugas. 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. Framework 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 cluster akan dihancurkan setelah tugas selesai. Hal ini berarti bahwa lapisan HDFS atau status cluster lainnya juga dihancurkan. Jika konfigurasi Anda memenuhi kriteria berikut, jenis penggunaan ini akan lebih mudah dimigrasikan dibandingkan dengan jenis penggunaan lainnya:
    • Input dan output ke tugas Anda tidak di-hardcode dalam kode sumber. Sebagai gantinya, tugas Anda menerima input dan output sebagai argumen.
    • Penyediaan lingkungan Dataproc otomatis, termasuk konfigurasi untuk setiap framework yang digunakan lingkungan Anda.
  • Cluster berumur panjang dengan data eksternal: Anda memiliki satu atau beberapa cluster, tetapi cluster tersebut adalah cluster berumur panjang—meskipun tidak ada tugas yang berjalan di cluster, cluster tersebut masih aktif dan berjalan. Data dan komputasi terpisah karena data disimpan di luar cluster pada solusi Google Cloud seperti Cloud Storage atau BigQuery. Model ini biasanya efektif jika selalu ada tugas yang berjalan di cluster, sehingga tidak masuk akal untuk meruntuhkan dan menyiapkan cluster seperti dalam model sementara. Karena data dan komputasi terpisah, migrasi ini mirip dengan migrasi model sementara.
  • Cluster yang berumur panjang dengan data dalam cluster: Cluster berumur panjang, tetapi cluster juga menyimpan status, data, atau keduanya, di dalam cluster, biasanya 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 untuk membuat inkonsistensi. Dalam skenario ini, pertimbangkan untuk memindahkan data dan status ke luar cluster sebelum migrasi, untuk memisahkan keduanya. Jika tidak memungkinkan, sebaiknya Anda menggunakan strategi pemeliharaan terjadwal untuk mengurangi risiko terjadinya inkonsistensi dalam data Anda.

Karena ada banyak potensi framework, serta banyak versi dan konfigurasi framework tersebut, Anda perlu menguji secara menyeluruh sebelum menjalankan rencana migrasi.

Cloud Composer

Cloud Composer adalah Apache Airflow versi terkelola Google Cloud, untuk orkestrasi dan penjadwalan alur. DAG, 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 berbagai region saat seluruh platform dimigrasikan.

Cloud Data Fusion

Cloud Data Fusion adalah alat integrasi visual yang membantu Anda membuat 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 dimigrasikan, Anda mungkin lebih memilih salah satu metode. Menggunakan CDAP API untuk membuat skrip migrasi mungkin sulit, dan memerlukan lebih banyak keterampilan software engineering. Namun, jika Anda memiliki banyak alur, atau jika alur berubah relatif sering, proses otomatis mungkin merupakan pendekatan terbaik.

Langkah Berikutnya

Kontributor

Penulis: Eyal Ben Ivri | Cloud Solutions Architect

Kontributor lainnya: Marco Ferrari | Cloud Solutions Architect