Ana içeriğe geç

ADR-003: MQTT Broker Olarak EMQX Secimi

DurumKabul Edildi
Tarih2025-11
Karar VerenGüçlü Ceyhan

Baglam

Zeus 2.0, sahada calisan ESP32 gateway'lerden MQTT uzerinden telemetri verisi alir. Broker'in karsilamasi gereken gereksinimler:

  • Binlerce es zamanli baglanti: Her GES sahasinda birden fazla ESP32 gateway
  • TLS zorunlulugu: Saha ile sunucu arasinda sifrelenmis iletisim
  • Tenant izolasyonu: Farkli organizasyonlarin verileri birbirinden ayrilmali
  • Webhook / Rule Engine: Gelen verileri backend'e veya veritabanina yonlendirme
  • Auth/ACL: Cihaz bazli yetkilendirme, topic erisim kontrolu
  • Monitoring: Baglanti durumu, mesaj metrikleri, hata takibi

Karar

EMQX 5.x (acik kaynak surum) MQTT broker olarak secildi.

Alternatifler

Eclipse Mosquitto

  • Artilari: Cok hafif, dusuk kaynak tuketimi, basit yapilandirma, genis topluluk
  • Eksileri: Rule engine yok, auth/ACL icin eklenti gerekli, clustering sinirli, dashboard yok
  • Red nedeni: Veri yonlendirme ve gelismis ACL icin cok fazla ozel gelistirme gerekir

HiveMQ

  • Artilari: Kurumsal destek, Java extension sistemi, Kafka entegrasyonu
  • Eksileri: Ticari lisans (Community Edition sinirli), daha yuksek kaynak tuketimi
  • Red nedeni: Lisans maliyeti ve Community Edition sinirlamalari

VerneMQ

  • Artilari: Erlang/OTP tabani (yuksek erisebilirlik), clustering, plugin sistemi
  • Eksileri: Daha kucuk topluluk, dokumantasyon sinirli, bakim durumu belirsiz
  • Red nedeni: Topluluk buyuklugu ve uzun vadeli surdurulebilirlik endisesi

RabbitMQ (MQTT Plugin)

  • Artilari: Olgun mesaj kuyrugu, AMQP + MQTT destegi, yonetim arayuzu
  • Eksileri: MQTT destegi plugin olarak eklenir (native degil), MQTT 5.0 destegi sinirli, IoT optimizasyonu zayif
  • Red nedeni: MQTT birincil protokol degil, IoT senaryolari icin optimize edilmemis

Gerekce

EMQX su temel avantajlari sundu:

  1. Rule Engine: Gelen MQTT mesajlarini dogrudan PostgreSQL/TimescaleDB'ye, HTTP webhook'a veya baska bir topic'e yonlendirme — ek kod yazmadan veri pipeline'i kurulur
  2. Built-in Auth/ACL: HTTP backend uzerinden auth (FastAPI endpoint'ine istek atar), topic bazli ACL kurallari — tenant izolasyonu ag seviyesinde saglanir
  3. Clustering destegi: Yatay olcekleme, yuk dagitimi, yuksek erisebilirlik (ileride gerektiginde)
  4. Dashboard (port 18083): Bagli cihazlar, mesaj hizi, topic dagilimi, kural istatistikleri — gorunur gozlemlenebilirlik
  5. Yuksek baglanti kapasitesi: Tek node'da 100K+ es zamanli baglanti (Erlang/OTP altyapisi)
  6. MQTT 5.0 destegi: Shared subscription, message expiry, user properties gibi gelismis ozellikler
  7. TLS terminasyonu: Let's Encrypt sertifikalari ile native TLS destegi

Sonuclar

Olumlu

  • Rule engine sayesinde cihaz verisi ek kod olmadan dogrudan veritabanina yaziliyor
  • HTTP auth backend ile FastAPI uzerinden cihaz dogrulama — tek kaynak noktasi
  • Topic bazli ACL ile tenant izolasyonu garanti altinda
  • Dashboard sayesinde MQTT trafigi ve cihaz durumu anlik izlenebiliyor
  • Webhook ile alarm tetikleme ve bildirim pipeline'i kolayca kuruldu

Olumsuz

  • Mosquitto'ya kiyasla daha fazla RAM tuketimi (384MB+ baseline) — kucuk sunucularda dikkat edilmeli
  • Rule Engine konfigurasyonu EMQX'e ozgu — broker degistirmek istenirse yeniden yazilmali
  • EMQX surum yukseltmeleri konfigurasyonu etkileyebilir (4.x → 5.x gecisi breaking change icerdi)
  • Erlang/OTP bilgisi gerektiren ileri duzey debug senaryolari zor olabilir