- 1. Faturanızı Optimize Etmeye Çalışmadan Önce Anlayın
- 2. Hesaplamalarınızı Doğru Boyutlandırın
- 3. Rezerve Kapasite ve Tasarruf Planları
- 4. Spot ve Öncelikli Olmayan Instancelar
- 5. Depolama: Yavaş Sızıntıdan Sel'e Dönüşen
- 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şturma
- Altyapı Disiplini Üzerine Birleşik Getiri
Ayın ilk günü, bir startup kurucusu veya mühendislik liderini vuran belirli bir korku türü vardır. Bulut faturası gelir, geçen aydan daha yüksektir ve ekipte kimse nedenini hemen açıklayamaz. Konsolu inceleyip, kalem kalem giderleri takip edersiniz ve sonunda birkaç suçlu bulursunuz; altı haftadır kimsenin dokunmadığı büyük bir instance, tam kapasite çalışan unutulmuş bir staging ortamı, son ürün değişikliğinden beri sorgulanmamış bir bucket'a çıktı döken bir veri pipeline'ı.
Bu nadir bir hikaye değil. Bu varsayılan hikaye. Bulut altyapısı sağlamak son derece kolay ve unutmak da son derece kolaydır. Faturalama modeli (kullandığınız kadar ödeyin, saniye başına faturalandırılır) adil görünür, ta ki "kullandığınız" her şeyin kapatmayı unuttuğunuz şeyleri de içerdiğini fark edene kadar.
Erken aşama startup'lar için bu, büyük şirketlere göre daha fazla önem taşır. Fortune 500 şirketi için ayda gereksiz $50,000 bulut harcaması bir verimsizliktir. Ancak bir Seri A startup'ı için bu, stratejik bir sorundur. Ne kadar süre çalışabileceğinizi, kimi işe alabileceğinizi ve hangi riskleri alabileceğinizi etkiler. Bulut maliyet disiplini, bir finans sorunu veya bir DevOps nişi değildir. Şirketi nasıl yöneteceğinizin merkezindedir.
İyi haber şu ki, bulut aşırı harcaması büyük ölçüde çözülmüş bir sorundur. Kalıplar iyi anlaşılmış, araçlar olgunlaşmış ve tasarruflar gerçek ve hızlıdır. Bu kılavuz, ilk günden itibaren yerinde olması gereken temel unsurlardan, yıllarca altyapı ekonominizi şekillendirecek mimari kararlara kadar her büyük kaldıraçtan geçer.
1. Faturanızı Optimize Etmeye Çalışmadan Önce Anlayın
Bu bariz görünüyor. Değil. Çoğu startup mühendislik ekibi, aylık toplam bulut harcamalarının kabaca farkındadır, nereden geldiği konusunda daha belirsiz bir fikre sahiptir ve hangi spesifik hizmetlerin, özelliklerin veya ortamların zaman içindeki maliyet eğilimlerinden sorumlu olduğuna dair neredeyse hiçbir fikre sahip değildir. Bu ihmal değil, kimse bu soruları yanıtlamak için altyapıyı açıkça kurmadığında varsayılan durumdur.
Bir şeyi optimize etmeden önce, görünürlük sağlamanız gerekir. Gerçek, ayrıntılı, ekip atfedilmiş 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 faturalama verilerinize akar. Etiketlemeye başladığınız anda, şu soruları yanıtlayabilirsiniz: veri pipeline'ı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 ekibin hizmetleri sorumlu?
Etiketler olmadan, tek bir sayıya bakıyorsunuz ve tahmin ediyorsunuz. Etiketlerle, gerçekten mantık yürütebileceğiniz yapılandırılmış bir veri kümeniz var. İlk günden itibaren bir etiketleme şeması kurun, ortam (prod, staging, dev), ekip veya takım, hizmet veya özellik ve maliyet merkezi en kullanışlı boyutlardır ve yeni kaynakların her zaman doğru şekilde etiketlenmesini sağlamak için kod olarak altyapınıza uygulayın.
Faturalama panoları ve anomali uyarıları ücretsiz sigortadır. Her bulut sağlayıcısı, ek bir ücret olmadan yerel maliyet yönetim 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ı ayarlayın. Herhangi bir hizmette harcama beklenmedik bir şekilde arttığında bildirim almanız için 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ününde keşfedilen bir sorundan çok daha az maliyetlidir.
İlk on kalem harcamanıza bakın 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 (egress) ve belki bir yönetilen konteyner hizmeti veya Kubernetes cluster'ı. Her birinin ne yaptığını, neden bu kadar maliyetli olduğunu ve makul bir temel çizginin neye benzediğini bilin. Diğer her şey bağlamdır.
2. Hesaplamalarınızı Doğru Boyutlandırın
Hesaplama neredeyse evrensel olarak en büyük kalemdir ve neredeyse evrensel olarak fazla sağlanmıştır. Bu, instance'ları boyutlandıran mühendislerin eleştirisi değil, belirsizlik altında altyapı kararları alan ekiplerin yapısal bir sonucudur.
Yeni bir hizmet başlatırken, tam olarak ne kadar trafik alacağını veya kaynak kullanım profilinin nasıl görüneceğini bilmiyorsunuz. Bu yüzden muhafazakar bir tahmin yapar ve bir tampon ekleyirsiniz. Bu mantıklıdır. Ancak bu tamponlar birikir. Bir düzine hizmet arasında, üç ortam arasında, iki yıllık organik büyüme boyunca, nadiren gördükleri bir yük için boyutlandırılmış bir instance filosu biriktirirsiniz.
Herhangi bir değişiklik yapmadan önce kullanım metriklerinizi çekin. Son 30 gün boyunca çalışan her instance için ortalama CPU ve bellek kullanımına bakın. Zirve değil, ortalama. Ortalama %8–12 CPU kullanımı ile çalışan ve %35 zirveye ulaşan bir instance, olduğu boyutta olmamalıdır. Çoğu bulut sağlayıcısı, maliyet konsollarında doğrudan doğru boyutlandırma önerileri sunar; bunları bir başlangıç noktası olarak alın, gerçek kullanım verilerinize karşı doğrulayın ve önerinin ötesine geçmeye istekli olun.
Üretim ve üretim dışı ortamlarınızı ayırın. Bu, çoğu startup'ın yapabileceği en yüksek kaldıraç değişikliklerinden biridir ve neredeyse hiç mimari çalışma gerektirmez. Geliştirme ve staging ortamlarının, üretim kapasitesinde 24 saat, haftanın yedi günü çalışmasına gerek yoktur. Mühendisler genellikle günde 10 saat, haftada 5 gün çalışır. Bu, üretim dışı altyapınızın yaklaşık %70 oranında boşta olduğu anlamına gelir.
Otomatik kapanma programları uygulayın. Akşamları üretim dışı instance'ları durdurmak ve sabahları yeniden başlatmak için bir Lambda işlevi, bir Cloud Scheduler işi veya basit bir cron tetiklemeli betik kullanın. Ortamlarınızı doğru şekilde etiketleyin, böylece bunu seçici olarak uygulayabilirsiniz. Sadece çalışma saatlerinde çalışan bir staging ortamı, 24/7 bir programda olacağının yaklaşık %30'u kadar maliyetlidir ve başlatma süresi kabul edilebilir (genellikle iki dakikadan az) ise geliştirici deneyimi etkisi minimumdur.
Özellikle geliştirme ortamları için, bireylerin sürekli bulut instance'larına ihtiyaç duyup duymadığını veya konteynerleştirilmiş yerel geliştirme kurulumlarının çoğu iş yükünü karşılayıp karşılayamayacağını düşünün. Birçok ekip, geliştirmeyi yerel Docker ortamlarına taşımanın ve bulut kaynaklarını yalnızca staging ve üretim için tutmanın, faturalarını anlamlı bir şekilde azalttığını ve verimliliği etkilemediğini bulur.
Instance aileleri, instance boyutlarından daha önemlidir. AWS, GCP ve Azure, eski nesillere göre daha iyi fiyat-performans sunan yeni instance ailelerini düzenli olarak piyasaya sürer. En son nesil hesaplama optimize edilmiş veya genel amaçlı instance'lar, önceki nesilden neredeyse her zaman daha ucuzdur, bazen %10–20 oranında. İki nesilden daha eski bir aileden instance'lar çalıştırıyorsanız, muhtemelen daha iyi bir seçenek vardır. Bunu en azından yıllık olarak gözden geçirin.
3. Rezerve Kapasite ve Tasarruf Planları: En Yüksek YG Kararı
Startup'ınız altı aydır veya daha uzun süredir faaliyet gösteriyorsa ve öngörülebilir gelecekte ihtiyaç duyacağı sabit bir hesaplama tabanına sahipse ve bu taban için talep üzerine fiyatlar ödüyorsanız, maliyetli bir hata yapıyorsunuz demektir. Bu bir uç durum değil. Startup bulut yönetiminde en yaygın ve en pahalı hatalardan biridir.
Talep üzerine fiyatlandırma, gerçekten öngörülemeyen iş yükleri için tasarlanmıştır. Kaynakları taahhüt etmeden yukarı ve aşağı döndürme esnekliği için bir prim ödersiniz. Bu prim, değişken, belirsiz iş yükleri için anlamlıdır. Geçen yıl boyunca değişmeden çalışan çekirdek altyapı için anlamlı değildir.
Rezerve instance'lar ve tasarruf planları, taahhüt süresi ve ödeme yapısına bağlı olarak, talep üzerine kıyasla hesaplama maliyetlerini %40–70 oranında azaltır. Peşin ödeme olmadan bir yıllık bir dönem, genellikle talep üzerine göre %30–40 daha ucuzdur. Kısmi veya tam peşin ödeme ile üç yıllık bir dönem, %60–70 tasarrufa ulaşabilir. EC2'de aylık $20,000 harcayan bir startup için, tabanı rezerve instance'lara taşımak, aylık $8,000–14,000 tasarruf sağlayabilir. Bu, yuvarlama hatası değildir.
Pratik yaklaşım: minimum taban hesaplamanızı, trafik veya yükten bağımsız olarak, sessiz bir Pazar günü sabah 3'te çalışan tabanı belirleyin. Bu taban, rezerve kapasite ile karşılanması gereken şeydir. Bunun üzerindeki her şey (patlamalar, trafik artışları, yeni özellik lansmanları) talep üzerine veya spot olarak kalır. Bu, taahhütlerin maliyet verimliliğini, değişken olan her şey için talep üzerine esnekliği ile birleştirir.
Taahhütlerinizi üç ayda bir gözden geçirin. Rezerve instance'lar ve tasarruf planları, ayarla ve unut türünde değildir. Ürün geliştikçe tabanınız değişecektir. Mevcut taahhütlerin kullanımını ve yeni taahhütler ekleme fırsatını her çeyrekte gözden geçirin. Biraz az taahhüt etmek ve tamamlamak, fazla taahhüt edip kullanılmayan rezerve kapasite bırakmaktan daha iyidir. Kullanılmayan rezervasyonlar, etkili bir şekilde boşa harcanan paradır.
Tasarruf planları vs. rezerve instance'lar: AWS tasarruf planları, geleneksel rezerve instance'lardan daha fazla esneklik sunar, belirli instance türü, bölge veya işletim sisteminden bağımsız olarak herhangi bir EC2 kullanımı için geçerlidir. Çoğu startup için, tasarruf planları yönetmesi daha kolaydır ve neredeyse maliyet açısından etkilidir. Altyapınız nispeten sabit ve iyi tanımlanmışsa, belirli instance türleri için rezerve instance'lar birkaç yüzde puanı daha fazla tasarruf sağlayabilir.
PlusClouds ve Bulut Maliyet Optimizasyonu:
Rezerve instance taahhütleri konusunda tahmin yürütmeyi bırakın.
PlusClouds, geçmiş kullanım kalıplarınızı analiz eder ve size tam olarak ne kadar rezerve kapasite almanız gerektiğini söyler — instance ailesi, bölge ve dönem uzunluğuna göre ayrılmış olarak. PlusClouds'un taahhüt önerilerini kullanan müşteriler, hesaplamada ortalama %41 tasarruf eder. AWS Rezerve Instance'lar, Azure Rezerve VM'ler ve GCP Taahhütlü Kullanım İndirimleri genelinde çalışır.
Nasıl çalıştığını görmek için plusclouds.com adresine bakın
4. Spot ve Öncelikli Olmayan Instancelar: Doğru İş Yükleri İçin %90 İndirimler
AWS'deki spot instance'lar ve GCP'deki öncelikli olmayan VM'ler, mevcut en güçlü maliyet azaltma araçlarından biridir ve startup'lar tarafından en az kullanılanlardan biridir. Bunun nedeni, risk algısı ve aşinalık eksikliğinin bir kombinasyonudur. Hangi iş yüklerinin uygun adaylar olduğunu anladığınızda, ekonomi neredeyse göz ardı edilemez hale gelir.
Spot instance'lar, bulut sağlayıcısının yedek kapasitesinde çalışır. Bu kapasite için teklif verirsiniz (veya modern AWS spot'ta, sadece mevcut spot fiyatında talep edersiniz) ve bulut sağlayıcısı geri ihtiyaç duyana kadar alırsınız, bu noktada sonlandırmadan önce iki dakikalık bir uyarı alırsınız. Bu rahatsızlık için indirim: talep üzerine fiyatların %90'ına kadar.
Kesintiye uğrayabilir veya yeniden başlatılabilir iş yükleri için bu, esasen bedava paradır. Spot instance'ların temiz bir şekilde çalıştığı kategoriler arasında CI/CD pipeline işçileri (bir derleme işi kesintiye uğrarsa, çalışan tekrar alır), toplu veri işleme ve ETL pipeline'ları (ilerlemenizi kontrol edin ve devam edin), makine öğrenimi eğitim işleri (çoğu çerçeve kontrol noktalarını destekler), gece analitiği veya rapor üretimi, yük testi ve bir instance'ın sonlandırılmasının diğerlerine trafik yönlendirerek zarif bir şekilde ele alındığı bir yük dengeleyici tarafından yönlendirilen herhangi bir durumsuz web hizmeti bulunur.
Spot'un uygun olmadığı iş yükleri: kesintiye tolerans gösteremeyen herhangi bir durumsal iş yükü, çoğu yapılandırmada veritabanları, sert gerçek zamanlı gecikme gereksinimleri olan hizmetler ve bir işlem ortasında bir hata durumunu bozacak veya sıfırdan tam bir yeniden başlatma gerektirecek herhangi bir iş yükü.
Karışık bir instance stratejisi en iyi sonucu verir. Kesintiye uğrayabilir her şey için spot, güvenilirliğe ihtiyaç duyan durumsuz hizmetler için talep üzerine ve sabit tabanınız için rezerve kullanın. Yalnızca spot instance'larda CI/CD çalıştırmak, yapım altyapı maliyetlerinizi %80 oranında azaltabilir ve minimal operasyonel karmaşıklıkla.
5. Depolama: Yavaş Sızıntıdan Sel'e Dönüşen
Depolama maliyetleri bireysel olarak küçük, toplu olarak ise devasa olabilir. Neredeyse her startup'ta ortaya çıkan desen aynıdır: veriler nesne depolamaya yazılır, kimse ne zaman çıkacağına karar vermek için bir süreç oluşturmaz ve 18 ay sonra, önceki ürün sürümünden beri erişilmemiş terabaytlarca veri için tam depolama ücretleri ödersiniz.
Nesne depolama fiyatlandırması ucuz görünür, S3 Standard'da GB-ay başına $0.023. Ancak ölçekle veya yeterince birikmiş veriyle birlikte, bu maliyetler artar. Daha da önemlisi, birçok startup verileri yanlış katmanda saklıyor: her şeyi Standard'da tutarken, çoğu nadiren veya hiç erişilmemiş çünkü kimse otomatik olarak taşınacak kuralları kurmamış.
Yaşam döngüsü politikaları isteğe bağlı değildir. Bir depolama bucket'ı oluşturduğunuzda yapılandırmanız gereken ilk şey olmalıdır, daha sonra ulaşacağınız bir optimizasyon değil. Nesnelere 30 veya 60 gün boyunca erişilmediğinde Infrequent Access depolamaya geçiş yapan, 90 veya 180 gün sonra Glacier veya Archive'a taşıyan ve tanımlanmış bir saklama süresi sonrasında silen kurallar tanımlayın. Günlük dosyaları için, saklama süresi genellikle 30–90 gündür. Yedeklemeler için, uyum gereksinimlerinize bağlıdır. Kullanımdan kaldırılmış özelliklerden gelen ham veriler için, cevap genellikle "6 ay sonra sil"dir.
Özel katman geçişleri ve zaman çizelgeleri sağlayıcıya ve kullanım durumuna göre değişiklik gösterecektir, ancak ilke evrenseldir: verilerin bir yaşam döngüsü vardır ve bunu kasıtlı olarak yönetmek, zamanla önemli ölçüde para tasarrufu sağlar.
Egress maliyetleri, bulutun en az tartışılan faturalama sürprizlerinden biridir. Bulut sağlayıcıları, ağlarından çıkan veriler için, internete, diğer bölgelere veya bazı durumlarda aynı hesap içindeki hizmetler arasında ücret alır. Bu ücretler gigabayt başına küçüktür ancak veri hacmiyle hızla ölçeklenir.
Yaygın egress tuzakları şunları içerir: işlemek için büyük veri kümelerini bölgeler arasında çeken mimariler (hesaplamayı veriye taşıyın), büyük dosyaları doğrudan nesne depolamadan son kullanıcılara bir CDN olmadan sunan uygulamalar ve gereksiz yere büyük yükleri hizmetler arasında geçiren mikro hizmet mimarileri. Önemli veri hareketi içeren bir mimariyi kabul etmeden önce, projeksiyon ölçeğinizde egress maliyetlerinin ne olacağını açıkça hesaplayın.
Depolamanızı düzenli olarak denetleyin. Depolama harcamanızı üç ayda bir gözden geçirmek için bir takvim hatırlatıcısı ayarlayın. Yaşam döngüsü politikası olmayan bucket'ları, kullanımdan kaldırılmış özellikler veya hizmetler için veri depolayan bucket'ları, bağlı olmayan EBS volume'ları (şaşırtıcı derecede yaygın bir israf kaynağı) ve saklama gereksinimlerinizin ötesinde birikmiş eski snapshot'ları arayın. Bu, cazip olmayan bir iş olabilir, ancak bir öğleden sonra yapılan bir temizlik, yıllarca devam eden tasarruflar sağlayabilir.
6. Yönetilen Veritabanları: Güçlü, Pahalı ve Sıkça Aşırı Sağlanmış
RDS, Cloud SQL ve Azure Database gibi yönetilen veritabanı hizmetleri, bulut sağlayıcılarının en değerli tekliflerinden biridir, yedeklemeler, yamalar, failover ve önemli operasyonel uzmanlık gerektirecek izlemeleri ele alırlar. Ayrıca, bir startup'ın bulut faturasındaki ikinci veya üçüncü en büyük kalemdir ve neredeyse her zaman gelecekteki bir iş yükü için boyutlandırılmıştır, mevcut olan için değil.
Çoklu AZ yüksek kullanılabilirlik RDS instance'ı, milyonlarca işlem yapan bir ürün için doğru cevaptır. Ancak $50K MRR'de 10,000 aktif kullanıcıya sahip bir startup için, bu önemli bir aşırı yatırımdır. Ödediğiniz özellikler (senkron replikasyon, otomatik failover, sağlanan throughput) değerlidir, ancak henüz ulaşmadığınız bir ölçekte ödüyorsunuz.
Veritabanı katmanınızı bugünkü gerçek gereksinimlerinize, 18 ay sonraki aspirasyonel gereksinimlerinize değil, eşleştirin. Her zaman ölçeklendirebilirsiniz; ölçeklendirme basittir ve çoğu yönetilen veritabanı hizmetinde minimum kesintiyle yapılabilir. Şu anda tek bir AZ instance veya daha küçük bir instance sınıfı çalıştırarak tasarruf ettiğiniz para, büyüme için gerçek paradır.
Sunucusuz veritabanı seçenekleri, erken aşama ürünler için düşük değerlendirilmektedir. Aurora Serverless v2, PlanetScale ve Firestore, gerçek yük temelinde hesaplama kapasitesini ölçeklendirir, boşta dönemlerde neredeyse sıfıra ölçeklenir. Geliştirme veritabanları, düşük trafikli dahili araçlar ve öngörülemeyen erişim kalıplarına sahip özellikler için, sunucusuz veritabanları, minimum kapasitede çalıştırılan sağlanmış instance'lara kıyasla maliyetleri önemli ölçüde azaltabilir.
Veritabanlarınızı ince tutun. Aktif uygulama kodu tarafından artık kullanılmayan tablolar, sütunlar ve dizinler için periyodik olarak şemanızı denetleyin. Gerçek zamanlı sorgular için artık gerekli olmadığında, tarihsel kayıtları daha ucuz depolamaya arşivleyin. Yumuşak silinmiş kayıtları bir programda temizleyin. Zirve eşzamanlı bağlantılar yerine tipik yük için sağlanmış bir veritabanı instance'ı boyutlandırmaktan kaçınmak için bağlantı havuzlaması uygulayın. Bunlar iyi mühendislik uygulamalarıdır ve aynı zamanda altyapı maliyetlerinizi de azaltır.
Community
Further questions? Ask our team
7. Kubernetes ve Konteynerler: Disiplin Gerektiren Güç
Kubernetes, birçok startup için varsayılan dağıtım platformu haline geldi ve iyi bir nedenle, ölçekli olarak konteynerleştirilmiş iş yüklerini güvenilir bir şekilde çalıştırmak için güçlü bir soyutlama sağlar. Aynı zamanda, ekipler hızlı hareket ederken ve kaynak tahsisine dikkat etmezken gözden kaçırılması kolay olan yeni bir maliyet yönetimi zorlukları seti getirir.
Her pod üzerinde kaynak istekleri ve sınırları isteğe bağlı değildir. Bir pod'un kaynak istekleri tanımlanmamışsa, Kubernetes zamanlayıcısının onu nereye yerleştireceğine karar verirken kullanabileceği hiçbir bilgi yoktur. Sonuç genellikle verimsiz bin-packing, nominal olarak "dolu" olan ancak önemli kullanılmayan kapasiteye sahip düğümler veya isteklerin gerçek kullanımı yansıtmadığı için gerçekten aşırı yüklenmiş düğümlerdir. Gözlemlenen kullanıma dayalı olarak CPU ve bellek isteklerini ayarlayın, tahminlere değil. Sınırlar belirleyin, böylece kontrolsüz süreçler komşularını etkilemez.
Ekosistemin sağladığı otomatik ölçeklendirme ilkel araçlarını kullanın. Yatay Pod Otomatik Ölçekleyici (HPA), CPU, bellek veya özel metriklere dayalı olarak pod replikalarının sayısını ölçeklendirir. Dikey Pod Otomatik Ölçekleyici (VPA), gözlemlenen kullanıma dayalı olarak kaynak isteklerini otomatik olarak ayarlar. Cluster Otomatik Ölçekleyici ve daha yeni Karpenter, bekleyen pod talebine dayalı olarak cluster'ınızdan düğümleri otomatik olarak ekler ve kaldırır. Birlikte, bu araçlar cluster kullanımını önemli ölçüde iyileştirebilir, ancak iyi çalışmaları için doğru kaynak istekleri gerektirirler, bu yüzden bu temel önemlidir.
Düğüm doğru boyutlandırması, pod doğru boyutlandırması kadar önemlidir. Kubernetes düğüm havuzunuz için seçtiğiniz instance türü, hem performansı hem de maliyeti etkiler. Mevcut düğüm türlerinizin gerçek iş yükü profilinize uyup uymadığını gözden geçirin: hesaplama ağırlıklı iş yükleri, hesaplama optimize edilmiş instance'lardan faydalanır, bellek ağırlıklı iş yükleri, bellek optimize edilmiş instance'lardan faydalanır. Genel amaçlı instance'lar kümesi, ağırlıklı olarak bellek bağımlı iş yükleri çalıştırıyorsa, hiç kullanılmayan CPU kapasitesi için ödeme yapıyorsunuz demektir.
Cluster maliyetinizi namespace, ekip veya uygulama bazında ayırın. Bu, ya bulut yerel maliyet tahsis yaklaşımı (düğümleri etiketleme ve iş yüklerine eşleme) ya da özel bir araç gerektirir. Bu görünürlük olmadan, Kubernetes cluster'ları kara kutulara dönüşür, cluster'ın ne kadar maliyetli olduğunu bilirsiniz, ancak hangi iş yüklerinin veya ekiplerin bunun hangi kısmından sorumlu olduğunu söyleyemezsiniz. Bu belirsizlik, optimizasyonu çok daha zor hale getirir.
8. Ağ ve Veri Transferi: Görünmez Bütçe Kalemi
Ağ maliyetleri, bulut optimizasyon öncelikleri listelerinde nadiren görünür ve nadiren faturadaki en büyük kalemdir. Ancak, uygulamalar ölçeklendikçe ve veri hacimleri büyüdükçe, genellikle maddi ve az değerlenen bir maliyet sürücüsüdür.
Bir bölge içinde, AZ'ler arası trafiği dikkatlice düşünün. Çoğu bulut sağlayıcısı, aynı bölgedeki kullanılabilirlik bölgeleri arasında aktarılan veriler için ücret alır. Önemli ölçüde hizmetler arası iletişim yapan mimariler için (birbirini arayan mikro hizmetler, önbelleklerden okuyan hizmetler, kuyruklardan tüketen işçiler), AZ'den AZ'ye veri transferi anlamlı bir maliyet haline gelebilir. Yoğun iletişim kuran hizmetleri aynı AZ'de birlikte yerleştirmek bir önlem olabilir; yerel instance'ları tercih etmek için AZ farkında yük dengeleme kullanmak başka bir önlemdir.
Temel ilke basittir: veri hareketi para harcar. Veri ne kadar uzağa giderse ve bir faturalama sınırını ne kadar çok geçerse, o kadar maliyetlidir. 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üşlerden kaçınmak 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ölgedeki kullanılabilirlik bölgeleri arasında aktarılan veriler için ücret alır. Önemli ölçüde hizmetler arası iletişim yapan mimariler için (birbirini arayan mikro hizmetler, önbelleklerden okuyan hizmetler, kuyruklardan tüketen işçiler), AZ'den AZ'ye veri transferi anlamlı bir maliyet haline gelebilir. Yoğun iletişim kuran hizmetleri aynı AZ'de birlikte yerleştirmek bir önlem olabilir; yerel instance'ları tercih etmek için AZ farkında yük dengeleme kullanmak başka bir önlemdir.
Kullanıcıya yönelik içerik için bir CDN kullanın. Statik varlıkları, resimleri ve önbelleğe alınmış yanıtları doğrudan nesne depolamadan veya kaynak sunuculardan sunmak, bunları bir CDN kenarından sunmaktan çok daha pahalıdır. CDN fiyatlandırması genellikle kaynak çıkış fiyatlandırmasından çok daha düşüktür ve son kullanıcılar için gecikme iyileştirmesi ücretsiz bir bonustur. Bu, bir startup'ın hayatının erken dönemlerinde öncelik verilmeyen ve sonra asla yeniden gözden geçirilmeyen iyi anlaşılan bir en iyi uygulamadır.
Egress tuzakları için VPC mimarinizi gözden geçirin. NAT Gateway maliyetleri yaygın bir sürprizdir. Özel bir subnet'ten internete giden her bayt trafik, hem saatlik hem de GB başına ücret alan bir NAT Gateway üzerinden geçer. Sık sık harici API çağrıları yapan hizmetleriniz, harici kaynaklardan büyük veri kümelerini işleyen veya derleme sırasında ağır paket indirmeleri yapan hizmetleriniz varsa, NAT Gateway ücretleri hızla birikebilir. AWS hizmetleri (S3, DynamoDB ve diğer birçokları) için VPC uç noktaları, bu hizmetler için NAT Gateway ücretlerinden tamamen kaçınarak trafiği AWS ağı içinde yönlendirir.
9. Kod Olarak Altyapı: Maliyet Disiplini Dağıtım Zamanında Başlar
Bulut maliyetlerini kontrol etmenin en etkili yollarından biri, maliyeti, kaynaklar oluşturulmadan önce görünür hale getiren bir mekanizma olan kod olarak altyapı (IaC) araçları (Terraform, Pulumi, AWS CDK ve diğerleri) aracılığıyla, altyapı sağlandığı anda bir değerlendirme konusu yapmaktır.
Tüm altyapı kodda tanımlandığında ve standart bir çekme isteği süreciyle gözden geçirildiğinde, maliyet etkileri kaynaklar oluşturulmadan önce görünür hale gelir. Bir gözden geçiren, yeni bir RDS instance ekleyen bir Terraform değişikliğine bakabilir ve şunu sorabilir: bu çoklu AZ olmalı mı? Yedekleme saklama süresi nedir? Bu instance sınıfı beklenen yük için uygun mu? Bu konuşmalar, gözden geçirme sırasında ucuzdur ve sonrasında pahalıdır.
Politika aracılığıyla etiketlemeyi zorlayın. OPA (Open Policy Agent), Sentinel veya bulut yerel politika çerçeveleri (AWS Hizmet Kontrol Politikaları, GCP Organizasyon Politikaları) gibi araçlar, gerekli maliyet tahsis etiketlerini içermeyen altyapı değişikliklerini reddedebilir. Bu, yeni kaynakların, etiketleme şemasını hatırlamaya bireysel mühendislerin güvenmeden, oluşturuldukları andan itibaren her zaman atfedilebilir olmasını sağlar.
Ortak 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 türleri, doğru etiketleme, ilişkili depolama için yaşam döngüsü politikaları ve üretim dışı ortamlar için otomatik kapanma yapılandırması. Modülü kullanan mühendisler, bunları düşünmeden iyi varsayılanlar alır.
Sapma tespiti uygulayın. Bulut konsolunda yapılan manuel değişiklikler, "Bir şeyi test etmek için hızlıca bunu döndüreceğim" türündeki değişiklikler, unutulmuş kaynakların ve beklenmedik maliyetlerin en yaygın kaynaklarından biridir. Sapma tespit araçları, bulutta var olan ancak IaC kod tabanınızda olmayan kaynakları işaretler, böylece aylarca fark edilmeden birikmeden önce ad-hoc kaynakları bulup temizlemenizi sağlar.
10. Maliyet Bilincine Sahip Bir Mühendislik Kültürü Oluşturma
Bu kılavuzdaki tüm taktiksel tavsiyeler, bir organizasyonda mühendislerin maliyeti birinci sınıf bir endişe olarak düşündüğü bir yerde daha kolay uygulanır ve daha olasıdır. Bulut maliyet disiplini sürdüren ekipler, bunu üç aylık denetimler veya özel maliyet optimizasyon sprintleri aracılığıyla yapmıyorlar. Maliyet farkındalığını, mühendislik işinin günlük olarak nasıl yapıldığına dahil etmişlerdir.
Bu, teknik olduğu kadar bir kültür ve süreç sorusudur.
Görünürlük davranışı yönlendirir. Mühendisler, göremedikleri şeyi optimize edemezler. CFO ve altyapı lideri değil, herkesin erişebileceği maliyet panoları, tüm ekibe maliyet bilinçli kararlar almak için ihtiyaç duydukları bilgiyi verir. Yeni bir özellik oluşturan 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.
Performans metriklerini paylaştığınız aynı kanallara maliyet panoları yayınlayın. Mühendislik tüm eller toplantılarınızda maliyet verilerini dahil edin. Mimari tartışmalarda "bu ne kadar maliyetli?" diye sormayı normal hale getirin, "bu nasıl ölçeklenecek?" veya "hata modları nelerdir?" diye sorduğunuz gibi.
Ekiplerin maliyetlerinden sorumlu olmasını sağlayın. Bu, maliyetleri ekip veya takım bazında etiketleme yapınızı kullanarak tahsis etmek, her ekibe bir bütçe ve bir pano vermek ve ekiplerin düzenli incelemelerde maliyet eğilimlerini açıklamalarını sağlamak anlamına gelir. Sahiplik, hesap verebilirlik yaratır ve hesap verebilirlik davranışı değiştirir. Kendi satır öğesini altyapı faturasına gören ekipler, başka birinin sorunu olan tek bir toplu sayı gören ekiplerden farklı davranır.
Maliyeti mimari inceleme sürecinizin bir parçası yapın. Herhangi bir önemli yeni hizmet veya altyapı değişikliği üretime gitmeden önce, incelemede bir maliyet tahmini dahil edin. Bu, mevcut ölçekte ne kadar maliyetli olacak? Mevcut ölçeğin 10 katında ne kadar maliyetli olacak? Anlamlı bir şekilde daha ucuz olacak alternatif yaklaşımlar var mı? Bu, ayrıntılı bir finansal model olmak zorunda değil, normal tasarım incelemesinin bir parçası olarak tartışılan kabaca bir büyüklük sırası tahmini, bariz sorunları yüzeye çı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 hale getirin. Bir ekip, doğru boyutlandırma yoluyla aylık altyapı maliyetlerini %20 oranında azalttığında, bunu tüm eller toplantısında belirtin. Maliyet optimizasyonu cazip olmayan bir iştir ve biraz tanıma, bunu bir kerelik bir girişim yerine sürdürüleb
