Cloud maliyeti tartışmasının çoğu yanlış soruyla başlar: bulut mu ucuz, on-premise mi. Doğru soru şu: iş yükünün talep eğrisi neye benziyor ve hangi ortam bu eğriye daha az israfla uyuyor.
TCO hesabında görünmeyen kalemler
Bir iş yükünü buluta taşımadan önce yapılan hesap genelde iki kalemden oluşur: hesaplama ve depolama. Fatura geldiğinde sürpriz yaratan kalemler ise çoğunlukla bunların dışındadır.
- Veri çıkışı ve bölgeler arası trafik. Veriyi içeri almak genelde ücretsizdir, dışarı çıkarmak değildir. Üstelik aynı sağlayıcı içinde bile farklı erişilebilirlik bölgeleri arasındaki trafik ücretlendirilebilir. Yüksek erişilebilirlik için bileşenleri bölgelere yayan bir mimari, farkında olmadan sürekli ücretli trafik üretir.
- Anlık görüntü birikimi. Yedek politikası almayı tanımlar ama silmeyi tanımlamazsa depolama maliyeti doğrusal artar.
- Sahipsiz kaynaklar. Silinen sunucudan geriye kalan bağlanmamış diskler, arkasında hedef kalmamış yük dengeleyiciler, kullanılmayan statik IP adresleri. Hiçbiri tek başına büyük değildir, toplamı büyür.
- Yönetilen servis primi. Yönetilen veritabanı ya da yönetilen cluster, ham sunucuya göre daha pahalıdır. Bu fark çoğu zaman mantıklıdır, çünkü karşılığında işletme yükü devredilir; ama hesaba katılmadığında sürpriz olur.
Kubernetes'te faturayı belirleyen ayar: request ve limit
Kubernetes çalıştıran ekiplerde cloud maliyetinin en büyük tek kaynağı genelde yanlış ayarlanmış kaynak talepleridir. Mekanizmayı doğru anlamak gerekiyor, çünkü request ve limit farklı işler yapar.
Request yerleştirme için kullanılır. Scheduler bir podu hangi node'a koyacağına karar verirken gerçek kullanıma değil, beyan edilen request değerine bakar. Yani 4 çekirdek isteyip 200 milicore kullanan bir pod, node üzerinde 4 çekirdeklik yer işgal etmiş sayılır. Bu boş kalan alan başka podlara verilemez, cluster daha erken dolar ve yeni node açılır. Faturayı büyüten şey tam olarak budur.
Limit ise çalışma anında üst sınırdır ve CPU ile bellek için farklı davranır. CPU limitine dayanan bir konteyner öldürülmez, kısılır; yani uygulama yavaşlar ama ayakta kalır. Bellek limitine dayanan bir konteyner ise kısılamaz, sonlandırılır. Bu asimetri şu pratik sonucu doğurur: bellek request ve limit değerlerini gerçekçi vermek, CPU'ya göre çok daha kritiktir.
Doğru değerleri bulmanın yolu ortalamaya bakmak değil, bir süre boyunca gözlenen yüksek yüzdelik dilimlere bakmaktır. Ortalamaya göre ayarlanan bir bellek limiti, yükün tepe yaptığı anlarda sonlandırmalar üretir. Kaynak yönetimi tarafında ilk yaptığımız iş genelde bu ölçümü toplamak oluyor, çünkü değerleri tahminle değiştirmek sorunu yalnızca yer değiştirtiyor.
Rezerve, spot ve on-demand arasında seçim
Bulut sağlayıcıları aynı kapasiteyi üç farklı taahhüt seviyesinde satar ve aradaki fiyat farkı önemlidir. Seçimi belirleyen şey fiyat değil, iş yükünün kesintiye ve taahhüde toleransıdır.
On-demand en esnek ve en pahalıdır. Talebin öngörülemediği, kısa ömürlü ya da yeni başlayan iş yükleri için doğrudur.
Rezerve ya da taahhüt bazlı modeller belirli süreli kapasite taahhüdü karşılığında indirim verir. Risk fiyat değil esnekliktir: bir yıllık taahhüt verdiğiniz aileden altı ay sonra çıkarsanız taahhüt sizde kalır. Bu yüzden taahhüt, mimarisi oturmuş ve talebi ölçülmüş iş yükleri için mantıklıdır.
Spot kapasitesi ise sağlayıcının atıl kapasitesidir ve kısa bir uyarıyla geri alınabilir. Doğru kullanıldığında en büyük tasarrufu sağlar, yanlış kullanıldığında kesinti üretir. Uygun iş yükleri kesintiye dayanıklı olanlardır: toplu işleme, derleme havuzları, test ortamları, yeniden başlatıldığında kaldığı yerden devam edebilen kuyruğa dayalı işler. Kullanıcı isteklerine doğrudan cevap veren ya da durum tutan bileşenler için uygun değildir.
Pratikte üçünü karıştırmak en iyi sonucu verir: taban yük taahhüt bazlı kapasitede, dalgalanan kısım on-demand üzerinde, kesintiye dayanıklı işler spot üzerinde. Bu karışımın işe yaraması için ölçeklemenin otomatik olması gerekir; auto-scaling ve self-healing tarafı kurulmadan bu model elle yönetilemez.
On-premise kırılım noktası nasıl hesaplanır
Bulutun fiyatladığı asıl şey esnekliktir: kapasiteyi dakikalar içinde artırıp azaltabilmek. Bu esnekliği kullanmayan bir iş yükü, kullanmadığı bir özelliğin primini öder. Kırılım noktası da buradan çıkar.
Karar verirken bakılacak ölçü, talebin tepe değerinin taban değerine oranıdır. Bu oran yüksekse, yani sistem günün büyük kısmında boşta durup kısa aralıklarla tepe yapıyorsa, bulut esnekliği gerçekten kullanılıyor demektir. Oran bire yakınsa, yani yük sürekli ve öngörülebilirse, aynı kapasiteyi sabit donanımda tutmak genelde daha ucuza gelir.
On-premise tarafında hesaba katılması gerekenler ise şunlardır: donanımın satın alma bedeli ve amortisman süresi, kabin ve enerji, soğutma, yedek donanım, lisanslar ve bu ortamı işletecek ekip. Bu kalemler yazılmadığında on-premise olduğundan ucuz görünür. Yazıldığında ise tablo çoğu kurum için şuna dönüşür: sabit taban yük kendi donanımında, dalgalanan kısım bulutta. Private cloud yaklaşımının cazip olmasının nedeni de budur; izole ve öngörülebilir bir kaynak havuzunu, esneklik gerektiren iş yükleriyle birlikte kullanabilmek.
Depolama katmanları ve veri yaşam döngüsü
Depolama, hesaplama kadar dikkat çekmediği için genelde tek katman olarak kurulur ve öyle kalır. Oysa verinin erişim sıklığı zamanla düşer: üç ay önceki bir işlem kaydına bugün neredeyse hiç bakılmaz, ama o kayıt hâlâ en hızlı ve en pahalı diskte durur.
Sağlayıcılar bu yüzden erişim sıklığına göre farklı katmanlar sunar. Sıcak katman hızlıdır ve depolama başına pahalıdır. Soğuk ve arşiv katmanları depolama başına çok daha ucuzdur, ama iki ek maliyet getirir: veriyi geri okumanın bir bedeli vardır ve minimum saklama süresi şartı bulunur. Süresi dolmadan silinen bir nesne için yine de tam süre faturalanabilirsiniz.
Katman geçişini elle yapmak yerine yaşam döngüsü kuralı tanımlamak gerekir. Dikkat edilecek nokta geri okuma bedelidir: ayda birkaç kez okunan bir veri kümesini arşiv katmanına indirmek tasarruf yerine ek maliyet üretebilir. Katman kararı verinin yaşına değil, gerçek okuma sıklığına göre verilir.
Ölçmeden optimize edilmez
FinOps yaklaşımının ilk adımı tasarruf değil görünürlüktür. Harcamanın hangi ekibe, hangi projeye ve hangi ortama ait olduğu ayrıştırılamıyorsa, yapılan her optimizasyon tahmine dayanır.
Görünürlüğün temeli tutarlı etiketlemedir. Etiket şeması baştan tanımlanmalı, etiketsiz kaynak oluşturulmasına izin verilmemelidir. Harcamayı ekip bazında gösterebilmek maliyeti göreninin çok daha hızlı davranmasını sağlar; tek tek sunucu bakmak yerine eğilim izlenir.
Geri tepen tasarruf yöntemleri
Maliyet düşürme çalışmalarında sık yapılan ve sonradan daha pahalıya patlayan birkaç hamle var. Bunları baştan bilmek gerekir.
- Replika sayısını tek düşürmek. Maliyeti azaltır ama bakım penceresinde kesintisiz çalışmayı imkansız kılar. Bunun neden böyle olduğunu Kubernetes sürüm yükseltme yazısında PodDisruptionBudget bölümünde ayrıntılı anlattık.
- Bellek limitlerini kırpmak. Kısa vadede node başına daha çok pod sığar, orta vadede sonlandırmalar ve yeniden başlatmalar artar.
- Yedek saklama süresini kısaltmak. Depolama faturası düşer, kurtarma penceresi de düşer. Bu bir maliyet kararı değil, risk kararıdır ve öyle alınmalıdır.
- İzleme ve log toplamayı kapatmak. En hızlı tasarrufu buradan almak mümkündür, karşılığında bir sonraki arızanın süresi uzar.
Sık sorulan sorular
Cloud faturasında en çok atlanan kalem hangisi?
Veri çıkışı ve bölgeler arası trafik. Hesaplama ve depolama kalemleri planlanırken hesaba katılır, ama iki servis arasındaki trafiğin ücretlendirildiği çoğu zaman mimari kurulduktan sonra fark edilir. Bunun yanında sahibi kalmamış diskler, eski anlık görüntüler ve boşta duran yük dengeleyiciler de sessizce birikir.
Kubernetes request ve limit ayarı maliyeti nasıl etkiler?
Scheduler yerleştirmeyi request değerine göre yapar, gerçek kullanıma göre değil. Request olduğundan yüksek verilirse node üzerinde kullanılmayan ama rezerve edilmiş kapasite kalır ve cluster gereğinden fazla büyür. Fatura da bu boş kapasiteyi öder.
Spot instance hangi iş yükleri için uygun?
Kesintiye dayanıklı, durum bilgisi tutmayan ve yarıda kalırsa baştan başlatılabilen işler için uygundur. Toplu işleme, test ortamları ve derleme havuzları tipik örneklerdir. Veritabanı gibi durum tutan bileşenler ya da kesintiye toleransı olmayan kullanıcı istekleri için uygun değildir.
On-premise ne zaman buluttan ucuz olur?
Yük sabit ve öngörülebilir olduğunda. Bulut esnekliği fiyatlar, o esnekliği kullanmayan sürekli çalışan bir iş yükü için bu prim boşa gider. Buna karşılık donanım alımı, amortisman, elektrik, soğutma ve işletme ekibi maliyetlerinin de hesaba katılması gerekir.
Maliyet optimizasyonuna nereden başlanmalı?
Ölçmekten. Harcamanın hangi ekibe, projeye ve ortama ait olduğu etiketlerle ayrıştırılmadan yapılan her indirim çalışması tahmine dayanır. Önce görünürlük kurulur, sonra boşta duran kaynaklar temizlenir, en son taahhüt bazlı indirimlere geçilir.