Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler
Şunu söyleyeyim, Geçen ay, bir finans kuruluşundaki müşterimizle Azure fatura incelemesi yapıyorduk. Adam masaya oturur oturmaz, “Aşkın bey, biz buluta geçince tasarruf edecektik, faturamız on-prem döneminin iki katına çıktı” dedi. Yüzündeki ifadeyi anlatsam… Açık konuşayım, bu cümleyi Türkiye’de — en azından ben öyle düşünüyorum — son iki yılda en az yirmi kere duydum (kendi tecrübem). Aynı hikâye hep dönüyor; önce heyecanla her şey ayağa kalkıyor, sonra fatura gelince ortam bir anda sessizleşiyor. Evet.
İşin aslı şu ki — bulut maliyet iyileştirmeu öyle bir kere yapıp kenara bırakacağınız iş değil. Sürekli göz üstünde tutmanız gerekiyor, yoksa küçük kaçaklar zamanla büyüyor (özellikle de kimsenin bakmadığı gece saatlerinde),. Sonra tablo birden garipleşiyor. AI iş yükleri de devreye girince konu artık “iyi olur” seviyesinden çıkıp baya can alıcı hâle geldi (ciddiyim). Peki neden?
Şimdi gelelim işin can alıcı noktasına.
Hmm, bunu nasıl anlatsamdı…
Bak şimdi, burada en büyük hata şu: insanlar bulutu sadece teknik bir geçiş sanıyor (en azından benim deneyimim böyle). Hani sunucuyu taşıdık mı tamam gibi düşünülüyor. Fiyatlandırma modeli, rezervasyonlar, boşta duran kaynaklar, yanlış boyutlandırılmış VM’ler derken iş uzuyor da uzuyor. Bir yerde durup “biz bunu niye böyle çalıştırıyoruz?” diye sormazsanız, maliyet kendi yolunu buluyor. (yanlış duymadınız). Maalesef.
Az önce söyledim ya, mesele tek seferlik optimize etme değil. Asıl iş düzenli takipte başlıyor; rapor bakacaksınız, uyarı kuracaksınız, kullanım desenlerini izleyeceksiniz. Bazen de cesurca kapatacaksınız (evet, kullanılmayan kaynağı kapatmak çoğu ekip için sandığınızdan daha zor oluyor). Neyse uzatmayalım, AI tarafında bu daha da belirgin çünkü model çağrıları, veri taşımaları. Işlem süresi çok hızlı şişebiliyor. Tam da öyle.
Bulut Maliyet Optimizasyonu Tam Olarak Ne?
Hani bazen biri “maliyet iyileştirmeu” deyince akla direkt kesmek, kısmak, kapatmak geliyor. Değil. Pek öyle değil aslında. Bulutta iş biraz daha kaygan; kaynakları gerçek kullanıma, yani iş yükünün ritmine. Işin parasal değerine göre ayarlıyorsunuz, gereksiz açık kalan bir VM’i kapatmak buna girer ama bir veritabanını sırf ucuz göründü diye küçültüp performansı gömmek bambaşka bir mesele.
Bunu biraz açayım.
Geleneksel IT tarafında sunucuyu bir kez alırsınız, parasını da peşin verirsiniz; kullanın ya da kullanmayın, fatura pek değişmezdi. Bulutta durum farklı. Tüketim bazlı model var. Açtığın kadar öde. Ama bak şimdi, burada küçük bir oyun dönüyor — insanlar “açtığın kadar” kısmını hemen kapıyor da “kapattığında nefes alan bütçe” tarafını çoğu zaman unutuyor, halbuki asıl tasarruf bazen orada çıkıyor.
Çok konuştum, örnekle göstereyim.
2021’de kendi lab ortamımda bunu baya net gördüm. İki haftalık bir POC için açtığım D-serisi VM’leri kapatmayı unuttum; sonra fark ettim ki 600 dolarlık fatura şişmiş. Lab ortamında 600 dolar az para değil. Kurumsal tarafta iş büyüyünce bu rakamlar rahatlıkla binlerce dolara çıkıyor, hatta bazı senaryolarda onbinlerce doları görüyorsunuz; hani küçük bir unutkanlık gibi başlıyor. Ay sonu gelince insanın yüzü biraz düşüyor.
Evet.
AI Is Yükleri Oyunun Kurallarını Değiştiriyor
Eh, şimdi işin sıcak tarafına gelelim. AI iş yükleri, klasik maliyet iyileştirme mantığını biraz dağıtıyor mu? Kısmen evet, kısmen hayır. Dur, açayım.
İşin garibi, Klasik bir web uygulaması düşünün; CPU ve memory kullanımı aşağı yukarı tahmin ediliyor, ölçeklendirme kuralları belli, maliyet profili de fena değil (yanlış duymadınız). Ama bir LLM fine-tuning işi? GPU saatleriyle faturalandırılıyor, training süresi net değil, inference maliyeti de kullanım desenine göre bir anda zıplayabiliyor (özellikle kullanıcılar botu sohbet arkadaşı sanınca) (en azından benim deneyimim böyle) (yanlış duymadınız). Logosoft’ta bir telekom müşterimizde GPT-4o tabanlı müşteri hizmetleri chatbot’u kurarken bunu birebir gördük. İlk ay inference maliyeti beklentimizin üç katına çıktı. Neden? Kullanıcılar tek soruda kalmamış, ortalama 12 mesajlık mini sohbetlere dönüştürmüşlerdi işi.
GPU Maliyetleri ve Türkiye Gerçeği
Azure’da bir A100 GPU instance’ı saatlik 3-4 dolar civarında dönüyor; ben de ilk duyduğumda “hmm” demiştim (bizzat test ettim). TL’ye çevirdiğinizde — şu anki kurla — saatlik 130-140 TL gibi bir rakam çıkıyor. Bir training job’ı 48 saat sürerse, tek deneme için kabaca 6.000-7.000 TL gidiyor. Üç beş deneme yapın, üstüne hyperparameter tuning ekleyin… bakıyorsunuz 30-40 bin TL buhar olmuş. Türkiye’deki şirketler için bu hiç ufak tefek bir kalem değil.
Küçük bir startup için açık konuşayım: bütçe dar ise doğrudan GPU instance peşine düşmek yerine Foundry Fine-Tuning Nisan Güncellemesi: RFT Artık Ucuz yazımda anlattığım managed fine-tuning servislerine bakın derim. RFT (Reinforcement Fine-Tuning) artık daha erişilebilir duruyor. Enterprise tarafta iseniz de GPU Reserved Instance’lar baya iş görüyor. Burada kritik nokta şu: iş yükünüzü iyi analiz etmeden rezervasyona girmek bazen ters de tepebiliyor.
Peki neden?
Evet.
AI Maliyet Yönetiminin Farklılaştığı Noktalar
| Kriter | Klasik İş Yükleri | AI İş Yükleri |
|---|---|---|
| Maliyet Tahmini | Nispeten kolay | Çok zor, değişkenlik yüksek |
| Kaynak Tipi | CPU, Memory, Disk | GPU, TPU, yüksek memory |
| Ölçeklendirme | Yatay/dikey, tahmin edilebilir |
Hâlâ Geçerli Olan Temel Prensipler
AI üstüne katman ekliyor, tamam. Ama bazı prensipler yerinden oynamıyor, işte mesele bu. Bunları tek tek sayacağım; dur bir saniye, önce şunu söyleyeyim: kağıt üstünde basit duran şeyler, pratikte insanı baya yoruyor. Hatta bazen küçük bir etiket eksikliği bile bütçeyi şaşırtıyor, sonra ekip oturup “biz bunu niye baştan düzgün kurmadık” diye birbirine bakıyor.
Kısa bir not düşeyim buraya. Daha fazla bilgi için Azure iPaaS’ta 8. Liderlik: Ne Anlama Geliyor? yazımıza bakabilirsiniz (bizzat test ettim)
1. Görünürlük Her Şeyin Temeli
Nereye para gittiğini bilmiyorsan, optimize etmeye çalışmak biraz kör dövüşü gibi oluyor. Nokta. Azure Cost Management + Billing bu işte fena değil, hatta baya iş görüyor; ama tek başına yeterli mi? Hmm, açık konuşayım, değil. Hele bir de multi-subscription ortamlarda tag’leme düzenin yoksa, araç sana toplam harcamayı gösterir,. “hangi proje ne kadar yakıyor” sorusunda biraz tökezler; yani sayı var, bağlam yok, bu da işin can sıkıcı tarafı.
Bir bankacılık projesinde şöyle yaptık: her kaynak grubuna zorunlu tag policy’si koyduk. Proje kodu, ortam tipi (dev/test/prod), maliyet merkezî ve sorumlu kişi. İlk hafta herkes söylendi — “bu kadar etiket mi girilecek?” Evet (ben de ilk duyduğumda şaşırmıştım). Girilecek. İki ay sonra aynı ekip “tag olmadan nasıl idare ediyormuşuz” demeye başladı. Garip ama gerçek; başta angarya gibi duran şey, sonra düzenin omurgası oluyor.
Hmm, bunu nasıl anlatsamdı…
Ve işler burada ilginçleşiyor. Peki, daha fazla bilgi için MSVC 14.51 RC Çıktı: Derleyici Tarafında Neler Var? yazımıza bakabilirsiniz.
2. Right-Sizing: Doğru Bedeni Bulmak
Bence, kurumsal müşterilerde en sık gördüğüm israf şu: oversized kaynaklar. Adamlar prod için D16s_v5 açıyor — 16 vCPU, 64 GB RAM — ama ortalama CPU kullanımı %8 civarında geziyor. Mantıklı değil mi? Sekiz! Bu resmen 150 metrekarelik eve tek başına taşınmak gibi bir şey, hani içeride yankı bile yapar; kaynak var ama yük yok, sonra maliyet tabii sessizce şişiyor. Copilot CLI’da Auto Model Seçimi: Ne İşe Yarıyor? yazımızda bu konuya da değinmiştik.
İlginç olan şu ki, Azure Advisor burada öneri veriyor, evet. Ama her tavsiyeyi sorgusuz uygulamayın derim; çünkü bazen düzgün görünen öneri, arka planda sessizce sorun çıkarabiliyor. Geçen yıl bir müşteride Advisor “bu VM’i B-serisi’ne düşür” dedi, biz de uyguladık. Sonra ayda bir çalışan batch processing job sırasında performans yere indi; mevsimsel yükleri Advisor her zaman doğru koklayamıyor (ki bu çoğu kişinin gözünden kaçıyor). Bak şimdi, asıl mesele şu: ortalamaya bakıp karar verirseniz rahat edersiniz gibi görünür, ama pik saatleri kaçırınca tablo bir anda değişiyor.
İşte tam da bu noktada devreye giriyor.
3. Rezervasyonlar ve Savings Plans
Eğer iş yükünüz 1 yıldan uzun sürecekse — kurumsal tarafta çoğu zaman öyle oluyor — Reserved Instances veya Azure Savings Plans ciddi tasarruf sağlayabiliyor. Yüzde 30-60 arası indirim görmek mümkün. Neyse, siz ne dersiniz? Ama burada küçük bir ama var: 1 yıllık ya da üç yıllık taahhüt veriyorsunuz; yani iş yükü yön değiştirirse bu karar ayağınıza dolanabiliyor, özellikle de kapasiteyi sabitleyip sonra büyüme planını başka yöne çekerseniz.
Rezervasyon alırken altın kural şu: son 3 ayın kullanım verisine bakın, en düşük noktayı baz alın. Tepeyi değil, tabanı seçin. Geri kalan kısmı pay-as-you-go ile kapatın.
Maliyet Yönetimi vs. Maliyet Optimizasyonu: Fark Var
Yani, Bu ikisi sık sık birbirine giriyor, hani ilk bakışta aynı şey gibi duruyor ya, işte tam orada küçük bir ayrım var. Lafı gevelemeden söyleyeyim:
Peki neden?
- Maliyet yönetimi (Cost Management): Harcamayı izlemek, raporlamak, bütçe koymak, alert tanımlamak. Yani işin özü şu: “Ne kadar gidiyor?” sorusuna net bir cevap vermek.
- Maliyet optimize etmeu (Cost Optimization): Harcamayı aktif biçimde aşağı çekmek. Doğru kaynak boyutunu seçmek, boşta kalan kaynakları temizlemek, mimari kararları yeniden düşünmek; kısacası “Aynı işi yaparken nasıl daha az öderiz?” sorusuna kafa yormak.
Maliyet yönetimi olmadan iyileştirme yapmak zor. Bu kısmı atlayan çok kişi oluyor; sonra da garip bir şekilde tasarruf bekliyorlar. Ama sadece maliyet yönetimi yapıp iyileştirme tarafına hiç girmemek de ayrı dert,. O zaman ekranlara bakıp iç çekmekten başka bir şey kalmıyor.
Açıkçası, Türkiye’de gördüğüm tablo da çoğu zaman bu oluyor. Cost Management dashboard’u açılmış, herkes arada bir bakıyor, raporlar geliyor, her şey düzenli görünüyor. Kimse “peki şimdi neyi kapatıyoruz?” demiyor. Dashboard’a bakmak para kazandırmıyor; aksiyon kazandırıyor (yanlış duymadınız)
Evet.
Değer Ölçümü: Sadece Maliyete Bakmak Yetmiyor
Bakın şimdi, en çok kaçırılan yer tam burası. Maliyet iyileştirmeu sadece “az harca” demek değil; işin aslı biraz daha farklı, yani “harcadığın paranın karşılığını al” demek, kulağa aynı geliyor. Tahmin eder misiniz? Pratikte epey ayrışıyor.
Bence, Bir e-ticaret şirketinde çalışıyorduk, adam AI tabanlı ürün öneri motoru kurdu. Aylık Azure maliyeti 15.000 TL artmıştı (kendi tecrübem). CFO önce gerildi, haklıydı da. Ama sonra detaylara bakınca şunu gördük: bu öneri motoru ortalama sipariş değerini %22 artırmıştı; yanlış duymadınız. 15.000 TL ek harcama karşılığında ayda 180.000 TL ek gelir geliyordu, tabloyu CFO’ya gösterince adam bir anda “daha fazla harcayalım mı?” moduna geçti. Azure DevOps Server Nisan Yaması: Ne Geldi, Ne Yapmalı? yazımızda buna da değinmiştik.
Yani mesele şu: her bulut harcamasının yanına bir “iş değeri” metriği koymanız lazım (ki bu çoğu kişinin gözünden kaçıyor). Bu bazen gelir artışı oluyor, bazen operasyonel verimlilik, bazen de risk azaltma; hani tek bir kalıba sokmaya çalışınca konu dağılıyor gibi oluyor. Ölçmeden de ilerleyemiyorsunuz.
FinOps Kültürü: Teknik Değil, Kültürel Bir Dönüşüm
Bak şimdi, Garip gelecek ama FinOps — yani Financial Operations — son yıllarda sık duyduğumuz kavramlardan biri. Kısaca mühendislik, finans ve iş birimlerinin bulut harcamaları konusunda ortak sorumluluk alması demek; AZ-305 sınavına hazırlanırken bunu epey kurcalamıştım ve açık konuşayım, araçlar fena değil ama asıl değişim kafada başlıyor.
Türkiye’de bu kültürün oturması biraz tuhaf ilerliyor, çünkü çoğu şirkette IT bütçesi hâlâ tek bir kalemin altında duruyor. “Kim ne kadar harcıyor?” sorusu pek sorulmuyor. Mühendis kaynağı açıyor, finans ay sonunda faturayı görüyor, arada kimse birbirine tam bakmıyor; FinOps tam da bu kopukluğu toparlıyor, ama itiraf edeyim — Türkiye’de FinOps’u düzgün uygulayan şirket sayısı bir elin parmaklarını geçmez (ciddiyim). Henüz.
Pratik Adımlar: Yarın Sabah Ne Yapmalısınız?
Tamam, teori kısmını biraz deşmiş olduk. Peki şimdi ne olacak? İşin aslı burada başlıyor; yarın sabah masanıza oturunca elinizde somut bir liste olsun istiyorsanız, aşağıdaki adımlar baya iş görüyor, çünkü lafı gevelemeden doğrudan para sızdıran yerleri gösteriyor.
- Tag audit yapın: Kaç kaynağınızda tag eksik, önce onu görün. Azure Policy ile zorunlu tag kuralı koyun; yoksa herkes kendi kafasına göre dağıtıyor ve sonra maliyet raporuna bakınca insanın canı sıkılıyor, hatta bazen “bu kadar mı?” dedirtiyor.
- Azure Advisor’ı açın: Cost tarafındaki önerilere göz atın. Ama körü körüne uygulamayın, çünkü bazı öneriler ilk bakışta mantıklı duruyor ama iş yükünüz farklıysa ters tepebiliyor; hani kağıt üstünde güzel, sahada ise biraz tuhaf kalabiliyor.
- Idle kaynakları temizleyin: Son 30 günde neredeyse hiç trafik almayan şeyler var mı? Disk snapshot’ları, eski IP adresleri, boş resource group’lar… Bunlar sessiz sessiz para yiyor. (bence en önemlisi) Bir de garip olan şu: çoğu ekip bunları görmüyor bile.
- Dev/Test ortamlarını otomatik kapatın: Auto-shutdown schedule’ı mesai dışına alın. Basit geliyor, biliyorum; ama tek hamlede %40-60 tasarruf gördüğüm oldu, şaka değil. Üstelik kurması da öyle saatler sürmüyor, yani biraz tembel işi gibi duruyor ama baya işe yarıyor.
- Bütçe alert’leri kurun: %80 ve %100 eşiklerini muhtemelen ekleyin. Basit bir ayar gibi duruyor ama sonra sizi son gün sürpriz faturadan kurtarıyor; açık konuşayım, bu küçük detay bazen bütün ayın sinirini alıyor. — ciddi fark yaratıyor
Ha bu arada, Azure CLI ile idle kaynakları hızlıca listelemek isterseniz şu komutu kullanabilirsiniz. İlk bakışta biraz kuru görünüyor, kabul; ama sonuçları görünce “vay be” diyorsunuz genelde, çünkü ekran bir anda beklediğinizden kalabalık çıkabiliyor.
# Son 30 gunde CPU kullanimi %5'in altinda olan VM'leri listele
az monitor metrics list \
--resource-type "Microsoft.Compute/virtualMachines" \
--metric "Percentage CPU" \
--aggregation Average \
--interval PT1H \
--start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
--query "[?average Bu sorgu kötü bir başlangıç değil. Hatta baya işe yarıyor. Siz ne dersiniz? Sonuçlara bakınca muhtemelen şaşıracaksınız; çoğu ortamda VM’lerin %20-30’u bu kategoriye düşüyor (tabi iş yüküne göre değişir),. Ortada boş yere açık duran ciddi bir kapasite olabiliyor. Evet, bazen sayı küçük görünür ama fatura tarafında hiç de küçük durmuyor (ben de ilk duyduğumda şaşırmıştım)
Bunu yaşayan biri olarak söyleyeyim, Eğer AI iş yüklerinde maliyet kontrolü için edge computing alternatiflerine de bakmak istiyorsanız, Azure Local ve Armada: Edge’de Egemen AI Dönemi yazımda bunu detaylı anlattım. Inference işlerini edge’e taşımak bazen beklediğinizden daha fazla fark yaratıyor; her senaryoda değil ama bazı durumlarda resmen nefes aldırıyor (en azından benim deneyimim böyle) (ki bu çoğu kişinin gözünden kaçıyor). Neyse, çok dağıtmadan söyleyeyim: doğru yerde kullanınca maliyet baskısı baya azalabiliyor.
Açık konuşayım, bir de şu taraf var: yerel AI modelleri çalıştırmak artık uçuk bir fikir değil. Foundry Local GA Öldü: Bulut Olmadan Yerel AI yazımda anlattığım gibi, bazı inference senaryolarında buluta hiç çıkmadan yerel makinenizde model koşturabiliyorsunuz. Maliyet? Sıfır sayılır. Tabi her senaryoya uymaz, hatta bazı yerlerde hiç uymaz; ama keşfetmeye değer, çünkü bazen en basit çözüm en az uğraştıran oluyor.
Sıkça Sorulan Sorular
Azure’da maliyet iyileştirmeuna nereden başlayayım?
Burada, azure Cost Management + Billing’i aktif kullanmaya başlamak iyi bir ilk adım. Sonra Azure Advisor’daki maliyet önerilerine bir göz at — hani orada gerçekten işe yarayan şeyler çıkıyor. En hızlı kazanım genelde boşta duran kaynakları kapatmaktan ve dev/test ortamlarına auto-shutdown kurmaktan geliyor. Bir de tag’leme stratejisini ilk hafta içinde oturtmaya çalış; tecrübeme göre bunu erteleyenler sonradan çok pişman oluyor, ciddiyim.
AI iş yüklerinde maliyeti nasıl tahmin ederim?
Açıkçası klasik iş yüklerine kıyasla çok daha zor bu. Training maliyetleri için önce küçük bir veri setiyle pilot çalışma yap, GPU-saat başına maliyeti ölç, sonra oradan extrapolate et. Inference içinse token bazlı fiyatlandırmayı iyi anlamak lazım — ortalama sorgu uzunluğunu tahmin etmeye çalış. Yani ilk 2-3 ay gerçek veriye bakarak bütçeni revize etmek neredeyse kaçınılmaz oluyor; bence bunu baştan kabullenmek çok daha sağlıklı.
Reserved Instances mi alsam, Savings Plans mi?
İş yükün belirli bir VM ailesine bağlıysa ve pek değişmeyecekse Reserved Instances daha yüksek indirim sunuyor. Ama mesela farklı bölgeler ya da farklı VM boyutları arasında geçiş yapman gerekiyorsa Savings Plans çok daha mantıklı. Tecrübeme göre çoğu zaman ikisinin bir kombinasyonu en iyi sonucu veriyor — aslında biri ya da diğeri diye düşünmemek lazım.
FinOps ekibi için minimum kaç kişi lazım?
Şahsen, Küçük-orta ölçekli şirketlerde ayrı bir ekip kurmak şart değil aslında. Bir bulut mühendisi, bir finans temsilcisi. Bir iş birimi temsilcisiyle haftada 1 saatlik toplantı bile inanılmaz fark yaratıyor. Bence önemli olan kişi sayısı değil — asıl mesele süreklilik ve hesap verebilirlik kültürü oluşturmak.
Bulut maliyet optimizasyonunu ne sıklıkla yapmalıyım?
Sürekli yapman lazım, yani bu bir kerelik iş değil (bizzat test ettim). Ayda bir fatura incelemesi minimum, haftalık Advisor kontrolü ideal. Büyük mimari değişiklikler veya yeni bir servis (söylemesi ayıp) adaptasyonu öncesinde de mutlaka maliyet analizi yap. Bir de otomasyon kur: bütçe aşımı alert’leri, idle kaynak raporları, reservation kullanım oranları — bunların hepsi otomatik gelmeli, yoksa takip etmek gerçekten çok zorlaşıyor.
Kaynaklar ve İleri Okuma
Azure Cost Management Resmî Dokümantasyonu
Cloud Cost Optimization: Principles That Still Matter – Azure Blog
FinOps Framework – FinOps Foundation
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments