Bagikan melalui

Desain Azure Event Hubs dan Functions yang tangguh

  • Artikel

Penanganan kesalahan, merancang untuk idempotensi dan mengelola perilaku percobaan kembali adalah beberapa langkah penting yang dapat Anda ambil untuk memastikan fungsi yang dipicu Azure Event Hubs tangguh dan mampu menangani data dalam jumlah besar. Artikel ini membahas konsep penting ini dan membuat rekomendasi untuk solusi streaming peristiwa tanpa server.

Azure menyediakan tiga layanan olah pesan utama yang dapat digunakan dengan Azure Functions untuk mendukung berbagai skenario unik yang digerakkan oleh peristiwa. Karena model konsumen yang dipartisi dan kemampuannya untuk menyerap data pada tingkat tinggi, Azure Event Hubs umumnya digunakan untuk streaming peristiwa dan skenario data besar. Untuk perbandingan terperinci layanan olah pesan Azure, lihat Memilih antara layanan olah pesan Azure - Azure Event Grid, Azure Event Hubs, dan Azure Service Bus.

Manfaat dan tantangan streaming

Memahami manfaat dan kekurangan streaming membantu Anda menghargai cara layanan seperti Azure Event Hubs beroperasi. Anda juga memerlukan konteks ini saat membuat keputusan arsitektur yang berdampak, memecahkan masalah, dan mengoptimalkan kinerja. Pertimbangkan konsep utama berikut tentang solusi yang menampilkan Azure Event Hubs dan Functions:

  • Stream bukan antrian: Azure Event Hubs, Kafka, dan penawaran serupa lainnya yang dibangun di atas model konsumen yang dipartisi tidak secara intrinsik mendukung beberapa fitur utama dalam broker pesan seperti Azure Service Bus. Mungkin indikator terbesar dari perbedaan ini adalah fakta bahwa bacaan tidak merusak. Ini memastikan bahwa data yang dibaca oleh host Functions tetap tersedia setelahnya. Sebaliknya, pesan tidak dapat diubah dan tetap untuk dibaca konsumen lain, termasuk konsumen yang berpotensi sama membacanya lagi. Untuk alasan ini, solusi yang menerapkan pola seperti konsumen yang bersaing mungkin lebih baik disajikan dengan broker pesan seperti Bus Layanan.

  • Tidak ada dukungan surat mati yang melekat: Saluran surat mati bukan fitur asli di Azure Event Hubs atau Kafka. Seringkali, konsep surat gagal diintegrasikan ke dalam solusi streaming untuk memperhitungkan data yang tidak dapat diproses. Fungsi ini sengaja bukan merupakan elemen bawaan di Azure Event Hubs dan hanya ditambahkan di sisi konsumen untuk menghasilkan perilaku atau efek yang sama. Jika Anda memerlukan dukungan surat mati, Anda harus berpotensi meninjau pilihan layanan pesan streaming Anda.

  • Unit kerja adalah partisi: Dalam broker pesan tradisional, unit kerja adalah satu pesan. Dalam solusi streaming, partisi sering dianggap sebagai unit kerja. Jika setiap peristiwa di pusat aktivitas diperlakukan sebagai pesan berbeda yang memerlukan pemrosesan pesanan atau penanganan transaksi keuangan, ini menyarankan kesempatan untuk menjelajahi layanan olahpesan yang lebih cocok untuk performa atau pemrosesan yang optimal.

  • Tidak ada pemfilteran sisi server: Salah satu alasan Azure Event Hubs mampu melakukan skala dan throughput yang luar biasa adalah karena overhead yang rendah pada layanan itu sendiri. Fitur seperti pemfilteran sisi server, indeks, dan koordinasi lintas broker bukan bagian dari arsitektur Azure Event Hubs. Fungsi kadang-kadang digunakan untuk memfilter peristiwa dengan merutekannya ke hub peristiwa lain berdasarkan konten di isi atau header. Pendekatan ini umum dalam streaming peristiwa tetapi dilengkapi dengan peringatan bahwa fungsi awal membaca dan mengevaluasi setiap peristiwa.

  • Setiap pembaca harus membaca semua data: Karena pemfilteran sisi server tidak tersedia, konsumen secara berurutan membaca semua data dalam partisi. Ini termasuk data yang mungkin tidak relevan atau bahkan bisa salah format. Beberapa opsi dan strategi dapat digunakan untuk mengimbangi tantangan ini, yang dibahas nanti di bagian ini.

Keputusan desain yang signifikan ini memungkinkan Azure Event Hubs untuk melakukan yang terbaik: mendukung masuknya peristiwa yang signifikan dan memberikan layanan yang kuat dan tangguh bagi konsumen untuk membacanya. Setiap aplikasi konsumen ditugaskan dengan tanggung jawab mempertahankan offset atau kursor sisi klien mereka sendiri untuk peristiwa tersebut. Overhead yang rendah membuat Azure Event Hubs menjadi pilihan yang terjangkau dan andal untuk streaming peristiwa.

Idempotensi

Salah satu prinsip inti dari Azure Event Hubs adalah konsep setidaknya sekali pengiriman. Pendekatan ini memastikan bahwa peristiwa selalu dikirimkan. Ini juga berarti bahwa peristiwa dapat diterima lebih dari sekali, bahkan berulang kali, oleh konsumen seperti fungsi. Untuk alasan ini, penting bahwa fungsi yang dipicu event hub mendukung pola konsumen idempotent.

Bekerja di bagian asumsi setidaknya sekali pengiriman, terutama dalam konteks arsitektur yang digerakkan oleh peristiwa, adalah pendekatan yang bertanggung jawab untuk memproses peristiwa yang dapat dipercaya. Fungsi Anda harus idempoten sehingga hasil pemrosesan peristiwa yang sama beberapa kali sama dengan pemrosesan sekali.

Peristiwa duplikat

Ada beberapa skenario berbeda yang dapat mengakibatkan peristiwa duplikat dikirim ke satu fungsi:

  • Titik pemeriksaan: Jika host Azure Functions mengalami crash atau ambang batas yang ditetapkan untuk frekuensi titik pemeriksaan batch tidak terpenuhi, titik pemeriksaan tidak dibuat. Akibatnya, offset untuk konsumen tidak maju dan lain kali fungsi dipanggil, offset akan dilanjutkan dari titik pemeriksaan terakhir. Penting untuk dicatat bahwa titik pemeriksaan terjadi pada tingkat partisi untuk setiap konsumen.

  • Peristiwa duplikat yang diterbitkan: Banyak teknik dapat mengurangi kemungkinan peristiwa yang sama dipublikasikan ke aliran, tetapi konsumen masih bertanggung jawab untuk menangani duplikat secara idempotik.

  • Pengakuan yang hilang: Dalam beberapa situasi, permintaan keluar ke layanan mungkin berhasil, namun, pengakuan (ACK) dari layanan tidak pernah diterima. Persepsi ini dapat mengakibatkan keyakinan bahwa panggilan keluar gagal dan memulai serangkaian percobaan ulang atau hasil lain dari fungsi. Pada akhirnya, peristiwa duplikat dapat dipublikasikan, atau titik pemeriksaan tidak dibuat.

Teknik deduplikasi

Merancang fungsi Anda untuk input yang identik harus menjadi pendekatan default yang diambil ketika dipasangkan dengan ikatan pemicu Event Hub. Anda harus mempertimbangkan teknik berikut:

  • Mencari duplikat: Sebelum diproses, ambil langkah-langkah yang diperlukan untuk memvalidasi bahwa peristiwa harus diproses. Dalam beberapa kasus, ini memerlukan penyelidikan untuk mengonfirmasi bahwa itu masih valid. Mungkin juga penanganan peristiwa tidak lagi diperlukan karena kesegaran atau logika data yang membuat peristiwa tersebut tidak valid.

  • Merancang peristiwa untuk idempotensi: Dengan memberikan informasi tambahan dalam payload peristiwa, dimungkinkan untuk memastikan bahwa memprosesnya beberapa kali tidak memiliki efek yang merugikan. Ambil contoh peristiwa yang mencakup penarikan dana dari rekening bank. Jika tidak ditangani secara bertanggung jawab, ada kemungkinan bahwa hal itu bisa mengurangi saldo rekening beberapa kali. Namun, jika peristiwa yang sama menyertakan pembaruan saldo ke rekening, peristiwa tersebut dapat digunakan untuk melakukan operasi upsert ke saldo rekening bank. Pendekatan transfer status yang dibawa peristiwa ini terkadang membutuhkan koordinasi antara produsen dan konsumen dan harus digunakan ketika sesuai untuk berpartisipasi dalam layanan.

Penanganan kesalahan dan percobaan ulang

Penanganan kesalahan dan uji coba ulang adalah beberapa kualitas terpenting dari aplikasi terdistribusi, berbasis peristiwa, dan Functions tidak terkecuali. Untuk solusi streaming peristiwa, kebutuhan akan dukungan penanganan kesalahan yang tepat sangat penting, karena ribuan peristiwa dapat dengan cepat berubah menjadi jumlah kesalahan yang sama jika tidak ditangani dengan benar.

Panduan penanganan kesalahan

Tanpa penanganan kesalahan, mungkin sulit untuk menerapkan percobaan kembali, mendeteksi pengecualian runtime, dan menyelidiki masalah. Setiap fungsi harus memiliki setidaknya beberapa tingkat atau penanganan kesalahan. Beberapa panduan yang direkomendasikan adalah:

  • Gunakan Application Insights: Aktifkan dan gunakan Application Insights untuk mencatat kesalahan dan memantau kesehatan fungsi Anda. Perhatikan opsi pengambilan sampel yang dapat dikonfigurasi untuk skenario yang memproses volume peristiwa yang tinggi.

  • Menambahkan penanganan kesalahan terstruktur: Terapkan konstruksi penanganan kesalahan yang sesuai untuk setiap bahasa pemrograman untuk menangkap, mencatat, dan mendeteksi pengecualian yang diantisipasi dan tidak ditangani dalam kode fungsi Anda. Misalnya, gunakan blok coba/tangkap di C#, Java dan JavaScript dan manfaatkan blok coba dan kecualikan di Python untuk menangani pengecualian.

  • Pencatatan: Menangkap pengecualian selama eksekusi memberikan kesempatan untuk mencatat informasi penting yang dapat digunakan untuk mendeteksi, mereproduksi, dan memperbaiki masalah dengan andal. Catat pengecualian, bukan hanya pesan, tetapi isi, pengecualian dalam, dan artefak berguna lainnya yang berguna nanti.

  • Jangan menangkap dan mengabaikan pengecualian: Salah satu hal terburuk yang dapat Anda lakukan adalah menangkap pengecualian dan tidak melakukan apa pun. Jika Anda menangkap pengecualian generik, catat di suatu tempat. Jika Anda tidak mencatat kesalahan, sulit untuk menyelidiki bug dan melaporkan masalah.

Percobaan kembali

Menerapkan logika percobaan kembali dalam arsitektur streaming peristiwa bisa rumit. Mendukung token pembatalan, jumlah percobaan kembali, dan strategi backoff eksponensial hanyalah beberapa pertimbangan yang membuatnya menantang. Untungnya, Fungsi menyediakan kebijakan percobaan kembali yang dapat menebus banyak tugas-tugas ini yang biasanya Anda kode sendiri.

Beberapa faktor penting yang harus dipertimbangkan saat menggunakan kebijakan coba kembali dengan pengikatan Event Hub, meliputi:

  • Hindari percobaan ulang yang tidak terbatas: Saat pengaturan jumlah coba lagi maks diatur ke nilai -1, fungsi akan mencoba kembali tanpa batas waktu. Secara umum, uji ulang yang tidak terbatas harus digunakan dengan hemat dengan Functions dan hampir tidak pernah dengan pengikatan pemicu Event Hub.

  • Pilih strategi percobaan kembali yang sesuai: Strategi penundaan tetap mungkin optimal untuk skenario yang menerima tekanan balik dari layanan Azure lainnya. Dalam kasus ini, penundaan dapat membantu menghindari throttling dan keterbatasan lain yang dihadapi dari layanan tersebut. Strategi backoff eksponensial menawarkan lebih banyak fleksibilitas untuk mencoba kembali interval penundaan dan biasanya digunakan saat terintegrasi dengan layanan pihak ketiga, titik akhir REST, dan layanan Azure lainnya.

  • Pertahankan interval dan jumlah percobaan kembali rendah: Jika memungkinkan, cobalah untuk mempertahankan interval percobaan kembali lebih pendek dari satu menit. Juga, pertahankan jumlah maksimum upaya percobaan kembali ke angka yang cukup rendah. Pengaturan ini sangat relevan saat dijalankan dalam rencana Konsumsi Functions.

  • Pola pemutus sirkuit: Kesalahan kegagalan sementara dari waktu ke waktu diharapkan dan kasus penggunaan alami untuk percobaan kembali. Namun, jika sejumlah besar kegagalan atau masalah terjadi selama pemrosesan fungsi, mungkin masuk akal untuk menghentikan fungsi, mengatasi masalah dan memulai kembali nanti.

Poin penting untuk kebijakan percobaan kembali di Functions adalah bahwa ini adalah fitur upaya terbaik untuk memproses ulang peristiwa. Hal tersebut tidak menggantikan kebutuhan untuk penanganan kesalahan, pencatatan, dan pola penting lainnya yang memberikan ketahanan terhadap kode Anda.

Strategi untuk kegagalan dan data yang rusak

Ada beberapa pendekatan penting yang dapat Anda gunakan untuk mengompensasi masalah yang muncul karena kegagalan atau data rusak dalam aliran peristiwa. Beberapa strategi dasar adalah:

  • Berhenti mengirim dan membaca: Untuk memperbaiki masalah yang mendasar, jeda pembacaan dan penulisan peristiwa. Manfaat dari pendekatan ini adalah data tidak akan hilang, dan operasi dapat dilanjutkan setelah perbaikan diluncurkan. Pendekatan ini mungkin memerlukan komponen pemutus sirkuit dalam arsitektur dan mungkin pemberitahuan ke layanan yang terkena dampak untuk mencapai jeda. Dalam beberapa kasus, menghentikan fungsi mungkin diperlukan sampai masalah diselesaikan.

  • Jatuhkan pesan: Jika pesan tidak penting atau dianggap tidak penting, pertimbangkan untuk melanjutkan dan tidak memprosesnya. Pendekatan ini tidak berfungsi untuk skenario yang membutuhkan konsistensi yang kuat seperti perekaman bergerak dalam pencocokan catur atau transaksi berbasis keuangan. Penanganan kesalahan di dalam fungsi disarankan untuk menangkap dan menjatuhkan pesan yang tidak dapat diproses.

  • Percobaan kembali: Ada banyak situasi yang mungkin memerlukan pemrosesan ulang suatu peristiwa. Skenario yang paling umum adalah kesalahan sementara yang terjadi saat memanggil layanan atau dependensi lain. Kesalahan jaringan, batas dan ketersediaan layanan, dan konsistensi yang kuat mungkin adalah kasus penggunaan yang paling sering yang membenarkan upaya pemrosesan ulang.

  • Surat gagal: Idenya di sini adalah untuk mempublikasikan peristiwa ke event hub yang berbeda sehingga aliran yang ada tidak terganggu. Persepsinya adalah bahwa ia dipindahkan dari jalur panas dan dapat ditangani nanti atau oleh proses yang berbeda. Solusi ini sering digunakan untuk menangani pesan atau peristiwa beracun. Setiap fungsi yang dikonfigurasi dengan grup konsumen yang berbeda masih akan menemukan data yang buruk atau rusak dalam aliran mereka dan harus menanganinya secara bertanggung jawab.

  • Percobaan kembali dan surat gagal: Kombinasi dari berbagai upaya percobaan kembali sebelum akhirnya menerbitkan ke aliran surat gagal setelah ambang batas terpenuhi, adalah metode lain yang sudah dikenal.

  • Gunakan registri skema: Registri skema dapat digunakan sebagai alat proaktif untuk membantu meningkatkan konsistensi dan kualitas data. Azure Schema Registry dapat mendukung transisi skema bersama dengan pembuatan versi dan mode kompatibilitas yang berbeda seiring berkembangnya skema. Pada intinya, skema berfungsi sebagai kontrak antara produsen dan konsumen, yang dapat mengurangi kemungkinan data yang tidak valid atau rusak dipublikasikan ke aliran.

Pada akhirnya, tidak ada solusi sempurna serta konsekuensi dan pengorbanan dari masing-masing strategi perlu diperiksa secara menyeluruh. Berdasarkan persyaratan, menggunakan beberapa teknik ini secara bersamaan mungkin merupakan pendekatan terbaik.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Sebelum melanjutkan, pertimbangkan untuk meninjau artikel terkait ini:

Keamanan

Pemrosesan peristiwa tanpa server adalah arsitektur referensi yang merinci arsitektur umum jenis ini, dengan sampel kode dan diskusi tentang pertimbangan pentingnya.