MQTT Broker Yüksek Erişilebilirlik: Kavramlar ve Sorular

MQTT broker yüksek erişilebilirliği, sistemin bir parçası arızalandığında cihazların ve uygulamaların iletişim kurmaya devam etmesiyle ilgilidir ve broker kadar istemcilerinize de bağlıdır. Bu makale temel kavramları, bir failover sırasında oturumlara ve mesajlara gerçekte ne olduğunu, temiz şekilde toparlanan istemcilerin nasıl tasarlanacağını ve ConnectMQ dahil herhangi bir sağlayıcıya güvenmeden önce hangi soruları sormanız gerektiğini açıklıyor.

MQTT İçin Yüksek Erişilebilirlik Ne Anlama Gelir?

Genel altyapı terimleriyle yüksek erişilebilirlik, bir bileşenin arızalanmasının tüm hizmeti uzun süre durdurmayacağı şekilde bir sistem tasarlamak demektir. Bir MQTT broker için bu, üç ayrı soruya ayrılır:

İstemciler hızla yeniden bağlanabiliyor mu? Broker süreci, makine veya ağ yolu arızalanırsa cihazların yeniden bağlanabilmesi ne kadar sürer?
Oturum durumuna ne olur? Çevrimdışı istemciler için abonelikler ve kuyruğa alınmış QoS 1 ve 2 mesajları arızadan sonra korunuyor mu?
İletimdeki mesajlara ne olur? Kabul edilmiş ama henüz teslim edilmemiş mesajlar kayboluyor mu, bir kez mi teslim ediliyor yoksa iki kez mi?

Bunların farklı mimarilerde farklı cevapları vardır ve ilkinde mükemmel olan bir sağlayıcı üçüncüsü hakkında hiçbir taahhütte bulunmayabilir. Hangisine ihtiyacınız olduğu konusunda net olun.

Yaygın Yüksek Erişilebilirlik Mimarileri

Kalıp	Nasıl çalışır	Bir node arızasından ne sağ çıkar	Ödünleşimler
Hızlı yeniden başlatmalı tek node	Arıza durumunda otomatik olarak yeniden başlatılan veya değiştirilen tek bir broker	Yeniden başlatma sonrası bağlantı; durum kalıcılığa bağlı	Basit; yeniden başlatma sırasında kısa kesinti
Aktif-pasif	Birincil arızalandığında bir yedek devralır	Bağlantı; durum yalnızca replike ediliyorsa veya paylaşımlı depolamadaysa	Yedek kapasite atıl bekler
Cluster, aktif-aktif	Birkaç node istemcilere hizmet verir ve mesajları kendi aralarında yönlendirir	Bağlantı; cluster replike ediyorsa durum	Daha karmaşık; node'lar arası koordinasyon yükü
Bölümlenmiş broker'lar	Tesis, kiracı veya bölge başına bağımsız broker'lar	Yalnızca arızalanan bölüm etkilenir	Tek bir global topic alanı yok
İstemci tarafı failover	İstemciler bir birincil ve bir ikincil endpoint bilir	İkincil sağlıklıysa bağlantı	Durum iki broker arasında paylaşılmaz

Bunların hiçbiri her durumda en iyisi değildir. Pek çok güvenilir IoT sistemi, bölüm başına iyi işletilen tek bir broker ile dayanıklı istemcileri birlikte kullanır; çünkü en basit mimari, en az arıza yoluna sahip olandır.

Yönetilen bir plan nereye oturur?

Açık konuşmakta fayda var. ConnectMQ mesaj replikasyonlu clustering sunmaz ve oturumlar ile kuyruğa alınmış mesajlar broker yeniden başlatmaları arasında kalıcı tutulmaz. Bu, istemcilerinizi yeniden bağlanarak, yeniden abone olarak ve önemli olan her şeyi yeniden yayınlayarak bir broker yeniden başlatmasına dayanacak şekilde tasarlamanız gerektiği anlamına gelir; bu zaten her broker'da iyi bir uygulamadır.

Erişilebilirlik planlaması için sunduğu şey ise dağıtım modeli seçimidir. Dedicated plan size izole bir cluster verir; böylece diğer kiracıların trafiği sizinkini etkileyemez. BYOC, broker'ı ConnectMQ tarafından yönetilen şekilde kendi bulut hesabınızda çalıştırır; böylece broker, zaten sizin kontrolünüzde olan altyapı, ağ ve bölge tercihlerinin içinde yaşar. Belirli bir erişilebilirlik hedefine ihtiyacınız varsa, bir rakam varsaymak yerine bunu Dedicated veya BYOC kurulumu için ekiple görüşün.

Failover Sırasında Ne Olur?

Bir broker yeniden başladığında veya bir istemci başka bir node'a taşındığında tipik akış şöyledir:

TCP bağlantısı kopar. İstemci bunu hemen ya da keepalive aralığından sonra fark eder.
Broker arızadan önce işleyebildiyse diğer subscriber'lar Last Will mesajını, aksi halde daha sonra bir durum güncellemesini alır.
İstemci backoff ile yeniden bağlanır.
Broker oturumu hâlâ tutuyorsa CONNACK session present bildirir ve abonelikler yerindedir. Tutmuyorsa istemci temiz bir oturumla başlar ve yeniden abone olmalıdır.
İstemci çevrimdışıyken yayınlanan mesajlar yalnızca broker onları sakladıysa teslim edilir; aksi halde kaybolmuştur.

Pratik sonuç: 4. adımın session present bildireceğini asla varsaymayın. Her bağlantıda yeniden abone olun ve kaybetmeyi göze alamayacağınız her şeyi onaylanana kadar istemcide tutun.

Yüksek Erişilebilirlik İçin İstemci Tasarımı

Dayanıklı istemciler, bir broker failover'ını bir olaydan küçük bir aksaklığa dönüştürür. Aşağıdaki kalıplar her broker'da çalışır.

Her bağlantıda yeniden abone olun

Abonelikleri başlangıç kodu yerine connect callback'ine koyun; böylece oturum durumundan bağımsız olarak her yeniden bağlanmadan sonra geri yüklenirler.

Onaylanana kadar yerelde tamponlayın

Önemli veriler için yerel bir kuyruk tutun ve bir öğeyi ancak broker bir QoS 1 publish'i onayladıktan sonra kaldırın. Store-and-forward MQTT rehberimiz gateway'lerde kalıcı tamponları ele alır.

Endpoint'ler arasında failover yapın

Birden fazla broker işletiyorsanız (örneğin farklı konumlarda iki bağımsız kurulum), istemci bunlar arasında sırayla geçiş yapabilir. Aşağıda paho-mqtt 2.x ile endpoint'ler arasında dönen, bağlantıda yeniden abone olan ve onaylanmamış mesajları bellekte tutan minimal bir Python örneği var.

import json
import random
import threading
import time

import paho.mqtt.client as mqtt

ENDPOINTS = [("broker.connectmq.com", 8883), ("YOUR_SECONDARY_HOST", 8883)]
BASE = "acme/site1/line1/gw-01"
pending = {}              # mid -> (topic, payload), onaylanınca kaldırılır
lock = threading.Lock()

def send(client, topic, payload):
    with lock:
        info = client.publish(topic, payload, qos=1)
        pending[info.mid] = (topic, payload)

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("refused:", reason_code)
        return
    print("connected; session present:", flags.session_present)
    client.subscribe(f"{BASE}/cmd/#", qos=1)           # her zaman yeniden abone ol
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    with lock:
        unacked = list(pending.values())
        pending.clear()
    for topic, payload in unacked:                       # onaylanmamış veriyi yeniden gönder
        send(client, topic, payload)

def on_publish(client, userdata, mid, reason_code, properties):
    with lock:
        pending.pop(mid, None)

def on_message(client, userdata, msg):
    print("command:", msg.topic, msg.payload.decode())

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()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_publish = on_publish
client.on_message = on_message

index, delay = 0, 1
while True:
    host, port = ENDPOINTS[index % len(ENDPOINTS)]
    try:
        client.connect(host, port, keepalive=30)
    except OSError as exc:
        print(f"{host} unreachable: {exc}")
        index += 1
        time.sleep(delay + random.random())              # jitter'lı backoff
        delay = min(delay * 2, 60)
        continue
    delay = 1
    client.loop_start()
    time.sleep(2)                                        # CONNACK'i bekle
    while client.is_connected():
        reading = json.dumps({"ts": int(time.time()), "rpm": 1480})
        send(client, f"{BASE}/telemetry", reading)
        time.sleep(5)
    client.loop_stop()
    print(f"lost {host}, trying the next endpoint")
    index += 1

Canlı ortamda pending yapısını diske kalıcı olarak yazar ve boyutunu sınırlarsınız, ancak yapı aynıdır. QoS 1 mükerrer mesajlara izin verdiğinden, alıcılar bir failover sonrasında bir mesajın iki kez gelmesini tolere etmelidir. Her endpoint'in o broker için geçerli kimlik bilgileri gerektirdiğini unutmayın.

Komutları idempotent yapın

Bir failover'dan sonra bir QoS 1 komutu iki kez gelebilir. Bir komut ID'si ekleyin ve cihazda mükerrerleri yok sayın.

Durumu yeniden yayınlayın, broker'ın saklamasına güvenmeyin

Retained durum ve yapılandırma mesajları kullanışlıdır, ancak broker kalıcılık olmadan yeniden başlarsa bunların yeniden yayınlanması gerekir. Örnekte olduğu gibi cihazların her bağlantıda retained durumu yeniden yayınlamasını sağlayın.

Herhangi Bir MQTT Sağlayıcısına Sorulacak Sorular

Bu listeyi değerlendirmelerde ve RFP'lerde kullanın. Yazılı cevap isteyin ve muğlak cevapları "hayır" olarak kabul edin.

Planım için dağıtım topolojisi nedir: tek node, aktif-pasif mi yoksa cluster mı?
Oturumlar ve kuyruğa alınmış mesajlar bir broker yeniden başlatmasında kalıcı tutuluyor mu?
Mesajlar onaylanmadan önce node'lar arasında replike ediliyor mu?
Bir arızadan sonra istemciler nasıl yönlendiriliyor: aynı hostname, DNS değişikliği mi yoksa yeni bir endpoint mi?
Bir node arızasından sonra tipik kurtarma süresi nedir ve sözleşmeye bağlı mı?
Yayınlanmış bir SLA var mı, neyi kapsıyor ve kredi koşulları neler?
Bakım ve yükseltmeler nasıl yapılıyor ve istemcilerin bağlantısı kopuyor mu?
Durum sayfası nerede ve olaylar nasıl duyuruluyor?
İkinci bir konumda veya kendi bulut hesabımda bir kurulum çalıştırabilir miyim?
Paylaşımlı bir planda başka bir kiracı sorun çıkarırsa iş yüküme ne olur?

Kendi hizmetimiz için 2. ve 3. soruların cevabı, yeniden başlatmalar arasında kalıcılığın ve mesaj replikasyonunun sunulmadığıdır; SLA koşulları için de doğrudan ekibe sormalısınız. MQTT broker SLA yazımız SLA dilinin nasıl okunacağını açıklar, MQTT broker RFP kontrol listesi ise daha uzun bir değerlendirme listesi sunar.

Yönetilen Bir Broker'da Pratik Yüksek Erişilebilirlik Kalıpları

Yukarıdaki kavramları birleştirdiğimizde, çoğu ekip için gerçekçi bir yaklaşım şöyle görünür:

Yamalar, TLS ve makine arızaları başkasının işi olsun diye barındırılan bir MQTT broker seçin.
Diğer kiracılardan izolasyona ihtiyacınız varsa Dedicated bir kurulum kullanın.
Broker'ın diğer sistemlerinizin yanında, kendi bulut hesabınızda yaşaması gerekiyorsa BYOC kullanın.
Tek bir kesintinin herkesi etkilememesi gereken yerlerde tesis veya müşteri bazında bölümleyin.
Her istemciyi bağlantıda yeniden abone olma, yerel tamponlama, idempotent komutlar ve jitter'lı backoff ile geliştirin.
Bağlantı durumunu örneğin $SYS/broker/connection/{clientId}/state üzerinden izleyin ve cihazlar çevrimdışı olduğunda alarm üretin.

Erişilebilirliğin yanında kapasite için bir MQTT broker'ın nasıl ölçeklendirileceğine bakın; daha geniş barındırma seçenekleri için de bulut MQTT broker rehberini okuyun.

MQTT Erişilebilirliğinizi ConnectMQ ile Planlayın

ConnectMQ, Serverless, Dedicated ve BYOC seçeneklerine sahip, tam yönetilen bir MQTT broker'dır; böylece erişilebilirlik ihtiyaçlarınıza uyan dağıtım modelini seçebilirsiniz. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz başlayın, dayanıklı istemcilerinizi onun üzerinde geliştirin ve Dedicated veya BYOC kurulumuna ihtiyaç duyduğunuzda ekiple görüşün.

Sık Sorulan Sorular

MQTT'nin yerleşik yüksek erişilebilirliği var mı?

Hayır. MQTT protokolü oturumları, QoS'u ve Last Will'i tanımlar, ancak yüksek erişilebilirlik broker'ın nasıl dağıtıldığına ve istemcilerin yeniden bağlanmaları nasıl ele aldığına bağlıdır.

MQTT oturumum bir broker yeniden başlatmasından sağ çıkar mı?

Yalnızca broker oturumları kalıcı tutuyorsa. Bizimki dahil pek çok kurulum oturumları yeniden başlatmalar arasında kalıcı tutmaz; bu yüzden istemciler her bağlantıda yeniden abone olmalı ve önemli durumu yeniden yayınlamalıdır.

Güvenilir bir MQTT sistemi için clustering şart mı?

Her zaman değil. İyi tasarlanmış istemciler, bölümlenmiş broker'lar ve izole kurulumlar, pek çok sisteme replike edilmiş bir cluster olmadan da güçlü bir güvenilirlik sağlar.

MQTT broker yüksek erişilebilirliği hakkında bir sağlayıcıya ne sormalıyım?

Topolojiyi, oturum kalıcılığını, mesaj replikasyonunu, failover davranışını, bakım pencerelerini ve yazılı SLA koşullarını sorun. Taahhütte bulunmadan önce cevapları yazılı olarak alın.

MQTT Broker Yüksek Erişilebilirlik: Kavramlar, İstemci Tasarımı ve Sorulacak Sorular