Bagikan melalui

Pemrosesan aktivitas yang andal Azure Functions

  • Artikel

Pemrosesan aktivitas adalah salah satu skenario paling umum yang terkait dengan arsitektur tanpa server. Artikel ini menjelaskan cara membuat prosesor pesan yang andal dengan Azure Functions untuk menghindari kehilangan pesan.

Tantangan aliran aktivitas dalam sistem terdistribusi

Pertimbangkan sistem yang mengirimkan aktivitas pada tingkat konstan 100 aktivitas per detik. Pada tingkat ini, dalam beberapa menit beberapa instans Functions paralel dapat mengonsumsi 100 aktivitas yang masuk setiap detik.

Namun, salah satu dari kondisi kurang optimal berikut mungkin terjadi:

  • Bagaimana jika penerbit aktivitas mengirim aktivitas yang rusak?
  • Bagaimana jika instans Functions Anda menemukan pengecualian yang tidak tertangani?
  • Bagaimana jika sistem hilir menjadi offline?

Bagaimana Anda menangani situasi ini sambil mempertahankan throughput aplikasi Anda?

Dengan antrean, olah pesan yang andal datang secara alami. Saat dipasangkan dengan pemicu Functions, fungsi membuat kunci pada pesan antrean. Jika pemrosesan gagal, kunci dilepaskan untuk mengizinkan instans lain mencoba kembali pemrosesan. Pemrosesan kemudian berlanjut sampai pesan berhasil dievaluasi atau ditambahkan ke antrean racun.

Bahkan saat satu pesan antrean mungkin tetap dalam siklus percobaan kembali, eksekusi paralel lainnya terus berlanjut untuk menghilangkan antrean pesan yang tersisa. Hasilnya adalah bahwa throughput keseluruhan sebagian besar tetap tidak terpengaruh oleh satu pesan buruk. Namun, antrean penyimpanan tidak menjamin pemesanan dan tidak dioptimalkan untuk permintaan throughput tinggi yang diperlukan oleh Azure Event Hubs.

Sebaliknya, Azure Event Hubs tidak menyertakan konsep penguncian. Untuk memungkinkan fitur seperti throughput tinggi, beberapa grup konsumen, dan kemampuan pemutaran kembali, aktivitas Azure Event Hubs berperilaku lebih seperti pemutar video. Aktivitas dibaca dari satu titik dalam aliran per partisi. Dari pointer, Anda dapat membaca maju atau mundur dari lokasi tersebut, tetapi Anda harus memilih untuk memindahkan pointer agar aktivitas dapat diproses.

Saat kesalahan terjadi dalam aliran, jika Anda memutuskan untuk mempertahankan pointer di spot yang sama, pemrosesan aktivitas diblokir hingga pointer dimajukan. Dengan kata lain, jika pointer dihentikan untuk menangani masalah pemrosesan satu aktivitas, aktivitas yang tidak diproses mulai menumpuk.

Azure Functions menghindari kebuntuan dengan memajukan pointer aliran terlepas dari keberhasilan atau kegagalan. Karena pointer terus maju, fungsi Anda perlu menangani kegagalan dengan tepat.

Bagaimana Azure Functions menggunakan aktivitas Event Hub

Azure Functions mengonsumsi aktivitas Event Hub saat berputar melalui langkah-langkah berikut:

  1. Pointer dibuat dan bertahan di Azure Storage untuk setiap partisi hub aktivitas.
  2. Saat pesan baru diterima (dalam batch secara default), host mencoba untuk memicu fungsi dengan batch pesan.
  3. Jika fungsi menyelesaikan eksekusi (dengan atau tanpa pengecualian), pointer maju dan titik pemeriksaan disimpan ke akun penyimpanan.
  4. Jika kondisi mencegah eksekusi fungsi selesai, host gagal untuk memajukan pointer. Jika pointer tidak maju, maka pemeriksaan selanjutnya akan memproses pesan yang sama.
  5. Ulangi langkah 2–4

Perilaku ini mengungkapkan beberapa poin penting:

Menangani pengecualian

Sebagai aturan umum, setiap fungsi harus menyertakan blok coba/tangkap pada tingkat kode tertinggi. Secara khusus, semua fungsi yang mengonsumsi aktivitas Azure Event Hubs harus memiliki blok catch. Dengan demikian, saat pengecualian dimunculkan, blok tangkap menangani kesalahan sebelum pointer maju.

Mencoba kembali mekanisme dan kebijakan

Beberapa pengecualian bersifat sementara dan tidak muncul kembali saat operasi dicoba lagi beberapa saat kemudian. Inilah sebabnya mengapa langkah pertama adalah selalu mencoba kembali operasi. Anda dapat memanfaatkan kebijakan percobaan kembali aplikasi fungsi atau logika percobaan kembali penulis dalam eksekusi fungsi.

Memperkenalkan perilaku penanganan kesalahan ke fungsi Anda memungkinkan Anda menentukan kebijakan percobaan kembali dasar dan lanjutan. Misalnya, Anda dapat mengimplementasikan kebijakan yang mengikuti alur kerja yang diilustrasikan oleh aturan berikut:

  • Coba masukkan pesan tiga kali (berpotensi dengan penundaan antara percobaan kembali).
  • Jika hasil akhir dari semua percobaan kembali adalah gagal, maka tambahkan pesan ke antrean sehingga pemrosesan dapat dilanjutkan di aliran.
  • Pesan yang rusak atau belum diproses kemudian ditangani nanti.

Catatan

Polly adalah contoh pustaka ketahanan dan penanganan kesalahan sementara untuk aplikasi C#.

Kesalahan non-pengecualian

Beberapa masalah muncul bahkan saat tidak ada kesalahan. Misalnya, pertimbangkan kegagalan yang terjadi di tengah eksekusi. Dalam hal ini, jika fungsi tidak menyelesaikan eksekusi, pointer offset tidak pernah maju. Jika pointer tidak maju, maka instans apa pun yang berjalan setelah eksekusi yang gagal terus membaca pesan yang sama. Situasi ini memberikan jaminan "setidaknya sekali".

Jaminan bahwa setiap pesan diproses setidaknya satu kali menyiratkan bahwa beberapa pesan dapat diproses lebih dari sekali. Aplikasi fungsi Anda perlu menyadari kemungkinan ini dan harus dibangun berdasarkan prinsip-prinsip idempotensi.

Menghentikan dan memulai kembali eksekusi

Meskipun beberapa kesalahan mungkin dapat diterima, bagaimana jika aplikasi Anda mengalami kegagalan yang signifikan? Anda mungkin ingin berhenti memicu aktivitas sampai sistem mencapai status yang sehat. Memiliki kesempatan untuk menjeda pemrosesan sering dicapai dengan pola pemutus sirkuit. Pola pemutus sirkuit memungkinkan aplikasi Anda untuk "memutuskan sirkuit" dari proses aktivitas dan melanjutkan di lain waktu.

Ada dua bagian yang diperlukan untuk mengimplementasikan pemutus arus dalam proses aktivitas:

  • Status bersama di semua instans untuk melacak dan memantau kesehatan sirkuit
  • Proses master yang dapat mengelola status sirkuit (terbuka atau tertutup)

Detail implementasi dapat bervariasi, tetapi untuk berbagi status di antara instans, Anda memerlukan mekanisme penyimpanan. Anda dapat memilih untuk menyimpan status di Azure Storage, cache Redis, atau akun lain apa pun yang dapat diakses oleh koleksi fungsi.

Azure Logic Apps atau fungsi yang tahan lama sangat cocok untuk mengelola alur kerja dan status sirkuit. Layanan lain mungkin juga berfungsi dengan baik, tetapi aplikasi logika digunakan untuk contoh ini. Dengan menggunakan aplikasi logika, Anda dapat menjeda dan memulai kembali eksekusi fungsi yang memberi Anda kontrol yang diperlukan untuk mengimplementasikan pola pemutus sirkuit.

Menentukan ambang kegagalan di seluruh instans

Untuk memperhitungkan beberapa aktivitas yang memproses instans secara bersamaan, status eksternal bersama yang bertahan diperlukan untuk memantau kesehatan sirkuit.

Aturan yang mungkin Anda pilih untuk diimplementasikan mungkin memberlakukan bahwa:

  • Jika ada lebih dari 100 kegagalan yang mungkin terjadi dalam waktu 30 detik di semua instans, maka putuskan sirkuit dan hentikan pemicuan pada pesan baru.

Detail implementasi akan bervariasi sesuai kebutuhan Anda, tetapi secara umum Anda dapat membuat sistem yang:

  1. Mencatat kegagalan ke akun penyimpanan (Azure Storage, Redis, dll.)
  2. Saat kegagalan baru dicatat, periksa hitungan bergulir untuk melihat apakah ambang terpenuhi (misalnya, lebih dari 100 dalam 30 detik terakhir).
  3. Jika ambang terpenuhi, keluarkan aktivitas ke Azure Event Grid yang memberi tahu sistem untuk memutus sirkuit.

Mengelola status sirkuit dengan Azure Logic Apps

Deskripsi berikut menyoroti satu cara Anda dapat membuat Azure Logic App untuk menghentikan pemrosesan aplikasi Functions.

Azure Logic Apps hadir dengan konektor bawaan ke berbagai layanan, menampilkan orkestrasi stateful, dan merupakan pilihan alami untuk mengelola status sirkuit. Setelah mendeteksi bahwa sirkuit perlu diputus, Anda dapat membangun aplikasi logika untuk mengimplementasikan alur kerja berikut:

  1. Memicu alur kerja Event Grid dan menghentikan Azure Function (dengan konektor Azure Resource)
  2. Mengirim email pemberitahuan yang menyertakan opsi untuk memulai kembali alur kerja

Penerima email dapat menyelidiki kesehatan sirkuit dan, jika sesuai, memulai kembali sirkuit melalui tautan di email pemberitahuan. Saat alur kerja memulai kembali fungsi, pesan diproses dari titik pemeriksaan Event Hub terakhir.

Dengan menggunakan pendekatan ini, tidak ada pesan yang hilang, semua pesan diproses secara berurutan, dan Anda dapat memutus sirkuit selama diperlukan.

Sumber

Langkah berikutnya

Untuk informasi selengkapnya, lihat sumber daya berikut: