Bulut Maliyeti Hesaplama ve Optimizasyonu

Bulut faturası, çoğu ekipte "geçen ay neden bu kadar arttı" sorusuyla gündeme gelir. Sunucu kalemi tanıdıktır ama toplam bunun iki katıdır; kimse tam olarak nereden geldiğini bilmez. Bulut maliyeti hesaplama işini doğru yapmanın sırrı, faturayı tek kalem olarak değil, altı yedi ayrı kalemin toplamı olarak görmek ve her birini ayrı ayrı ölçebilmektir.

Bu rehberde bir bulut faturasının gerçek bileşenlerini tek tek açacağım: hesaplama, depolama, çıkış trafiği, yedekleme, IP adresleri, yönetilen servisler ve genellikle hiç sayılmayan emek maliyeti. Ardından kendi sisteminde bu kalemleri nasıl ölçeceğini, doğru boyutlandırmayı nasıl yapacağını, hangi optimizasyonların gerçekten işe yaradığını ve en sık yapılan hesap hatalarını anlatacağım.

Faturayı Oluşturan Kalemler#

Bir bulut ortamının toplam maliyeti tek bir "sunucu ücreti" değildir. Kalemleri ayırdığında hem karşılaştırma yapabilir hem de optimizasyonu nereye uygulayacağını bilirsin:

Bu dağılım iş yüküne göre çok değişir. Statik dosya ya da medya sunan bir sistemde çıkış trafiği baskın kalem olur; veri işleyen bir sistemde hesaplama; arşiv tutan bir sistemde depolama. Kendi dağılımını bilmeden yapılan optimizasyon, yanlış yere harcanan emektir — önce ölç, sonra müdahale et.

En sık gözden kaçan iki kalem çıkış trafiği ve emek maliyetidir. Çıkış trafiği, sunucudan internete giden veridir; giriş genellikle ücretsizken çıkış ücretlidir ve trafiğin büyümesi doğrusal biçimde faturaya yansır. Emek maliyeti ise faturada hiç görünmez ama bir sistem yöneticisinin ayda 20-30 saatini alan bir altyapı, o saatlerin karşılığı kadar gerçek maliyet üretir.

Mevcut Kullanımı Ölçmek#

Boyutlandırma kararlarının tamamı ölçüme dayanmalıdır. En az bir aylık, saat çözünürlüğünde veri toplamadan hiçbir küçültme ya da büyütme kararı verme. Ölçüm için ek yazılım kurmaya gerek yok; sysstat paketi çoğu ihtiyacı karşılar:

# sysstat kurulumu ve etkinleştirme
apt install sysstat && systemctl enable --now sysstat

# Toplama sıklığını 10 dakikaya indir (varsayılan bazen daha seyrek)
sed -i 's|^\*/[0-9]* |*/10 |' /etc/cron.d/sysstat

# Bugünün CPU dağılımı
sar -u

# Bellek kullanımı
sar -r

# Disk I/O ve cihaz doyumu
sar -d -p

# Ağ arayüzü trafiği (KB/s cinsinden)
sar -n DEV | grep -E 'eth0|ens'

Aylık çıkış trafiğini kabaca hesaplamak için arayüz sayaçlarını da kullanabilirsin:

# Arayüzün açılıştan bu yana gönderdiği toplam bayt
cat /sys/class/net/eth0/statistics/tx_bytes

# İnsan okunur biçimde (GB)
awk '{printf "%.2f GB\n", $1/1024/1024/1024}' /sys/class/net/eth0/statistics/tx_bytes

# vnstat ile günlük/aylık özet (kurulum sonrası veri birikmesi gerekir)
apt install vnstat && vnstat -m

Bu ölçümlerden sonra elinde şu beş sayı olmalıdır: ortalama ve tepe CPU kullanımı, tepe bellek kullanımı, ortalama ve tepe IOPS, aylık toplam çıkış trafiği, tepe eşzamanlı istek sayısı. Bu beş sayı, hem doğru boyutlandırmanın hem de iki sağlayıcıyı adil karşılaştırmanın temelidir.

Doğru Boyutlandırma: En Büyük Tasarruf Kalemi#

Sahada gördüğüm en büyük israf kaynağı, aşırı boyutlandırılmış sunuculardır. "Ne olur ne olmaz" mantığıyla alınan 8 vCPU / 32 GB'lık bir makine, ayda ortalama %8 CPU ve %20 bellek kullanıyorsa, ödediğin paranın büyük bölümü boşa gidiyor demektir.

Doğru boyutlandırma için pratik bir yöntem:

1. Tepe kullanımı temel al, ortalamayı değil. Ortalamaya göre boyutlandırırsan yoğun saatte darboğaz yaşarsın.
2. Tepe kullanımın üstüne %30 pay bırak. Bu pay hem büyümeyi hem de beklenmedik yükü karşılar.
3. CPU ve belleği ayrı değerlendir. Çoğu iş yükü ikisinden yalnızca birinde sınıra dayanır; dengeli paket almak zorunda değilsin.
4. Küçültmeyi kademeli yap. Bir seferde yarıya indirmek yerine bir kademe küçült, iki hafta izle, gerekirse tekrarla.
5. Küçültmeden önce yedek al. Boyut değişikliği çoğu ortamda yeniden başlatma gerektirir.

Basit bir örnek hesap: tepe CPU kullanımın 4 vCPU'lu bir makinede %45 ise, fiilen 1.8 vCPU tüketiyorsun demektir. %30 pay eklediğinde 2.34 vCPU eder; yani 2 vCPU'luk pakete inmek sınırda, 3 vCPU rahat olur. Aynı hesabı bellek için ayrı yapmalısın.

Bellek tarafında dikkat edilecek bir incelik var: free -h çıktısındaki available sütunu gerçek payı gösterir, used değil. Sayfa önbelleği (buff/cache) kullanılmış görünse de gerektiğinde serbest bırakılır:

free -h
#                total        used        free      shared  buff/cache   available
# Mem:            7.8Gi       2.1Gi       0.6Gi       0.2Gi       5.1Gi       5.3Gi

Bu çıktıda used 2.1 GB'tır ama available 5.3 GB'dır; yani makinenin gerçekten ihtiyaç duyduğu bellek 2-3 GB bandındadır. Sanal ortamlarda panelde yazan bellek ile fiilen elinde olan bellek de farklı olabilir; bunun sebebini RAM balloon ve bellek aşırı tahsisi yazısında anlattım.

Çıkış Trafiği ve Depolama Maliyetini Düşürmek#

Çıkış trafiği, büyüyen sistemlerde en hızlı artan kalemdir ve neyse ki en kolay optimize edilenlerden biridir. Sıralı olarak uygulanacak dört önlem şudur:

1. Sıkıştırmayı aç. Metin tabanlı içerikte (HTML, CSS, JS, JSON) sıkıştırma trafiği ciddi biçimde azaltır:

# /etc/nginx/conf.d/sikistirma.conf
gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript
           text/xml application/xml image/svg+xml;
gzip_vary on;

# Brotli modülü kuruluysa daha iyi oran verir
# brotli on;
# brotli_comp_level 5;

2. Önbellek başlıklarını doğru ayarla. Değişmeyen varlıklar için uzun süreli önbellek, aynı dosyanın tekrar tekrar indirilmesini engeller:

location ~* \.(jpg|jpeg|png|webp|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

3. Görselleri optimize et. Modern formatlara geçmek ve gereksiz büyük görselleri küçültmek, medya ağırlıklı sitelerde çıkış trafiğini belirgin biçimde düşürür.

4. Gereksiz iç trafiği azalt. İki bileşen sürekli birbirine büyük veri gönderiyorsa, aynı ortama taşımak hem gecikmeyi hem faturayı düşürür.

Depolama tarafında ise en çok tasarruf, biriken çöpü temizlemekten çıkar. Tipik suçlular loglar, eski yedekler, konteyner imajları ve geçici dosyalardır:

# En çok yer kaplayan dizinleri bul
du -h --max-depth=1 / 2>/dev/null | sort -hr | head -15

# Journald log boyutunu sınırla
journalctl --vacuum-size=500M
# Kalıcı yapmak için: /etc/systemd/journald.conf -> SystemMaxUse=500M

# Eski paket önbelleğini temizle
apt clean

# Kullanılmayan Docker katmanlarını temizle
docker system df
docker system prune -a --volumes

Docker'ın diski nasıl doldurduğunu ve güvenli temizleme yöntemlerini Docker diski doldurdu, nasıl temizlenir yazısında ayrıntılı ele aldım; disk kullanımını doğru okumak için df, du ve ncdu ile disk kullanımı yazısı iyi bir başlangıç.

Zamanlama ve Otomasyonla Tasarruf#

Bulutun asıl maliyet avantajı, kullanmadığın kapasiteyi kapatabilmendir — ama bu otomatik olmaz, sen kurarsın. En yüksek getirili üç uygulama:

Test ve geliştirme ortamlarını gece kapat. Yalnızca iş saatlerinde kullanılan bir ortam, haftada 168 saat yerine 45 saat çalışırsa maliyeti üçte birin altına iner. Basit bir cron yeterlidir:

# /etc/cron.d/ortam-zamanlama
# Hafta içi 08:30'da başlat, 19:30'da durdur
30 8 * * 1-5 root /usr/local/bin/ortam-baslat.sh
30 19 * * 1-5 root /usr/local/bin/ortam-durdur.sh

Toplu işleri yoğun olmayan saatlere kaydır. Raporlama, yedekleme ve veri işleme gibi işler gece çalıştığında, gündüz için daha küçük bir makine yeterli olur.

Kullanılmayan kaynakları düzenli tara. Bağlı olmayan diskler, ayrılmış ama kullanılmayan IP adresleri, unutulmuş anlık görüntüler ve boşta duran yük dengeleyiciler sessizce faturaya eklenir. Ayda bir kez yapılacak bir envanter taraması, çoğu ortamda gözle görülür tasarruf çıkarır.

Uzun vadeli taahhüt indirimleri de önemli bir kalemdir: yükün sabit ve öngörülebilirse, aylık yerine yıllık taahhütle belirgin indirim alabilirsin. Buradaki risk, ihtiyacın değişmesi durumunda esnekliği kaybetmendir; bu yüzden yalnızca kesinlikle kalıcı olan taban kapasite için taahhüt vermek doğru yaklaşımdır.

Toplam Sahip Olma Maliyetini Karşılaştırmak#

İki seçeneği karşılaştırırken yalnızca aylık sunucu bedeline bakmak, en sık yapılan hatadır. Doğru karşılaştırma toplam sahip olma maliyeti üzerinden yapılır ve şu kalemleri içerir:

Bu tabloyu doldurup 24 aylık toplamı çıkardığında karar genellikle netleşir. Pratik bir eşik olarak, kaynağın ayda %60'ın üzerinde dolu çalışıyorsa sabit maliyetli modeller öne geçer; bunun altında ve dalgalı bir profildeysen esneklik kazanır. Bu karşılaştırmanın ayrıntılı halini bulut sunucu mu fiziksel sunucu mu yazısında ele aldım; hangi hizmet katmanını satın aldığının maliyete etkisi için ise IaaS, PaaS ve SaaS farkı yazısına bakabilirsin.

Sık Yapılan Hatalar ve Tuzaklar#

En yaygın hata, maliyeti tek seferlik bir iş sanmak. Ortamlar zamanla büyür, unutulmuş kaynaklar birikir ve altı ay sonra fatura yeniden şişer. Aylık kısa bir gözden geçirme rutini (bir saatlik) yıllık büyük bir optimizasyon projesinden daha etkilidir.

İkinci hata, kullanım verisi olmadan küçültmek. Tahminle yapılan küçültmeler yoğun saatte darboğaz yaratır ve geri alınır; bu döngü hem zaman kaybettirir hem güveni yıpratır. Küçültmeden önce mutlaka en az bir aylık tepe kullanım verisi topla.

Üçüncü tuzak, emek maliyetini sıfır saymak. Ucuz ama sürekli bakım isteyen bir çözüm, bakımını yapan kişinin zamanı hesaba katıldığında pahalı olabilir. Bu hesabı yaparken kendi zamanını da bir maliyet kalemi olarak yaz.

Dördüncü hata, yedeklemeden kısmak. Maliyet optimizasyonu adına yedek saklama süresini kısaltmak ya da yedekleri aynı ortamda tutmak, ilk ciddi olayda tüm tasarrufun katbekat üstünde zarar yazdırır. Yedek, kesilecek kalem değildir; saklama politikasını akıllı kurgulayarak (günlük yedekleri kısa, haftalık ve aylıkları uzun süre tutmak) hem maliyeti düşürebilir hem güvenliği koruyabilirsin. Uygulamalı bir yaklaşım için Borg ile sunucu yedekleme yazısına bakabilirsin.

Beşinci ve en pahalı tuzak, yanlış katmanı optimize etmek. Faturanın %55'i hesaplama kalemiyken depolama optimizasyonuna hafta harcamak, en iyi ihtimalle küçük bir kazanç getirir. Her zaman en büyük kalemden başla.

Sıkça Sorulan Sorular#

Bulut maliyetimi ne sıklıkla gözden geçirmeliyim#

Ayda bir kez kısa bir gözden geçirme yeterlidir ve düzenli yapıldığında en etkili yöntemdir. Bu incelemede üç şeye bak: geçen aya göre değişen kalemler, kullanılmayan kaynaklar (bağlantısız disk, boşta IP, eski anlık görüntü) ve doluluk oranı düşen sunucular. Çeyrek dönemde bir de daha kapsamlı bir boyutlandırma incelemesi yapmak, birikmiş israfı temizler.

Çıkış trafiği ücreti nasıl azaltılır#

En etkili üç yöntem sıkıştırma, önbellekleme ve içerik optimizasyonudur. Metin tabanlı içerikte gzip ya da brotli açmak trafiği önemli ölçüde düşürür; değişmeyen varlıklara uzun süreli önbellek başlığı koymak aynı dosyanın tekrar indirilmesini engeller. Medya ağırlıklı sitelerde görselleri modern formatlara çevirmek ve boyutlarını gerçek görüntüleme ölçüsüne indirmek çok belirgin fark yaratır.

Sunucumu küçültmek risk mi#

Ölçüme dayanıyorsa değil. Riski azaltmanın yolu kademeli ilerlemektir: bir kademe küçült, iki hafta boyunca tepe kullanımı ve yanıt sürelerini izle, sorun yoksa devam et. Küçültmeden önce anlık görüntü ya da yedek almak, sorun çıkarsa hızlı dönüş sağlar. Ayrıca değişikliği yoğun dönem dışında yapmak, olası bir aksaklığın etkisini en aza indirir.

Rezerve kapasite veya yıllık taahhüt almalı mıyım#

Yükün gerçekten kalıcıysa evet, çünkü indirim oranları anlamlıdır. Ancak taahhüt esnekliği azaltır: ihtiyacın değişirse ödediğin kapasiteyi kullanamazsın. Sağlıklı yaklaşım, kapasiteyi ikiye ayırmaktır — hiçbir koşulda azalmayacak taban kapasite için taahhüt ver, dalgalanan kısmı esnek bırak. Bu ayrım hem indirimden yararlanmanı hem esnekliği korumanı sağlar.

Maliyet takibi için ücretsiz araç var mı#

Temel takip için sistem üzerindeki araçlar yeterlidir. sysstat (sar) ile CPU, bellek, disk ve ağ geçmişini tutabilir; vnstat ile aylık trafik özeti alabilir; ncdu ile disk kullanımını hızlıca inceleyebilirsin. Bunlara sağlayıcının fatura dökümünü ekleyip basit bir tabloda birleştirmek, çoğu ekip için pahalı maliyet yönetimi araçlarının yerini tutar.

Hangi kalemden tasarrufa başlamalıyım#

Faturandaki en büyük kalemden. Çoğu ortamda bu hesaplama kalemidir ve oradaki en hızlı kazanç doğru boyutlandırmadır: gerçek kullanımı ölçüp aşırı büyük makineleri kademeli küçültmek genellikle tek adımda ciddi tasarruf sağlar. Statik içerik ya da medya sunan sistemlerde ise en büyük kalem çıkış trafiği olabilir; o durumda sıkıştırma ve önbellekleme ilk sıraya geçer.

Kapanış#

Bulut maliyeti, tek bir sunucu bedeli değil birbirinden bağımsız birkaç kalemin toplamıdır ve her kalemin optimizasyon yöntemi farklıdır. Aklında tutman gereken dört alışkanlık şunlar: kararları en az bir aylık ölçüme dayandır, en büyük kalemden başla, kullanılmayan kaynakları aylık rutinle temizle ve emek maliyetini de hesaba kat. Tasarruf ederken yedeklemeden kısmamak ise pazarlık konusu olmayan tek kuraldır.

Yük profilin dalgalıysa ve esnekliğe ihtiyacın varsa bulut sunucu paketlerimiz kullanmadığın kapasiteyi kapatmanı sağlar; yükün sabit ve yoğunsa VDS ya da dedicated sunucu tarafında birim maliyet belirgin biçimde düşer. Yedekleme politikanı sağlam kurmak için yedekleme hizmetimize, boyutlandırma ve optimizasyonu bizimle yürütmek istersen sunucu yönetimi hizmetimize bakabilirsin.