AB180 geliştirme ekibinin AWS maliyet yönetimi yolculuğu: Fatura kontrolünden FinOps kültürüne

Gemini ile özetlenmiştir.

--

Çok büyük miktarda veriyi işleyen pazarlama performansı ölçüm çözümü 'Airbridge'i işletirken, sistematik bir AWS maliyet yönetimi (FinOps) kültürü oluşturduk. Bu süreçte edindiğimiz deneyim ve birikimi paylaşıyoruz.

AB180'in maliyet yönetimi işletim biçimi:
Biz, maliyetleri "yönetmek" için aşağıdaki süreçleri işletiyoruz.

• Google Sheets tabanlı pano: Verileri kolayca işleyip paylaşabilmek için Google Sheets kullanarak bir pano kurduk. Etiket bazlı maliyet durumunun yanı sıra, maliyetleri doğrudan etkileyen veri toplama hacmini de birlikte göstererek değişim nedenlerini sezgisel olarak anlamayı sağlıyoruz. Ayrıca Savings Plan kapsama durumunu görselleştiriyor ve sözleşme değişikliği durumunda sonucu önceden simüle ederek makul kararlar alınmasına yardımcı oluyoruz.
• Periyodik ve otomatikleştirilmiş maliyet kontrolü: İki haftada bir, yaklaşık 30 dakikalık kısa bir toplantıyla maliyet değişimlerini gözden geçiriyoruz. Toplantı materyali oluşturma, Slack bildirimi, toplantı notu yazımı gibi tekrar eden işleri mümkün olduğunca otomatikleştirerek verimliliği artırdık. Maliyet değişimi büyükse, ilgili kişi Google Sheets yorumlarıyla nedeni analiz edip paylaşarak şeffaflığı sağlıyor.
• Geliştirme öncesinde beklenen maliyetin hesaplanması: Yeni özellik geliştirme veya mimari değişikliklerde, 'Tech Spec' belgesinde beklenen maliyetin hesaplanmasını zorunlu hale getirdik. Böylece geliştirme aşamasından itibaren maliyeti dikkate alan daha iyi teknik kararlar alınabiliyor.

Maliyet yönetim sisteminin olgunlaştırılma süreci:
Bugünkü sistem bir gecede ortaya çıkmadı. Aşağıdaki aşamalardan geçerek gelişti.

• Phase 0 (Fatura kontrolü): Başlangıçta yalnızca her ay faturayı kontrol etme düzeyindeydik.
• Phase 1 (Asgari sınıflandırma): Name etiketiyle kaynakları asgari düzeyde sınıflandırmaya başladık.
• Phase 2 (Etiket stratejisinin gelişmiş hale getirilmesi): Team, Service gibi net politikalara dayalı bir etiket stratejisi oluşturduk. Yalnızca kılavuz dağıtmak yeterli olmadığından, IAM politikalarıyla entegre ederek etiket ayarını zorunlu kıldık ve etiketsiz kaynaklar için Slack botu üzerinden otomatik bildirim gönderen bir mekanizma kurduk. Sonuç olarak, etiketsiz kaynak maliyetini toplamın %1'inin altında yönetir hale geldik.

Bu yolculuktan çıkarılan 5 ders:

• Duruma uygun mühendislik önemlidir. Maliyet kontrolü için kusursuz bir sistem aramak yerine, şirketin ölçeğine ve durumuna uygun "doğru" seviyede bir yönetim çerçevesini aşamalı olarak kurmak daha akıllıcadır.
• Maliyet "kontrolü" ve "optimizasyonu" farklı işlerdir. Maliyetlerin öngörülebilirliğini artıran "kontrol" ile maliyetin kendisini azaltan "optimizasyon" açıkça farklıdır. Koşulların önceliğine göre hangisine odaklanılacağına karar verilmelidir.
• Cesurca otomatikleştirmek gerekir. Basit ve tekrar eden işleri otomatikleştirmenin ötesinde, ekip arkadaşlarının veriyi doğrudan sorgulayıp sorunları anlayabildiği bir 'self-serve' ortamı kurulduğunda üretkenlik en üst düzeye çıkar.
• Bir "mekanizma" kurmak gerekir. "Etiketleri düzgün ekleyelim" demek yerine, etiket yoksa kaynak yetkisi verilmeyecek olması gibi, politikalara uymayı fiilen zorunlu kılan bir "düzenek (mekanizma)" tasarlamak etkilidir.
• FinOps sonuçta bir "kültür"dür. Maliyet yönetiminin belirli bir kişinin işi değil, ürünü geliştiren herkesin sorumluluğu olduğu anlayışının yerleşmesi için sürekli çaba göstermek ve bu kültürü inşa etmek en önemli noktadır.

[tujuc]

Oho.. En temel Tag’leri bile eklesek belli bir noktaya kadar iş görür gibi görünüyor.. :)

Ama RI ya da SP gibi şeyleri kullanarak maliyeti düşürmek de zaten temel olarak yapılması gerekenlerden mi sayılıyor acaba....
Altyapımızda hangi boyutun kullanılacağı konusu da gerçekten epey kafa yorulan bir kısım gibi görünüyor...

[dongho42]

Asıl metinde de değiniliyor ama ben ayrıca bir SP simülatörü yapıp son n gündeki workload’u temel alarak burada ne kadar daha fazla SP satın alınırsa "mevcut maliyet + Covered olduğu için azalacak maliyet + Recurring olduğu için boşa gidecek maliyet" toplamının en aza ineceğini hesaplıyor ve buna göre karar veriyordum.

[slave4salary]

Şu anda AWS Korea'da çalışıyorum.

İşe girdikten sonra verilen eğitimlerde en önemli başlıklardan biri, müşterilerin bulut maliyetlerini daha az kullanabilmesi için yöntemler düşünmek oluyor; bu noktada en etkili yöntemlerden biri olarak RI & SP öneriliyor.

[cocofather]

Lütfen ücreti düşürün..

[toughrogrammer]

RI'ı bilmiyor olsam da, SP söz konusu olduğunda birden fazla iş yüküne uygulanabildiği için sabit giden bir maliyetiniz varsa bunu kesinlikle değerlendirmeye değer. Hatta biz, beklenen optimizasyon zamanını da hesaba katarak satın alma yapmıştık... haha Mesela 9 ay sonra optimizasyon tamamlanıp sunucu maliyetinin yarıya düşeceğini düşünüyorsanız, yine de 1 yıllık almak daha kârlıysa o şekilde satın alıyorduk.