Bulut Maliyetlerini Düşürmek: FinOps ile Optimizasyon

Buluta geçen pek çok işletme, ilk birkaç ayın sonunda aynı soruyla karşılaşır: Fatura neden geçiş öncesinde hesaplanan tutarın üzerinde? Bulut, doğru yönetildiğinde esnek ve verimli bir altyapı sunar; ancak kullandıkça öde modeli, kontrol edilmeyen her kaynağın sessizce faturaya yansıması anlamına gelir. Bu yazıda Azure, AWS ve Google Cloud ortamlarında uyguladığımız maliyet optimizasyonu yaklaşımını FinOps disiplini, doğru boyutlandırma, taahhüt modelleri, etiketleme ve bütçe alarmları başlıkları altında adım adım anlatıyoruz.

Bulut Faturası Neden Beklenenden Yüksek Çıkar?

Bulut faturasındaki sürprizlerin büyük kısmı teknik bir arızadan değil, yönetim eksikliğinden kaynaklanır. Şirket içi veri merkezinde bir sunucu satın alındığında maliyet bir kez ödenir ve sunucu boşta beklese bile ek fatura gelmez. Bulutta ise her sanal makine, disk, IP adresi, yedek ve veri transferi ayrı ayrı ve sürekli ücretlendirilir. Bu fark göz ardı edildiğinde şu durumlar sıkça yaşanır:

• Birebir taşıma (lift and shift): Şirket içindeki sunucular aynı işlemci ve bellek değerleriyle buluta taşınır. Oysa yerinde sunucular çoğu zaman gelecekteki büyüme düşünülerek fazla kapasiteyle alınmıştır; bu fazlalık bulutta her ay yeniden ödenir.
• Unutulan kaynaklar: Test için açılan sanal makineler, silinen sunuculardan geriye kalan diskler, eski anlık görüntüler (snapshot) ve kullanılmayan genel IP adresleri faturada kalmaya devam eder.
• Gözden kaçan veri transferi: Buluta veri yüklemek genellikle ücretsizken, buluttan dışarıya ve bölgeler arasına veri çıkışı ücretlendirilir. Yoğun raporlama, yedek geri dönüşleri veya şubelerle yapılan senkronizasyonlar bu kalemi büyütür.
• Yanlış depolama katmanı: Nadiren erişilen arşiv verisinin, sık erişim için tasarlanmış pahalı depolama katmanında tutulması.
• Sınırsız log ve izleme verisi: Tüm kaynaklardan ayrıntılı log toplanıp uzun süre saklandığında izleme hizmetinin kendisi ciddi bir maliyet kalemine dönüşür.
• Sahipsiz harcama: Kimin hangi kaynağı neden açtığının bilinmemesi. Sahibi olmayan kaynak kapatılamaz, çünkü kimse kapatmanın güvenli olup olmadığını bilmez.

Geçiş öncesinde yapılan maliyet hesaplamaları genellikle yalnızca işlem ve depolama kalemlerini kapsar. Lisanslar, yedekleme, izleme, bağlantı ve destek planları hesaba katılmadığında bütçe sapması kaçınılmaz olur. Geçiş planlamasının bu boyutunu buluta geçiş rehberimizde ayrıntılı olarak ele aldık.

FinOps Nedir? Maliyet Görünürlüğü ve Sorumluluk

FinOps, bulut harcamalarının finans, teknik ekip ve iş birimleri arasında ortak bir sorumluluk olarak yönetilmesini sağlayan bir çalışma disiplinidir. Bir araç ya da tek seferlik proje değil; harcamaların sürekli görünür kılındığı, optimize edildiği ve kararların maliyet bilinciyle alındığı bir döngüdür. FinOps topluluğunun tanımladığı çerçeve bu döngüyü üç aşamada ele alır:

1. Bilgilendirme (Inform): Harcamanın hangi hizmete, projeye, departmana ve ortama ait olduğunu görünür hale getirmek. Bu aşama olmadan yapılan optimizasyon tahmine dayanır.
2. Optimizasyon (Optimize): Atıl kaynakları kapatmak, boyutlandırmayı düzeltmek, uygun taahhüt modellerini seçmek ve mimari iyileştirmeler yapmak.
3. İşletim (Operate): Kuralları, bütçeleri ve sorumlulukları kalıcı hale getirmek; optimizasyonu düzenli bir rutine dönüştürmek.

KOBİ ölçeğinde FinOps için ayrı bir ekip kurmak gerekmez. Önemli olan rolleri netleştirmektir: Finans tarafında bütçeyi takip eden bir kişi, teknik tarafta kaynakları yöneten bir sorumlu ve her iş yükü için bir kaynak sahibi. Aylık kısa bir maliyet toplantısında bu taraflar faturadaki değişimleri birlikte değerlendirir. Teknik ekibe maliyet görünürlüğü verildiğinde, mühendisler çoğu zaman kendi açtıkları kaynakların maliyetini ilk kez görür ve davranış kendiliğinden değişmeye başlar. Ekiplerin fiyatlandırma modellerini, etiketleme kurallarını ve bütçe süreçlerini tanıdığı kısa bir farkındalık eğitimi, bu maliyet bilincinin şirket kültürüne yerleşmesini hızlandırır.

Doğru Boyutlandırma ve Atıl Kaynakların Temizlenmesi

Hızlı kazanımların büyük kısmı bu aşamadan gelir, çünkü herhangi bir uzun vadeli taahhüt ya da mimari değişiklik gerektirmez.

Doğru boyutlandırma (rightsizing)

Her sanal makine ve veritabanı için en az birkaç haftalık işlemci, bellek, disk ve ağ kullanım verisi incelenmelidir. Ortalama kullanımı sürekli düşük kalan ve tepe noktalarında bile kapasiteye yaklaşmayan kaynaklar bir alt boyuta indirilebilir. Azure Advisor, AWS Compute Optimizer ve Google Cloud'un öneri motorları bu analiz için iyi bir başlangıç noktasıdır; ancak önerileri körü körüne uygulamak yerine uygulama sahibinin onayıyla ve mümkünse önce test ortamında denemek gerekir. Ay sonu kapanışı gibi dönemsel yükleri olan sistemlerde inceleme süresini bu dönemleri kapsayacak şekilde uzatın.

Çalışma saatlerine göre planlama

Geliştirme, test ve eğitim ortamlarının gece ve hafta sonu çalışması çoğu zaman gereksizdir. Otomatik başlatma ve durdurma zamanlamaları bu ortamların yalnızca mesai saatlerinde çalışmasını sağlar. Değişken yük altındaki üretim sistemlerinde ise otomatik ölçeklendirme (autoscaling), sabit ve büyük bir kapasite yerine ihtiyaç kadar kaynak kullanılmasına imkân tanır.

Atıl kaynak temizliği için kontrol listesi

• Hiçbir sanal makineye bağlı olmayan diskler
• Saklama süresi dolmuş veya sahibi belli olmayan anlık görüntüler ve eski yedekler
• Kullanılmayan genel IP adresleri, yük dengeleyiciler ve VPN ağ geçitleri
• Uzun süredir erişilmeyen, verisi arşiv katmanına taşınabilecek depolama alanları
• Durdurulmuş ama silinmemiş, disk ücreti oluşturmaya devam eden sanal makineler; Azure'da yalnızca işletim sistemi içinden kapatılıp serbest bırakılmayan makineler işlem ücreti de yansıtmaya devam eder
• Proje bitmiş olmasına rağmen açık kalan test ortamları

Temizliği güvenli yapmak için silmeden önce kaynak sahibine bildirim gönderin, makul bir bekleme süresi tanıyın ve kritik olabilecek verilerin yedeğini alın. Depolama tarafında yaşam döngüsü kuralları tanımlayarak belirli süre erişilmeyen verilerin otomatik olarak daha ekonomik katmanlara taşınmasını sağlayabilirsiniz.

Rezervasyon, Tasarruf Planları ve Spot Kaynaklar

Sürekli çalışan ve öngörülebilir iş yükleri için kullandıkça öde fiyatlandırması en pahalı seçenektir. Sağlayıcıların sunduğu taahhüt modelleri, belirli bir süre boyunca kullanım garantisi karşılığında belirgin indirimler sağlar.

• Rezerve kaynaklar: Azure Reserved VM Instances ve AWS Reserved Instances, belirli bir kaynak tipi ve bölge için bir veya üç yıllık taahhüt karşılığında indirimli fiyat sunar. Sürekli çalışan veritabanı ve uygulama sunucuları için uygundur.
• Tasarruf planları (Savings Plans): Belirli bir kaynak tipine değil, saatlik harcama tutarına taahhüt verilir. Esneklik daha yüksektir; sanal makine boyutu veya ailesi değiştiğinde indirim çoğu durumda devam eder.
• Taahhütlü kullanım indirimleri: Google Cloud benzer mantıkla, belirli bir kaynak miktarı veya harcama için taahhüt karşılığında indirim sağlar.
• Spot kaynaklar: Sağlayıcının boşta kalan kapasitesi çok daha düşük fiyatla sunulur; karşılığında kaynak kısa bir uyarıyla geri alınabilir. Toplu veri işleme, render ve kesintiye dayanıklı test işleri için idealdir; kesintisiz çalışması gereken sistemler için uygun değildir.
• Lisans avantajları: Azure Hybrid Benefit gibi programlar, yazılım güvencesi bulunan mevcut Windows Server ve SQL Server lisanslarının bulutta kullanılmasına imkân tanır. Lisans envanteri bu nedenle maliyet analizinin bir parçası olmalıdır.

Taahhüt kararı için temel kural şudur: Önce doğru boyutlandırın, sonra rezerve edin. Fazla büyük bir sunucuyu üç yıllığına rezerve etmek, israfı üç yıllığına kilitlemek demektir. Taahhütleri başlangıçta sürekli çalışan taban yükün bir bölümüyle sınırlamak ve kullanım oranını her ay izleyerek kademeli olarak artırmak daha güvenli bir yoldur.

Etiketleme, Bütçe Alarmları ve Raporlama

Görünürlük olmadan kalıcı tasarruf olmaz. Bunun temeli tutarlı bir etiketleme (tag) politikasıdır. Her kaynağa en azından şu etiketlerin verilmesini öneriyoruz:

• Ortam: Üretim, test veya geliştirme
• Sahip: Kaynaktan sorumlu kişi veya ekip
• Maliyet merkezi: Harcamanın hangi departman bütçesinden karşılanacağı
• Proje veya uygulama: Kaynağın hangi iş yüküne ait olduğu

Etiketleme gönüllülüğe bırakılmamalıdır. Azure Policy veya AWS etiket politikalarıyla etiketsiz kaynak oluşturulmasını engelleyebilir ya da en azından raporlayabilirsiniz. Kaynakları abonelik, kaynak grubu veya hesap düzeyinde mantıklı biçimde ayırmak da raporlamayı kolaylaştırır.

Bütçe alarmları ikinci katmandır. Azure Cost Management ve AWS Budgets ile abonelik, proje veya departman bazında aylık bütçeler tanımlayıp belirli eşiklere ulaşıldığında ilgili kişilere bildirim gönderebilirsiniz. Gerçekleşen harcamanın yanında ay sonu tahmini üzerinden de alarm kurmak, sorunu fatura kesilmeden önce fark etmenizi sağlar. Anomali tespiti özelliklerini de açık tutun; bir betiğin yanlışlıkla çok sayıda kaynak açması gibi durumlar ancak bu şekilde erken yakalanır.

Son olarak bir raporlama ritmi belirleyin. Azure Cost Management ve AWS Cost Explorer gibi yerleşik araçlar, harcamayı hizmet, etiket ve zaman bazında kırarak bu rapor için gereken veriyi ek bir yatırım yapmadan sağlar. Aylık raporda toplam harcama, önceki aya göre değişim, en çok harcayan kaynaklar, taahhüt kullanım oranı ve etiketsiz harcamanın payı yer almalıdır. Bu rapor, IT bütçe planlamasının da temel girdilerinden biridir.

Sık Yapılan Maliyet Hataları

• Tek seferlik temizlik yapıp bırakmak: Atıl kaynaklar zamanla yeniden birikir. Optimizasyon aylık bir rutin olmalıdır.
• Varsayılan özellikleri sorgulamamak: Kaynak oluştururken açılan premium destek planı, gelişmiş izleme, coğrafi yedekli depolama veya ek güvenlik katmanı gibi seçeneklerin o iş yükü için gerçekten gerekip gerekmediğini değerlendirmemek.
• Yalnızca işlem maliyetine bakmak: Depolama, veri transferi, log ve destek planları gibi kalemleri göz ardı etmek.
• Maliyet için güvenliği ve sürekliliği feda etmek: Yedekleri azaltmak veya felaket kurtarma kopyasını kapatmak kısa vadede tasarruf gibi görünür, ancak bir kesintide çok daha pahalıya mal olur.
• Çoklu bulutu otomatik olarak ucuz sanmak: Birden fazla sağlayıcı kullanmak pazarlık gücü ve esneklik sağlayabilir; ancak bölünen taahhüt indirimleri, sağlayıcılar arası veri transferi ve artan yönetim yükü toplam maliyeti yükseltebilir. Karar iş yükü bazında verilmelidir; bu konuyu hibrit ve çoklu bulut yazımızda ele aldık.
• Mimariyi hiç sorgulamamak: Bazı iş yükleri sanal makine yerine yönetilen veritabanı, konteyner veya sunucusuz hizmetlerde daha ekonomik çalışır. Uzun vadeli en büyük tasarruflar çoğu zaman mimari iyileştirmelerden gelir.

Maliyet Optimizasyonu İçin Ne Zaman Destek Almalı?

Aşağıdaki durumlardan biri sizin için geçerliyse dışarıdan bir göz faydalı olacaktır:

• Faturanız her ay artıyor, ancak artışın nedenini kalem bazında açıklayamıyorsunuz.
• Birden fazla abonelik veya hesap var ve kimin neyi yönettiği belirsiz.
• Rezervasyon veya tasarruf planı almayı düşünüyor, ancak doğru taahhüt miktarını belirleyemiyorsunuz.
• Buluta yeni geçtiniz ve bütçe planı ile gerçekleşen harcama arasında belirgin bir fark var.
• Teknik ekibinizin maliyet analizine ayıracak zamanı yok.

Bir maliyet değerlendirmesi genellikle mevcut faturanın ve kaynak envanterinin incelenmesiyle başlar; ardından hızlı kazanımlar, taahhüt önerileri ve mimari iyileştirmeler önceliklendirilmiş bir eylem planına dönüştürülür. Ümraniye Bilişim olarak bulut çözümleri hizmetimiz kapsamında bu değerlendirmeyi yapıyor, önerileri sizinle birlikte uyguluyor ve düzenli raporlama sürecini kuruyoruz.

Sonuç

Bulut maliyetlerini düşürmek tek bir ayar değil, sürekli bir disiplindir. Önce görünürlük sağlayın, ardından atıl kaynakları temizleyip doğru boyutlandırma yapın, sonra öngörülebilir yükler için taahhüt modellerini değerlendirin ve bütçe alarmlarıyla süreci kalıcı hale getirin. Bu sırayla ilerleyen işletmeler, performanstan ve güvenlikten ödün vermeden bulut faturalarını kontrol altına alabilir. Mevcut bulut harcamalarınızı birlikte incelemek için ücretsiz ön görüşme talep edebilirsiniz.