- 1. Faturanızı Anlamadan İyileştirmeye Çalışmayın
- 2. Hesaplama Kaynaklarını Doğru Boyutlandırma
- 3. Rezerve Kapasite ve Tasarruf Planları
- 4. Spot Instances ve İptal Edilebilir Kaynaklar
- 5. Depolama: Yavaş Sızıntıdan Sel Baskınına
- 6. Yönetilen Veritabanları
- 7. Kubernetes ve Konteynerler
- 8. Ağ ve Veri Aktarımı
- 9. Kod Olarak Altyapı
- 10. Maliyet Bilincine Sahip Mühendislik Kültürü Oluşturma
- Altyapı Disiplininde Birikimli Getiri
Her ayın ilk günü, bir girişim kurucusu veya mühendislik liderini özel bir endişe türü sarar. Bulut faturası gelir ve geçen aydan daha yüksektir, ve ekipte kimse hemen nedenini açıklayamaz. Konsolda gezinmeye başlarsınız, fatura kalemlerini takip edersiniz ve sonunda bir dizi neden bulursunuz; altı haftadır kimsenin dokunmadığı büyük boyutlu bir instance, unutulmuş bir test ortamı tam kapasitede çalışıyor, veri hattı çıktıları en son ürün değişikliğinden beri sorgulanmayan bir bucket'a boşaltılıyor.
Bu nadir bir hikaye değil. Bu varsayılan hikaye. Bulut altyapısı sağlamak çok kolay ve unutmak da bir o kadar kolay. Faturalama modeli (kullandıkça öde, saniye bazında ücretlendirme) adil görünüyor, ta ki "kullandığınız" her şeyin kapatmayı unuttuğunuz şeyleri içerdiğini fark edene kadar.
Erken aşama girişimler için bu, büyük kuruluşlara göre daha önemlidir. Fortune 500 şirketi için aylık 50.000 dolarlık gereksiz bulut harcaması sadece bir verimsizliktir. Ancak hızla tasarruflarını tüketen bir Seri A aşamasındaki girişim için bu stratejik bir sorundur. Çalışma sürenizi, kimi işe alabileceğinizi ve hangi riskleri alabileceğinizi etkiler. Bulut maliyet disiplini sadece bir finansal mesele veya DevOps uzmanlığı değildir. Şirket yönetiminin temel bir parçasıdır.
İyi haber, bulut aşırı harcama sorununun büyük ölçüde çözülmüş bir sorun haline gelmiş olmasıdır. 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 hazır olması gereken temel bilgilerden başlayarak, altyapınızın ekonomilerini yıllar boyunca belirleyecek mimari kararlara kadar her ana kaldıraç noktasını kapsar.
1. Faturanızı Anlamadan İyileştirmeye Çalışmayın
Bu sezgisel görünebilir. Ancak öyle değil. Çoğu girişim mühendislik ekibi, aylık bulut harcamalarının toplamı hakkında kabaca bir fikre sahiptir, bu harcamanın kaynağı hakkında daha belirsiz bir fikre sahiptir ve zamanla maliyet eğilimlerinden sorumlu olan belirli hizmetler, özellikler veya ortamlar hakkında neredeyse hiç fikre sahip değildir. Bu bir ihmal değil, bu sorulara açıkça yanıt verecek altyapıyı kimsenin kurmadığı varsayılan durumdur.
Bir şeyi iyileştirmeden önce, görmeniz gerekir. Gerçek, doğru ve her takıma atfedilebilen bir görüş.
Maliyet etiketleri temeldir. Her büyük bulut sağlayıcısı, kaynaklara rastgele anahtar-değer çiftleriyle etiketleme desteği sunar ve bu etiketler fatura verilerinize yansır. Etiketlemeye başladığınızda, şu soruları yanıtlayabilirsiniz: Veri hattımızın aylık maliyeti nedir? Test ortamımızın çalıştırılma maliyeti nedir? Geçen salı gördüğümüz artıştan hangi hizmetler sorumluydu?
Etiketler olmadan, tek bir sayıya bakıp tahmin yürütüyorsunuz. Etiketlerle, gerçekten çıkarım yapabileceğiniz yapılandırılmış bir veri kümeniz olur. İlk günden itibaren bir etiketleme planı oluşturun, ortam (üretim, test, geliştirme), takım veya grup, hizmet veya özellik ve maliyet merkezi en faydalı boyutlardır ve bunları kod olarak altyapıya uygulayın, böylece yeni kaynaklar her zaman doğru şekilde etiketlenir.
Fatura panoları ve anomali uyarıları ücretsiz sigortadır. Her bulut hizmeti 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. Beklenmedik bir şekilde herhangi bir hizmette harcamalar arttığında bilgilendirilmeniz için anomali tespiti yapılandırın. Bu araçlar size maliyetin neden arttığını söylemez, ancak bunun ne zaman olduğunu bilmenizi sağlar ve zamanlama çok önemlidir. Ayın ikinci gününde tespit edilen bir sorun, otuzuncu gününde tespit edilenden çok daha az maliyetlidir.
Faturanızdaki en önemli on kaleme bakın ve her birini anlayın. Çoğu girişimde, dört ila altı hizmet toplam faturanın %80-90'ını oluşturur: EC2 veya eşdeğeri hesaplama hizmetleri, RDS veya eşdeğeri yönetilen veritabanları, S3 veya eşdeğeri nesne depolama, veri aktarımı (çıkış) ve muhtemelen yönetilen konteyner hizmeti veya Kubernetes kümesi. Her birinin ne yaptığını, neden bu kadar maliyetli olduğunu ve makul temel seviyesinin ne olduğunu bilmelisiniz. Diğer her şey ek bağlamdır.
2. Hesaplama Kaynaklarını Doğru Boyutlandırma
Genellikle hesaplama, faturadaki en büyük kalemdir ve genellikle fazla tahsis edilmiştir. Bu, sistemleri boyutlandıran mühendislerin eleştirisi değil, belirsizlik altında ekiplerin altyapı kararları alma şeklinin yapısal bir sonucudur.
Yeni bir hizmet başlattığınızda, tam olarak ne kadar trafik alacağınızı veya kaynak kullanım profilinizin nasıl görüneceğini bilmezsiniz. Bu yüzden muhafazakar bir tahmin yapar ve bir güvenlik marjı ekleriz. Bu mantıklıdır. Ancak bu marjlar birikir. Onlarca hizmet, üç ortam ve iki yıllık organik büyüme boyunca, nadiren gördüğünüz yükleri kaldıracak şekilde tahsis edilmiş bir sistem filosu ile karşılaşırsınız.
Herhangi bir değişiklik yapmadan önce kullanım metriklerini çekin. Son otuz gün boyunca her çalışan sistem için ortalama CPU ve bellek kullanımına bakın. Maksimum değil, ortalama. Ortalama CPU kullanımı %8-12 arasında olan ve zirveleri %35'e ulaşan bir sistem bu boyutta olmamalıdır. Çoğu bulut sağlayıcısı, doğrudan maliyet kontrol panolarında boyutlandırma önerileri sunar; bunları bir başlangıç noktası olarak kabul edin, bunları kendi kullanım verilerinizle karşılaştırın ve önerinin ötesine geçmeye hazır olun.
Üretim ve üretim dışı ortamları 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 test ortamlarının 7/24 üretim kapasitesinde çalışmasına gerek yoktur. Mühendisler genellikle günde 10 saat, haftada 5 gün çalışır. Bu, üretim dışı altyapının zamanın yaklaşık %70'inde neredeyse boşta olduğu anlamına gelir.
Otomatik kapanma zamanlamaları uygulayın. Üretim dışı instance'ları akşamları kapatmak ve sabahları yeniden başlatmak için bir Lambda işlevi, Cloud Scheduler görevi veya cron aracılığıyla çalışan basit bir betik kullanın. Ortamlarınızı doğru şekilde etiketleyin, böylece bunu seçici olarak uygulayabilirsiniz. Sadece mesai saatlerinde çalışan bir test ortamı, 24/7 çalışma programına göre yaklaşık %30 maliyetlidir ve başlangıç süresi kabul edilebilir (genellikle iki dakikadan az) ise geliştirici deneyimi üzerindeki etkisi minimumdur.
Özellikle geliştirme ortamları için, bireylerin kalıcı bulut instance'larına ihtiyaç duyup duymadığını veya yerel konteyner tabanlı 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şımak ve yalnızca test ve üretim için bulut kaynaklarını tutmanın, üretkenliği etkilemeden faturayı önemli ölçüde azalttığını bulmaktadır.
Instance aileleri, instance boyutlarından daha önemlidir. AWS, GCP ve Azure, eski nesillere kıyasla fiyat-performans açısından daha iyi olan yeni instance ailelerini düzenli olarak piyasaya sürer. Genellikle, en yeni nesil hesaplama için optimize edilmiş veya genel amaçlı instance'lar, önceki nesilden birim performans başına daha ucuzdur, bazen %10-20 oranında. İki nesil daha eski bir aileden instance çalıştırıyorsanız, muhtemelen daha iyi bir seçenek vardır. Bunu en az yılda bir gözden geçirin.
3. Rezerve Kapasite ve Tasarruf Planları: En Yüksek Yatırım Getirisi Kararı
Girişiminiz altı aydan uzun süredir faaliyet gösteriyorsa ve öngörülebilir gelecekte ihtiyaç duyacağınızı bildiğiniz istikrarlı bir hesaplama tabanına sahipseniz ve bu taban için talep üzerine fiyatlar ödüyorsanız, pahalı bir hata yapıyorsunuz. Bu istisnai bir durum değil. Bu, girişimler için bulut yönetiminde en yaygın ve en maliyetli hatalardan biridir.
Talep üzerine fiyatlandırma, gerçekten öngörülemeyen yükler için tasarlanmıştır. Taahhütsüz kaynakları artırma veya azaltma esnekliği için ekstra ödeme yaparsınız. Bu ekstra ödeme, değişken ve belirsiz yükler için mantıklıdır. Ancak, geçen yıl boyunca değişmeden çalışan temel altyapı için mantıklı değildir.
Rezerve edilmiş instance'lar ve tasarruf planları, taahhüt süresine ve ödeme yapısına bağlı olarak, talep üzerine ödemeye kıyasla hesaplama maliyetlerini %40-70 oranında azaltır. Genellikle, bir yıllık taahhüt, peşin ödeme olmadan, talep üzerine ödemeye göre %30-40 daha ucuzdur. Üç yıllık taahhüt, kısmi veya tam peşin ödeme ile %60-70'e kadar tasarruf sağlayabilir. EC2'ye aylık 20.000 dolar harcayan bir girişim için, minimum kullanımı rezerve edilmiş instance'lara taşımak, aylık 8.000-14.000 dolar arasında tasarruf sağlayabilir. Bu, göz ardı edilemeyecek bir miktardır.
Pratik yaklaşım: Minimum hesaplama tabanınızı belirleyin, yani sessiz bir pazar günü sabah 3'te çalışan minimum miktar, trafik veya yükten bağımsız olarak. Bu minimum, rezerve kapasite ile karşılanması gereken şeydir. Bunun üzerindeki her şey (ani yük artışları, yeni özelliklerin başlatılması) talep üzerine veya spot olarak kalır. Bu, taahhütlerin sağladığı maliyet verimliliğini, herhangi bir değişken için talep üzerine ödeme esnekliği ile birleştirir.
Taahhütlerinizi üç ayda bir gözden geçirin. Rezerve edilmiş instance'lar ve tasarruf planları, ayarla ve unut türü değildir. Ürün geliştikçe minimum seviyeniz değişecektir. Mevcut taahhütlerin kullanımını ve yeni taahhüt ekleme fırsatlarını her çeyrekte gözden geçirin. Biraz daha az taahhüt etmek ve daha sonra artırmak, fazla taahhüt etmek ve kullanılmayan rezerve kapasite bırakmaktan daha iyidir. Kullanılmayan taahhütler, aslında boşa harcanan para anlamına gelir.
Tasarruf planları vs. rezerve edilmiş instance'lar: AWS'nin tasarruf planları, geleneksel rezerve edilmiş instance'lardan daha fazla esneklik sunar, çünkü aynı ailedeki herhangi bir EC2 kullanımına, belirli instance türü, bölge veya işletim sisteminden bağımsız olarak uygulanır. Çoğu girişim için, tasarruf planları yönetimi daha kolaydır ve neredeyse aynı derecede maliyet etkilidir. Altyapınız kararlı ve iyi tanımlanmışsa, belirli instance türleri için rezerve edilmiş instance'lar, ek bir tasarruf sağlayabilir.
PlusClouds ve Bulut Maliyet İyileştirme:
Rezerve edilmiş instance taahhütlerinde tahmin yapmayı bırakın.
PlusClouds, geçmiş kullanım kalıplarınızı analiz eder ve hangi rezerve kapasiteyi satın almanız gerektiğini tam olarak söyler — instance ailesine, bölgeye ve süreye göre ayrılmış olarak. PlusClouds'un taahhüt önerilerini kullanan müşteriler, hesaplamada ortalama %41 tasarruf sağlar. AWS Reserved Instances, Azure Reserved VMs ve GCP Committed Use Discounts üzerinde çalışır.
Nasıl çalıştığını plusclouds.com adresinde görün
4. Geçici ve İptal Edilebilir Hesaplama: Uygun Yükler İçin %90'a Varan İndirimler
AWS'deki spot hesaplama ve GCP'deki iptal edilebilir sanal makineler, mevcut en güçlü maliyet azaltma araçlarından biridir, ancak girişimler tarafından en az kullanılanlardır. Bunun nedeni, risk algısı ve aşinalık eksikliğinin bir karışımıdır. Hangi yüklerin uygun adaylar olduğunu anladığınızda, ekonomik faydaları göz ardı etmek zorlaşır.
Spot hesaplama, bulut sağlayıcının fazla kapasitesi üzerinde çalışır. Bu kapasite için teklif verirsiniz (veya modern AWS'de, mevcut fiyatla basitçe talep edersiniz) ve sağlayıcıya tekrar ihtiyaç duyulana kadar alırsınız, bu durumda durdurulmadan önce iki dakikalık bir uyarı alırsınız. Bu rahatsızlık için indirim: talep üzerine fiyatların %90'ına kadar.
Durdurulabilir veya yeniden başlatılabilir yükler için, bu neredeyse bedava para gibidir. Spot hesaplamanın mükemmel çalıştığı kategoriler arasında CI/CD hat işçileri (bir yapı görevi durdurulursa, işçi tekrar alır), toplu veri işleme ve ETL hatları (ilerlemeyi kaydedin ve devam edin), makine öğrenimi eğitim görevleri (çoğu çerçeve kontrol noktalarını kaydetmeyi destekler), gece analitikleri veya rapor üretimi, yük testleri ve bir yük dengeleyicinin önünde durumu olmayan web hizmetleri bulunur, burada bir instance'ın sonlandırılması, trafiği diğer instance'lara yönlendirerek sorunsuz bir şekilde ele alınır.
Spot hesaplamaya uygun olmayan yükler: kesintiye dayanıklı olmayan herhangi bir durumlu yük, çoğu konfigürasyonda veritabanları, gerçek zamanlı yanıt süreleri gerektiren hizmetler ve işlemin ortasında başarısız olması durumunda durumun bozulmasına neden olabilecek veya sıfırdan yeniden başlatılması gereken herhangi bir iş yükü.
Hesaplama türlerini karıştırma stratejisi en iyisidir. Durdurulabilir her şey için spot hesaplama kullanın, güvenilirliğe ihtiyaç duyan durumdan bağımsız hizmetler için talep üzerine ve kararlı tabanınız için rezerve edilmiş hesaplama kullanın. Yalnızca spot hesaplama üzerinde CI/CD hatlarını çalıştırmak, yapı altyapısı maliyetlerini %80 oranında azaltabilir ve operasyonel karmaşıklık çok azdır.
5. Depolama: Yavaş Sızıntıdan Sel Baskınına
Depolama maliyetleri bireysel düzeyde küçüktür, ancak toplandığında muazzamdır. Neredeyse her girişimde tekrarlanan model aynıdır: veriler nesne depolamada saklanır, kimse ne zaman silinmesi gerektiğini belirlemek için 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 fiyatları ödediğinizi fark edersiniz.
Nesne depolama fiyatları ucuz görünür, S3 Standard'da gigabayt başına aylık 0.023 dolar. Ancak ölçeklendikçe veya yeterince veri biriktikçe, maliyet büyük hale gelir. Daha da önemlisi, birçok girişim verileri yanlış kategoride saklar: her şeyi Standard'da tutar, oysa çoğuna nadiren veya hiç erişilmez, çünkü kimse onları otomatik olarak taşımak için kurallar oluşturmaz.
Yaşam döngüsü politikaları isteğe bağlı değildir. Bir bucket oluşturduğunuzda yapılandırmanız gereken ilk şey olmalı, daha sonra yapılacak bir iyileştirme değil. Erişilmediği 30 veya 60 gün sonra nesneleri az erişimli depolamaya taşıyan kurallar belirleyin, 90 veya 180 gün sonra Glacier veya Archive'a taşıyın ve belirli bir saklama süresinden sonra silin. Günlük dosyaları için, saklama süresi genellikle 30-90 gündür. Yedeklemeler için, uyumluluk gereksinimlerinize bağlıdır. Terk edilmiş özelliklerden gelen ham veriler için, cevap genellikle "6 ay sonra sil"dir.
Sınıflar arası geçişler ve zaman çizelgeleri sağlayıcıya ve kullanım durumuna göre değişiklik gösterebilir, ancak ilke evrenseldir: verilerin bir yaşam döngüsü vardır ve bunu kasıtlı olarak yönetmek zamanla çok para tasarrufu sağlar.
Çıkış maliyetleri, bulutta konuşulmayan en büyük fatura sürprizlerinden biridir. Bulut hizmet sağlayıcıları, ağlarından, internete, diğer bölgelere veya bazı durumlarda aynı hesap içindeki hizmetler arasında çıkan veriler için ücret alır. Bu ücretler gigabayt başına küçüktür, ancak veri hacmiyle hızla artar.
Çıkış maliyetleri için yaygın tuzaklar: işleme için bölgeler arasında büyük veri kümeleri çeken yapılar (veriyi işleme taşımak yerine işleme veriye taşıyın), son kullanıcılara doğrudan nesne depolamadan büyük dosyalar sunan uygulamalar, içerik dağıtım ağı (CDN) olmadan ve gereksiz yere büyük veri yüklerini hizmetler arasında ileten mikro hizmet mimarileri. Büyük veri aktarımı içeren bir mimariyi kabul etmeden önce, beklenen ölçeğinizde çıkış maliyetlerinin ne olacağını açıkça hesaplayın.
Depolamanızı düzenli olarak denetleyin. Depolama harcamanızı her üç ayda bir gözden geçirmek için takviminize bir hatırlatıcı koyun. Yaşam döngüsü politikası olmayan bucket'ları, eski özellikler veya hizmetler için veri depolayan bucket'ları, 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 olmayabilir, ancak birkaç saatlik temizlik, yıllarca sürecek tasarruflar sağlayabilir.
6. Yönetilen Veritabanları: Güçlü, Maliyetli ve Genellikle Aşırı Tahsis Edilmiş
RDS, Cloud SQL ve Azure Database gibi yönetilen veritabanı hizmetleri, yedekleme, güncellemeler, otomatik hata geçişi ve izleme gibi büyük operasyonel uzmanlık gerektiren görevleri üstlenerek bulut sağlayıcılarının en değerli tekliflerinden biridir. Ayrıca, genellikle girişimlerin bulut faturasında ikinci veya üçüncü en büyük kalemdir ve genellikle mevcut iş yükü yerine gelecekteki iş yükü için tahsis edilir.
Örnek: Çok bölgeli yüksek kullanılabilirlikli bir RDS instance'ı, okuma replikaları ve 500 GB özel IOPS, günlük milyonlarca işlemle başa çıkan bir ürün için uygundur. Ancak aylık 50.000 dolar gelir getiren ve 10.000 aktif kullanıcısı olan bir girişim için, bu aşırı bir yatırımdır. Ödediğiniz özellikler (eşzamanlı çoğaltma, otomatik hata geçişi, özel throughput) değerlidir, ancak henüz ulaşmadığınız bir ölçekte ödüyorsunuz.
Veritabanı seviyesini bugünkü gerçek gereksinimlerinize uygun hale getirin, 18 ay sonra ulaşmayı umduğunuz gereksinimlere değil. Daha sonra genişletmek her zaman mümkündür; çoğu yönetilen veritabanı hizmetinde yukarı doğru genişleme basittir ve genellikle çok az kesinti ile yapılabilir. Şu anda daha küçük bir instance sınıfı veya tek bölge çalıştırarak tasarruf ettiğiniz para, büyüme için gerçek bir yatırımdır.
Sunucusuz veritabanı seçenekleri, erken aşama ürünler için yeterince değerlendirilmiyor. Aurora Serverless v2, PlanetScale ve Firestore, gerçek yük temelinde hesaplama kapasitesini genişletir, boşta kalma sürelerinde neredeyse sıfıra kadar küçülür. Geliştirme veritabanları, düşük trafikli iç araçlar ve erişim desenleri tahmin edilemeyen özellikler için, sunucusuz veritabanları, sürekli çalışan tahsis edilmiş instance'lara kıyasla maliyetleri önemli ölçüde azaltabilir.
Veritabanlarınızı hafif tutun. Uygulama kodu tarafından artık kullanılmayan tabloları, sütunları ve indeksleri aramak için şemanızı düzenli olarak gözden geçirin. Anlık sorgular için artık gerekli olmadığında, geçmiş kayıtları daha düşük maliyetli depolamaya arşivleyin. Silinen kayıtları belirli bir zaman çizelgesine göre programlı olarak temizleyin. Bağlantı havuzlaması uygulayın, böylece veritabanı instance'ınızı maksimum eşzamanlı bağlantılar yerine tipik yükle uyumlu bir boyutta tahsis etmek zorunda kalmazsınız. Bunlar iyi mühendislik uygulamalarıdır ve aynı zamanda altyapı maliyetlerinizi azaltmaya yardımcı olur.
Community
Further questions? Ask our team
7. Kubernetes ve Konteynerler: Disiplin Gerektiren Güç
Kubernetes, birçok girişim için varsayılan dağıtım platformu haline geldi ve iyi bir nedenle, konteynerleştirilmiş iş yüklerini güvenilir ve ölçeklenebilir bir şekilde çalıştırmak için güçlü bir soyutlama sağlar. Ancak, maliyet yönetimi açısından göz ardı edilmesi kolay yeni bir dizi zorluk da sunar, özellikle ekipler hızlı hareket ederken ve kaynak tahsisine dikkat etmiyorlarsa.
Her pod için kaynak talepleri ve sınırları isteğe bağlı değildir. Bir pod'un kaynak talepleri tanımlanmadığında, Kubernetes planlayıcısının onu nereye yerleştireceğine karar verirken kullanabileceği bir bilgi yoktur. Sonuç genellikle düğümlerin "dolu" görünmesi ancak büyük ölçüde kullanılmayan kapasiteye sahip olması veya taleplerin gerçek kullanımı yansıtmadığı için aşırı yüklenmiş düğümler olmasıdır. CPU ve bellek taleplerini gözlemlenen tüketime göre belirleyin, tahminlere göre değil. Kontroller belirleyin, böylece kontrolsüz işlemler komşularını etkilemesin.
Ekosistemin sağladığı otomatik ölçeklendirme araçlarını kullanın. Horizontal Pod Autoscaler (HPA), CPU, bellek veya özel metriklere göre pod sayısını genişletir. Vertical Pod Autoscaler (VPA), gerçek kullanıma dayalı olarak kaynak taleplerini otomatik olarak ayarlar. Cluster Autoscaler ve daha yeni araç Karpenter, bekleyen pod talebine göre kümeden düğüm ekler veya çıkarır. Birlikte, bu araçlar küme kullanımını önemli ölçüde optimize edebilir, ancak verimli çalışabilmeleri için kaynak taleplerinin doğru belirlenmesi gerekir, bu yüzden bu temeller önemlidir.
Düğüm boyutlandırması, konteyner boyutlandırması kadar önemlidir. Kubernetes düğüm kümesi için seçtiğiniz instance türü, hem performansı hem de maliyeti etkiler. Mevcut düğüm türlerinizin gerçek iş yükü profiliyle uyumlu olup olmadığını gözden geçirin: yoğun hesaplama gerektiren yükler, hesaplama için optimize edilmiş instance'lardan yararlanır, yoğun bellek gerektiren yükler ise bellek için optimize edilmiş instance'lardan yararlanır. Genel amaçlı instance'ların bir karışımını çalıştıran ve esas olarak bellek ağırlıklı iş yükleri çalıştıran bir küme, asla kullanılmayan CPU kapasitesi için ödeme yapar.
Küme maliyetini ad alanı, takım veya uygulama bazında ayırın. Bu, ya bulut yerel maliyet tahsisi yaklaşımı (düğümleri etiketleme ve iş yükleriyle ilişkilendirme) ya da özel bir araç gerektirir. Bu görünürlük olmadan, Kubernetes kümeleri kara kutular haline gelir; kümenin maliyetini bilirsiniz, ancak hangi yüklerin veya takımların hangi kısmından sorumlu olduğunu belirleyemezsiniz. Bu belirsizlik, optimizasyonu çok daha zor hale getirir.
8. Ağ ve Veri Aktarımı: Görünmez Bütçe Kalemi
Ağ maliyetleri nadiren bulut optimizasyon öncelikleri listelerinde yer alır ve nadiren faturadaki en büyük kalemdir. Ancak, uygulamalar büyüdükçe ve veri hacimleri arttıkça, genellikle maddi ve hafife alınan bir maliyet sürücüsü haline gelirler.
Bölge içi, kullanılabilirlik bölgeleri (AZ) arasındaki trafiği dikkatlice düşünün. Çoğu bulut sağlayıcısı, aynı bölgedeki kullanılabilirlik bölgeleri arasında taşınan veriler için ücret alır. Hizmetler arasında çok sayıda bağlantı kuran yapılar (örneğin, birbirleriyle iletişim kuran mikro hizmetler, önbellekten okuyan hizmetler veya kuyruklardan tüketen işçiler) için kullanılabilirlik bölgeleri arasındaki veri aktarım maliyeti önemli hale gelebilir. Hafifletme yolları: yoğun iletişim kuran hizmetleri aynı kullanılabilirlik bölgesinde gruplamak veya yerel instance'ları tercih eden kullanılabilirlik bölgesi farkındalığı olan yük dengeleme kullanmak.
Temel ilke basittir: veri aktarımı para tutar. Veri ne kadar uzak mesafe kat ederse ve ne kadar çok faturalama sınırını aşarsa, maliyet o kadar artar. Sistemleri verilerin yerel kalacağı şekilde tasarlamak, hesaplamayı veriye yakın tutmak, bölgeler arası iletişimi azaltmak ve gereksiz gidiş-dönüşleri önlemek, hem mimari hem de ekonomik açıdan iyi bir uygulamadır.
Bölge içi, kullanılabilirlik bölgeleri (AZ) arasındaki trafiği dikkatlice düşünün. Çoğu bulut sağlayıcısı, aynı bölgedeki kullanılabilirlik bölgeleri arasında taşınan veriler için ücret alır. Hizmetler arasında yoğun iletişim kuran yapılar (örneğin, birbirleriyle iletişim kuran mikro hizmetler, önbellekten okuyan hizmetler veya kuyruklardan tüketen işçiler) için kullanılabilirlik bölgeleri arasındaki veri aktarım maliyeti önemli hale gelebilir. Hafifletme yolları: yoğun iletişim kuran hizmetleri aynı kullanılabilirlik bölgesinde gruplamak veya yerel instance'ları tercih eden kullanılabilirlik bölgesi farkındalığı olan yük dengeleme kullanmak.
Kullanıcıya yönelik içerik için bir İçerik Dağıtım Ağı (CDN) kullanın. Sabit varlıkları, resimleri ve önbelleğe alınmış yanıtları doğrudan nesne depolamadan veya kaynak sunuculardan sunmak, çıkış maliyeti açısından CDN üzerinden sunmaktan çok daha pahalıdır. Genellikle CDN fiyatları, kaynak çıkış fiyatlarından çok daha düşüktür ve son kullanıcılar için yanıt süresini iyileştirmek ek bir ücretsiz kazançtır. Bu, iyi bilinen bir uygulamadır ve genellikle girişimin erken aşamalarında göz ardı edilir ve daha sonra gözden geçirilmez.
Çıkış tuzaklarından kaçınmak için VPC mimarinizi gözden geçirin. NAT Gateway maliyetleri, yaygın bir sürprizdir. Özel bir alt ağdan internete giden her bayt, saat başına ve gigabayt başına ücret alan NAT Gateway üzerinden geçer. Dış API çağrıları yapan hizmetleriniz varsa, dış kaynaklardan büyük veri kümeleri işliyorsanız veya yapı sırasında büyük paketler indiriyorsanız, NAT Gateway ücretleri hızla birikebilir. AWS hizmetleri için VPC uç noktaları (S3, DynamoDB ve diğer birçok hizmet gibi), trafiği AWS ağı içinde yönlendirir, bu hizmetler için NAT Gateway ücretlerini tamamen ortadan kaldırır.
9. Kod Olarak Altyapı: Finansal Disiplin Dağıtımdan Başlar
Bulut maliyetlerini kontrol altına almanın en etkili yollarından biri, maliyeti altyapı sağlama anında temel bir düşünce haline getirmektir, aylar sonra yapılan bir denetim değil. Terraform, Pulumi, AWS CDK gibi Kod Olarak Altyapı (IaC) araçları, bunu mümkün kılan mekanizmalardır.
Tüm altyapı kodda tanımlandığında ve standart bir çekme isteği süreciyle gözden geçirildiğinde, finansal etkiler kaynaklar oluşturulmadan önce belirgin hale gelir. Bir inceleyici, yeni bir RDS instance ekleyen bir Terraform değişikliğine bakabilir ve şu soruları sorabilir: Bu çok bölgeli mi olmalı? Yedekleme saklama süresi nedir? Bu instance sınıfı, beklenen yük için uygun mu? Bu tartışmalar inceleme sırasında ucuzdur, olay gerçekleştikten sonra pahalıdır.
Etiket uygulamasını politikalarla zorlayın. OPA (Open Policy Agent), Sentinel veya bulut yerel politika çerçeveleri (AWS Hizmet Kontrol Politikaları, GCP Kurumsal Politikaları gibi), maliyet dağıtımı için gerekli etiketleri içermeyen altyapı değişikliklerini reddedebilir. Bu, yeni kaynakların her zaman oluşturuldukları andan itibaren izlenebilir olmasını sağlar, mühendislerin etiketleme planını hatırlamalarına güvenmeden.
Yaygın desenler için modüller ve standartlar kullanın. Ekibinizin bir EC2 instance'ı veya RDS veritabanı oluşturmak için standart bir modülü olduğunda, bu modül maliyet etkin varsayılanları kodlayabilir: uygun instance türleri, doğru etiketler, bağlı 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ılan ayarlar alır.
Sapma tespiti uygulayın. "Bir şeyi hızlıca test etmek için bunu çalıştıracağım" türündeki bulut konsolu üzerinden yapılan manuel değişiklikler, unutulmuş kaynakların ve beklenmedik maliyetlerin en yaygın kaynaklarından biridir. Sapma tespit araçları, bulutta bulunan ancak IaC kod tabanınızda bulunmayan kaynakları işaretler, bu da geçici kaynakları bulmayı ve aylarca fark edilmeden birikmeden önce temizlemeyi mümkün kılar.
10. Maliyet Bilincine Sahip Mühendislik Kültürü Oluşturma
Bu kılavuzdaki tüm taktiksel ipuçları, mühendislerin maliyeti temel bir öncelik olarak gördüğü bir organizasyonda daha kolay uygulanır ve daha sürdürülebilir olur. Bulut maliyet disiplinini zamanla sürdüren ekipler, bunu üç aylık denetimler veya maliyet optimizasyonu için özel kampanyalarla yapmazlar. Maliyet bilincini, günlük mühendislik işlerinin bir parçası haline getirirler.
Bu, teknik olduğu kadar kültür ve süreç meselesidir.
Görünürlük davranışı yönlendirir. Mühendisler, göremedikleri şeyi iyileştiremezler. Herkesin erişebileceği maliyet panoları, sadece CFO ve altyapı lideri değil, tüm ekibe maliyet bilincine sahip kararlar almak için ihtiyaç duydukları bilgileri verir. Yeni bir özellik geliştiren ekip, o özelliğin altyapı maliyetini gerçek zamanlı olarak görebildiğinde, maliyet, tasarım seçeneklerini değerlendirme şekillerinin doğal bir parçası haline gelir.
Maliyet panolarını, performans metriklerini paylaştığınız aynı kanallarda yayınlayın. Maliyet verilerini tüm mühendislik toplantılarına dahil edin. Altyapı tartışmalarında "Bu ne kadara mal olacak?" sorusunu sormayı, "Bu nasıl ölçeklenecek?" veya "Hata modları neler?" sorularını sormak kadar doğal hale getirin.
Ekiplerin kendi maliyetlerini sahiplenmelerini sağlayın. Bu, maliyetleri takım veya grup bazında etiketleme yapınızla tahsis etmek, her takıma bir bütçe ve pano vermek ve ekipleri düzenli incelemelerde maliyet eğilimlerini açıklamaktan sorumlu tutmak anlamına gelir. Sahiplenme, hesap verebilirlik yaratır ve hesap verebilirlik davranışı değiştirir. Altyapı faturasındaki kendi kalemlerini gören ekipler, toplam bir rakamı başkasının sorunu olarak gören ekiplerden farklı davranır.
Maliyeti, altyapı inceleme sürecinizin bir parçası yapın. Üretime alınacak herhangi bir yeni önemli hizmet veya altyapı değişikliği çalıştırılmadan önce, incelemede bir maliyet tahmini dahil edin. Bu, mevcut ölçekte ne kadara mal olacak? On kat daha büyük ölçekte ne kadara mal olacak? Önemli ölçüde daha ucuz olacak alternatif yollar var mı? Bu, ayrıntılı bir finansal model olmak zorunda değil, düzenli tasarım incelemesinin bir parçası
