Mendesain alur kerja pipeline Dataflow

Pengembangan pipeline melibatkan berbagai tahap dan tugas, seperti pengembangan kode, pengujian, dan pengiriman ke produksi. Dokumen ini menjelaskan:

• Pertimbangan untuk continuous integration dan continuous delivery (CI/CD) guna mendukung build, pengujian, dan deployment pipeline otomatis ke lingkungan yang berbeda.
• Fitur Dataflow untuk mengoptimalkan performa dan penggunaan resource dalam produksi.
• Pendekatan dan titik pengamatan untuk memperbarui pipeline streaming dalam produksi.
• Praktik terbaik untuk meningkatkan keandalan pipeline dalam produksi.

Continuous integration

Continuous integration (CI) mewajibkan developer untuk menggabungkan kode ke repositori bersama secara rutin, yang berguna untuk aplikasi yang sering berubah, seperti situs yang sering diupdate. Meskipun pipeline data biasanya tidak banyak berubah seperti jenis aplikasi lainnya, praktik CI memberikan banyak manfaat untuk pengembangan pipeline. Misalnya, otomatisasi pengujian memberikan masukan cepat saat ditemukan kerusakan dan mengurangi kemungkinan regresi memasuki codebase.

Otomatisasi pengujian adalah bagian penting dari CI. Jika dikombinasikan dengan cakupan pengujian yang sesuai, otomatisasi pengujian akan menjalankan rangkaian pengujian Anda pada setiap commit kode. Server CI Anda dapat bekerja bersama dengan alat otomatisasi build seperti Maven untuk menjalankan test suite Anda sebagai satu atau beberapa langkah pipeline CI. Anda dapat mengemas kode yang berhasil lulus pengujian unit dan pengujian integrasi ke dalam artefak deployment dari tempat pipeline diluncurkan. Build ini disebut sebagai build lulus.

Jumlah dan jenis artefak deployment yang dibuat dari build yang lulus bervariasi bergantung pada cara pipeline diluncurkan. Dengan menggunakan Apache Beam Java SDK, Anda dapat mengemas kode pipeline ke dalam file JAR yang dapat dieksekusi sendiri. Kemudian, Anda dapat menyimpan file JAR di bucket yang dihosting di project untuk lingkungan deployment, seperti project praproduksi atau produksi Google Cloud . Jika Anda menggunakan Template Klasik (jenis eksekusi berbasis template), artefak deployment mencakup file template JSON, file JAR untuk pipeline, dan template metadata opsional. Kemudian, Anda dapat men-deploy artefak ke lingkungan deployment yang berbeda menggunakan pengiriman berkelanjutan, seperti yang dijelaskan di bagian berikut.

Continuous delivery dan deployment

Continuous delivery (CD) menyalin artefak deployment ke satu atau beberapa lingkungan deployment yang siap diluncurkan secara manual. Biasanya, artefak yang dibuat oleh server CI di-deploy ke satu atau beberapa lingkungan praproduksi untuk menjalankan pengujian end-to-end. Lingkungan produksi diperbarui jika semua pengujian menyeluruh berhasil lulus.

Untuk pipeline batch, deployment berkelanjutan dapat meluncurkan pipeline secara langsung sebagai tugas Dataflow baru. Atau, sistem lain dapat menggunakan artefak untuk meluncurkan tugas batch jika diperlukan. Misalnya, Anda dapat menggunakan Cloud Composer untuk menjalankan tugas batch dalam alur kerja, atau Cloud Scheduler untuk menjadwalkan tugas batch.

Pipeline streaming dapat lebih rumit untuk di-deploy daripada pipeline batch, dan oleh karena itu, lebih sulit untuk diotomatiskan menggunakan deployment berkelanjutan. Misalnya, Anda mungkin perlu menentukan cara mengganti atau memperbarui pipeline streaming yang ada. Jika Anda tidak dapat memperbarui pipeline, atau jika Anda memilih untuk tidak memperbaruinya, Anda dapat menggunakan metode lain seperti mengoordinasikan beberapa tugas Dataflow untuk meminimalkan atau mencegah gangguan bisnis.

Identitas dan peran yang diperlukan untuk CI/CD

Pipeline CI/CD Anda berinteraksi dengan berbagai sistem untuk membuat, menguji, dan men-deploy pipeline. Misalnya, pipeline Anda memerlukan akses ke repositori kode sumber Anda. Untuk mengaktifkan interaksi ini, pastikan pipeline Anda memiliki identitas dan peran yang tepat. Aktivitas pipeline berikut juga mungkin memerlukan pipeline Anda untuk memiliki identitas dan peran tertentu.

Pengujian integrasi dengan layanan eksternal, termasuk Google Cloud

Saat Anda menggunakan Direct Runner untuk menjalankan pengujian ad hoc atau pengujian integrasi sistem, pipeline Anda menggunakan Kredensial Default Aplikasi (ADC)) untuk mendapatkan kredensial. Cara Anda menyiapkan ADC bergantung pada tempat pipeline Anda berjalan. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Kredensial Default Aplikasi.

Pastikan akun layanan yang digunakan untuk mendapatkan kredensial untuk resourceGoogle Cloud yang diakses oleh pipeline memiliki peran dan izin yang memadai.

Men-deploy artefak ke lingkungan deployment yang berbeda

Jika memungkinkan, gunakan kredensial unik untuk setiap lingkungan (secara efektif untuk setiap project) dan batasi akses ke resource yang sesuai.

Gunakan akun layanan unik untuk setiap project guna membaca dan menulis artefak deployment ke bucket penyimpanan. Bergantung pada apakah pipeline Anda menggunakan template, proses deployment Anda mungkin perlu melakukan penyiapan beberapa artefak. Misalnya, membuat dan melakukan staging template Dataflow memerlukan izin untuk menulis artefak deployment yang diperlukan untuk meluncurkan pipeline, seperti file template pipeline, ke bucket Cloud Storage.

Men-deploy pipeline ke lingkungan deployment yang berbeda

Jika memungkinkan, gunakan akun layanan unik untuk setiap project guna mengakses dan mengelola Google Cloud resource dalam project, termasuk mengakses Dataflow itu sendiri.

Akun layanan yang Anda gunakan untuk membuat dan mengelola tugas Dataflow harus memiliki izin IAM yang memadai untuk pengelolaan tugas. Untuk mengetahui detailnya, lihat bagian Akun layanan Dataflow di halaman keamanan dan izin Dataflow.

Akun layanan pekerja yang Anda gunakan untuk menjalankan tugas Dataflow memerlukan izin untuk mengelola resource Compute Engine saat tugas berjalan dan untuk mengelola interaksi antara pipeline Apache Beam dan layanan Dataflow. Untuk mengetahui detailnya, lihat bagian Akun layanan worker di halaman keamanan dan izin Dataflow.

Untuk menentukan akun layanan pekerja yang dikelola pengguna untuk tugas, gunakan --serviceAccount opsi pipeline. Jika Anda tidak menentukan akun layanan pekerja saat membuat tugas, Dataflow akan mencoba menggunakan akun layanan default Compute Engine. Sebaiknya tentukan akun layanan worker yang dikelola pengguna untuk lingkungan produksi, karena akun layanan default Compute Engine biasanya memiliki serangkaian izin yang lebih luas daripada izin yang diperlukan untuk tugas Dataflow Anda.

Dalam skenario produksi, sebaiknya gunakan akun layanan terpisah untuk pengelolaan tugas Dataflow dan untuk akun layanan pekerja, yang memberikan keamanan yang lebih baik dibandingkan dengan menggunakan satu akun layanan. Misalnya, akun layanan yang digunakan untuk membuat tugas Dataflow mungkin tidak perlu mengakses sumber dan tujuan data atau menggunakan resource lain yang digunakan oleh pipeline. Dalam skenario ini, akun layanan pekerja yang digunakan untuk menjalankan tugas Dataflow diberi izin untuk menggunakan resource pipeline. Akun layanan lain untuk pembuatan tugas diberi izin untuk mengelola (termasuk membuat) tugas Dataflow.

Contoh pipeline CI/CD

Diagram berikut memberikan tampilan umum dan independen terhadap alat CI/CD untuk pipeline data. Selain itu, diagram menunjukkan hubungan antara tugas pengembangan, lingkungan deployment, dan pelaksana pipeline.

Diagram menunjukkan tahap berikut:

• Pengembangan kode: Selama pengembangan kode, developer menjalankan kode pipeline secara lokal menggunakan Direct Runner. Selain itu, developer menggunakan lingkungan sandbox untuk eksekusi pipeline ad hoc menggunakan Runner Dataflow.

  Dalam pipeline CI/CD standar, proses continuous integration dipicu saat developer membuat perubahan pada sistem kontrol sumber, seperti mengirim kode baru ke repositori.

• Build dan pengujian: Proses continuous integration mengompilasi kode pipeline, lalu menjalankan pengujian unit dan pengujian integrasi transformasi menggunakan Direct Runner. Pengujian integrasi sistem opsional, yang mencakup pengujian integrasi dengan sumber dan tujuan eksternal menggunakan set data pengujian kecil, juga dapat dijalankan.

  Jika pengujian berhasil, proses CI akan menyimpan artefak deployment, yang mungkin mencakup file JAR, image Docker, dan metadata template, yang diperlukan untuk meluncurkan pipeline ke lokasi yang dapat diakses oleh proses pengiriman berkelanjutan. Bergantung pada jenis artefak deployment yang dihasilkan, Anda dapat menggunakan Cloud Storage dan Artifact Registry untuk menyimpan berbagai jenis artefak.

• Pengiriman dan deployment: Proses continuous delivery menyalin artefak deployment ke lingkungan praproduksi atau membuat artefak ini tersedia untuk digunakan dalam lingkungan tersebut. Developer dapat menjalankan pengujian end-to-end secara manual menggunakan Runner Dataflow, atau mereka dapat menggunakan deployment berkelanjutan untuk memulai pengujian secara otomatis. Biasanya, pendekatan deployment berkelanjutan lebih mudah diaktifkan untuk pipeline batch daripada untuk pipeline streaming. Karena pipeline batch tidak berjalan terus-menerus, lebih mudah untuk menggantinya dengan rilis baru.

  Proses memperbarui pipeline streaming mungkin sederhana atau rumit, dan Anda harus menguji update di lingkungan praproduksi. Prosedur update mungkin tidak selalu konsisten di antara rilis. Misalnya, pipeline mungkin berubah sedemikian rupa sehingga update di tempat tidak mungkin dilakukan. Oleh karena itu, terkadang sulit untuk mengotomatiskan pembaruan pipeline menggunakan deployment berkelanjutan.

Jika semua pengujian menyeluruh lulus, Anda dapat menyalin artefak deployment atau menyediakannya untuk lingkungan produksi sebagai bagian dari proses pengiriman berkelanjutan. Jika pipeline baru memperbarui atau menggantikan pipeline streaming yang ada, gunakan prosedur yang diuji di lingkungan praproduksi untuk men-deploy pipeline baru.

Eksekusi tugas tanpa template versus dengan template

Anda dapat membuat tugas Dataflow dengan menggunakan Apache Beam SDK secara langsung dari lingkungan pengembangan. Jenis tugas ini disebut tugas non-template. Meskipun pendekatan ini nyaman bagi developer, Anda mungkin lebih memilih untuk memisahkan tugas pengembangan dan menjalankan pipeline. Untuk melakukan pemisahan ini, Anda dapat menggunakan template Dataflow, yang memungkinkan Anda menyiapkan dan menjalankan pipeline sebagai tugas independen. Setelah template dipentaskan, pengguna lain, termasuk non-developer, dapat menjalankan tugas dari template menggunakan Google Cloud CLI, konsol Google Cloud , atau Dataflow REST API.

Dataflow menawarkan jenis template tugas berikut:

• Template Klasik: Developer menggunakan Apache Beam SDK untuk menjalankan kode pipeline dan menyimpan grafik eksekusi yang diserialisasi JSON sebagai template. Apache Beam SDK menyiapkan file template ke lokasi Cloud Storage, beserta dependensi apa pun yang diperlukan oleh kode pipeline.
• Template Flex: Developer menggunakan Google Cloud CLI untuk mengemas pipeline sebagai image Docker, yang kemudian disimpan di Artifact Registry. File spesifikasi Template Flex juga dibuat dan disimpan secara otomatis ke lokasi Cloud Storage yang ditentukan pengguna. File spesifikasi Template Flex berisi metadata yang menjelaskan cara menjalankan template, seperti parameter pipeline.

Selain fitur Template Flex yang dijelaskan dalam dokumentasi tertaut, Template Flex menawarkan keunggulan dibandingkan Template Klasik untuk mengelola template.

• Dengan Template Klasik, beberapa artefak, seperti file JAR, dapat disimpan di lokasi penyiapan Cloud Storage, tetapi tanpa fitur untuk mengelola beberapa artefak ini. Sebagai perbandingan, Template Flex dienkapsulasi dalam image Docker. Image mengemas semua dependensi, selain spesifikasi Flex Template, yang diperlukan untuk pipeline Anda ke dalam satu artefak deployment yang dikelola oleh Artifact Registry.
• Anda dapat menggunakan fitur pengelolaan image Docker untuk Template Flex Anda. Misalnya, Anda dapat membagikan Template Flex secara aman dengan memberikan izin pull (dan secara opsional push) ke Artifact Registry, dan menggunakan tag image Docker untuk berbagai versi Template Flex Anda.

Developer dapat menggunakan Template Klasik dan Template Fleksibel untuk meluncurkan tugas dalam project yang berbeda dari project yang memiliki registry dan bucket penyimpanan yang menghosting aset template, atau hanya bucket penyimpanan jika Anda menggunakan Template Klasik. Fitur ini berguna jika Anda perlu mengisolasi pemrosesan data untuk beberapa pelanggan ke dalam project dan tugas pipeline yang berbeda. Dengan Template Flex, Anda dapat menentukan lebih lanjut berbagai versi image Docker yang akan digunakan saat meluncurkan pipeline. Fitur ini menyederhanakan penggantian bertahap pipeline batch atau pipeline streaming di beberapa project saat Anda memperbarui template nanti.

Fitur Dataflow untuk mengoptimalkan penggunaan resource

Dataflow menyediakan fitur khusus runner berikut untuk mengoptimalkan penggunaan resource, yang dapat meningkatkan performa dan menurunkan biaya:

• Streaming Engine: Streaming Engine memindahkan eksekusi pipeline streaming dari pekerja VM ke layanan khusus. Manfaatnya mencakup peningkatan responsivitas penskalaan otomatis, pengurangan resource VM pekerja yang digunakan, dan update layanan otomatis tanpa deployment ulang. Dalam beberapa kasus, Anda juga dapat mengurangi penggunaan resource dengan menggunakan pemrosesan minimal sekali untuk kasus penggunaan yang dapat mentoleransi duplikat. Streaming Engine sebaiknya diaktifkan untuk pipeline streaming. Fitur ini diaktifkan secara default saat Anda menggunakan Apache Beam Java SDK atau Python SDK versi terbaru.
• Dataflow Shuffle: Dataflow Shuffle memindahkan operasi shuffle untuk pipeline batch dari worker VM ke layanan khusus. Manfaatnya mencakup eksekusi yang lebih cepat untuk sebagian besar pipeline batch, pengurangan konsumsi resource oleh VM pekerja, peningkatan responsivitas penskalaan otomatis, dan peningkatan toleransi fault. Dataflow Shuffle sebaiknya diaktifkan untuk pipeline batch. Fitur ini diaktifkan secara default menggunakan Apache Beam Java SDK dan Python SDK terbaru.
• Penjadwalan resource fleksibel (FlexRS): FlexRS mengurangi biaya pemrosesan batch dengan menggunakan teknik penjadwalan lanjutan, layanan Dataflow Shuffle, serta kombinasi instance VM preemptible dan VM reguler.

Memperbarui pipeline streaming dalam produksi

Lihat Mengupgrade pipeline streaming.

Fungsi tugas Dataflow

Tugas Dataflow melalui siklus proses yang direpresentasikan oleh berbagai status tugas. Untuk menjalankan tugas Dataflow, kirimkan ke region. Kemudian, tugas akan dirutekan ke backend Dataflow yang tersedia di salah satu zona dalam region tersebut. Sebelum menetapkan backend, Dataflow akan memverifikasi bahwa Anda memiliki kuota dan izin yang memadai untuk menjalankan tugas. Setelah pemeriksaan awal ini selesai dan backend ditetapkan, tugas akan berpindah ke status JOB_STATE_PENDING. Untuk tugas FlexRS, penetapan backend mungkin ditunda ke waktu mendatang, dan tugas ini akan memasuki status JOB_STATE_QUEUED.

Backend yang ditetapkan akan mengambil tugas untuk dijalankan dan mencoba memulai pekerja Dataflow di project Google Cloud Anda. Zona yang dipilih untuk VM pekerja bergantung pada sejumlah faktor. Untuk tugas batch yang menggunakan Dataflow Shuffle, layanan ini juga mencoba memastikan bahwa backend Dataflow dan VM pekerja berada di zona yang sama untuk menghindari traffic lintas zona.

Setelah pekerja Dataflow dimulai, mereka akan meminta tugas dari backend Dataflow. Backend bertanggung jawab untuk membagi pekerjaan menjadi beberapa bagian yang dapat diparalelkan, yang disebut bundle, yang didistribusikan di antara pekerja. Jika pekerja tidak dapat menangani pekerjaan yang ada, dan jika penskalaan otomatis diaktifkan, backend akan memulai lebih banyak pekerja untuk menangani pekerjaan tersebut. Demikian pula, jika lebih banyak pekerja yang dimulai daripada yang diperlukan, beberapa pekerja akan dimatikan.

Setelah pekerja Dataflow dimulai, backend Dataflow akan bertindak sebagai control plane untuk mengatur eksekusi tugas. Selama pemrosesan, bidang data tugas melakukan operasi pengacakan seperti GroupByKey, CoGroupByKey, dan Combine. Tugas menggunakan salah satu implementasi bidang data berikut untuk operasi pengacakan:

• Data plane berjalan di worker Dataflow, dan data shuffle disimpan di persistent disk.
• Bidang data berjalan sebagai layanan, yang dieksternalkan dari VM pekerja. Implementasi ini memiliki dua varian, yang Anda tentukan saat membuat tugas: Pengacakan Dataflow untuk pipeline batch dan Streaming Engine untuk pipeline streaming. Pengacakan berbasis layanan secara signifikan meningkatkan performa dan skalabilitas operasi pengacakan data dibandingkan dengan pengacakan berbasis pekerja.

Tugas streaming yang memasuki status JOB_STATE_RUNNING akan terus berjalan tanpa batas waktu hingga dibatalkan atau dihentikan, kecuali jika terjadi kegagalan tugas. Tugas batch akan otomatis berhenti saat semua pemrosesan selesai atau jika terjadi error yang tidak dapat dipulihkan. Bergantung pada cara tugas dihentikan, Dataflow menetapkan status tugas ke salah satu dari beberapa status terminal, termasuk JOB_STATE_CANCELLED, JOB_STATE_DRAINED, atau JOB_STATE_DONE.

Praktik terbaik keandalan pipeline

Bagian ini membahas kegagalan yang mungkin terjadi saat Anda menggunakan Dataflow dan praktik terbaik untuk tugas Dataflow.

Mengikuti prinsip isolasi

Rekomendasi umum untuk meningkatkan keandalan pipeline secara keseluruhan adalah dengan mengikuti prinsip isolasi di balik region dan zona. Pastikan pipeline Anda tidak memiliki dependensi lintas region yang penting. Jika Anda memiliki pipeline yang memiliki dependensi penting pada layanan dari beberapa region, kegagalan di salah satu region tersebut dapat memengaruhi pipeline Anda. Untuk membantu menghindari masalah ini, deploy ke beberapa region untuk redundansi dan pencadangan.

Membuat snapshot Dataflow

Dataflow menawarkan fitur snapshot yang menyediakan cadangan status pipeline. Anda dapat memulihkan snapshot pipeline ke pipeline Dataflow streaming baru di zona atau region lain. Kemudian, Anda dapat memulai pemrosesan ulang pesan di topik Pub/Sub atau Kafka yang dimulai pada stempel waktu snapshot. Jika menyiapkan snapshot reguler alur kerja, Anda dapat meminimalkan waktu Tujuan Waktu Pemulihan (RTO).

Untuk mengetahui informasi selengkapnya tentang snapshot Dataflow, lihat Menggunakan snapshot Dataflow.

Menangani kegagalan pengiriman tugas

Anda mengirimkan tugas Dataflow non-template menggunakan Apache Beam SDK. Untuk mengirimkan tugas, Anda menjalankan pipeline menggunakan Runner Dataflow, yang ditentukan sebagai bagian dari opsi pipeline. Apache Beam SDK membuat file sementara di Cloud Storage, membuat file permintaan tugas, dan mengirimkan file tersebut ke Dataflow.

Atau, tugas yang dibuat dari template Dataflow menggunakan metode pengiriman yang berbeda, yang biasanya mengandalkan API template.

Anda mungkin melihat berbagai error yang ditampilkan oleh Dataflow yang menunjukkan kegagalan tugas untuk tugas template dan non-template. Bagian ini membahas berbagai jenis kegagalan pengiriman tugas dan praktik terbaik untuk menanganinya atau memitigasinya.

Mencoba lagi pengiriman tugas setelah kegagalan sementara

Jika tugas gagal dimulai karena masalah layanan Dataflow, coba lagi tugas tersebut beberapa kali. Mencoba lagi akan mengurangi masalah layanan sementara.

Memitigasi kegagalan zona dengan menentukan region pekerja

Dataflow menyediakan ketersediaan regional dan tersedia di beberapa region. Saat pengguna mengirimkan tugas ke region tanpa menentukan zona secara eksplisit, Dataflow akan merutekan tugas ke zona di region yang ditentukan berdasarkan ketersediaan resource.

Opsi yang direkomendasikan untuk penempatan tugas adalah menentukan region pekerja menggunakan flag --region daripada flag --zone jika memungkinkan. Langkah ini memungkinkan Dataflow memberikan tingkat toleransi kesalahan tambahan untuk pipeline Anda dengan otomatis memilih zona terbaik untuk tugas tersebut. Tugas yang menentukan zona eksplisit tidak mendapatkan manfaat ini, dan tugas tersebut akan gagal jika terjadi masalah dalam zona. Jika pengiriman tugas gagal karena masalah zona, Anda sering kali dapat menyelesaikan masalah dengan mencoba lagi tugas tanpa menentukan zona secara eksplisit.

Mengurangi kegagalan regional dengan menyimpan data di beberapa region

Jika seluruh region tidak tersedia, coba jalankan tugas di region lain. Penting untuk memikirkan ketersediaan data Anda saat tugas gagal di berbagai region. Untuk melindungi dari kegagalan satu region tanpa menyalin data secara manual ke beberapa region, gunakan Google Cloud resource yang secara otomatis menyimpan data di beberapa region. Misalnya, gunakan lokasi multi-region BigQuery untuk set data atau bucket dual-region dan multi-region Cloud Storage. Jika satu region tidak tersedia, Anda dapat menjalankan ulang pipeline di region lain tempat data tersedia.

Untuk contoh penggunaan layanan multi-regional dengan Dataflow, lihat Ketersediaan tinggi dan redundansi geografis.

Menangani kegagalan dalam menjalankan pipeline

Setelah tugas dikirimkan dan diterima, satu-satunya operasi yang valid untuk tugas tersebut adalah sebagai berikut:

• membatalkan tugas batch
• memperbarui, menguras, atau membatalkan tugas streaming

Anda tidak dapat mengubah lokasi tugas yang sedang berjalan setelah mengirimkan tugas. Jika Anda tidak menggunakan FlexRS, tugas biasanya mulai memproses data dalam beberapa menit setelah pengiriman. Tugas FlexRS dapat memerlukan waktu hingga enam jam agar pemrosesan data dimulai.

Bagian ini membahas kegagalan untuk menjalankan tugas dan praktik terbaik untuk menanganinya.

Pantau tugas untuk mengidentifikasi dan menyelesaikan masalah yang disebabkan oleh error sementara

Untuk tugas batch, paket yang menyertakan item yang gagal akan dicoba ulang sebanyak empat kali. Dataflow menghentikan tugas jika satu bundle gagal empat kali. Proses ini mengatasi banyak masalah sementara. Namun, jika terjadi kegagalan yang berkepanjangan, batas percobaan ulang maksimum biasanya tercapai dengan cepat, sehingga memungkinkan tugas gagal dengan cepat.

Untuk pemantauan dan pengelolaan insiden, konfigurasi aturan pemberitahuan untuk mendeteksi tugas yang gagal. Jika tugas gagal, periksa log tugas untuk mengidentifikasi kegagalan tugas yang disebabkan oleh item kerja yang gagal dan melebihi batas percobaan ulang.

Untuk tugas streaming, Dataflow mencoba ulang item kerja yang gagal tanpa batas waktu. Tugas tidak dihentikan. Namun, tugas mungkin terhenti hingga masalah teratasi. Buat kebijakan pemantauan untuk mendeteksi tanda-tanda pipeline terhenti, seperti peningkatan latensi sistem dan penurunan keakuratan data. Terapkan logging error dalam kode pipeline Anda untuk membantu mengidentifikasi kebuntuan pipeline yang disebabkan oleh item kerja yang gagal berulang kali.

Mulai ulang tugas di zona lain jika terjadi pemadaman layanan zona

Setelah tugas dimulai, pekerja Dataflow yang menjalankan kode pengguna dibatasi ke satu zona. Jika terjadi gangguan zonal, tugas Dataflow sering kali terpengaruh, bergantung pada tingkat gangguan tersebut.

Untuk pemadaman layanan yang hanya memengaruhi backend Dataflow, backend akan otomatis dimigrasikan ke zona lain oleh layanan terkelola sehingga dapat melanjutkan tugas. Jika tugas menggunakan Dataflow Shuffle, backend tidak dapat dipindahkan antar-zona. Jika terjadi migrasi backend Dataflow, tugas mungkin tertunda untuk sementara.

Jika terjadi pemadaman layanan zona, tugas yang sedang berjalan kemungkinan akan gagal atau terhenti hingga ketersediaan zona dipulihkan. Jika zona tidak tersedia dalam jangka waktu yang lama, hentikan tugas (batalkan untuk tugas batch dan kosongkan untuk tugas streaming), lalu mulai ulang tugas tersebut agar Dataflow dapat memilih zona baru yang berfungsi dengan baik.

Mulai ulang tugas batch di region lain jika terjadi pemadaman layanan regional

Jika terjadi pemadaman layanan regional di region tempat tugas Dataflow Anda berjalan, tugas dapat gagal atau terhenti. Untuk tugas batch, mulai ulang tugas di region lain jika memungkinkan. Penting untuk memastikan bahwa data Anda tersedia di berbagai region.

Mengurangi dampak gangguan regional dengan menggunakan ketersediaan tinggi atau failover

Untuk tugas streaming, bergantung pada toleransi kesalahan dan anggaran untuk aplikasi Anda, Anda memiliki berbagai opsi untuk memitigasi kegagalan. Untuk gangguan regional, opsi yang paling sederhana dan hemat biaya adalah menunggu hingga gangguan berakhir. Namun, jika aplikasi Anda sensitif terhadap latensi atau jika pemrosesan data tidak boleh terganggu atau harus dilanjutkan dengan penundaan minimal, bagian berikut membahas opsi yang tersedia.

Ketersediaan tinggi: Sensitif terhadap latensi tanpa kehilangan data

Jika aplikasi Anda tidak dapat mentoleransi kehilangan data, jalankan pipeline duplikat secara paralel di dua region yang berbeda, dan buat pipeline menggunakan data yang sama. Sumber data yang sama harus tersedia di kedua region. Aplikasi hilir yang bergantung pada output pipeline ini harus dapat beralih antara output dari kedua region ini. Karena duplikasi resource, opsi ini melibatkan biaya tertinggi dibandingkan dengan opsi lainnya. Untuk contoh deployment, lihat bagian Ketersediaan tinggi dan redundansi geografis.

Failover: Sensitif terhadap latensi dengan potensi kehilangan data

Jika aplikasi Anda dapat mentoleransi potensi kehilangan data, sediakan sumber data streaming di beberapa region. Misalnya, menggunakan Pub/Sub, pertahankan dua langganan independen untuk topik yang sama, satu untuk setiap region. Jika terjadi gangguan layanan regional, mulai pipeline pengganti di region lain, dan minta pipeline tersebut menggunakan data dari langganan cadangan.

Putar ulang langganan pencadangan ke waktu yang sesuai untuk meminimalkan kehilangan data tanpa mengorbankan latensi. Aplikasi downstream harus mengetahui cara beralih ke output pipeline yang sedang berjalan, mirip dengan opsi ketersediaan tinggi. Opsi ini menggunakan lebih sedikit resource daripada menjalankan pipeline duplikat karena hanya data yang diduplikasi.

Ketersediaan tinggi dan redundansi geografis

Anda dapat menjalankan beberapa pipeline streaming secara paralel untuk pemrosesan data ketersediaan tinggi. Misalnya, Anda dapat menjalankan dua tugas streaming paralel di region yang berbeda, yang memberikan redundansi geografis dan fault tolerance untuk pemrosesan data.

Dengan mempertimbangkan ketersediaan geografis sumber data dan sink, Anda dapat mengoperasikan pipeline menyeluruh dalam konfigurasi multi-region yang sangat tersedia. Diagram berikut menunjukkan contoh deployment.

Diagram menunjukkan alur berikut:

1. Pub/Sub berjalan di sebagian besar region di seluruh dunia, sehingga layanan ini dapat menawarkan akses data global yang cepat, sekaligus memberi Anda kontrol atas lokasi penyimpanan pesan. Pub/Sub dapat menyimpan pesan yang dipublikasikan secara otomatis di region yang paling dekat dengan pelanggan, atau Anda dapat mengonfigurasinya untuk menggunakan region tertentu atau sekumpulan region menggunakan kebijakan penyimpanan pesan. Google Cloud

   Kemudian, Pub/Sub mengirimkan pesan ke pelanggan di seluruh dunia, terlepas dari tempat pesan disimpan. Klien Pub/Sub tidak perlu mengetahui lokasi server yang terhubung dengannya, karena mekanisme load balancing global mengarahkan traffic ke pusat data Google Cloud terdekat tempat pesan disimpan.

2. Dataflow berjalan di region Google Cloud tertentu. Dengan menjalankan pipeline paralel di region Google Cloud terpisah, Anda dapat mengisolasi tugas dari kegagalan yang memengaruhi satu region. Diagram ini menunjukkan dua instance pipeline yang sama, yang masing-masing berjalan di region Google Cloud terpisah.

3. BigQuery menyediakan lokasi set data regional dan multi-regional. Saat Anda memilih lokasi multi-region, set data Anda berada di setidaknya dua region geografis. Diagram ini menggambarkan dua pipeline terpisah, yang masing-masing menulis ke set data multi-region terpisah.