MQTT broker fiyatlandırması kafa karıştırıcıdır, çünkü sağlayıcılar farklı şeyleri ölçer: biri bağlantı başına, diğeri mesaj başına, üçüncüsü gigabayt başına, dördüncüsü de ayrılmış küme başına ücret alır. Bu rehber her fiyatlandırma modelini açıklıyor, hangi iş yüklerini avantajlı ya da dezavantajlı kıldığını gösteriyor ve teklifleri eşit koşullarda karşılaştırabilmeniz için kendi kullanımınızı tahmin etmenize yarayan tekrarlanabilir bir yöntem sunuyor. Fiyatlar sık değiştiği için rehberde bilinçli olarak hiçbir fiyat rakamı yer almıyor; yöntem ise geçerliliğini koruyor.
MQTT Broker Fiyatları Neden Bu Kadar Farklı?
Bir broker'ın gerçek maliyeti birkaç kaynaktan gelir: açık her bağlantı için bellek, yönlendirilen her mesaj için CPU, ağ bant genişliği, retained ve kuyruktaki mesajlar için depolama ve sistemi işleten insanlar. Her sağlayıcı bunlardan bir ya da ikisini faturalandırma birimi olarak seçer, geri kalanını plan limitlerine yedirir. Sonuç olarak iki servis, trafiğinizin yapısına bağlı olarak tamamen aynı cihaz filosu için ucuz ya da pahalı görünebilir.
İki filo düşünün. Birincisinde her biri on beş dakikada bir küçük bir ölçüm gönderen binlerce cihaz var. İkincisinde yüksek frekanslı veri akıtan birkaç düzine makine var. Birincisi bağlantı ağırlıklı ve mesaj açısından hafif; ikincisi ise tam tersi. Bağlantı başına model ikinci filoyu, mesaj başına model birinci filoyu kayırır. İşin özü, kendi trafik yapınızı bilmektir.
Yaygın MQTT Broker Fiyatlandırma Modelleri
1. Bağlantı Başına
Eşzamanlı bağlantı sayısı için ödeme yaparsınız; bu sayı çoğunlukla zirve değer ya da aylık maksimum olarak ölçülür. Mesaj hacmi adil kullanım çerçevesinde sınırsız olabilir veya plan başına sınırlandırılabilir.
- Avantajlı olduğu durumlar: çok konuşan cihazlar, yüksek mesaj hızları, küçük filolar.
- Dezavantajlı olduğu durumlar: çoğu zaman boşta duran devasa cihaz filoları ve her tarayıcı sekmesinin ya da mobil uygulamanın kendi bağlantısını tuttuğu mimariler.
- Dikkat edilecekler: sayımın eşzamanlı mı yoksa kümülatif mi olduğu ve kısa süreli yeniden bağlanma fırtınalarının zirve değere dahil edilip edilmediği.
2. Bağlantı Dakikası Başına (Oturum Süresi)
İstemcilerin bağlı kaldığı toplam süre için ödeme yaparsınız; bu genellikle bağlantı dakikası veya oturum dakikası olarak sayılır. Her şeyi tüketim üzerinden faturalandıran bulut IoT platformlarında yaygındır.
- Avantajlı olduğu durumlar: kısa süre bağlanıp yayın yapan ve bağlantıyı kesen cihazlar.
- Dezavantajlı olduğu durumlar: her biri ay boyunca dakika biriktiren, sürekli bağlı cihazlar.
- Dikkat edilecekler: dakika kesirlerinin nasıl yuvarlandığı ve keepalive trafiğinin ayrıca mesaj olarak sayılıp sayılmadığı.
3. Mesaj Başına
Yayınlanan veya teslim edilen mesaj başına, çoğu zaman paketler halinde ödeme yaparsınız. Bazı servisler bir mesajı yayın anında bir kez sayar; diğerleri her abone için her teslimi ayrıca sayar, yani on abonesi olan tek bir yayın on bir mesaj eder. Bazıları sabit boyutlu dilimlerle sayar; bu durumda büyük bir payload birkaç mesaj olarak sayılır.
- Avantajlı olduğu durumlar: büyük ama sessiz filolar.
- Dezavantajlı olduğu durumlar: yüksek frekanslı telemetri, çok sayıda aboneye dağıtım (fan-out) ve büyük payload'lar.
- Dikkat edilecekler: ping'lerin, subscribe işlemlerinin, retained teslimlerin ve QoS onaylarının sayılıp sayılmadığı.
4. Trafik Hacmi Başına
Gelen, giden veya her iki yöndeki aktarılan gigabayt başına ödeme yaparsınız. Bu, bulut ağ hizmetlerinin faturalandırılma biçimine yakındır.
- Avantajlı olduğu durumlar: Sparkplug B veya CBOR gibi kompakt ikili payload'lar.
- Dezavantajlı olduğu durumlar: ayrıntılı (verbose) JSON, yüksek fan-out ve video benzeri iş yükleri.
- Dikkat edilecekler: TLS ve protokol ek yükünün dahil olup olmadığı ve gelen (ingress) ile giden (egress) trafiğin farklı fiyatlandırılıp fiyatlandırılmadığı.
5. Kotalı Kademeli Planlar
Kademe başına sabit bir tutar ödersiniz; her kademe bağlantı, mesaj boyutu, QoS seviyesi, verim veya özellikler için limitler içerir. Bütçeleme açısından en öngörülebilir modeldir.
- Avantajlı olduğu durumlar: aylık faturasını önceden bilmek isteyen ekipler.
- Dezavantajlı olduğu durumlar: bir kademe sınırının hemen üzerinde kalan iş yükleri.
- Dikkat edilecekler: limite ulaşıldığında ne olduğu: reddetme, hız sınırlama (throttling) veya otomatik aşım faturası.
6. Ayrılmış Kapasite
Ne kadar kullandığınızdan bağımsız olarak; instance, node veya kapasite birimi cinsinden boyutlandırılmış izole bir küme için ödeme yaparsınız. BYOC (bring your own cloud, kendi bulutunu getir) bu modelin bir çeşididir: altyapı sizin bulut hesabınızda çalışır, böylece kaynaklar için bulut sağlayıcısına, yönetim için de sağlayıcıya ödeme yaparsınız.
- Avantajlı olduğu durumlar: büyük ve istikrarlı iş yükleri, sıkı izolasyon ve veri yerleşimi (data residency) gereksinimleri.
- Dezavantajlı olduğu durumlar: kapasiteyi boşta bırakan küçük veya dalgalı iş yükleri.
- Dikkat edilecekler: minimum taahhütler, yüksek erişilebilirlik çarpanları ve bölgeler arası (cross-zone) trafiğin bedelini kimin ödediği.
7. Kendi Yönettiğiniz Yazılım Lisansları
Kendiniz işlettiğiniz yazılımlarda sağlayıcılar node başına, çekirdek başına, bağlantı kademesine göre veya kurumsal anlaşmayla ücret alabilir. Lisans, maliyetin yalnızca bir parçasıdır; altyapı ve personel zamanı çoğu zaman baskın kalemdir. MQTT broker toplam sahip olma maliyeti rehberimiz bu gizli maliyetleri ele alıyor.
Fiyatlandırma Modellerine Hızlı Bakış
| Model | Faturalandırma birimi | En uygun olduğu durum | En büyük risk |
|---|---|---|---|
| Bağlantı başına | Eşzamanlı istemciler | Az sayıda yoğun istemci | Boşta duran büyük filolar |
| Bağlantı dakikası | Bağlı kalınan süre | Aralıklı bağlanan cihazlar | Sürekli bağlı cihazlar |
| Mesaj başına | Yayınlanan veya teslim edilen mesajlar | Büyük, sessiz filolar | Fan-out ve yüksek hızlar |
| Trafik başına | Gigabayt | Kompakt payload'lar | Ayrıntılı JSON, fan-out |
| Kademeli planlar | Kotalı, kademe başına sabit ücret | Öngörülebilir bütçeler | Kademe sınırları |
| Ayrılmış kapasite | Küme boyutu | Büyük istikrarlı yük, izolasyon | Boşta kalan kapasite |
| Kendi yönettiğiniz lisans | Node, çekirdek veya anlaşma | Tam kontrol | Gizli operasyon maliyeti |
Kullanımınızı Nasıl Tahmin Edersiniz?
Herhangi bir teklifi karşılaştırmadan önce iş yükünüzü ölçün veya tahmin edin. Her fiyatlandırma modeli aynı birkaç sayıdan hesaplanabilir:
- Cihazlar (D): yayın yapan istemci sayısı.
- Diğer istemciler (B): backend'ler, dashboard'lar, tarayıcı oturumları, Node-RED instance'ları.
- Zirve eşzamanlı bağlantı sayısı: genellikle D + B, artı yeniden bağlanma çakışmaları için pay.
- Cihaz başına saatlik mesaj sayısı (R).
- Bayt cinsinden ortalama payload boyutu (S).
- Mesaj başına ortalama abone sayısı (F): fan-out.
- Bağlı kalınan süre oranı (C): sürekli bağlı cihazlar için 1,0.
Bunlardan aylık değerleri türetin (ayda 730 saat kabul ederek):
published messages / month = D x R x 730
delivered messages / month = published x F
connection-minutes / month = (D + B) x C x 730 x 60
payload traffic in (bytes) = published x S
payload traffic out (bytes) = delivered x S
Varsayımsal sayılarla çözülmüş bir örnek: her 30 saniyede bir yayın yapan 400 cihaz (R = 120), 200 baytlık bir JSON payload ve mesaj başına iki abone (bir veritabanı yazıcısı ve bir dashboard).
published = 400 x 120 x 730 = 35,040,000 messages / month
delivered = 35,040,000 x 2 = 70,080,000 messages / month
traffic in = 35,040,000 x 200 bytes = about 7 GB / month
traffic out= 70,080,000 x 200 bytes = about 14 GB / month
peak connections = 400 + 3 backend clients + headroom
Her sağlayıcının birimlerini bu değerlere uygulayın; ardından payload baytlarının hikâyenin tamamı olduğunu varsaymak yerine trafik tahminlerine yüzde birkaç onluk protokol ek yükü (TLS, MQTT başlıkları, keepalive'lar) ekleyin. Gerçek bir broker üzerinde yapılan ve konsolu veya $SYS istatistikleri üzerinden izlenen bir pilot çalışma, varsayımları ölçülmüş değerlerle değiştirmenizi sağlar.
Kontrolünüzdeki Maliyet Kaldıraçları
Model ne olursa olsun, tasarım tercihleriyle faturayı genellikle düşürebilirsiniz:
- Sabit ve hızlı aralıklar yerine değişim olduğunda veya ölü bant (deadband) ile yayın yapın.
- Gecikmenin izin verdiği yerlerde birkaç ölçümü tek mesajda toplayın.
- Bayt sayısını azaltmak için kompakt payload'lar veya MQTT 5 topic alias'ları kullanın.
- Birbirinin aynısı çok sayıda tüketici yerine shared subscription kullanın.
- Dağıtımı bir backend yapabiliyorsa her tarayıcı sekmesi için ayrı broker bağlantısı açmaktan kaçının.
Tahmininizi ConnectMQ Planlarına Eşleme
ConnectMQ, limitlerle tanımlanan kademeli planlar kullanır; bu da tahmini basitleştirir: zirve bağlantı sayınızı, QoS ve mesaj boyutu gereksinimlerinizi karşılayan en küçük planı bulmanız yeterlidir. Serverless (Free), en fazla 25 bağlantı, QoS 1'e kadar ve 256 KB mesaj boyutuyla paylaşımlı bir küme üzerinde çalışır; prototipler ve küçük pilotlar için uygundur. Serverless (Paid) bunu en fazla 1.000 bağlantı, QoS 2, 1 MB mesaj ve shared subscription desteğine çıkarır. Bunun ötesinde Dedicated izole bir küme sunar, BYOC ConnectMQ tarafından yönetilerek sizin bulut hesabınızda çalışır, Self Managed Enterprise ise sizin altyapınızda çalışır. Bir kotaya ulaşıldığında MQTT 5 istemcileri 0x97 (quota exceeded) gibi açık bir reason code alır; böylece limitler asla sessizce devreye girmez. MQTT broker bağlantı kotaları makalesi bu limitlere göre nasıl plan yapacağınızı anlatıyor.
ConnectMQ'da Planları Karşılaştırın
Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz Serverless planla başlayın, pilot sırasında gerçek trafiğinizi ölçün ve yalnızca rakamlar gerektirdiğinde üst plana geçin. ConnectMQ, her planda aynı endpoint'leri ve aynı istemci kodunu kullanan bir yönetilen MQTT broker hizmetidir. Dağıtım modelleri hakkında bilgi için bulut MQTT broker rehberimizi okuyun; piyasadaki ücretsiz planlardan neler bekleyebileceğinizi görmek için de MQTT broker ücretsiz katmanı yazımıza göz atın.
Sık Sorulan Sorular
Hangi MQTT broker fiyatlandırma modeli en ucuzu?
Genel olarak en ucuz olan bir model yoktur. Bağlantı başına fiyatlandırma az sayıda yoğun istemciye, mesaj başına fiyatlandırma çok sayıda sessiz cihaza, ayrılmış kapasite ise büyük ve istikrarlı yüklere uygundur. Önce iş yükünüzü tahmin edin, ardından her modeli uygulayın.
Keepalive ping'leri mesaj olarak sayılır mı?
Sağlayıcıya göre değişir. Bazıları yalnızca uygulama yayınlarını, diğerleri tüm MQTT paketlerini sayar. Bunu açıkça sorun, çünkü büyük bir filoda kısa keepalive aralıkları hızla birikebilir.
Sürpriz aşım ücretlerinden nasıl kaçınırım?
Limitleri otomatik faturalandırmak yerine reddeden veya hız sınırlayan bir plan seçin, kullanımı konsoldan izleyin ve bir kotaya yaklaşmadan önce uyarılar tanımlayın.
Gerçek cihazlar olmadan maliyet tahmini yapabilir miyim?
Evet, bu rehberdeki formülü varsayımsal hızlar ve payload boyutlarıyla kullanarak yapabilirsiniz. Varsayımları mümkün olan en kısa sürede küçük bir pilottan elde edilen ölçülmüş değerlerle değiştirin.



