Bulut Maliyet Optimizasyonu: Startuplar İçin Pratik Bir Rehber

• 1. Faturanızı Optimize Etmeye Çalışmadan Önce Anlayın
• 2. Hesaplama Kaynaklarını Doğru Boyutlandırın
• 3. Rezerve Kapasite ve Tasarruf Planları
• 4. Spot ve Öncelikli (Preemptible) Sunucular
• 5. Depolama: Yavaş Sızıntıdan Sel Felaketine
• 6. Yönetilen Veritabanları
• 7. Kubernetes ve Konteynerler
• 8. Ağ ve Veri Transferi
• 9. Kod Olarak Altyapı
• 10. Maliyet Bilincine Sahip Bir Mühendislik Kültürü Oluşturmak
• Altyapı Disiplini Üzerine Bileşik Getiri

Ayın ilk günü, bir startup kurucusu veya mühendislik liderine özgü bir tür korku gelir. Bulut faturası gelir, geçen aydan daha yüksektir ve ekipte kimse hemen nedenini açıklayamaz. Konsola dalar, kalem kalem giderleri incelersiniz ve sonunda birkaç suçlu bulursunuz; altı haftadır kimsenin dokunmadığı büyük boyutlu bir sunucu, tam kapasitede çalışan unutulmuş bir test ortamı, son ürün değişikliğinden beri sorgulanmamış bir kovaya veri döken bir veri hattı.

Bu nadir bir hikaye değil. Aslında varsayılan hikaye bu. Bulut altyapısı sağlamak son derece kolay ve unutmak da bir o kadar kolaydır. Faturalandırma modeli (kullandığın kadar öde, saniye bazında faturalandırılır) adil gibi görünür, ta ki "kullandığın" şeyin kapatmayı unuttuğun her şeyi de kapsadığını fark edene kadar.

Erken aşamadaki girişimler için bu, büyük işletmelere kıyasla çok daha önemlidir. Fortune 500 şirketi için ayda 50.000 dolarlık gereksiz bulut harcaması bir verimsizliktir. Ancak, runway’ini hızla tüketen bir Seri A girişimi için bu gerçek bir stratejik sorundur. Ne kadar süreyle faaliyet gösterebileceğinizi, kimi işe alabileceğinizi ve hangi riskleri alabileceğinizi doğrudan etkiler. Bulut maliyeti disiplini bir finans meselesi ya da yalnızca bir DevOps alanı değildir. Şirketi nasıl yönettiğinizin temel bir parçasıdır.

İyi haber şu ki, bulut harcamalarının aşırıya kaçması büyük ölçüde çözülmüş bir problem. Kalıplar iyi anlaşılmış, araçlar olgunlaşmış durumda ve tasarruflar gerçek ve hızlı. Bu rehber, ilk günden itibaren sahip olmanız gereken temel unsurlardan, altyapı ekonominizi yıllarca şekillendirecek mimari kararlara kadar her önemli kaldıracı adım adım ele alıyor.

1. Faturanızı Optimize Etmeye Çalışmadan Önce Anlayın

Bu kulağa bariz geliyor. Ama öyle değil. Çoğu girişim mühendislik ekibi, toplam aylık bulut harcamalarının kabaca farkında, bunun nereden geldiğine dair daha belirsiz bir fikre sahip ve zaman içindeki maliyet eğilimlerinden hangi spesifik hizmetlerin, özelliklerin veya ortamların sorumlu olduğuna dair neredeyse hiçbir fikre sahip değil. Bu bir ihmal değil, sadece kimse bu soruları yanıtlayacak altyapıyı açıkça kurmadığında varsayılan durum budur.

Herhangi bir şeyi optimize edebilmeniz için önce görünürlük gerekir. Gerçek, ayrıntılı ve takıma atfedilmiş bir görünürlük.

Maliyet tahsis etiketleri temeldir. Her büyük bulut sağlayıcısı, kaynakları keyfi anahtar-değer çiftleriyle etiketlemeyi destekler ve bu etiketler fatura verilerinize yansır. Etiketlemeye başladığınız anda şu soruları yanıtlayabilirsiniz: Veri hattımızın aylık maliyeti nedir? Staging ortamımızı çalıştırmanın maliyeti nedir? Geçen Salı gördüğümüz artıştan hangi takımın hizmetleri sorumlu?

Etiketler olmadan, tek bir sayıya bakıp tahmin yürütüyorsunuz. Etiketlerle ise gerçekten mantık yürütebileceğiniz yapılandırılmış bir veri setine sahip oluyorsunuz. İlk günden bir etiketleme şeması oluşturun; ortam (prod, staging, dev), takım veya ekip, hizmet veya özellik ve maliyet merkezi en kullanışlı boyutlardır ve bunu altyapı-kodunuzda zorunlu kılın ki yeni kaynaklar her zaman doğru şekilde etiketlensin.

Faturalandırma panoları ve anomali uyarıları ücretsiz sigortadır. Her bulut sağlayıcısı, ek ücret olmadan yerel maliyet yönetimi araçları sunar (AWS Cost Explorer, GCP Cost Management, Azure Cost Analysis). Aylık hedefinizin %50, %75 ve %90’ında bütçe uyarıları kurun. Herhangi bir hizmette harcama beklenmedik şekilde arttığında bilgilendirilecek şekilde anomali tespiti yapılandırın. Bu araçlar size neden bir şeyin pahalı olduğunu söylemez, ancak ne zaman pahalı olduğunu bilmenizi sağlar ve zamanlama son derece önemlidir. Ayın ikinci gününde yakalanan bir sorun, otuzuncu günde keşfettiğinizden çok daha az maliyetlidir.

En çok harcama yaptığınız ilk on kalemi inceleyin ve her birini anlayın. Çoğu erken aşama şirkette, dört ila altı hizmet toplam faturanın %80–90’ını oluşturur: EC2 veya eşdeğer hesaplama, RDS veya eşdeğer yönetilen veritabanı, S3 veya eşdeğer nesne depolama, veri transferi (çıkış) ve belki de yönetilen bir konteyner servisi veya Kubernetes kümesi. Her birinin ne yaptığını, neden bu kadar maliyetli olduğunu ve makul bir temel seviyenin nasıl göründüğünü bilin. Geri kalan her şey bağlamdır.

2. Hesaplama Kaynaklarını Doğru Boyutlandırın

Hesaplama neredeyse her zaman en büyük harcama kalemidir ve neredeyse her zaman fazla tahsis edilmiştir. Bu, sunucu boyutlandırmasını yapan mühendislere bir eleştiri değil, ekiplerin belirsizlik altında altyapı kararları alma biçiminin yapısal bir sonucudur.

Yeni bir hizmet başlatırken, tam olarak ne kadar trafik alacağını veya kaynak kullanım profilinin nasıl olacağını bilemezsiniz. Bu yüzden muhafazakâr bir tahmin yapar ve bir tampon eklersiniz. Bu mantıklıdır. Ancak bu tamponlar birleşir. Bir düzine hizmet, üç ortam ve iki yıl boyunca organik büyüme ile, nadiren karşılaştıkları bir yük için boyutlandırılmış bir dizi sunucu biriktirirsiniz.

Herhangi bir değişiklik yapmadan önce kullanım metriklerinizi çekin. Son 30 gün boyunca çalışan her bir sunucu için ortalama CPU ve bellek kullanımına bakın. Zirveye değil, ortalamaya bakın. Ortalama %8–12 CPU kullanımıyla çalışan ve zaman zaman %35’e çıkan bir sunucunun bu kadar büyük olmasına gerek yoktur. Çoğu bulut sağlayıcısı, maliyet konsollarında doğrudan doğru boyutlandırma önerileri sunar; bunları başlangıç noktası olarak alın, gerçek kullanım verilerinizle doğrulayın ve önerinin ötesine geçmeye istekli olun.

Üretim ve üretim dışı ortamlarınızı ayırın. Bu, çoğu girişimin yapabileceği en etkili değişikliklerden biridir ve neredeyse hiç mimari çalışma gerektirmez. Geliştirme ve hazırlık (staging) ortamlarının, üretim kapasitesinde haftanın yedi günü, günde 24 saat çalışmasına gerek yoktur. Mühendisler genellikle günde 10 saat, haftada 5 gün çalışır. Bu da üretim dışı altyapınızın zamanın yaklaşık %70'inde boşta olduğu anlamına gelir.

Otomatik kapatma programları uygulayın. Bir Lambda fonksiyonu, bir Cloud Scheduler işi veya basit bir cron ile tetiklenen bir betik kullanarak, üretim dışı örnekleri akşamları durdurup sabahları yeniden başlatın. Ortamlarınızı doğru şekilde etiketleyin, böylece bunu seçici olarak uygulayabilirsiniz. Sadece mesai saatlerinde çalışan bir staging ortamı, 7/24 çalışan bir ortama göre yaklaşık %30 maliyetle çalışır ve başlatma süresi kabul edilebilir düzeydeyse (genellikle iki dakikanın altında) geliştirici deneyimine etkisi minimumdur.

Özellikle geliştirme ortamları için, bireylerin sürekli bulut örneklerine gerçekten ihtiyacı olup olmadığını veya çoğu iş yükünü konteyner tabanlı yerel geliştirme ortamlarının karşılayıp karşılayamayacağını değerlendirin. Birçok ekip, geliştirmeyi yerel Docker ortamlarına taşıyıp bulut kaynaklarını yalnızca staging ve üretim için tutmanın, verimliliği etkilemeden faturalarını anlamlı şekilde azalttığını görüyor.

Örnek aileleri, örnek boyutlarından daha önemlidir. AWS, GCP ve Azure düzenli olarak, eski nesillere göre daha iyi fiyat-performans sunan yeni örnek aileleri piyasaya sürer. En son nesil işlemciye optimize edilmiş veya genel amaçlı örnekler, neredeyse her zaman önceki nesle göre birim başına daha ucuzdur; bazen bu fark %10–20’ye kadar çıkar. İki nesilden daha eski bir aileden örnekler çalıştırıyorsanız, muhtemelen daha iyi bir seçenek vardır. Bunu en az yılda bir kez gözden geçirin.

3. Rezerve Kapasite ve Tasarruf Planları: En Yüksek Yatırım Getirili Karar

Girişiminiz altı aydan uzun süredir faaliyet gösteriyorsa ve öngörülebilir gelecek için ihtiyaç duyacağı sabit bir hesaplama tabanına sahipse ve bu taban için isteğe bağlı (on-demand) fiyatlar ödüyorsanız, pahalı bir hata yapıyorsunuz. Bu bir istisna değil. Bu, girişimlerin bulut yönetiminde en yaygın ve en maliyetli hatalardan biridir.

Talep üzerine fiyatlandırma, gerçekten öngörülemeyen iş yükleri için tasarlanmıştır. Kaynakları taahhüt olmadan hızlıca artırıp azaltabilme esnekliği için fazladan ödeme yaparsınız. Bu ek ücret, değişken ve belirsiz iş yükleri için mantıklıdır. Son bir yıldır değişmeden çalışan temel altyapı için ise hiçbir anlam ifade etmez.

Rezerve instance’lar ve tasarruf planları, taahhüt süresine ve ödeme yapısına bağlı olarak, isteğe bağlı kullanıma göre %40–70 oranında hesaplama maliyetlerini azaltır. Bir yıl vadeli, peşinatsız bir taahhüt genellikle isteğe bağlı kullanıma göre %30–40 daha ucuzdur. Üç yıl vadeli, kısmi veya tam peşinatlı bir taahhüt ise %60–70’e varan tasarruf sağlayabilir. EC2 üzerinde ayda 20.000 $ harcayan bir startup için, temel kullanımı rezerve instance’lara taşımak ayda 8.000–14.000 $ tasarruf anlamına gelir. Bu, göz ardı edilecek bir rakam değildir.

Pratik yaklaşım: minimum temel hesaplama ihtiyacınızı belirleyin; yani, trafik veya yükten bağımsız olarak, sessiz bir Pazar günü sabah 3’te çalışan taban. Bu tabanı rezerve kapasiteyle karşılamalısınız. Bunun üzerindeki her şey (ani artışlar, trafik patlamaları, yeni özellik lansmanları) isteğe bağlı veya spot olarak kalmalı. Böylece, değişken her şey için isteğe bağlı esnekliği korurken, taahhütlerin maliyet verimliliğinden yararlanırsınız.

Taahhütlerinizi üç ayda bir gözden geçirin. Rezerve instance’lar ve tasarruf planları “al ve unut” değildir. Ürününüz geliştikçe tabanınız değişecektir. Mevcut taahhütlerin kullanımını ve yeni ekleme fırsatlarını her çeyrekte gözden geçirin. Biraz az taahhüt edip üzerine eklemek, fazla taahhüt edip rezerve kapasiteyi kullanmadan bırakmaktan daha iyidir. Kullanılmayan rezervasyonlar, pratikte boşa harcanan paradır.

Tasarruf planları vs. rezerve instance’lar: AWS tasarruf planları, geleneksel rezerve instance’lara göre daha fazla esneklik sunar; belirli instance türü, bölge veya işletim sisteminden bağımsız olarak, bir aile içindeki herhangi bir EC2 kullanımına uygulanır. Çoğu startup için tasarruf planları yönetimi daha kolay ve neredeyse aynı derecede maliyet etkilidir. Altyapınız nispeten stabil ve iyi tanımlanmışsa, belirli instance türleri için rezerve instance’lar birkaç puan daha fazla tasarruf sağlayabilir.

PlusClouds ve Bulut Maliyet Optimizasyonu:

Rezerve instance taahhütlerinde tahmin yürütmeyi bırakın.

PlusClouds, geçmiş kullanım alışkanlıklarınızı analiz eder ve tam olarak ne kadar rezerve kapasite satın almanız gerektiğini — örnek ailesi, bölge ve süre uzunluğuna göre ayrıntılı şekilde — size bildirir. PlusClouds'un taahhüt önerilerini kullanan müşteriler, hesaplama maliyetlerinde ortalama %41 tasarruf eder. AWS Reserved Instances, Azure Reserved VMs ve GCP Committed Use Discounts üzerinde çalışır.

plusclouds.com adresinde nasıl çalıştığını görün

4. Spot ve Preemptible Instance'lar: Doğru İş Yükleri İçin %90 İndirim

AWS'deki spot instance'lar ve GCP'deki preemptible VM'ler, mevcut en güçlü maliyet azaltma araçları arasında yer alır ve startup'lar tarafından en az kullanılanlardandır. Bunun nedeni, risk algısı ve aşinalık eksiminin birleşimidir. Hangi iş yüklerinin uygun adaylar olduğunu anladığınızda, ekonomik avantajları göz ardı etmek neredeyse imkansızdır.

Spot instance'lar, bulut sağlayıcısının yedek kapasitesi üzerinde çalışır. Bu kapasiteye teklif verirsiniz (veya modern AWS spot'ta, mevcut spot fiyatından talep edersiniz) ve bulut sağlayıcısı kapasiteye tekrar ihtiyaç duyana kadar kullanırsınız; bu noktada sonlandırmadan önce iki dakikalık bir uyarı alırsınız. Bu rahatsızlık için sunulan indirim: isteğe bağlı fiyatlara göre %90'a varan indirim.

Kesintiye uğrayabilen veya yeniden başlatılabilen iş yükleri için bu, temelde bedava para demektir. Spot instance'ların sorunsuz çalıştığı kategoriler arasında CI/CD pipeline çalışanları (bir derleme işi kesilirse, runner tekrar alır), toplu veri işleme ve ETL pipeline'ları (ilerlemenizi kaydedin ve devam edin), makine öğrenimi eğitim işleri (çoğu framework checkpoint'i destekler), gece analizleri veya rapor oluşturma, yük testi ve bir yük dengeleyici tarafından yönlendirilen, durumsuz web servisleri (bir instance'ın sonlandırılması trafiğin diğerlerine yönlendirilmesiyle sorunsuzca yönetilir) yer alır.

Spot'un uygun olmadığı iş yükleri: kesintiye tahammül edemeyen herhangi bir durumlu uygulama, çoğu yapılandırmada veritabanları, gerçek zamanlı gecikme gereksinimi olan servisler ve işlem ortasında bir hatanın durumu bozacağı veya sıfırdan tam bir yeniden başlatma gerektirecek herhangi bir iş yükü.

En iyi sonuçlar için karma bir instance stratejisi kullanın. Kesintiye uğrayabilen her şey için spot, güvenilirliğe ihtiyaç duyan durumsuz servisler için isteğe bağlı, sabit tabanınız için rezerve instance kullanın. Sadece CI/CD'nizi spot instance'larda çalıştırmak bile, minimum operasyonel karmaşıklıkla derleme altyapı maliyetlerinizi %80 azaltabilir.

5. Depolama: Sinsi Bir Sızıntıdan Sel Baskınına

Depolama maliyetleri bireysel olarak küçük, toplu olarak ise devasa boyutlardadır. Neredeyse her girişimde yaşanan örüntü aynıdır: veriler nesne depolamaya yazılır, ne zaman silineceğine dair bir süreç oluşturulmaz ve 18 ay sonra, önceki bir ürün sürümünden beri erişilmeyen terabaytlarca veri için tam depolama ücretleri ödenir.

Nesne depolama fiyatlandırması ucuz görünür, S3 Standard’da GB-ay başına 0,023 dolar. Ancak ölçek büyüdükçe veya yeterince veri biriktikçe bu tutar artar. Daha da önemlisi, birçok girişim verileri yanlış katmanda depoluyor: çoğu veriye nadiren veya hiç erişilmemesine rağmen her şeyi Standard’da tutuyorlar, çünkü kimse verilerin otomatik olarak taşınmasını sağlayacak kuralları kurmamış.

Yaşam döngüsü politikaları isteğe bağlı değildir. Bir depolama kovası oluşturduğunuzda yapılandırmanız gereken ilk şey olmalı, daha sonra optimize edeceğiniz bir şey değil. Nesneleri 30 veya 60 gün erişilmediğinde Infrequent Access depolamaya taşıyan, 90 veya 180 gün sonra Glacier veya Archive’a aktaran ve tanımlı bir saklama süresi sonunda silen kurallar tanımlayın. Günlük dosyaları için saklama süresi genellikle 30–90 gündür. Yedeklemeler için bu süre, uyumluluk gereksinimlerinize bağlıdır. Kullanımdan kaldırılmış özelliklerden gelen ham veriler için cevap çoğunlukla “6 ay sonra sil” olur.

Belirli katman geçişleri ve zaman çizelgeleri sağlayıcıya ve kullanım durumuna göre değişecektir, ancak ilke evrenseldir: verinin bir yaşam döngüsü vardır ve bunu bilinçli şekilde yönetmek zaman içinde önemli ölçüde tasarruf sağlar.

Çıkış maliyetleri, bulutun en az konuşulan fatura sürprizlerinden biridir. Bulut sağlayıcıları, verinin kendi ağlarından internete, diğer bölgelere veya bazı durumlarda aynı hesap içindeki hizmetler arasında çıkışı için ücret alır. Bu ücretler GB başına küçük olsa da, veri hacmiyle hızla artar.

Yaygın çıkış tuzakları şunlardır: işleme için büyük veri kümelerini bölgeler arasında çeken mimariler (bunun yerine işlemi verinin bulunduğu yere taşıyın), büyük dosyaları CDN olmadan doğrudan nesne depolamadan son kullanıcılara sunan uygulamalar ve gereksiz yere servisler arasında büyük veri yükleri aktaran mikroservis mimarileri. Önemli miktarda veri hareketi içeren bir mimariyi kabul etmeden önce, öngörülen ölçeğinizde çıkış maliyetlerinin ne olacağını açıkça hesaplayın.

Depolamanızı düzenli olarak denetleyin. Depolama harcamalarınızı üç ayda bir gözden geçirmek için bir takvim hatırlatıcısı ayarlayın. Yaşam döngüsü politikası olmayan kovaları, kullanımdan kaldırılmış özellikler veya hizmetler için veri depolayan kovaları, ilişkilendirilmemiş EBS hacimlerini (şaşırtıcı derecede yaygın bir israf kaynağıdır) ve saklama gereksinimlerinizi aşan eski anlık görüntüleri arayın. Bu iş cazip olmasa da, tek bir öğleden sonra yapılacak bir temizlik, yıllarca sürecek tasarruflar sağlayabilir.

6. Yönetilen Veritabanları: Güçlü, Pahalı ve Sıkça Aşırı Tahsis Edilmiş

RDS, Cloud SQL ve Azure Database gibi yönetilen veritabanı hizmetleri, bulut sağlayıcılarının en değerli hizmetleri arasındadır; yedeklemeler, yamalar, hata toleransı ve izleme gibi işlemleri, aksi takdirde önemli operasyonel uzmanlık gerektirecek şekilde yönetirler. Aynı zamanda genellikle bir girişimin bulut faturasındaki ikinci veya üçüncü en büyük kalemdir ve neredeyse her zaman mevcut iş yükünden ziyade gelecekteki bir iş yükü için boyutlandırılmıştır.

Okuma replikalarına ve 500GB sağlanmış IOPS'a sahip, çoklu-AZ yüksek erişilebilirlikli bir RDS örneği, günde milyonlarca işlem gerçekleştiren bir ürün için doğru cevaptır. Ancak 10.000 aktif kullanıcısı olan ve aylık 50.000$ MRR'ye sahip bir girişim için bu, önemli bir aşırı yatırımdır. Ödediğiniz özellikler (senkron replikasyon, otomatik hata toleransı, sağlanmış bant genişliği) değerlidir, ancak henüz ulaşmadığınız bir ölçek için bu özelliklere para ödüyorsunuz.

Veritabanı katmanınızı bugünkü gerçek gereksinimlerinize göre eşleştirin, 18 ay sonraki hedeflerinize göre değil. Her zaman ölçek büyütebilirsiniz; ölçek büyütmek genellikle basittir ve çoğu yönetilen veritabanı hizmetinde minimum kesintiyle yapılabilir. Şu anda tek bir AZ örneği veya daha küçük bir örnek sınıfı çalıştırarak tasarruf edeceğiniz para, büyüme için kullanılabilecek gerçek paradır.

Sunucusuz veritabanı seçenekleri, erken aşamadaki ürünler için yeterince değer görmüyor. Aurora Serverless v2, PlanetScale ve Firestore gibi çözümler, gerçek yük durumuna göre işlem kapasitesini ölçeklendirir ve boşta kaldıklarında neredeyse sıfıra kadar düşebilirler. Geliştirme veritabanları, düşük trafikli dahili araçlar ve erişim desenleri öngörülemeyen özellikler için sunucusuz veritabanları, yükten bağımsız olarak minimum kapasitede çalışan ayrılmış örneklerle karşılaştırıldığında maliyetleri önemli ölçüde azaltabilir.

Veritabanlarınızı sade tutun. Şemanızı periyodik olarak denetleyin ve artık aktif uygulama kodu tarafından kullanılmayan tablo, sütun ve indeksleri tespit edin. Tarihsel kayıtları, gerçek zamanlı sorgulamalar için artık gerekli olmadıklarında daha ucuz depolama alanlarına arşivleyin. Yumuşak silinmiş kayıtları belirli bir takvime göre temizleyin. Tipik yük yerine en yüksek eşzamanlı bağlantılar için boyutlandırılmış bir veritabanı örneği sağlamamak adına bağlantı havuzlaması uygulayın. Bunlar, aynı zamanda altyapı maliyetlerinizi azaltan iyi mühendislik uygulamalarıdır.

7. Kubernetes ve Konteynerler: Disiplin Gerektiren Güç

Kubernetes, birçok girişim için varsayılan dağıtım platformu haline geldi ve bunun iyi bir nedeni var; kapsayıcılaştırılmış iş yüklerini ölçekli ve güvenilir bir şekilde çalıştırmak için güçlü bir soyutlama sunar. Ancak, özellikle ekipler hızlı hareket ederken ve kaynak tahsisine dikkat etmezken, gözden kaçırılması kolay yeni bir maliyet yönetimi zorlukları da getirir.

Her podda kaynak istekleri ve limitleri zorunludur. Bir pod için kaynak istekleri tanımlanmadığında, Kubernetes scheduler’ı onu nereye yerleştireceğine karar verirken kullanacağı hiçbir bilgiye sahip olmaz. Sonuç genellikle verimsiz bir kutu yerleştirme, görünüşte "dolu" ama önemli ölçüde kullanılmamış kapasiteye sahip düğümler veya istekler gerçek kullanımı yansıtmadığı için gerçekten aşırı yüklenmiş düğümler olur. CPU ve bellek isteklerini tahminlere göre değil, gözlemlenen kullanıma göre ayarlayın. Komşularını etkileyebilecek kontrolden çıkmış süreçleri önlemek için limitler belirleyin.

Ekosistemin sunduğu otomatik ölçeklendirme araçlarını kullanın. Horizontal Pod Autoscaler (HPA), pod replikalarının sayısını CPU, bellek veya özel metriklere göre ölçeklendirir. Vertical Pod Autoscaler (VPA), gözlemlenen kullanıma göre kaynak isteklerini otomatik olarak ayarlar. Cluster Autoscaler ve daha yeni olan Karpenter, bekleyen pod taleplerine göre kümenize otomatik olarak düğüm ekler veya çıkarır. Bu araçlar birlikte küme kullanımını önemli ölçüde artırabilir, ancak iyi çalışabilmeleri için doğru kaynak isteklerine ihtiyaç duyarlar; bu nedenle bu temel çok önemlidir.

Node boyutlandırması, pod boyutlandırması kadar önemlidir. Kubernetes node havuzunuz için seçtiğiniz instance türü hem performansı hem de maliyeti etkiler. Mevcut node tiplerinizin gerçek iş yükü profilinize uygun olup olmadığını gözden geçirin: hesaplama ağırlıklı iş yükleri, hesaplama için optimize edilmiş instance’lardan; bellek ağırlıklı iş yükleri ise bellek için optimize edilmiş instance’lardan fayda sağlar. Ağırlıklı olarak belleğe bağlı iş yükleri çalıştıran genel amaçlı instance’lardan oluşan bir küme, asla kullanılmayan CPU kapasitesi için ödeme yapıyor demektir.

Küme maliyetinizi namespace, ekip veya uygulama bazında ayırın. Bu, ya bulut-yerel bir maliyet tahsis yaklaşımı (node’ları etiketleyip iş yüklerine eşleştirme) ya da özel bir araç gerektirir. Bu görünürlük olmadan Kubernetes kümeleri birer kara kutuya dönüşür; kümenin toplam maliyetini bilirsiniz, ancak hangi iş yüklerinin veya ekiplerin bunun hangi kısmından sorumlu olduğunu göremezsiniz. Bu belirsizlik, optimizasyonu çok daha zor hale getirir.

8. Ağ ve Veri Transferi: Görünmez Bütçe Kalemi

Ağ maliyetleri nadiren bulut optimizasyon öncelikleri listelerinde yer alır ve genellikle faturadaki en büyük kalem değildir. Ancak, uygulamalar ölçeklendikçe ve veri hacmi büyüdükçe, sıklıkla önemli ve yeterince takdir edilmeyen bir maliyet unsuruna dönüşürler.

Bir bölge içinde, AZ’ler arası trafiği dikkatlice düşünün. Çoğu bulut sağlayıcısı, aynı bölge içindeki kullanılabilirlik alanları (AZ) arasında aktarılan veri için ücret alır. Önemli miktarda servisler arası iletişim yapan mimarilerde (birbirini çağıran mikroservisler, önbellekten okuyan servisler, kuyruklardan veri tüketen işçiler), AZ’den AZ’ye veri transferi anlamlı bir maliyet haline gelebilir. Yoğun iletişim kuran servisleri aynı AZ’de konumlandırmak bir çözüm olabilir; yerel instance’ları tercih eden AZ-farkında yük dengeleme kullanmak ise bir diğeridir.

Temel ilke basittir: veri taşımak maliyetlidir. Veri ne kadar uzağa giderse ve ne kadar çok faturalandırma sınırını aşarsa, maliyeti o kadar artar. Veri yerelliği için tasarım yapmak, hesaplamayı veriye yakın tutmak, bölgeler arası iletişimi en aza indirmek ve gereksiz gidiş-dönüşleri önlemek hem iyi bir mimari hem de iyi bir ekonomidir.

Bir bölge içinde, AZ’ler arası trafiği dikkatlice düşünün. Çoğu bulut sağlayıcısı, aynı bölge içindeki kullanılabilirlik alanları (AZ) arasında aktarılan veri için ücret alır. Yoğun şekilde servisler arası iletişim yapan mimarilerde (birbirini çağıran mikroservisler, önbellekten okuyan servisler, kuyruklardan tüketen işçiler), AZ’den AZ’ye veri transferi anlamlı bir maliyet haline gelebilir. Yoğun iletişim kuran servisleri aynı AZ’de konumlandırmak bir çözüm olabilir; yerel örnekleri tercih eden AZ-farkındalıklı yük dengeleme kullanmak ise başka bir yöntemdir.

Kullanıcıya yönelik içerik için bir CDN kullanın. Statik varlıkları, görselleri ve önbelleğe alınmış yanıtları doğrudan nesne depolamadan veya orijin sunuculardan sunmak, bunları bir CDN kenarından sunmaktan çok daha pahalıya mal olur. CDN fiyatlandırması genellikle orijin çıkış fiyatlandırmasından çok daha düşüktür ve son kullanıcılar için gecikme iyileştirmesi de ücretsiz bir bonus olarak gelir. Bu, iyi bilinen bir en iyi uygulamadır; ancak bazen bir girişimin ilk zamanlarında önceliklendirilmez ve bir daha asla gözden geçirilmez.

VPC mimarinizi çıkış tuzakları açısından gözden geçirin. NAT Gateway maliyetleri yaygın bir sürprizdir. Özel bir alt ağdan internete giden her bir veri baytı bir NAT Gateway’den geçer ve bu hem saatlik hem de GB başına ücretlendirir. Eğer servisleriniz sık sık harici API çağrıları yapıyor, harici kaynaklardan büyük veri setleri işliyor veya derleme sırasında yoğun paket indirmeleri gerçekleştiriyorsa, NAT Gateway ücretleri hızla birikebilir. AWS servisleri için VPC uç noktaları (S3, DynamoDB ve diğerleri), trafiği AWS ağı içinde yönlendirir ve bu servisler için NAT Gateway ücretlerinden tamamen kaçınmanızı sağlar.

9. Kod Olarak Altyapı: Maliyet Disiplini Dağıtım Anında Başlar

Bulut maliyetlerini kontrol etmenin en etkili yollarından biri, maliyeti altyapı sağlanırken dikkate almak, aylar sonra yapılan bir denetim olarak bırakmamaktır. Kod olarak altyapı (IaC) araçları (Terraform, Pulumi, AWS CDK ve diğerleri) bunu mümkün kılan mekanizmadır.

Tüm altyapı kodla tanımlandığında ve standart bir pull request süreciyle incelendiğinde, maliyet etkileri kaynaklar oluşturulmadan önce görünür hale gelir. Bir inceleyici, yeni bir RDS örneği ekleyen bir Terraform değişikliğine bakıp şunu sorabilir: Bu gerçekten multi-AZ olmalı mı? Yedekleme saklama süresi nedir? Bu instance sınıfı beklenen yük için uygun mu? Bu tür konuşmalar inceleme aşamasında ucuzdur, sonradan ise pahalıya mal olur.

Politika yoluyla etiketlemeyi zorunlu kılın. OPA (Open Policy Agent), Sentinel veya bulut-yerel politika çerçeveleri (AWS Service Control Policies, GCP Organization Policies) gibi araçlar, gerekli maliyet tahsis etiketlerini içermeyen altyapı değişikliklerini reddedebilir. Bu, yeni kaynakların oluşturuldukları andan itibaren her zaman izlenebilir olmasını sağlar ve bireysel mühendislerin etiketleme şemasını hatırlamasına güvenilmesini ortadan kaldırır.

Yaygın kalıplar için modüller ve standartlar kullanın. Ekibinizin bir EC2 instance’ı veya bir RDS veritabanı oluşturmak için standart bir modülü olduğunda, bu modül maliyet açısından verimli varsayılanları kodlayabilir: uygun instance tipleri, doğru etiketleme, ilişkili depolama için yaşam döngüsü politikaları ve üretim dışı ortamlar için otomatik kapatma yapılandırması. Modülü kullanan mühendisler, bunları düşünmek zorunda kalmadan iyi varsayılanlara sahip olur.

Sapma tespiti uygulayın. Bulut konsolunda yapılan manuel değişiklikler, “Sadece hızlıca bir şey denemek için bunu başlatacağım” türündeki değişiklikler, unutulan kaynakların ve beklenmedik maliyetlerin en yaygın kaynakları arasındadır. Sapma tespit araçları, bulutta var olan ancak IaC kod tabanınızda olmayan kaynakları işaretler ve bu sayede aylarca fark edilmeden biriken geçici kaynakları bulup temizlemenizi mümkün kılar.

10. Maliyet Odaklı Bir Mühendislik Kültürü Oluşturmak

Bu rehberdeki tüm taktiksel öneriler, mühendislerin maliyeti birinci sınıf bir öncelik olarak düşündüğü bir organizasyonda uygulaması daha kolay ve kalıcıdır. Zaman içinde bulut maliyet disiplinini sürdüren ekipler, bunu üç ayda bir yapılan denetimlerle veya özel maliyet optimizasyon sprintleriyle başarmıyor. Maliyet farkındalığını, mühendislik işinin günlük olarak nasıl yapıldığının bir parçası haline getiriyorlar.

Bu, teknik olduğu kadar kültürel ve süreçle ilgili bir sorudur.

Görünürlük davranışı yönlendirir. Mühendisler göremedikleri şeyi optimize edemezler. Sadece CFO ve altyapı lideri için değil, herkesin erişebileceği maliyet panoları, tüm ekibe maliyet odaklı kararlar almaları için ihtiyaç duydukları bilgileri sunar. Yeni bir özellik geliştiren ekip, o özelliğin altyapı maliyetlerini gerçek zamanlı olarak görebildiğinde, maliyet tasarım seçimlerini değerlendirmenin doğal bir parçası haline gelir.

Maliyet panolarını, performans metriklerini paylaştığınız aynı kanallarda yayınlayın. Mühendislik genel toplantılarınıza maliyet verilerini dahil edin. Mimari tartışmalarda "bu ne kadar tutar?" diye sormayı, "bu nasıl ölçeklenir?" ya da "hata modları neler?" diye sormak kadar normal hale getirin.

Takımlara maliyetlerinin sahipliğini verin. Bu, maliyetleri takım veya ekip bazında etiketleme yapınızla ayırmak, her takıma bir bütçe ve pano vermek ve düzenli incelemelerde maliyet trendlerini açıklamaktan takımları sorumlu tutmak anlamına gelir. Sahiplik, hesap verebilirlik yaratır ve hesap verebilirlik davranışı değiştirir. Altyapı faturasındaki kendi kalemini gören takımlar, başkasının sorunu olan tek bir toplam sayı gören takımlardan farklı davranır.

Maliyeti mimari inceleme sürecinizin bir parçası haline getirin. Üretime alınacak önemli bir yeni servis veya altyapı değişikliğinden önce, incelemede bir maliyet tahmini ekleyin. Bu mevcut ölçekte ne kadar tutacak? Mevcut ölçeğin 10 katında ne kadar tutacak? Anlamlı şekilde daha ucuz olabilecek alternatif yaklaşımlar var mı? Bunun detaylı bir finansal model olması gerekmez, normal tasarım incelemesinin bir parçası olarak tartışılan kabaca bir büyüklük tahmini, bariz sorunları ortaya çıkarmak için yeterlidir.

Başarıları kutlayın. Bir mühendis bir israf kaynağını bulup ortadan kaldırdığında bunu görünür kılın. Bir takım, kaynakları doğru boyutlandırarak aylık altyapı maliyetlerini %20 azalttığında, bunu genel toplantıda belirtin. Maliyet optimizasyonu göz alıcı bir iş değildir ve biraz takdir, bunun tek seferlik bir girişim yerine sürdürülebilir bir uygulama olmasına büyük katkı sağlar.

Altyapı Disiplini Üzerine Bileşik Getiri

Bulut maliyeti optimizasyonunun dramatik bir getiri eğrisi yoktur; bu, bir şirketi tek bir çeyrekte dönüştüren türden bir çalışma değildir. Birikir. Altyapıyı nasıl sağladığınız, izlediğiniz ve yönettiğiniz konusunda yapılan küçük ve tutarlı iyileştirmeler zamanla birikerek, birim ekonominizi, nakit akışınızı ve daha az disiplinli rakiplerinizin göze alamayacağı riskleri alabilme yeteneğinizi etkileyen yapısal bir maliyet avantajına dönüşür.

Bunu erken dönemde ciddiye alan, görünürlüğü sağlayan, kültürü oluşturan ve altyapı harcamalarını sabit bir maliyet yerine stratejik bir kaldıraç olarak gören girişimler, bileşik bir avantaja sahip oluyor. Mühendisleri varsayılan olarak daha iyi kararlar alıyor. Mimarileri, maliyet bilinciyle evriliyor. Finans ekipleri her ay sonunda sürpriz yaşamıyor.

Temel bilgilerle başlayın: görünürlük, etiketleme, faturalandırma uyarıları ve en fazla fazla tahsis edilmiş instance’larınızı doğru boyutlandırma. Sabit bir temel oluşturduktan sonra rezerve kapasite taahhütlerini ekleyin. Disiplini kendi kendine sürdürebilir kılan kültürel alışkanlıkları, paylaşılan panoları, maliyet odaklı incelemeleri ve ekip sahipliğini oluşturun. Bunların hiçbiri karmaşık değil. Hepsi karşılığını verir.

Bulut faturası korkmanız gereken bir şey olmak zorunda değil. Doğru temellerle, bu fatura bir gösterge paneline dönüşür; ekibinizin ne kadar verimli çalıştığının ve altyapınızın ürününüze ne kadar etkili hizmet ettiğinin açık, okunabilir bir sinyali olur.