1. Faturanızı Optimize Etmeye Çalışmadan Önce Anlayın
2. Compute Kaynaklarınızı Doğru Boyutlandırın
3. Rezerve Kapasite ve Tasarruf Planları
4. Spot ve Preemptible Instances
5. Depolama: Yavaş Bir Sızıntıdan Taşkına
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ı Disiplininin Bileşik Getirisi

Ayın ilk günü bir startup kurucusunu veya mühendislik liderini saran belirli bir tür korku vardır. Bulut faturası gelir, geçen aydan daha yüksektir ve ekipte kimse nedenini hemen açıklayamaz. Konsola dalar, maliyet kalemlerini inceler ve sonunda birkaç suçlu bulursunuz; altı haftadır dokunulmamış büyük bir instance, tam kapasitede çalışan unutulmuş bir staging ortamı, son ürün değişikliğinden beri erişilmeyen bir bucket'a çıktı döken bir veri hattı.

Bu nadir bir hikaye değil. Bu standart hikaye. Bulut altyapısı sağlamak son derece kolaydır 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" şeyin kapatmayı unuttuğunuz her şeyi de kapsadığını fark edene kadar.

Yeni başlayan startup'lar için bu, büyük işletmelere göre daha önemlidir. Aylık 50.000 $ gereksiz bulut maliyetini absorbe eden bir Fortune 500 şirketi bir verimsizlikle karşı karşıyadır. Runway'ini tüketen bir Series A startup'ı için bu gerçek bir stratejik sorundur. Ne kadar süre çalışabileceğinizi, kimi işe alabileceğinizi ve hangi riskleri alabileceğinizi etkiler. Bulut maliyetleri disiplini bir finansal endişe veya bir DevOps nişi değildir. Şirketinizi nasıl yönettiğinizin temel bir parçasıdır.

İyi haber şu ki, bulut harcamaları büyük ölçüde çözülmüş bir sorundur. Kalıplar iyi anlaşılmıştır, araçlar olgunlaşmıştır ve tasarruflar gerçek ve hızlıdır. Bu kılavuz, ilk günden itibaren düzenlemeniz gereken temellerden, altyapınızın ekonomisini yıllarca belirleyecek mimari seçimlere kadar her önemli kaldıraç noktasını ele alır.

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ı hakkında genel bir fikre sahiptir, bu harcamaların nereden geldiği konusunda daha belirsiz bir fikre sahiptir ve zaman içindeki maliyet gelişmelerinden hangi belirli hizmetlerin, özelliklerin veya ortamların sorumlu olduğu konusunda neredeyse hiçbir fikre sahip değildir. Bu ihmal değildir, sadece kimsenin bu soruları yanıtlamak için altyapıyı açıkça kurmadığı durumlarda standarttır.

Bir şeyi optimize etmeden önce, içgörüye ihtiyacınız var. Gerçek, ayrıntılı, ekiplere atfedilen içgörü.

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 geri döner. Etiketlemeye başladığınızda, ş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 zirveden hangi ekip hizmetleri sorumludur?

Etiketler olmadan, tek bir sayıya bakar ve tahmin yürütürsünüz. Etiketlerle, gerçekten akıl yürütebileceğiniz yapılandırılmış bir veri kümesine sahipsiniz. İlk günden bir etiketleme şeması oluşturun: ortam (prod, staging, dev), ekip veya takım, hizmet veya işlev ve maliyet merkezi en kullanışlı boyutlardır ve bunu kod olarak altyapınıza dahil edin, böylece yeni kaynaklar her zaman doğru şekilde etiketlenir.

Faturalama panoları ve anomali uyarıları ücretsiz sigortadır. Her bulut sağlayıcısı ücretsiz, yerleşik 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ı ayarlayın. Bir hizmetin harcamaları beklenmedik şekilde arttığında bildirim alacak şekilde anomali tespiti yapılandırın. Bu araçlar size bir şeyin neden pahalı olduğunu söylemez, ancak ne zaman olduğunu bilmenizi sağlar—ve zamanlama son derece önemlidir. Ayın ikinci gününde keşfettiğiniz bir sorun, otuzuncu gününde fark ettiğiniz bir sorundan çok daha az maliyetlidir.

En yüksek on maliyet kaleminize bakın ve tek tek anlayın. Erken aşamadaki çoğu şirkette, dört ila altı hizmet toplam faturanın %80–90'ından sorumludur: EC2 veya benzeri bir compute hizmeti, RDS veya benzeri bir yönetilen veritabanı, S3 veya benzeri bir nesne depolama, veri transferi (egress) ve belki de bir yönetilen konteyner hizmeti veya Kubernetes cluster. Her birinin ne yaptığını, neden bu kadar maliyetli olduğunu ve makul bir başlangıç noktasının ne olduğunu bilin. Bunun dışındaki her şey bağlamdır.

2. Compute Kaynaklarınızı Doğru Boyutlandırın

Compute neredeyse her zaman en büyük maliyet kalemidir ve neredeyse her zaman fazla sağlanmıştır. Bu, instance'ları boyutlandıran mühendisler için bir eleştiri değil, ekiplerin belirsizlik altında altyapı kararları almasının yapısal bir sonucudur.

Yeni bir hizmet başlattığınızda, ne kadar trafik alacağını veya kaynak kullanımının ne olacağını tam olarak bilemezsiniz. Bu yüzden muhafazakar bir tahmin yapar ve bir tampon ekleriz. Bu mantıklıdır. Ancak bu tamponlar birikir. Bir düzine hizmet, üç ortam ve iki yıllık organik büyüme boyunca, nadiren karşılaştıkları bir yük için boyutlandırılmış bir dizi instance toplarsınız.

Değişiklik yapmadan önce kullanım istatistiklerinizi alın. Son 30 gün boyunca her çalışan instance'ın ortalama CPU ve bellek kullanımına bakın. Zirve değil, ortalama. Ortalama %8–12 CPU kullanan ve %35'e kadar zirve yapan bir instance, şu anki boyutunda olmak zorunda değildir. Çoğu bulut sağlayıcısı, maliyet konsollarında doğrudan optimizasyon önerileri sunar; bunları başlangıç noktası olarak kullanın, bunları gerçek kullanım verilerinizle karşılaştırın ve önerinin ötesine geçmeye hazır olun.

Üretim ve üretim dışı ortamlarınızı ayırın. Bu, çoğu startup'ın gerçekleştirebileceği en etkili değişikliklerden biridir ve neredeyse hiç mimari çalışma gerektirmez. Geliştirme ve staging ortamlarının 7/24 üretim kapasitesinde çalışması gerekmez. Mühendisler genellikle günde 10 saat, haftada 5 gün çalışır. Bu, üretim dışı altyapınızın zamanın yaklaşık %70'inde hiçbir şey yapmadığı anlamına gelir.

Otomatik kapatma programları uygulayın. Üretim dışı instance'ları akşamları kapatmak ve sabahları yeniden başlatmak için bir Lambda işlevi, bir Cloud Scheduler görevi veya basit bir cron tetikleyici betiği kullanın. Bu seçici olarak uygulamak için ortamlarınızı doğru şekilde etiketleyin. Sadece mesai saatlerinde çalışan bir staging ortamı, 7/24 bir programda çalışacak olanın yaklaşık %30'u kadar maliyetlidir ve başlatma süresi kabul edilebilir (genellikle iki dakikadan az) olduğunda geliştirici deneyimi üzerindeki etkisi minimumdur.

Geliştirme ortamları için, bireylerin kalıcı bulut instance'larına ihtiyaç duyup duymadıklarını veya konteynerleştirilmiş yerel geliştirme ortamlarının çoğu işi halledebileceğini özellikle 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 saklamanın, üretkenliği etkilemeden faturalarını önemli ölçüde azalttığını keşfeder.

Instance aileleri, instance boyutlarından daha önemlidir. AWS, GCP ve Azure, eski nesillere göre daha iyi fiyat-performans oranı sunan yeni instance ailelerini düzenli olarak piyasaya sürer. En yeni nesil compute-optimize edilmiş veya genel amaçlı instance'lar, önceki nesilden neredeyse her zaman daha ucuzdur, bazen %10–20. İki nesilden daha eski bir aileden instance'lar çalıştırıyorsanız, muhtemelen daha iyi bir seçenek vardır. Bunu en az yılda bir değerlendirin.

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

Startup'ınız altı aydan uzun süredir aktifse ve yakın gelecekte ihtiyaç duyacağınızı bildiğiniz istikrarlı bir compute temeline sahipseniz ve bu temel için on-demand oranlar ödüyorsanız, maliyetli bir hata yapıyorsunuz. Bu bir istisna değildir. Startup'larda bulut yönetimindeki en yaygın ve en maliyetli hatalardan biridir.

On-demand fiyatlar, gerçekten öngörülemeyen iş yükleri için tasarlanmıştır. Kaynakları taahhüt olmaksızın ölçeklendirme ve küçültme esnekliği için bir prim ödersiniz. Bu prim, değişken, belirsiz iş yükleri için mantıklıdır. Ancak, geçen yıl boyunca değişmeden çalışan çekirdek altyapı için mantıklı değildir.

Rezerve instance'lar ve tasarruf planları, süre ve ödeme yapısına bağlı olarak on-demand'e göre %40–70 oranında compute maliyetlerini azaltır. Bir yıl süreli peşin ödeme olmadan genellikle on-demand'e göre %30–40 daha ucuzdur. Üç yıl süreli kısmi veya tam peşin ödeme, %60–70'e kadar tasarruf sağlayabilir. EC2'ye aylık 20.000 $ harcayan bir startup için, temeli rezerve instance'lara taşımak, ayda 8.000–14.000 $ tasarruf sağlayabilir. Bu bir yuvarlama farkı değildir.

Pratik yaklaşım: minimum temel compute'unuzu, sessiz bir pazar günü sabah 3'te trafik veya yükten bağımsız olarak çalışan alt sınırınızı belirleyin. Bu alt sınırı rezerve kapasite ile kapsamalısınız. Bunun üzerindeki her şey (zirveler, trafik artışları, yeni özellik lansmanları) on-demand veya spot olarak kalır. Bu şekilde, değişken olan her şey için on-demand'in esnekliği ile taahhütlerin maliyet etkinliğini elde edersiniz.

Taahhütlerinizi her çeyrekte değerlendirin. Rezerve instance'lar ve tasarruf planları set-and-forget değildir. Ürünün evrimiyle birlikte temeliniz değişir. Her çeyrekte mevcut taahhütlerin kullanımını ve yenilerini ekleme olasılığını değerlendirin. Biraz az taahhüt etmek ve doldurmak, çok fazla taahhüt etmek ve rezerve kapasiteyi kullanılmadan bırakmaktan daha iyidir. Kullanılmayan rezervasyonlar aslında boşa harcanan paradır.

Tasarruf planları vs. rezerve instance'lar: AWS tasarruf planları, geleneksel rezerve instance'lardan daha fazla esneklik sunar; belirli bir instance türü, bölge veya işletim sistemi ne olursa olsun, bir aile içindeki herhangi bir EC2 kullanımına uygulanır. Çoğu startup için tasarruf planları yönetimi daha kolaydır ve neredeyse aynı derecede maliyet etkilidir. Altyapınız nispeten istikrarlı ve iyi tanımlanmışsa, belirli instance türleri için rezerve instance'lar birkaç ekstra yüzde tasarruf sağlayabilir.

PlusClouds ve Bulut Maliyet Optimizasyonu:

Rezerve instance taahhütleri üzerine kumar oynamayı bırakın.

PlusClouds, geçmiş kullanım kalıplarınızı analiz eder ve size tam olarak ne kadar rezerve kapasite satın almanız gerektiğini söyler — instance ailesi, bölge ve süreye göre ayrılmış olarak. PlusClouds'un taahhüt önerilerini kullanan müşteriler, compute üzerinde ortalama %41 tasarruf eder. AWS Reserved Instances, Azure Reserved VMs ve GCP Committed Use Discounts ile çalışır.

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

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

AWS'deki spot instances ve GCP'deki preemptible VM'ler, mevcut en güçlü maliyet tasarruf araçlarından biridir, ancak startup'lar tarafından en az kullanılanlardır. Bunun nedeni, risk algısı ve bilinmezliğin bir kombinasyonudur. Hangi iş yüklerinin uygun adaylar olduğunu anladığınızda, ekonomik faydalar neredeyse göz ardı edilemez hale gelir.

Spot instances, bulut sağlayıcısının fazla kapasitesinde çalışır. Bu kapasiteye teklif verirsiniz (veya modern AWS spot'ta, sadece mevcut spot fiyatına istersiniz) ve bulut sağlayıcısı kapasiteye tekrar ihtiyaç duyana kadar alırsınız. O anda, instance'ın sonlandırılmasından iki dakika önce bir uyarı alırsınız. Bu rahatsızlık için indirim: on-demand oranlara göre %90'a kadar indirim.

Kesintiye uğrayabilen veya yeniden başlatılabilen iş yükleri için bu aslında bedava paradır. Spot instances'ın iyi çalıştığı kategoriler arasında CI/CD pipeline işçileri (bir build görevi kesintiye uğrarsa, runner bunu tekrar alır), batch veri işleme ve ETL hatları (ilerlemenizi kaydedin ve devam edin), makine öğrenimi eğitim görevleri (çoğu framework kontrol noktalarını destekler), gece analizleri veya rapor oluşturma, yük testi ve bir load balancer tarafından yönlendirilen herhangi bir stateless web hizmeti bulunur, burada bir instance'ın sonlandırılması, trafiği diğer instance'lara yönlendirerek sorunsuz bir şekilde ele alınır.

Spot'un uygun olmadığı iş yükleri: stateful olan ve kesintiyi tolere etmeyen her şey, çoğu yapılandırmada veritabanları, katı gerçek zamanlı gecikme gereksinimleri olan hizmetler ve bir kesintinin ortasında durumun bozulacağı veya sıfırdan tam bir yeniden başlatma gerektireceği her iş yükü.

Birleşik bir instance stratejisi en iyi şekilde çalışır. Kesintiye uğrayabilen her şey için spot kullanın, güvenilirlik gerektiren stateless hizmetler için on-demand ve istikrarlı temeliniz için reserved kullanın. Yalnızca CI/CD'yi spot instances üzerinde çalıştırmak, build altyapısı maliyetlerinizi %80 oranında azaltabilir ve operasyonel karmaşıklığı minimumda tutar.

5. Depolama: Yavaş Bir Sızıntıdan Taşkına

Depolama maliyetleri bireysel olarak küçük, ancak toplu olarak büyüktür. Neredeyse her startup'ta aynı model ortaya çıkar: veriler nesne depolamada saklanır, ne zaman silineceğini belirlemek için kimse bir süreç oluşturmaz ve 18 ay sonra, önceki bir ürün sürümünden beri erişilmeyen terabaytlarca veri için tam depolama ücreti ödersiniz.

Nesne depolama, S3 Standard'da GB başına aylık 0,023 $ gibi ucuz fiyatlandırılır. Ancak ölçekle veya yeterince birikmiş veriyle hızla artar. Daha da önemlisi, birçok startup verileri yanlış katmanda saklar: her şey Standard'da kalır, çünkü kimse bunu otomatik olarak taşımak için kuralları ayarlamamıştır.

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 geleceğiniz bir optimizasyon değil. 30 veya 60 gün boyunca erişilmeden kalan nesneleri Infrequent Access depolamaya taşıyan, 90 veya 180 gün sonra Glacier veya Archive'a taşıyan ve tanımlanmış bir saklama süresinden sonra silen kurallar tanımlayın. Günlük dosyaları için saklama süresi genellikle 30–90 gündür. Yedeklemeler için, uyumluluk gereksinimlerinize bağlıdır. Kullanımdan kaldırılmış işlevlerin ham verileri için cevap genellikle "6 ay sonra sil"dir.

Katmanlar arasındaki belirli geçişler ve zaman çizelgeleri sağlayıcıya ve kullanım durumuna göre farklılık gösterir, ancak ilke evrenseldir: verilerin bir yaşam döngüsü vardır ve bunu bilinçli bir şekilde yönetmek uzun vadede önemli ölçüde para tasarrufu sağlar.

Egress maliyetleri, bulut faturasındaki en az tartışılan sürprizlerden biridir. Bulut sağlayıcıları, ağlarını terk eden, diğer bölgelere veya bazı durumlarda aynı hesap içindeki hizmetler arasında veri için ücret alır. Bu maliyetler GB başına küçüktür, ancak veri hacmiyle hızla ölçeklenir.

Yaygın egress tuzakları arasında: işlemek için büyük veri kümelerini bölgeler arasında taşıyan mimariler (bunun yerine compute'u veriye taşıyın), büyük dosyaları doğrudan nesne depolamadan son kullanıcılara sunan uygulamalar bir CDN olmadan ve mikro hizmet mimarileri arasında gereksiz büyük yükleri ileten uygulamalar bulunur. Önemli veri hareketi içeren bir mimariyi kabul etmeden önce, beklenen ölçeğinizde egress maliyetlerinin ne olacağını açıkça hesaplayın.

Depolamanızı düzenli olarak kontrol edin. Her çeyrekte depolama harcamalarınızı kontrol etmek için takviminize bir hatırlatıcı ayarlayın. Yaşam döngüsü politikası olmayan bucket'ları, eski işlevler veya hizmetler için veri içeren bucket'ları, bağlı olmayan EBS hacimlerini (şaşırtıcı derecede yaygın bir israf kaynağı) ve saklama politikanızın dışında birikmiş eski snapshot'ları arayın. Bu, çekici bir iş değildir, ancak bir öğleden sonra temizlik yapmak, yıllarca sürecek tasarruflar sağlayabilir.

6. Yönetilen Veritabanları: Güçlü, Pahalı ve Genellikle Fazla 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 izleme gibi önemli operasyonel uzmanlık gerektiren işleri hallederler. Ancak, aynı zamanda genellikle bir startup'ın bulut faturasındaki ikinci veya üçüncü en büyük bileşendir ve neredeyse her zaman mevcut iş yükü yerine gelecekteki bir iş yükü için yapılandırılmıştır.

Çoklu AZ, yüksek kullanılabilirlik RDS instance'ı, okuma replikaları ve 500GB sağlanmış IOPS, günde milyonlarca işlem işleyen bir ürün için doğru seçimdir. 50K $ MRR ve 10.000 aktif kullanıcıya sahip bir startup için bu önemli bir fazla yatırımdır. Ödediğiniz özellikler (senkron replikasyon, otomatik failover, garanti edilen throughput) değerlidir, ancak henüz ulaşmadığınız bir ölçekte ödüyorsunuz.

Veritabanı katmanınızı bugünkü gerçek ihtiyaçlarınıza göre ayarlayın, 18 ay sonraki hırslı isteklerinize değil. Her zaman ölçeklendirebilirsiniz; ölçeklendirme kolaydır ve çoğu yönetilen veritabanı hizmetinde minimum kesinti ile yapılabilir. Şu anda tek AZ instance veya daha küçük bir instance sınıfı çalıştırarak tasarruf ettiğiniz para, büyüme için kullanabileceğiniz gerçek paradır.

Sunucusuz veritabanı seçenekleri, erken aşama ürünler için hafife alınır. Aurora Serverless v2, PlanetScale ve Firestore, gerçek yük temelinde compute'u ölçeklendirir, idle dönemlerde neredeyse sıfıra kadar küçülür. Geliştirme veritabanları, düşük trafiğe sahip iç araçlar ve tahmin edilemeyen erişim kalıplarına sahip özellikler için sunucusuz veritabanları, yük ne olursa olsun minimum kapasitede çalışan 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ı kontrol edin. Gerçek zamanlı sorgular için artık gerekli olmadığında tarihi kayıtları daha ucuz depolamaya arşivleyin. Yumuşak silinmiş kayıtları bir programa göre temizleyin. Bağlantı havuzlamayı uygulayın, böylece veritabanı instance'ınızı, zirve eşzamanlı bağlantı sayısına göre değil, normal yük temelinde sağlamak zorunda kalmazsınız. 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 dağıtım için standart platform haline geldi ve bu boşuna değil: konteynerleştirilmiş iş yüklerini ölçekli olarak güvenilir bir şekilde çalıştırmak için güçlü bir soyutlama sunar. Ancak, aynı zamanda, kaynak tahsisine dikkat etmeyen ekipler hızlı hareket ederken kolayca gözden kaçan yeni bir maliyet yönetimi zorlukları seti de sunar.

Her pod üzerinde kaynak talepleri ve sınırları isteğe bağlı değildir. Bir pod'un tanımlanmış kaynak talepleri yoksa, Kubernetes scheduler'ı bunu nereye yerleştireceğini belirlemek için bilgiye sahip değildir. Sonuç genellikle verimsiz bin-packing, nominal olarak "dolu" olan ancak hala çok fazla kullanılmayan kapasiteye sahip düğümler veya taleplerin 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 talepleri ayarlayın, tahminlere değil. Sınırlar belirleyin, böylece kontrolden çıkan süreçler komşularını etkilemez.

Ekosistemin sunduğu otomatik ölçeklendirme ilkeliklerini kullanın. Horizontal Pod Autoscaler (HPA), CPU, bellek veya özel metriklere dayalı olarak pod replikalarının sayısını ölçeklendirir. Vertical Pod Autoscaler (VPA), gözlemlenen kullanıma dayalı olarak kaynak taleplerini otomatik olarak ayarlar. Cluster Autoscaler ve daha yeni Karpenter, bekleyen pod taleplerine dayalı olarak cluster'a otomatik olarak düğümler ekler veya çıkarır. Bu araçlar birlikte cluster kullanımını önemli ölçüde iyileştirebilir, ancak doğru kaynak taleplerine ihtiyaç duyarlar, bu yüzden bu temel çok önemlidir.

Düğümleri doğru boyutlandırmak, pod'ları doğru boyutlandırmak kadar önemlidir. Kubernetes düğüm havuzunuz için seçtiğiniz instance türü, hem performansı hem de maliyetleri etkiler. Mevcut düğüm türlerinizin gerçek iş yükü profiliyle eşleşip eşleşmediğini kontrol edin: compute yoğun iş yükleri, compute optimize edilmiş instance'lardan, bellek yoğun iş yükleri, bellek optimize edilmiş instance'lardan faydalanır. Genel instance'lardan oluşan bir cluster, ağırlıklı olarak bellek yoğun iş yükleri çalıştırıyorsa, kullanılmayan CPU kapasitesi için ödeme yapar.

Cluster maliyetlerinizi namespace, ekip veya uygulama bazında ayırın. Bu, bulut yerel maliyet tahsisi yaklaşımı (düğümleri etiketleme ve iş yükleriyle ilişkilendirme) veya özel bir araç gerektirir. Bu içgörü olmadan, Kubernetes cluster'ları kara kutular haline gelir: cluster'ın ne kadar maliyetli olduğunu bilirsiniz, ancak hangi iş yüklerinin veya ekiplerin 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 optimizasyonu öncelikleri listelerinde yer alı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 düşük değer verilen bir maliyet faktörüdür.

Bir bölge içinde AZ'ler arası trafiği iyi düşünün. Çoğu bulut sağlayıcısı, aynı bölgedeki availability zones arasında aktarılan veri için ücret alır. Çok fazla hizmetler arası iletişim yapan mimariler için (birbirini çağıran mikro hizmetler, önbelleklerden okuyan hizmetler, kuyruklardan tüketen işçiler), AZ'den AZ'ye veri transferi önemli bir maliyet kalemi haline gelebilir. Birbirleriyle sıkça iletişim kuran hizmetleri aynı AZ'de birlikte yerleştirmek bir çözümdür; yerel instance'ları tercih etmek için AZ bilinçli yük dengeleme kullanmak başka bir çözümdür.

Temel ilke basittir: veri trafiği maliyetlidir. Veri ne kadar uzağa giderse ve bir faturalama sınırını ne kadar sık aşarsa, o kadar pahalı hale gelir. Veri yerelliği için tasarlamak, compute'u veriye yakın tutmak, bölgeler arası iletişimi en aza indirmek ve gereksiz round-trip'lerden kaçınmak hem iyi bir mimari hem de ekonomi için iyidir.

Kullanıcılar tarafından görüntülenen 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-edge'den sunmaktan çok daha pahalıdır. CDN fiyatları genellikle kaynak çıkış maliyetlerinden çok daha düşüktür ve son kullanıcılar için daha düşük gecikme süresi ücretsiz bir bonustur. Bu, bazen bir startup'ın erken aşamasında göz ardı edilen ve daha sonra asla yeniden gözden geçirilmeyen bilinen bir en iyi uygulamadır.

VPC mimarinizi çıkış tuzakları için gözden geçirin. NAT Gateway maliyetleri yaygın bir sürprizdir. Özel bir subnet'ten internete giden her bayt, hem saatlik hem de GB başına maliyetler hesaplayan bir NAT Gateway üzerinden geçer. Sık sık harici API çağrıları yapan, harici kaynaklardan büyük veri kümelerini işleyen veya build sırasında ağır paket indirmeleri yapan hizmetleriniz varsa, NAT Gateway maliyetleri hızla artabilir. AWS hizmetleri için VPC uç noktaları (S3, DynamoDB ve diğer birçokları), trafiği AWS ağı içinde yönlendirir, böylece bu hizmetler için tamamen NAT Gateway maliyetlerinden kaçınırsınız.

9. Kod Olarak Altyapı: Maliyet Kontrolü Dağıtımda Başlar

Bulut maliyetlerini kontrol etmenin en etkili yollarından biri, kaynaklar oluşturulmadan önce maliyetleri doğrudan dağıtım anında dikkate almaktır, aylar sonra bir denetimde değil. Kod olarak altyapı (IaC) araçları (Terraform, Pulumi, AWS CDK ve diğerleri) bunu mümkün kılar.

Tüm altyapı kodda kaydedildiğinde ve standart bir pull request süreci aracılığıyla incelendiğinde, maliyet etkileri kaynaklar oluşturulmadan önce görünür hale gelir. Bir inceleyici, yeni bir RDS instance ekleyen bir Terraform değişikliğine bakabilir ve şunu sorabilir: bu multi-AZ olmalı mı? Yedekleme saklama süresi nedir? Bu instance sınıfı beklenen yük için uygun mu? Bu konuşmalar inceleme sırasında ucuzdur ve sonradan pahalıdır.

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şturulduğu andan itibaren her zaman tahsis edilebilir olmasını sağlar ve bireysel mühendislerin etiketleme şemasını hatırlamalarına güvenmez.

Yaygın desenler 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 etkin varsayılan değerler içerebilir: uygun instance türleri, doğru etiketleme, bağlı 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, düşünmeden iyi varsayılan ayarlar alır.

Sürüklenme tespiti uygulayın. Bulut konsolunda yapılan manuel değişiklikler, "bunu test etmek için hızlıca başlatıyorum" türü değişiklikler, unutulmuş kaynakların ve beklenmedik maliyetlerin en yaygın kaynaklarından biridir. Sürüklenme tespit araçları, bulutta var olan ancak IaC kod tabanınızda olmayan kaynakları işaretler, böylece ad-hoc kaynakları bulup temizlemenizi sağlar, aylarca fark edilmeden kalmadan önce.

10. Maliyet Bilincine Sahip Bir Mühendislik Kültürü Oluşturma

Bu kılavuzdaki tüm taktiksel tavsiyeler, bir organizasyonda mühendislerin maliyetleri birincil bir endişe olarak gördüğü bir ortamda daha kolay uygulanır ve daha iyi kalıcı olur. Bulut maliyet disiplini uzun vadede sürdüren ekipler, bunu çeyrek incelemeleri veya özel maliyet optimizasyonu sprintleri aracılığıyla yapmazlar. Maliyet bilincini günlük mühendislik işinin bir parçası haline getirmiş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ı sorumlusunun yanı sıra herkesin erişebileceği maliyet panoları, tüm ekibe maliyet bilincine sahip kararlar almak için ihtiyaç duydukları bilgiyi verir. Yeni bir özellik inşa eden ekip, o özelliğin altyapı maliyetlerini gerçek zamanlı olarak görebildiğinde, maliyet etkinliği, tasarım seçimlerini değerlendirirken doğal bir parça haline gelir.

Maliyet panolarını performans metriklerini paylaştığınız aynı kanallarda yayınlayın. Maliyet verilerini mühendislik toplantılarınıza dahil edin. "Bu ne kadar maliyetli?" diye sormayı normal hale getirin. mimari tartışmalarda, "bu nasıl ölçeklenir?" veya "hata modları nelerdir?" gibi sorular sorduğunuz gibi.

Ekiplerin maliyetleri üzerinde sahiplik kazanmalarını sağlayın. Bu, etiketleme yapınızı kullanarak maliyetleri ekip veya takım başına tahsis etmek, her ekibe bir bütçe ve bir pano vermek ve ekipleri düzenli incelemelerde maliyet trendlerini açıklamaktan sorumlu tutmak anlamına gelir. Sahiplik, sorumluluk yaratır ve sorumluluk davranışı değiştirir. Altyapı faturasındaki kendi satırlarını gören ekipler, sadece başkasının sorunu olan bir toplam sayı gören ekiplerden farklı davranır.

Maliyetleri mimari inceleme sürecinizin bir parçası yapın. Önemli bir yeni hizmet veya altyapı değişikliği üretime geçmeden önce, incelemede bir maliyet tahmini ekleyin. Bu, mevcut ölçekte ne kadar maliyetli? Mevcut ölçeğin 10 katında ne kadar maliyetli? Önemli ölçüde daha ucuz olabilecek alternatif yaklaşımlar var mı? Bu, ayrıntılı bir finansal model olmak zorunda değildir; normal tasarım incelemesinin bir parçası olarak tartışılan bir büyüklük sırası tahmini, bariz sorunları ortaya çıkarmak için yeterlidir.

Başarıları kutlayın. Bir mühendis bir israf kaynağı bulup ortadan kaldırdığında, bunu görünür hale getirin. Bir ekip, doğru boyutlandırma yaparak aylık altyapı maliyetlerini %20 oranında azalttığında, bunu toplantılarda belirtin. Maliyet optimizasyonu çekici bir iş değildir ve biraz tanıma, bunu bir kerelik bir girişim yerine kalıcı bir uygulama haline getirmeye büyük ölçüde yardımcı olur.

Altyapı Disiplininin Bileşik Getirisi

Bulut maliyet optimizasyonu dramatik bir getiri eğrisi sunmaz; bir şirketi bir çeyrekte dönüştüren türden bir iş değildir. Birikir. Altyapınızı nasıl yapılandırdığınız, izlediğiniz ve yönettiğiniz konusundaki küçük, tutarlı iyileştirmeler, zamanla, birim maliyetlerinizi, finansal hareket alanınızı ve daha az disiplinli rakiplerinizin göze alamayacağı riskleri

Bulut maliyet optimizasyonu: Startuplar için pratik bir kılavuz