Django ve Celery: Asenkron Görev İşleme ve Mülakat Soruları 2026

Django ile ölçeklenebilir web uygulamaları geliştirirken, e-posta gönderimi, rapor oluşturma veya görsel işleme gibi zaman alan operasyonlar kullanıcı deneyimini doğrudan etkiler. Bu noktada Celery, Django ekosisteminin en güçlü asenkron görev işleme çözümü olarak öne çıkar. 2026 itibarıyla Django 6.0'ın yerleşik görev altyapısı tartışılsa da, Celery kurumsal düzeydeki projelerde hala vazgeçilmez konumunu korumaktadır.

Bu rehberde Django-Celery entegrasyonunun temellerinden üretim ortamı yapılandırmasına, görev yönlendirmeden periyodik zamanlayıcılara kadar tüm kritik konular ele alınmaktadır. Yazının sonunda yer alan mülakat soruları ise teknik görüşmelere hazırlık açısından değerli bir kaynak sunmaktadır.

Django Projesine Celery Entegrasyonu

Celery entegrasyonunun ilk adımı, Django projesinin kök dizininde bir celery.py dosyası oluşturmaktır. Bu dosya Celery uygulamasını başlatır, Django ayarlarını yükler ve tüm uygulamalardaki görevleri otomatik olarak keşfeder.

# myproject/celery.py
import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')

app = Celery('myproject')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

config_from_object metodu namespace='CELERY' parametresiyle çağrıldığında, Django ayar dosyasındaki CELERY_ önekine sahip tüm değişkenler otomatik olarak Celery yapılandırmasına aktarılır. autodiscover_tasks() ise INSTALLED_APPS içindeki her uygulamanın tasks.py dosyasını tarayarak görevleri kayıt altına alır.

Ayar dosyasında broker ve sonuç deposu (result backend) yapılandırması şu şekilde tanımlanır:

# myproject/settings.py
CELERY_BROKER_URL = 'redis://localhost:6379/0'
CELERY_RESULT_BACKEND = 'redis://localhost:6379/1'
CELERY_ACCEPT_CONTENT = ['json']
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_TIMEZONE = 'UTC'

Broker ve result backend için farklı Redis veritabanlarının kullanılması (sırasıyla /0 ve /1) önerilen bir yaklaşımdır. Bu sayede görev mesajları ile sonuç verileri birbirinden izole edilmiş olur. Serileştirme formatı olarak JSON tercih edilmesi güvenlik açısından kritik öneme sahiptir; pickle formatı uzaktan kod çalıştırma (RCE) zafiyetlerine kapı açabileceğinden üretim ortamlarında kesinlikle kullanılmamalıdır.

Görev Tanımlama ve Tetikleme

Celery görevleri @shared_task dekoratörü ile tanımlanır. Bu dekoratör, görevin belirli bir Celery uygulamasına bağımlı olmadan çalışmasını sağlar ve Django uygulamalarının yeniden kullanılabilirliğini artırır.

Aşağıdaki örnekte sipariş onay e-postası gönderen bir görev, hata yönetimi ve yeniden deneme mekanizmasıyla birlikte tanımlanmıştır:

# orders/tasks.py
from celery import shared_task
from django.core.mail import send_mail
from orders.models import Order

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def send_order_confirmation(self, order_id: int) -> str:
    """Send confirmation email for a completed order."""
    try:
        order = Order.objects.select_related('user').get(id=order_id)
        send_mail(
            subject=f'Order #{order.id} Confirmed',
            message=f'Your order totaling {order.total} has been confirmed.',
            from_email='noreply@example.com',
            recipient_list=[order.user.email],
        )
        return f'Email sent for order {order_id}'
    except Order.DoesNotExist:
        return f'Order {order_id} not found'
    except Exception as exc:
        # Retry on transient failures (SMTP timeout, etc.)
        raise self.retry(exc=exc)

Bu görevde dikkat edilmesi gereken birkaç kritik tasarım kararı bulunmaktadır. bind=True parametresi sayesinde görev kendi referansına (self) erişebilir ve self.retry() metodunu çağırabilir. max_retries=3 ve default_retry_delay=60 parametreleri, geçici hatalar karşısında 60 saniye aralıklarla en fazla 3 deneme yapılmasını garanti eder. Görev parametresi olarak order_id (tam sayı) gönderilmesi, ORM nesneleri yerine serileştirilebilir veri kullanılması gerektiğini gösteren önemli bir pratiktir.

Görevin bir Django view içinden tetiklenmesi .delay() metodu ile gerçekleştirilir:

# orders/views.py
from orders.tasks import send_order_confirmation

def complete_order(request, order_id):
    # ... process payment, update order status ...
    send_order_confirmation.delay(order_id)
    return redirect('order_success', order_id=order_id)

.delay() metodu görev mesajını broker kuyruğuna ekler ve hemen döner. Kullanıcı, e-posta gönderiminin tamamlanmasını beklemek zorunda kalmaz. Daha gelişmiş kontrol gerektiren durumlarda .apply_async() metodu kullanılabilir; bu metod countdown, eta, queue ve priority gibi ek parametreler kabul eder.

Görev Yönlendirme ve Kuyruk Yönetimi

Üretim ortamlarında tüm görevlerin tek bir kuyrukta işlenmesi performans darboğazlarına yol açar. Farklı görev tiplerinin ayrı kuyruklara yönlendirilmesi, kaynak tahsisinin optimize edilmesini sağlar.

# myproject/settings.py
CELERY_TASK_ROUTES = {
    'orders.tasks.send_order_confirmation': {'queue': 'notifications'},
    'reports.tasks.generate_monthly_report': {'queue': 'reports'},
    'images.tasks.resize_upload': {'queue': 'media'},
}

Her kuyruk için ayrı worker süreçleri başlatılarak eşzamanlılık seviyesi (concurrency) ve havuz tipi (pool) bağımsız olarak ayarlanabilir:

# Start notification worker (fast tasks, high concurrency)
celery -A myproject worker -Q notifications -c 8 --loglevel=info

# Start report worker (slow tasks, limited concurrency)
celery -A myproject worker -Q reports -c 2 --loglevel=info

# Start media worker (CPU-bound, prefork pool)
celery -A myproject worker -Q media -c 4 -P prefork --loglevel=info

Bildirim görevleri genellikle I/O bağımlı ve hızlı olduğundan yüksek eşzamanlılık (-c 8) uygundur. Rapor görevleri uzun sürebileceğinden sınırlı eşzamanlılık (-c 2) bellek tüketimini kontrol altında tutar. Görsel işleme gibi CPU yoğun görevler için prefork havuzu tercih edilir; bu havuz her görev için ayrı bir süreç oluşturarak GIL (Global Interpreter Lock) kısıtlamasını aşar.

Celery Beat ile Periyodik Görevler

Celery Beat, cron benzeri bir zamanlayıcı olarak belirli aralıklarla veya belirli zamanlarda görevlerin otomatik tetiklenmesini sağlar. Zamanlama tanımları CELERY_BEAT_SCHEDULE sözlüğünde yapılır:

# myproject/settings.py
from celery.schedules import crontab

CELERY_BEAT_SCHEDULE = {
    'cleanup-expired-sessions': {
        'task': 'accounts.tasks.cleanup_expired_sessions',
        'schedule': crontab(hour=3, minute=0),  # Daily at 3 AM UTC
    },
    'sync-inventory': {
        'task': 'inventory.tasks.sync_external_inventory',
        'schedule': 300.0,  # Every 5 minutes
    },
    'generate-weekly-digest': {
        'task': 'notifications.tasks.send_weekly_digest',
        'schedule': crontab(hour=9, minute=0, day_of_week='monday'),
    },
}

Beat sürecinin başlatılması ayrı bir komutla gerçekleştirilir:

celery -A myproject beat --loglevel=info

Üretim ortamlarında Beat sürecinin yalnızca tek bir instance olarak çalıştırılması zorunludur. Birden fazla Beat süreci aynı anda aktif olursa periyodik görevler mükerrer olarak tetiklenir. Yüksek erişilebilirlik gerektiren senaryolarda django-celery-beat paketi veritabanı tabanlı zamanlama sunarak dinamik görev yönetimini mümkün kılar.

Flower ile İzleme ve Gözlemleme

Flower, Celery kümelerini gerçek zamanlı olarak izlemek için kullanılan web tabanlı bir araçtır. Worker durumları, kuyruk derinlikleri, görev başarı/başarısızlık oranları ve görev detayları tek bir arayüzden takip edilebilir.

# Install and run Flower
pip install flower
celery -A myproject flower --port=5555

Flower varsayılan olarak http://localhost:5555 adresinde çalışır. Üretim ortamlarında Flower arayüzünün kimlik doğrulama ve ters proxy (reverse proxy) arkasına alınması güvenlik açısından kritiktir. Prometheus ve Grafana gibi araçlarla entegrasyon yapılarak metriklerin uzun vadeli saklanması ve alarm kurallarının tanımlanması da mümkündür.

Django 6.0 Yerleşik Görev Sistemi ve Celery Karşılaştırması

Django 6.0 ile birlikte tanıtılan yerleşik görev altyapısı, basit asenkron operasyonlar için ek bağımlılık gerektirmeyen hafif bir çözüm sunar. Ancak bu sistem Celery'nin sunduğu tüm yeteneklerin yerini almayı hedeflememektedir.

Django 6.0'ın yerleşik sistemi, karmaşık yönlendirme, önceliklendirme veya zincir (chain) ve grup (group) gibi gelişmiş iş akışları gerektirmeyen senaryolar için uygundur. E-posta gönderimi veya basit bildirimler gibi görevler bu sistemle yeterli performansla çalışabilir.

Celery ise görev yönlendirme, çoklu kuyruk yönetimi, yeniden deneme stratejileri, periyodik zamanlama (Beat), sonuç depolama, canvas iş akışları (chain, chord, group) ve üretim düzeyinde izleme gibi gelişmiş özellikler sunmaya devam etmektedir. Kurumsal projelerde, mikro servis mimarilerinde ve yoğun görev işleme gereksinimlerinde Celery tercih edilmesi gereken çözümdür.

Pratik bir yaklaşım olarak her iki sistem bir arada kullanılabilir: basit görevler Django'nun yerleşik sistemiyle, karmaşık iş akışları ise Celery ile yönetilebilir.

Mülakat Soruları: Django ve Celery

Teknik mülakatlardan Django-Celery entegrasyonu hakkında sıkça sorulan sorular ve beklenen yanıtların özeti aşağıda sunulmaktadır.

Soru 1: Celery görevlerine neden ORM nesneleri yerine birincil anahtar (ID) gönderilmelidir?

ORM nesneleri serileştirildiğinde stale data (eski veri) riski oluşur. Görev kuyruğa alındıktan sonra ve worker tarafından işlenene kadar geçen sürede veritabanındaki veri değişmiş olabilir. ID gönderildiğinde görev her zaman güncel veriyi veritabanından çeker. Ayrıca JSON serileştirme ile ORM nesneleri doğrudan gönderilemez; pickle kullanımı ise güvenlik açıklarına davetiye çıkarır.

Soru 2: CELERY_TASK_ALWAYS_EAGER = True ayarı ne işe yarar ve neden üretimde kullanılmamalıdır?

Bu ayar aktif olduğunda görevler broker'a gönderilmeden doğrudan çağıran süreçte senkron olarak çalıştırılır. Test ortamlarında broker bağımlılığını ortadan kaldırmak için kullanışlıdır. Ancak üretimde bu ayar aktif bırakılırsa asenkron işlemenin tüm avantajları kaybedilir; web sunucu süreci görev tamamlanana kadar bloke olur.

Soru 3: acks_late ve reject_on_worker_lost ayarları birlikte nasıl çalışır?

acks_late=True olduğunda görev mesajı worker tarafından alındığında değil, başarıyla tamamlandığında onaylanır (acknowledged). Worker beklenmedik şekilde çökerse mesaj broker'da kalır ve başka bir worker'a teslim edilir. reject_on_worker_lost=True ise worker sürecinin beklenmedik biçimde sonlanması durumunda mesajın reddedilerek kuyruğa geri eklenmesini garanti eder. Bu iki ayar birlikte at-least-once delivery (en az bir kez teslim) garantisi sağlar.

Soru 4: Celery canvas iş akışlarından chain, group ve chord arasındaki fark nedir?

chain görevleri sıralı olarak çalıştırır; her görevin çıktısı bir sonrakine girdi olarak aktarılır. group görevleri paralel olarak çalıştırır ve tüm sonuçları bir liste olarak döndürür. chord ise bir group tamamlandıktan sonra tek bir callback görevini tetikleyen yapıdır. Örneğin, birden fazla API'den paralel veri çekip (group) sonuçları birleştiren (callback) bir iş akışı chord ile ifade edilir.

Soru 5: Celery worker'larında bellek sızıntısı (memory leak) nasıl önlenir?

CELERY_WORKER_MAX_TASKS_PER_CHILD ayarı ile her child sürecinin belirli sayıda görev işledikten sonra yeniden başlatılması sağlanır. Bu mekanizma, uzun süreli çalışan süreçlerde birikebilecek bellek sızıntılarını etkili biçimde önler. Ayrıca CELERY_TASK_TIME_LIMIT ve CELERY_TASK_SOFT_TIME_LIMIT ayarları ile takılı kalan görevlerin zorla sonlandırılması garanti altına alınmalıdır.

Soru 6: Celery Beat ile django-celery-beat arasındaki fark nedir?

Celery Beat zamanlama bilgilerini dosya sisteminde veya yapılandırma dosyasında saklar ve statiktir; değişiklik için kod dağıtımı gerektirir. django-celery-beat ise zamanlama bilgilerini veritabanında tutar ve Django admin paneli üzerinden dinamik olarak yönetilebilir. Çalışma zamanında yeni periyodik görevler eklemek veya mevcut zamanlamaları değiştirmek gerektiğinde django-celery-beat tercih edilmelidir.

Üretim Ortamı Yapılandırma Kontrol Listesi

Celery'nin üretim ortamında güvenilir ve performanslı çalışması için aşağıdaki yapılandırma parametreleri dikkatle ayarlanmalıdır:

# myproject/settings.py — Production configuration
CELERY_TASK_ALWAYS_EAGER = False  # Never True in production
CELERY_TASK_ACKS_LATE = True  # Redelivery on worker crash
CELERY_WORKER_PREFETCH_MULTIPLIER = 1  # Fair scheduling
CELERY_TASK_REJECT_ON_WORKER_LOST = True  # Reject on unexpected exit
CELERY_TASK_TIME_LIMIT = 300  # Hard kill after 5 minutes
CELERY_TASK_SOFT_TIME_LIMIT = 240  # SoftTimeLimitExceeded after 4 min
CELERY_WORKER_MAX_TASKS_PER_CHILD = 1000  # Prevent memory leaks
CELERY_BROKER_CONNECTION_RETRY_ON_STARTUP = True

Her parametre belirli bir üretim gereksinimini karşılar. TASK_ACKS_LATE ve REJECT_ON_WORKER_LOST birlikte görev kaybını önler. PREFETCH_MULTIPLIER = 1 uzun ve kısa görevlerin aynı kuyrukta bulunduğu senaryolarda adil dağıtım sağlar. Zaman limitleri takılı kalan görevlerin sistem kaynaklarını tüketmesini engeller. MAX_TASKS_PER_CHILD bellek sızıntılarına karşı koruma katmanı oluşturur.

Worker süreçlerinin systemd ile yönetilmesi, otomatik yeniden başlatma ve sistem açılışında otomatik başlatma gibi kritik operasyonel gereksinimleri karşılar:

# /etc/systemd/system/celery-worker.service
[Unit]
Description=Celery Worker
After=network.target redis.service

[Service]
Type=forking
User=django
Group=django
WorkingDirectory=/opt/myproject
ExecStart=/opt/myproject/venv/bin/celery -A myproject worker \
    --loglevel=info --concurrency=4 --pidfile=/var/run/celery/worker.pid
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

Restart=always direktifi worker sürecinin herhangi bir nedenle sonlanması durumunda otomatik olarak yeniden başlatılmasını sağlar. After=network.target redis.service satırı ise worker'ın Redis bağlantısı hazır olmadan başlatılmasını önler.

Sonuc

Django ve Celery entegrasyonu, modern web uygulamalarında asenkron görev işlemenin temel taşıdır. Doğru yapılandırılmış kuyruk yönetimi, sağlam yeniden deneme stratejileri ve kapsamlı izleme mekanizmaları ile ölçeklenebilir ve güvenilir sistemler inşa edilebilir. Django 6.0'ın yerleşik görev sistemi basit senaryolar için yeterli olsa da, kurumsal düzeydeki ihtiyaçlar için Celery rakipsiz konumunu sürdürmektedir.

Teknik mülakatlarda broker mimarisi, idempotent görev tasarımı, hata yönetimi ve üretim yapılandırması gibi konularda derinlemesine bilgi sahibi olunması, adayları diğerlerinden ayıran belirleyici faktördür.