Discord Botu İçin Minimum VDS: RAM, CPU ve Trafik Rehberi

Discord botu çalıştırmak “küçük bir script” gibi görünse de asıl yük; yoğun olaylar (event), komut sayısı, cache kullanımı ve gerekiyorsa veri tabanı trafiğinden çıkar. Bu rehberde Discord botu için minimum VDS ihtiyacını, tipik kullanım senaryolarına göre netleştiriyoruz. Sonunda hangi özelliklerde VDS aldığınızda performans ve maliyet dengesinin nasıl kurulduğunu göreceksiniz.

Discord botu neden VDS gerektirebilir?

Küçük botlar zamanla büyür. Şunlar arttıkça tek makinede çalıştırmak yerine VDS daha mantıklı hale gelir: - Botun aynı anda çok fazla event işlemesi (message create, reaction, guild member güncellemeleri) - Komutların dış servis çağırması (API istekleri, webhooks, çeviri, arama) - Kalıcılık ihtiyacı: kayıt tutma, whitelist/role yönetimi, anti-spam puanları - Yeniden başlatma/kalıcılık: kod güncellemeleri, disk üzerinde log/backup, hata toparlama - En önemlisi: çalışır durumda kalma hedefi (uptime) ve denetlenebilir ortam

VDS seçerken kritik soru şudur: Botun “ortalama” yükü mü önemli, yoksa “tepe (peak)” yük mü? Discord tarafında anlık mesaj patlamaları veya kitlenme anlarında event akışı değişir. Bu yüzden minimum VDS planlarken sadece ortalama RAM/CPU değil, ağ ve disk I/O davranışını da hesaba katmak gerekir.

Botun yükünü hangi faktörler belirler?

• Gateway intents ve event yoğunluğu: Daha fazla intent daha fazla event demektir.
• Komutların karmaşıklığı: Basit “!ping” gibi komutlar ile veri tabanı sorgusu olan komutlar farklıdır.
• Cache kullanımı: Cache (ör. in-memory), RAM’i artırır ama dış çağrıları azaltır.
• Veri tabanı kullanımı: SQLite ile küçük botlar çalışabilir; büyüyen botlarda Postgres/MySQL/Redis gündeme gelir.
• Loglama ve analytics: Çok detaylı log yazımı disk I/O’yu etkiler.

Minimum VDS spesifikasyonu: net öneriler

Aşağıdaki değerler “genel amaçlı üretim botu” (production) için pratik eşiklerdir. Discord botu dili ve runtime (Node.js, Python, Go) farklı olsa da aynı mantık geçerlidir: olay akışı artarsa özellikle RAM ve tek çekirdek (single-core) darboğazı hissedilir.

1) Çok küçük bot (hobi/öğrenme)

• Kullanım: 1-3 sunucu, günde birkaç bin komut, ağır veri tabanı yok
• Önerilen VDS:
• RAM: 1 GB
• vCPU: 1 (tercihen tek çekirdek performansı iyi)
• Disk: 20–30 GB SSD
• Ağ: aylık 100–300 GB bant genişliği genelde yeter
• OS: Ubuntu 22.04/24.04

Bu senaryoda çoğu zaman sorun RAM’den değil, yanlış intent/çok yoğun event akışından çıkar. Hızlı çözüm: gereksiz intentleri kapatmak, rate-limit mantığı kurmak.

2) Orta ölçekli bot (gerçek kullanım)

• Kullanım: 10-50 sunucu, günde 10.000–100.000 komut, bazı komutlarda dış API/DB
• Önerilen VDS:
• RAM: 2 GB
• vCPU: 2 (mümkünse 2 çekirdek yerine 1 hızlı çekirdek de olur, ama genel denge için 2 pratik)
• Disk: 40–60 GB SSD
• Ağ: aylık 300–1000 GB bant genişliği

Bu seviyede cache ve veri tabanı tasarımı önem kazanır. Botunuz bir süre sonra “daha çok komut” değil “daha çok istek” yapar. DB sorguları ve log yazımı arttığında disk ve RAM davranışı hissedilir.

3) Yoğun bot (moderasyon, ticket, otomatize sistem)

• Kullanım: 50+ sunucu, event yoğunluğu yüksek, moderasyon akışları, sayaç/anti-spam
• Önerilen VDS:
• RAM: 4 GB (gerekiyorsa 6–8 GB)
• vCPU: 2–4
• Disk: 80–120 GB SSD/NVMe
• Ağ: aylık 1000+ GB (tahmine göre)

Yoğun kullanımda asıl risk: event fırtınası sırasında işlem gecikmesi. Bu gecikme komutların cevap süresini uzatır ve bot “şu an yavaş” hissi verir. Burada minimum VDS’in ötesinde “ölçekleme planı” kritik olur.

RAM/CPU hesaplaması: pratik yol

Discord botlarında CPU genelde “sürekli %100” çalışmaz; daha çok kısa süreli tepe (peak) görülür. Bu yüzden min değerleri seçerken şu yaklaşım işe yarar:

Node.js/Python botlarda minimum sınır mantığı

• Bot uygulaması ve runtime: 200–500 MB aralığında (basit bot)
• Cache/in-memory yapı: 200 MB – 1 GB
• Log buffer + event kuyruğu: 50–300 MB
• DB client ve bağlantı havuzu: 50–200 MB

Bu yüzden orta ölçekli botlar için 2 GB RAM pratik “güvenli minimum”dur. Daha altı çalışabilir ama bakım maliyeti artar: OOM (Out of Memory) yaşanabilir veya GC (garbage collection) davranışı gecikme yaratabilir.

vCPU seçimi: tek çekirdek mi, çok çekirdek mi?

• Tek çekirdek darboğazı: event işleme ve CPU-bound işlemler artarsa tek çekirdek yetmez.
• Çok çekirdek: bot “tek process” olarak çalışıyorsa bile bazı runtime/işlemler paralelleştirilebilir; yine de en iyi sonuç botun doğru yapılandırılmasıyla gelir.

Pratik kural: - CPU-bound işlem (ağır görsel işleme, büyük dosya parse) varsa 2 vCPU minimuma yaklaşır. - Basit komut ve DB sorgusu ağırlıksa 1 vCPU ile başlanır, ama peak’te yanıt süresi izlenir.

Ağ (bant genişliği) ve gecikme: minimumu belirleyen kısım

Botun bant genişliği tüketimi genellikle “dosya indirme/medya” olmadığı sürece beklenen şekilde olur. Yine de aşağıdakiler ağ tüketimini hızlandırır: - Çok sık mesaj içeriği okuma/işleme - Medya indirme (avatar, attachment) ve yeniden yükleme - Dış API çağrıları için gidiş-dönüş (request/response) sayısının artması

Bant genişliği tahmini için kontrol listesi

Aşağıdaki sorulara cevap verin: - Bot dosya indiriyor mu? (attachment/medya) - Komutlar çok mu sık? (message başına tetiklenen işlemler) - Dış API çağrıları var mı? (ör. çeviri)

Bunlar yoksa orta ölçek bot bile genelde “aşırı bant” tüketmez; daha çok event ve DB yükü öne çıkar.

Disk ve I/O: minimum SSD seçimi

Disk kapasitesi kadar disk hızı da önemlidir: - Loglar büyür: düzenli log rotasyonu (logrotate) - Backup tutacaksanız: disk yerinde kalma riski - Cache olarak dosya sistemi kullanıyorsanız (nadiren) I/O hissedilir

Bu nedenle minimumda bile SSD gerekir. NVMe disk farkı her botta görülmez; ancak yüksek log/backup ve DB yazımı varsa farkın etkisi olur.

Redis/DB kullanıyorsanız minimum değişir

Redis veya bir veri tabanı eklenince botun “minimum VDS” ihtiyacı ayrışır. İki senaryo var:

Senaryo A: Tek VDS üzerinde her şey

• Postgres/MySQL + bot aynı makinede
• Redis aynı makinede

Bu durumda minimum şu şekilde güncellenir: - Basit DB + orta bot: 2 GB yerine çoğu zaman 3–4 GB daha rahat olur.

Senaryo B: DB/Redis ayrı sunucuda

• Bot VDS küçük tutulur
• DB/Redis performansı ayrı yönetilir

Bu senaryo maliyeti artırabilir ama operasyonel istikrarı yükseltir. Ayrıca bot yeniden deploy edilse bile DB etkilenmez.

Ölçekleme planı: minimumu doğru seçmek nasıl garantilenir?

Minimum VDS’in amacı “hemen çalışsın” değil, “ilk izleme + kapasite planı”nı tamamlayacak kadar stabil olsun. Bu yüzden kurulumdan sonra şu metrikleri düzenli izleyin:

İzlenecek metrikler

• Uygulama RAM kullanımı (özellikle peak’te)
• Ortalama ve peak CPU (tek çekirdek spike)
• Event işleme süresi (latency)
• Komut cevap süreleri
• DB query süresi (varsa)
• Disk kullanımı ve inode
• Ağ giriş/çıkış

İdeal başlangıç akışı: - 1–2 hafta minimum VDS ile çalıştırın - Peak günlerde RAM/CPU nasıl davranıyor bakın - Peak değerinden sonra hedef RAM rezervi bırakın

Karşılaştırmalı seçim tablosu: hızlı karar

Aşağıdaki tablo, “minimum VDS” seçimini netleştirir.

Minimum VDS kurulumunda operasyonel gereksinimler

Spesifikasyon tek başına yetmez. Aynı VDS içinde doğru yapı kurmak, “minimumu büyütmeden” stabilite sağlar.

1) Süreç yönetimi (process management)

Botu tek komutla çalıştırmak yerine servis olarak yönetin. Sistem yeniden başlarsa bot ayağa kalkmalı.

Örnek mantık: - systemd ile service oluşturma - logların journald veya dosyaya yazılması

2) Otomatik yeniden başlatma ve hata toparlama

• Uygulama crash olursa otomatik restart
• Rate-limit mekanizması: Discord API limitlerine takılmayı azaltın

3) Yedekleme (backup) stratejisi

Minimum VDS’de yedekleri “anlık” tutmak yerine gerçek ihtiyaca göre kurgulayın: - Bot kodu için Git tabanlı sürümleme - DB varsa periyodik dump (ör. günlük) - Yedekleri ayrı lokasyona gönderme

Sonuç: Hangi minimumla başlayın?

Discord botu için minimum VDS seçimi tek bir sayı değildir; botunuzun event yoğunluğu ve veri kalıcılığı ihtiyacına göre netleşir. Standart bir üretim botu için başlangıç noktası şu şekilde özetlenir: küçük botlarda 1 GB/1 vCPU, orta botlarda 2 GB/2 vCPU, yoğun botlarda 4 GB/2–4 vCPU. İlk 1–2 haftada RAM/CPU peak değerlerini izleyip, kapasite rezervini koruyacak şekilde plan yapın. Eğer Redis/DB eklediğinizde RAM hızla yükseliyorsa minimumu artırın veya DB’yi ayrı sunucuya taşıyın.

Aksiyon önerisi: NetKıyas’ta VDS seçeneklerini incelerken önce bu tabloda sizin senaryonuza uyan RAM/vCPU bandını belirleyin, sonra aynı sağlayıcıda SSD türü, ağ limitleri ve yedek/konfigürasyon kolaylığını doğrulayın. Böylece “fazla satın alma” yerine gerçekten ihtiyacınız olan minimuma kilitlenmiş olursunuz.