Mendesain alur kerja pipeline Dataflow

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

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

Continuous integration

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

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

Jumlah dan jenis artefak deployment yang dibuat dari build yang lulus bervariasi bergantung pada cara peluncuran pipeline. Dengan menggunakan Apache Beam Java SDK, Anda dapat mengemas kode pipeline ke dalam file JAR yang dieksekusi secara mandiri. Selanjutnya, Anda dapat menyimpan file JAR di bucket yang dihosting dalam project untuk lingkungan deployment, seperti project Google Cloud praproduksi atau produksi. Jika Anda menggunakan Template klasik (jenis eksekusi dengan template), artefak deployment akan menyertakan file template JSON, file JAR untuk pipeline Anda, dan template metadata opsional. Kemudian, Anda dapat men-deploy artefak ke berbagai lingkungan deployment menggunakan continuous delivery, 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 menyeluruh. Lingkungan produksi diperbarui jika semua pengujian menyeluruh berhasil lulus.

Untuk pipeline batch, deployment berkelanjutan dapat langsung meluncurkan pipeline 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 kompleks untuk di-deploy daripada pipeline batch, sehingga lebih sulit untuk diotomatiskan menggunakan deployment berkelanjutan. Misalnya, Anda mungkin perlu menentukan cara mengganti atau memperbarui pipeline streaming yang ada. Jika tidak dapat mengupdate pipeline, atau jika memilih untuk tidak mengupdatenya, Anda dapat menggunakan metode lain seperti menkoordinasikan 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 mem-build, menguji, dan men-deploy pipeline. Misalnya, pipeline Anda memerlukan akses ke repositori kode sumber. Untuk mengaktifkan interaksi ini, pastikan pipeline Anda memiliki identitas dan peran yang tepat. Aktivitas pipeline berikut mungkin juga 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 Google Cloud CLI untuk menggunakan sumber dan sink data Google Cloud, atau menggunakan kredensial yang disediakan oleh variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS. Pastikan akun layanan yang digunakan untuk mendapatkan kredensial untuk resource Google 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 yang 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 staging 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 resource Google Cloud 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 pekerja di halaman keamanan dan izin Dataflow.

Untuk menentukan akun layanan pekerja yang dikelola pengguna untuk tugas, gunakan opsi pipeline --serviceAccount. Jika Anda tidak menentukan akun layanan pekerja saat membuat tugas, Dataflow akan mencoba menggunakan akun layanan default Compute Engine. Sebaiknya tentukan akun layanan pekerja yang dikelola pengguna untuk lingkungan produksi, karena akun layanan default Compute Engine biasanya memiliki kumpulan 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 akun layanan tunggal. Misalnya, akun layanan yang digunakan untuk membuat tugas Dataflow mungkin tidak perlu mengakses sumber data dan sink 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 tidak bergantung pada alat CI/CD untuk pipeline data. Selain itu, diagram menunjukkan hubungan antara tugas pengembangan, lingkungan deployment, dan runner pipeline.

Diagram menunjukkan tahap-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.

• Mem-build dan menguji: 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 sink 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 continuous delivery. Bergantung pada jenis artefak deployment yang dihasilkan, Anda dapat menggunakan Cloud Storage dan Artifact Registry untuk menyimpan berbagai jenis artefak.

• Mengirim dan men-deploy: Proses continuous delivery menyalin artefak deployment ke lingkungan praproduksi atau menyediakan artefak ini untuk digunakan dalam lingkungan tersebut. Developer dapat menjalankan pengujian menyeluruh 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 secara terus-menerus, akan lebih mudah untuk menggantinya dengan rilis baru.

  Proses mengupdate 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 in-place tidak dapat dilakukan. Karena alasan ini, terkadang sulit untuk mengotomatiskan update pipeline menggunakan deployment berkelanjutan.

Jika semua pengujian menyeluruh lulus, Anda dapat menyalin artefak deployment atau menyediakannya ke lingkungan produksi sebagai bagian dari proses continuous delivery. Jika pipeline baru memperbarui atau mengganti 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 langsung dari lingkungan pengembangan. Jenis tugas ini disebut tugas tanpa template. Meskipun pendekatan ini mudah bagi developer, Anda mungkin lebih suka memisahkan tugas pengembangan dan menjalankan pipeline. Untuk melakukan pemisahan ini, Anda dapat menggunakan template Dataflow, yang memungkinkan Anda melakukan staging dan menjalankan pipeline sebagai tugas independen. Setelah template di-staging, 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 serial 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 memaketkan pipeline sebagai image Docker, yang kemudian disimpan di Artifact Registry. File spesifikasi Template Flex juga dibuat secara otomatis dan disimpan 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 staging Cloud Storage, tetapi tanpa fitur apa pun untuk mengelola beberapa artefak ini. Sebagai perbandingan, Template Flex dienkapsulasi dalam image Docker. Image mengemas semua dependensi, selain spesifikasi Template Flex, 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. Misalnya, Anda dapat membagikan Template Flex dengan aman dengan memberikan izin pull (dan 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 versi image Docker yang berbeda untuk 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 setidaknya sekali untuk kasus penggunaan yang dapat menerima duplikat. Mengaktifkan Streaming Engine direkomendasikan 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 pekerja VM dan ke layanan khusus. Manfaatnya meliputi eksekusi yang lebih cepat untuk sebagian besar pipeline batch, pengurangan konsumsi resource oleh VM pekerja, peningkatan responsivitas penskalaan otomatis, dan peningkatan toleransi error. Mengaktifkan Dataflow Shuffle direkomendasikan 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, dan kombinasi instance VM preemptible dan VM reguler.

Memperbarui pipeline streaming dalam produksi

Lihat Mengupgrade pipeline streaming.

Siklus proses tugas Dataflow

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

Backend yang ditetapkan akan mengambil tugas yang akan 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 juga mencoba memastikan bahwa backend Dataflow dan VM pekerja berada di zona yang sama untuk menghindari traffic lintas zona.

Setelah pekerja Dataflow dimulai, mereka meminta pekerjaan dari backend Dataflow. Backend bertanggung jawab untuk membagi pekerjaan menjadi bagian yang dapat diparalelkan, yang disebut paket, 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 dinonaktifkan.

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

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

Tugas streaming yang memasuki status JOB_STATE_RUNNING akan terus berjalan tanpa batas waktu hingga dibatalkan atau habis, 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 mulai dari stempel waktu snapshot. Jika menyiapkan snapshot reguler pipeline, Anda dapat meminimalkan waktu Batas Waktu Pemulihan (RTO).

Untuk 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 Dataflow Runner, yang ditentukan sebagai bagian dari opsi pipeline. Apache Beam SDK membuat file di Cloud Storage, membuat file permintaan tugas, dan mengirimkan file ke Dataflow.

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

Anda mungkin melihat error yang berbeda 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 menangani atau menguranginya.

Mencoba ulang pengiriman tugas setelah kegagalan sementara

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

Mitigasi 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 dengan menggunakan flag --region, bukan flag --zone jika memungkinkan. Langkah ini memungkinkan Dataflow memberikan tingkat toleransi error tambahan untuk pipeline Anda dengan memilih zona terbaik secara otomatis untuk tugas tersebut. Tugas yang menentukan zona eksplisit tidak memiliki manfaat ini, dan tugas tersebut akan gagal jika masalah terjadi dalam zona. Jika pengiriman tugas gagal karena masalah zona, Anda sering kali dapat menyelesaikan masalah tersebut dengan mencoba kembali tugas tanpa menentukan zona secara eksplisit.

Mitigasi kegagalan regional dengan menyimpan data di beberapa region

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

Untuk contoh penggunaan layanan multi-region 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 adalah sebagai berikut:

• membatalkan untuk tugas batch
• memperbarui, menghabiskan, atau membatalkan untuk 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 dikirim. Tugas FlexRS dapat memerlukan waktu hingga enam jam untuk memulai pemrosesan data.

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

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

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

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

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

Memulai ulang tugas di zona lain jika terjadi pemadaman layanan zona

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

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

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

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

Jika pemadaman layanan regional terjadi di region tempat tugas Dataflow Anda berjalan, tugas tersebut 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.

Mitigasi pemadaman regional menggunakan ketersediaan tinggi atau failover

Untuk tugas streaming, bergantung pada toleransi error dan anggaran untuk aplikasi Anda, Anda memiliki opsi yang berbeda untuk mengurangi kegagalan. Untuk pemadaman layanan regional, opsi yang paling sederhana dan hemat biaya adalah menunggu hingga pemadaman layanan 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.

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 minta pipeline menggunakan data yang sama. Sumber data yang sama harus tersedia di kedua region. Aplikasi downstream yang bergantung pada output pipeline ini harus dapat beralih di 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 beberapa 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 pemadaman layanan regional, mulai pipeline pengganti di region lain, dan minta pipeline 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-tolerant 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, yang memungkinkan layanan menawarkan akses data global yang cepat, sekaligus memberi Anda kontrol atas lokasi penyimpanan pesan. Pub/Sub dapat otomatis menyimpan pesan yang dipublikasikan di region Google Cloud yang terdekat dengan pelanggan, atau Anda dapat mengonfigurasinya untuk menggunakan region atau kumpulan region tertentu menggunakan kebijakan penyimpanan pesan.

   Pub/Sub kemudian mengirimkan pesan ke pelanggan di seluruh dunia, terlepas dari tempat pesan disimpan. Klien Pub/Sub tidak perlu mengetahui lokasi server yang terhubung kepadanya, 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 menunjukkan dua instance pipeline yang sama, masing-masing berjalan di region Google Cloud terpisah.

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