Go uygulaması için minimum sunucu spec’leri: net rehber

Go uygulamaları (özellikle HTTP API, worker ve cron yapan servisler) için doğru minimum sunucu spec’lerini seçmek; hem performans hem de maliyet açısından doğrudan belirleyicidir. Bu rehberde, Go uygulamanın tek başına CPU/RAM ihtiyacını değil, pratikte darboğaz oluşturan bileşenleri (TLS, ters proxy, log/metrics, veritabanı erişimi, concurrency) hesaba katarak minimum ve rahat çalışma eşiklerini netleştireceksin. Ayrıca VDS/VPS seçerken “küçük aldım yine yetmedi” senaryolarını önleyen kontrol listesini de bulacaksın.

Önce mimariyi netleştirin: Go tek başına mı, ters proxy ile mi?

Go uygulamanın minimum spec’i; dağıtım şekline göre değişir. Çünkü Go’nun kendisi tek başına küçük olabilir; ama önünde çalışan bileşenler (Nginx/Traefik, WAF/CDN, TLS termination, rate limit) CPU ve RAM tüketir.

En yaygın 3 senaryo

1. Tek servis (Go binary): Uygulama doğrudan portta çalışır, önünde yalnızca basit bir reverse proxy olabilir.
2. Reverse proxy + Go: Nginx/Traefik TLS’yi sonlandırır (termination) ve Go’ya proxy yapar.
3. Go + async worker + veritabanı: HTTP istekleri kadar arka plan kuyrukları (Redis/RabbitMQ) ve DB bağlantıları performansı belirler.

Bu rehberde minimum hesaplar, 2 ve 3. senaryolarda görülen darboğazları hedefler. Çünkü Go’yu “çok hafif” sanıp asıl masrafı yaratan şey çoğu zaman DB bağlantısı, log hacmi ve ters proxy’dır.

Minimum spec nasıl seçilir? Ölçülebilir 6 metrik

Aşağıdaki 6 metriği netlediğinde “minimum” tanımı gerçekçi olur:

• Eş zamanlı istek (concurrency): Aynı anda kaç kullanıcı/işlem var?
• P95 latency hedefi: Yük altında 95. yüzdelik dilimde gecikme.
• CPU-bound vs I/O-bound: İşlemci mi veri/DB bekleme mi? Go çoğu I/O’da verimli olur ama JSON/şablon, şifreleme ve sık log CPU kullanır.
• TLS yükü: TLS termination reverse proxy’deyse CPU’yu proxy çeker.
• Log/metrics hacmi: stdout/JSON log, gönderim ve disk/CPU etkisi yapar.
• Veritabanı modeli: Bağlantı sayısı (connection pool) ve sorgu maliyeti.

Bu metrikler olmadan verilen tek bir “şu kadar RAM yeter” tavsiyesi, gerçek hayatta ya fazla ödeme yaptırır ya da yetmeyip zaman kaybettirir.

Yük senaryolarına göre net minimum öneriler

Aşağıdaki değerler, ters proxy + Go + log/metrics varsayımıyla ve çoğu API/worker uygulamasında görülen tipik dağımla hazırlanmıştır. Veritabanı aynı sunucudaysa disk ve RAM değerleri yükselir; bu rehberde DB için ayrıca not verdim.

Senaryo bazlı minimum VDS/VPS spec tablosu

Disk seçimi: NVMe tercih et. Disk IOPS düşükse log yoğunluğu ve DB/queue persistence gecikme yaratır. Yine de “minimum” seviyede 20–80 GB arası genellikle yeterli olur; asıl belirleyici doluluk değil, log rotasyonu ve snapshot (yedek) stratejisidir.

Minimum spec’i belirlerken Go ayarı neden şart?

Go uygulaması doğru concurrency ayarıyla “küçük sunucuda” çok iyi çalışabilir. En sık gözden kaçanlar:

• HTTP server timeouts: ReadHeaderTimeout, ReadTimeout, WriteTimeout gibi alanlar yoksa yavaş istemciler kaynak tüketir.
• DB connection pool: MaxOpenConns, MaxIdleConns değerleri kontrol edilmezse DB bekler ve uygulama daha fazla thread/iş bekletir.
• Worker concurrency: Queue’dan iş çekerken tek seferde çok job alıp RAM’i şişirmek yaygın hatadır.

Bu yüzden sunucu spec’i “minimum” olsa bile, Go uygulaması içinde doğru sınırları koymak gerekir. Aksi halde 2 GB RAM’lik VDS, 30 GB RAM’lik gibi davranmaz; çöp üretir (OOM) ve servis donar.

CPU ihtiyacını belirleyen gerçek yük: TLS, proxy ve JSON

Go’nun kendisi genelde verimlidir; CPU tüketimini çoğu zaman şunlar yükseltir:

1) TLS termination

TLS’yi Nginx/Traefik sonlandırıyorsa CPU’yu proxy çeker. Minimum spec seçerken şu net kuralları uygula:

• Trafik azsa (A senaryosu) 1 vCPU çoğu zaman yeterlidir.
• TLS kullanımı arttıkça (özellikle yüksek RPS ve kısa istekler) 2 vCPU ve üzeri daha stabil olur.

2) Ters proxy buffer ve gzip

• Büyük response’lar + sık gzip = CPU artışı.
• Çok küçük buffer ayarları = fragment/ek bellek kullanımı.

Net öneri: Proxy tarafında keep-alive ve gzip’i ölçerek etkinleştir. Salt varsayımla “her şeyi aç” yapmak minimum spec’i bozar.

3) Log ve metrik

Uygulama her istekte JSON log basıyorsa ve loglar diske yazılıyorsa disk + CPU beraber büyür.

• Minimum seviyede mutlaka log rotasyonu (ör. günlük rotasyon) ve gereksiz alanların loglanmamasını yap.
• Metrics’i çok sık (her request’te) üretme. 10–30 saniyelik toplama pencereleri genelde yeterlidir.

RAM: Minimumu doğru koyan kontrol listesi

RAM için “şu kadar GB yeter” tek cümle değildir. Şu kontrol listesini uygula; ardından tabloda verdiğim minimumları “garantiye” yaklaştır.

RAM’i hızlı yükselten 5 etken

• DB bağlantı kuyruğu şişmesi (pool limiti yoksa)
• Worker paralelliğinin fazla olması
• Büyük body parse: Çok büyük JSON/form dosyaları
• Aynı anda yoğun GC: Uygulama heap’inde peak artışı
• Log birikmesi: Disk dolumu ya da log taşıma kuyruğu

Net karar kuralı

İlk 7 günde izlediğin peak RSS (container/servis RAM) değeri, minimum planın RAM’inin %70’ini geçiyorsa bir üst seviyeye çık. Örneğin 2 GB RAM plan kullanıyorsan peak 1.5 GB’ı geçiyorsa vCPU ve RAM’i birlikte artır; sadece RAM artırmak bazen yeterli olmaz çünkü GC ve concurrency de etkilenir.

Disk: “GB yetmez” sorununu nasıl engellersin?

Minimum disk, çoğu zaman GB değil dosya/IO düzenidir.

• Loglar için rotasyon yap: Aksi halde 20–40 GB disk birkaç hafta içinde dolup servis keser.
• Yedekleri aynı diske yazma: Yedek (backup) dosyaları için ayrı dizin veya ayrı storage kullan.
• Container kullanıyorsan imaj katmanları büyüyebilir; prune planı yap.

Net eşik önerisi: Minimum disk seçerken 1) log rotasyonunu koy, 2) günlük log hacmini ölç, 3) 30 günlük projeksiyonu al. Sonra 30 günlük ihtiyaç + %30 tamponu koy.

Veritabanı aynı sunucuda mı? Spec’i iki kat düşün

Eğer Go uygulamanın veritabanı aynı sunucuda çalışıyorsa (özellikle MySQL/PostgreSQL), “minimum spec” yaklaşımı değişir.

DB aynı makinedeyse minimum tablo notu

Net açıklama: DB bağlantıları yükselince Go tarafı bekler; bekleyen istekler goroutine/thread birikimine yol açar. Bu zincir RAM’i ve CPU’yu birlikte büyütür.

Ölçekleme stratejisi: minimumdan sonra nasıl ilerlenir?

Minimum spec satın almak, tek seferlik karar değildir. Doğru yaklaşım:

1. Minimum planla başla (tablodan bir üst değil, gerçek yükten sonra)
2. 1 hafta boyunca izleme yap
3. İkinci haftada kaynakları “peak’e göre” ayarla
4. Gerekirse dikey ölçekle (scale up) veya böl (Go’yu ve worker’ı ayır)

İzleme: minimum planı doğrulayan metrikler

• CPU kullanım ortalaması değil, peak ve load average
• RAM peak’i
• Uygulama P95/P99 latency
• DB connection pool kullanım oranı
• Nginx/Traefik upstream response time
• Disk doluluk ve inode sayısı

Kaynak maliyetini netleştiren pratik öneri

En düşük planı seçerken en çok yapılan hata, “CPU var ama RAM yok” veya “RAM var ama disk IOPS düşük” sonucudur. Bu yüzden minimum seçim yaparken şu kombinasyonu hedefle:

• API odaklı: vCPU ve RAM birlikte artır
• Worker odaklı: RAM’i, iş paralelliğine göre ayarla
• DB aynı sunucuda: Disk kapasitesi ve DB cache için RAM’i yükselt

Hızlı karar kontrol listesi (kullan-at)

Aşağıdakilerden 1 madde bile “evet” ise minimumu bir seviye yukarı al:

• TLS termination ters proxy’de ve hedef RPS 30+
• Log her request’te yüksek hacimli üretiliyor
• Büyük payload’lar (ör. >5–10 MB) sık geliyor
• Worker concurrency tek proses içinde 20+
• DB aynı sunucuda ve sorgular dalgalı

Bu kontrolleri geçmezsen, minimum spec “çalışır” ama stabil olmaz. Stabilite, üretimde maliyetin kontrolünü sağlar.

Sonuç: Minimum spec’i tek sayı değil, eşiklerle seç

Go uygulaması için minimum sunucu spec’i; trafik, concurrency, TLS/proxy yükü, log/metrics hacmi ve DB modeliyle birlikte belirlenmelidir. Bu rehberdeki tabloyu başlangıç noktası olarak al; ardından ilk 7 gün izleme yaparak CPU peak, RAM peak ve P95 latency eşiklerine göre bir üst seviyeye geç. Eğer uygulamanın önünde TLS termination ve ters proxy varsa, “Go hafif” varsayımını bırakıp proxy + bağlantı havuzunu temel alarak seçim yap; böylece hem gereksiz maliyet çıkarmazsın hem de servis kesintisi riskini düşürürsün.