Dedicated MQTT Broker: Serverless Size Dar Geldiğinde

Dedicated bir MQTT broker, tek bir müşteriye paylaşımlı bir kümenin bir dilimi yerine izole bir broker kümesi verir; böylece performans ve kapasite yalnızca sizin filonuza ayrılır. Bu rehber izolasyonun size ne kazandırdığını, serverless bir katmanı aştığınızın işaretlerini, geçmeden önce kapasiteyi nasıl planlayacağınızı ve ConnectMQ Serverless'tan Dedicated'a geçiş için pratik bir kontrol listesini açıklıyor.

Dedicated MQTT Broker Nedir

Serverless bir katmanda birçok kiracı tek bir kümeyi paylaşır ve kimlik bilgileri, topic isim alanları ve kotalarla mantıksal olarak ayrılır. Dedicated bir kurulum bu paylaşımı ortadan kaldırır: sağlayıcı yalnızca sizin kuruluşunuza hizmet veren bir broker kümesi çalıştırır. Hâlâ barındırılan bir MQTT broker olduğu için sunucuları, işletim sistemlerini veya sertifikaları yine siz yönetmezsiniz; ancak uç noktanızın arkasındaki işlem gücü, bellek ve ağ başka kimseyle paylaşılmaz.

Bu ayrım küçük filolar için insanların beklediğinden daha az, büyük veya gecikmeye duyarlı filolar için ise beklediğinden çok daha fazla önemlidir. Barındırma modelleri arasında hâlâ üst düzeyde karar veriyorsanız bulut MQTT broker ana rehberi tüm tabloyu açıklıyor.

İzolasyon Size Ne Kazandırır

Öngörülebilir Performans

Paylaşımlı bir kümede kotalar herhangi bir kiracının kaynakları tekeline almasını engeller, ancak trafiğiniz yine de diğer herkesinkiyle yan yana akar. Dedicated bir MQTT broker'da başka bir şirketten gelen bir ani yükseliş sizi hiçbir şekilde etkileyemez. Gecikme ve verim kendi iş yükünüze bağlıdır; bu da davranışı akıl yürütmeyi ve test etmeyi kolaylaştırır.

Etrafında Plan Yapabileceğiniz Kapasite Payı

Paylaşımlı katmanların plan başına sabit kotaları vardır. Dedicated bir küme beklenen yükünüze göre boyutlandırılır; böylece ortalama kiracı için tasarlanmış bir tavana çarpmak yerine kapasite payını bilinçli olarak planlarsınız.

Daha Net Bir Güvenlik ve Uyumluluk Hikâyesi

Bazı güvenlik incelemeleri basit bir soru sorar: başka herhangi bir müşterinin trafiği aynı broker sürecine dokunuyor mu? Dedicated barındırmada cevap hayırdır. Paylaşımlı katman teknik olarak iyi izole edilmiş olsa bile bu, satın alma görüşmelerini çoğu zaman kısaltır.

Tasarım Üzerinde Daha Az Kısıt

Geniş fan-out, shared subscription üzerindeki çok sayıda backend tüketicisi, daha büyük payload'lar ve QoS 2 akışlarının hepsini, küme size ait olduğunda karşılamak daha kolaydır.

Serverless'ı Aştığınızın İşaretleri

Bu sinyalleri izleyin. Tek başına biri taşınmak için mutlaka bir neden değildir; birkaçı bir aradaysa genellikle öyledir.

ConnectMQ'nun Serverless (Paid) planı 1.000'e kadar bağlantıyı, QoS 2'yi, 1 MB mesajları ve shared subscription'ı destekler; bu birçok ürün için fazlasıyla yeterlidir. Dedicated, paylaşımlı bir kümede daha yüksek kotalar yerine kendinize ait izole bir küme istediğiniz durumlar içindir.

Dedicated Bir Kurulum İçin Kapasite Planlaması

İyi bir kapasite planlaması broker benchmark'larından değil, cihazlarınızdan başlar. Bu rakamları adım adım hesaplayın ve yazın; kümenizi boyutlandırırken konuşacağınız şeyler bunlardır.

1. Tepe eşzamanlı bağlantılar. Cihazlar, ağ geçitleri, backend servisleri, dashboard'lar ve test araçlarının hepsi sayılır. Yeniden bağlanma fırtınası senaryosunu ekleyin: bir ağ kesintisinden sonra her cihaz kısa bir zaman diliminde yeniden bağlanır.
2. Saniyedeki gelen mesajlar. Cihaz sayısını yayın hızıyla çarpın. Her 10 saniyede bir mesaj gönderen 2.000 cihaz ortalama saniyede 200 mesaj eder; ancak hizalanma (cihazların dakika başında raporlaması) tepeler yaratır.
3. Giden fan-out. Yayımlanan her mesaj, eşleşen her abonelik için bir kez teslim edilir. Bir dashboard, bir historian ve bir uyarı servisi tarafından okunan mesaj üç teslimattır.
4. Payload boyutu. Ortalama ve maksimum. Kompakt JSON veya ikili payload'lar bant genişliğini ve broker belleğini azaltır.
5. QoS karışımı. QoS 1 ve 2, QoS 0'a kıyasla onay trafiği ve in-flight durum ekler. Bkz. MQTT QoS seviyeleri.
6. Oturum durumu. Çevrimdışı istemciler için kuyruğa alınmış mesajlar içeren kalıcı oturumlar bellek tüketir. Terk edilmiş oturumların birikmemesi için session expiry ayarlayın.
7. Retained message'lar. Durum topic'i başına bir retained message ucuzdur; milyonlarca eskimiş retained topic ise değildir.
8. Büyüme. Bugünkü sayı yerine önümüzdeki 12 ila 18 aylık filo büyümesine göre plan yapın.

Düz metin hâlinde basit bir boyutlandırma çalışma sayfası ekibinizi aynı noktada buluşturmaya yardımcı olur:

Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s   -> ~200 msg/s inbound
Avg subscribers per message .... 2      -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x

Geçmeden Önce Ölçün

Geçiş yapmadan önce serverless broker'ınızdan gerçek rakamları toplayın. Üst seviye topic başına mesajları sayan küçük bir Python abonesi size hızlı bir temel çizgi verir.

import collections
import ssl
import time

import paho.mqtt.client as mqtt

counts = collections.Counter()
start = time.time()


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe("#", qos=0)


def on_message(client, userdata, msg):
    counts[msg.topic.split("/")[0]] += 1
    elapsed = time.time() - start
    if elapsed >= 60:
        for prefix, n in counts.most_common():
            print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
        counts.clear()
        globals()["start"] = time.time()


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("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Hem trafiği hem de bağlantı davranışını anlamak için bunu portal dashboard'u ve belirli bir istemcinin bağlı olup olmadığını gösteren $SYS/broker/connection/{clientId}/state topic'i ile birleştirin.

Geçiş Kontrol Listesi: Serverless'tan Dedicated'a

Dedicated bir MQTT broker aynı portlarda (1883, 8883, 8083 ve /mqtt ile 8084) aynı MQTT 3.1.1 ve 5.0 protokolünü konuştuğu için geçiş büyük ölçüde bir yapılandırma çalışmasıdır.

1. Uç noktayı yapılandırılabilir yapın. Hostname, port, kullanıcı adı, parola ve client ID firmware'e derlenmişse önce bunu düzeltin. Bunları NVS'te, bir yapılandırma dosyasında veya provisioning verisinde saklayın.
2. Dedicated broker'ı talep edin ve hazırlayın. Dedicated ortam için portaldan yeni kimlik bilgileri alın.
3. Önce backend tüketicilerini taşıyın. Her backend servisinin bir kopyasını yeni broker'a yönlendirin ve test trafiğini aldığını doğrulayın.
4. Geçiş sırasında kendi aracınızla köprü kurun. Cihazlar günler veya haftalar içinde taşınacaksa, eski broker'da abone olup yeni broker'da yeniden yayımlayan küçük bir aktarıcı (Node-RED veya kısa bir Python betiği) çalıştırın. ConnectMQ yerleşik köprüler sunmaz, bu yüzden bu iş harici bir MQTT istemcisiyle yapılır.
5. Cihazları dalgalar hâlinde taşıyın. Küçük bir yüzdeyi güncelleyin, bağlantı durumunu ve hata günlüklerini izleyin, ardından devam edin.
6. Retained durumu yeniden yayımlayın. Retained message'lar otomatik olarak taşınmaz; cihazların bağlandıklarında mevcut durumlarını yayımlamasını sağlayın.
7. Eski broker'ı emekliye ayırın. Eskisinde hiçbir cihaz bağlantısı kalmadığında aktarıcıyı durdurun ve devreden çıkarın.

Yaygın tuzaklar: hâlâ eski hostname'i gösteren dashboard'ları ve betikleri unutmak, ortamlar arasında çakışan sabit kodlu client ID'ler ve geçiş sonrasında eksik kalan retained durum. Geçişler kimlik bilgilerini yenilemek için doğal bir an olduğundan, aynı zamanda MQTT güvenlik en iyi uygulamaları rehberimizi okumaya değer.

Dedicated, BYOC mu Yoksa Enterprise mı?

Dedicated tek izole seçenek değildir. Kuruluşunuz broker'ın kendi bulut hesabında çalışmasını istiyorsa, BYOC onu oraya dağıtır ve ConnectMQ yönetir. Her şeyi kendiniz işletmeniz gerekiyorsa Self Managed Enterprise bunu karşılar. Kurumsal MQTT broker rehberi bu modelleri tipik kurumsal gereksinimlere göre karşılaştırıyor.

ConnectMQ ile Dedicated Bir Broker'a Geçin

Çoğu ekip app.connectmq.com adresinde ücretsiz Serverless planıyla (kredi kartı gerekmez) başlar, gerçek trafiği ölçer ve izolasyon ile kapasite payı öncelik hâline geldiğinde Dedicated bir kümeye geçer. ConnectMQ planlar arasında aynı protokolleri, portları ve portal araçlarını korur; böylece cihazlarınız, topic gezgininiz, dashboard'larınız ve uyarı kurallarınız geçişten sonra da aynı şekilde çalışmaya devam eder.

Sık Sorulan Sorular

Dedicated bir MQTT broker serverless'tan daha mı hızlıdır?

Ortalamada mutlaka değil, ancak kümeyi başka hiçbir kiracı paylaşmadığı için daha öngörülebilirdir. Fayda en çok sürekli yük altında ve ani yükselişler sırasında görülür.

Dedicated'a geçmek için cihaz firmware'ini yeniden yazmam gerekir mi?

Bağlantı ayarları yapılandırılabilir durumdaysa hayır. Protokol ve portlar aynı kalır, yalnızca hostname ve kimlik bilgileri değişir.

Dedicated'a geçtikten sonra serverless bir broker'ı tutmaya devam edebilir miyim?

Evet. Birçok ekip geliştirme ve test için ücretsiz bir serverless broker tutar ve üretimi dedicated kümede çalıştırır.

Dedicated bir broker bölgeler arası replikasyon içerir mi?

Bunu varsaymayın. Belirli kurulum hakkında soru sorun ve cihazları, herhangi bir broker yeniden başlatmasından temiz bir şekilde toparlanmaları için backoff ile yeniden bağlanacak ve durumu yeniden yayımlayacak şekilde tasarlayın.