Pola Pengawas Agen Penjadwal

Mengoordinasikan serangkaian tindakan terdistribusi sebagai satu operasi. Jika salah satu tindakan gagal, cobalah untuk menangani kegagalan secara transparan, atau membatalkan pekerjaan yang telah dilakukan, sehingga seluruh operasi berhasil atau gagal secara keseluruhan. Hal ini dapat menambah ketahanan pada sistem terdistribusi, dengan memungkinkannya untuk memulihkan dan mencoba kembali tindakan yang gagal karena pengecualian sementara, kesalahan jangka panjang, dan kegagalan proses.

Konteks dan masalah

Aplikasi melakukan tugas yang mencakup sejumlah langkah yang beberapa di antaranya memanggil layanan jarak jauh atau mengakses sumber daya jarak jauh. Langkah-langkah individu mungkin independen satu sama lain, tetapi langkah tersebut diatur oleh logika aplikasi yang menerapkan tugasnya.

Bila memungkinkan, aplikasi harus memastikan bahwa tugas berjalan sampai selesai dan menyelesaikan setiap kegagalan yang mungkin terjadi ketika mengakses layanan atau sumber daya jarak jauh. Kegagalan dapat terjadi karena berbagai alasan. Misalnya, jaringan mungkin tidak berfungsi, komunikasi dapat terganggu, layanan jarak jauh mungkin tidak responsif atau dalam keadaan tidak stabil, atau sumber daya jarak jauh mungkin sementara tidak dapat diakses, mungkin karena kendala sumber daya. Dalam banyak kasus kegagalan akan bersifat sementara dan dapat ditangani dengan menggunakan Pola coba kembali.

Jika aplikasi mendeteksi kegagalan yang lebih permanen yang tidak dapat dengan mudah dipulihkan, aplikasi harus dapat memulihkan sistem ke keadaan yang konsisten dan memastikan integritas seluruh operasi.

Solusi

Pola Pengawas Agen Penjadwal mendefinisikan pelaku berikut. Para pelaku ini mengatur langkah-langkah yang akan dilakukan sebagai bagian dari keseluruhan tugas.

• Scheduler mengatur langkah-langkah yang membentuk tugas yang akan dieksekusi dan mengatur operasi mereka. Langkah-langkah ini dapat digabungkan menjadi alur atau alur kerja. Scheduler bertanggung jawab untuk memastikan bahwa langkah-langkah dalam alur kerja ini dilakukan dalam urutan yang benar. Saat setiap langkah dilakukan, Scheduler mencatat keadaan alur kerja, seperti "langkah belum dimulai," "langkah berjalan", atau "langkah selesai." Informasi status juga harus mencakup batas atas waktu yang diizinkan untuk langkah untuk diselesaikan, yang disebut waktu selesai. Jika langkah memerlukan akses ke layanan atau sumber daya jarak jauh, Scheduler memanggil Agen yang sesuai, meneruskannya detail pekerjaan yang akan dilakukan. Scheduler biasanya berkomunikasi dengan Agen menggunakan pesan permintaan/respons asinkron. Ini dapat diimplementasikan menggunakan antrean, meskipun teknologi pesan terdistribusi lainnya dapat digunakan sebagai gantinya.

  Scheduler melakukan fungsi yang mirip dengan Manajer Proses dalam pola Manajer Proses. Alur kerja yang sebenarnya biasanya didefinisikan dan diimplementasikan oleh mesin alur kerja yang dikendalikan oleh Scheduler. Pendekatan ini memisahkan logika bisnis dalam alur kerja dari Scheduler.

• Agen berisi logika yang merangkum panggilan ke layanan jarak jauh, atau akses ke sumber daya jarak jauh yang dirujuk oleh langkah dalam tugas. Setiap Agen biasanya membungkus panggilan ke satu layanan atau sumber daya, menerapkan penanganan kesalahan yang sesuai dan mencoba kembali logika (tunduk pada batasan batas waktu, dijelaskan kemudian). Saat menerapkan logika coba lagi, berikan pengidentifikasi stabil di semua upaya coba lagi sehingga layanan jarak jauh dapat menggunakannya untuk logika deduplikasi apa pun yang mungkin dimilikinya. Jika langkah-langkah dalam alur kerja yang dijalankan oleh Scheduler menggunakan beberapa layanan dan sumber daya di berbagai langkah, setiap langkah mungkin merujuk Agen yang berbeda (ini adalah detail implementasi dari pola).

• Supervisor memantau status langkah-langkah dalam tugas yang dilakukan oleh Scheduler. Ini berjalan secara berkala (frekuensi akan khusus sistem), dan memeriksa status langkah-langkah yang dikelola oleh Scheduler. Jika mendeteksi ada yang telah kehabisan waktu atau gagal, ia mengatur Agen yang sesuai untuk memulihkan langkah atau menjalankan tindakan perbaikan yang sesuai (ini mungkin melibatkan perubahan status langkah). Perhatikan bahwa tindakan pemulihan atau perbaikan dilaksanakan oleh Scheduler dan Agen. Supervisor hanya cukup meminta agar tindakan ini dilakukan.

Scheduler, Agen, dan Supervisor adalah komponen logis dan implementasi fisiknya tergantung pada teknologi yang digunakan. Misalnya, beberapa agen logika dapat diimplementasikan sebagai bagian dari satu layanan web.

Scheduler menyimpan informasi tentang progres tugas dan status setiap langkah di penyimpanan data yang tahan lama, yang disebut penyimpanan status. Supervisor dapat menggunakan informasi ini untuk membantu menentukan apakah suatu langkah telah gagal. Angka tersebut menggambarkan hubungan antara Scheduler, Agen, Supervisor, dan penyimpanan status.

Ketika aplikasi siap untuk menjalankan tugas, aplikasi mengajukan permintaan ke Scheduler. Scheduler mencatat informasi status awal tentang tugas dan langkah-langkahnya (misalnya, langkah belum dimulai) di penyimpanan status bagian dan kemudian mulai melakukan operasi yang ditentukan oleh alur kerja. Saat Scheduler memulai setiap langkah, Scheduler memperbarui informasi tentang status langkah tersebut di penyimpanan status (misalnya, langkah sedang berjalan).

Jika langkah merujuk layanan jarak jauh atau sumber daya, Scheduler mengirimkan pesan ke Agen yang sesuai. Pesan berisi informasi yang perlu diteruskan Agen ke layanan atau mengakses sumber daya, selain waktu penyelesaian untuk operasi. Jika Agen berhasil menyelesaikan operasinya, Agen mengembalikan respons ke Scheduler. Scheduler kemudian dapat memperbarui informasi status di penyimpanan status (misalnya, langkah selesai) dan melakukan langkah berikutnya. Proses ini berlanjut sampai seluruh tugas selesai.

Agen dapat menerapkan logika percobaan kembali yang diperlukan untuk melakukan pekerjaannya. Namun, jika Agen tidak menyelesaikan pekerjaannya sebelum periode selesai berakhir, Scheduler akan berasumsi bahwa operasi telah gagal. Dalam hal ini, Agen harus menghentikan pekerjaannya dan tidak mencoba mengembalikan apa pun ke Scheduler (bahkan bukan pesan kesalahan), atau mencoba segala bentuk pemulihan. Alasan untuk pembatasan ini adalah bahwa, setelah langkah telah kehabisan waktu atau gagal, contoh lain dari Agen mungkin dijadwalkan untuk menjalankan langkah gagal (proses ini dijelaskan kemudian).

Jika Agen gagal, Scheduler tidak akan menerima respons. Pola ini tidak membuat perbedaan antara langkah yang kehabisan waktu dan yang benar-benar gagal.

Jika langkah kehabisan waktu atau gagal, penyimpanan status akan berisi catatan yang menunjukkan bahwa langkah tersebut sedang berjalan, tetapi melewati waktu selesai. Supervisor mencari langkah-langkah seperti ini dan mencoba memulihkannya. Salah satu strategi yang mungkin adalah Supervisor memperbarui nilai total untuk memperpanjang waktu yang tersedia untuk menyelesaikan langkah tersebut, kemudian mengirim pesan ke Scheduler yang mengidentifikasi langkah yang kehabisan waktu. Scheduler kemudian dapat mencoba mengulangi langkah ini. Namun, desain ini mengharuskan tugas menjadi idempogen. Sistem harus berisi infrastruktur untuk menjaga konsistensi. Untuk informasi selengkapnya, lihat Infrastruktur yang Dapat Diulang, Aplikasi Arsitek Azure untuk ketahanan dan ketersediaan, dan Panduan keputusan konsistensi sumber daya.

Supervisor mungkin perlu mencegah langkah yang sama untuk dicoba kembali jika terus gagal atau kehabisan waktu. Untuk melakukan ini, Supervisor dapat mempertahankan perhitungan percobaan ulang untuk setiap langkah, bersama dengan informasi status, di penyimpanan status. Jika hitungan ini melebihi ambang batas yang telah ditentukan, Supervisor dapat mengadopsi strategi menunggu waktu yang lama sebelum memberi tahu Scheduler bahwa ia harus mencoba kembali langkah tersebut, dengan harapan bahwa kesalahan akan diselesaikan selama periode ini. Atau, Supervisor dapat mengirim pesan ke Scheduler untuk meminta seluruh tugas dibatalkan dengan menerapkan pola Transaksi Kompensasi. Pendekatan ini akan tergantung pada Scheduler dan Agen yang memberikan informasi yang diperlukan untuk menerapkan operasi kompensasi untuk setiap langkah yang berhasil diselesaikan.

Ini bukan tujuan dari Supervisor untuk memantau Scheduler dan Agen, dan memulai ulang mereka jika mereka gagal. Aspek sistem ini harus ditangani oleh infrastruktur yang dijalankan oleh komponen-komponen ini. Demikian pula, Supervisor tidak boleh memiliki pengetahuan tentang operasi bisnis aktual yang dilakukan oleh tugas yang dilakukan Scheduler (termasuk cara mengompensasi jika tugas-tugas ini gagal). Ini adalah tujuan logika alur kerja yang diterapkan oleh Scheduler. Satu-satunya tanggung jawab Supervisor adalah untuk menentukan apakah suatu langkah telah gagal dan mengaturnya agar dapat diulang atau untuk seluruh tugas yang berisi langkah yang gagal untuk dibatalkan.

Jika Scheduler dimulai ulang setelah kegagalan, atau alur kerja yang dilakukan oleh Scheduler berakhir secara tak terduga, Scheduler harus dapat menentukan status tugas inflight yang sedang ditanganinya ketika gagal, dan bersiaplah untuk melanjutkan tugas ini dari titik tersebut. Detail implementasi dari proses ini cenderung khusus sistem. Jika tugas tidak dapat dipulihkan, mungkin perlu untuk membatalkan pekerjaan yang sudah dilakukan oleh tugas. Ini mungkin juga memerlukan penerapan transaksi kompensasi.

Keuntungan utama dari pola ini adalah bahwa sistem tangguh jika terjadi kegagalan sementara yang tidak terduga atau kegagalan yang tidak dapat dipulihkan. Sistem ini dapat dibangun untuk penyembuhan sendiri. Misalnya, jika Agen atau Scheduler gagal, yang baru dapat dimulai dan Supervisor dapat mengatur tugas yang akan dilanjutkan. Jika Supervisor gagal, instans lain dapat dimulai dan dapat mengambil alih dari tempat kegagalan terjadi. Jika Supervisor dijadwalkan untuk berjalan secara berkala, instans baru dapat dimulai secara otomatis setelah interval yang telah ditentukan sebelumnya. Penyimpanan status dapat direplikasi untuk mencapai tingkat ketahanan yang lebih besar.

Masalah dan pertimbangan

Anda harus mempertimbangkan poin berikut saat memutuskan cara menerapkan pola ini:

• Pola ini bisa sulit diterapkan dan memerlukan pengujian menyeluruh dari setiap mode kegagalan sistem yang mungkin.

• Logika pemulihan/percobaan kembali yang diterapkan oleh Scheduler bersifat kompleks dan tergantung pada informasi status yang disimpan di penyimpanan status. Mungkin juga perlu untuk mencatat informasi yang diperlukan untuk menerapkan transaksi kompensasi di penyimpanan data yang tahan lama.

• Seberapa sering Supervisor berjalan akan menjadi penting. Supervisor harus berjalan cukup sering untuk mencegah langkah yang gagal memblokir aplikasi untuk waktu yang lama, tetapi seharusnya tidak berjalan begitu sering sehingga menjadi overhead.

• Langkah-langkah yang dilakukan oleh Agen dapat dijalankan lebih dari sekali. Logika yang menerapkan langkah-langkah ini harus idempoten.

Kapan menggunakan pola ini

Gunakan pola ini ketika proses yang berjalan di lingkungan terdistribusi, seperti cloud, harus tahan terhadap kegagalan komunikasi dan/atau kegagalan operasional.

Pola ini mungkin tidak cocok untuk tugas yang tidak memanggil layanan jarak jauh atau mengakses sumber daya jarak jauh.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Pengawas Agen Penjadwal dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

Aplikasi web yang menerapkan sistem e-commerce telah disebarkan di Microsoft Azure. Pengguna dapat menjalankan aplikasi ini untuk menelusuri produk yang tersedia dan melakukan pemesanan. Antarmuka pengguna berjalan sebagai peran web, dan elemen pemrosesan pesanan aplikasi diimplementasikan sebagai seperangkat peran pekerja. Bagian dari logika pemrosesan pesanan melibatkan mengakses layanan jarak jauh, dan aspek sistem ini dapat rentan terhadap kesalahan sementara atau lebih tahan lama. Untuk alasan ini, para desainer menggunakan pola Pengawas Agen Penjadwal untuk menerapkan elemen pemrosesan pesanan dari sistem.

Ketika pelanggan melakukan pemesanan, aplikasi membangun pesan yang menjelaskan pesanan dan memposting pesan ini ke antrean. Proses pengiriman terpisah, berjalan dalam peran pekerja, mengambil pesan, memasukkan detail pesanan ke dalam database pesanan, dan membuat catatan untuk proses pemesanan di penyimpanan status. Perhatikan bahwa insert ke dalam database pesanan dan penyimpanan status dilakukan sebagai bagian dari operasi yang sama. Proses pengiriman dirancang untuk memastikan bahwa kedua insert selesai bersama-sama.

Informasi status yang dibuat oleh proses pengiriman untuk pesanan meliputi:

• OrderID. ID pesanan dalam database pesanan.

• LockedBy. ID instans peran pekerja yang menangani pesanan. Mungkin beberapa instans saat ini dari peran pekerja yang menjalankan Scheduler, tetapi setiap pesanan hanya boleh ditangani oleh satu contoh.

• CompleteBy. Waktu pesanan harus selesai diproses.

• ProcessState. Status tugas saat ini yang menangani pesanan. Status yang mungkin adalah:

  • Tertunda. Pesanan telah dibuat tetapi pemrosesan belum dimulai.
  • Sedang diproses. Pesanan saat ini sedang diproses.
  • Diproses. Pesanan telah berhasil diproses.
  • Kesalahan. Pemrosesan pesanan telah gagal.

• FailureCount. Berapa kali pemrosesan telah dicoba untuk pesanan.

Pada informasi status, bidang OrderID disalin dari ID pesanan milik pesanan baru. Bidang LockedBy dan CompleteBy diatur ke null, kolom ProcessState diatur ke Pending, dan kolom FailureCount diatur ke 0.

Scheduler juga berjalan sebagai bagian dari peran pekerja dan menerapkan logika bisnis yang menangani pesanan. Instans polling Scheduler untuk pesanan baru memeriksa penyimpanan status untuk catatan di mana bidang LockedBy null dan bidang ProcessState tertunda. Ketika Scheduler menemukan pesanan baru, Scheduler segera mengisi bidang LockedBy dengan ID instansnya sendiri, mengatur bidang CompleteBy ke waktu yang tepat, dan mengatur bidang ProcessState untuk diproses. Kode ini dirancang untuk menjadi eksklusif dan atomik untuk memastikan bahwa dua instans bersamaan dari Scheduler tidak dapat mencoba untuk menangani pesanan yang sama secara bersamaan.

Scheduler kemudian menjalankan alur kerja bisnis untuk memproses pesanan secara asinkron, meneruskan nilainya di bidang OrderID dari penyimpanan status. Alur kerja yang menangani pesanan mengambil detail pesanan dari database pesanan dan melakukan pekerjaannya. Ketika langkah dalam alur kerja pemrosesan pesanan perlu memanggil layanan jarak jauh, langkah menggunakan Agen. Langkah alur kerja berkomunikasi dengan Agen menggunakan sepasang antrean pesan Azure Service Bus yang bertindak sebagai saluran permintaan/respons. Angka tersebut menunjukkan tampilan solusi tingkat tinggi.

Pesan yang dikirim ke Agen dari langkah alur kerja menjelaskan pesanan dan menyertakan waktu selesai. Jika Agen menerima respons dari layanan jarak jauh sebelum waktu selesai berakhir, agen akan memposting pesan balasan di antrean Azure Service Bus tempat alur kerja mendengarkan. Ketika langkah alur kerja menerima pesan balasan yang valid, langkah tersebut menyelesaikan pemrosesannya dan Scheduler mengatur bidang ProcessState dari status pesanan untuk diproses. Pada titik ini, pemrosesan pesanan telah berhasil diselesaikan.

Jika waktu selesai berakhir sebelum Agen menerima respons dari layanan jarak jauh, Agen hanya menghentikan pemrosesannya dan berhenti menangani pesanan. Demikian pula, jika alur kerja yang menangani pesanan melebihi waktu selesai, itu juga berakhir. Dalam kedua kasus tersebut, status pesanan di penyimpanan status tetap diatur untuk diproses, tetapi waktu selesai menunjukkan bahwa waktu untuk memproses pesanan telah berlalu dan prosesnya dianggap telah gagal. Perhatikan bahwa jika Agen yang mengakses layanan jarak jauh, atau alur kerja yang menangani pesanan (atau keduanya) berakhir secara tak terduga, informasi di penyimpanan status akan kembali tetap diatur ke pemrosesan dan pada akhirnya akan memiliki nilai selesai yang kedaluwarsa.

Jika Agen mendeteksi kesalahan yang tidak dapat diperbaiki dan tidak transparan saat mencoba menghubungi layanan jarak jauh, agen dapat mengirim respons kesalahan kembali ke alur kerja. Scheduler dapat mengatur status pesanan menjadi kesalahan dan memunculkan peristiwa yang memberi tahu operator. Operator kemudian dapat mencoba menyelesaikan alasan kegagalan secara manual dan mengirimkan kembali langkah pemrosesan yang gagal.

Supervisor secara berkala memeriksa penyimpanan status untuk mencari pesanan dengan nilai selesai yang kedaluwarsa. Jika Supervisor menemukan catatan, hal itu menambah bidang FailureCount. Jika nilai hitungan kegagalan berada di bawah nilai ambang batas yang ditentukan, Supervisor mengatur ulang bidang LockedBy menjadi null, memperbarui bidang CompleteBy dengan waktu kedaluwarsa baru, dan mengatur bidang ProcessState menjadi tertunda. Instans Scheduler dapat mengambil pesanan ini dan melakukan pemrosesannya seperti sebelumnya. Jika nilai hitungan kegagalan melebihi ambang batas yang ditentukan, alasan kegagalan dianggap tidak transparan. Supervisor dapat mengatur status pesanan menjadi kesalahan dan memunculkan peristiwa yang memberi tahu operator.

Dalam contoh ini, Supervisor diimplementasikan dalam peran pekerja yang terpisah. Anda dapat menggunakan berbagai strategi untuk mengatur tugas Supervisor yang akan dijalankan, termasuk menggunakan layanan Azure Scheduler (jangan keliru dengan komponen Scheduler dalam pola ini). Untuk informasi selengkapnya tentang layanan Azure Scheduler, kunjungi halaman Scheduler.

Meskipun tidak ditampilkan dalam contoh ini, Scheduler mungkin perlu menyimpan aplikasi yang mengirimkan informasi pesanan tentang kemajuan dan status pesanan. Aplikasi dan Scheduler diisolasi satu sama lain untuk menghilangkan ketergantungan di antara mereka. Aplikasi ini tidak memiliki pengetahuan tentang instans Scheduler mana yang menangani pesanan, dan Scheduler tidak mengetahui contoh aplikasi spesifik mana yang memposting pesanan.

Untuk memungkinkan status pesanan dilaporkan, aplikasi dapat menggunakan antrean respons privatnya sendiri. Detail antrian respons ini akan dimasukkan sebagai bagian dari permintaan yang dikirim ke proses pengiriman, yang akan mencakup informasi ini di penyimpanan status. Scheduler kemudian akan memposting pesan ke antrean ini yang menunjukkan status pesanan (permintaan diterima, pesanan selesai, pesanan gagal, dan sebagainya). Hal ini seharusnya menyertakan ID pesanan dalam pesan-pesan ini sehingga mereka dapat berkorelasi dengan permintaan asli oleh aplikasi.

Langkah berikutnya

Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:

• Primer Olahpesan Asinkron. Komponen dalam pola Pengawas Agen Penjadwal biasanya berjalan terpisah satu sama lain dan berkomunikasi secara asinkron. Menjelaskan beberapa pendekatan yang dapat digunakan untuk menerapkan komunikasi asinkron berdasarkan antrian pesan.

• Referensi 6: Saga pada Saga. Contoh yang menunjukkan bagaimana pola CQRS menggunakan manajer proses (bagian dari panduan Perjalanan CQRS).

• Microsoft Azure Scheduler

Sumber daya terkait

Pola berikut mungkin juga relevan saat menerapkan pola ini:

• Pola percobaan ulang. Agen dapat menggunakan pola ini untuk mencoba kembali operasi secara transparan yang mengakses layanan atau sumber daya jarak jauh yang sebelumnya gagal. Gunakan ketika harapannya adalah penyebab kegagalan bersifat sementara dan dapat diperbaiki.

• Pola Pemutus Sirkuit. Agen dapat menggunakan pola ini untuk menangani kesalahan yang membutuhkan waktu untuk diperbaiki saat terhubung ke layanan atau sumber daya jarak jauh.

• Pola Transaksi Kompensasi. Jika alur kerja yang dilakukan oleh Scheduler tidak dapat diselesaikan dengan sukses, mungkin perlu untuk membatalkan pekerjaan apa pun yang sebelumnya dilakukan. Pola Transaksi Kompensasi menjelaskan bagaimana hal ini dapat dicapai untuk operasi yang mengikuti model konsistensi akhir. Jenis operasi ini biasanya diimplementasikan oleh Scheduler yang melakukan proses dan alur kerja bisnis yang kompleks.

• Pola Pemilihan Pemimpin. Mungkin perlu untuk mengoordinasikan tindakan beberapa instans Supervisor untuk mencegahnya dari mencoba untuk memulihkan proses gagal yang sama. Pola Pemilihan Pemimpin menjelaskan cara melakukan ini.

• Arsitektur Cloud: Pola Scheduler-Agent-Supervisor di blog Clemens Vasters

• Pola Manajer Proses