Ara Katmanlar -2. MQTT ile Sistem Geliştirme
MQTT Nedir
MQTT protokolü IBM firması tarafından geliştirilen ve açık kaynak olarak sunulan bir ara katman standardıdır. Gerek protokol gerekse özellik olarak hafif tutulmuştur. Bu özelliklerinden dolayı günümüzde özellikle nesnelerin interneti uygulamalarında tercih edilmektedir.
İsminin mesaj kuyruğu terimini içermesine karşın mesaj kuyruğu değil, Yayımla-Abone ol yaklaşımına uygun bir ara katmandır. Ortada Broker denilen bir aracı (komisyoncu, acente, simsar ya da kabzımal) üzerinden veri alışverişi sağlanmaktadır. Her bir uygulama TCP/IP ile bu broker uygulamasına bağlanır. Bu uygulama bir uygulamadan gelen mesajı diğer uygulamalara yayımla abone ol felsefesi ile iletir.
MQTT ara katmanında abonelik konu (topic) bazında olmaktadır. Topic ismi ile abone olunmakta ve ilgili konuda bir uygulama yayım yapar ise veri alınmaktadır.
Topic ismi basit tümce olabileceği gibi bölü işareti ile ayrılmış şekilde seviyeli bir yapıda olmaktadır. Örneğin mühendislik binasının, 3. Katının, 323 numaralı odasının sıcaklık verisi gibi bir topik ismi olabilmektedir (‘MühendislikBinası/Kat3/Oda323/sıcaklık’) şekilde de tanımlanabilmektedir.
MQTT ara katmanı uygulamalar arasında iletilen veri ile ilgilenmez. Bu sebeple sistem tasarımı aşamasında ne tür bir yapıda veri iletileceğine karar vermeniz beklenir. Veri text, Json, XML veya ikili (binary) biçimde olabilir. Bu durumda veriyi gönderen uygulama önce veriyi üzerinde anlaşılan biçimde oluşturacak ve ara katmana öyle verecektir. Benzer şekilde alan uygulamada aldığı veriyi nasıl çözeceğini bilecektir.
Bu kapsamda en yaygın kullanılan protokoller JSON ve Google tarafından geliştirilmiş olan ProtocolBuffer olarak göze çarpmaktadır. Protocol Buffer farklı donanım mimarilerini dikkate aldığı için ve veriyi ikili sistemde gönderdiği için daha tercih edilebilir bir protokol olabilir. Öte yandan JSON biçimi hem çözücü desteği bakımından alternatiflerinin çok olması hem de okunabilir biçimden dolayı kullanılmaktadır. Ben en son projemde gecikme ve performans açısında çok hassas gereksinimler olmadığı için json biçimini tercih ettim.
Servis Kalitesi
MQTT servis kalitesi özelliği bakımından çok temel özellik olan mesaj iletiminin güvenilir olup olmamasını barındırır. Temelde altyapı TCP/IP olduğu için bütün mesajların iletileceği varsayılabilir fakat arada bağlantı kopmaları vb sebeplerle yine de mesaj kaybı olabilir.
Servis kalitesinde temel seviye olan 0 (At Most once) seçilmiş ise bağlantı kopması durumunda mesaj karşıya ulaşmayabilir. Sıcaklık verilerini ölçüp abone olan uygulamalara gönderiyor ise arada mesaj kaybolmasını çok fazla umursamayız çünkü biraz sonra yeni sıcaklık verisi zaten ölçülüp tekrar gönderilecektir.
Bir üst seviye olan 1(At least one) de mesajın en az bir kere iletilmesi için TCP/IP protokolü üzerinde ek protokol işletilir. Bu biraz kafa karıştırıcı olabilir. Burada söylenmek istenen mesajın karşıya erişip erişmediğinden emin olmadan kopma vb. olur ise mesaj bir defa daha karşıya iletilir ve karşı taraf mutlaka mesajı alır. Ama nadiren de olsa aynı mesaj iki kere alınabilir. Bu durumda MQTT’yi bankacılıkta kullanıyor olsak bazen hesabımıza iki kere maaş yatabilir.
Aynı mesajı birden fazla iletilmesini yönetemiyor isek servis kalitesi seviyesi 2 (exactly one) kullanılabilir. Ara katman her mesajın kesin bir şekilde bir kere iletilmesini garanti eder.
Bir ara katmanda sadece bir servis kalitesi özelliği olması bu ara katmanın çok fazla konfigüre edilemediği ve ihtiyaç duyulan başka özelliklerin uygulama seviyesinde çözülmesi gerektiğini ifade eder.
İyi Tasarım Yaklaşımları
İletişiminizi konu tabanlı tutun. Her bir konu için kullanacağınız mesaj yapısı belirli olsun. Yani bir konu içinde farklı mesaj başlıkları ile birden fazla tip veriyi iletmeye çalışmayın. Bu arayüzleri mimari kararları yönettiğiniz gibi iyi yönetin. Farklı modüller farklı versiyon mesaj yapıları kullanmaya başlayınca entegrasyon sizin için inanılmaz problem haline gelecektir.
İletişim için ya json gibi rahat işlenen veriler ya da Google ProtocolBuffer gibi standart kodlayıcılar kullanın. Aksi takdirde şu anda ön görmediğiniz heterojen yazılım ortamı daha sonra ihtiyaç haline geldiğinde alt seviye veri dönüşüm problemleri ile çok fazla zaman kaybedersiniz.
Konu isimleri anlamlı ve kısa olsun. Veritabanı tasarımında nasıl tablo isimleri için standartlar koyup üzerine kafa yoruyorsunuz, benzerini konu (topic) isimleri içinde yapın. Konu isimleri kısa ve amacını anlatır olur ise hem test mühendisleri hem de geliştiriciler daha rahat entegrasyon yapabilir, hataları bulup sistemi çalışır duruma getirebilirler.
DDS ara katmanı eğitiminde en çok vurgulanan bir prensip var. Yayımla abone ol türü sistemlerde iletişimi mesaj tabanlı değil durum (state) tabanlı yapın. Bu prensip MQTT içinde geçerlidir. Uç sistemler değişimleri değil verisi değişen elemanın durumunu paylaşırlar ise bu veriyi kullanan bileşenler daha kolay programlanabilir. Örnek verecek olur isek ben mail grubundan MQTT sunumu konusunda mail attığımı varsayalım. Önce 50 kişilik bir gruba eğitim içeriğine attığımı varsayalım. Sonra sunumun 10 Mayıs tarihinde olacağını gönderiyorum. Sonra sunumu Hacettepe’de vereceğimi yazayım. 10 mayısın uygun olmadığını görüp 12 mayısa alayım. Bu durumda sunuma gelecek herkes benden gelen bütün mesajları doğru sırada değerlendirip sunum ne zaman, nerede ve ne konuda olduğunu oluşturması gerekir. Arada mail grubuna katılan birisi eğitim içeriğini alamamış olabilir. Bu mesaj tabanlı iletişimlerde çok karşılaşılan bir sorundur. Buna alternatif olarak mail sunucuların toplantı isteği özelliğini kullandığımızda her güncellemede tüm katılımcılar toplantının konusunu, yerini ve zamanını doğru şekilde işleyebilirler. Yani toplantı ile ilgili durum bilgisi bir bütün olarak paylaşılıyor.
Performans
MQTT yi benim kullandığım projede saniyede en fazla 500–100 mesaj iletiliyor idi. Bu sistemde herhangi bir performans sorunu yaşamadım.
İnternette Mosquitto brokerının 6000 civarında uygulamayı desteklediğini ve 64 byte içeren bir mesajı 10 milisaniye ile 1 saniye arasında iletebildiğini yazmaktadır.
MQTT Çözümleri
İnternet sitesinden fiyat bulamıyorsunuz ama ihtiyacınızı belirtip fiyat alabilirsiniz. Bu arada yakın zamanda HiveMQ da temel seviyede broker ve Java tabanlı istemiciyi açık kaynak olarak sunmaya başlamış. Firmanın genel beklentisi sizin temel servisleri kullandıktan sonra ihtiyaç duyacağınız katma değerli servisleri almaya bütçe ayırmaktır.
Tabi ortamda bulut modasına uymuş ve bulut üzerinden MQTT broker hizmeti sunan CloudMQTT ve mymqtthub gibi sitelerde var. Ama zaten bulut üzerinden hizmet alacak kadar karmaşık ihtiyaçlarınız var ise benzer diğer bulut ara katman çözümlerinin de değerlendirildiği daha geniş kapsamlı bir mimari ödün analizine ihtiyacınız var demektir.
