Duolingo, mütevazi başlangıcından bu yana uzun bir yol kat etti—son birkaç yılda Hikayeler gibi sevilen özellikleri geliştirmeye ve DuoRadio ve Macera gibi etkileyici dersler oluşturmaya ağırlık verdik. Ürünümüzün geleceği hakkında hepimiz çok heyecanlıyız, ancak zor bir gerçekle de yüzleşmek zorunda kaldık: AWS iyi niyetleri ödeme olarak kabul etmiyor.

Her parlak özellik, sürdürülmesi için kaynak gerektirir ve çoğu yüklü fiyat etiketleriyle gelir. Zamanla bu maliyetler yılda milyonlarca doları buldu! (Tam rakamı paylaşmak isterdik ama avukatlarımız hayır dedi.) 2024’ün başında büyük bir görev belirlendi: Ürünümüzü tehlikeye atmadan bulut harcamalarını azaltmak. Onlarca mühendis bu çabaya katkıda bulundu ve sadece birkaç ay içinde %20 tasarruf sağladık (yıllık olarak)! İşte bu deneyimden çıkardığımız bazı dersler.

Gözlemlenebilirlik çok önemli

İlk adım, her bir doların nereye gittiğini anlamaktı. “Ne kadar harcıyoruz ve ne için?” sorularını yanıtlayan verilere kolay erişime ihtiyacımız vardı. Ve kritik olarak, “Bu zaman içinde nasıl değişiyor?”

Başlangıç olarak CloudZero adlı üçüncü taraf bir araç kullandık, bu araç bulut maliyetlerimizi sorgulanabilir satır öğelerine ayırdı. Bu sayede en çok harcama yapanları gözden geçirip aralarındaki anormallikleri tespit edebildik. Bizi şaşırtan durumlar da oldu! Örneğin, bir hizmetin test kaynakları, üretim kaynaklarından daha pahalıya mal oluyordu… Birinin bir testi gerçekleştirmek için kaynakları ölçeklendirdiği ve sonra geri küçültmeyi unuttuğu ortaya çıktı.

Maliyetleri izleyen mühendis sayısını artırmak tasarruf etmenin harika bir ilk adımı, bu nedenle keşfedilebilirliği ve erişilebilirliği artırmak için çalıştık. AWS dışındaki bulut hizmetlerini de içerecek şekilde veri kapsamımızı genişlettik, bulut harcamalarını mevcut metrik ekosistemimize entegre ettik ve ekiplerin hizmetlerini pasif olarak izleyebilmeleri için haftalık raporlar gönderdik.

Açık olan: ihtiyacınız olmayan şeyler için ödeme yapmayın

Bu basit gibi görünebilir ama ihtiyacımız olmayan şeyler için ne kadar çok harcama yaptığımıza şaşırabilirsiniz (tüm eski aboneliklerinizi düşünün 😱). Araştırmamızda, bir dizi gereksiz kaynak bulduk: eski ElastiCache kümeleri, tüm veritabanları ve bir mikro hizmet. Birçoğu tam anlamıyla temizlenmemiş kodu olan eski özelliklere aitti—ancak sahipleri teknoloji borçlarının gerçek maliyetini bilselerdi, belki ikinci bir kez düşünürlerdi!

Kullanılmayan kaynakları silmenin ötesinde, gereksiz verileri silmek de önemli olabilir. İşte üç örnek:

• Aktif olarak kullanılan S3 kovalarımız vardı, ancak tüm sürüm geçmişini korumak için de ödeme yapıyorduk.
  • Yedeklemeleri seviyoruz ama bunların sonsuza kadar gitmesine gerek yok.
  • En büyük kovalarımıza yaşam döngüsü kuralları ekleyerek çok para tasarrufu sağladık!
• DynamoDB tablolarımızda saklanan ve ödemesini yaptığımız bir sürü eski veri vardı.
  • Suçlu? Eksik TTL kuralları. Ekledik.
  • Uyarı: Yeni TTL kuralları mevcut satırları sihirli bir şekilde silmez—bu satırları kaldırmak gerçekten zahmetlidir!
• Üretim ortamlarında aşırı ayrıntılı günlükleri, örnekleme yapmadan tutuyorduk.
  • Birçok hizmet CloudWatch için gereğinden fazla harcama yapıyordu, ancak günlüklerini denetleyerek çok tasarruf sağladık.
  • Bir ipucu: Yığın izleri büyüktür. Üretimde bunları kaydetmeyin.

“Sadece ihtiyacınız olan şey için ödeme yapın” fikri, hesaplama kaynakları için de geçerlidir! Hizmetlerimizin çoğu fazla kaynak ayrılmıştı:

• Düşük bellek kullanımıyla çalışan bir hizmet, iki yatak odalı bir daire kiralayıp sadece bir odasını kullanmak gibidir.
  • Çözüm? Bellek tahsisini düşürmek.
  • Deneyimle öğrendik ki, hizmetlerimizin çoğu bellek kullanımını %90 veya hatta %95’te rahatlıkla çalıştırabilir.
• Benzer şekilde, düşük CPU kullanımıyla çalışan bir hizmet, küçük bir daireden taşınmak için 10 kamyon kiralamak gibidir.
  • Burada her “kamyon” bir “görevdir”—her biri için ödeme yaparsınız, bu yüzden en iyi şekilde yararlanın.
  • Hizmet görev sayısını minimum eşiği düşürerek azalttık ve görev ekleme politikasını daha az agresif hale getirdik.
  • Bir hizmet o kadar fazla ölçeklenmişti ki, görev tahsisini optimize ederek yılda yüz binlerce tasarruf sağladık!

Yarı açık olan: yerleşik optimizasyon stratejilerinden yararlanın

AWS belgelerini daha yakından incelediğimizde, belirli okuma/yazma kullanım desenlerine göre optimize edilmiş bazı maliyet tasarrufu politikaları bulduk. AWS ayrıca geçici trafik artışlarına uyum sağlamak için otomatik ölçeklendirme ve görev zamanlama yapılandırmaları sunar, böylece her zaman tam kapasitede çalışmak zorunda kalmazsınız.