Orkestrasi Background Job Skala Masif Menggunakan Redis dan Supervisor

Pukul 2 pagi. PagerDuty berdering keras membangunkan saya dari tidur lelap. Di dashboard Grafana, grafik HTTP response time melonjak dari 45 milidetik menjadi 8 detik. Penyebabnya klasik namun selalu mematikan: endpoint upload laporan CSV ribuan baris mengeksekusi proses parsing sinkron di dalam thread web server PHP-FPM, melahap seluruh alokasi koneksi database, dan melumpuhkan website utama. Tim sales berteriak karena klien gagal checkout, sementara manajemen panik. Saat itulah kita butuh pemisahan beban instan melalui orkestrasi background job yang solid menggunakan Redis dan Supervisor.

Mari kita bedah langsung ke arena pertarungan arsitektur melalui matriks perbandingan performa di bawah ini:

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Dalam ekosistem backend modern, membiarkan proses berat berjalan di dalam request-response siklus HTTP adalah dosa besar arsitektural. Kita dihadapkan pada dua pilar penting yang tidak bisa saling menggantikan namun harus bekerja sama: Redis bertindak sebagai pengantar pesan dan penyimpanan antrean (message broker) yang super cepat, sementara Supervisor bertindak sebagai pengawas kejam yang memastikan pasukan worker di balik layar tidak pernah mati, bahkan ketika server mengalami out-of-memory.

[!IMPORTANT] Redis bukanlah database transaksional permanen secara default. Jika Redis tidak dikonfigurasi dengan persistensi RDB/AOF yang tepat, antrean job bisa lenyap seketika saat server restart mendadak.

Transisi dari proses sinkron ke asinkron seringkali menemui batu sandungan pada manajemen state. Di sinilah Supervisor mengambil alih kendali sistem operasi Linux untuk memastikan skrip worker PHP, Node.js, atau Go Anda berjalan secara daemonized dan otomatis bangkit kembali ketika mengalami fatal error.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Mari kita lihat bagaimana rasanya berurusan dengan konfigurasi nyata di lingkungan production. Supervisor menggunakan file konfigurasi berbasis INI yang sangat mudah dibaca namun menuntut ketelitian tingkat tinggi pada sintaks.

Berikut adalah file konfigurasi Supervisor yang telah diuji di medan perang untuk mengelola multiple background worker secara paralel:

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

Konfigurasi di atas meluncurkan 8 proses worker sekaligus secara independen. Jika salah satu worker mengalami memory leak dan crash, Supervisor akan langsung membunuhnya dan merestart instance baru dalam hitungan milidetik. Namun, kenyataan di lapangan sering tidak semulus teori. Pernahkah Anda mendapati supervisor gagal membaca perubahan konfigurasi? Perintah sudo supervisorctl reread dan sudo supervisorctl update menjadi mantra sakti yang wajib dihafal di luar kepala.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Ketika kami melakukan stress testing menggunakan k6 dengan menyuntikkan 10.000 job per detik ke dalam Redis, titik jenuh utama bukanlah pada Redis itu sendiri—karena Redis mampu melayani ratusan ribu operasi per detik dengan mudah—melainkan pada seberapa cepat worker yang dikelola Supervisor dapat mengonsumsi payload tersebut tanpa membuat koneksi database MySQL kolaps.

Jika worker langsung melakukan koneksi baru ke database pada setiap job, MySQL akan langsung memuntahkan error Too many connections. Di sinilah strategi koneksi persisten dan pembatasan concurrency mutlak diperlukan.

[!TIP] Selalu gunakan connection pooling atau pastikan ORM/Query Builder Anda mendaur ulang koneksi database di dalam loop worker Redis untuk menghindariexhaustion socket MySQL.

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Dari sisi infrastruktur, kombinasi Redis dan Supervisor adalah pahlawan penghemat anggaran cloud. Sebuah instance EC2 t3.medium dengan RAM 4GB sudah lebih dari cukup untuk menjalankan Nginx, PHP-FPM, Redis, dan 16 proses worker Supervisor yang memproses jutaan job per hari.

Redis hanya memakan beberapa ratus megabita RAM untuk menyimpan struktur data list atau sorted set dari antrean, sementara proses worker yang dikelola Supervisor hanya aktif mengonsumsi CPU saat job masuk (BLPOP), dan tidur nyenyak (sleeping) saat antrean kosong. Tidak ada proses polling yang memboroskan siklus CPU.

5. Kapan Wajib Menggunakan Redis

Anda wajib menggunakan Redis ketika aplikasi Anda membutuhkan kecepatan milidetik untuk memasukkan tugas ke dalam antrean (LPUSH/RPUSH), membutuhkan struktur data yang kompleks seperti sorted set untuk scheduled jobs (delayed queue), atau ketika Anda membangun sistem terdistribusi di mana beberapa server backend perlu mengambil antrean dari satu sumber terpusat yang andal.

6. Kapan Wajib Menggunakan Supervisor

Supervisor adalah harga mati ketika Anda menjalankan background worker di lingkungan VPS berbasis Linux (Ubuntu/Debian/CentOS) dan butuh kepastian 99.99% bahwa skrip worker CLI Anda tidak akan mati begitu saja ketika SSH session ditutup atau terjadi unhandled exception di dalam kode aplikasi. Jangan pernah menggunakan nohup atau screen untuk production server jangka panjang!

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Arsitektur background job menggunakan Redis dan Supervisor bukanlah pilihan yang paling canggih jika dibandingkan dengan Apache Kafka atau RabbitMQ, tetapi untuk 95% kasus skala menengah hingga besar, stack ini adalah kombinasi paling pragmatis, mudah di-debug, hemat biaya, dan terbukti tahan banting di dunia nyata. Gunakan Redis untuk bahan bakar antreannya, dan biarkan Supervisor yang menjadi satpam setianya.