Go Uygulaması için Minimum Sunucu Spec’leri: 2026 Rehberi

Go ile yazılmış bir API, worker ya da web servisi çalıştırırken kritik konu “başlangıçta fazla para yakmadan” hedef performansı tutturmaktır. Bu rehberde Go uygulamanızın minimum sunucu gereksinimlerini; CPU/RAM/SSD, ağ (band genişliği), dosya sistemi, süreç (process) yönetimi ve log/yedekleme boyutları üzerinden netleştireceksiniz. Ayrıca gerçek kullanım senaryolarına göre başlangıç spec’lerini ve hangi metriğe bakınca yükseltmeniz gerektiğini öğreneceksiniz.

Go uygulaması minimum spec’leri nasıl belirlenir?

Go uygulamasında minimum donanım, tek bir “doğru” değerle değil; uygulamanın türü ve çalışma profiliyle belirlenir. Aşağıdaki üç sorunun cevabı spec’i doğrudan şekillendirir.

1) Uygulama türü: API mi, worker mı?

• HTTP API (REST/GraphQL): Aynı anda istek işleme (concurrency), bağlantı sayısı, TLS/şifreleme ve cevap boyutu öne çıkar.
• Arka plan worker: CPU’dan çok kuyruk (queue), eşzamanlı işçi sayısı (worker pool) ve dış servis gecikmeleri öne çıkar.
• Akış/stream (SSE/WebSocket): Uzun süre açık bağlantılar ve bellek (RAM) davranışı kritik hale gelir.

2) Performans profili: CPU mu RAM mi sınır oluyor?

• Uygulama sık JSON parse/encode, şifreleme, görüntü dönüştürme gibi işlemler yapıyorsa CPU sınır olur.
• Büyük veri setlerini belleğe alıyor (ör. caching/aggregation) ya da çok sayıda bağlantı uzun süre açık kalıyorsa RAM sınır olur.

3) G/Ç (I/O) ihtiyacı: Log, dosya ve veri tabanı

Minimum spec’te disk seçimi önemlidir çünkü log yazma ve gerektiğinde geçici dosya oluşturma (temp) gecikmeyi büyütebilir. Genel kural: uygulama sunucusunda SSD (NVMe tercih) kullanın.

Başlangıç için net CPU/RAM/SSD değerleri (senaryo bazlı)

Aşağıdaki tabloda, tipik Go servisleri için “minimum canlı çalışma” yaklaşımıyla öneriler var. Değerler, aynı zamanda Go'nun yönettiği goroutine sayısı ve süreç modeli (systemd/dokker) gibi faktörlere göre küçük oynamalar gerektirebilir.

Not: Burada “minimum” ifadesi, güvenli başlangıç anlamındadır. Trafik dalgalanmalarında 1-2 kat headroom bırakmak gerçek hayatta daha az sorun yaşatır.

Minimum spec’te ağ (network) nasıl planlanır?

Go API’lerde sorunların büyük kısmı CPU’dan önce network kaynaklı olur: yanlış bant genişliği varsayımı, MTU uyumsuzluğu, bağlantı sayısı (connections) ve yük dengeleyici (load balancer) ayarları.

Bant genişliği (bandwidth) hesabı için pratik formül

Yaklaşık plan yapmak için şu yaklaşımı kullanın: - Aylık trafik (GB) = günlük istek sayısı × ortalama yanıt boyutu × 30 / 1024 - Ortalama yanıt boyutu = JSON cevap (örn. 2-10 KB) + header + gzip/deflate sonrası gerçek boyut

Örnek: Günlük 500.000 istek, gzip sonrası ortalama 4 KB cevap. - Aylık = 500.000 × 4 KB × 30 / 1024 ≈ 58.6 GB Bu senaryoda minimum olarak ayda 100 GB band genişliği olan bir plan genelde “başlangıç güveni” verir.

Bağlantı limitleri: file descriptor (FD) ve keep-alive

Go net/http varsayımları yanında OS seviyesinde limitler devreye girer. - Yük artınca “too many open files” hatası görüyorsanız FD limitleri düşüktür. - Reverse proxy (Nginx/Traefik) ve Go server arasında keep-alive ayarları gecikmeyi ve CPU’yu etkiler.

Minimum kurulumda hedefiniz şudur: - Web sunucu (reverse proxy) için worker_connections kapasitesini ve Go için bağlantı kuyruğunu uygulama davranışına göre artırmak. - CPU yükseltmeden önce concurrency tavanını ve timeout’ları düzenlemek.

Disk ve I/O: Log, temp dosyaları ve kalıcı veri

Uygulama sunucusunda disk “yeterli” görünse bile log ve temp dosyaları büyüdüğünde performans düşer.

Minimum disk önerisi

• Yalnızca uygulama + log: 25-60 GB SSD
• Log rotasyonu iyi ayarlı değilse: ilk günden itibaren büyüme hızı çok yüksektir. 30 gün sonunda disk dolabilir.
• Veri tabanı (DB) uygulama sunucusunda ise: minimum yaklaşım değişir; bu rehberde DB’yi ayrı tutan mimari varsayımı daha uygundur.

Log rotasyonu (rotation) ve retention

Minimum spec belirlerken “günde kaç GB log” bilmek gerekir. - Ortalama log satırı boyutu × günlük istek × 1.2 (header/stack) yaklaşık bir tahmin verir. - 7-14 gün retention ile başlayıp gözlemleyin.

RAM tarafında Go’nun davranışı: Garbage Collection etkisi

Go uygulamalarında RAM ihtiyacını belirleyen ana faktör GC (garbage collection) yüküdür. Çok sayıda kısa ömürlü nesne (ör. her istekte büyük map/slice üretimi) GC frekansını artırır.

Minimum RAM seçerken nelere bakılır?

• Uygulama RAM kullanımı trafikle birlikte düzgün artıyor mu, yoksa ani sıçramalar mı var?
• GC pause süreleri artıyor mu?
• Cache kullanıyorsanız cache boyutu sabit mi, büyüyor mu?

Minimum spec’te güvenlik ve operasyonel gereksinimler

Minimum sunucu, yalnızca “çalıştırma” değil “işletme”yi de kapsamalıdır.

Süreç yönetimi ve restart davranışı

• systemd ile process restart politikasını tanımlayın.
• Sağlıklı kapanma (graceful shutdown) için HTTP server timeout’larını ayarlayın.

Yedekleme (backup) ve disk alanı

Sunucuda yedek alınacaksa kapasite planına ekleyin. - Uygulama konfig ve statik dosyalar: genelde düşüktür. - Log yedekleme: maliyeti diskten çıkarır, ayrı depoda saklamak daha sağlıklıdır.

Minimum hedef: - Uygulama yapılandırmasını ve build çıktısını düzenli yedekleyin. - Veritabanı yedeklerini (varsa) uygulama sunucusundan bağımsız yönetin.

Sonuçları ölç: yükseltme kararı için net eşikler

Minimum spec ile kurduktan sonra hangi metriğe bakarak “yükseltme zamanı” dediğinizi netleştirin.

Yükseltme sinyalleri (CPU/RAM/Disk/Ağ)

• CPU: Sürekli %70+ (ör. 15 dk ortalama) seviyede kalıyorsa 1. sinyal
• RAM: Sürekli fiziksel RAM’in %80+’ine dayanıyorsa 1. sinyal
• Disk: Disk I/O wait artışı veya log nedeniyle disk doluluk oranı %80+ ise 1. sinyal
• Network: Mbps tavanına yaklaşıp response time uzuyorsa 1. sinyal

Hangi sırayla artırmalısınız?

1) Önce uygulama tarafı: concurrency/timeout, goroutine pool, query ve serialization maliyeti 2) Sonra kaynak: CPU (vCPU) veya RAM 3) En son mimari: reverse proxy caching, Redis cache, queue sistemi, yatay ölçek

Go için minimum kurulumda sık yapılan hatalar

• Reverse proxy ile Go server arasında doğru timeout ayarlamamak (özellikle yavaş upstream isteklerinde)
• Logları console’a akıtıp rotasyon yapmamak
• Cache boyutunu limite etmeden “her şeyi belleğe koymak”
• File descriptor (FD) limitlerini göz ardı etmek (özellikle WebSocket/SSE)
• Eş zamanlılık tavanını (concurrency limit) kontrol etmemek

Pratik öneri: Senaryonuza göre net başlangıç seti

Aşağıdaki liste, “minimum kur ve 7 gün izle” yaklaşımıyla hızlı karar içindir.

• Düşük trafik Go API: 2 vCPU / 2 GB RAM / 25 GB SSD / gzip + HTTP keep-alive / 7 gün log retention
• Orta seviye Go API: 4 vCPU / 4-6 GB RAM / 40-60 GB SSD / Redis ile sık sorguları azaltma / 14 gün retention
• Queue worker: 2-4 vCPU / 4 GB RAM / 30-50 GB SSD / worker sayısını kuyruk derinliğiyle sınırlama
• WebSocket/SSE: 4-8 vCPU / 8-16 GB RAM / 60 GB SSD / FD limitlerini yükseltme / reverse proxy buffering ayarlarını doğru yapma

Son olarak: İlk kurulumda minimum spec’e yakın değer seçin, fakat izleme raporlarına göre 1-2 hafta içinde yükseltme planı yapın. NetKıyas’taki VDS/VPS seçiminde CPU/RAM/SSD ve ağ limitlerini bu eşiklerle eşleyin; hedefiniz “sorunsuz çalıştırmak” değil, sorunu gördüğünüz anda hangi kaynağı artıracağınızı baştan bilmektir. İstediğiniz senaryonun trafik ve eşzamanlılık değerlerini belirleyin; buna göre yukarıdaki tabloyu kullanarak minimum spec’i netleştirip kurun.