Membangun Task Queue dengan Celery dan Redis: Pemrosesan Background untuk Aplikasi Python

Mengapa Proses Berat Tidak Boleh Memblokir Request HTTP

Pola request-response sinkron menahan satu thread web server sampai pekerjaan selesai. Saat pengguna memicu kirim email, resize gambar, atau generate laporan di dalam handler, seluruh siklus HTTP menunggu operasi tersebut. Proses ini terlihat wajar pada trafik rendah, namun menjadi masalah ketika permintaan bertambah. Latency naik karena setiap request mengantre di belakang pekerjaan berat, throughput turun, dan koneksi database habis terpakai untuk menahan request yang belum selesai. Di sisi client, waktu tunggu melewati batas sehingga muncul timeout meskipun server sebenarnya masih bekerja.

asyncio dan threading sering dianggap solusi, tetapi keduanya tetap berjalan di dalam proses aplikasi web yang sama. Pemisahan ini tidak memberi isolasi ketika proses web kehabisan memori atau berhenti mendadak. Task queue menyelesaikan masalah tersebut dengan memisahkan penerimaan request dari eksekusi pekerjaan berat. Handler web hanya menaruh tugas ke antrean lalu segera mengembalikan respons, sementara proses lain mengerjakan tugas itu secara independen.

Kriteria pemakaian task queue cukup jelas. Ketika operasi memakan waktu lebih dari beberapa ratus milidetik, melibatkan layanan eksternal, atau perlu dijalankan ulang saat gagal, kita layak memindahkannya ke antrean. Menjalankan fungsi di background thread hanya cocok untuk pekerjaan singkat yang tidak menuntut keandalan.

Contoh nyata muncul pada endpoint unggah dokumen. Ketika handler langsung memanggil layanan OCR dan pengiriman notifikasi, satu request bisa menahan koneksi selama beberapa detik. Memindahkan kedua langkah itu ke task queue membuat endpoint hanya menyimpan berkas dan mengembalikan task.id, sehingga pengguna mendapat respons cepat sementara pemrosesan berlanjut di belakang.

Arsitektur Celery: Broker, Worker, dan Result Backend

Celery menyusun eksekusi asinkron dari tiga komponen. broker adalah antrean pesan yang menyimpan task sebelum dikerjakan, worker adalah proses yang mengambil dan menjalankan task, sedangkan result backend menyimpan hasil eksekusi. Alur kerjanya berurutan: aplikasi mengirim task ke broker, worker menarik pesan dari sana, menjalankan fungsi, lalu menulis hasilnya ke result backend.

broker berperan seperti loket perantara yang menampung pesanan sebelum diambil pekerja, sehingga pengirim dan pekerja tidak perlu saling menunggu.

Gambar: Diagram alur pesan yang menunjukkan broker sebagai perantara antara pengirim dan penerima — Sumber: Wikimedia Commons

Redis sering dipakai sebagai broker sekaligus result backend dalam setup paling ringkas. Satu instance Redis menangani dua peran tersebut melalui penyimpanan key-value yang cepat. Karena task berjalan di proses terpisah dari aplikasi web, kita dapat menambah jumlah worker secara horizontal hanya dengan menjalankan proses tambahan. Pola ini membuat kapasitas eksekusi menyesuaikan beban tanpa mengubah kode aplikasi.

Perbedaan penting muncul antara fungsi biasa dan task terdistribusi. Argumen dan nilai balik task harus dapat diserialisasi, umumnya ke JSON. Objek ORM, koneksi database aktif, atau file handle tidak dapat dikirim langsung ke antrean. Praktik yang aman adalah mengirim data primitif seperti id atau dict, lalu memuat ulang objek di dalam worker. Pemahaman ini menentukan cara kita merancang tanda tangan fungsi: sederhana, deterministik, dan tidak bergantung pada state proses web.

Mengonfigurasi Instance Celery yang Terhubung ke Redis

Konfigurasi dimulai dari satu modul celery_app.py yang membuat instance Celery dan menunjuk broker serta backend ke Redis. Kredensial koneksi sebaiknya dibaca dari environment variable, bukan ditulis langsung di source code, agar aman ketika kode dibagikan.

!pip install celery redis

import os
from celery import Celery

REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379/0")

app = Celery(
    "rumahcoding",
    broker=REDIS_URL,
    backend=REDIS_URL,
)

app.conf.update(
    task_serializer="json",
    result_serializer="json",
    accept_content=["json"],
    timezone="Asia/Jakarta",
    enable_utc=True,
    task_track_started=True,
)

Setelan serialisasi menentukan format pesan. Kita memakai json pada task_serializer, result_serializer, dan accept_content agar hanya tipe aman yang diterima. timezone serta enable_utc menjaga konsistensi waktu eksekusi, sementara task_track_started=True membuat status STARTED terlihat di log dan dashboard.

Sebelum menjalankan worker, verifikasi koneksi Redis dengan redis-cli ping yang seharusnya mengembalikan PONG. Menjaga celery_app.py terpisah dari modul task memudahkan import lintas aplikasi tanpa memicu siklus dependensi. Untuk pengembangan lokal, Redis dapat dinyalakan cepat lewat Docker dengan image redis:7-alpine. Simpan juga REDIS_URL di file .env untuk pengembangan dan di secret manager untuk produksi, sehingga nilai yang sama dapat dipakai ulang tanpa menyentuh kode.

Menulis Task Background dan Mengirimkannya dari Aplikasi

Dekorator @app.task mengubah fungsi Python biasa menjadi task terdistribusi. Setiap task terdaftar di worker dan dapat dipanggil dari aplikasi mana pun yang mengimpor celery_app.

!pip install celery redis

from celery_app import app

@app.task
def generate_report(user_id: int, month: str) -> dict:
    rows = fetch_rows(user_id, month)
    total = sum(row["amount"] for row in rows)
    return {"user_id": user_id, "total": total, "count": len(rows)}

@app.task
def send_email(to: str, subject: str, body: str) -> str:
    deliver(to, subject, body)
    return f"email terkirim ke {to}"

# Mengirim task dari aplikasi web
result = generate_report.delay(user_id=42, month="2026-09")
print("task.id:", result.id)
print("status:", result.status)

output = result.get(timeout=30)
print("hasil:", output)

Pemanggilan .delay() mengirim task ke broker dan langsung mengembalikan objek AsyncResult tanpa menunggu eksekusi. Saat butuh kontrol lebih, .apply_async() menyediakan opsi seperti menetapkan countdown, eta, atau queue tujuan. Dari objek AsyncResult, kita dapat membaca task.id, memeriksa status, dan mengambil nilai akhir melalui .get() atau .result. Menetapkan timeout yang tepat pada .get() mencegah aplikasi web menunggu tanpa batas.

Satu prinsip yang tidak boleh dilewatkan adalah idempotent. Kegagalan jaringan dapat memicu pengiriman ulang task, sehingga fungsi harus aman dijalankan berkali-kali dengan argumen sama. Untuk itu, batasi argumen pada tipe yang dapat diserialisasi JSON dan hindari meneruskan objek ORM atau koneksi aktif ke antrean.

Menjalankan Worker dan Memantau Eksekusi Task

worker dijalankan dengan perintah celery -A celery_app worker --loglevel=info. Flag -A menunjuk modul aplikasi, sedangkan --loglevel=info menampilkan log setiap task yang diterima dan diselesaikan. Dari log kita membaca siklus status task: RECEIVED saat pesan masuk, STARTED ketika tracking aktif, lalu SUCCEEDED atau FAILURE di akhir eksekusi.

!pip install flower
celery -A celery_app worker --loglevel=info --concurrency=4
redis-cli llen celery
celery -A celery_app flower --port=5555

Flag --concurrency=4 menjalankan empat slot eksekusi paralel di dalam satu proses worker. Untuk beban lebih besar, kita dapat menjalankan beberapa proses worker sekaligus sehingga kapasitas bertambah tanpa mengubah kode aplikasi. Flower melengkapi pemantauan dengan dashboard di http://localhost:5555, menampilkan daftar task aktif, riwayat, dan tingkat keberhasilan secara visual. Ketika butuh pemeriksaan cepat tanpa membuka dashboard, redis-cli llen celery mengembalikan panjang antrean yang masih menunggu. Angka ini berguna untuk mendeteksi penumpukan lebih awal sebelum latency dirasakan pengguna.

Gambar: Diagram worker pool yang menarik task dari antrean lalu mencatat hasil tugas yang selesai — Sumber: Wikimedia Commons

Di lingkungan produksi, jalankan worker dengan opsi --max-tasks-per-child untuk mendaur ulang proses setelah sejumlah task, sehingga kebocoran memori kecil tidak menumpuk. Saat melakukan deployment, kirim sinyal SIGTERM agar worker menyelesaikan task yang sedang berjalan sebelum berhenti, bukan memutusnya di tengah jalan.

Retry, Timeout, dan Praktik Produksi untuk Task Queue yang Andal

Task yang memanggil layanan eksternal rawan gagal sementara. Celery menyediakan mekanisme retry deklaratif melalui autoretry_for, retry_backoff, max_retries, dan retry_jitter. retry_backoff=True menambah jeda antarpercobaan secara eksponensial, sementara retry_jitter menambahkan variasi acak untuk mencegah semua task mencoba ulang serentak dalam satu gelombang.

from celery import shared_task
from celery.exceptions import SoftTimeLimitExceeded

@shared_task(
    autoretry_for=(ConnectionError, TimeoutError),
    retry_backoff=True,
    retry_jitter=True,
    max_retries=5,
    time_limit=120,
    soft_time_limit=90,
)
def sync_payment(order_id: int) -> str:
    try:
        response = payment_gateway.capture(order_id)
        return f"order {order_id}: {response['status']}"
    except SoftTimeLimitExceeded:
        release_reservation(order_id)
        raise

Kita membedakan kegagalan sementara dan permanen. Error seperti ConnectionError layak dicoba ulang, sedangkan kesalahan validasi sebaiknya langsung gagal dan dicatat. Kombinasi time_limit dan soft_time_limit memastikan task yang menggantung tidak menyumbat antrean: soft_time_limit memberi kesempatan membersihkan sumber daya, lalu time_limit menghentikan proses secara paksa.

Pada skala lebih besar, pisahkan task cepat dan task berat ke antrean berbeda melalui task_routes, lalu arahkan worker ke antrean tertentu dengan flag -Q. Praktik operasional menuntut pemantauan queue length dan latensi task, menjalankan worker sebagai service terpisah, serta menyimpan konfigurasi di environment. Dengan begitu, kegagalan pada satu jenis task tidak mengganggu seluruh pipeline.

Lanjut Membangun Backend Asinkron di Rumah Coding

Task queue membuka jalan menuju arsitektur backend yang lebih andal: request cepat di depan, pekerjaan berat di belakang. Di Rumah Coding, kursus dan bootcamp Python membahas alur ini secara end-to-end, dari menulis task, menskalakan worker, sampai deployment ke lingkungan produksi. Bergabunglah untuk membangun sistem asinkron yang siap menghadapi trafik nyata.