Public ve Private MQTT Broker: Ne Zaman Geçiş Yapmalı?

Neredeyse her MQTT projesi public bir broker’da başlar. Bir eğitimden broker.hivemq.com ya da broker.emqx.io adresini kopyalarsınız, kimlik bilgisi olmadan bağlanırsınız ve mesajlar saniyeler içinde akmaya başlar. Public broker’ların var olma nedeni tam olarak bu hızdır. Ancak onları kolay kılan aynı açıklık, deneylerin ötesindeki her şey için onları uygunsuz kılar. Bu rehber, ne zaman kalmanız ve ne zaman geçmeniz gerektiğini bilmeniz için artıları ve eksileri dürüstçe ortaya koyuyor.

Public bir MQTT broker’ı aslında nedir

Public broker, internetteki herkesten anonim bağlantı kabul eden paylaşımlı bir MQTT sunucusudur. Üreticiler ve açık kaynak projeleri bunları demo ve birlikte çalışabilirlik (interoperability) sandbox’ı olarak işletir. Public broker listemiz popüler olanları kapsıyor. Belirleyici özellikleri şunlardır:

• Kayıt gerekmez ve genellikle kullanıcı adı veya parola yoktur.
• Dünyadaki tüm kullanıcılar için tek bir ortak topic ad alanı (namespace) vardır.
• Desteklenen bir servis değil, test amaçlı “elden gelenin en iyisi” (best-effort) düzeyinde işletilir.

Public sandbox’ların gerçek riskleri

1. Topic’lerinizi herkes okuyabilir ve yazabilir

Kimlik doğrulama ve erişim kontrolü olmadığından, # topic’ine abone olan biri broker’daki her mesajı alır — sizinkiler dahil. Herkes komut topic’lerinize de yayın yapabilir. Bir cihaz home/garage/door/set topic’ini dinliyorsa, bir yabancı kapıyı açabilir. Tahmin edilmesi zor topic adları çakışmaları azaltır ama güvenlik sağlamaz: # topic’ine abone olan herkes onları görür.

2. Retained çöpler ve bayat durum bilgisi

Retained mesajlar biri onları temizleyene kadar kalır. Public bir broker’da topic’ler diğer kullanıcılardan ve eski testlerden kalan retained payload’larla doludur ve herkes sizin retained durumunuzun üzerine yazabilir. Abonelik sırasında gelen retained değere güvenen bir dashboard, hiç size ait olmamış verileri gösterebilir. Retention’ın nasıl çalıştığı için MQTT retained mesajlar yazısına bakın.

3. Topic ve client ID çakışmaları

test/temperature gibi genel topic’ler, aynı eğitimi takip eden herkesle paylaşılır. Genel client ID’ler daha da kötüdür: başka biri sizin ID’nizle bağlandığında broker sizin bağlantınızı keser ve her iki client da bir yeniden bağlanma döngüsüne girer. Ayrıntılar MQTT bağlantı hataları yazısında.

4. SLA yok, destek yok, önceden haber yok

Public broker’lar herhangi bir anda yeniden başlatılabilir, güncellenebilir veya hız sınırına tabi tutulabilir. Bazıları bilerek geliştirme sürümleri çalıştırır. Bir sandbox için bu sorun değildir, ancak bir demonun bir müşterinin önünde, sizin göremeyeceğiniz ya da düzeltemeyeceğiniz nedenlerle başarısız olabileceği anlamına gelir.

5. Hız sınırları ve eksik özellikler

İşletmeciler paylaşımlı altyapıyı bağlantı, mesaj hızı ve payload sınırlarıyla korur; bu sınırlar belgelenmemiş olabilir. Ayrıca production’ın dayandığı özellikleri test edemezsiniz: kimlik doğrulama, topic bazında yetkiler, client sertifikaları, bridging veya kalıcılık (persistence) ayarları.

Public bir broker’ın tamamen yeterli olduğu durumlar

• QoS, wildcard’lar ve Last Will gibi MQTT kavramlarını öğrenmek.
• Yeni bir client kütüphanesinin veya cihaz firmware’inin bağlanıp yayın yapabildiğini kontrol etmek.
• Sahte verilerle ve rastgele bir topic önekiyle hızlı demolar yapmak.
• Bir hatayı tarafsız, iyi bilinen bir broker üzerinde yeniden üretmek.

Eğer kullanıyorsanız, birkaç alışkanlık edinin:

# Random prefix + random client ID = fewer collisions
PREFIX="testmqtt/$(openssl rand -hex 4)"
mosquitto_sub -h broker.emqx.io -i "sub-$(openssl rand -hex 4)" -t "$PREFIX/#" -v

Public bir broker’ı güvenle deneyin

Geçiş zamanının geldiğini gösteren işaretler

1. Mesajlarınız herkese açık paylaşmayacağınız herhangi bir şey içeriyor.
2. Cihazlar MQTT üzerinden komut kabul ediyor.
3. Sizden başka biri buna bağımlı — bir ekip arkadaşı, bir pilot müşteri, bir demo.
4. Kimlik doğrulamayı, ACL’leri veya TLS client sertifikalarını test etmeniz gerekiyor.
5. Açıklanamayan bağlantı kopmaları, hız kısıtlamaları veya yabancı mesajlarla karşılaştınız.

Özel (private) bir broker için seçenekleriniz

Self-hosting sağlam bir seçimdir ve tam kontrol sağlar; bedeli ise süregelen iştir — sertifika yenilemeleri, işletim sistemi yamaları, yedeklemeler ve alarm yönetimi. Yönetilen bir broker, bu işleri yapmak zorunda kalmamanız karşılığında kontrolün bir kısmından vazgeçmenizi gerektirir.

Mantıklı bir yol: öğrenmek için public, geri kalan her şey için private

Bir kez ve sonsuza dek seçim yapmak zorunda değilsiniz. Pek çok ekip ilk öğleden sonrası için public bir sandbox kullanır — bir kütüphanenin çalıştığını ve topic tasarımının mantıklı olduğunu doğrulamak için — ve gerçek cihazlar veya ekip arkadaşları devreye girer girmez özel bir broker’a geçer. Bu noktadan itibaren development, staging ve production’ın her biri kendi broker’ına ya da kendi kimlik bilgilerine sahip olur; böylece bir test script’i asla yanlışlıkla production topic’lerine yayın yapamaz.

Bağlantı bilgilerini (URL, kullanıcı adı, parola) ilk günden itibaren yapılandırmada veya ortam değişkenlerinde tutun. Böylece broker değiştirmek bir kod değişikliği değil, bir dağıtım (deployment) değişikliği olur ve aynı build’i bir demo için public bir broker’a, bir pilot için de özel bir broker’a yönlendirebilirsiniz.

Özel veya yönetilen bir broker’da nelere bakmalısınız

• İzolasyon: paylaşımlı bir topic ağacı değil, size ait bir instance veya namespace.
• Kimlik doğrulama: en azından client başına kullanıcı adı/parola; ideal olarak cihaz başına kimlik bilgileri.
• Yetkilendirme: bir sensörün yalnızca kendi topic’lerine yayın yapabilmesi için topic bazında erişim kontrolü.
• Şifreleme: 8883 üzerinde TLS ve tarayıcı uygulamaları için güvenli WebSocket. MQTT port’ları yazısına bakın.
• Protokol desteği: eski cihazlar ile yeni özelliklerin bir arada var olabilmesi için MQTT 3.1.1 ve MQTT 5.
• Standart uç noktalar: düz host ve port; böylece ileride geçiş yapmak yalnızca yapılandırma değişikliği anlamına gelir.
• Görünürlük: bağlı client’ları ve bir bağlantının neden reddedildiğini görebilmenin bir yolu.

Geçiş çoğunlukla bir yapılandırma işidir

MQTT standart bir protokol olduğu için public bir broker’dan özel bir broker’a geçmek uygulama mantığına nadiren dokunur:

// Before: public sandbox
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

// After: private broker with credentials over TLS
mqtt.connect(process.env.MQTT_URL, {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `sensor-${deviceSerial}`,
});

Bu geçişi topic hiyerarşinizi düzenlemek için de bir fırsat olarak görün — tutarlı bir yapı, erişim kurallarını yazmayı çok daha kolay hale getirir. MQTT topic’leri ve wildcard’lar yazısı ölçeklenen adlandırma kalıplarını ele alıyor; filtrelerinizi de topic eşleştirici ile kontrol edebilirsiniz.

Sıkça sorulan sorular