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.
Bu yazıda, hem kendi sahadan edindiğim deneyimleri hem de Microsoft’un yakın zamanda yayımladığı Cosmos DB maliyet tasarrufu whitepaper’ındaki önerileri harmanlayarak 7 pratik ipucu paylaşacağım (ben de ilk duyduğumda şaşırmıştım). Bunlar kağıt üzerinde hoş duran teorik tavsiyeler değil — gerçekten TL bazında fark yaratan, test edilmiş yaklaşımlar. Evet, doğrudan cebinize dokunuyor.
Dev/Test Ortamında Para Yakmayı Bırakın
Bakın şimdi, bu kadar basit bir şey olmasına rağmen inanılmaz sık karşılaşıyorum: ekipler production-grade Cosmos DB instance’ı dev ortamında çalıştırıyor (buna dikkat edin). Hani geliştirme yapıyorsun, test ediyorsun, ama provision edilmiş throughput sürekli para yakıyor. Gece kimse kullanmıyor bile! Garip ama oluyor.
Şimdi gelelim işin can alıcı noktasına.
Cosmos DB’nın iki bedava silahı var ve bunları kullanmayan ekip gördüğümde içim acıyor:
- Free Tier: Her Azure subscription’da aylık 1000 RU/s throughput ve 25 GB storage bedava geliyor. Dev/test için bu çoğu zaman yeterli.
- Cosmos DB Emülatör: Yerel makinende çalışıyor, bulut maliyeti sıfır. Embedding denemelerinizi, vektör arama testlerinizi burada yapabilirsiniz.
2024 sonunda bir e-ticaret müşterimizde 4 farklı ortam vardı — dev, staging, UAT, production. Hepsi provisioned throughput’la çalışıyordu. Sadece dev ve UAT’ı emülatör + free tier’a taşıyarak aylık yaklaşık 3200 TL tasarruf sağladık. Ciddi para değil mi? Üstelik hiçbir fonksiyonellik kaybı yaşanmadı. Şaşırdım açıkçası.
Agentic AI uygulamalarında geliştirme döngüsü çok hızlı. Prompt değişiyor, embedding boyutu değişiyor, tool tanımları güncelleniyor. Bu süreçte her deneme için bulutta para harcamak — açık konuşayım — gereksiz.
Throughput Mode Seçimi: En Pahalı Kararınız
Bu konu baya kritik. Cosmos DB’de üç farklı throughput modu var ve yanlış seçim direkt cüzdanınızı vuruyor. Hadi bir tablo ile özetleyelim; işin özünü orada daha net görüyorsunuz.
| Mod | En Uygun Senaryo | Maliyet Profili | AI Workload Uyumu |
|---|---|---|---|
| Serverless | Düşük hacimli, bursty trafik | Kullandığın kadar öde | Prototip, chatbot MVP |
| Autoscale | Değişken yük, spike’lar var | Min-max arasında otomatik | Üretim RAG uygulamaları |
| Provisioned | Sabit, tahmin edilebilir yük | En düşük birim fiyat | Olgunlaşmış, kararlı pipeline |
Aslında — hayır dur, daha doğrusu, Şimdi gelelim asıl meseleye. AI workload’ları — özellikle agentic olanlar — doğası gereği bursty. Bir kullanıcı chatbot’a soru soruyor, arkada 5-6 tool çağrısı oluyor, embedding lookup yapılıyor, sonra 10 dakika sessizlik. Bu pattern serverless veya autoscale için biçilmiş kaftan. Kısacası ritim düzensiz; tam da bu yüzden esnek modlar iş görüyor.
Evet, doğru duydunuz.
Tuhaf ama, Ama dur bir saniye — burada sık yapılan bir hata var. Ekipler baştan provisioned seçiyor çünkü “production’da serverless olmaz” diye bir algı var. Yanlış değil mi? Değil yanı; çoğu senaryoda yanlış bakış açısı bu. Novo Nordisk örneğini düşünün: aylık 240 dolardan 1 doların altına düşmüşler — serverless’a geçerek. Veri modelini yeniden tasarlayarak. Dört ortam çarpanıyla bu neredeyse 960 dolar tasarruf demek.
Benim önerim şu: başlangıçta serverless ile başlayın, trafik paternini 2-3 hafta izleyin, sonra kararınızı verin. Autoscale’e geçiş Cosmos DB’de zaten kolay — portalda birkaç tıklamayla halloluyor. Ama provisioned’dan serverless’a dönmek o kadar pürüzsüz değil; bunu atlamayın derim (ciddiyim)
Türkiye’deki Şirketler İçin Ekstra Not
Türkiye’deki kurumsal müşterilerimde gördüğüm bir şey var: bütçe onay süreçleri uzun olduğu için ekipler genelde “en güvenli”. Provisioned seçeneğini tercih ediyor. Ama bu “güvenli” seçenek aslında en pahalısı olabiliyor. En çok da TL/USD kuru düşünüldüğünde, gereksiz provision edilmiş 400 RU/s bile aylık ciddi bir fark yaratıyor. Eğer FinOps ekibiniz varsa, bu modu genelde challenge etmelerini söyleyin; yoksa kimse dönüp bakmıyor.
Partition Key Tasarımı: Görünmez Maliyet Katili
Vallahi, Hmm, bu konuda biraz düşüneyim… Evet, partition key meselesi çoğu kişinin gözden kaçırdığı ama en çok RU tüketen faktörlerden biri. Kötü bir partition key seçimi cross-partition query’lere yol açıyor ve her cross-partition query ekstra RU yakıyor. Yanı sorun küçük görünse de faturaya etkisi baya sert oluyor.
AI uygulamalarında genellikle şu pattern’i görüyorum: embedding’ler bir container’da, kullanıcı session’ları başka bir container’da, agent state’leri ayrı yerde tutuluyor. Session bazlı sorgulama yapıyorsanız — ki agentic workload’larda genelde öyle — /sessionId veya /userId gibi bir partition key işinizi görür.
Geçen sene bir bankacılık projesinde /documentType diye bir partition key seçilmişti. Kulağa mantıklı geliyor değil mi? Ama düşünün — sadece 3 farklı document type varmış gibi davranıyorsunuz aslında; tüm veriler 3 partition’a sıkışıyor, hot partition oluşuyor, throttling başlıyor, RU tavan yapıyor. Partition key’i /customerId olarak değiştirdikten sonra RU tüketimi %35 düştü. Ciddi söylüyorum, %35. Daha fazla bilgi için SELinux Volume Label Değişikliği: v1.37 Öncesi Hazırlık yazımıza bakabilirsiniz.
/tenantId + /sessionId kombinasyonu kullanarak hem multi-tenant izolasyonu hem de verimli sorgu paterni elde edebilirsiniz. AI workload’ları için bu fena olmayan bir seçenek.
Vektör Arama ve Embedding Maliyetlerini Kontrol Altına Alın
Cosmos DB’nın DiskANN tabanlı vektör arama özelliği — açık konuşayım — oldukça iyi çalışıyor. Ama embedding’leri saklamak ucuz değil; orası ayrı mesele. 1536 boyutlu bir OpenAI embedding’i düşünün: her biri yaklaşık 6 KB yer kaplıyor. 10 milyon döküman chunk’ınız varsa, sadece embedding’ler 60 GB’a yakın yer tutuyor (yanlış duymadınız)
Ve işler burada ilginçleşiyor.
Böyle olunca birkaç strateji öne çıkıyor:
- Quantized Flat Index: Cosmos DB’nın vektör indeksleme seçeneklerinden biri. DiskANN kadar hızlı değil ama storage maliyetini ciddi düşürüyor.
- Embedding boyutunu küçültün: OpenAI’ın
text-embedding-3-smallmodeli 1536 yerine 512 boyut destekliyor. Çoğu senaryo için yeterli oluyor. - TTL (Time-to-Live) kullanın: Eski embedding’leri otomatik sildirin. Chatbot session’ları 30 gün sonra işe yaramıyor zaten. (bence en önemlisi)
Ha bu arada,
Cosmos DB Dynamic Data Masking: Veri Güvenliğinde Yeni Dönem
yazımda Cosmos DB’nın güvenlik tarafını da detaylı ele almıştım — maliyet iyileştirmeu yaparken güvenlikten taviz vermeyin diye hatırlatayım; ikisini birlikte düşünmek lazım. .NET 10 Data Protection Güvenlik Açığı ve Acil Yama yazımızda bu konuya da değinmiştik.
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 Kubernetes’te Production Debug Güvenliği: Rehber yazımıza bakabilirsiniz.
Peki neden?
Sreserved Capacity ve Spot Discount’tan Faydalanın?
This heading appears malformed in source? No—let’s keep meaning intact in HTML form and continue properly in Turkish while preserving the tag structure as given originally would be expected to remain consistent in content flow.
Cosmos DB’de reserved capacity alarak provisioned throughput’ta indirim alabilirsiniz; oranlar süreye göre değişiyor ve özellikle uzun taahhütlerde avantaj artıyor.
Ama tabi — üç yıl taahhüt vermek kolay değil.
Workload’unuzun kararlı olduğundan emin olmanız lazım.
Kısa vadeli dalgalanmalar varsa acele etmeyin.
Peki neden?
süreyi uzatmadan devam edelim:
Benim tavsiyem ilk birkaç ay pay-as-you-go ile çalışmak,
trafik paternini iyice anlamak,
sonra minimum sabit yükünüz kadar reserved capacity almak.
Üstüne gelen spike’lar için autoscale devreye girsin.
Bu hibrit yaklaşım çoğu kurumsal müşterimde en iyi sonucu veriyor.
Bir anda tüm yükü kilitlemek yerine nefes alan bırakıyorsunuz,
işte kritik nokta bu.
Peki neden?
Araya gireyim: Peki şu bağlantıya da bakabilirsiniz:
Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler
yazımda genel bulut FinOps prensiplerine değinmiştim.
Cosmos DB’ye özel olmasa da reservation stratejisi oradaki yaklaşımlarla uyumlu gidiyor.
Yanı tek başına düşünmeyin; resmin tamamı aynı yere çıkıyor. azd Hook’larını Python, TypeScript,.NET ile Yazın yazımızda bu konuya da değinmiştik.
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. Azure SDK Nisan 2026: Kritik Güvenlik Yaması ve Yenilikler yazımızda bu konuya da değinmiştik.
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 ‘da x-ms-request-charge d 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-charge header’ı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
20+ 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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments