Çok kiracılı (multi-tenant) bir MQTT broker, birbirinden bağımsız pek çok müşteriye veya ekibe paylaşımlı altyapıdan hizmet verirken her birinin mesajlarını, kimliklerini ve kaynak kullanımını ayrı tutar. Bu yazı, bu mimarinin yapı taşlarını, yani ad alanlarını, kimlik bilgilerini ve kotaları, aralarındaki ödünleşimleri ve bir sağlayıcıya sormanız gereken soruları ele alıyor. Sonunda kendi platformunuzu tasarlamak veya başkasınınkini değerlendirmek için kullanabileceğiniz bir zihinsel modele sahip olacaksınız.
Çok Kiracılılık Bir MQTT Broker İçin Ne Anlama Gelir?
MQTT'de her client bir broker'a bağlanır ve topic'lere yayın yapar veya abone olur. Sade bir broker'ın tek ve düz bir topic alanı vardır: #'e abone olmasına izin verilen herhangi bir client her şeyi görür. Bu tek bir uygulama için sorun değildir; ancak iki müşteri aynı sunucuyu paylaştığı anda tehlikelidir.
Kiracı (tenant), bir izolasyon birimidir: bir müşteri, bir iş birimi, staging gibi bir ortam ya da bir ürün hattı. Çok kiracılılık, bağlantılar aynı süreçlere ve makinelere düşse bile broker'ın her kiracıya kendi özel broker'ı varmış gibi davranması demektir. Buna ulaşmak için mimarinin her bağlantı ve her mesaj için üç soruyu yanıtlaması gerekir:
- Bu client hangi kiracıya ait? (kimlik)
- Bu client hangi topic'leri görebilir ve yazabilir? (ad alanı)
- Bu kiracı paylaşımlı kapasitenin ne kadarını tüketebilir? (kaynaklar)
Genel olarak broker'lar hakkında bilgilerinizi tazelemeniz gerekiyorsa önce bir MQTT broker'ın ne yaptığını okuyun.
Yapı Taşı 1: Kiracı Ad Alanları
Topic Önekleri
En basit yaklaşım bir kuraldır: her kiracının topic'leri tenant-42/site-a/line-1/temperature gibi bir önekle başlar. Ardından broker'ın veya önündeki bir yetkilendirme katmanının, kiracı 42'deki bir client'ın yalnızca tenant-42/ altındaki topic'leri kullanabilmesini zorunlu kılması gerekir. Zorunlu kılınmadığında önek yalnızca düzenli bir adlandırmadır, izolasyon değildir.
Mountpoint'ler ve Sanal Host'lar
Bazı broker'lar mountpoint veya benzeri mekanizmaları destekler: broker, bir client'ın kullandığı her topic'in başına sessizce kiracıya özgü bir önek ekler. Client sensors/temp topic'ine yayın yapar; broker bunu tenant-42/sensors/temp olarak saklar ve yönlendirir. Client'lar kendi ad alanlarının dışındaki bir topic'i ifade bile edemez ve # aboneliği yalnızca kiracının alanı içinde eşleşir. Doğru client davranışına dayanmadığı için bu, kuraldan daha güçlüdür.
Ayrı Mantıksal Broker'lar
En güçlü mantıksal model, alttaki küme paylaşımlı olsa bile her kiracıya kendi kimlik bilgileri, kendi oturum deposu ve kendi retained message'ları olan ayrı bir broker örneği kimliği verir. Bir kiracıdaki joker karakterli abonelik başka bir kiracıdaki topic ile asla eşleşemez; çünkü bir topic ağacını hiç paylaşmazlar.
Yapı Taşı 2: Kimlik ve Kimlik Bilgileri
İzolasyon CONNECT anında başlar. Sağlam bir tasarım, her kimlik bilgisini tam olarak bir kiracıya bağlar ve herhangi bir topic işlemi kabul edilmeden önce onu kontrol eder.
- Kiracı başına kimlik bilgileri. Kullanıcı adları ve parolalar, token'lar veya client sertifikaları kiracı başına, ideal olarak cihaz başına verilir.
- Client ID bağlama. Client ID'yi verilen kimlik bilgisine bağlamak, bir cihazın başka bir cihazı taklit etmesini ve başkasının oturumunu ele geçirmesini engeller; çünkü MQTT, aynı client ID ile yeni bir bağlantı geldiğinde eski bağlantıyı keser.
- Kaba kuvvet koruması. Paylaşımlı altyapı daha büyük bir hedeftir. Hız sınırlama ve tekrarlanan başarısız oturum açma denemelerinden sonra adresleri engelleme, tüm kiracıları aynı anda korur.
- Gizli anahtar rotasyonu. Kiracıların, operatörden herhangi bir şeyi yeniden başlatmasını istemeden kimlik bilgilerini yenileyebilmesi gerekir.
Yapı Taşı 3: Kaynak Kotaları ve Gürültülü Komşular
Gürültülü komşu (noisy neighbor) sorunu, paylaşımlı altyapının klasik riskidir. Bir kiracının sıkı bir döngüde yeniden bağlanan firmware hatası ya da olabildiğince hızlı yayın yapan bir betiği, diğer kiracıların ihtiyaç duyduğu CPU, bellek ve bant genişliğini tüketebilir. Kotalar bu riski sınırlı, kiracı başına bir soruna dönüştürür.
| Kaynak | Neden sınırlanır | Tipik uygulama |
|---|---|---|
| Eşzamanlı bağlantılar | Bağlantı başına bellek ve dosya tanımlayıcıları | Limitin üzerindeki CONNECT'i reddetme |
| Mesaj hızı | CPU ve dağıtım (fan-out) maliyeti | Kısma veya bağlantıyı kesme, MQTT 5 reason code |
| Maksimum mesaj boyutu | Bellek sıçramaları, bant genişliği | Aşırı büyük PUBLISH'i reddetme |
| Client başına abonelik | Yönlendirme tablosu boyutu | Limitin üzerindeki SUBSCRIBE'ı reddetme |
| QoS seviyesi | Uçuştaki durum ve yeniden denemeler | Düşürme veya reddetme |
| Oturum süresi dolumu | Saklanan çevrimdışı mesajlar | Süre aralığına üst sınır koyma |
| Retained message'lar | Depolama | Sayı ve boyut limitleri |
MQTT 5 burada yardımcı olur; çünkü broker kendini açıklayabilir. 0x97 (Quota exceeded) reason code'u, iyi yazılmış bir client'a bir yayının neden düşürüldüğünü tahmin etmeye bırakmak yerine bir limite takıldığını söyler. Limitlerin client tarafı için MQTT broker bağlantı kotaları yazısına bakın.
Paylaşımlı Küme mi, Dedicated Küme mi?
Çok kiracılılık bir yelpazedir. Bir uçta tüm kiracılar mantıksal izolasyonla tek bir kümeyi paylaşır. Diğer uçta her kiracı dedicated makinelere sahip olur. Tablo bu ödünleşimi özetler.
| Özellik | Paylaşımlı çok kiracılı küme | Kiracı başına dedicated küme |
|---|---|---|
| Maliyet verimliliği | Yüksek, kapasite havuzlanır | Daha düşük, kapasite ayrılır |
| İzolasyon | Mantıksal (kimlik, ad alanı, kotalar) | Fiziksel |
| Gürültülü komşuya maruz kalma | Kotalarla sınırlı | Diğer kiracılardan yok |
| Provizyon süresi | Saniyeler | Daha uzun |
| Özel limitler | Plana dayalı | Kiracıya göre boyutlandırılmış |
| Tipik kullanım | Prototipler, küçük ve orta ölçekli filolar | Büyük filolar, katı gereksinimler |
Çoğu sağlayıcı ikisini de sunar ve ihtiyaçlar büyüdükçe kiracının birinden diğerine geçmesine izin verir. Müşterilerin ne kadar güçlü ayrılması gerektiği sorusu MQTT kiracı izolasyonu yazısında daha derinlemesine ele alınır.
Çok Kiracılı Bir Broker'ı İşletmek
İzolasyonu tasarlamak işin yarısıdır. Onu işletmek diğer yarısıdır:
- Kiracı başına gözlemlenebilirlik. Metriklerin bir kiracı boyutuna ihtiyacı vardır: yalnızca küme toplamları değil, kiracı başına bağlantılar, mesaj hızları ve kota reddetmeleri.
- Adil güncellemeler. Kademeli yeniden başlatmalar yeniden bağlanma yükünü yaymalıdır; client'lar da pek çok kiracıdan binlerce cihazın aynı anda geri dönmemesi için rastgeleleştirilmiş backoff kullanmalıdır.
- Kötüye kullanımla başa çıkma. Flood koruması tüm kümeye değil, sorunlu kiracıya veya client'a etki etmelidir.
- Kiracı yaşam döngüsü. Kiracı oluşturma, askıya alma ve silme işlemleri oturumları, retained message'ları ve kimlik bilgilerini tamamen temizlemelidir.
ConnectMQ Çok Kiracılılığı Nasıl Uygular?
ConnectMQ, çok kiracılı bir platform olarak inşa edilmiştir. Serverless planlarında pek çok broker bir kümeyi paylaşır ve her broker diğerlerinden izoledir: kendi otomatik oluşturulmuş kullanıcı adına, parolasına ve client ID'sine sahiptir, client ID'ler verilen kimlik bilgilerine bağlıdır ve plan başına kotalar bağlantıları, QoS'u ve mesaj boyutunu sınırlar. Ücretsiz Serverless planı 25 bağlantıya, QoS 1'e ve 256 KB mesajlara kadar izin verir; ücretli Serverless planı bunu 1.000 bağlantıya, QoS 2'ye, 1 MB mesajlara ve paylaşımlı aboneliklere çıkarır.
Flood koruması ve tekrarlanan başarısız oturum açma denemelerinden sonra IP engelleme, paylaşımlı kümedeki her kiracıyı korur. Bir client limitlerini aştığında MQTT 5 client'ları 0x97 reason code'unu alır; böylece neden görünür olur. Mantıksal izolasyon yeterli değilse Dedicated planı size izole bir küme verir; BYOC ise broker'ı, ConnectMQ yönetmeye devam ederken sizin bulut hesabınızda çalıştırır.
Kiracı Kapsamlı Bir Topic Düzeni Deneyin
Kendi broker'ınızın içinde bile tutarlı bir topic düzeni, çok kiracılı uygulamalar hakkında düşünmeyi kolaylaştırır. Bu MQTT.js örneği, herkese açık MQTT test broker'ında kiracı ve saha önekli bir topic'e yayın yapar; herkese açık alanın herkes tarafından okunabildiğini unutmayın.
const mqtt = require("mqtt");
const tenant = "tenant-demo-91b2";
const base = `connectmq/demo/${tenant}`;
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
clientId: `${tenant}-gw-01`,
protocolVersion: 5,
});
client.on("connect", () => {
client.subscribe(`${base}/+/+/temperature`, { qos: 1 });
setInterval(() => {
const payload = JSON.stringify({ value: 20 + Math.random() * 5, ts: Date.now() });
client.publish(`${base}/site-a/line-1/temperature`, payload, { qos: 1 });
}, 5000);
});
client.on("message", (topic, message) => console.log(topic, message.toString()));
client.on("error", (err) => console.error("MQTT error:", err.message));
Özel bir ConnectMQ broker'ında username: "YOUR_USERNAME" ve password: "YOUR_PASSWORD" ekleyin ve portaldaki YOUR_CLIENT_ID değerini kullanın.
ConnectMQ ile Başlayın
Kiracı izolasyonunu kendiniz kurmakla uğraşmayın. Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz, izole bir Serverless broker oluşturun ve daha güçlü ayrıma ihtiyaç duyduğunuzda Dedicated veya BYOC'ye ölçeklendirin. Barındırılan MQTT broker modeli hakkında daha fazla bilgi edinin veya kapsamlı bulut MQTT broker rehberine göz atın.
Sık Sorulan Sorular
Kiracıları ayırmak için bir topic öneki yeterli mi?
Yalnızca broker bunu zorunlu kılıyorsa. Zorunlu kılınmayan bir önek bir adlandırma kuralıdır; #'e abone olan bir client yine de diğer kiracıların mesajlarını görür.
MQTT'de gürültülü komşu sorunu nedir?
Bir kiracının yoğun veya hatalı trafiğinin paylaşımlı broker kaynaklarını tüketip diğerlerinin hizmetini bozmasıyla ortaya çıkar. Kiracı başına kotalar ve flood koruması hasarı sınırlar.
Çok kiracılı bir broker client kodumu etkiler mi?
Genellikle hayır. Client'lar standart MQTT kullanır; kiracı sınırı, bağlandığınız kimlik bilgileri ve uç nokta ile tanımlanır.
Paylaşımlı bir broker'dan dedicated bir broker'a ne zaman geçmeliyim?
Paylaşılmayan öngörülebilir kapasiteye, paylaşımlı plan kotalarının üzerinde limitlere ya da fiziksel izolasyon gerektiren bir politikaya ihtiyaç duyduğunuzda geçin.
