Dokumen ini menjelaskan cara meminimalkan dampak kegagalan tugas untuk pipeline batch besar. Kegagalan workload besar sangat berdampak karena waktu dan uang yang diperlukan untuk memulihkan dan memperbaiki kegagalan ini. Mencoba ulang pipeline ini dari awal saat gagal akan mahal dari segi waktu dan uang.
Untuk mengurangi kegagalan pipeline batch yang mahal, ikuti panduan di halaman ini. Karena Anda tidak selalu dapat sepenuhnya menghindari elemen yang gagal dan kegagalan pipeline, teknik yang diberikan berfokus pada peningkatan ketahanan, pengurangan biaya kegagalan, dan memudahkan proses debug dan memahami kegagalan saat terjadi.
Untuk mengetahui praktik terbaik pipeline umum, lihat Praktik terbaik pipeline Dataflow.
Menjalankan eksperimen kecil untuk tugas besar
Sebelum menjalankan tugas batch besar, jalankan satu atau beberapa tugas yang lebih kecil pada subset set data. Teknik ini dapat memberikan perkiraan biaya dan membantu menemukan potensi titik kegagalan.
Perkiraan biaya
Menjalankan eksperimen dapat memberikan perkiraan batas bawah total biaya menjalankan tugas. Biasanya, perhitungan biaya tugas adalah cost of test
job*size(full dataset)/size(test dataset). Bergantung pada pipeline, biaya dapat diskalakan superlinear atau, lebih jarang, sublinear. Namun, langkah ini sering kali memberikan perkiraan kasar yang baik tentang biaya tugas. Anda juga dapat mencoba berbagai ukuran input untuk mendapatkan perkiraan yang lebih baik tentang skala biaya Anda. Gunakan informasi ini untuk memutuskan apakah akan melanjutkan pipeline yang ada atau mendesain ulang pipeline untuk mengurangi biaya.
Menemukan titik kegagalan
Menjalankan eksperimen dapat mengekspos bug, potensi titik kegagalan, atau potensi masalah konfigurasi dan efisiensi. Anda juga dapat memeriksa metrik pipeline lainnya, seperti metrik berikut:
- Jika pipeline Anda menggunakan hampir semua memori yang tersedia, pipeline tersebut mungkin mengalami pengecualian kehabisan memori (OOM) di bawah beban yang lebih tinggi atau dengan kumpulan data yang sangat besar. Anda mungkin perlu menyediakan lebih banyak memori untuk tugas akhir guna menghindari error OOM ini.
- Jika pipeline Anda mengalami penurunan throughput, periksa log pipeline untuk menentukan alasannya. Anda mungkin menemukan elemen yang macet atau bagian dari set data Anda dengan performa yang sangat buruk. Anda dapat memproses titik data ini secara terpisah, atau Anda dapat menerapkan waktu tunggu saat memproses elemen. Untuk mengetahui informasi selengkapnya, lihat bagian Waktu tunggu kumpulan data mahal dalam dokumen ini.
- Jika performa pipeline Anda jauh lebih buruk pada tugas di Dataflow daripada di lokal, periksa logika pipeline untuk mengetahui alasannya. Misalnya, jika Anda mendapatkan throughput yang sama dengan delapan core di Dataflow seperti yang Anda dapatkan dengan satu core secara lokal, tugas mungkin mengalami bottleneck pada pertentangan untuk resource. Jika performa Anda lebih buruk dari yang diharapkan, pertimbangkan satu atau beberapa opsi berikut:
- Jalankan lebih banyak eksperimen dengan konfigurasi mesin atau software yang berbeda.
- Uji secara lokal dengan beberapa core secara bersamaan.
- Periksa kode Anda untuk menemukan potensi bottleneck saat men-deploy dalam skala besar.
Jika pipeline Anda memiliki rekomendasi Dataflow, ikuti rekomendasi tersebut untuk meningkatkan performa.
Menggunakan dead-letter queue untuk menangani data buruk yang tidak terduga
Pipeline sering kali berhasil pada sebagian besar elemen input, tetapi gagal pada subset kecil input. Anda mungkin tidak menemukan masalah ini saat menjalankan eksperimen kecil, karena eksperimen ini hanya menguji subset input. Secara default, Dataflow mencoba ulang tugas yang gagal ini empat kali dalam mode batch dan jumlah yang tidak terbatas dalam mode streaming. Dalam mode batch, setelah mencapai batas percobaan ulang, seluruh tugas Anda akan gagal. Dalam mode streaming, tugas dapat terhenti tanpa batas.
Dalam banyak tugas, Anda dapat mengecualikan elemen yang gagal ini dari pipeline dan menyelesaikan tugas lainnya menggunakan dead-letter queue (antrean pesan yang tidak diproses). Dead-letter queue meneruskan kumpulan data yang gagal ke output PCollection terpisah, yang dapat Anda kelola secara terpisah dari output utama. Konfigurasi ini memungkinkan Anda mendesain kebijakan untuk kumpulan data ini. Misalnya, Anda dapat menulisnya ke Pub/Sub secara manual, memeriksa dan membersihkannya, lalu memproses ulang kumpulan data.
Banyak transformasi Apache Beam menyertakan dukungan bawaan untuk dead-letter queue.
Di Java, Anda dapat mengaksesnya dengan objek ErrorHandler. Di Python, Anda dapat mengaksesnya menggunakan metode with_exception_handling. Beberapa transformasi memiliki cara kustom untuk menentukan dead-letter queue, yang dapat Anda baca di dokumentasi untuk transformasi. Untuk mengetahui informasi selengkapnya,
lihat Menggunakan dead-letter queue untuk penanganan error
handling.
Untuk menentukan apakah tugas Anda memenuhi kriteria untuk dead-letter queue, lihat bagian Batasan dalam dokumen ini.
Batasan dead-letter queue
Dalam skenario berikut, dead-letter queue mungkin tidak membantu:
- Kegagalan siklus proses worker atau
DoFnpenuh. Jika pemrosesan gagal untuk seluruh worker atau paket, dead-letter queue tidak dapat menangkap kegagalan tersebut. Misalnya, jika pipeline Anda mengalami pengecualian kehabisan memori (OOM), semua tugas aktif di VM akan gagal dan dicoba ulang, tanpa mengirim apa pun ke dead-letter queue. - Gabungan atau agregasi lainnya. Jika pipeline Anda melakukan komputasi yang mengharuskan semua elemen input ada dan diproses sebagai bagian dari hasil, berhati-hatilah saat menggunakan dead-letter queue sebelum langkah ini. Menggunakan dead-letter queue akan mengecualikan sebagian data input Anda dari hasil. Menambahkan dead-letter queue dapat menukar kebenaran dengan toleransi kesalahan.
- Kegagalan di jalur dead-letter queue. Jika elemen gagal saat dikirim ke sink dead-letter queue, seluruh pipeline dapat gagal.
Untuk menghindari kegagalan ini, pertahankan logika dead-letter queue Anda sesederhana mungkin. Anda dapat menambahkan langkah tunggu (lihat
wait class) untuk memastikan input utama selesai sebelum menulis elemen dead-letter queue. Konfigurasi ini dapat mengurangi performa dan menunda sinyal error dari pipeline Anda. - Elemen yang diubah sebagian. Jika Anda menyisipkan dead-letter queue di tengah pipeline, dead-letter queue mungkin akan menampilkan elemen yang diubah sebagian dan tidak memiliki akses ke elemen asli. Akibatnya, Anda tidak dapat membersihkan elemen dan menjalankan ulang pipeline terhadapnya. Sebagai gantinya, Anda mungkin perlu menerapkan logika yang berbeda untuk mengorelasikan output di dead-letter queue dengan elemen asli, atau Anda mungkin perlu menafsirkan dan memproses elemen yang diubah sebagian. Hal ini juga dapat menyebabkan hasil yang tidak konsisten. Misalnya, jika elemen dikirim ke dua cabang pipeline, dan setiap cabang mengirim elemen yang menyebabkan pengecualian ke dead-letter queue, satu elemen input mungkin akan masuk ke satu, yang lain, keduanya, atau tidak satu pun dari cabang tersebut.
Waktu tunggu kumpulan data mahal
Pipeline mungkin berhenti merespons saat memproses subset kecil elemen yang lebih mahal atau yang mencapai batasan yang menyebabkan tidak responsif, seperti deadlock. Untuk mengurangi masalah ini, beberapa transformasi memungkinkan Anda menetapkan waktu tunggu dan menggagalkan elemen yang waktu tunggunya habis di DoFn kode pengguna mana pun yang mengalami masalah ini. Misalnya, Anda dapat menggunakan metode with_exception_handling Python. Saat menggunakan waktu tunggu dengan dead-letter queue, pipeline Anda dapat terus memproses elemen yang sehat dan membuat progres, serta Anda dapat memproses ulang elemen yang mahal secara terpisah. Konfigurasi ini dapat menimbulkan biaya performa.
Untuk menentukan operasi DoFn mana yang mungkin memerlukan waktu tunggu, jalankan eksperimen kecil
sebelum meluncurkan pipeline lengkap.
Mengaktifkan Penskalaan Otomatis Vertikal
Jika Anda tidak yakin berapa banyak memori yang dibutuhkan tugas Anda atau merasa bahwa tugas Anda berisiko kehabisan memori, aktifkan Penskalaan Otomatis Vertikal. Fitur ini membantu menghindari kegagalan OOM saat pipeline berjalan dalam skala yang lebih besar atau saat menemukan elemen yang sangat besar.
Karena Penskalaan Otomatis Vertikal dapat meningkatkan biaya tugas Anda dan tidak mencegah semua kegagalan kehabisan memori, Anda tetap perlu mengatasi masalah konsumsi memori yang berlebihan. Penskalaan Otomatis Vertikal juga memerlukan Dataflow Prime, yang memiliki batasan tambahan dan model penagihan yang berbeda.
Menggunakan eksekusi spekulatif untuk menghindari straggler
Untuk pipeline batch, Anda dapat mengaktifkan eksekusi spekulatif, sebuah fitur untuk mengurangi dampak tugas yang berjalan lambat atau macet. Tugas yang lambat atau macet ini juga dikenal sebagai straggler. Fitur ini meluncurkan eksekusi tugas yang berlebihan, atau cadangan, yang memerlukan waktu terlalu lama. Tugas pertama yang selesai akan digunakan, dan tugas lainnya akan dibatalkan, yang dapat meningkatkan waktu penyelesaian keseluruhan pipeline Anda.
Eksekusi spekulatif dapat membantu pipeline selesai lebih cepat dengan menyediakan jalur eksekusi alternatif untuk item kerja yang mengalami penundaan karena mesin worker yang lambat atau masalah sementara lainnya seperti bug non-deterministik, throttling resource, atau masalah konektivitas.
Batasan dan pertimbangan
Sebelum mengaktifkan eksekusi spekulatif, pertimbangkan hal berikut:
- Pipeline streaming: Eksekusi spekulatif tidak didukung untuk pipeline streaming.
- Potensi perubahan biaya: Dampak biaya dari fitur ini sulit diperkirakan karena straggler dan penyediaan tugas cadangan sulit diprediksi. Misalnya, meskipun item kerja cadangan menggunakan resource tambahan, yang berpotensi meningkatkan biaya, penyelesaiannya yang lebih awal dapat menyebabkan penghematan resource dan pengurangan biaya. Dalam kedua skenario tersebut, dampak keseluruhan diperkirakan akan minimal.
- Item kerja yang berjalan lama dan konsisten: Eksekusi spekulatif mungkin tidak membantu item kerja yang berjalan lama dan konsisten secara signifikan seperti hot-key, karena masalah mendasar yang menyebabkan kelambatan akan tetap ada.
Untuk mengetahui informasi selengkapnya tentang straggler dalam tugas batch, lihat Memecahkan masalah straggler dalam tugas batch.
Mengaktifkan eksekusi spekulatif
Untuk mengaktifkan eksekusi spekulatif, gunakan opsi layanan Dataflow map_task_backup_mode. Ada dua mode yang tersedia:
Java
--dataflowServiceOptions=map_task_backup_mode=ON--dataflowServiceOptions=map_task_backup_mode=CAUTIOUS
Python / Go
--dataflow_service_options=map_task_backup_mode=ON--dataflow_service_options=map_task_backup_mode=CAUTIOUS
Dalam mode ON, tugas cadangan dijadwalkan jika runtime yang diharapkan dari tugas asli sekitar 20% lebih lama daripada runtime yang diharapkan dari tugas baru.
Dalam mode CAUTIOUS, tugas cadangan dijadwalkan jika runtime yang diharapkan dari tugas asli sekitar 70% lebih lama daripada runtime yang diharapkan dari tugas baru.
Untuk mengonfirmasi bahwa eksekusi spekulatif diaktifkan, periksa pesan log. Cari entri yang menunjukkan bahwa tugas cadangan diluncurkan. Hal ini mengonfirmasi bahwa eksekusi spekulatif dipicu. Untuk melihat log ini, buka panel Job Logs untuk pipeline Anda (Jobs > pilih tugas > bagian Logs > Job logs). Pesan log akan muncul sebagai berikut:
Backup issued in step STEP_NAME. ADDITIONAL_INFORMATION.
Solusi untuk pipeline yang rentan terhadap kegagalan
Beberapa pipeline sangat rentan terhadap error. Meskipun lebih baik mengatasi sumber error ini, untuk mengurangi biaya kegagalan, pertimbangkan opsi berikut.
Mewujudkan hasil menengah
Pipeline mungkin memiliki satu atau beberapa transformasi yang sangat mahal yang mendominasi waktu eksekusi pipeline. Kegagalan pipeline setelah transformasi ini dapat sangat berbahaya, karena semua pekerjaan yang telah selesai akan hilang. Untuk menghindari skenario ini, pertimbangkan untuk menulis PCollections menengah yang dihasilkan oleh langkah-langkah mahal ke sink seperti Cloud Storage. Konfigurasi ini mengurangi biaya kegagalan. Anda harus mempertimbangkan keunggulan ini terhadap biaya untuk melakukan penulisan tambahan. Anda dapat menggunakan hasil yang diwujudkan ini dengan salah satu cara berikut:
- Membagi pipeline asli Anda menjadi dua pipeline: satu yang menulis hasil menengah dan satu yang membacanya.
- Hanya jika terjadi kegagalan pipeline, baca dan ratakan hasil dari sumber asli dan koleksi menengah yang diwujudkan.
Untuk memastikan bahwa perwujudan ini ditulis sebelum pemrosesan lebih lanjut, tambahkan
langkah tunggu (lihat wait
class)
sebelum langkah pemrosesan berikutnya.