IoT SaaS İçin MQTT: Yönetilen Broker Üzerinde Kurun

IoT SaaS için MQTT kullanmak, tek bir üründen pek çok müşteriye gerçek zamanlı cihaz verisi sunmanızı sağlar; ancak yalnızca bu müşterileri ilk cihazdan itibaren doğru şekilde ayırırsanız. Bu rehber, bir izolasyon modelini nasıl seçeceğinizi, kimlik bilgilerini ve topic öneklerini nasıl tasarlayacağınızı, cihazları nasıl dahil edeceğinizi ve arka ucunuzu yönetilen bir broker üzerinde nasıl yapılandıracağınızı gösteriyor; böylece daha hızlı yayına alabilir ve mimariyi yeniden kurmadan ölçeklenebilirsiniz.

Bir IoT SaaS Platformunun Yapısı

Çoğu IoT SaaS ürünü aynı deseni izler. Sahadaki cihazlar telemetri ve durum bilgisi yayınlar. Bir arka uç abone olur, verileri saklar, mantığı değerlendirir ve bir API sunar. Bir web veya mobil uygulama her müşteriye yalnızca kendi cihazlarını gösterir ve komutları geri gönderir. MQTT ortada yer alır; çünkü kesintili bağlantıyı, küçük payload'ları ve çift yönlü mesajlaşmayı iyi yönetir. Protokol sizin için yeniyse bir MQTT broker'ın ne yaptığı ile başlayın.

Broker işletmeniz için paylaşımlı altyapıdır, ancak üzerindeki veriler müşterilerinize aittir. Bundan üç tasarım kararı doğar:

Müşteriler broker'da ne kadar güçlü ayrılıyor?
Cihazlar nasıl tanımlanıyor ve doğrulanıyor?
Arka ucunuzun verileri müşteri bazında yönlendirebilmesi için topic'ler nasıl yapılandırılıyor?

Karar 1: Bir Müşteri İzolasyon Modeli Seçin

Model A: Müşteri Başına Bir Broker

Her müşteri kendi uç nokta kimlik bilgilerine ve kendi topic alanına sahip kendi broker'ını alır. A müşterisinin cihazları, aynı broker ad alanında olmadıkları için B müşterisinin topic'lerine fiziksel olarak abone olamaz. Arka ucunuz her müşteri broker'ına bir client olarak bağlanır.

Bu, en güçlü ayrımı sağlar ve müşteri başına limitleri, müşteri ilişiğini kesmeyi ve veri silmeyi basitleştirir: broker'ı silersiniz. Bedeli, provizyonlanacak daha fazla broker ve pek çok bağlantıyı yöneten bir arka uçtur.

Model B: Topic Önekli Tek Paylaşımlı Broker

Tüm müşterilerin cihazları tek bir broker'a bağlanır ve her müşterinin topic'leri acme/ veya bir müşteri ID'si gibi bir önekle başlar. Arka ucunuz +/devices/+/telemetry topic'ine abone olur ve müşteriyi ilk topic seviyesinden çıkarır.

Bu basit ve verimlidir; ancak bir topic öneki tek başına bir düzenleme kuralıdır, erişim kontrolü sınırı değildir. Broker'daki herhangi bir cihaz #'e abone olabiliyorsa, her müşterinin verisini görebilir. Bu modeli yalnızca tüm cihaz firmware'ini siz kontrol ediyorsanız ve müşteriye dönük hiçbir şey broker'a doğrudan bağlanmıyorsa ya da broker'ınız kiracı başına topic kısıtlamalarını zorunlu kılıyorsa kullanın.

Model C: Kademeli

Küçük müşteriler bir broker'ı paylaşırken, büyük veya mevzuata tabi müşteriler kendi broker'larını, dedicated bir kümeyi ya da kendi bulut hesaplarında bir dağıtımı alır. Bu, pek çok SaaS işletmesinin planlarını fiyatlandırma biçimini yansıtır.

Model	Ayrım gücü	Operasyonel yük	En uygun
A: müşteri başına broker	Güçlü, broker tarafından zorunlu kılınır	Orta	B2B ürünler, müşteriye dönük erişim
B: paylaşımlı broker, önekler	Zorunlu kılmaya bağlı	Düşük	Tamamen kontrol edilen firmware, yalnızca dahili veri
C: kademeli	Önemli olduğu yerde güçlü	Orta	Self-servis ve kurumsal katmanları olan ürünler

Temel kavramlar MQTT kiracı izolasyonu ve çok kiracılı MQTT broker mimarisi yazılarında ele alınır.

Karar 2: Kimlik Bilgisi Tasarımı

Kimlik bilgisi modeliniz, cihazları ne kadar güvenli şekilde dahil edebileceğinizi, iptal edebileceğinizi ve yenileyebileceğinizi belirler.

Cihaz başına client ID'ler. Her cihazın benzersiz ve sabit bir client ID'ye ihtiyacı vardır. Bunu bir seri numarasından veya provizyon kaydından türetin; açılışta üretilen rastgele bir değerden asla türetmeyin, aksi hâlde kalıcı oturumlar devam etmez.
Herkese açık depolarda veya uygulama paketlerinde kimlik bilgisi olmamalı. Mobil ve web uygulamaları cihaz düzeyinde broker kimlik bilgileri tutmamalıdır. Uygulamaların API'nizi çağırmasını ve broker ile arka ucun konuşmasını sağlayın ya da broker'ınız destekliyorsa kısa ömürlü, kapsamı sınırlı kimlik bilgileri verin.
İptal yolu. Bir müşteri ayrıldığında veya bir cihaz çalındığında, diğer cihazlara dokunmadan onu devre dışı bırakabilmeniz gerekir.
Rotasyon yolu. Firmware'in yeni kimlik bilgilerini nasıl alacağını planlayın; örneğin kimliği doğrulanmış bir yapılandırma topic'i üzerinden veya bir OTA güncellemesi sırasında.

Karar 3: Çok Müşterili Yönlendirme İçin Topic Tasarımı

Öngörülebilir bir topic ağacı arka ucu basit tutar ve joker karakterli abonelikleri güvenli kılar. İyi çalışan bir desen:

<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response

Yönergeler:

Müşteriyi en başa koyun; böylece her seviyede bir joker karakter size tam bir müşteri görünümü verir.
Tanımlayıcıları sabit, küçük harfli ve boşluksuz tutun.
Panoların bilinen son durumu hemen görmesi için status üzerinde retained message kullanın.
Komut ve yanıt akışları için kendi yönteminizi icat etmek yerine MQTT 5 response topic'lerini ve correlation data'yı kullanın.
Topic adlarında kişisel veriden kaçının; topic'ler loglarda ve araçlarda görünür.

Model A'da müşteri seviyesi broker tarafından zaten ima edilir; bu nedenle onu topic'ten çıkarabilir veya katmanlar arası tutarlılık için koruyabilirsiniz.

Minimal Bir Arka Uç Veri Alım Servisi

Arka uç abone olur, doğrular ve saklar. paho-mqtt 2.x ve MQTT 5 kullanan bu Python örneği, paylaşımlı bir broker'dan telemetri alır ve müşteriyi topic'ten çıkarır. ConnectMQ Serverless (Paid) üzerinde bu tür veri alım işçilerini, mesajları işçiler arasında dağıtan $share/ingest/+/+/+/telemetry gibi bir paylaşımlı abonelikle yatay olarak ölçekleyebilirsiniz.

import json
import ssl
import paho.mqtt.client as mqtt

SUBSCRIPTION = "+/+/+/telemetry"   # paylaşımlı abonelik olan planlarda $share/ingest/+/+/+/telemetry kullanın

def store(customer, site, device, data):
    # Kendi veritabanı yazma işleminizle değiştirin
    print(f"[{customer}] {site}/{device}: {data}")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Ingest connected:", reason_code)
    client.subscribe(SUBSCRIPTION, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) != 4:
        return
    customer, site, device, _ = parts
    try:
        data = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("Rejected non-JSON payload on", msg.topic)
        return
    store(customer, site, device, data)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()

Veritabanları, bildirimler veya analitik gibi entegrasyonlar bu servise ya da broker'a sıradan MQTT client'lar olarak bağlanan Node-RED ve Telegraf gibi araçlara bağlanır.

ConnectMQ Üzerinde Geliştirmek

ConnectMQ, bu modellerin her birine uyan tam yönetilen bir MQTT hizmetidir. Oluşturduğunuz her broker, otomatik oluşturulan kimlik bilgileri ve bunlara bağlı bir client ID alır; broker'lar paylaşımlı kümede birbirinden izoledir. Bu da Model A'yı kolaylaştırır: müşteri başına bir broker oluşturun, kimlik bilgilerini arka ucunuzda saklayın ve veri alım servisinizi her birine bağlayın.

Plan limitleri SaaS katmanlarıyla doğal olarak eşleşir. Ücretsiz Serverless planı 25 bağlantıya, QoS 1'e ve 256 KB mesajlara kadar destekler; geliştirme ve pilot müşteriler için idealdir. Serverless (Paid) 1.000 bağlantıya, QoS 2'ye, 1 MB mesajlara ve paylaşımlı aboneliklere kadar destekler. Dedicated bir müşteriye izole bir küme sunar; BYOC ise broker'ı sizin veya müşterinizin kontrol ettiği bir bulut hesabında, ConnectMQ yönetiminde çalıştırır.

Portal destek ekiplerine de yardımcı olur: canlı topic gezgini ve tarayıcı içi MQTT client, bir müşterinin cihazlarının gerçekte ne gönderdiğini görmenizi sağlar; cihaz görünümü endüstriyel müşteriler için ekipmanları ISA-95 seviyelerine göre gruplar; uyarı kaydıyla birlikte eşik tabanlı uyarı kuralları da aralık dışı değerleri işaretler.

IoT SaaS'ınız İçin Yayına Alma Kontrol Listesi

Fiyatlandırma katmanı başına seçilmiş ve belgelenmiş izolasyon modeli.
Cihaz başına benzersiz client ID ve kimlik bilgileri, bir iptal prosedürüyle.
Belgelenmiş ve arka uçta doğrulanan topic ağacı.
Yalnızca 8883 (cihazlar) ve 8084 (tarayıcı client'ları) portlarında TLS.
Tüm firmware'lerde üstel backoff ve jitter ile yeniden bağlanma.
Mümkün olan yerlerde paylaşımlı aboneliklerle ölçeklenen veri alım servisi.
Firmware ve arka uç testleri için ayrı bir staging broker.
Müşteri başına bağlantılar ve mesaj akışı için izleme ve uyarılar; MQTT canlı ortam kontrol listesi yazısına bakın.

ConnectMQ ile Başlayın

SaaS'ınızın prototipini kredi kartı gerekmeden app.connectmq.com adresindeki ücretsiz bir Serverless broker üzerinde oluşturun, ardından müşteri kazandıkça her biri için bir broker ekleyin. Hesap oluşturmadan önce fikirlerinizi herkese açık MQTT test broker'ında da test edebilir ve barındırma seçeneklerini karşılaştırmak için bulut MQTT broker rehberini okuyabilirsiniz.

Sık Sorulan Sorular

Her SaaS müşterisi kendi MQTT broker'ını almalı mı?

Müşteriler veya uygulamaları doğrudan bağlanıyorsa ya da sözleşmeler ayrım gerektiriyorsa evet. Müşteri başına bir broker, zorunlu kılınan izolasyon ve kolay müşteri ilişiği kesme sağlar.

Müşterileri ayırmak için topic önekleri yeterli mi?

Verileri düzenlerler; ancak verileri yalnızca broker her client'ın hangi önekleri kullanabileceğini zorunlu kılıyorsa korurlar. Zorunlu kılınmadığında #'e abone olan herhangi bir client her şeyi görür.

Cihaz verilerini tüketen arka ucu nasıl ölçeklerim?

Broker'ın mesajları aralarında dengelemesi için MQTT 5 paylaşımlı aboneliği kullanan birkaç veri alım işçisi çalıştırın.

Mobil uygulamam broker'a doğrudan bağlanabilir mi?

8084 portunda Secure WebSocket üzerinden bağlanabilir, ancak cihaz kimlik bilgilerini uygulamaya gömmekten kaçının. Trafiği API'niz üzerinden yönlendirin veya kullanıcı başına kapsamı sınırlı kimlik bilgileri kullanın.

IoT SaaS İçin MQTT: Yönetilen Bir Broker Üzerinde Çok Müşterili Platform Kurmak