Küçük Ekipler İçin Bulut Maliyeti: Para Nereye Gidiyor?

Altı kişilik bir ekibin bir rezervasyon platformu işlettiğini düşünün. İki yıl önce kiralık tek bir sunucudan büyük bir bulut sağlayıcısına geçtiler. İlk faturalar makuldü, herkes memnundu. Şimdi aylık fatura o günün birkaç katı, trafik ise yalnızca biraz arttı ve kurucu neyin değiştiğini sorduğunda kimse emin bir cevap veremiyor. Yazılımcılar yeni özellik çıkarmakla meşgul; fatura muhasebenin gelen kutusuna tek bir rakam olarak düşüyor.

Bu, küçük ekipler için olağan bir yol; dikkatsizlik işareti değil. Bulut platformları kaynak oluşturmayı çok kolaylaştırır, o kaynaklar işe yaramaz hâle geldiğinde ise neredeyse hiçbir şey söylemez. Bu yazıda AWS, Google Cloud ya da Azure'da paranın en sık sızdığı yerleri, aşağı yukarı bizim kontrol ettiğimiz sırayla ve her biri için ne yapılabileceğiyle anlatıyoruz.

1. Hiç uyumayan ortamlar

Çoğu ekibin bir test (staging) ortamı, bazen satış için ayrı bir demo ortamı ve ara sıra da birinin bir geçişi denemek için açtığı bir kopyası vardır. Bunların her biri genelde canlı ortamın aynısıdır: bir uygulama sunucusu, bir veritabanı, bir önbellek, bir yük dengeleyici. Haftada birkaç saat kullanılırken bütün gece ve bütün hafta sonu çalışırlar.

İşe her ortamı listeleyip kimin ne zaman kullandığını sorarak başlayın. Test ortamı çoğu zaman mesai dışında duracak şekilde zamanlanabilir ya da canlı ortam gibi davranmaya devam eden en küçük makineye indirilebilir. Geçici kopyalara oluşturuldukları gün bir sahip ve bir bitiş tarihi verilmeli. Bir ortamın sahibi yoksa, kapatılabileceğinin genelde en açık işareti budur.

2. Hiç gelmeyen bir açılış günü için boyutlanmış makineler

Bir sistem ilk kurulduğunda güvenli seçim cömert bir makinedir. Sonra açılış olur, trafik oturur ve boyut aynı kalır. Sağlayıcının izleme ekranı çoğu zaman işlemcinin haftalarca düşük seyrettiğini, belleğin de sınırının çok altında kaldığını gösterir.

En yoğun günleriniz dahil en az iki üç haftalık gerçek kullanıma bakın, sonra her seferinde bir boy küçültüp izleyin. Uygulama birden fazla sunucuda çalışıyorsa otomatik ölçeklemenin yalnızca yukarı değil, gece aşağı da indiğini kontrol edin. Kullanım bir süre sabit kaldıktan sonra, ayrılmış sunucu (reserved instance) ya da tasarruf planı gibi taahhütlü seçenekler, elinizde tutacağınızdan emin olduğunuz kapasitenin fiyatını düşürebilir; bunlar boyutlandırma doğru yapıldıktan sonra anlamlıdır, öncesinde değil.

3. Yönetilen veritabanı katmanları

Yönetilen veritabanları parasını hak eder: yedekleme, güncelleme ve yedeğe geçiş sizin yerinize yapılır. Ama tek kalemdeki en büyük tutar da çoğu zaman burada saklanır. Bekleyen bir kopyası olan yüksek erişilebilirlik kurulumu sunucunun maliyetini ikiye katlar; bu canlı ortam için doğru bir tercihtir, test ortamı için ise nadiren. Ayrılan depolama alanı ve garanti edilen disk hızı da bazen iş yükünün ihtiyacının çok üzerinde ayarlanır.

Her veritabanında üç şeye bakın: katmanı hizmet ettiği ortama uyuyor mu, depolama ve hız ayarları gerçek kullanıma uyuyor mu, eski okuma kopyaları hâlâ bir yere bağlı mı. Yavaş sorgular da burada önemlidir. Eksik bir indeks, veritabanını daha büyük bir makineye ihtiyacı varmış gibi gösterebilir; oysa asıl çözüm sorgudadır.

4. Buluttan çıkan veri

Bulut sağlayıcısına giren veri genelde ücretsizdir; çıkan veri genelde değildir. Bölgeler ya da erişilebilirlik alanları arasındaki trafik de faturalanabilir. Ekipler, özellikle görseller ve dosyalar doğrudan depolamadan sunuluyorsa ya da sürekli konuşan servisler farklı bölgelerdeyse, faturanın kayda değer bir kısmının ağ transferi olduğunu görünce şaşırır.

Statik dosyaları ve görselleri bir CDN üzerinden sunmak hem maliyeti hem de yüklenme süresini düşürür. Çok veri alışverişi yapan servisleri aynı bölgede tutmak da yardımcı olur. Özel sunucuların internete çıkması için bir NAT gateway kullanıyorsanız, üzerinden ne kadar trafik geçtiğine bakın; paket indirmeleri ve dış API çağrıları orada birikir ve bu trafiğin bir kısmı daha ucuz bir yoldan yönlendirilebilir.

5. Kimsenin okumadığı loglar

Merkezi loglama önemlidir ve öneririz. Ama loglar alınan hacme ve ne kadar süre saklandığına göre faturalanır. Bir incelemeden sonra açık unutulan bir debug seviyesi, birkaç saniyede bir satır yazan bir sağlık kontrolü ya da "süresiz" bir saklama süresi, loglamayı şaşırtıcı derecede büyük bir faturaya çevirebilir.

Canlı ortam için bir log seviyesinde anlaşın, saklama süresini sorun gidermek ve varsa yasal gereklilikler için gerçekten ihtiyaç duyduğunuz kadar tutun, eski logları saklamanız gerekiyorsa daha ucuz arşiv depolamaya taşıyın. Metrikler ve alarmlar, hacmin çok küçük bir kısmıyla, ham log satırlarından genelde daha fazlasını anlatır.

6. Yalnızca büyüyen depolama

Artık var olmayan disklerin anlık kopyaları, bir sunucu silinirken geride kalan bağlı olmayan diskler, kayıttaki eski container imajları, her yayın hattı çalışmasından kalan derleme çıktıları ve kaldırılmış bir özellikten kalan dosya klasörleri: depolama gigabayt başına ucuzdur ve tam da bu yüzden sessizce birikir.

Çoğu sağlayıcı, nesneleri belirli bir süreden sonra silen ya da arşivleyen yaşam döngüsü kuralları tanımlamanıza izin verir. Bunları derleme çıktılarına, container imajlarına ve yedek kopyalarına uygulayın. İhtiyacınız olan yedekleri tutun, ama bilinçli olarak, birinin seçtiği bir saklama süresiyle tutun.

7. Faturanın sahibi yok

Yukarıdakilerin hepsinin altındaki sorun genelde aynıdır: kaynakları oluşturan kişiler ne tuttuklarını hiç görmez, maliyeti gören kişi de her kaynağın ne işe yaradığını bilemez.

İki basit alışkanlık bunu değiştirir. Birincisi, her kaynağı en azından proje, ortam ve sahip bilgisiyle etiketleyin; böylece fatura insanların tanıdığı bir şekilde bölünebilir. İkincisi, sağlayıcının konsolunda bütçe alarmları kurun; ani bir sıçrama ay sonunda değil, birkaç gün içinde fark edilsin. Faturanın etiketlere göre bölündüğü yarım saatlik aylık bir gözden geçirme, maliyeti işin gerçekten kullandığıyla uyumlu tutmaya çoğu zaman yeter.

Kısaca

Küçük bir ekibin bulut faturası artıklarla büyür: gece gündüz çalışan ortamlar, daha yoğun bir gün için boyutlanmış makineler, gerekenden yüksek ayarlanmış veritabanı katmanları, kimsenin planlamadığı veri transferi, süresiz saklanan loglar ve kimsenin temizlemediği depolama. Görünür olduklarında her birini düzeltmek kolaydır. Kaynakları etiketleyin, bütçe alarmları kurun, faturayı her ay gözden geçirin ve uzun vadeli indirimlere bağlanmadan önce boyutlandırmayı yapın.

Bulut ve DevOps çalışmalarımızda maliyet kontrolü, izleme ve yedeklemenin yanında yer alır: kullanımı inceliyor, gereksiz olanı kapatıyor, kalanı yeniden boyutlandırıyor ve hesapları müşterinin kendi adına tutuyoruz.