1. GİRİŞ

Modern yazılım ve veri sistemlerinde "job scheduling" (görev zamanlama) yalnızca bir zamanlayıcıdan ibaret değildir. Gerçek dünya uygulamaları batch işlerinden gerçek zamanlı stream işleme ve ML eğitimine kadar geniş bir alanı kapsar. Doğru tasarlanmış bir scheduling sistemi; kaynak verimliliğini, işlem gecikmesini, maliyetleri ve sistemin dayanıklılığını doğrudan etkiler. Bulutun esnekliği, container orkestratörlerinin yükselişi ve GPU/TPU gibi özel kaynakların kullanımı, scheduling sistemlerini hem daha kritik hem de daha karmaşık hale getirdi.

Bu konu neden bugün önemli?

• Heterojen kaynaklar (CPU/GPU/FPGAs/TPU, disk, ağ) ve çoklu iş türleri (batch, streaming, real‑time inference) scheduling politikalarının karmaşıklaşmasına yol açıyor.
• Bulut maliyetlerini kontrol etmek için daha etkin packing ve preemption stratejileri gerekiyor.
• ML eğitim işlerinin kaynak talebi ve veri transfer maliyetleri scheduling kararlarını business KPI'larına doğrudan bağladı.

Kimler için önemli?

• SRE, platform ve altyapı mühendisleri
• Veri mühendisleri, ML mühendisleri ve batch pipeline sahipleri
• Çözüm mimarları ve teknik liderler — iş sürekliliği, SLA ve maliyet optimizasyonu için

Hangi problemleri çözüyor?

• İşlerin hangi node’da, ne zaman ve hangi kaynaklarla çalışacağını belirler.
• Kaynak çatışmalarını yönetir, öncelik ve fairness sağlar.
• Backfill, retry, rate limiting, SLA enforcement gibi operasyonel ihtiyaçları karşılar.

2. KAVRAMSAL TEMELLER

Scheduling sistemi tasarlamaya başlamadan önce kullanılan temel kavramlar, bileşenler ve terminolojiyi netleştirmek gerekir.

2.1. Temel Tanımlar

• Job (görev): Zamanlayıcı tarafından yürütülen birim işler; kısa çalışan task ya da uzun süren batch olabilir.
• Task / Work item: Daha küçük birimler; bir job birden çok task içerebilir (map/reduce, parallel shards).
• Queue: İşlerin tutulduğu yapı; sıralama, priority ve visibility timeout mekanizmaları içerir.
• Worker / Executor: Job'ları çalıştıran süreç veya konteyner.
• Scheduler: Kaynaklar ve işler arasında eşleştirme yapan bileşen; politikaları uygular.
• Resource: CPU, memory, GPU, network, disk I/O, IP adresi veya özel lisans anahtarları gibi sınırlı varlıklar.
• Preemption: Daha yüksek öncelikli iş gerektiğinde düşük öncelikli işi durdurma/taşıma mekanizması.
• Fairness: Kaynakların adil dağılımı; quota veya share tabanlı politikalar kullanılır.
• Bin‑packing / Packing: Node üzerindeki kaynakları verimli kullanma problemi; NP‑hard kararlar içerir.

2.2. Scheduling Sınıfları

• Batch Scheduling: Gece işleri, ETL, veri işleme; latency ikinci plandadır.
• Real‑time / Online Scheduling: Low‑latency gereksinimleri olan görevler; örn. inference, stream processing.
• Periodic Scheduling (Cron): Zaman tabanlı görev tetiklemeleri.
• Workflow Scheduling: Adımları bağımlılık grafiğine göre yürüten sistemler (Airflow, Argo, Dagster).
• Resource-aware Scheduling: Heterojen kaynaklar ve affinity/anti‑affinity kurallarıyla çalışan scheduler'lar (Kubernetes, Mesos).

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE ALGORITMALAR

Scheduling sistemlerinin çekirdeği, iş‑kaynak eşleştirme mantığıdır. Burada hem mimari bileşenleri hem de kullanılan algoritma ailelerini inceliyoruz.

3.1. Yüksek Seviyeli Mimariler

• Centralized Scheduler: Tek bir merkezi scheduler karar alır; global optimizasyon ve karar tutarlılığı sağlar. Dezavantaj: single point of failure ve ölçekleme sınırları (ör. Hadoop YARN).
• Distributed Scheduler: Scheduler kararını delegeler veya çoklu bölgesel scheduler'lar kullanır (ör. Kubernetes scheduler + kubelets, Mesos with frameworks). Daha iyi ölçeklenir ama global optimalite zordur.
• Decentralized / Peer‑to‑peer: Her node kendi kararını alır (örn. some P2P batch systems); genelde simple policies ve eventual convergence sağlar.
• Two‑level Scheduling: Cluster resource manager (Mesos) ile framework‑level scheduler'ların kombinasyonu; üst seviye kaynak tahsisi, alt seviye task placement yapılır.

3.2. Scheduling Algoritma Aileleri

• FIFO / Priority queues: En basit; öncelik tabanlı sıralama ile işlenir. İyi planlama yoksa starvation riski vardır.
• Fair queuing / Shares: Kaynakları paylaştırır; adil kullanım için pay (share) belirlenir (Linux CFS, YARN Fair Scheduler).
• Bin‑packing / Best‑fit / First‑fit: Node packing problem'leri; heuristikler ile çözülür. Amaç boşlukları azaltmak ve maliyeti minimize etmektir.
• Gang scheduling: Paralel uygulamaların tüm parçalarının aynı anda çalışmasını garanti eden model (HPC/parallel jobs için).
• Backfilling: Öncelikli işlerin beklediği durumda küçük işleri araya yerleştirme stratejisi (SLURM, PBS gibi HPC scheduler'larında yaygın).
• Constraint‑based / Affinity: Node etiketleri, GPU tipleri, availability zone gibi kurallara göre filtreleme ve yerleştirme.
• Rate limiting & Throttling: External API çağrıları veya downstream servisler için istek hızını sınırlama mekanizmaları.

3.3. Heterojen Kaynaklar ve Özellikleri

GPU/TPU scheduling, disk‑optimized jobs, network‑intensive işlemler ve lisans/endpoint sınırlamaları scheduling kararlarına ek kısıtlar getirir:

• GPU paylaşımı (exclusive vs time‑slice vs MIG)
• NUMA/CPU pinning ve memory binding
• Network bandwidth reservation ve locality (data locality önem arzeder: veri node'a yakın çalıştırmak I/O maliyetlerini düşürür)

3.4. Preemption ve Eviction

Preemption uygulamak karmaşıktır: checkpointing, stateful job'ların taşınması veya yeniden başlatılması gerekir. Preemption politika örnekleri:

• Low-priority batch job'ları durdurup yüksek-priority interactive job'lara yer açma
• Spot/Preemptible instance'larda job'ları zamanlayıp aksiyon alacak şekilde checkpoint uygulama
• Graceful termination ve pre‑stop hooks ile state'i persist etme

3.5. Scheduling Pipeline — Özet Akış

1. Job submit: Kullanıcı veya workflow engine iş bilgisini gönderir (resource requests, constraints, priority).
2. Admission control: Quotas, rate limits ve validation (quota/exceed check) yapılır.
3. Placement: Scheduler matching algoritması çalışır ve node seçilir.
4. Dispatch: Task worker'a gönderilir, worker çalıştırır ve heartbeat ile status raporlar.
5. Completion: Sonuç toplanır, logs/metrics toplanır, retries veya DLQ (dead‑letter queue) mekanizmaları uygulanır.

4. GERÇEK DÜNYA KULLANIMLARI

Farklı sektörlerde job scheduling sistemleri nasıl kullanılıyor; hangi problemlere çözüm getiriyor? Aşağıda örnek uygulamalar ve yaklaşımlar vardır.

Netflix

Güçlü veri‑pipeline’ları (ETL/feature computation), encoding işleri ve A/B test pipeline'ları için custom scheduler'lar ve Kubernetes tabanlı orkestrasyon kullanır. Veri locality, cost per job ve SLA‑based scheduling önemli parametrelerdir.

Uber

Gerçek‑zamanlı stream processing ve batch işlerin kombinasyonu; time‑sensitive jobs için locality ve low‑latency önceliklidir. Ayrıca fleet scheduling (sürü planlama) gibi domain‑specific scheduling problemleri vardır.

Amazon (AWS)

AWS Batch, Step Functions ve managed schedulers ile müşteri iş yüklerine göre hem batch hem workflow orchestrations sunar. Spot instance kullanımı ve job retries ile maliyet optimizasyonu yaygındır.

OpenAI

Model training, distributed data loading ve GPU/TPU resource scheduling kritik. Data parallel ve model parallel job'lar için gang scheduling ve resource reservation stratejileri kullanılır.

Stripe

Fatura, reconciliation ve fraud detection cron/job pipeline'ları için güvenilir scheduling, idempotency ve audit log'lar ön plandadır. Retry/compensation playbook'ları işlem güvenliğini sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Kaynakların etkin kullanımı ve maliyet optimizasyonu
• İşlerin SLA'lara uygun yürütülmesi ve otomatik retry/compensation
• Heterojen iş tiplerini aynı platformda koordine edebilme

Sınırlamalar

• Özellikle heterojen kaynaklarda optimal packing NP‑hard problemidir; heuristikler her zaman yeterli olmayabilir
• Stateful ve uzun süreli işlerin taşınması zordur; checkpointing gerektirir
• Preemption ve spot instance stratejileri ek Complexity ve tiyatro (edge) hataları getirir

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Yaygın job scheduling çözümlerinin avantaj ve dezavantajları aşağıdaki tabloda özetlenmiştir.

7. EN İYİ PRATİKLER

Aşağıda production ortamında job scheduling kullanırken dikkat edilmesi gereken temel prensipler bulunuyor. Kod örneği yoktur; operasyon ve mimari tavsiyelere odaklanılmıştır.

Production Kullanımı

• Kaynak taleplerini doğru beyan edin: CPU/GPU/memory/IO istekleri gerçek tüketimi yansıtmalı.
• Idempotency: Her job idempotent olacak veya idempotency token'ı kullanacak şekilde tasarlansın.
• Backfill ve retry politikalarını SLO'lara göre tanımlayın; DLQ mekanizmalarını kurun.
• Preemption stratejisini kaçınılmazsa checkpointing ile destekleyin.

Performans Optimizasyonu

• Bin‑packing heuristiklerini test edin; packing kalite metriği oluşturun (e.g. bin utilization).
• Gang scheduling gereken işler için resource reservation uygulayın.
• Spot/Preemptible instance kullanımında checkpoint & resume pattern'leri uygulayın.

Güvenlik

• Job metadata ve secrets yönetimi: secret injection, KMS, RBAC politikaları.
• Audit logging: iş başlatma, iptal, yeniden çalışma ve sonuçların audit izleri tutulmalı.

İzleme ve Operasyon

• Per‑job metrikler: duration, retries, failure reason, resource usage toplayın.
• End‑to‑end tracing ile correlation ID'leri workflow ve job düzeyinde taşıyın.
• DR ve chaos testing: worker crash, node eviction, network partition senaryolarını düzenli test edin.

8. SIK YAPILAN HATALAR

• Resource requests/limits beyan etmeden job submit etmek: Scheduler yanlış packing yapar ve OOM/CPU starvation oluşur.
• Idempotency olmadan retries uygulamak: duplicate side‑effect'ler ve veri bozulmaları ortaya çıkar.
• Preemption planı olmadan spot instance stratejisi kullanmak: job kayıpları ve uzun recovery süreleri.
• Observability eksikliği: failure sebeplerini ve hotspot'ları tespit etmek zorlaşır.
• Large state'i workflow state'e koymak: state store büyür ve performance düşer.

9. GELECEK TRENDLER

AI‑Assisted Scheduling

ML tabanlı scheduler'lar iş talep tahmini, hotspot öngörüsü, bin‑packing optimizasyonu ve preemption timing kararlarını otomatikleştirecek. Reinforcement learning yaklaşımları ile uzun vadeli maliyet‑performans hedefleri optimize edilebilecek.

Serverless & Autoscaling Evrimi

Serverless batch ve gömülü GPU havuzları, scheduling soyutlamasını geliştirerek geliştiricilerin infra ile daha az uğraşmasını sağlayacak. Ancak cold start ve maliyet kontrolü sorunları devam edecek.

Edge Scheduling ve Geo‑aware Orchestration

Edge ve 5G ile birlikte job'lar coğrafi olarak daha yakın çalıştırılacak; latency‑aware scheduling ve data residency politikaları önem kazanacak.