Cosmos DB’de AI Maliyet Optimizasyonu: 7 Pratik İpucu
Geçen ay bir fintek müşterimizde agentic AI workflow’u canlıya aldık. Güzel gidiyordu aslında, embedding’ler akıyor, RAG pattern’i düzgün dönüyor, LLM orchestration da fena değil… ta ki ay sonu fatura gelene kadar. Cosmos DB tarafında beklenmedik şekilde bütçenin %180’ını aşmıştık. Neden? Throughput mode yanlış seçilmişti, partition key tasarımı düşünülmemişti, bir de cross-region replication gereksiz yere açık kalmıştı. İşte o projeden sonra oturdum, AI workload’ları için Cosmos DB maliyet iyileştirmeu konusunda ciddi bir çalışma yaptım.
📋 İçindekiler
-
Birkaç ay önce bir startup müşterimiz embedding boyutunu 1536’dan 512’ye düşürdüğünde aylık storage maliyeti neredeyse üçte bire indi. Retrieval kalitesi? Hemen bir düşüneyim… hemen aynı kaldı ya da gözle görülür fark yaratmadı diyeyim ben buna.%100 doğru olmayabilir ama sonuç buydu işte. Yanı bazen “daha büyük daha iyi” olmuyor — özellikle cüzdanınız için. Daha fazla bilgi için
Multi-Region Yazma: Gerçekten İhtiyacınız Var mı?
Dur bir dakika, şunu da söylemem lazım (ki bu çoğu kişinin gözünden kaçıyor). Multi-region write Cosmos DB’nın en güçlü özelliklerinden biri ama aynı zamanda en pahalısı. Her ek write region, RU maliyetinizi neredeyse ikiye katlıyor. AI workload ‘larının çoğunda — mesela bir RAG chatbot düşünün — yazma işlemi okumaya göre çok az. Embedding ‘leri bir kere yazıyorsunuz, sonra sürekli okuyorsunuz. Yanı asıl trafik okuma tarafında dönüyor, yazma tarafı işe seyrek kalıyor.
Bu durumda tek write region + birden fazla read region çok daha mantıklı. Read replica ‘lar write ‘a göre ucuz. Agentic workload ‘da agent state ‘i yazıyorsunuz, evet, ama bu da genelde tek bölgeden yönetilebilir. Burada mesele ihtiyacı abartmamak ; çünkü herkes global dağıtım istiyor diye şart değil.
Logosoft ‘ta bir telekomünikasyon projesinde multi-region write açıktı çünkü “gerekebilir” diye düşünülmüştü. Dört ay boyunca hiç kullanılmadı. Kapattığımızda aylık maliyet %40 düştü. Kırk yüzde, az buz değil. Maalesef tablo buydu.
Enterprise vs Startup Farkı
Büyük kurumsal yapıdaysanız. Gerçekten global kullanıcı tabanınız varsa — mesela Avrupa, ABD ve Asya ‘da aktif kullanıcılar — multi-region write mantıklı olabilir.
Ama Türkiye merkezli bir SaaS uygulaması yapıyorsanız, West Europe tek başına çoğu senaryoda yeterli.
Belki bir de North Europe read replica eklersiniz, o kadar.
Neyse uzatmayalım ; ihtiyaç neyse önü alın.
Fazlası sadece fatura şişiriyor.
Sız ne dersiniz ?Sorgu Optimizasyonu ve Maliyet İzleme
En gözden kaçan kısım burası.
Cosmos DB her sorgu için kaç RU harcandığını söylüyor —
response header ‘dax-ms-request-charged değerine bakmanız yeterli.
Ama kaç ekibin buna baktığını sorarsanız…
Az.
Çok az.
İnsanlar genelde ekran parlaklığına bakar gibi buna bakmıyor ; halbuki tam orada para akıp gidiyor (şaşırtıcı ama gerçek).//.NET SDK ile RU maliyetini logla var response = await container.ReadItemAsync<dynamic>(id, partitionKey); Console.WriteLine($"Bu sorgu {response.RequestCharge} RU harcadı"); // Yüksek maliyetli sorguları yakala if (response.RequestCharge > 50) { _logger.LogWarning($"Pahalı sorgu tespit edildi: {response.RequestCharge} RU"); }Bunu yapın.
Ciddiyim.
Her sorgunun RU maliyetini loglayın,
sonra en pahalı 10 sorguyu bulun ve optimize edin.
Genellikle sorun cross-partition query,
eksik composite index veya gereksiz büyük döküman okumalarıdır.
Bazen sorun sandığınızdan basit çıkıyor ;
bazen de iki satırlık kod bütün faturayı kurtarıyor.Bir de Azure Monitör ve Cosmos DB Insights dashboard’ünü mutlaka aktif edin.
Hangi container ne kadar RU tüketiyor,
throttling oluyor mu,
partition hot spot var mı —
hepsi orada görünüyor.
AI Maliyet Optimizasyonu: ROI’yi Gerçekten Artırmanın Yolu
yazımda da AI projelerinde genel maliyet takibi stratejilerinden bahsetmiştim,
Cosmos DB izleme de o çerçevenin önemli parçası.
Yanı izlemeyi sonradan eklemeyin ;
baştan koyun derim.Eh, E tabi, bir de şu var : AI workload ‘larında SELECT * yapmayın.
Embedding alanı devasa,
her sorguda tüm embedding’i çekmenize gerek yok.
Sadece ihtiyacınız olan alanları project edin —
bu tek başına RU tüketimini %30-50 azaltabiliyor.
Basit görünüyor. Etkisi baya hissediliyor.
Denemediniz mi hiç ?Sonuç : Maliyet Kontrolü Sürekli Bir İştir
Yedi ipucunu özetlediğimde şunu görüyorum :
Cosmos DB’de AI workload maliyet iyileştirmeu tek seferlik iş değil,
sürekli döngü. Başlangıçta doğru throughput modu seçiyorsunuz,
sonra partition key’i optimize ediyorsunuz,
sonra sorguları izliyorsunuz,
sonra belki reserved capacity’e geçiyorsunuz. Her aşamada farklı bir kaldıraç devreye giriyor ;
bir yerde rahatlıyorsunuz,
başka yerde tekrar ince ayar gerekiyor.Yanı, Bence Microsoft bu konuda doğru yolda —
özellikle DiskANN vektör indeksleme ve hierarchical partition key gibi özellikler maliyet bilincini mimariye entegre ediyor.
Ama hâlâ eksik olan şey ne biliyor musunuz ?
Otomatik maliyet öneri sistemi.
Azure Advisor Cosmos DB için bazı öneriler veriyor ama bunlar çok jenerik.
AI workload ‘larına özel,
“şu container’da embedding TTL’i yoksa ekle” gibi akıllı öneriler görmek isterdim.
Belki gelecek versiyonlarda…
şey, umut etmek serbest tabi.Şunu fark ettim: Şimdi eğer sız de bir AI projesi planlıyorsanız,
ilk adım olarak şunu yapın :
mevcut Cosmos DB kullanımınızın RU breakdown’ını çıkarın.
Hangi container,
hangi sorgu,
ne kadar harcıyor —
bunu bilmeden optimizasyon yapamazsınız.
Veri olmadan karar olmaz.
Lafı gevelemeden söyleyeyim :
önce ölçün,
sonra oynayın.Sıkça Sorulan Sorular
Cosmos DB’de serverless mı autoscale mı seçmeliyim AI projesi için?
Projeniz henüz MVP aşamasındaysa ya da trafik düşük ve düzensizse, bence serverless ile başlamak çok daha mantıklı. Yanı production’da düzenli ama değişken bir yük varsa autoscale devreye giriyor. Açıkçası en güvenli yol şu: ilk birkaç hafta serverless’ta çalıştırıp trafik paternini izledikten sonra karar vermek.
Embedding boyutu Cosmos DB maliyetini nasıl etkiliyor?
Doğrudan etkiliyor, hani hiç dolaylı bir ilişki değil. Her embedding hem storage hem de sorgu sırasında RU tüketiyor. Mesela 1536 boyutlu embedding yerine 512 boyutlu kullanmak, storage maliyetini yaklaşık üçte bire indiriyor. Aslında çoğu RAG senaryosunda 512 boyut yeterli kaliteyi veriyor, gereksiz yere büyük boyutlara geçmeye gerek yok.
Cosmos DB free tier AI geliştirme için yeterli mi?
Şöyle ki, Dev ve test ortamı için genelde yeterli. Aylık 1000 RU/s ve 25 GB storage sunuyor. Embedding denemeleri, küçük ölçekli vektör arama testleri rahatça yapılabiliyor. Production için tabi ki yetmez ama tecrübeme göre geliştirme döngüsünde para yakmamak için birebir.
Multi-region write ne zaman gerekli olur?
Gerçekten farklı coğrafyalarda aktif yazma işlemi yapan kullanıcılarınız varsa gerekli oluyor. Burada,. Türkiye merkezli çoğu uygulama için tek write region artı read replica yeterli, yanı çoğu zaman gerek kalmıyor. Multi-region write RU maliyetini neredeyse ikiye katlıyor — açıkçası ihtiyaç yoksa kesinlikle açmayın.
Cosmos DB’de hangi sorguların pahalı olduğunu nasıl bulurum?
Bak şimdi, SDK response’undaki
x-ms-request-chargeheader’ını loglayarak başlayabilirsiniz, hani en hızlı yol bu. Azure Monitör’da Cosmos DB Insights dashboard’u da container bazında RU tüketimini gösteriyor. Bence 50 RU üzeri sorguları ayrıca uyarı olarak loglamanız çok işe yarıyor.Kaynaklar ve İleri Okuma
7 Tips to Optimize Azure Cosmos DB Costs for AI and Agentic Workloads — Microsoft DevBlogs
Bir şey dikkatimi çekti: Azure Cosmos DB Maliyet Yönetimi — Microsoft Learn
Azure Cosmos DB Vektör Arama Dokümantasyonu — Microsoft Learn
Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Yasemin İ.
RAG pipeline’larında partition key seçimini hep hafife alıyordum, tam olarak bu yüzden maliyetler beklentinin çok üstüne çıkıyordu. Dev/test için ücretsiz kaynakları kullanma kısmını da merak ediyorum, Cosmos DB Serverless bu senaryoda yeterli geliyor mu acaba?
Kaan T.
Cosmos DB maliyetleri gerçekten sinsi bir şekilde büyüyor, fark ettiğinde iş işten geçmiş oluyor. Partition key seçimini baştan yanlış yapınca sonradan düzeltmek de epey acı veriyor. Dev/test için ücretsiz kaynakları kullanmak basit ama çok işe yarayan bir öneri, bunu atlayan çok ekip var.
Yorumlar kapalı.
2 comments