Pekerjaan latar belakang

  • Artikel

Banyak jenis aplikasi memerlukan tugas latar belakang yang berjalan secara independen dari antarmuka pengguna (UI). Contohnya termasuk pekerjaan batch, tugas pemrosesan intensif, dan proses yang berjalan lama seperti alur kerja. Pekerjaan latar belakang dapat dijalankan tanpa memerlukan interaksi pengguna--aplikasi dapat memulai pekerjaan lalu melanjutkan memproses permintaan interaktif dari pengguna. Ini dapat membantu meminimalkan beban pada antarmuka pengguna aplikasi, yang dapat meningkatkan ketersediaan dan mengurangi waktu respons interaktif.

Misalnya, jika aplikasi diperlukan untuk membuat gambar kecil gambar yang diunggah oleh pengguna, aplikasi dapat melakukannya sebagai pekerjaan latar belakang dan menyimpan gambar kecil ke penyimpanan saat selesai--tanpa pengguna perlu menunggu proses selesai. Dengan cara yang sama, pengguna yang melakukan pemesanan dapat memulai alur kerja latar belakang yang memproses pesanan, sementara antarmuka pengguna memungkinkan pengguna untuk terus menelusuri aplikasi web. Saat pekerjaan latar belakang selesai, itu dapat memperbarui data pesanan yang disimpan dan mengirim email ke pengguna yang mengonfirmasi pesanan.

Saat Anda mempertimbangkan apakah akan menerapkan tugas sebagai pekerjaan latar belakang, kriteria utamanya adalah apakah tugas dapat berjalan tanpa interaksi pengguna dan tanpa antarmuka pengguna yang perlu menunggu pekerjaan selesai. Tugas yang mengharuskan pengguna atau antarmuka pengguna untuk menunggu saat selesai mungkin tidak sesuai sebagai tugas latar belakang.

Jenis pekerjaan latar belakang

Pekerjaan latar belakang biasanya mencakup satu atau beberapa jenis pekerjaan berikut:

  • Pekerjaan intensif CPU, seperti perhitungan matematis atau analisis model struktural.
  • Pekerjaan intensif I/O, seperti mengeksekusi serangkaian transaksi penyimpanan atau mengindeks file.
  • Pekerjaan batch, seperti pembaruan data setiap malam atau pemrosesan terjadwal.
  • Alur kerja yang berjalan lama, seperti pemenuhan pesanan, atau provisi layanan dan sistem.
  • Pemrosesan data sensitif yang tugasnya diserahkan ke lokasi yang lebih aman untuk diproses. Misalnya, Anda mungkin tidak ingin memproses data sensitif dalam aplikasi web. Sebagai gantinya, Anda dapat menggunakan pola seperti pola Gatekeeper untuk mentransfer data ke proses latar belakang terisolasi yang memiliki akses ke penyimpanan yang dilindungi.

Pemicu

Pekerjaan latar belakang dapat dimulai dengan beberapa cara yang berbeda. Pekerjaan tersebut termasuk dalam salah satu kategori berikut:

  • Pemicu berdasarkan peristiwa. Tugas dimulai sebagai respons terhadap suatu peristiwa, biasanya tindakan yang diambil oleh pengguna atau langkah dalam alur kerja.
  • Pemicu berdasarkan jadwal. Tugas dipanggil pada jadwal berdasarkan timer. Ini mungkin jadwal berulang atau permintaan satu kali yang ditentukan untuk lain waktu.

Pemicu berdasarkan peristiwa

Pemanggilan berdasarkan peristiwa menggunakan pemicu untuk memulai proses di latar belakang. Contoh penggunaan pemicu berdasarkan peristiwa meliputi:

  • Antarmuka pengguna atau pekerjaan lain menempatkan pesan dalam antrean. Pesan tersebut berisi data tentang tindakan yang telah terjadi, seperti pengguna yang melakukan pemesanan. Proses di latar belakang mendengarkan antrean ini dan mendeteksi kedatangan pesan baru. Ini membaca pesan dan menggunakan data di dalamnya sebagai input ke pekerjaan latar belakang. Pola ini dikenal sebagai komunikasi berbasis pesan asinkron.
  • Antarmuka pengguna atau pekerjaan lain menyimpan atau memperbarui nilai dalam penyimpanan. Proses di latar belakang memantau penyimpanan dan mendeteksi perubahan. Ini membaca data dan menggunakannya sebagai input ke pekerjaan latar belakang.
  • Antarmuka pengguna atau pekerjaan lain membuat permintaan ke titik akhir, seperti URI HTTPS, atau API yang diekspos sebagai layanan web. Ini melewati data yang diperlukan untuk menyelesaikan proses di latar belakang sebagai bagian dari permintaan. Titik akhir atau layanan web memanggil proses di latar belakang, yang menggunakan data sebagai inputnya.

Contoh umum tugas yang cocok untuk pemanggilan berdasarkan peristiwa meliputi pemrosesan gambar, alur kerja, pengiriman informasi ke layanan jarak jauh, pengiriman pesan email, dan provisi pengguna baru dalam aplikasi multipenyewa.

Pemicu berdasarkan jadwal

Pemanggilan berdasarkan jadwal menggunakan timer untuk memulai proses di latar belakang. Contoh penggunaan pemicu berbasis jadwal meliputi:

  • Timer yang berjalan secara lokal di dalam aplikasi atau sebagai bagian dari sistem operasi aplikasi memanggil proses di latar belakang secara teratur.
  • Timer yang berjalan di aplikasi yang berbeda, seperti Azure Logic Apps, mengirimkan permintaan ke API atau layanan web secara teratur. API atau layanan web memanggil proses di latar belakang.
  • Proses atau aplikasi terpisah memulai timer yang menyebabkan proses di latar belakang dipanggil sekali setelah penundaan waktu tertentu, atau pada waktu tertentu.

Contoh umum tugas yang cocok untuk pemanggilan berdasarkan jadwal termasuk rutinitas pemrosesan batch (seperti memperbarui daftar produk terkait untuk pengguna berdasarkan perilaku terbaru mereka), tugas pemrosesan data rutin (seperti memperbarui indeks atau menghasilkan akumulasi hasil), data analisis untuk laporan harian, pembersihan retensi data, dan pemeriksaan konsistensi data.

Jika Anda menggunakan tugas berdasarkan jadwal yang harus dijalankan sebagai satu instans, perhatikan hal berikut:

  • Jika instans komputasi yang menjalankan penjadwal (seperti mesin virtual yang menggunakan tugas terjadwal Windows) diskalakan, Anda akan menjalankan beberapa instans penjadwal. Ini bisa memulai beberapa contoh tugas. Untuk informasi selengkapnya tentang ini, baca posting blog ini tentang idempotensi.
  • Jika tugas berjalan lebih lama dari periode antara peristiwa penjadwal, penjadwal dapat memulai instans tugas lain saat yang sebelumnya masih berjalan.

Mengembalikan hasil

Pekerjaan latar belakang dijalankan secara asinkron dalam proses terpisah, atau bahkan di lokasi terpisah, dari antarmuka pengguna atau proses yang menjalankan proses di latar belakang. Idealnya, proses di latar belakang adalah operasi "fire and forget", dan kemajuan eksekusinya tidak berdampak pada antarmuka pengguna atau proses panggilan. Ini berarti bahwa proses pemanggilan tidak menunggu penyelesaian tugas. Oleh karena itu, tidak dapat secara otomatis mendeteksi ketika tugas berakhir.

Jika Anda memerlukan proses di latar belakang untuk berkomunikasi dengan tugas panggilan guna menunjukkan kemajuan atau penyelesaian, Anda harus menerapkan mekanisme untuk ini. Beberapa contohnya adalah:

  • Menulis nilai indikator status ke penyimpanan yang dapat diakses oleh antarmuka pengguna atau tugas pemanggil, yang dapat memantau atau memeriksa nilai ini saat diperlukan. Data lain yang harus dikembalikan oleh proses di latar belakang ke pemanggil dapat ditempatkan ke dalam penyimpanan yang sama.
  • Menetapkan antrean balasan yang didengarkan oleh antarmuka pengguna atau pemanggil. Proses di latar belakang dapat mengirim pesan ke antrean yang menunjukkan status dan penyelesaian. Data yang harus dikembalikan oleh proses di latar belakang ke pemanggil dapat ditempatkan ke dalam pesan. Jika Anda menggunakan Azure Service Bus, Anda dapat menggunakan properti ReplyTo dan CorrelationId untuk menerapkan kemampuan ini.
  • Mengekspos API atau titik akhir dari proses di latar belakang yang dapat diakses oleh antarmuka pengguna atau pemanggil untuk mendapatkan informasi status. Data yang harus dikembalikan oleh proses di latar belakang ke pemanggil dapat disertakan dalam respons.
  • Meminta proses di latar belakang memanggil kembali ke antarmuka pengguna atau pemanggil melalui API untuk menunjukkan status pada titik yang telah ditentukan sebelumnya atau saat selesai. Ini mungkin melalui peristiwa yang diangkat secara lokal atau melalui mekanisme publish-and-subscribe. Data yang harus dikembalikan oleh proses di latar belakang ke pemanggil dapat disertakan dalam permintaan atau payload peristiwa.

Lingkungan hosting

Anda dapat menghosting proses di latar belakang dengan menggunakan berbagai layanan platform Azure yang berbeda:

  • Azure Web Apps dan WebJobs. Anda dapat menggunakan WebJobs untuk menjalankan pekerjaan kustom berdasarkan berbagai jenis skrip atau program yang dapat dijalankan dalam konteks aplikasi web.
  • Fungsi-fungsi Azure. Anda dapat menggunakan fungsi untuk pekerjaan latar belakang yang tidak berjalan untuk waktu yang lama. Kasus penggunaan lainnya adalah jika beban kerja Anda sudah dihosting di paket App Service dan kurang dimanfaatkan.
  • Azure Virtual Machines. Jika Anda memiliki layanan Windows atau ingin menggunakan Windows Task Scheduler, biasanya menghosting proses di latar belakang Anda dalam mesin virtual khusus.
  • Azure Batch. Batch adalah layanan platform yang menjadwalkan pekerjaan intensif komputasi untuk dijalankan pada kumpulan mesin virtual yang dikelola. Ini dapat secara otomatis menskalakan sumber daya komputasi.
  • Azure Kubernetes Service (AKS). Azure Kubernetes Service menyediakan lingkungan hosting terkelola untuk Kubernetes di Azure.
  • Azure Container Apps. Azure Container Apps memungkinkan Anda untuk membangun layanan mikro tanpa server berdasarkan kontainer.

Bagian berikut menjelaskan opsi ini secara lebih rinci, dan menyertakan pertimbangan untuk membantu Anda memilih opsi yang sesuai.

Azure Web Apps dan WebJobs

Anda dapat menggunakan Azure WebJobs untuk menjalankan pekerjaan kustom sebagai proses di latar belakang dalam Aplikasi Web Azure. WebJobs berjalan dalam konteks aplikasi web Anda sebagai proses berkelanjutan. WebJobs juga berjalan sebagai respons terhadap peristiwa pemicu dari Azure Logic Apps atau faktor eksternal, seperti perubahan pada blob penyimpanan dan antrean pesan. Pekerjaan dapat dimulai dan dihentikan sesuai permintaan, dan dimatikan dengan benar. Jika WebJob yang terus berjalan gagal, WebJob akan dihidupkan ulang secara otomatis. Coba lagi dan tindakan kesalahan dapat dikonfigurasi.

Saat Anda mengonfigurasi WebJob:

  • Jika Anda ingin pekerjaan merespons pemicu berdasarkan peristiwa, Anda harus mengonfigurasinya sebagai Jalankan terus menerus. Skrip atau program disimpan dalam folder bernama site/wwwroot/app_data/jobs/continuous.
  • Jika Anda ingin pekerjaan merespons pemicu berdasarkan jadwal, Anda harus mengonfigurasinya sebagai Jalankan sesuai jadwal. Skrip atau program disimpan dalam folder bernama site/wwwroot/app_data/jobs/triggered.
  • Jika Anda memilih opsi Jalankan sesuai permintaan saat Anda mengonfigurasi pekerjaan, ini akan menjalankan kode yang sama dengan opsi Jalankan sesuai jadwal saat Anda memulainya.

Azure WebJobs berjalan di dalam kotak pasir aplikasi web. Ini berarti bahwa Azure WebJobs dapat mengakses variabel lingkungan dan berbagi informasi, seperti string koneksi, dengan aplikasi web. Pekerjaan memiliki akses ke pengidentifikasi unik komputer yang menjalankan pekerjaan. string koneksi bernama AzureWebJobsStorage menyediakan akses ke antrean, blob, dan tabel Azure Storage untuk data aplikasi, dan akses ke Bus Layanan untuk olahpesan dan komunikasi. String koneksi bernama AzureWebJobsDashboard menyediakan akses ke file log tindakan pekerjaan.

Azure WebJobs memiliki karakteristik berikut:

  • Keamanan: WebJobs dilindungi oleh info masuk penyebaran aplikasi web.
  • Jenis file yang didukung: Anda dapat menentukan WebJobs dengan menggunakan skrip perintah (.cmd), file batch (.bat), skrip PowerShell (.ps1), skrip shell Bash (.sh), skrip PHP (.php), skrip Python (.py), kode JavaScript (.js), dan program yang dapat dieksekusi (.exe, .jar, dan banyak lagi).
  • Penyebaran: Anda dapat menyebarkan skrip dan executable dengan menggunakan portal Azure, dengan menggunakan Visual Studio, dengan menggunakan Azure WebJobs SDK, atau dengan menyalinnya langsung ke lokasi berikut:
    • Untuk eksekusi yang dipicu: site/wwwroot/app_data/jobs/triggered/{job name}
    • Untuk eksekusi berkelanjutan: site/wwwroot/app_data/jobs/continuous/{job name}
  • Pengelogan: Console.Out diperlakukan (ditandai) sebagai INFO. Console.Error diperlakukan sebagai ERROR. Anda dapat mengakses informasi pemantauan dan diagnostik dengan menggunakan portal Azure. Anda dapat mengunduh file log langsung dari situsnya. Mereka disimpan di lokasi berikut:
    • Untuk eksekusi yang dipicu: Vfs/data/jobs/triggered/jobName
    • Untuk eksekusi berkelanjutan: Vfs/data/jobs/continuous/jobName
  • Konfigurasi: Anda dapat mengonfigurasi WebJobs menggunakan portal, REST API, dan PowerShell. Anda dapat menggunakan file konfigurasi bernama settings.job di direktori akar yang sama dengan skrip pekerjaan untuk memberikan informasi konfigurasi suatu pekerjaan. Misalnya:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Pertimbangan

  • Secara default, WebJobs diskalakan dengan aplikasi web. Namun, Anda dapat mengonfigurasi pekerjaan untuk dijalankan pada satu instans dengan mengatur properti konfigurasi is_singleton ke true. WebJobs instans tunggal berguna untuk tugas yang tidak ingin Anda skalakan atau jalankan sebagai beberapa instans simultan, seperti pengindeksan ulang, analisis data, dan tugas serupa.
  • Untuk meminimalkan dampak pekerjaan pada performa aplikasi web, pertimbangkan untuk membuat instans Aplikasi Web Azure kosong dalam paket App Service baru untuk menghosting WebJobs yang berjalan lama atau intensif sumber daya.

Azure Functions

Opsi yang mirip dengan WebJobs adalah Azure Functions. Layanan ini tanpa server yang paling cocok untuk pemicu berdasarkan peristiwa yang berjalan dalam waktu singkat. Sebuah fungsi juga dapat digunakan untuk menjalankan tugas terjadwal melalui pemicu timer, jika dikonfigurasi untuk dijalankan pada waktu yang ditentukan.

Azure Functions bukanlah opsi yang direkomendasikan untuk tugas besar yang berjalan lama karena dapat menyebabkan masalah batas waktu yang tidak terduga. Namun, tergantung pada paket hosting, Azure Functions dapat dipertimbangkan untuk pemicu berdasarkan jadwal.

Pertimbangan

Jika proses di latar belakang diharapkan berjalan dalam waktu singkat sebagai respons terhadap suatu peristiwa, pertimbangkan untuk menjalankan tugas dalam paket Konsumsi. Waktu eksekusi dapat dikonfigurasi hingga waktu maksimum. Fungsi yang berjalan lebih lama membutuhkan biaya lebih banyak. Juga pekerjaan intensif CPU yang menghabiskan lebih banyak memori bisa lebih mahal. Jika Anda menggunakan pemicu tambahan untuk layanan sebagai bagian dari tugas Anda, pemicu tersebut akan ditagih secara terpisah.

Paket Premium lebih cocok jika Anda memiliki banyak tugas yang singkat tetapi diharapkan berjalan terus menerus. Paket ini lebih mahal karena membutuhkan lebih banyak memori dan CPU. Keuntungannya adalah Anda dapat menggunakan fitur seperti integrasi jaringan virtual.

Paket Khusus paling cocok untuk pekerjaan latar belakang jika beban kerja Anda sudah berjalan di atasnya. Jika Anda memiliki VM yang kurang dimanfaatkan, Anda dapat menjalankannya pada VM yang sama dan berbagi biaya komputasi.

Untuk informasi selengkapnya, lihat artikel berikut ini:

Azure Virtual Machines

Tugas latar belakang mungkin diterapkan dengan cara yang mencegahnya disebarkan ke Azure Web Apps, atau opsi ini mungkin tidak nyaman. Contoh umum adalah layanan Windows, dan utilitas pihak ketiga dan program yang dapat dijalankan. Contoh lain mungkin program yang ditulis untuk lingkungan eksekusi yang berbeda dari yang menghosting aplikasi. Misalnya, mungkin program Unix atau Linux yang ingin Anda jalankan dari aplikasi Windows atau .NET. Anda dapat memilih dari berbagai sistem operasi untuk mesin virtual Azure, dan menjalankan layanan Anda atau dapat dijalankan pada mesin virtual tersebut.

Untuk membantu Anda memilih kapan menggunakan Virtual Machines, lihat Perbandingan Azure App Services, Cloud Services, dan Virtual Machines. Untuk informasi tentang opsi untuk Virtual Machines, lihat Ukuran untuk mesin virtual Windows di Azure. Untuk informasi selengkapnya tentang sistem operasi dan gambar bawaan yang tersedia untuk Virtual Machines, lihat Azure Virtual Machines Marketplace.

Untuk memulai proses di latar belakang di mesin virtual terpisah, Anda memiliki berbagai opsi:

  • Anda dapat menjalankan tugas sesuai permintaan langsung dari aplikasi Anda dengan mengirimkan permintaan ke titik akhir yang diekspos oleh tugas tersebut. Ini meneruskan data apa pun yang diperlukan tugas. Titik akhir ini memanggil tugas.
  • Anda dapat mengonfigurasi tugas agar berjalan sesuai jadwal dengan menggunakan penjadwal atau timer yang tersedia di sistem operasi pilihan Anda. Misalnya, di Windows Anda dapat menggunakan Windows Task Scheduler untuk menjalankan skrip dan tugas. Atau, jika Anda memiliki SQL Server yang terinstal di mesin virtual, Anda dapat menggunakan SQL Server Agent untuk menjalankan skrip dan tugas.
  • Anda bisa menggunakan Azure Logic Apps untuk memulai tugas dengan menambahkan pesan ke antrean yang didengarkan tugas, atau dengan mengirimkan permintaan ke API yang diekspos oleh tugas.

Lihat bagian sebelumnya Pemicu untuk informasi selengkapnya tentang bagaimana Anda dapat memulai proses di latar belakang.

Pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan apakah akan menyebarkan proses di latar belakang di mesin virtual Azure:

  • Hosting proses di latar belakang di mesin virtual Azure terpisah memberikan fleksibilitas dan memungkinkan kontrol yang tepat atas inisiasi, eksekusi, penjadwalan, dan alokasi sumber daya. Namun, itu akan meningkatkan biaya runtime jika mesin virtual harus disebarkan hanya untuk menjalankan proses di latar belakang.
  • Tidak ada fasilitas untuk memantau tugas di portal Azure dan tidak ada kemampuan menghidupkan ulang otomatis untuk tugas yang gagal--meskipun Anda dapat memantau status dasar mesin virtual dan mengelolanya dengan menggunakan Cmdlet Azure Resource Manager. Namun, tidak ada fasilitas untuk mengontrol proses dan utas di node komputasi. Biasanya, menggunakan mesin virtual akan memerlukan upaya tambahan untuk menerapkan mekanisme yang mengumpulkan data dari instrumentasi dalam tugas, dan dari sistem operasi di mesin virtual. Salah satu solusi yang mungkin tepat adalah menggunakan Paket Manajemen Pusat Sistem untuk Azure.
  • Anda mungkin mempertimbangkan untuk membuat probe pemantauan yang diekspos melalui titik akhir HTTP. Kode untuk probe ini dapat melakukan pemeriksaan kesehatan, mengumpulkan informasi operasional dan statistik--atau menyusun informasi kesalahan dan mengembalikannya ke aplikasi manajemen. Untuk informasi selengkapnya, lihat Pola Pemantauan Titik Akhir Kesehatan.

Untuk informasi selengkapnya, lihat:

Azure Batch

Pertimbangkan Azure Batch jika Anda perlu menjalankan beban kerja komputasi performa tinggi (HPC) yang besar dan paralel di puluhan, ratusan, atau ribuan VM.

Layanan Batch memprovisikan VM, menetapkan tugas ke VM, menjalankan tugas, dan memantau kemajuan. Batch dapat secara otomatis menskalakan VM sebagai respons terhadap beban kerja. Batch juga menyediakan penjadwalan pekerjaan. Azure Batch mendukung VM Linux dan Windows.

Pertimbangan

Batch bekerja dengan baik dengan beban kerja paralel intrinsik. Ini juga dapat melakukan perhitungan paralel dengan langkah pengurangan di akhir, atau menjalankan Aplikasi Message Passing Interface (MPI) untuk tugas paralel yang memerlukan pengiriman pesan antar node.

Pekerjaan Azure Batch berjalan pada kumpulan node (VM). Salah satu pendekatannya adalah mengalokasikan kumpulan hanya saat dibutuhkan lalu menghapusnya setelah pekerjaan selesai. Ini memaksimalkan pemanfaatan, karena node tidak diam, tetapi pekerjaan harus menunggu node dialokasikan. Atau, Anda dapat membuat kumpulan sebelumnya. Pendekatan tersebut meminimalkan waktu yang diperlukan untuk memulai pekerjaan, tetapi dapat menghasilkan node yang tidak digunakan. Untuk informasi selengkapnya, lihat Masa pakai node kumpulan dan komputasi.

Untuk informasi selengkapnya, lihat:

Azure Kubernetes Service

Azure Kubernetes Service (AKS) mengelola lingkungan Kubernetes yang dihosting, yang memudahkan penyebaran dan manajemen aplikasi dalam kontainer.

Kontainer dapat berguna untuk menjalankan pekerjaan latar belakang. Beberapa manfaatnya antara lain:

  • Kontainer mendukung hosting dengan kepadatan tinggi. Anda dapat mengisolasi proses di latar belakang dalam sebuah kontainer, sambil menempatkan beberapa kontainer di setiap VM.
  • Orkestrator kontainer menangani penyeimbangan beban internal, mengonfigurasi jaringan internal, dan tugas konfigurasi lainnya.
  • Kontainer dapat dimulai dan dihentikan sesuai kebutuhan.
  • Azure Container Registry memungkinkan Anda mendaftarkan kontainer di dalam batas Azure. Ini dilengkapi dengan keuntungan keamanan, privasi, dan kedekatan.

Pertimbangan

  • Memerlukan pemahaman tentang cara menggunakan orkestrator kontainer. Bergantung pada keahlian tim DevOps Anda, ini mungkin atau mungkin tidak menjadi masalah.

Untuk informasi selengkapnya, lihat:

Azure Container Apps

Azure Container Apps memungkinkan Anda untuk membangun layanan mikro tanpa server berdasarkan kontainer. Fitur khas dari Container Apps meliputi:

Pertimbangan

Azure Container Apps tidak menyediakan akses langsung ke API Kube yang mendasarinya. Jika Anda memerlukan akses ke API Kube dan bidang kontrol, Anda harus menggunakan Azure Kubernetes Service. Namun, jika Anda ingin membangun aplikasi bergaya Kube dan tidak memerlukan akses langsung ke semua API Kube asli dan manajemen kluster, Container Apps memberikan pengalaman yang terkelola sepenuhnya berdasarkan praktik terbaik. Untuk alasan ini, banyak tim mungkin lebih memilih untuk mulai membangun layanan mikro kontainer dengan Azure Container Apps.

Untuk informasi selengkapnya, lihat:

Anda bisa mulai membangun aplikasi kontainer pertama Anda menggunakan mulai cepat.

Partisi

Jika Anda memutuskan untuk menyertakan proses di latar belakang dalam instans komputasi yang ada, Anda harus mempertimbangkan bagaimana hal ini akan memengaruhi atribut kualitas instans komputasi dan proses di latar belakang itu sendiri. Faktor-faktor ini akan membantu Anda memutuskan apakah akan menempatkan tugas dengan instans komputasi yang ada atau memisahkannya menjadi instans komputasi terpisah:

  • Ketersediaan: Proses di latar belakang mungkin tidak perlu memiliki tingkat ketersediaan yang sama seperti bagian lain dari aplikasi, khususnya antarmuka pengguna dan bagian lain yang terlibat langsung dalam interaksi pengguna. Proses di latar belakang mungkin lebih toleran terhadap latensi, kegagalan koneksi yang dicoba lagi, dan faktor lain yang memengaruhi ketersediaan karena operasi dapat diantrekan. Namun, harus ada kapasitas yang cukup untuk mencegah pencadangan permintaan yang dapat memblokir antrean dan memengaruhi aplikasi secara keseluruhan.

  • Skalabilitas: Proses di latar belakang cenderung memiliki persyaratan skalabilitas yang berbeda dari antarmuka pengguna dan bagian interaktif aplikasi. Penyekalaan antarmuka pengguna mungkin diperlukan untuk memenuhi puncak permintaan, sementara proses di latar belakang yang luar biasa mungkin diselesaikan selama waktu yang tidak terlalu sibuk dengan lebih sedikit instans komputasi.

  • Ketahanan: Kegagalan instans komputasi yang hanya menghosting proses di latar belakang mungkin tidak berdampak fatal pada aplikasi secara keseluruhan jika permintaan untuk tugas ini dapat diantrekan atau ditunda hingga tugas tersedia lagi. Jika instans komputasi dan/atau tugas dapat dihidupkan ulang dalam interval yang sesuai, pengguna aplikasi mungkin tidak terpengaruh.

  • Keamanan: Proses di latar belakang mungkin memiliki persyaratan atau batasan keamanan yang berbeda dari antarmuka pengguna atau bagian lain dari aplikasi. Dengan menggunakan instans komputasi terpisah, Anda dapat menentukan lingkungan keamanan yang berbeda untuk tugas tersebut. Anda juga dapat menggunakan pola seperti Gatekeeper untuk mengisolasi instans komputasi latar belakang dari antarmuka pengguna untuk memaksimalkan keamanan dan pemisahan.

  • Performa: Anda dapat memilih jenis instans komputasi untuk proses di latar belakang agar sesuai dengan persyaratan performa tugas secara khusus. Ini mungkin berarti menggunakan opsi komputasi yang lebih murah jika tugas tidak memerlukan kemampuan pemrosesan yang sama seperti antarmuka pengguna, atau instans yang lebih besar jika memerlukan kapasitas dan sumber daya tambahan.

  • Keterkelolaan: Proses di latar belakang mungkin memiliki ritme pengembangan dan penyebaran yang berbeda dari kode aplikasi utama atau antarmuka pengguna. Menyebarkannya ke instans komputasi terpisah dapat menyederhanakan pembaruan dan penerapan versi.

  • Biaya: Menambahkan instans komputasi untuk menjalankan proses di latar belakang meningkatkan biaya hosting. Anda harus hati-hati mempertimbangkan trade-off antara kapasitas tambahan dan biaya tambahan ini.

Untuk informasi selengkapnya, lihat pola Pemilihan Pemimpin dan pola Konsumen Bersaing.

Konflik

Jika Anda memiliki beberapa instans pekerjaan latar belakang, ada kemungkinan bahwa instans tersebut akan bersaing untuk mendapatkan akses ke sumber daya dan layanan, seperti database dan penyimpanan. Akses bersamaan ini dapat mengakibatkan pertentangan sumber daya, yang dapat menyebabkan konflik dalam ketersediaan layanan dan integritas data dalam penyimpanan. Anda dapat menyelesaikan pertentangan sumber daya dengan menggunakan pendekatan penguncian pesimistis. Ini mencegah instans tugas yang bersaing mengakses layanan secara bersamaan atau merusak data.

Pendekatan lain untuk menyelesaikan konflik adalah dengan menentukan proses di latar belakang sebagai tunggal, sehingga hanya ada satu instans yang berjalan. Namun, ini menghilangkan keuntungan keandalan dan performa yang dapat diberikan oleh konfigurasi multi-instans. Ini terutama benar jika antarmuka pengguna dapat menyediakan pekerjaan yang cukup untuk membuat lebih dari satu proses di latar belakang sibuk.

Sangat penting untuk memastikan bahwa proses di latar belakang dapat dihidupkan ulang secara otomatis dan memiliki kapasitas yang cukup untuk mengatasi puncak permintaan. Anda dapat mencapainya dengan mengalokasikan instans komputasi dengan sumber daya yang memadai, dengan menerapkan mekanisme antrean yang dapat menyimpan permintaan untuk eksekusi nanti saat permintaan menurun, atau dengan menggunakan kombinasi teknik ini.

Koordinasi

Proses di latar belakang mungkin rumit dan mungkin memerlukan beberapa tugas individu untuk dijalankan guna menghasilkan hasil atau untuk memenuhi semua persyaratan. Adalah umum dalam skenario ini untuk membagi tugas menjadi langkah-langkah atau sub tugas yang lebih kecil yang dapat dijalankan oleh banyak konsumen. Pekerjaan multi langkah bisa lebih efisien dan lebih fleksibel karena langkah individu mungkin dapat digunakan kembali dalam banyak pekerjaan. Juga mudah untuk menambah, menghapus, atau mengubah urutan langkah-langkahnya.

Mengoordinasikan banyak tugas dan langkah dapat menjadi tantangan, tetapi ada tiga pola umum yang dapat Anda gunakan untuk memandu penerapan solusi Anda:

  • Mengurai tugas menjadi beberapa langkah yang dapat digunakan kembali. Sebuah aplikasi mungkin diperlukan untuk melakukan berbagai tugas dengan kompleksitas yang berbeda-beda pada informasi yang diprosesnya. Pendekatan langsung tetapi tidak fleksibel untuk menerapkan aplikasi ini mungkin dengan melakukan pemrosesan ini sebagai modul monolitik. Namun, pendekatan ini kemungkinan akan mengurangi peluang untuk merefaktorkan kode, mengoptimalkannya, atau menggunakannya kembali jika bagian dari pemrosesan yang sama diperlukan di tempat lain dalam aplikasi. Untuk informasi selengkapnya, lihat Pola Pipa dan Filter.

  • Mengelola eksekusi langkah-langkah untuk tugas. Aplikasi mungkin melakukan tugas yang terdiri dari sejumlah langkah (beberapa di antaranya mungkin meminta 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. Untuk informasi selengkapnya, lihat Pola Scheduler Agent Supervisor.

  • Mengelola pemulihan untuk langkah-langkah tugas yang gagal. Aplikasi mungkin perlu membatalkan pekerjaan yang dilakukan oleh serangkaian langkah (yang bersama-sama menentukan operasi yang pada akhirnya konsisten) jika satu atau beberapa langkah gagal. Untuk informasi selengkapnya, lihat Pola Transaksi Kompensasi.

Pertimbangan ketahanan

Proses di latar belakang harus tangguh untuk memberikan layanan yang andal ke aplikasi. Saat Anda merencanakan dan mendesain proses di latar belakang, pertimbangkan poin-poin berikut:

  • Proses di latar belakang harus dapat menangani penghidupan ulang dengan baik tanpa merusak data atau memasukkan inkonsistensi ke dalam aplikasi. Untuk tugas yang berjalan lama atau beberapa langkah, pertimbangkan untuk menggunakan penunjukan pemeriksaan dengan menyimpan status pekerjaan di penyimpanan persisten, atau sebagai pesan dalam antrean jika ini sesuai. Misalnya, Anda dapat mempertahankan informasi status dalam pesan dalam antrean dan secara bertahap memperbarui informasi status ini dengan kemajuan tugas sehingga tugas dapat diproses dari titik pemeriksaan terakhir yang diketahui--bukan menghidupkan ulang dari awal. Saat menggunakan antrean Azure Service Bus, Anda dapat menggunakan sesi pesan untuk mengaktifkan skenario yang sama. Sesi memungkinkan Anda untuk menyimpan dan mengambil status pemrosesan aplikasi dengan menggunakan metode SetState dan GetState. Untuk informasi selengkapnya tentang mendesain proses dan alur kerja multi langkah yang andal, lihat Pola Scheduler Agent Supervisor.

  • Saat Anda menggunakan antrean untuk berkomunikasi dengan proses di latar belakang, antrean dapat bertindak sebagai buffer untuk menyimpan permintaan yang dikirim ke tugas saat aplikasi berada di bawah beban yang lebih tinggi dari biasanya. Ini memungkinkan tugas untuk mengejar antarmuka pengguna selama periode yang tidak terlalu sibuk. Ini juga berarti bahwa memulai ulang tidak akan memblokir antarmuka pengguna. Untuk informasi selengkapnya, lihat Pola Perataan Beban Berbasis Antrean. Jika beberapa tugas lebih penting daripada yang lain, pertimbangkan untuk menerapkan pola Antrean Prioritas untuk memastikan bahwa tugas ini berjalan sebelum tugas yang kurang penting.

  • Proses di latar belakang yang diprakarsai oleh pesan atau pesan proses harus didesain untuk menangani inkonsistensi, seperti pesan yang tiba tidak sesuai urutan, pesan yang berulang kali menyebabkan kesalahan (sering disebut sebagai pesan racun), dan pesan yang disampaikan lebih dari satu kali. Pertimbangkan hal berikut:

    • Pesan yang harus diproses dalam urutan tertentu, seperti yang mengubah data berdasarkan nilai data yang ada (misalnya, menambahkan nilai ke nilai yang sudah ada), mungkin tidak sampai dalam urutan asli pengirimannya. Atau, pesan tersebut mungkin ditangani oleh instans proses di latar belakang yang berbeda dalam urutan yang berbeda karena beban yang bervariasi pada setiap instans. Pesan yang harus diproses dalam urutan tertentu harus menyertakan nomor urut, kunci, atau indikator lain yang dapat digunakan proses di latar belakang untuk memastikan bahwa pesan diproses dalam urutan yang benar. Jika Anda menggunakan Azure Service Bus, Anda dapat menggunakan sesi pesan untuk menjamin urutan pengiriman. Namun, biasanya lebih efisien, jika memungkinkan, untuk mendesain proses sehingga urutan pesan tidak penting.

    • Biasanya, proses di latar belakang akan mengintip pesan dalam antrean, yang untuk sementara menyembunyikannya dari konsumen pesan lainnya. Kemudian menghapus pesan setelah pesan berhasil diproses. Jika proses di latar belakang gagal saat memproses pesan, pesan tersebut akan muncul kembali di antrean setelah batas waktu mengintip berakhir. Ini akan diproses oleh instans lain dari tugas atau selama siklus pemrosesan berikutnya dari instans ini. Jika pesan secara konsisten menyebabkan kesalahan pada konsumen, itu akan memblokir tugas, antrean, dan akhirnya aplikasi itu sendiri ketika antrean menjadi penuh. Oleh karena itu, sangat penting untuk mendeteksi dan menghapus pesan racun dari antrean. Jika Anda menggunakan Azure Bus Layanan, pesan yang menyebabkan kesalahan dapat dipindahkan secara otomatis atau manual ke antrean surat mati terkait.

    • Antrean dijamin setidaknya sekali mekanisme pengiriman, tetapi mungkin mengirimkan pesan yang sama lebih dari sekali. Selain itu, jika proses di latar belakang gagal setelah memproses pesan tetapi sebelum menghapusnya dari antrean, pesan akan tersedia untuk diproses lagi. Proses di latar belakang harus idempoten, yang berarti bahwa memproses pesan yang sama lebih dari sekali tidak menyebabkan kesalahan atau inkonsistensi dalam data aplikasi. Beberapa operasi secara alami idempoten, seperti mengatur nilai tersimpan ke nilai baru tertentu. Namun, operasi seperti menambahkan nilai ke nilai tersimpan yang ada tanpa memeriksa apakah nilai yang disimpan masih sama seperti saat pesan awalnya dikirim akan menyebabkan inkonsistensi. Antrean Azure Service Bus dapat dikonfigurasi untuk menghapus pesan duplikat secara otomatis. Untuk informasi selengkapnya tentang tantangan dengan pengiriman pesan setidaknya sekali, lihat panduan tentang pemrosesan pesan idempogen.

    • Beberapa sistem olahpesan, seperti Antrean Azure Queue Storage dan Azure Bus Layanan, mendukung properti jumlah de-antrean yang menunjukkan berapa kali pesan dibaca dari antrean. Ini dapat berguna dalam menangani pesan racun dan berulang. Untuk informasi selengkapnya, lihat Primer Olahpesan Asinkron dan Pola Idempotensi.

Pertimbangan penyekalaan dan performa

Proses di latar belakang harus menawarkan performa yang memadai untuk memastikannya tidak memblokir aplikasi, atau menyebabkan inkonsistensi karena operasi yang tertunda saat sistem sedang dimuat. Biasanya, performa ditingkatkan dengan menskalakan instans komputasi yang menghosting proses di latar belakang. Saat Anda merencanakan dan mendesain proses di latar belakang, pertimbangkan poin-poin berikut seputar skalabilitas dan performa:

  • Azure mendukung penyekalaan otomatis (baik peluasan skala dan penyempitan skala kembali) berdasarkan permintaan dan beban saat ini atau pada jadwal yang telah ditentukan, untuk penyebaran yang dihosting Web Apps dan Virtual Machines. Gunakan fitur ini untuk memastikan bahwa aplikasi secara keseluruhan memiliki kemampuan performa yang memadai sekaligus meminimalkan biaya runtime.

  • Jika proses di latar belakang memiliki kemampuan performa yang berbeda dari bagian lain aplikasi (misalnya, antarmuka pengguna atau komponen seperti lapisan akses data), menghosting proses di latar belakang bersama-sama dalam layanan komputasi terpisah memungkinkan antarmuka pengguna dan proses di latar belakang untuk diskalakan secara independen guna mengelola beban. Jika beberapa proses di latar belakang memiliki kemampuan performa yang sangat berbeda satu sama lain, pertimbangkan untuk membaginya dan menskalakan setiap jenis secara independen. Namun, perhatikan bahwa ini dapat meningkatkan biaya runtime.

  • Hanya menskalakan sumber daya komputasi mungkin tidak cukup untuk mencegah hilangnya performa saat dimuat. Anda mungkin juga perlu menskalakan antrean penyimpanan dan sumber daya lainnya untuk mencegah satu titik dari keseluruhan rantai pemrosesan menjadi penyempitan. Juga, pertimbangkan batasan lain, seperti throughput maksimum penyimpanan dan layanan lain yang diandalkan oleh aplikasi dan proses di latar belakang.

  • Proses di latar belakang harus didesain untuk penyekalaan. Misalnya, proses tersebut harus dapat secara dinamis mendeteksi jumlah antrean penyimpanan yang digunakan untuk mendengarkan atau mengirim pesan ke antrean yang sesuai.

  • Secara default, WebJobs menskalakan dengan instans Azure Web Apps terkait. Namun, jika Anda ingin WebJob berjalan hanya sebagai satu instans, Anda dapat membuat file Settings.job yang berisi data JSON { "is_singleton": true }. Ini memaksa Azure untuk hanya menjalankan satu instans WebJob, meskipun ada beberapa instans dari aplikasi web terkait. Ini bisa menjadi teknik yang berguna untuk tugas terjadwal yang harus dijalankan hanya sebagai satu instans.

Langkah berikutnya