Una piattaforma IoT acquisisce dati da sensori tramite server API Node.js su EC2 dietro un Application Load Balancer e li memorizza in un'istanza RDS MySQL su un singolo SSD per uso generico da 4 TB. Il numero di sensori è in crescita; i server API sono sovraccarichi e RDS mostra un'elevata latenza di scrittura. Quali due azioni insieme forniscono una risoluzione permanente, scalabile ed economicamente vantaggiosa all'aumentare dei sensori?

Le due azioni corrette risolvono i problemi di scalabilità e latenza in modo duraturo ed economico. L'uso di Amazon Kinesis Data Streams per l'acquisizione dei dati grezzi dei sensori e l'elaborazione con AWS Lambda disaccoppia l'ingestione dei dati dall'elaborazione, consentendo una scalabilità elevata e gestendo picchi di traffico senza sovraccaricare i server API. La riprogettazione del database per utilizzare Amazon DynamoDB invece di RDS MySQL offre una soluzione NoSQL altamente scalabile e a bassa latenza, ideale per carichi di lavoro IoT con elevati volumi di scrittura e lettura. Aumentare la dimensione del volume MySQL a 6 TB migliorerebbe gli IOPS ma non risolverebbe il problema di scalabilità intrinseco di un singolo database relazionale in un ambiente IoT in crescita. Riprogettare il livello del database su Amazon Aurora e aggiungere repliche di lettura migliorerebbe la scalabilità di lettura, ma la latenza di scrittura rimarrebbe un collo di bottiglia per un singolo writer in un ambiente IoT ad alta intensità di scrittura. Utilizzare AWS X-Ray per risolvere i problemi dell'applicazione e aggiungere altri server API aiuterebbe a gestire il carico sui server API, ma non risolverebbe il problema della latenza di scrittura del database RDS MySQL.