Service Bus Batch İşlemede Mesaj Bazlı Settlement Devrimi
Ne yalan söyleyeyim, Bir finans müşterisinde geçen ay yaşadığımız olay tam olarak şuydu: Azure Functions üzerinde Service Bus trigger’ı batch modda çalışıyordu, 50 mesajlık bir batch geliyordu ve içinden bir tanesi — sadece bir tanesi — bozuk formatlı olduğu için tüm batch başarısız oluyordu. 49 mesaj tekrar kuyruğa düşüyordu. Sonra yine işleniyordu. Sonra aynı bozuk mesaj tekrar geliyordu. Döngü başa sarıyordu. Peki bunu neden söylüyorum? Kısacası, sınır bozucu bir kısır döngüydü.
📋 İçindekiler
-
E sonra? Ek Altyapı Kurmadan Retry Takibi Yapabiliyorsunuz
Ama şu küçük detay baya önemli: abandon yaparken application properties’i değiştirebilmeniz güzel çalışıyor.
RetryCount gibi bir property ekleyip her abandon’da artırabiliyorsunuz; sonra fonksiyonun başında bu değeri kontrol edip mesela 5’ten fazla retry olan mesajı direkt dead-letter’a gönderebiliyorsunuz.Mesaj bazlı settlement ile exponential backoff, retry tracking ve poison message handling’i tek bir Function içinde ek altyapıya gerek kalmadan yapabilirsiniz.
Bu da serverless mesaj işlemenin nihayet düzgün davranması demek.Saha Tarafında Bu İş Nasıl Dürüyor?
Peki Türkiye’deki kurumsal yapılarda durum nasıl? Hmm… açıkçası global dokümantasyonda okuduğunuz kadar pürüzsüz gitmiyor her zaman. Daha fazla bilgi için
Maliyet tarafını da unutmayın.
Batch mode + per-message settlement kullandığınızda Function invocation sayısı düşüyor çünkü aynı anda çok kayıt işliyorsunuz — valla güzel iş çıkarmışlar —. Her kayıt için ayrı settlement API çağrısı yapıyorsunuz.
Çok yüksek throughput senaryolarında — saniyede binlerce ileti gibi — bunun maliyetini hesaba katmak lazım.
Küçük-orta ölçekte pek hissettirmez ama günde milyonlarca ileti varsa TL bazında fark yaratabilir.
Neyse uzatmayayım; nokta net zaten.Böyle event-driven yapılarda agent’lar arası iletişim de ayrı mesele tabiî.
Farklı platformlardaki agent’ların haberleşmesi gerekiyorsa,
A2A v1 ile.NET’te Çapraz Platform Agent İletişimi
// kod değil tabiî :)
yazımda bunu ayrıca anlatmıştım.
Sız ne dersiniz?Python ve JavaScript Tarafında Ne Oluyor?
Yanı, This özellik sadece.NET’e özel değil;
Python. JavaScript/TypeScript tarafında da kullanılabiliyor.
Ama burada küçük bir not düşeyim: her dil SDK’sının olgunluk seviyesi aynı değil,
yanı görünürde benzer duran şeylerin altında ufak farklar çıkabiliyor..NET tarafı en oturmuş olan kısım gibi dürüyor;
settlement aksiyonları temiz ilerliyor,daha tip güvenli diyelim doğrudan type-safe demeyeyim...Sıkça Sorulan Sorular
Per-message settlement için Azure Functions’ın hangi versiyonu lazım?
Isolated worker model (out-of-process) kullanıyorsanız.NET için
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus5.x veya üzeri gerekiyor. In-process model’de de destekleniyor aslında, (yanlış duymadınız). Microsoft yeni projelerde isolated model’i önerdiğini söylüyor — bunu aklınızın bir köşesinde tutun. Python ve Node.js için de en güncel extension bundle’ları kullanmanız yeterli.Dead-letter kuyruğundaki mesajları otomatik tekrar işleyebilir mıyım?
Evet, dead-letter kuyruğuna ayrı bir Function trigger bağlayabilirsiniz. Ama bence bunu hemen otomatikleştirmek yerine, önce mesajın neden dead-letter’a düştüğünü analiz eden bir mekanizma kurmanız çok daha mantıklı. Sız hiç denediniz mi? Yoksa aynı bozuk mesajı sürekli tekrar işlemeye çalışırsınız — yanı tam da kaçınmak istediğimiz o kısır döngüye girmiş olursunuz.
Batch mode’da maxMessageCount’u ne kadar yüksek tutmalıyım?
Dürüst olmak gerekirse, Bu tamamen iş yükünüze bağlı. Tecrübeme göre 16-32 arasında başlayıp monitöring verilerine göre ayarlamak en sağlıklısı. Çok yüksek tutarsanız (belki yanılıyorum ama) — mesela 100+ gibi — lock timeout sorunları yaşayabilirsiniz, hani tüm mesajları işlemeniz lock süresi içinde bitmeyebilir. Çok düşük tutarsanız da batch kullanmanın avantajını kaybedersiniz zaten.
Per-message settlement kullanıyorsam idempotency’ye hâlâ ihtiyaç var mı?
Kısa cevap: evet, ama çok daha az. Complete edilen mesajlar kuyruktan siliniyor, yanı normal akışta duplicate gelmiyor. Açıkçası nadir bir senaryo, ama network partition gibi durumlarda mesaj complete edilmiş olsa bile SDK tarafında onay alınamayıp tekrar işlenebiliyor. Bu yüzden kritik iş süreçlerinde yine de temel seviyede bir idempotency koruması bulundurun.
Peki neden?
Managed Identity ile per-message settlement çalışıyor mu?
Evet, çalışıyor. Ama connection string yerine managed identity kullanıyorsanız, Service Bus namespace’ine doğru RBAC rollerini atadığınızdan emin olun. En azından “Azure Service Bus Data Receiver” rolü gerekiyor — settlement işlemleri için de bu rol ya da “Azure Service Bus Data Owner” yeterli oluyor.
Kaynaklar ve İleri Okuma
Azure Functions Service Bus Trigger — Resmî Dokümantasyon
Per-message Settlement in Azure Service Bus — Azure SDK Blog
Azure Service Bus Message Sessions ve Settlement — Microsoft Learn
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.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
Merve Ş.
Tam da geçen hafta bu sorunla boğuştuğum için yazı çok yerinde geldi. Batch içinde bir mesaj patladığında başarılı olanların da tekrar işlenmesi gerçekten can sıkıcı bir durum, mesaj bazlı settlement ile çözüm mantıklı görünüyor. Bu arada şu yazınız da güzeldi: GPT-5.5 ve Microsoft Foundry: Kurumsal AI Artık Ciddi — https://www.askinkilic.com.tr/gpt-55-ve-microsoft-foundry-kurumsal-ai-artik-ciddi/
Cenk B.
Bunu acı tecrübeyle öğrendim, production’da bir mesaj yüzünden tüm batch’in tekrar işlenmesi ciddi sorun yaratıyor. Mesaj bazlı settlement’a geçince gerçekten fark yaratıyor mu peki, latency açısından bir etkisi oluyor mu?
Yorumlar kapalı.
2 comments