AI agent, n8n akışı, bot veya zamanlanmış otomasyon production ortamında 7/24 çalışırken “kaç CPU ve ne kadar RAM gerekir?” sorusu tek başına yeterli değildir. Asıl kapasite problemi; aynı anda kaç işin çalışacağı, her işin ne kadar süreceği, harici API bekleme süreleri, kuyrukta kabul edilebilir gecikme ve hata anındaki tekrar davranışıdır. Doğru plan, sunucu paketini tahmin etmek yerine iş yükünü ölçülebilir bir kapasite modeline dönüştürür.

AI agent kapasitesi neden klasik web trafiğinden farklıdır?

Klasik bir web isteği çoğu zaman saniyeler içinde tamamlanır. Agent işi ise model API’si, veritabanı, arama servisi, dosya işleme ve üçüncü taraf sistemler arasında birden fazla adım çalıştırabilir. CPU boş görünürken worker harici yanıt bekliyor olabilir; bellek kullanımı ise uzun bağlam, dosya dönüştürme veya eşzamanlı tarayıcı süreçleri nedeniyle sıçrayabilir. Bu nedenle yalnızca ortalama CPU’ya bakmak, gerçek darboğazı gizler.

Kapasite planının temel birimi “istek” değil “iş” olmalıdır. Her iş için başlangıç ve bitiş zamanı, bekleme süresi, aktif işlem süresi, kullanılan bellek, dış API çağrısı, başarılı/başarısız sonuç ve tekrar sayısı kaydedilmelidir. Böylece aynı sunucuda çalışan kısa webhook işleriyle uzun rapor üretimleri birbirinden ayrılır.

Önce iş sınıflarını ayırın

Tüm otomasyonları aynı kuyruğa ve aynı worker havuzuna koymak kolaydır; fakat yoğun bir görev küçük ve acil işleri bloke edebilir. En az üç sınıf tanımlamak yararlıdır:

• Kısa ve etkileşimli işler: Webhook yanıtı, sınıflandırma veya kısa veri zenginleştirme. Düşük kuyruk gecikmesi beklenir.
• Uzun arka plan işleri: Rapor, doküman işleme, tarama veya çok adımlı agent görevi. Süre uzundur; timeout ve checkpoint tasarımı gerekir.
• Zamanlanmış toplu işler: Gece çalışan senkronizasyon, indeksleme veya veri kontrolü. Pik saatlerden ayrılabilir ve daha düşük öncelik alabilir.

Her sınıfın eşzamanlılık sınırı, timeout’u, tekrar politikası ve kuyruk önceliği ayrı olmalıdır. Tek bir global “10 worker” değeri, farklı maliyet ve risk profillerini aynı kurala zorlar.

Worker sayısını throughput ile hesaplayın

Başlangıç hesabı için belirli bir zaman aralığında gelen iş sayısını ve p95 tamamlanma süresini ölçün. Örneğin saatte 120 iş geliyor ve p95 süre 90 saniyeyse, sürekli akışta teorik eşzamanlılık yaklaşık üç iştir. Ancak bu değer doğrudan üç worker anlamına gelmez. Trafik dalgalanması, tekrarlar, bakım ve harici API yavaşlığı için rezerv gerekir.

Pratikte hedef, worker’ları yüzde 100 dolu çalıştırmak değil; beklenmedik yükte kuyruğun sınırsız büyümesini engelleyecek boşluk bırakmaktır. Başlangıçta ölçülen ihtiyacın üzerine kontrollü rezerv eklenebilir. Rezerv oranı sabit bir sektör kuralı değildir; işlerin kritikliği, geliş sıklığı ve dış bağımlılıkların oynaklığına göre belirlenir.

Bir worker aynı anda bir işi çalıştırıyorsa worker başına maksimum bellek tüketimini de ölçün. Dört worker’ın her biri pikte 1 GB kullanabiliyorsa işletim sistemi, kuyruk/veritabanı bileşenleri ve gözlemleme ajanları için ayrıca pay bırakılmalıdır. Swap’a düzenli düşen bir yapı “çalışıyor” görünse de kuyruk gecikmesini ve timeout riskini artırır.

Kuyruk uzunluğu tek başına alarm değildir

Kuyrukta 100 iş bulunması, işler saniyeler içinde eriyorsa sorun olmayabilir. On işin yarım saat beklemesi ise kritik olabilir. Bu yüzden şu metrikler birlikte izlenmelidir:

• Kuyruktaki hazır ve çalışan iş sayısı
• En eski işin bekleme süresi
• İş sınıfına göre p50, p95 ve p99 tamamlanma süresi
• Dakika başına gelen ve tamamlanan iş sayısı
• Başarı, timeout, retry ve kalıcı hata oranı
• Worker başına CPU, bellek ve açık bağlantı sayısı
• Harici API gecikmesi ve kota/rate-limit yanıtları

Servis seviyesi hedefi de bu ölçümlere bağlanmalıdır. Örneğin “etkileşimli işlerin yüzde 95’i iki dakika içinde başlamalı” gibi bir kuyruk SLO’su, yalnız CPU alarmından daha anlamlıdır. Alarm, en eski iş süresi ile tamamlanma hızını birlikte değerlendirmelidir.

Eşzamanlılığı sınırlamak neden performans kazandırabilir?

Daha fazla worker her zaman daha fazla throughput üretmez. Veritabanı bağlantı havuzu, harici API kotası veya disk I/O doygunluğa ulaştığında yeni worker’lar yalnızca yarışmayı artırır. Sonuç; daha yüksek timeout, daha fazla retry ve daha uzun kuyruk olabilir. Bu nedenle global sınırın yanında bağımlılık bazlı limitler gerekir.

Örneğin bir dış servis aynı anda beş çağrıyı güvenli biçimde kaldırıyorsa toplam worker sayısı yirmi olsa bile o entegrasyon için semaphore ya da rate limiter kullanılmalıdır. Veritabanı tarafında da uygulama worker sayısı ile bağlantı havuzu birlikte planlanmalı; her worker’ın sınırsız bağlantı açmasına izin verilmemelidir.

Retry fırtınasını kapasite hesabına katın

Harici bir API yavaşladığında aynı işlerin anında ve eşzamanlı tekrarlanması normal trafiği katlayabilir. Retry; üst sınır, exponential backoff ve jitter ile tasarlanmalıdır. Kalıcı hatalar belirli denemeden sonra ayrı hata kuyruğuna taşınmalı; insan incelemesi gereken görevler sürekli dönmemelidir.

Idempotency anahtarı, aynı işin ağ hatası nedeniyle iki kez çalıştırılması durumunda çift fatura, çift mesaj veya çift kayıt riskini azaltır. Retry sayısı kapasite panosunda ayrı gösterilmelidir; çünkü tamamlanan iş sayısı yüksek görünürken gerçek yeni iş throughput’u düşüyor olabilir.

Kontrollü ölçekleme ve güvenli küçülme

Otomatik ölçekleme kullanılıyorsa yalnız CPU’ya göre karar vermeyin. Kuyruk bekleme süresi, geliş/tamamlama farkı ve worker doygunluğu daha doğrudan sinyallerdir. Ölçek artışı için üst sınır koymak, hatalı bir workflow’un sınırsız kaynak ve API maliyeti üretmesini engeller. Scale-down sırasında çalışan işlerin yarıda kesilmemesi için graceful shutdown, görünürlük süresi ve iş yeniden teslimi test edilmelidir.

Uzun işler mümkünse küçük, tekrar başlatılabilir adımlara bölünmeli ve checkpoint tutmalıdır. Böylece worker yeniden başlatıldığında süreç en baştan pahalı çağrıları tekrarlamaz. Dağıtım veya bakım öncesinde yeni iş alımı durdurulmalı, mevcut işlerin tamamlanması için süre tanınmalı ve kalan işler güvenli biçimde kuyruğa dönmelidir.

Production kapasite kontrol listesi

• İşleri kısa, uzun ve zamanlanmış sınıflara ayırın.
• Her sınıf için p95 süre, kuyruk SLO’su ve eşzamanlılık limiti belirleyin.
• Worker başına pik bellek ve bağlantı tüketimini yük testiyle ölçün.
• Harici API ve veritabanı için bağımlılık bazlı limit uygulayın.
• Retry’larda backoff, jitter, maksimum deneme ve hata kuyruğu kullanın.
• Idempotency ile çift işlem riskini azaltın.
• Ölçekleme üst sınırı ve güvenli durdurma prosedürü tanımlayın.
• Kapasite testini production verisi içermeyen temsilî iş yüküyle tekrarlayın.

Narweb ile AI agent altyapısını planlayın

AI agent kapasitesi; sunucu kaynağı, kuyruk tasarımı, gözlemleme ve güvenli operasyonun birlikte değerlendirilmesini gerektirir. Narweb AI Agent Hosting kapsamında 7/24 çalışan agent, n8n ve otomasyon iş yükünüzün worker, izleme ve altyapı ihtiyaçlarını netleştirebilirsiniz. Mevcut iş hacminiz, görev süreleriniz ve büyüme beklentiniz için teknik değerlendirme talep edin.