Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler
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. 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), ve 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. Peki neden?
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; ama 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 zaten (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. Bulut kaynaklarını, gerçek iş yüküne ve iş değerine göre ayarlamak lazım; gereksiz açık kalan bir VM’i kapatmak buna girer, ama hayatı bir veritabanını küçültüp performansı düşürmek başka bir hikâye, yanı tasarruf gibi görünürken işin içine risk de giriyor.
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.
Ç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şe bu rakamlar rahatlıkla binlerce dolara çıkıyor, hatta bazı senaryolarda onbinlerce doları görüyorsunuz.
AI Is Yükleri Oyunun Kurallarını Değiştiriyor
Eh, Şimdi işin en sıcak yerine gelelim. AI iş yükleri, klasik maliyet iyileştirmeu mantığını biraz dağıtıyor mu? Kısmen evet, kısmen hayır. Dur, açayım.
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. 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). 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 şaşırmıştım). 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 işe 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 dürüyor. 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.
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.
Kısa bir not düşeyim buraya. Daha fazla bilgi için Azure iPaaS’ta 8. Liderlik: Ne Anlama Geliyor? yazımıza bakabilirsiniz.
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.
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ı.
Ve işler burada ilginçleşiyor. 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. 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)
İş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. Sız ne dersiniz? Ama burada küçük bir ama var: 1 yıllık ya da 3 yıllık taahhüt veriyorsunuz, yanı iş yükü yön değiştirirse bu karar ayağınıza dolanabiliyor.
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
Bu ikisi sık sık birbirine karışıyor. Lafı gevelemeden söyleyeyim:
- Maliyet yönetimi (Cost Management): Harcamayı izlemek, raporlamak, bütçe koymak, alert tanımlamak. Yanı 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, mimarı kararları gözden geçirmek. Yanı “Aynı işi yaparken nasıl daha az öderiz?” sorusuna kafa yormak.
Maliyet yönetimi olmadan iyileştirme yapamazsınız. Bu kısmı atlayan çok kişi oluyor, sonra da garip bir şekilde tasarruf bekliyor. Ama sadece maliyet yönetimi yapıp iyileştirme tarafına hiç girmemek de ayrı dert; o zaman ekranlara bakıp iç çekmekten öteye geçemiyorsunuz.
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 ama kimse “peki şimdi neyi kapatıyoruz?” demiyor. Dashboard’a bakmak para kazandırmıyor. Aksiyon kazandırıyor.
Evet.
Değer Ölçümü: Sadece Maliyete Bakmak Yetmiyor
Bakın şimdi, en çok atlanan yer burası. Maliyet iyileştirmeu sadece “az harca” demek değil, işin aslı biraz daha farklı; “harcadığın paranın karşılığını al” demek, yanı aynı şey gibi dürüyor ama pratikte baya ayrışıyor.
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 biz detaylı bakınca gördük ki bu öneri motoru ortalama sipariş değerini %22 artırmış; (yanlış duymadınız). 15.000 TL ek harcama karşılığında ayda 180.000 TL ek gelir geliyordu, bu 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 bu konuya da değinmiştik.
Yanı mesele şu: her bulut harcamasının yanına bir “iş değeri” metriği koymanız lazım. 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 ama ölçmeden de ilerleyemiyorsunuz.
FinOps Kültürü: Teknik Değil, Kültürel Bir Dönüşüm
Garip gelecek ama, FinOps — yanı 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 garip ilerliyor, çünkü çoğu şirkette IT bütçesi hâlâ tek bir kalemin altında dürüyor. “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 konuştuk. E 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.
- Tag audit yapın: Kaç kaynağınızda tag eksik, önce önü 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.
- 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ı dürüyor ama iş yükünüz farklıysa ters tepebiliyor.
- 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)
- 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 öldü, şaka değil.
- Bütçe alert’leri kurun: %80 ve %100 eşiklerini mutlaka ekleyin. Basit bir ayar gibi dürüyor ama sonra sizi son gün sürpriz faturadan kurtarı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.
# Son 30 günde CPU kullanımı %5'in altında 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. Sız 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), yanı ortada boş yere açık duran ciddi bir kapasite olabiliyor.
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)
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. Tabi her senaryoya uymaz, hatta bazı yerlerde hiç uymaz; ama keşfetmeye değer, açık konuşayım.
Sıkça Sorulan Sorular
Azure’da maliyet optimize etmeuna nereden başlayayım?
Vallahi, Önce Azure Cost Management + Billing’i aktif kullanmaya başla. Sonra Azure Advisor’daki maliyet önerilerine bir göz at. Hani en hızlı kazanım genelde boşta duran kaynakları kapatmaktan ve dev/test ortamlarına auto-shutdown kurmaktan geliyor (evet, doğru duydunuz). Bir de tag’leme stratejisini mutlaka ilk hafta içinde oturtur, yoksa sonradan çok zor oluyor (ciddiyim)
AI iş yüklerinde maliyeti nasıl tahmin ederim?
Açıkçası klasik iş yüklerine göre çok daha zor. 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 anla ve ortalama sorgu uzunluğunu tahmin etmeye çalış. Tahmin eder mısınız? Yanı ilk 2-3 ay gerçek veriye bakarak bütçeni revize etmek kaçınılmaz oluyor — bence bunu baştan kabullenmek lazım.
Reserved Instances mi alsam, Savings Plans mi?
Eğer iş 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.
FinOps ekibi için minimum kaç kişi lazım?
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 bir düşüneyim… haftada 1 saatlik toplantı bile inanılmaz fark yaratıyor. Mantıklı değil mi? Bence önemli olan kişi sayısı değil — süreklilik ve hesap verebilirlik kültürü oluşturmak asıl mesele.
Bulut maliyet optimizasyonunu ne sıklıkla yapmalıyım?
Sürekli yapman lazım. Ayda bir fatura incelemesi minimum, haftalık Advisor kontrolü ideal. Büyük mimarı değişiklikler veya yeni bir servis 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 çok zorlaşıyor.
Kaynaklar ve İleri Okuma
Azure Cost Management Resmî Dokümantasyonu
Cloud Cost Optimization: Principles That Still Matter – Azure Blog (yanlış duymadınız)
FinOps Framework – FinOps Foundation
İçeriği paylaş:
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.
0 comments