Kuyruk bir tampondur, pompa değil
Kuyruk eklemek yavaş bir servisin önüne tampon koyar ama kapasiteyi artırmaz. Irina Scurtu, Azure Service Bus ve Azure Functions örnekleriyle biriken iş yükünün ne zaman eriyeceğini, ne zaman hiç erimeyeceğini sayılarla gösteriyor; consumer ölçeklemenin yükü bir sonraki katmana taşıdığını ve TTL ayarlarının neden kritik olduğunu anlatıyor.
Kilit noktalar
- Kuyruk yükü dengeler, kapasiteyi artırmaz; spayk bittikten sonra boşaltma süresi spayktan uzun olabilir
- Boşaltma hızı headroom'a bağlı: 240.000 mesaj, 300 msg/s headroom ile yaklaşık 13 dakikada erir
- Ortalama geliş hızı sürekli kapasitenin üzerindeyse kuyruk hiç boşalmaz; Service Bus QuotaExceeded ile gönderimi reddeder
- Derinliğe göre ölçeklemede instance sayısı ile maxConcurrentCalls çarpımı downstream'in kaldırabileceğinden fazla olmamalı
- Azure Functions'ta host.json'daki maxConcurrentCalls ile maximum-instance-count / functionAppScaleLimit birlikte sınırlanmalı
- Mesaj yaşını ServiceBusReceivedMessage.EnqueuedTime ile izleyin; TimeToLive ve DeadLetteringOnMessageExpiration'ı birlikte açın
Queue-Based Load Leveling deseni yükü dengeler, azaltmaz. Örneğin saniyede 600 mesaj işleyen consumer'lar 10 dakika boyunca saniyede 1.000 mesaj alırsa 240.000 mesajlık bir birikim oluşur; son giren mesaj yaklaşık 6 dakika 40 saniye bekler ve normal trafiğe dönüldüğünde boşaltma 20 dakikayı aşar, yani süre spaykın kendisinden uzun olur. Boşaltma hızını belirleyen şey kapasite eksi normal trafik, yani headroom'dur.
Ortalama geliş hızı sürekli kapasitenin üzerindeyse hiçbir kuyruk boyutu kurtarmaz; Azure Service Bus bu noktada QuotaExceeded hatasıyla gönderimleri reddeder. Kuyruk derinliğine göre ölçekleme de tek başına çözüm değil: maxConcurrentCalls ile instance sayısı çarpımı veritabanına dayanır. Mesaj yaşını ServiceBusReceivedMessage.EnqueuedTime ile ölçün, TimeToLive ve DeadLetteringOnMessageExpiration ayarlarını birlikte kullanın.
Gerçek dünyada kullanımı
- Kampanya gününde sipariş trafiği patlayan bir e-ticaret API'sinin arkasındaki Service Bus kuyruğunun boşalma süresini hesaplamak
- Azure Functions ile Service Bus tetikleyicisi kullanan bir arka plan işçisinde ölçekleme limitlerini veritabanı kapasitesine göre sabitlemek
- Sürücü konumu bildirimi gibi kısa ömürlü mesajlarda TimeToLive ile eskiyen işi dead-letter'a düşürmek
- Senkron yanıt bekleyen HTTP endpoint'lerinde kuyruğun neden uygun olmadığını değerlendirmek
Neden önemli
Kuyruk eklemek sorunu görünmez kılar ama ortalamayı düşürmez; birkaç sayıyı önceden hesaplamazsanız aylar sonra her sabah biraz daha derin bir birikimle ve kimsenin ne zaman başladığını bilmediği bir gecikmeyle uyanırsınız.