Bir şirket, Amerika Birleşik Devletleri'nde milyonlarca ev sensörü içeren bir IoT çözümü işletmektedir. Sensörler, verileri tek bir EC2 örneğindeki özel bir MQTT broker'ına göndermek için MQTT kullanır. Sensörler, iot.example.com (Route 53) adresindeki broker'a bağlanır. Broker verileri DynamoDB'ye yazar. Broker birçok kez aşırı yüklendi ve veri kaybına neden oldu. Hangi çözüm güvenilirliği artırır ve gereksinimleri karşılar?

Doğru cevap, AWS IoT Core'u kullanmaktır çünkü bu hizmet, milyonlarca cihazdan gelen MQTT mesajlarını ölçeklenebilir ve güvenilir bir şekilde yönetmek için tasarlanmıştır. Mevcut tek EC2 örneğindeki özel MQTT broker'ı aşırı yükleniyor ve veri kaybına neden oluyordu; bu da ölçeklenebilirlik ve güvenilirlik sorunlarına işaret ediyor. AWS IoT Core, mesajları DynamoDB gibi diğer AWS hizmetlerine yönlendirmek için kurallar (IoT Rules Engine) kullanır, bu da broker'ın veri depolama yükünü kaldırır. Özel bir alan adı yapılandırmak ve Route 53 kaydını AWS IoT Core Data-ATS uç noktasına güncellemek, sensörlerin mevcut yapılandırmalarında minimum değişiklikle bağlanmaya devam etmesini sağlar. Yanlış seçenekler: Bir ALB ve Auto Scaling grubu oluşturmak, özel MQTT broker'ının ölçeklenebilirliğini artırsa da, ALB MQTT'yi doğrudan desteklemez ve broker'ın kendisi hala veri depolama yükünü taşıyarak potansiyel darboğazlar oluşturur. NLB ve Global Accelerator kullanmak, bağlantı güvenilirliğini ve performansını artırabilir ancak yine de tek bir EC2 örneğindeki özel MQTT broker'ının temel ölçeklenebilirlik ve veri depolama sorunlarını çözmez. AWS IoT Greengrass, uç cihazlarda çalıştırılmak üzere tasarlanmıştır ve merkezi bir bulut MQTT broker'ı yerine sensör verilerini toplamak için uygun değildir.