MQTT Broker Nasıl Ölçeklendirilir: Bağlantılar, Throughput ve Fan-Out

Bir MQTT broker'ın nasıl ölçeklendirileceğini bilmek, gerçekte hangi tür yükün büyüdüğünü bilmekle başlar: bağlantılar, gelen mesajlar ya da giden fan-out. Bu rehber her boyutu açıklıyor, dikey ve yatay ölçeklendirmeyi karşılaştırıyor, boyutlandırma için ihtiyaç duyduğunuz fan-out hesabını adım adım gösteriyor ve çoğu zaman broker'ın kendisinden daha önemli olan istemci tarafı alışkanlıkları ortaya koyuyor.

MQTT Yükünün Üç Boyutu

Bir MQTT broker üç farklı türde iş yapar ve bunlar birbirinden bağımsız olarak ölçeklenir.

Bağlantılar. Bağlı her istemci bir TCP soketi, şifreliyse bir TLS oturumu, bir oturum durumu nesnesi ve keepalive zamanlayıcıları tutar. Bağlantı yükü büyük ölçüde bellek ve dosya tanımlayıcılarıyla ilgilidir ve cihazlar sessiz olsa bile filo büyüklüğüyle birlikte artar.

Gelen mesajlar. Bir istemciden gelen her PUBLISH ayrıştırılmalı, yetkilendirilmeli, aboneliklerle eşleştirilmeli ve QoS 1 veya 2 ise onaylanmalıdır. Gelen yük, filo büyüklüğü çarpı yayın sıklığı oranında büyür.

Giden fan-out. Broker her gelen mesaj için eşleşen her subscriber'a bir kopya teslim eder. Bir dashboard, bir veritabanı yazıcısı ve bir alarm servisi tarafından tüketilen tek bir sensör okuması üç giden mesaja dönüşür. Fan-out, ekiplerin en sık unuttuğu boyuttur ve çoğu zaman en büyüğüdür.

Dördüncü ve daha sessiz bir faktör oturum durumudur: çevrimdışı istemciler için kuyruğa alınmış QoS 1 mesajları bulunan kalıcı oturumlar, bu istemciler geri dönene ya da oturumun süresi dolana kadar bellek tüketir.

Fan-Out Hesabı: Gerçek Broker Yükünü Tahmin Etmek

Yük hakkında akıl yürütmek için bir benchmark'a değil, aritmetiğe ihtiyacınız var. Temel formüller şunlardır:

• Gelen hız = cihaz sayısı x cihaz başına saniyedeki mesaj sayısı
• Giden hız = tüm topic'ler üzerinden (o topic'teki gelen hız x eşleşen subscriber sayısı) toplamı
• Toplam broker işi kabaca gelen artı gidendir; QoS 1 ve 2 onayları ile TLS için ek maliyet vardır

Aşağıda kendi filonuza uyarlayabileceğiniz küçük bir hesaplayıcı var. İçindeki sayılar bir ölçüm değil, bir örnektir.

# fanout.py - kapasite planlaması için kabaca MQTT yük tahmini
fleet = [
    # (ad, cihaz sayısı, cihaz başına dakikadaki mesaj, mesaj başına subscriber, ortalama payload baytı)
    ("env sensors",  400, 2,  2, 180),
    ("machines",      60, 60, 3, 600),
    ("status",       460, 0.1, 1, 20),
]

total_in = total_out = total_bytes = 0.0
for name, devices, per_min, subs, size in fleet:
    inbound = devices * per_min / 60
    outbound = inbound * subs
    total_in += inbound
    total_out += outbound
    total_bytes += (inbound + outbound) * size
    print(f"{name:12s} in={inbound:7.1f}/s out={outbound:7.1f}/s")

print(f"\nTOTAL inbound  {total_in:8.1f} msg/s")
print(f"TOTAL outbound {total_out:8.1f} msg/s")
print(f"Approx traffic {total_bytes/1024:8.1f} KB/s (payload only, no protocol/TLS overhead)")

python fanout.py ile çalıştırın. Genellikle iki ders hemen göze çarpar. Birincisi, bir avuç geveze makine yüzlerce yavaş sensörden ağır basabilir. İkincisi, yüksek hacimli bir topic'e bir subscriber daha eklemek (örneğin ikinci bir analitik servisi), yüzlerce cihaz eklemekten daha fazla giden yük artışına yol açabilir. Daha ayrıntılı bir anlatım için saniyedeki MQTT mesaj sayısını tahmin etme yazımızı okuyun.

Dikey ve Yatay Ölçeklendirme

Bir broker'a daha fazla kapasite kazandırmanın iki genel yolu vardır.

Dikey ölçeklendirme hak ettiğinden az değer görür. Yeterli donanım üzerinde iyi ayarlanmış tek bir broker süreci büyük miktarda trafiği kaldırabilir ve operasyonel sadelik değerlidir. Ayarlama genellikle dosya tanımlayıcı limitlerini yükseltmeyi, belleği oturumlar ve iletimdeki mesajlar için boyutlandırmayı ve TLS'i dışarı aktarmayı ya da optimize etmeyi içerir.

Yatay ölçeklendirme, bir load balancer arkasında birkaç broker node'u demektir. Zor olan node eklemek değil, onları tutarlı tutmaktır: A node'unda yayınlanan bir mesaj B node'una bağlı bir subscriber'a ulaşmalıdır ve farklı bir node'a yeniden bağlanan bir istemci oturumunu orada bulmayı bekler. Farklı broker ürünleri bunu gecikme ve tutarlılık açısından farklı ödünleşimlerle, farklı yollarla çözer.

Üçüncü bir kalıp bölümlemedir (partitioning): ayrı tesisler, kiracılar veya ürün grupları için ayrı ve bağımsız broker'lar çalıştırmak. Bu, tek bir global topic alanına sahip olmamak pahasına node'lar arası koordinasyonu tamamen ortadan kaldırır. Pek çok çok tesisli ve çok müşterili kurulumda bölümleme, büyümenin en basit yoludur.

Shared Subscription ile Tüketici Tarafını Ölçeklendirmek

Backend tüketicileri çoğu zaman ilk darboğazdır. acme/# topic'ine abone olan tek bir Python servisi, filonun gönderdiği her mesajı işlemek zorundadır. Geride kaldığında mesajlar broker'da kuyruğa girer ve bellek kullanımı artar.

MQTT 5 shared subscription, birkaç tüketici instance'ının tek bir aboneliği paylaşmasına izin vererek bunu çözer. Her mesaj grubun tüm üyelerine değil, yalnızca birine gider. Shared subscription, ConnectMQ Serverless (Paid) planında mevcuttur.

import os
import paho.mqtt.client as mqtt

GROUP = "writers"
FILTER = "acme/+/+/+/+/telemetry"

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"$share/{GROUP}/{FILTER}", qos=1)

def on_message(client, userdata, msg):
    # Burada veritabanınıza, kuyruğunuza veya dosyanıza yazın.
    print(os.getpid(), msg.topic, len(msg.payload), "bytes")

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

Her tüketici instance'ı için, her biri kendi kimlik bilgileri ve client ID'siyle bir kopya çalıştırın. Bir instance eklemek, cihazlara dokunmadan yükü daha da dağıtır.

Ölçeklenen İstemci Tarafı Alışkanlıklar

Pek çok ölçeklendirme sorunu aslında istemci sorunudur. Bu alışkanlıklar her broker'da işe yarar:

1. Zamanlayıcıyla değil, değişimde yayınlayın. İstisna bazlı raporlama (report-by-exception), yavaş değişen değerler için gelen yükü büyük ölçüde azaltır.
2. Okumaları gruplayın. On mesaj yerine tek bir mesajda on örnek gönderin.
3. QoS'u bilinçli kullanın. Bir sonraki örneğin öncekinin yerini aldığı yüksek frekanslı telemetri için QoS 0; olaylar ve komutlar için QoS 1; QoS 2'yi yalnızca mükerrer mesajların kabul edilemez olduğu yerlerde kullanın. MQTT QoS seviyeleri yazımıza bakın.
4. Dar kapsamlı abone olun. Tek bir tesisi gösteren bir dashboard # topic'ine abone olmamalıdır.
5. Makul keepalive değerleri belirleyin. Çok kısa keepalive değerleri, büyük bir filoda PINGREQ trafiğini katlar.
6. Yeniden bağlanmalara ve periyodik yayınlara jitter ekleyin. Tam olarak aynı saniyede yayın yapan binlerce cihaz gereksiz sıçramalar yaratır.
7. İhtiyacınız olmayanın süresini doldurun. Session expiry ve message expiry, broker'ın asla geri dönmeyecek istemciler için durum tutmasını önler.
8. Kısıtlı bağlantılarda uzun topic'ler için topic alias kullanın. MQTT 5 topic alias'ları, tekrarlanan uzun topic dizelerini kısa bir tam sayıyla değiştirir.

Ne Zaman Daha Büyük Bir Plana Geçmeli?

Yönetilen bir hizmette ölçeklendirme büyük ölçüde bir plan kararıdır. ConnectMQ'da basamaklar şöyledir:

• Serverless (Free): 25 bağlantıya kadar, QoS 1'e kadar, 256 KB mesajlar. Prototipler ve küçük pilotlar.
• Serverless (Paid): 1.000 bağlantıya kadar, QoS 2, 1 MB mesajlar, shared subscription. Paylaşımlı bir cluster üzerinde büyüyen filolar.
• Dedicated: İş yükünüzün kaynakları diğer kiracılarla paylaşmaması için izole bir cluster.
• BYOC: Kendi bulut hesabınızda çalışan ve ConnectMQ tarafından yönetilen bir broker; altyapıyı seçmek ve kontrol etmek istediğinizde kullanışlıdır.
• Self Managed Enterprise: Broker'ı kendileri işletmesi gereken kuruluşlar için.

Bir üst plana geçmeniz gerektiğini gösteren sinyaller arasında bağlantı tavanına yaklaşmak, backend tüketicileri için shared subscription'a ihtiyaç duymak ya da diğer kiracıların trafiğinden izolasyon istemek yer alır. Dedicated veya Enterprise bir kurulumun iş yükünüze göre boyutlandırılması için beklenen bağlantı ve mesaj hızlarınızı ekiple konuşun. Modelleri genel olarak karşılaştırıyorsanız bulut MQTT broker rehberi her birini ele alır; MQTT broker yüksek erişilebilirlik yazısı da kapasitenin yanında sorulması gereken yedeklilik sorularını açıklar.

Kaçınılması Gereken Ölçeklendirme Tuzakları

• Ortalamalara göre boyutlandırmak. Vardiya değişimleri, yeniden bağlanma fırtınaları ve birikmiş verinin boşaltılması gibi tepe anlarına göre plan yapın.
• Subscriber'ları göz ardı etmek. Yalnızca cihazları değil, giden fan-out'u da sayın.
• Tek bir dev wildcard tüketicisi. Bir darboğaza dönüşmeden önce onu shared subscription ile bölün.
• Her yerde büyük retained message'lar. Her yeni subscriber bunları hemen alır; bu da geniş wildcard'larda hızla birikir.
• Canlı ortama karşı yük testi yapmak. Kendi kotalarınıza takılmamak için yük testlerinde ayrı bir broker veya plan kullanın.

MQTT Filonuzu ConnectMQ ile Ölçeklendirin

ConnectMQ, protokolleri veya topic tasarımını değiştirmeden küçük başlamanıza ve bağlantılarınız ile fan-out'unuz büyüdükçe plan basamaklarında yükselmenize olanak tanır. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve rakamlarınız zamanı geldiğini söylediğinde yükseltin. Planlamaya başlamadan önce bir MQTT broker'ın ne yaptığını hatırlamak isterseniz oradan başlayın.

Sık Sorulan Sorular

MQTT broker ölçeklendirmesini genellikle ilk olarak ne sınırlar?

İş yüküne bağlıdır. Büyük ve sessiz filolar önce bağlantı ve bellek limitlerine takılır; topic başına birkaç tüketicisi olan yoğun filolar ise önce giden fan-out limitlerine takılır.

Yatay ölçeklendirme her zaman dikey ölçeklendirmeden daha mı iyidir?

Hayır. Dikey ölçeklendirme daha basittir ve pek çok kurulum için yeterlidir. Yatay ölçeklendirme koordinasyon yükü ekler ve tek bir node kapasite veya yedeklilik hedeflerini karşılayamadığında buna değer.

Shared subscription ölçeklendirmeye nasıl yardımcı olur?

Birkaç tüketici instance'ının tek bir aboneliği paylaşmasını sağlar; böylece her mesaj grubun bir üyesi tarafından bir kez işlenir. Bu, cihazları değiştirmeden tek tüketici darboğazını ortadan kaldırır.

Serverless'tan Dedicated'a ne zaman geçmeliyim?

Diğer kiracılardan izolasyona ihtiyaç duyduğunuzda veya paylaşımlı Serverless planlarının sağladığının ötesinde bir yük beklediğinizde Dedicated'ı düşünün. Kurulumun doğru boyutlandırılması için beklenen bağlantı ve mesaj hızlarınızı paylaşın.