AWS IoT Core Alternatifi: Standart Bir MQTT Broker Ne Zaman Daha Basittir

Projeniz buluta özgü bir IoT platformundan çok standart bir MQTT broker'a ihtiyaç duyuyorsa bir AWS IoT Core alternatifi anlamlı hale gelir. Bu rehber AWS IoT Core'un neler sunduğunu, hangi farkları değerlendirmeniz gerektiğini, kimlik doğrulama modellerinin nasıl karşılaştırıldığını ve standartlara dayalı yönetilen bir broker'ın ne zaman daha basit yol olduğunu, her ikisini test etmek için kullanabileceğiniz kodla birlikte açıklıyor.

AWS IoT Core'un Güçlü Olduğu Alanlar

AWS IoT Core, cihazları AWS bulutuna bağlayan yönetilen bir hizmettir. Bir MQTT uç noktasının ötesinde; cihaz kaydı ve kimliği, X.509 sertifika tabanlı kimlik doğrulama, ayrıntılı IoT politikaları, device shadow'lar ve mesajları diğer AWS hizmetlerine yönlendiren bir rules engine sunar. Arka ucunuz zaten AWS'de çalışıyorsa ve cihaz verilerinin az miktarda yapıştırıcı kodla AWS hizmetlerine akmasını istiyorsanız, bu entegrasyon onu seçmenin ana nedenidir.

Bu makale AWS IoT Core'un iyi olup olmadığıyla ilgili değil; projenize doğru biçimde uyup uymadığıyla ilgilidir. AWS hizmeti düzenli olarak günceller; bu yüzden her belirli noktayı güncel AWS IoT Core geliştirici kılavuzuyla doğrulayın.

Ekipler Ne Zaman Bir Alternatif Arar

Nedenler genellikle birkaç gruba ayrılır:

• Sade bir broker'a ihtiyaç duyarlar. Proje bir AWS veri hattı değil; cihazdan uygulamaya mesajlaşma, bir dashboard ya da endüstriyel bir veri merkezidir.
• Arka uçları AWS'de değildir. Başka bir bulutta, şirket içinde ya da karma bir ortamda çalışır.
• Devreye alma sürtünmesi. Cihaz başına sertifika provisioning'i güçlü bir güvenliktir, ancak prototipler, sınıflar ve küçük filolar için ek adımlar getirir.
• Taşınabilirlik endişeleri. Birkaç ayarı değiştirerek broker'lar arasında taşınabilen cihazlar isterler.
• Öngörülebilir fiyatlandırma modelleri. Bazı ekipler kullanım bazlı ölçüm yerine plan bazlı fiyatlandırmayı tercih eder. Hangisinin daha ucuz olduğu tamamen iş yükünüze bağlıdır.

Neleri Değerlendirmeli: AWS IoT Core vs Standart Bir MQTT Broker

AWS, MQTT uygulamasının MQTT spesifikasyonundan nerelerde ayrıldığını anlatan bir sayfa yayımlar. Bunu gereksinimlerinizle birlikte okuyun. Tablo, güncel ayrıntıları iddia etmek yerine neleri kontrol etmeniz gerektiğini listeliyor.

Son iki satır, AWS IoT Core'un daha fazlasını yerleşik olarak sunduğu yerlerdir. Bunlar tasarımınızın merkezindeyse o daha uygun seçim olabilir.

Kimlik Doğrulama Modelindeki Fark

Bu çoğu zaman en büyük pratik farktır.

Tipik bir AWS IoT Core cihazı, Amazon kök CA'sının yanı sıra bir istemci sertifikası ve özel anahtar tutar ve karşılıklı TLS (mutual TLS) ile bağlanır. Sertifikaya bağlı politikalar neye yayın yapıp neye abone olabileceğini kontrol eder. Bu güçlü bir modeldir ve ölçekte bir provisioning süreci gerektirir.

ConnectMQ gibi standart bir broker ise portalda verilen kullanıcı adı, parola ve client ID ile sunucu taraflı TLS kullanır. Cihazlar broker'ın Let's Encrypt sertifikasını sistem CA deposunu kullanarak doğrular ve client ID verilen kimlik bilgilerine bağlıdır. Başlamak daha basittir; sizin sorumluluğunuz kimlik bilgilerini cihazlarda güvenli şekilde saklamaktır.

Hiçbiri evrensel olarak daha iyi değildir. Filo boyutunuzun, güvenlik gereksinimlerinizin ve üretim sürecinizin hangi modeli destekleyebileceğini değerlendirin.

Her İkisiyle de Çalışan Cihaz Kodu Yazmak

Tedarikçi bağımlılığından kaçınmanın en iyi yolu bağlantı ayrıntılarını uygulama mantığından ayırmaktır. Bu MQTT.js v5 örneği ya bir sertifikayla (AWS IoT Core tarzı) ya da kullanıcı adı ve parolayla (standart broker) bağlanır; kodun geri kalanı birebir aynı kalır:

// npm install mqtt
const fs = require("fs");
const mqtt = require("mqtt");

const mode = process.env.BROKER_MODE || "standard"; // "standard" veya "certificate"

const options = {
  clientId: process.env.MQTT_CLIENT_ID || "YOUR_CLIENT_ID",
  protocolVersion: 5,
  reconnectPeriod: 5000,
};

let url;
if (mode === "certificate") {
  url = `mqtts://${process.env.MQTT_ENDPOINT}:8883`;
  options.key = fs.readFileSync("device.private.key");
  options.cert = fs.readFileSync("device.cert.pem");
  options.ca = fs.readFileSync("root-ca.pem");
} else {
  url = "mqtts://broker.connectmq.com:8883";
  options.username = process.env.MQTT_USERNAME || "YOUR_USERNAME";
  options.password = process.env.MQTT_PASSWORD || "YOUR_PASSWORD";
}

const client = mqtt.connect(url, options);
const topic = "site1/area1/pump7/telemetry";

client.on("connect", () => {
  console.log("Connected in", mode, "mode");
  setInterval(() => {
    const reading = { pressure: 2.4 + Math.random() * 0.2, ts: Date.now() };
    client.publish(topic, JSON.stringify(reading), { qos: 1 });
  }, 5000);
});

client.on("error", (err) => console.error("MQTT error:", err.message));

Topic adlarını sağlayıcıya özgü öneklerden arındırın ve cihaz firmware'inde yalnızca sağlayıcıya özgü özelliklere bağımlı olmaktan kaçının. Böylece sağlayıcı değiştirmek bir yapılandırma değişikliğine dönüşür. MQTT tedarikçi bağımlılığı makalesi dikkat edilmesi gereken desenleri listeliyor.

AWS'ye Özgü Özellikleri Değiştirmek

Sade bir broker'a geçerseniz kullandığınız özellikleri nasıl karşılayacağınızı planlayın:

1. Rules engine. Topic'leri okuyup veritabanınıza ya da API'nize yazan bir abone servisi, Node-RED akışı ya da Telegraf ajanı çalıştırın.
2. Device shadow'lar. İstenen ve raporlanan durumu site1/area1/pump7/state/reported ve .../state/desired gibi retained topic'lerde yayınlayın.
3. Filo kimliği. Cihaz başına bir kimlik bilgisi seti verin ve envanteri kendi sisteminizde tutun.
4. İzleme. Broker'ın bağlantı durumu topic'ini (ConnectMQ'da $SYS/broker/connection/{clientId}/state) ve portal dashboard'unu kullanın.

Düşük Riskli Bir Taşıma Yolu

Cihazların bir kısmını ya da tamamını taşımaya karar verirseniz bunu tek seferde değil, aşamalar halinde yapın:

1. Önce yansıtın. Mevcut uç noktadaki seçili topic'lere abone olup bunları yeni broker'a yeniden yayınlayan küçük bir bridge servisi çalıştırın. Böylece cihazlar yerlerinde kalırken dashboard'lar ve yeni tüketiciler yeni broker'a geçebilir.
2. Bir cihaz grubuyla pilot yapın. Küçük bir cihaz grubunu yeni uç nokta ve kimlik bilgileriyle yeniden flash'layın ya da yapılandırın. Yeniden bağlanma davranışını, mesaj hızlarını ve payload boyutlarını yeni planın sınırlarına göre izleyin.
3. Entegrasyonları taşıyın. Her kuralı, bir seferde bir veri hedefi olmak üzere harici bir abone ya da Node-RED akışıyla değiştirin ve çıktıları yan yana karşılaştırın.
4. Filoyu dalgalar halinde geçirin; her dalga kararlı hale gelene kadar eski yapılandırmayı geri dönüş için hazır tutun.

Her iki taraf da MQTT konuştuğu için her aşama geri alınabilir; firmware'i sağlayıcıya özgü bağımlılıklardan arındırılmış tutmanın ana nedeni de budur.

Bir Karar Kontrol Listesi

• Arka ucunuzun çoğu AWS'de mi ve rules engine'i yoğun olarak kullanıyor musunuz? Muhtemelen AWS IoT Core daha uygundur.
• Ortamlar arasında cihazlar, uygulamalar ve şirket içi sistemler için tarafsız bir broker'a mı ihtiyacınız var? Standart bir broker daha basittir.
• QoS 2'ye ya da belirli MQTT 5 özelliklerine ihtiyacınız var mı? Her iki taraftaki güncel desteği kontrol edin.
• Cihaz başına sertifika provisioning'i bugün sizin için pratik mi?
• Ekibiniz, yalın bir broker'ın harici araçlara bıraktığı entegrasyonları çalıştırabilir mi?

Standartlara Dayalı Bir Broker Deneyin

Hiçbir şeyi taşımadan alternatifi değerlendirebilirsiniz. Kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, yukarıdaki betiği standart modda çalıştırın ve trafiği canlı topic gezgininde inceleyin. Daha fazla bağlam için bulut MQTT broker rehberini okuyun, Azure IoT Hub alternatifi ile karşılaştırın ve yönetilen bir MQTT broker'ın bir IoT platformundan nasıl farklılaştığını görün. Daha fazlasını connectmq.com adresinde öğrenin.

Sık Sorulan Sorular

AWS IoT Core için geliştirilmiş cihazlar başka bir MQTT broker'a bağlanabilir mi?

Evet, standart MQTT kullanıyorlarsa. Genellikle uç noktayı değiştirir, sertifika tabanlı kimlik doğrulamadan yeni broker'ın yöntemine geçer ve AWS'ye özgü topic kullanımlarını kaldırırsınız.

Standart bir broker AWS IoT rules engine'in yerini alır mı?

Tek başına almaz. Veriyi yönlendirmek için harici bir abone, Node-RED ya da Telegraf eklersiniz; bu da her parçanın değiştirilebilir kalmasını sağlar.

AWS IoT Core, kullanıcı adı ve parolalı bir broker'dan daha mı güvenlidir?

Cihaz başına sertifikalarla karşılıklı TLS güçlü bir modeldir. Cihaz başına benzersiz kimlik bilgileriyle TLS kullanan bir broker da, kimlik bilgileri doğru şekilde saklanıp döndürüldüğünde sağlam bir yaklaşımdır.

AWS IoT Core sınırlarını nereden kontrol etmeliyim?

Sınırlar ve desteklenen özellikler değiştiğinden güncel AWS IoT Core geliştirici kılavuzunu ve service quotas sayfalarını kullanın.