ADR-003: MQTT Broker Olarak EMQX Secimi
| Durum | Kabul Edildi |
| Tarih | 2025-11 |
| Karar Veren | Güç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:
- 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
- Built-in Auth/ACL: HTTP backend uzerinden auth (FastAPI endpoint'ine istek atar), topic bazli ACL kurallari — tenant izolasyonu ag seviyesinde saglanir
- Clustering destegi: Yatay olcekleme, yuk dagitimi, yuksek erisebilirlik (ileride gerektiginde)
- Dashboard (port 18083): Bagli cihazlar, mesaj hizi, topic dagilimi, kural istatistikleri — gorunur gozlemlenebilirlik
- Yuksek baglanti kapasitesi: Tek node'da 100K+ es zamanli baglanti (Erlang/OTP altyapisi)
- MQTT 5.0 destegi: Shared subscription, message expiry, user properties gibi gelismis ozellikler
- 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