Bir MQTT broker SLA'sı, sağlayıcının erişilebilirlik konusundaki yazılı taahhüdüdür ve küçük puntolu ayrıntılar, manşetteki yüzde kadar önemlidir. Bu yazı, yaygın çalışma süresi hedeflerini gerçek kesinti dakikalarına çeviriyor, SLA'ların genellikle neyi kapsayıp neyi hariç tuttuğunu açıklıyor ve cihazlarınızı ve uygulamalarınızı, her SLA'nın yine de izin verdiği kesintilerle sorunsuz başa çıkacak şekilde nasıl tasarlayacağınızı gösteriyor.
SLA Nedir, Ne Değildir?
Hizmet seviyesi sözleşmesi (SLA) sözleşmesel bir belgedir. Ölçülebilir bir hedefi (genellikle aylık erişilebilirlik), erişilebilirliğin nasıl ölçüldüğünü ve hedef tutturulamazsa sağlayıcının size neyi borçlu olduğunu tanımlar. Birbiriyle ilişkili üç terim sık sık karıştırılır:
- SLI (hizmet seviyesi göstergesi): başarılı bağlantı denemelerinin yüzdesi gibi ölçülen değer.
- SLO (hizmet seviyesi hedefi): bir ekibin hedeflediği, çoğu zaman SLA'dan daha katı olan dahili hedef.
- SLA (hizmet seviyesi sözleşmesi): sonuçları olan, genellikle hizmet kredileriyle bağlanan harici, sözleşmesel taahhüt.
Kritik nokta şudur: SLA kesintileri önlemez. Ne kadar erişilemezliğin kabul edilebilir olduğunu ve daha fazlası olduğunda nasıl tazmin edileceğinizi tanımlar. Sisteminizin yine de SLA'nın izin verdiği kesintiyle başa çıkması gerekir.
Kesinti Dakikalarıyla Çalışma Süresi Yüzdeleri
"Dokuzlar" arasındaki farklar göründüğünden daha büyüktür. Tablo, yaklaşık 30,4 günlük ortalama bir ay ve 365 günlük bir yıl kullanır.
| Erişilebilirlik | Aylık kesinti | Yıllık kesinti |
|---|---|---|
| %99 | yaklaşık 7 saat 18 dakika | yaklaşık 3 gün 15,6 saat |
| %99,5 | yaklaşık 3 saat 39 dakika | yaklaşık 1 gün 19,8 saat |
| %99,9 | yaklaşık 43,8 dakika | yaklaşık 8,8 saat |
| %99,95 | yaklaşık 21,9 dakika | yaklaşık 4,4 saat |
| %99,99 | yaklaşık 4,4 dakika | yaklaşık 52,6 dakika |
| %99,999 | yaklaşık 26 saniye | yaklaşık 5,3 dakika |
%99,9'dan %99,99'a geçmek, izin verilen kesintiyi on kat azaltır. Bunu başarmak, hata alanları arasında yedeklilik, otomatik yük devretme ve dikkatli değişiklik yönetimi gerektirir; bu yüzden üst seviyeler genellikle dedicated altyapıya ve kurumsal sözleşmelere bağlıdır.
Bu değerleri kendiniz hesaplayabilirsiniz:
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
Bir MQTT Broker SLA'sı Genellikle Neyi Kapsar?
Kesintinin Tanımı
"Erişilemez" kavramının nasıl tanımlandığını okuyun. Bir broker için bu, uç noktanın yeni bağlantı kabul etmemesi, bağlantı denemelerinin belirli bir yüzdesinin başarısız olması ya da mesajların iletilmemesi anlamına gelebilir. Bazı sözleşmeler yalnızca art arda birkaç dakikadan uzun süren kesintileri sayar; bu da kısa aksaklıkların hiç sayılmadığı anlamına gelir.
Ölçüm Yöntemi
Kim ölçüyor ve nereden? Sağlayıcı tarafındaki izleme broker'ı sağlıklı görürken, belirli bir ağdaki cihazlarınız ona ulaşamıyor olabilir. Kredi talep ederken kendi izleme verilerinizi sunup sunamayacağınızı sorun.
Kapsam
Hangi bileşenlerin kapsandığını kontrol edin: bağlantı uç noktaları, TLS ve WebSocket dinleyicileri, yönetim portalı, provizyon için kullanılan API'ler. Portallar ve API'ler çoğu zaman veri düzleminden farklı şekilde kapsanır ya da hiç kapsanmaz.
Hizmet Kredileri
Hedef tutturulamadığında olağan çözüm bir kredidir: aylık ücretin bir yüzdesi; çoğu zaman erişilebilirliğin ne kadar düştüğüne göre kademelendirilir. Krediler genellikle belirli bir süre içinde talep edilmelidir ve bir kesintinin iş üzerindeki etkisiyle nadiren orantılıdır. Kredileri sizin için bir sigorta değil, sağlayıcı için bir teşvik olarak düşünün.
Yaygın İstisnalar
Neredeyse her SLA bazı olayları hariç tutar. Tipik istisnalar şunlardır:
- Önceden duyurulan planlı bakım.
- Müşterinin kendi cihazları, ağları veya yanlış yapılandırmasından kaynaklanan sorunlar.
- Bağlantı veya mesaj kotaları gibi plan limitlerinin aşılması.
- Mücbir sebep olayları.
- Ücretsiz, deneme veya beta katmanları.
- Cihazlarınız ile sağlayıcı arasındaki üçüncü taraf ağlardaki sorunlar.
Özellikle ücretsiz katmanlar nadiren sözleşmesel bir SLA ile gelir. Bu, geliştirme ve pilot projeler için makuldür; ancak kendi müşterilerinize verdiğiniz canlı ortam taahhütleri, açık koşulları olan bir plana dayanmalıdır.
Bileşik Erişilebilirlik: Sisteminiz Bir Zincirdir
Uçtan uca erişilebilirliğiniz broker'ın erişilebilirliği değildir. Bir sensörden gelen mesaj cihazdan, yerel ağdan, mobil veya internet sağlayıcısından, broker'dan, arka ucunuzdan ve veritabanınızdan geçer. Bileşenler seri bağlı olduğunda erişilebilirlikler çarpılır.
Örneğin bir cihaz ağı %99,5, broker %99,9 ve arka ucunuz %99,9 erişilebilirse, zincir kabaca 0,995 x 0,999 x 0,999, yani yaklaşık %99,3 olur. En zayıf halka belirleyicidir. Arka ucunuz tek bir sunucuda çalışırken broker'ın dokuzlarına büyük harcama yapmak pek bir şey kazandırmaz. Mimari desenler için MQTT broker yüksek erişilebilirlik yazısına bakın.
Bir SLA'nın İzin Verdiği Kesinti İçin Tasarım
%99,99'da bile bir broker zaman zaman erişilemez olacaktır. Buna dayanabilen client'lar geliştirin:
- Üstel backoff ve jitter ile yeniden bağlanın; böylece binlerce cihaz aynı anda yeniden bağlanmaz.
- Yerel olarak tamponlayın; cihazlarda ve ağ geçitlerinde, bağlantı geri geldiğinde yayınlayın.
- Kalıcı oturumlar kullanın; uygun bir oturum süresi dolumuyla, böylece çevrimdışı aboneler için QoS 1 ve 2 mesajları kuyruğa alınır.
- Durum için retained message kullanın; böylece panolar yeniden bağlandıktan hemen sonra bilinen son değeri görür.
- Bir Last Will ayarlayın; böylece arka ucunuz bir cihazın beklenmedik şekilde düştüğünü bilir.
- Dışarıdan izleyin; bir heartbeat yayınlayıp alan sentetik bir client ile.
MQTT broker kesintisi rehberi olay tarafını ele alır; MQTT canlı ortam kontrol listesi ise bu noktaları yayın öncesi görevlere dönüştürür.
Erişilebilirlik ile Dayanıklılık Aynı Şey Değildir
Bir erişilebilirlik hedefi, broker'ın bağlantı kabul edip mesaj yönlendirip yönlendirmediğini söyler. Bir olay boyunca her mesajın korunup korunmadığı hakkında hiçbir şey söylemez. Bir broker düğümü yeniden başladığında veya yük devrettiğinde oturumların, kuyruktaki mesajların ve retained message'ların nasıl davrandığını ayrıca sorun ve yanıta göre tasarlayın. Kaybolan bir mesaj maliyetli olacaksa, doğruluk kaynağını cihazda veya arka ucunuzda tutun ve broker'ı bir depo değil bir taşıma katmanı yapın. Destek yanıt süreleri de yakından okunmaya değer, ayrı bir üçüncü taahhüttür.
İmzalamadan Önce Sorulacak Sorular
| Soru | Neden önemli |
|---|---|
| Erişilebilirlik nasıl ve kim tarafından ölçülüyor? | Neyin kesinti sayılacağını belirler |
| Sayılan minimum kesinti süresi nedir? | Kısa kesintiler hariç tutulabilir |
| Planlı bakım hariç tutuluyor mu ve ne kadar önceden bildiriliyor? | Planlı kesinti de cihazları etkiler |
| Hangi bileşenler kapsanıyor? | Portal ve API'ler uç noktalardan farklı olabilir |
| Krediler nasıl hesaplanıyor ve talep ediliyor? | Süre sınırları ve tavanlar geçerlidir |
| Bir durum sayfası ve olay geçmişi var mı? | Gerçek performans geçmişini gösterir |
| Hangi destek yanıt süreleri geçerli? | Çalışma süresi ve destek ayrı taahhütlerdir |
SLA'lar ve ConnectMQ
ConnectMQ, paylaşımlı bir kümedeki ücretsiz Serverless katmanından Dedicated izole kümelere, kendi bulut hesabınızda ConnectMQ tarafından yönetilen BYOC'ye ve Self Managed Enterprise'a kadar birkaç plan sunar. Projeniz sözleşmesel erişilebilirlik koşulları gerektiriyorsa, Dedicated, BYOC veya kurumsal seçenekler için bunları ConnectMQ ekibiyle görüşün ve sunulanı yukarıdaki sorularla gözden geçirin. Koşullar ne olursa olsun, herhangi bir broker kötü bir gün geçirdiğinde filonuzu sağlıklı tutan şey bu yazıdaki client tarafı uygulamalardır.
ConnectMQ ile Başlayın
Yeniden bağlanma ve tamponlama mantığınızı kredi kartı gerekmeden app.connectmq.com adresindeki ücretsiz bir Serverless broker üzerinde geliştirip test edin ya da önce ücretsiz herkese açık MQTT broker üzerinde deneme yapın. Tam yönetilen bir MQTT hizmetinin sizi nelerden kurtardığına ve barındırma modellerinin nasıl karşılaştırıldığına genel bir bakış için bulut MQTT broker rehberini okuyun.
Sık Sorulan Sorular
%99,9 SLA ne kadar kesintiye izin verir?
Ayda yaklaşık 43,8 dakika ya da yılda kabaca 8,8 saat.
SLA cihazlarımın bağlı kalacağını garanti eder mi?
Hayır. Bir erişilebilirlik hedefini ve tutturulamazsa uygulanacak tazminatı tanımlar. Cihazlarınızın yine de yeniden bağlanma mantığına, tamponlamaya ve izlemeye ihtiyacı vardır.
Ücretsiz MQTT broker planları SLA içerir mi?
Ücretsiz katmanlar genellikle sözleşmesel SLA içermez. Bunları geliştirme ve pilot projeler için kullanın, canlı ortam taahhütleri için açık koşulları olan bir plan seçin.
%99,99 her zaman %99,9'dan daha mı iyidir?
On kat daha az kesintiye izin verir; ancak uçtan uca erişilebilirliğiniz zincirdeki her bileşene bağlıdır. Önce en zayıf halkayı iyileştirin.
