Bermigrasi lintas 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 ekspansi mendatang ke region lain atau dari migrasi region ke region. Dokumen ini adalah bagian dari rangkaian yang membantu Anda memahami dampak dari memperluas platform data ke region lain. Panduan ini membantu Anda mempelajari cara melakukan hal-hal berikut:

  • Bersiaplah 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 lintas region atau untuk melakukan perluasan ke beberapa region terlebih dahulu. Dalam hal ini, Anda mungkin perlu melakukan upaya tambahan guna menyiapkan infrastruktur, beban kerja, dan data untuk migrasi di berbagai region dan untuk ekspansi ke beberapa region.

Dokumen ini adalah bagian dari rangkaian:

Seri 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 dijelaskan dalam bagian Migrasi ke Google Cloud: Memulai:

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

Platform data modern di Google Cloud

Bagian ini menjelaskan berbagai bagian platform data modern, dan cara pembuatannya biasanya dilakukan 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 berupa file yang Anda gunakan untuk mengelola byte aktual di sistem file seperti Hadoop Distributed File System (HDFS) atau Cloud Storage, atau Anda dapat menggunakan domain-specific language (DSL) untuk mengelola data di sistem pengelolaan database.
  • Lapisan komputasi data adalah pemrosesan data yang mungkin Anda aktifkan di atas sistem penyimpanan. Seperti lapisan penyimpanan, terdapat banyak kemungkinan implementasi, 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 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 tempat Anda memproses data.

Sebaiknya Anda juga memisahkan lapisan penyimpanan data dari lapisan komputasi data. Memisahkan lapisan-lapisan ini akan meningkatkan fleksibilitas Anda dalam mengubah lapisan komputasi dan memigrasikan data. Memisahkan lapisan juga akan mengurangi penggunaan resource karena Anda tidak perlu membuat lapisan komputasi berjalan sepanjang waktu. Oleh karena itu, sebaiknya 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 menentukan persyaratan dan dependensi untuk memigrasikan pipeline data batch yang telah Anda deploy:

  1. Bangun inventaris yang komprehensif dari pipeline data Anda.
  2. Katalogkan 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-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—lapisan penyimpanan dan berbagai 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 mem-build inventaris platform data, pertimbangkan hal berikut untuk setiap bagian infrastruktur data:

  • Lapisan penyimpanan. Bersama dengan 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 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 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 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. Penting bagi Anda untuk memahami waktu yang dibutuhkan untuk menyalin data. Anda juga perlu menguji latensi jaringan dari klien dan lingkungan eksternal (seperti lingkungan lokal) terhadap lingkungan target dibandingkan dengan lingkungan sumber.

  • Konfigurasi dan deployment. Setiap produk infrastruktur data memiliki metode pengaturan sendiri. Periksa 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 setiap komponen dikonfigurasi karena mesin komputasi mungkin berperilaku berbeda ketika 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 antar-versi. Perubahan konfigurasi seperti ini dapat menyebabkan perubahan pada output, serialisasi, dan komputasi.

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

  • Ukuran cluster. Untuk cluster yang dikelola sendiri, seperti cluster Dataproc yang tahan lama atau cluster Apache Kafka yang berjalan di Compute Engine, perhatikan 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 Anda membuat profil dan mengoptimalkan workload setelah men-deploy infrastruktur yang dimigrasikan ke produksi. Jika sebuah komponen terkelola sepenuhnya atau serverless (misalnya Dataflow), pengubahan ukuran akan menjadi bagian dari setiap tugas, 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 untuk pipeline data batch biasanya diukur secara tepat waktu hingga selesai, tetapi juga dapat diukur dengan cara lain, seperti daya komputasi yang digunakan. Metadata bisnis ini penting dalam mendorong proses kelangsungan bisnis dan disaster recovery plan (BCDR), seperti kegagalan pada sebagian pipeline paling penting Anda ke region lain jika terjadi kegagalan zona atau regional.
  • Dependensi pipeline data. Beberapa {i>data pipeline<i} bergantung pada data yang dihasilkan oleh data pipeline lain. Saat Anda 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 dihasilkannya. Dengan melakukannya, Anda dapat mengidentifikasi dependensi antara pipeline dan antara sistem atau komponen lain dalam arsitektur Anda 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 dapat menganggap beberapa data historis tidak diperlukan untuk migrasi, atau dimigrasikan pada waktu yang berbeda, jika data tersebut diarsipkan dan tidak digunakan secara aktif. Dengan menentukan ruang lingkup proses migrasi dan sprint migrasi, Anda dapat mengurangi risiko dalam migrasi.
  • Ukuran data. Jika Anda berencana untuk mengompresi file sebelum mentransfernya, pastikan untuk mencatat ukuran file sebelum dan sesudah kompresi. Ukuran data 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 akan 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 memberikan informasi ke strategi Anda terkait cara memverifikasi bahwa data dimigrasikan dengan benar dan lengkap.

Selesaikan penilaian

Setelah membuat inventaris yang terkait dengan cluster dan workload Kubernetes, selesaikan aktivitas lainnya dalam fase penilaian di bagian Migrasi ke Google Cloud: Menilai dan menemukan beban kerja.

Merencanakan dan membangun fondasi Anda

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

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

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

Memigrasikan data dan pipeline data

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

Rencana migrasi

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

Sebaiknya Anda membagi berbagai pipeline dan set data menjadi sprint dan memigrasikannya secara terpisah. Pendekatan ini membantu mengurangi risiko untuk setiap sprint migrasi, dan dapat meningkatkan performa setiap sprint. Untuk meningkatkan strategi migrasi dan menemukan masalah lebih awal, sebaiknya Anda memprioritaskan beban kerja yang lebih kecil dan non-kritis, sebelum memigrasikan beban kerja yang lebih besar dan lebih penting.

Bagian penting lainnya dari rencana migrasi adalah menjelaskan strategi, dependensi, dan sifat pipeline data yang berbeda dari lapisan komputasi. Jika lapisan penyimpanan data dan lapisan komputasi data Anda dibangun 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 pada 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 dengan menggunakan metrik bawaan atau kustom. Untuk menghindari kewalahan sistem, sebaiknya Anda berencana menonaktifkan beberapa beban kerja selama proses penyalinan data, atau untuk memperlambat fase penyalinan.

Karena menyalin data membuat migrasi menjadi proses yang berjalan lama, sebaiknya Anda memiliki rencana darurat 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 roll back atau mencoba memperbaiki dan mencoba lagi operasi yang gagal. Meskipun rollback dapat menjadi solusi yang lebih sederhana, melakukan penyalinan 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 apa, berapa lama waktu yang diberikan untuk mencoba membuat patch, dan kapan harus melakukan rollback lengkap.

Penting untuk membedakan antara alat dan skrip yang Anda gunakan untuk migrasi, dan data yang Anda salin. Dengan melakukan roll back pemindahan data, Anda harus menyalin ulang data dan mengganti atau menghapus data yang telah disalin. Melakukan roll back perubahan pada alat dan skrip berpotensi lebih mudah dan lebih murah, tetapi perubahan pada alat mungkin 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 agar dapat dilanjutkan 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 bersamaan saat data sedang disalin ke lingkungan target. Pertimbangkan runtime pipeline yang menulis data, dan cobalah untuk memprioritaskan migrasinya lebih awal dalam keseluruhan proses. Dengan begitu, Anda dapat menyiapkan data di lingkungan target sebelum memigrasikan pipeline yang membaca data tersebut.
  • 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 sedang 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 antar sistem. Sistem Anda mungkin memiliki persyaratan fungsional dan non-fungsional yang berbeda (misalnya, satu sistem untuk batch dan satu lagi untuk streaming). Oleh karena itu, rencana Anda harus menyertakan strategi yang berbeda untuk memigrasikan setiap sistem. Pastikan Anda menentukan dependensi antar-sistem dan menentukan cara mengurangi periode 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 {i>sprint<i} ini. Untuk mengetahui strategi umum, lihat Men-deploy workload.
  • 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 mencakup skrip kustom yang digunakan untuk menyalin aset Cloud Storage, alat standar seperti gsutil, dan alat Google Cloud seperti Layanan Migrasi.
  • Daftar resource yang akan di-deploy ke lingkungan target. Buat daftar 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 berukuran (seperti cluster Dataproc) dalam kapasitas yang lebih kecil, sedangkan sprint berikutnya akan mencakup pengubahan ukuran agar sesuai dengan workload baru. Pastikan bahwa rencana Anda memiliki potensi perubahan ukuran.
  • Daftar set data yang akan disalin. Untuk setiap set data, pastikan untuk menentukan informasi berikut:
    • Urutan yang disalin (jika berlaku): Untuk sebagian besar strategi, urutan operasi mungkin penting. Pengecualiannya adalah strategi pemeliharaan terjadwal yang akan dijelaskan kemudian dalam dokumen ini.
    • Ukuran
    • Key statistics: Statistik utama diagram, 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 untuk menyalin: Lihat daftar alat dan metode yang dijelaskan sebelumnya dalam dokumen ini.
    • Pengujian verifikasi: Mencantumkan pengujian yang ingin diselesaikan secara eksplisit untuk memverifikasi bahwa data disalin secara penuh.
    • Rencana darurat: Jelaskan apa yang harus dilakukan jika ada pengujian verifikasi yang gagal. Rencana darurat Anda harus menentukan kapan harus mencoba ulang dan melanjutkan penyalinan atau mengisi kesenjangan, serta kapan harus melakukan rollback lengkap dan menyalin ulang seluruh set data.

Pengujian

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

  • Ringkasan atau perbandingan hashing: Untuk memvalidasi kelengkapan data setelah menyalin data, Anda harus 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 lintas 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 sekumpulan file di Cloud Storage mungkin menggunakan pipeline Spark untuk menghitung hash dari setiap file, lalu menggabungkan hash.

  • Alur canary: Alur canary mengaktifkan tugas yang dibuat untuk memvalidasi integritas dan kelengkapan data. Sebelum Anda melanjutkan kasus penggunaan bisnis seperti analisis data, sebaiknya jalankan tugas alur canary untuk memastikan data input sesuai dengan serangkaian prasyarat. Anda dapat menerapkan alur canary sebagai pipeline data yang dibuat khusus, atau sebagai alur di 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 sesuai dengan jumlah yang diharapkan.

    Anda juga dapat menggunakan alur canary untuk membuat ringkasan atau agregasi lain dari kolom atau subset data. Anda kemudian dapat menggunakan alur canary untuk membandingkan data dengan ringkasan atau agregasi serupa yang diambil dari salinan data tersebut.

    Metode alur canary sangat berguna jika 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 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 apa pun terkait paket migrasi, dan membantu memverifikasi bahwa data dapat berhasil dimigrasikan. Pengujian harus mencakup 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 multilevel, mulai 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 pendekatan untuk melakukannya adalah dengan membuat pipeline pengujian yang dapat menghitung beberapa agregasi dari 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 antar 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 dibatasi baris baru. File tersebut 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 bukan merupakan 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. Kalkulasi ini dibuat di lingkungan sumber dan target, lalu dibandingkan. Dalam beberapa kasus, seperti jika set data disimpan di BigQuery, Anda tidak dapat menggabungkan tabel dari lingkungan sumber dan target karena berada di region yang berbeda. Jadi, Anda perlu menggunakan klien yang dapat terhubung ke kedua lingkungan.

Anda dapat mengimplementasikan metode pengujian sebelumnya, baik 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 untuk memastikan bahwa data lengkap dan akurat.

Aspek penting lainnya dalam pengujian lapisan komputasi adalah menjalankan pipeline yang mencakup semua variasi mesin pemrosesan dan metode komputasi. Menguji pipeline kurang penting untuk mesin komputasi terkelola, seperti BigQuery atau Dataflow. Namun, penting untuk menguji pipeline untuk mesin komputasi yang tidak terkelola seperti Dataproc. Misalnya, jika Anda memiliki cluster Dataproc yang menangani beberapa jenis komputasi berbeda, seperti Apache Spark, Apache Hive, Apache Flink, atau Apache MapReduce, Anda harus menguji setiap runtime untuk memastikan bahwa berbagai jenis workload tersebut 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 sebagaimana adanya atau disesuaikan dengan kebutuhan Anda:

  • Pemeliharaan terjadwal: Anda merencanakan saat periode penghentian layanan terjadi. Strategi ini cocok jika data sering diubah, tetapi SLO dan SLA dapat menahan periode nonaktif. Strategi ini memberikan keyakinan tinggi atas data yang ditransfer karena data tersebut benar-benar usang saat sedang disalin. Untuk mengetahui informasi selengkapnya, lihat Pemeliharaan terjadwal di "Migrasi ke Google Cloud: Mentransfer set data besar".
  • Cutover 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. Kekurangan dari strategi ini adalah data yang dihasilkan sudah usang selama migrasi karena data sumber tidak diperbarui. Oleh karena itu, Anda mungkin perlu menggunakan strategi pencarian setelah migrasi untuk memperhitungkan data yang sudah tidak berlaku di sistem akhir.
  • Aktif sepenuhnya: Anda menyalin data pada stempel waktu tertentu, sedangkan lingkungan sumber masih aktif untuk pipeline data baca dan tulis. Setelah menyalin data dan beralih ke deployment baru, Anda akan 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 lain. Oleh karena itu, rencana migrasi harus menyertakan cara menangani operasi pembaruan dan penghapusan pada data sumber.
  • Double-write: Pipeline data dapat berjalan di lingkungan sumber dan target, selagi data disalin. Strategi ini menghindari fase penyalinan delta yang diperlukan untuk mengisi ulang data jika Anda menggunakan strategi yang sepenuhnya aktif atau hanya baca. Namun, untuk membantu memastikan bahwa pipeline data memberikan hasil yang identik, strategi penulisan ganda memerlukan lebih banyak pengujian sebelum migrasi. Jika tidak melakukan pengujian lanjutan, Anda akan mengalami masalah saat mencoba mengonsolidasikan skenario otak terpisah. Strategi penulisan ganda juga memperkenalkan potensi biaya saat menjalankan workload yang sama dua kali di region berbeda. Strategi ini berpotensi memigrasikan platform Anda tanpa periode nonaktif, tetapi memerlukan koordinasi yang jauh lebih besar untuk menjalankannya dengan benar.

Pengujian pascamigrasi

Setelah migrasi selesai, Anda harus menguji kelengkapan data dan menguji validitasnya pipeline data. Jika menyelesaikan migrasi dalam sprint, Anda perlu melakukan pengujian ini setelah setiap sprint. Pengujian yang Anda lakukan dalam tahap ini mirip dengan pengujian integrasi: Anda menguji validitas pipeline data yang menjalankan kasus penggunaan bisnis dengan data tingkat produksi lengkap sebagai input, kemudian 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 untuk kedua lingkungan sama.

Anda dapat mengonfirmasi bahwa data sudah lengkap jika memenuhi kumpulan kriteria standar, dengan data di lingkungan sumber sama (atau cukup serupa) dengan data di lingkungan target. Bergantung pada strategi yang Anda gunakan dari bagian sebelumnya, data mungkin tidak cocok dengan one-to-one. Oleh karena itu, Anda harus menentukan terlebih dahulu kriteria untuk mendeskripsikan kelengkapan data untuk kasus penggunaan Anda. Misalnya, untuk data deret waktu, Anda dapat menganggap data tersebut lengkap ketika kumpulan data 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 konfigurasi mereka 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 bucket mana yang akan digunakan. Nama bucket Cloud Storage unik secara global, sehingga bucket Cloud Storage lingkungan target Anda akan berbeda dengan lingkungan sumber.

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

Fase pengujian pra-migrasi tidak selengkap proses produksi pipeline data. Oleh karena itu, setelah penghentian 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 yang dapat diulang hingga lingkungan Anda memenuhi persyaratan pengoptimalan:

  1. Evaluasi 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.

Menyiapkan data Google Cloud dan resource komputasi untuk migrasi lintas region

Bagian ini menyediakan ringkasan tentang resource komputasi dan data di Google Cloud serta prinsip-prinsip desain untuk menyiapkan migrasi lintas region.

BigQuery

Karena BigQuery adalah data warehouse SQL serverless, Anda tidak perlu men-deploy lapisan komputasi. Jika beberapa klien BigQuery Anda menentukan region untuk diproses, Anda perlu 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 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 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 dengan mudah ke region mana pun, Anda harus memasukkan semua input dan output sebagai parameter ke tugas Anda. Daripada menulis lokasi data input dan output di kode sumber, sebaiknya Anda meneruskan jalur Cloud Storage dan string koneksi database sebagai argumen atau parameter.

Dataproc

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

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

  • Cluster ephemeral dengan data di Cloud Storage: Cluster dibangun untuk menjalankan tugas tertentu, dan dihancurkan setelah tugas selesai. Artinya, lapisan HDFS atau status cluster lainnya juga akan 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 di-hardcode dalam kode sumber. Sebagai gantinya, tugas Anda menerima input dan output sebagai argumen.
    • Penyediaan lingkungan Dataproc bersifat otomatis, termasuk konfigurasi untuk setiap framework yang digunakan lingkungan Anda.
  • Cluster jangka panjang dengan data eksternal: Anda memiliki satu atau beberapa cluster, tetapi cluster tersebut berumur panjang—meskipun tidak ada tugas yang berjalan pada 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 ketika selalu ada tugas yang berjalan di cluster, sehingga tidak masuk akal untuk merobek dan menyiapkan cluster seperti dalam model efemeral. Karena data dan komputasi terpisah, migrasi serupa dengan migrasi model efemeral.
  • Cluster berumur panjang dengan data dalam cluster: Cluster ini berumur panjang, tetapi cluster juga menyimpan status, data, atau keduanya, di dalam cluster, paling sering sebagai data di HDFS. Jenis penggunaan ini mempersulit upaya migrasi karena data dan komputasi tidak terpisah; jika Anda memigrasikan satu perangkat tanpa yang lain, sangat berisiko menimbulkan inkonsistensi. Dalam skenario ini, pertimbangkan untuk memindahkan data dan status ke luar cluster sebelum migrasi untuk memisahkan keduanya. Jika tidak memungkinkan, sebaiknya gunakan strategi pemeliharaan terjadwal untuk mengurangi risiko timbulnya inkonsistensi dalam data Anda.

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

Cloud Composer

Cloud Composer adalah Apache Airflow versi terkelola dari 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 kode untuk membuat ulang lingkungan dengan cara yang sepenuhnya otomatis.

Cloud Composer tidak mengelola data, tetapi mengaktifkan framework dan platform pemrosesan data lainnya. Oleh karena itu, migrasi Cloud Composer dapat sepenuhnya terisolasi dari data. Cloud Composer juga tidak memproses data, sehingga deployment Anda tidak harus 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, hal ini dapat berguna untuk mengoperasikan pipeline yang berbeda di region yang berbeda saat seluruh platform sedang 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 datanya 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 satu metode daripada metode lainnya. Menggunakan CDAP API untuk membuat skrip migrasi mungkin sulit, dan memerlukan lebih banyak keterampilan software engineering. Namun, jika Anda memiliki banyak flow, atau jika flow relatif sering berubah, proses otomatis mungkin menjadi pendekatan terbaik.

Langkah Berikutnya

Kontributor

Penulis:

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, login ke LinkedIn.