6 kemacetan tersembunyi dalam migrasi data cloud

Seth Noble adalah pendiri dan presiden Ekspedisi Data.

Memindahkan terabyte atau bahkan petabyte data ke cloud adalah tugas yang berat. Tetapi penting untuk melihat melampaui jumlah byte. Anda mungkin tahu bahwa aplikasi Anda akan berperilaku berbeda saat diakses di cloud, bahwa struktur biaya akan berbeda (mudah-mudahan lebih baik), dan perlu waktu untuk memindahkan semua data itu.

Karena perusahaan saya, Ekspedisi Data, menjalankan bisnis transfer data berperforma tinggi, pelanggan datang kepada kami saat mereka mengharapkan kecepatan jaringan menjadi masalah. Namun dalam proses membantu perusahaan mengatasi masalah itu, kami telah melihat banyak faktor lain yang mengancam untuk menggagalkan migrasi cloud jika dibiarkan.

Mengumpulkan, mengatur, memformat, dan memvalidasi data Anda dapat menghadirkan tantangan yang jauh lebih besar daripada memindahkannya. Berikut beberapa faktor umum yang perlu dipertimbangkan dalam tahap perencanaan migrasi cloud, sehingga Anda dapat menghindari masalah yang memakan waktu dan mahal nantinya.

Hambatan migrasi cloud # 1: Penyimpanan data

Kesalahan paling umum yang kami lihat dalam migrasi cloud adalah mendorong data ke penyimpanan cloud tanpa mempertimbangkan bagaimana data itu akan digunakan. Proses berpikir yang umum adalah, "Saya ingin meletakkan dokumen dan database saya di cloud dan penyimpanan objek itu murah, jadi saya akan meletakkan file dokumen dan database saya di sana." Tetapi file, objek, dan database berperilaku sangat berbeda. Menempatkan byte Anda ke yang salah dapat melumpuhkan paket cloud Anda.

File diatur oleh hierarki jalur, pohon direktori. Setiap file dapat diakses dengan cepat, dengan latensi minimal (waktu hingga byte pertama) dan kecepatan tinggi (bit per detik setelah data mulai mengalir). File individual dapat dengan mudah dipindahkan, diganti namanya, dan diubah ke tingkat byte. Anda dapat memiliki banyak file kecil, sejumlah kecil file besar, atau campuran ukuran dan tipe data. Aplikasi tradisional dapat mengakses file di cloud seperti yang mereka lakukan di lokasi, tanpa kesadaran cloud khusus.

Semua kelebihan ini menjadikan penyimpanan berbasis file sebagai opsi paling mahal, tetapi menyimpan file di cloud memiliki beberapa kelemahan lainnya. Untuk mencapai kinerja tinggi, sebagian besar sistem file berbasis cloud (seperti Amazon EBS) hanya dapat diakses oleh satu mesin virtual berbasis cloud pada satu waktu, yang berarti semua aplikasi yang memerlukan data tersebut harus dijalankan pada satu VM cloud. Untuk melayani banyak VM (seperti Azure Files) memerlukan fronting penyimpanan dengan protokol NAS (penyimpanan terpasang jaringan) seperti SMB, yang dapat sangat membatasi kinerja. Sistem file cepat, fleksibel, dan kompatibel dengan warisan, tetapi harganya mahal, hanya berguna untuk aplikasi yang berjalan di awan, dan tidak berskala dengan baik.

Objek bukanlah file. Ingatlah itu, karena mudah dilupakan. Objek tinggal di namespace datar, seperti satu direktori raksasa. Latensi tinggi, terkadang ratusan atau ribuan milidetik, dan throughput rendah, seringkali mencapai sekitar 150 megabit per detik kecuali trik cerdik digunakan. Banyak tentang mengakses objek bermuara pada trik pintar seperti unggahan multi bagian, akses rentang byte, dan pengoptimalan nama kunci. Objek dapat dibaca oleh banyak aplikasi berbasis cloud dan web sekaligus, baik dari dalam maupun luar cloud, tetapi aplikasi tradisional memerlukan solusi yang melumpuhkan kinerja. Sebagian besar antarmuka untuk mengakses penyimpanan objek membuat objek terlihat seperti file: nama kunci difilter dengan awalan agar terlihat seperti folder, metadata khusus dilampirkan ke objek agar tampak seperti file metadata,dan beberapa sistem seperti objek cache FUSE pada sistem file VM untuk memungkinkan akses oleh aplikasi tradisional. Tetapi solusi seperti itu rapuh dan kinerja getir. Penyimpanan cloud itu murah, skalabel, dan cloud native, tetapi juga lambat dan sulit diakses.

Database memiliki struktur kompleksnya sendiri, dan diakses oleh bahasa kueri seperti SQL. Database tradisional mungkin didukung oleh penyimpanan file, tetapi mereka memerlukan proses database langsung untuk melayani kueri. Ini dapat diangkat ke cloud dengan menyalin file database dan aplikasi ke VM, atau dengan memigrasi data ke layanan database yang dihosting di cloud. Tetapi menyalin file database ke penyimpanan objek hanya berguna sebagai cadangan offline. Skala basis data juga menjadi bagian dari layanan yang dihosting di awan, tetapi sangat penting untuk memastikan bahwa aplikasi dan proses yang bergantung pada basis data sepenuhnya kompatibel dan asli awan. Penyimpanan database sangat terspesialisasi dan khusus aplikasi.

Menyeimbangkan penghematan biaya penyimpanan objek terhadap fungsionalitas file dan database memerlukan pertimbangan yang cermat tentang fungsionalitas apa yang diperlukan. Misalnya, jika Anda ingin menyimpan dan mendistribusikan ribuan file kecil, arsipkan ke dalam file ZIP dan simpan sebagai objek tunggal daripada mencoba menyimpan setiap file sebagai objek terpisah. Pilihan penyimpanan yang salah dapat menyebabkan ketergantungan kompleks yang sulit dan mahal untuk diubah nanti.

Hambatan migrasi cloud # 2: Persiapan data

Memindahkan data ke cloud tidak sesederhana menyalin byte ke dalam jenis penyimpanan yang ditentukan. Banyak persiapan perlu dilakukan sebelum ada yang disalin, dan waktu itu membutuhkan penganggaran yang cermat. Proyek pembuktian konsep sering mengabaikan langkah ini, yang dapat mengakibatkan pembengkakan yang mahal nantinya.

Memfilter data yang tidak perlu dapat menghemat banyak waktu dan biaya penyimpanan. Misalnya, kumpulan data mungkin berisi cadangan, versi sebelumnya, atau file awal yang tidak perlu menjadi bagian dari alur kerja cloud. Mungkin bagian terpenting dari pemfilteran adalah memprioritaskan data mana yang perlu dipindahkan terlebih dahulu. Data yang sedang digunakan secara aktif tidak akan mentolerir ketidaksinkronan pada minggu, bulan, atau tahun yang diperlukan untuk menyelesaikan seluruh proses migrasi. Kuncinya di sini adalah menemukan cara otomatis untuk memilih data mana yang akan dikirim dan kapan, kemudian menyimpan catatan yang cermat tentang semua yang sudah dan tidak dilakukan.

Alur kerja cloud yang berbeda mungkin memerlukan data dalam format atau organisasi yang berbeda dari aplikasi lokal. Misalnya, alur kerja legal mungkin memerlukan penerjemahan ribuan dokumen Word atau PDF kecil dan mengemasnya dalam file ZIP, alur kerja media mungkin melibatkan transcoding dan pengemasan metadata, dan alur kerja bioinformatika mungkin memerlukan pengambilan dan pementasan terabyte data genomik. Pemformatan ulang semacam itu bisa menjadi proses yang sangat manual dan memakan waktu. Ini mungkin memerlukan banyak eksperimen, banyak penyimpanan sementara, dan banyak penanganan pengecualian. Terkadang Anda tergoda untuk menunda pemformatan ulang apa pun ke lingkungan cloud, tetapi ingat bahwa ini tidak menyelesaikan masalah, ini hanya mengalihkannya ke lingkungan di mana setiap sumber daya yang Anda gunakan memiliki harga.

Bagian dari pertanyaan penyimpanan dan pemformatan mungkin melibatkan keputusan tentang kompresi dan pengarsipan. Misalnya, masuk akal untuk membuat ZIP jutaan file teks kecil sebelum mengirimnya ke cloud, tetapi bukan file media multi-gigabyte. Mengarsipkan dan mengompresi data mempermudah transfer dan penyimpanan data, tetapi pertimbangkan waktu dan ruang penyimpanan yang diperlukan untuk mengemas dan membongkar arsip tersebut di kedua ujungnya.

Hambatan migrasi cloud # 3: Validasi informasi

Pemeriksaan integritas adalah satu-satunya langkah terpenting, dan juga yang paling mudah untuk salah. Seringkali diasumsikan bahwa korupsi akan terjadi selama pengiriman data, baik melalui media fisik atau transfer jaringan, dan dapat ditangkap dengan melakukan checksum sebelum dan sesudah. Checksum adalah bagian penting dari proses, tetapi sebenarnya ini adalah persiapan dan pengimporan data di mana Anda kemungkinan besar akan mengalami kerugian atau korupsi.

Ketika data mengubah format dan aplikasi, makna dan fungsionalitas dapat hilang bahkan ketika byte-nya sama. Ketidakcocokan sederhana antara versi perangkat lunak dapat membuat petabyte data "benar" menjadi tidak berguna. Menghasilkan proses yang dapat diskalakan untuk memverifikasi bahwa data Anda benar dan dapat digunakan bisa menjadi tugas yang menakutkan. Paling buruk, ini mungkin berubah menjadi proses manual yang padat karya dan tidak tepat "sepertinya tidak masalah bagi saya". Tetapi bahkan itu lebih baik daripada tidak ada validasi sama sekali. Yang paling penting adalah memastikan bahwa Anda akan dapat mengenali masalah sebelum sistem lama dinonaktifkan!

Hambatan migrasi cloud # 4: Transfer marshaling

Saat mengangkat satu sistem ke cloud, relatif mudah untuk hanya menyalin data yang disiapkan ke media fisik atau mendorongnya ke seluruh Internet. Tetapi proses ini bisa jadi sulit untuk diukur, terutama untuk media fisik. Apa yang tampak "sederhana" dalam bukti konsep dapat menggelembung menjadi "mimpi buruk" ketika banyak dan beragam sistem ikut bermain.

Perangkat media, seperti AWS Snowball, harus dihubungkan ke setiap mesin. Itu bisa berarti berjalan perangkat secara fisik di sekitar satu atau lebih pusat data, menyulap konektor, memperbarui driver, dan menginstal perangkat lunak. Menghubungkan melalui jaringan lokal menghemat pergerakan fisik, tetapi penyiapan perangkat lunak masih dapat menjadi tantangan dan kecepatan penyalinan mungkin turun jauh di bawah apa yang dapat dicapai dengan mengunggah langsung ke Internet. Mentransfer data secara langsung dari setiap mesin melalui Internet menghemat banyak langkah, terutama jika datanya sudah cloud-ready.

Jika persiapan data melibatkan penyalinan, ekspor, format ulang, atau pengarsipan, penyimpanan lokal dapat menjadi penghambat. Mungkin perlu untuk menyiapkan penyimpanan khusus untuk menyiapkan data. Ini memiliki keuntungan karena memungkinkan banyak sistem melakukan persiapan secara paralel, dan mengurangi titik kontak untuk media yang dapat dikirim dan perangkat lunak transfer data menjadi hanya satu sistem.

Hambatan migrasi cloud # 5: Transfer data

Saat membandingkan transfer jaringan dengan pengiriman media, mudah untuk berfokus hanya pada waktu pengiriman. Misalnya, perangkat AWS Snowball 80 terabyte dapat dikirim oleh kurir hari berikutnya, mencapai kecepatan data yang jelas lebih dari delapan gigabit per detik. Tetapi ini mengabaikan waktu yang diperlukan untuk memperoleh perangkat, mengonfigurasi dan memuatnya, menyiapkannya untuk dikembalikan, dan mengizinkan vendor cloud untuk menyalin data di back-end. Pelanggan kami yang melakukan ini secara teratur melaporkan bahwa waktu penyelesaian empat minggu (dari pemesanan perangkat hingga data yang tersedia di cloud) adalah umum. Itu membuat kecepatan transfer data aktual pengiriman perangkat turun menjadi hanya 300 megabit per detik, apalagi jika perangkat tidak terisi penuh.

Kecepatan transfer jaringan juga bergantung pada sejumlah faktor, terutama uplink lokal. Anda tidak dapat mengirim data lebih cepat daripada bit rate fisik, meskipun persiapan data yang cermat dapat mengurangi jumlah data yang perlu Anda kirim. Protokol lama, termasuk yang digunakan vendor cloud secara default untuk penyimpanan objek, mengalami kesulitan dengan kecepatan dan keandalan di jalur Internet jarak jauh, yang dapat mempersulit pencapaian bit rate tersebut. Saya dapat menulis banyak artikel tentang tantangan yang terlibat di sini, tetapi ini adalah salah satu yang tidak harus Anda selesaikan sendiri. Data Expedition adalah salah satu dari sedikit perusahaan yang berspesialisasi dalam memastikan bahwa jalur tersebut digunakan sepenuhnya terlepas dari seberapa jauh data Anda dari tujuan cloud-nya. Misalnya, koneksi Internet satu gigabit dengan perangkat lunak akselerasi seperti CloudDat menghasilkan 900 megabit per detik,tiga kali throughput bersih dari AWS Snowball.

Perbedaan terbesar antara pengiriman fisik dan transfer jaringan juga merupakan salah satu yang paling sering diabaikan selama pembuktian konsep. Dengan pengiriman fisik, byte pertama yang Anda muat ke perangkat harus menunggu hingga byte terakhir dimuat sebelum Anda dapat mengirim. Artinya, jika perlu berminggu-minggu untuk memuat perangkat, beberapa data Anda akan kedaluwarsa berminggu-minggu pada saat tiba di awan. Bahkan ketika kumpulan data mencapai tingkat petabyte di mana pengiriman fisik mungkin lebih cepat, kemampuan untuk menjaga data prioritas terkini selama proses migrasi mungkin masih mendukung transfer jaringan untuk aset utama. Perencanaan yang cermat selama fase pemfilteran dan pembuatan prioritas dari persiapan data sangat penting, dan memungkinkan untuk pendekatan hybrid.

Mendapatkan data ke penyedia cloud mungkin bukan akhir dari langkah transfer data. Jika perlu direplikasi ke beberapa wilayah atau penyedia, rencanakan dengan hati-hati bagaimana itu akan sampai di sana. Mengunggah melalui Internet gratis, sementara AWS, misalnya, mengenakan biaya hingga dua sen per gigabyte untuk transfer data antarwilayah dan sembilan sen per gigabyte untuk transfer ke vendor cloud lainnya. Kedua metode akan menghadapi batasan bandwidth yang dapat memanfaatkan akselerasi transportasi seperti CloudDat.

Hambatan migrasi cloud # 6: Penskalaan cloud

Setelah data tiba di tujuannya di cloud, proses migrasi baru setengah selesai. Checksum datang lebih dulu: Pastikan bahwa byte yang datang cocok dengan yang dikirim. Ini bisa jadi lebih rumit dari yang mungkin Anda sadari. Penyimpanan file menggunakan lapisan cache yang dapat menyembunyikan kerusakan data yang baru saja diunggah. Korupsi semacam itu jarang terjadi, tetapi hingga Anda membersihkan semua cache dan membaca kembali file, Anda tidak dapat memastikan checksum apa pun. Mem-boot ulang instance atau melepas penyimpanan melakukan pekerjaan yang dapat ditoleransi untuk membersihkan cache.

Memvalidasi checksum penyimpanan objek mengharuskan setiap objek dibaca menjadi instance untuk kalkulasi. Berlawanan dengan kepercayaan populer, objek "E-tag" tidak berguna sebagai checksum. Objek yang diunggah menggunakan teknik multi bagian secara khusus hanya dapat divalidasi dengan membacanya kembali.