Pengembangan pipeline melibatkan berbagai tahap dan tugas, seperti pengembangan kode, pengujian, dan pengiriman ke dalam produksi. Dokumen ini menjelaskan:
- Pertimbangan untuk continuous integration dan continuous delivery (CI/CD) guna mendukung build, pengujian, dan deployment pipeline otomatis ke berbagai lingkungan.
- fitur Dataflow untuk mengoptimalkan performa dan penggunaan resource dalam produksi.
- Pendekatan dan watchpoint untuk memperbarui pipeline streaming dalam produksi.
- Praktik terbaik untuk meningkatkan keandalan pipeline dalam produksi.
Continuous integration
Continuous integration (CI) mengharuskan developer untuk menggabungkan kode ke dalam repositori bersama secara rutin. Hal ini berguna untuk aplikasi yang banyak 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 terjadi kerusakan dan mengurangi kemungkinan regresi yang masuk ke 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 sama dengan alat otomatisasi build, seperti Maven, untuk menjalankan rangkaian pengujian sebagai satu atau beberapa langkah pipeline CI. Anda dapat mengemas kode yang berhasil lulus pengujian unit dan pengujian integrasi ke dalam artefak deployment tempat pipeline diluncurkan. Build ini disebut sebagai build penerusan.
Jumlah dan jenis artefak deployment yang dibuat dari build yang lewat bervariasi, bergantung pada cara pipeline diluncurkan. Dengan Apache Beam Java SDK, Anda dapat mengemas kode pipeline menjadi file JAR yang dieksekusi sendiri. Selanjutnya, Anda dapat menyimpan file JAR dalam 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 mencakup file template JSON, file JAR untuk pipeline Anda, dan template metadata opsional. Selanjutnya, 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 dibangun oleh server CI di-deploy ke satu atau beberapa lingkungan praproduksi untuk menjalankan pengujian end-to-end. Lingkungan produksi akan diupdate 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 bisa lebih kompleks untuk di-deploy daripada pipeline batch, dan oleh karena itu dapat lebih sulit untuk diotomatisasi menggunakan deployment berkelanjutan. Misalnya, Anda mungkin perlu menentukan cara mengganti atau memperbarui pipeline streaming yang ada. Jika tidak dapat memperbarui pipeline, atau 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 sistem yang berbeda untuk membangun, menguji, dan men-deploy pipeline. Misalnya, pipeline Anda memerlukan akses ke repositori kode sumber Anda. Untuk memungkinkan interaksi ini, pastikan pipeline Anda memiliki identitas dan peran yang tepat. Aktivitas pipeline berikut mungkin juga mengharuskan pipeline Anda 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 akan menggunakan kredensial Google Cloud CLI untuk menggunakan sumber data dan sink Google Cloud, atau menggunakan kredensial yang diberikan 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 berbagai lingkungan deployment
Jika memungkinkan, gunakan kredensial unik untuk setiap lingkungan (secara efektif untuk setiap project) dan batasi akses ke resource sebagaimana mestinya.
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 beberapa artefak. Misalnya, membuat dan melakukan staging template Dataflow memerlukan izin untuk menulis artefak deployment yang diperlukan untuk meluncurkan pipeline Anda, seperti file template pipeline, ke bucket Cloud Storage.
Men-deploy pipeline ke berbagai lingkungan deployment
Jika memungkinkan, gunakan akun layanan unik untuk setiap project agar dapat 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, serta 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.
Dalam skenario produksi, sebaiknya gunakan akun layanan yang terpisah untuk pengelolaan tugas Dataflow dan untuk akun layanan pekerja, yang memberikan keamanan lebih baik dibandingkan dengan menggunakan satu akun layanan. 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 yang berbeda untuk pembuatan tugas diberi izin untuk mengelola (termasuk membuat) tugas Dataflow.
Contoh pipeline CI/CD
Diagram berikut memberikan tampilan umum dan agnostik alat dari CI/CD untuk pipeline data. Selain itu, diagram menunjukkan hubungan antara tugas pengembangan, lingkungan deployment, dan runner pipeline.
Diagram ini menampilkan tahapan 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 Dataflow Runner.
Pada pipeline CI/CD standar, proses continuous integration dipicu saat developer melakukan perubahan pada sistem kontrol sumber, seperti mengirim kode baru ke repositori.
Build dan uji: Proses continuous integration mengompilasi kode pipeline, lalu menjalankan pengujian unit dan mentransformasi pengujian integrasi menggunakan Direct Runner. Pengujian integrasi sistem opsional, yang mencakup pengujian integrasi dengan sumber eksternal dan sink menggunakan set data pengujian kecil juga dapat berjalan.
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.
Kirim dan 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 Dataflow Runner, atau mereka dapat menggunakan deployment berkelanjutan untuk memulai pengujian secara otomatis. Biasanya, pendekatan deployment berkelanjutan lebih mudah diaktifkan untuk pipeline batch daripada pipeline streaming. Karena pipeline batch tidak berjalan terus-menerus, lebih mudah untuk menggantinya dengan rilis baru.
Proses mengupdate pipeline streaming mungkin sederhana atau kompleks, dan Anda harus menguji update di lingkungan praproduksi. Prosedur update mungkin tidak selalu konsisten antar-rilis. Misalnya, pipeline dapat berubah sedemikian rupa sehingga membuat update di tempat tidak mungkin 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 untuk 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 template
Anda dapat membuat tugas Dataflow dengan menggunakan Apache Beam SDK langsung dari lingkungan pengembangan. Jenis tugas ini disebut tugas non-template. Meskipun pendekatan ini nyaman bagi developer, Anda mungkin lebih memilih untuk memisahkan tugas mengembangkan dan menjalankan pipeline. Untuk melakukan pemisahan ini, Anda dapat menggunakan template Dataflow, yang memungkinkan Anda menyusun dan menjalankan pipeline sebagai tugas independen. Setelah template ditahapkan, pengguna lain, termasuk non-developer, dapat menjalankan tugas dari template tersebut 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 menempatkan file template ke lokasi Cloud Storage, beserta dependensi yang diperlukan oleh kode pipeline.
- Template Fleksibel: Developer menggunakan Google Cloud CLI untuk memaketkan pipeline sebagai image Docker yang kemudian disimpan di Artifact Registry. File spesifikasi Template Flex juga otomatis dibuat 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 Fleksibel yang dijelaskan dalam dokumentasi tertaut, Template Fleksibel menawarkan keunggulan dibandingkan Template Klasik untuk mengelola template.
- Dengan Template Klasik, beberapa artefak, seperti file JAR, mungkin disimpan di lokasi staging Cloud Storage, tetapi tanpa fitur untuk mengelola beberapa artefak ini. Sebagai perbandingan, Template Flex dienkapsulasi di 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 secara opsional push) ke Artifact Registry, dan menggunakan tag image Docker untuk berbagai versi Template Flex.
Developer dapat menggunakan Template Klasik dan Template Fleksibel untuk meluncurkan tugas dalam project yang berbeda dengan 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 banyak pelanggan ke dalam berbagai project dan tugas pipeline. Dengan Template Flex, Anda dapat menentukan lebih lanjut berbagai versi image Docker yang akan digunakan saat meluncurkan pipeline. Fitur ini menyederhanakan penggantian pipeline batch atau pipeline streaming secara bertahap pada 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. 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 acak untuk pipeline batch dari pekerja VM ke layanan khusus. Manfaat ini mencakup eksekusi yang lebih cepat untuk sebagian besar pipeline batch, pengurangan konsumsi resource oleh VM pekerja, peningkatan respons penskalaan otomatis, dan fault tolerance yang lebih baik. Mengaktifkan Dataflow Shuffle direkomendasikan untuk pipeline batch. Fitur ini diaktifkan secara default menggunakan Apache Beam Java SDK dan Python SDK terbaru.
- Penjadwalan resource yang fleksibel (FlexRS): FlexRS mengurangi biaya batch processing menggunakan teknik penjadwalan lanjutan, layanan Dataflow Shuffle, serta kombinasi instance preemptible VM dan VM reguler.
Memperbarui pipeline streaming dalam produksi
Lihat Mengupgrade pipeline streaming.
Masa pakai tugas Dataflow
Tugas Dataflow melalui siklus proses yang diwakili oleh berbagai status tugas.
Untuk menjalankan tugas Dataflow, kirimkan ke region.
Tugas ini kemudian dirutekan ke backend Dataflow yang tersedia di salah satu zona dalam region tersebut. Sebelum menetapkan backend, Dataflow memverifikasi bahwa Anda memiliki kuota dan izin yang memadai untuk menjalankan tugas. Setelah
pemeriksaan preflight ini selesai dan backend telah ditetapkan, tugas
akan dipindahkan ke status JOB_STATE_PENDING. Untuk
tugas FlexRS, tugas backend mungkin tertunda di waktu mendatang, dan tugas ini
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 ini juga mencoba memastikan bahwa backend Dataflow dan VM pekerja berada di zona yang sama untuk menghindari traffic lintas zona.
Setelah pekerja Dataflow dimulai, pekerja tersebut meminta tugas 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 worker untuk menangani pekerjaan tersebut. Demikian pula, jika jumlah pekerja yang dimulai lebih banyak daripada yang dibutuhkan, sebagian pekerja akan dinonaktifkan.
Setelah pekerja Dataflow dimulai, backend Dataflow bertindak sebagai bidang kontrol untuk mengatur eksekusi tugas. Selama pemrosesan, bidang data
tugas menjalankan operasi shuffle seperti GroupByKey, CoGroupByKey, dan Combine.
Tugas menggunakan salah satu implementasi bidang data berikut untuk operasi shuffle:
- Bidang data berjalan pada pekerja Dataflow, dan data acak 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: Dataflow Shuffle 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
dihabiskan,
kecuali 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 bekerja dengan Dataflow dan praktik terbaik untuk tugas Dataflow.
Mengikuti prinsip isolasi
Rekomendasi umum untuk meningkatkan keandalan pipeline secara keseluruhan adalah 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 kritis 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 dalam topik Pub/Sub atau Kafka yang dimulai pada stempel waktu snapshot. Jika menyiapkan snapshot reguler pipeline, Anda dapat meminimalkan waktu Batas Waktu Pemulihan (RTO).
Untuk mengetahui informasi selengkapnya tentang snapshot Dataflow, lihat Menggunakan snapshot Dataflow.
Menangani kegagalan pengiriman tugas
Kirim tugas Dataflow non-template menggunakan Apache Beam SDK. Untuk mengirimkan tugas, jalankan pipeline menggunakan Dataflow Runner, yang ditentukan sebagai bagian dari opsi pipeline. Apache Beam SDK menempatkan file di Cloud Storage, membuat file permintaan tugas, dan mengirimkan file tersebut ke Dataflow.
Selain itu, tugas yang dibuat dari template Dataflow menggunakan metode pengiriman yang berbeda, yang biasanya mengandalkan API template.
Anda mungkin melihat error 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 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 memberikan ketersediaan regional dan tersedia di beberapa region. Saat pengguna mengirim tugas ke region tanpa menentukan zona secara eksplisit, Dataflow akan mengarahkan tugas ke zona di region yang ditentukan berdasarkan ketersediaan resource.
Opsi yang direkomendasikan untuk penempatan tugas adalah menentukan wilayah pekerja
dengan menggunakan tanda --region,
bukan tanda --zone jika memungkinkan. Dengan langkah ini,
Dataflow dapat memberikan tingkat fault
tolerance tambahan untuk pipeline Anda dengan memilih zona terbaik
untuk tugas tersebut secara otomatis. Tugas yang menentukan zona eksplisit tidak memiliki manfaat ini, dan
akan gagal jika terjadi masalah di dalam zona tersebut. Jika pengiriman tugas gagal karena
masalah zona, Anda biasanya dapat
mengatasi masalah tersebut dengan mencoba kembali tugas tersebut tanpa menentukan zona secara eksplisit.
Memitigasi 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 dual-region dan multi-region Cloud Storage. Jika satu region menjadi tidak tersedia, Anda dapat menjalankan ulang pipeline di region lain tempat data tersedia.
Untuk mengetahui contoh penggunaan layanan multi-regional dengan Dataflow, lihat Ketersediaan tinggi dan redundansi geografis.
Menangani kegagalan dalam menjalankan pipeline
Setelah tugas dikirim dan diterima, satu-satunya operasi yang valid untuk tugas tersebut adalah sebagai berikut:
- batalkan tugas batch
- memperbarui, mengosongkan, 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 untuk memulai pemrosesan data.
Bagian ini membahas kegagalan dalam 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 lagi empat kali. Dataflow menghentikan tugas jika satu paket gagal empat kali. Proses ini menangani banyak masalah sementara. Namun, jika kegagalan berkepanjangan terjadi, batas percobaan ulang maksimum biasanya tercapai dengan cepat, sehingga tugas dapat gagal dengan cepat.
Untuk pemantauan dan manajemen 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 melampaui batas percobaan ulang.
Untuk tugas streaming, Dataflow mencoba ulang item pekerjaan yang gagal tanpa batas waktu. Tugas tidak dihentikan. Namun, tugas mungkin berhenti hingga masalah diselesaikan. Buat kebijakan pemantauan untuk mendeteksi tanda-tanda pipeline yang terhenti, seperti peningkatan latensi sistem dan penurunan keaktualan data. Terapkan logging error dalam kode pipeline untuk membantu mengidentifikasi penghentian pipeline yang disebabkan oleh item pekerjaan yang gagal berulang kali.
Memulai ulang tugas di zona lain jika terjadi pemadaman layanan di zona
Setelah tugas dimulai, pekerja Dataflow yang menjalankan kode pengguna dibatasi pada satu zona. Jika terjadi pemadaman layanan di zona, tugas Dataflow sering terpengaruh, bergantung pada tingkat pemadaman layanan.
Untuk pemadaman layanan yang hanya memengaruhi backend Dataflow, backend akan otomatis dimigrasikan ke zona berbeda oleh layanan terkelola agar dapat melanjutkan tugas. Jika tugas menggunakan Dataflow Shuffle, backend dapat dipindahkan antar-zona. Jika migrasi backend Dataflow terjadi, tugas mungkin terhenti untuk sementara.
Jika terjadi pemadaman layanan di zona, tugas yang berjalan kemungkinan akan gagal atau terhenti hingga ketersediaan zona dipulihkan. Jika suatu zona menjadi tidak tersedia untuk jangka waktu yang lama, hentikan tugas (batalkan untuk tugas batch dan kuras untuk tugas streaming), lalu mulai ulang zona tersebut agar Dataflow dapat memilih zona baru yang sehat.
Memulai ulang tugas batch di region yang berbeda jika terjadi pemadaman layanan regional
Jika terjadi pemadaman layanan regional di region tempat tugas Dataflow Anda berjalan, tugas tersebut dapat gagal atau terhenti. Untuk tugas batch, mulai ulang tugas di region yang berbeda jika memungkinkan. Penting untuk memastikan bahwa data Anda tersedia di berbagai region.
Memitigasi pemadaman layanan regional menggunakan ketersediaan tinggi atau failover
Untuk tugas streaming, bergantung pada fault tolerance dan anggaran untuk aplikasi, Anda memiliki berbagai opsi untuk memitigasi kegagalan. Untuk pemadaman regional, opsi paling sederhana dan hemat biaya adalah menunggu hingga pemadaman berakhir. Namun, jika aplikasi Anda sensitif terhadap latensi atau jika pemrosesan data tidak boleh terganggu atau harus dilanjutkan dengan penundaan minimal, bagian berikut akan membahas opsi yang tersedia.
Ketersediaan tinggi: Sensitif terhadap latensi tanpa kehilangan data
Jika aplikasi Anda tidak dapat menoleransi 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 wilayah. Aplikasi downstream yang bergantung pada output pipeline ini harus dapat beralih di antara output dari kedua region ini. Karena duplikasi resource, opsi ini memerlukan biaya tertinggi dibandingkan 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 menoleransi potensi kehilangan data, buat sumber data streaming tersedia di beberapa region. Misalnya, dengan menggunakan Pub/Sub, pertahankan dua langganan independen untuk topik yang sama, satu untuk setiap wilayah. Jika terjadi pemadaman layanan regional, mulai pipeline pengganti di region lain, dan buat pipeline menggunakan data dari langganan cadangan.
Putar ulang langganan pencadangan ke waktu yang tepat 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 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 dengan ketersediaan tinggi. Diagram berikut menunjukkan contoh deployment.
Diagram menunjukkan alur berikut:
Pub/Sub berjalan di sebagian besar region di seluruh dunia, sehingga layanan ini dapat menawarkan akses data global yang cepat, sekaligus memberi Anda kontrol terhadap lokasi penyimpanan pesan. Pub/Sub dapat otomatis menyimpan pesan yang dipublikasikan di region Google Cloud yang paling dekat dengan pelanggan, atau Anda dapat mengonfigurasinya untuk menggunakan region atau sekumpulan region tertentu menggunakan kebijakan penyimpanan pesan.
Pub/Sub kemudian mengirimkan pesan ke pelanggan di seluruh dunia, di mana pun pesan disimpan. Klien Pub/Sub tidak perlu mengetahui lokasi server yang mereka hubungkan, karena mekanisme load balancing global mengarahkan traffic ke pusat data Google Cloud terdekat tempat pesan disimpan.
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 dari pipeline yang sama, masing-masing berjalan di region Google Cloud yang terpisah.
BigQuery menyediakan lokasi set data regional dan multi-regional. Saat memilih lokasi multi-regional, set data Anda berada di setidaknya dua wilayah geografis. Diagram ini menggambarkan dua pipeline terpisah, yang masing-masing ditulis ke set data multi-regional yang terpisah.