Manajemen Cron Job Terdistribusi dan Queue Workers dengan Redis & Supervisor

1. Intisari Kilat: Fondasi dalam Sekali Lirik

Pernahkah Anda mendapati server produksi megap-megap karena trafik mendadak melonjak, sementara di saat bersamaan, proses cron job dan queue worker berjalan brutal tanpa kendali? Di lapangan, mengandalkan cron bawaan Linux (/etc/crontab) untuk mengeksekusi tugas berat adalah resep bencana. Proses bisa menumpuk, memakan habis RAM, dan membuat koneksi database jebol.

[!IMPORTANT] Kita butuh pemisahan tegas: Web Server (Nginx/Apache + PHP-FPM) hanya melayani HTTP Request. Tugas latar belakang (seperti mengirim email massal, generate PDF, atau sinkronisasi API) wajib dilempar ke Redis sebagai broker pesan, lalu dikelola dayung hidupnya oleh Supervisor agar tetap hidup (daemonized).

Bayangkan Supervisor sebagai satpam pabrik yang tidak kenal lelah. Jika ada pekerja (worker) yang pingsan karena kehabisan memori atau error tak tertangani, satpam langsung membangunkan pekerja pengganti dalam hitungan milidetik. Sementara itu, Redis bertindak sebagai ban berjalan yang mengatur antrean dengan presisi tingkat tinggi.

2. Kompas Keputusan: Kapan Memilih Solusi Ini vs Alternatif Lain

Menentukan senjata tempur di level infrastruktur tidak boleh pakai tebak-tebakan. Mari kita bedah jalur keputusan yang biasa saya gunakan saat merancang arsitektur backend skala menengah hingga besar.

• Jika skala aplikasi masih kecil (< 100 request/menit) dan tugas latar belakang sangat ringan:
  • Pilih cron bawaan sistem Linux dengan eksekusi script PHP/Node langsung. Tidak perlu kompleksitas Redis.
• Jika aplikasi Anda mulai dibanjiri event asynchronous, butuh retry otomatis, dan penanganan ribuan job per menit:
  • Langsung gunakan Redis + Supervisor. Kenapa Redis? Karena berbasis in-memory, operasi baca-tulis antrean sangat instan dibanding menyimpan job ke dalam tabel MySQL.
• Hindari penggunaan Database (MySQL/PostgreSQL) sebagai Queue Driver:
  • Mengapa? Karena tabel database akan mengalami table lock dan bloating akibat operasi INSERT dan DELETE yang masif secara konstan, menghancurkan performa query utama aplikasi.
• Kapan beralih ke RabbitMQ atau Apache Kafka?
  • Jika sistem Anda sudah masuk ranah Microservices lintas bahasa pemrograman yang kompleks dengan kebutuhan message routing tingkat lanjut (fanout, topic exchange). Namun untuk monolitis modern berbasis Laravel, Node.js, atau Go, Redis sudah lebih dari cukup.

3. Contekan Konfigurasi & Parameter Paling Sering Dicari

Langsung ke praktiknya. Berikut adalah file konfigurasi Supervisor yang sudah teruji di medan perang produksi untuk menangani queue worker.

Simpan file ini di /etc/supervisor/conf.d/worker-production.conf:

[program:app-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work redis --queue=high,default --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/html/storage/logs/worker.log
stopwaitsecs=3600

[!TIP] Perhatikan parameter numprocs=4. Ini memerintahkan Supervisor untuk langsung menelurkan 4 proses worker paralel secara otomatis. Jika satu worker mati, Supervisor langsung merestartnya berkat autorestart=true.

Tabel referensi parameter penting Supervisor:

4. Koleksi Mantra One-Liner Siap Salin untuk Keseharian

Sebagai sysadmin, kecepatan eksekusi di terminal adalah segalanya. Berikut kumpulan mantra one-liner yang wajib ada di kepala Anda:

• Reload konfigurasi Supervisor setelah mengubah file .conf:

  sudo supervisorctl reread && sudo supervisorctl update
  

• Restart seluruh worker queue secara anggun tanpa memutus job yang sedang aktif (Graceful Restart):

  sudo supervisorctl restart app-worker:*
  

• Cek status kesehatan seluruh worker:

  sudo supervisorctl status
  

• Memantau antrean Redis secara real-time via CLI:

  redis-cli monitor | grep "LPUSH"
  

• Membersihkan stuck worker atau memory leak mendadak:

  sudo supervisorctl stop app-worker:* && sudo supervisorctl start app-worker:*
  

5. Jalur Bahaya: Dosa Besar yang Wajib Dihindari di Produksi

Pengalaman bertahun-tahun mengajarkan saya bahwa kegagalan sistem sering kali bukan karena teknologinya yang buruk, melainkan kesalahan manusia saat konfigurasi.

[!WARNING] Dosa Besar #1: Menjalankan Supervisor sebagai root! Selalu definisikan user=www-data atau user non-privilege di file konfigurasi Supervisor. Jika script PHP Anda memiliki celah keamanan (RCE) dan dieksploitasi, penyerang langsung menguasai seluruh server root.

[!WARNING] Dosa Besar #2: Mengabaikan Memory Leak pada Worker. Bahasa seperti PHP atau Node.js rentan mengalami memory leak jika ada garbage collection yang tidak sempurna dalam long-running process. Selalu batasi umur proses worker menggunakan parameter --max-jobs=1000 atau --max-time=3600 agar worker membersihkan memorinya secara berkala.

Dengan memahami fondasi Redis, ketegasan Supervisor, serta menghindari jebakan-jebakan di atas, infrastruktur backend Anda kini siap menghadapi terjangan trafik jutaan pengguna tanpa rasa khawatir.