Approcci architetturali per IoT in una soluzione multi-tenant

Le soluzioni IoT multi-tenant sono disponibili in molti tipi e dimensioni diversi. Potrebbero essere presenti molti requisiti e vincoli, tra cui la proprietà dell'infrastruttura, l'isolamento dei dati dei clienti e la conformità. Può essere difficile definire un modello che soddisfi tutti questi vincoli di progettazione e spesso è necessario prendere in considerazione più dimensioni. Questo articolo descrive diversi approcci comunemente usati per risolvere le considerazioni sulla multi-tenancy per le soluzioni basate su IoT. Questo documento include architetture multi-tenant di esempio che sfruttano componenti comuni, in base all'architettura di riferimento IoT.

Considerazioni e requisiti principali

Queste considerazioni e requisiti vengono presentati nell'ordine in cui vengono in genere classificati in ordine di priorità per la progettazione di una soluzione.

Governance e conformità

Le considerazioni sulla governance e sulla conformità potrebbero richiedere l'uso di un modello o di un set specifico di risorse IoT. Non tutti i servizi IoT hanno le stesse certificazioni o funzionalità. Se è necessario soddisfare specifici standard di conformità, potrebbe essere necessario selezionare servizi specifici. Le informazioni sulla governance e la conformità sono illustrate in un articolo dedicato su questo argomento.

La governance in IoT può anche assumere forme aggiuntive, ad esempio la proprietà e la gestione dei dispositivi. Il cliente è proprietario del dispositivo o del provider di soluzioni? Chi possiede la gestione di tali dispositivi? Queste considerazioni e implicazioni sono univoche per ogni provider di soluzioni e possono portare a scelte diverse nel modello di tecnologia, distribuzione e multi-tenancy usato.

Ridimensiona

È importante pianificare la scalabilità della soluzione. La scala viene spesso considerata in queste tre dimensioni:

• Quantità di dispositivi: tutti i servizi di gestione dei dispositivi di Azure - Azure IoT Central, hub IoT di Azure servizio Device Provisioning (DPS) e hub IoT di Azure - presentano limitazioni sul numero di dispositivi supportati in una singola istanza.

  Suggerimento

  Fare riferimento alla documentazione su larga scala se si prevede di distribuire un numero molto elevato di dispositivi.

• Velocità effettiva dei dispositivi: dispositivi diversi, anche nella stessa soluzione, potrebbero avere requisiti di velocità effettiva diversi. "Velocità effettiva" in questo contesto si riferisce sia al numero di messaggi in un periodo di tempo che alle dimensioni dei messaggi. Ad esempio, in una soluzione smart-building, i termostati segnalano probabilmente i dati a una frequenza inferiore rispetto agli ascensori, mentre in una soluzione di veicolo connesso, i messaggi di dati di registrazione della fotocamera del veicolo saranno probabilmente maggiori dei messaggi di telemetria di navigazione. Se i messaggi sono limitati in relazione alla frequenza, potrebbe essere necessario aumentare le istanze di un determinato servizio, ma se sono limitate rispetto alle dimensioni, potrebbe essere necessario aumentare le istanze di un determinato servizio.

• Tenant: la scalabilità di un singolo tenant può essere ridotta, ma moltiplicata per il numero di tenant può aumentare rapidamente.

Prestazioni e affidabilità

Isolamento dei tenant

Le soluzioni completamente condivise possono avere vicini rumorosi. Nei casi di hub IoT e IoT Central, questo può comportare codici di risposta HTTP 429 ("Troppe richieste"), che sono errori rigidi che possono causare un effetto a catena. Per altre informazioni, vedere Quote e limitazione.

Nelle soluzioni completamente multi-tenant, questi effetti possono essere propagati. Quando i clienti condividono hub IoT o applicazioni IoT Central, tutti i clienti dell'infrastruttura condivisa inizieranno a ricevere errori. Poiché hub IoT e IoT Central sono in genere i punti di ingresso per i dati nel cloud, è probabile che anche altri sistemi downstream che dipendono da questi dati non riescano. Spesso, l'occorrenza più comune di questa situazione è quando è stato superato un limite di quota di messaggi. In questo caso, la soluzione più rapida e più semplice per le soluzioni hub IoT consiste nell'aggiornare lo SKU hub IoT, aumentare il numero di unità di hub IoT o entrambe. Per le soluzioni IoT Central, la soluzione viene ridimensionata automaticamente in base alle esigenze, fino al numero documentato di messaggi supportati.

È possibile isolare e distribuire i tenant tra i piani di controllo, gestione e comunicazione IoT usando i criteri di allocazione personalizzati di DPS. Inoltre, quando si seguono le indicazioni per le soluzioni IoT a scalabilità elevata, è possibile gestire una distribuzione di allocazione aggiuntiva a livello di bilanciamento del carico DPS.

Archiviazione dei dati, query, utilizzo e conservazione

Le soluzioni IoT tendono a essere molto a elevato utilizzo di dati, sia quando si esegue lo streaming che inattivi. Per altre informazioni sulla gestione dei dati nelle soluzioni multi-tenant, vedere Approcci architetturali per l'archiviazione e i dati nelle soluzioni multi-tenant.

Sicurezza

Le soluzioni IoT spesso hanno considerazioni sulla sicurezza a più livelli, soprattutto nelle soluzioni distribuite in un'architettura di riferimento aziendale purdue modificata dal cloud o in soluzioni industry 4.0. L'approccio di progettazione selezionato da quelli seguenti influirà sui livelli e i limiti di rete esistenti; una volta selezionata la progettazione fisica, è possibile selezionare l'implementazione della sicurezza. Gli strumenti che possono essere usati in qualsiasi approccio includono:

• Microsoft Defender per IoT, una soluzione di monitoraggio IoT completa da considerare che offre una licenza EIoT per dispositivo e licenze del sito OT per ogni dispositivo e/o sito. A seconda dell'approccio selezionato più avanti in questo articolo, lo scenario di licenza utente denominato Microsoft 365 potrebbe non essere possibile. In tal caso, sono disponibili le opzioni di licenza per dispositivo e sito, che sono opzioni di licenza indipendenti dalle licenze tenant di Microsoft 365.

• Firewall di Azure o un'appliance firewall di terze parti, che è consigliabile prendere in considerazione per isolare i livelli di rete e monitorare il traffico di rete. La scelta esatta dell'approccio influirà sulla posizione in cui i carichi di lavoro avranno isolamento di rete rispetto a una rete condivisa, come illustrato di seguito.

• Azure IoT Edge o Azure IoT Operations, che è consigliabile considerare come parte della connettività dei dispositivi ai servizi ospitati in Azure senza esporre direttamente i dispositivi all'accesso Diretto a Internet. Poiché le operazioni IoT di Azure sono in anteprima in questo momento, questo documento non descrive l'uso di tale offerta in generale. Verrà affrontata una revisione futura di questo documento.

La maggior parte di questi argomenti di sicurezza si applica in una soluzione multi-tenant simile a quella in una soluzione a tenant singolo, con le varianti associate all'approccio selezionato. Un componente che probabilmente sarà sostanzialmente diverso in una soluzione IoT complessiva è l'identità dell'utente e dell'applicazione. Gli approcci architetturali per l'identità nelle soluzioni multi-tenant illustrano questo aspetto di una soluzione multi-tenant complessiva.

Approcci da considerare

Tutte le considerazioni che normalmente si fanno in un'architettura IoT, per tutti i componenti principali (ad esempio gestione, inserimento, elaborazione, archiviazione, sicurezza e così via), sono tutte le scelte che è necessario fare quando si esegue una soluzione multi-tenant. La differenza principale è il modo in cui si organizzano e si usano i componenti per supportare la multi-tenancy. Ad esempio, i punti decisionali comuni per l'archiviazione potrebbero decidere se usare SQL Server o Azure Esplora dati o forse nel livello di inserimento e gestione, è possibile scegliere tra hub IoT e IoT Central.

La maggior parte delle soluzioni IoT rientra in un modello di architettura radice, che è una combinazione del modello di distribuzione, del modello di tenancy e del modello di distribuzione. Questi fattori sono determinati dai requisiti principali e dalle considerazioni descritte in precedenza.

Uno dei punti decisionali più importanti da prendere, all'interno dello spazio IoT, consiste nel selezionare tra approcci PaaS (Application-Platform-as-a-Service) e PaaS (Platform-as-a-Service). Per altre informazioni, vedere Confrontare gli approcci della soluzione Internet delle cose (IoT) (PaaS e aPaaS).

Questo è il dilemma comune di "compilazione e acquisto" che molte organizzazioni affrontano in molti progetti. È importante valutare i vantaggi e gli svantaggi di entrambe le opzioni.

Concetti e considerazioni per le soluzioni aPaaS

Una tipica soluzione aPaaS che usa Azure IoT Central, come core della soluzione, potrebbe usare i servizi PaaS e aPaaS di Azure seguenti:

• Hub eventi di Azure come motore di messaggistica e flusso di dati multipiattaforma di livello aziendale.
• App per la logica di Azure come offerta di piattaforma distribuita come servizio o iPaaS di integrazione.
• Azure Esplora dati come piattaforma di analisi dei dati.
• Power BI come piattaforma di visualizzazione e creazione di report.

Nel diagramma precedente i tenant condividono un ambiente IoT Central, Azure Esplora dati, Power BI e App per la logica di Azure.

Questo approccio è in genere il modo più rapido per ottenere una soluzione sul mercato. Si tratta di un servizio su larga scala che supporta la multi-tenancy usando le organizzazioni.

È importante comprendere che poiché IoT Central è un'offerta aPaaS, esistono determinate decisioni che non rientrano nel controllo di un implementatore. Queste decisioni includono:

• IoT Central usa Microsoft Entra ID come provider di identità.
• Le distribuzioni di IoT Central vengono eseguite usando operazioni sia di controllo che di piano dati, che combinano documenti dichiarativi con codice imperativo.
• In un modello multi-tenant, sia il limite massimo di nodi di IoT Central (che si applica sia agli elementi padre che alle foglie) e alla profondità massima dell'albero, potrebbe forzare un provider di servizi ad avere più istanze di IoT Central. In tal caso, è consigliabile seguire il modello Deployment Stamp.
• IoT Central impone limiti di chiamata API, che potrebbero influire sulle implementazioni di grandi dimensioni.

Concetti e considerazioni per le soluzioni PaaS

Un approccio basato su PaaS può usare i servizi di Azure seguenti:

• hub IoT di Azure come piattaforma di configurazione e comunicazione del dispositivo principale.
• Servizio Device Provisioning IoT di Azure come distribuzione del dispositivo e piattaforma di configurazione iniziale.
• Azure Esplora dati per l'archiviazione e l'analisi dei dati delle serie temporali dei percorsi ad accesso frequente e sporadico dai dispositivi IoT.
• Analisi di flusso di Azure per l'analisi dei dati dei percorsi ad accesso frequente dai dispositivi IoT.
• Azure IoT Edge per l'esecuzione di intelligenza artificiale ,servizi di terze parti o logica di business nei dispositivi IoT Edge.

Nel diagramma precedente ogni tenant si connette a un'app Web condivisa, che riceve dati da hub IoT e un'app per le funzioni. I dispositivi si connettono al servizio Device Provisioning e a hub IoT.

Questo approccio richiede maggiore impegno per gli sviluppatori per creare, distribuire e gestire la soluzione (rispetto a un approccio aPaaS). Per comodità dell'implementatore, sono predefinite meno funzionalità. Ciò significa che questo approccio offre anche un maggiore controllo, perché meno presupposti sono incorporati nella piattaforma sottostante.

Modelli di architettura radice

La tabella seguente elenca i modelli comuni per le soluzioni IoT multi-tenant. Ogni modello include le informazioni seguenti:

• Nome del modello, basato sulla combinazione del tipo di destinazione, del modello e della distribuzione.
• Destinazione di distribuzione, che rappresenta la sottoscrizione di Azure in cui distribuire le risorse.
• Il modello Tenancy a cui viene fatto riferimento dal modello, come descritto in Modelli multi-tenancy
• Modello di distribuzione, che fa riferimento a una distribuzione semplice con considerazioni minime sulla distribuzione, un modello Geode o un modello deployment stamp.

Modello	Destinazione di distribuzione	Modello tenancy	Modello di distribuzione
SaaS semplice	Sottoscrizione del provider di servizi	Completamente multi-tenant	Semplice
SaaS orizzontale	Sottoscrizione del provider di servizi	Partizionato orizzontalmente	Stamp di distribuzione
Automatizzato a tenant singolo	Sottoscrizione del provider di servizi o del cliente	Tenant singolo per cliente	Semplice

SaaS semplice

Destinazione distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi	Completamente multi-tenant	Semplice

L'approccio SaaS semplice è l'implementazione più semplice per una soluzione IoT SaaS. Come illustrato nel diagramma precedente, tutta l'infrastruttura è condivisa e l'infrastruttura non ha un timbro geografico o scala applicato. Spesso l'infrastruttura si trova all'interno di una singola sottoscrizione di Azure.

Azure IoT Central supporta il concetto di organizzazioni. Le organizzazioni consentono a un provider di soluzioni di separare facilmente i tenant in modo sicuro e gerarchico, condividendo al tempo stesso la progettazione di base delle applicazioni in tutti i tenant.

Le comunicazioni ai sistemi all'esterno di IoT Central, ad esempio per l'analisi dei dati a lungo termine, lungo un percorso sporadico o una connettività con le operazioni aziendali, vengono eseguite tramite altre offerte Microsoft PaaS e aPaaS. Queste offerte aggiuntive possono includere i servizi seguenti:

• Hub eventi di Azure come motore di messaggistica e flusso di dati multipiattaforma di livello aziendale.
• App per la logica di Azure come piattaforma di integrazione distribuita come servizio o iPaaS.
• Azure Esplora dati come piattaforma di analisi dei dati.
• Power BI come piattaforma di visualizzazione e creazione di report.

Se si confronta l'approccio SaaS semplice con il modello aPaaS automatizzato a tenant singolo, molte caratteristiche sono simili. La differenza principale tra i due modelli è che nel modello automatizzato a tenant singolo si distribuisce un'istanza di IoT Central distinta per ogni tenant, mentre nel modello SaaS semplice con aPaaS si distribuisce invece un'istanza condivisa per più clienti e si crea un'organizzazione IoT Central per ogni tenant.

Quando si condivide un livello dati multi-tenant in questo modello, è necessario implementare la sicurezza a livello di riga, come descritto in Approcci architetturali per l'archiviazione e i dati in soluzioni multi-tenant, per isolare i dati dei clienti.

Vantaggi:

• Più facile da gestire e operare rispetto agli altri approcci presentati qui.

Rischi:

• Questo approccio potrebbe non essere facilmente ridimensionato a un numero molto elevato di dispositivi, messaggi o tenant.

• Poiché tutti i servizi e i componenti sono condivisi, un errore in qualsiasi componente potrebbe influire su tutti i tenant. Si tratta di un rischio per l'affidabilità e la disponibilità elevata della soluzione.

• È importante considerare come gestire la conformità, le operazioni, il ciclo di vita del tenant e la sicurezza dei dispositivi secondari. Queste considerazioni diventano importanti a causa della natura condivisa di questo tipo di soluzione nei piani di controllo, gestione e comunicazione.

SaaS orizzontale

Destinazione di distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi	Partizionato orizzontalmente	Stamp di distribuzione

Un approccio di scalabilità comune consiste nel partizionare orizzontalmente la soluzione. Ciò significa che sono presenti alcuni componenti condivisi e alcuni componenti per cliente.

All'interno di una soluzione IoT sono disponibili molti componenti che possono essere partizionati orizzontalmente. I sottosistemi partizionati orizzontalmente vengono in genere disposti usando un modello di stamp di distribuzione che si integra con la soluzione più grande.

Esempio di SaaS orizzontale

L'esempio di architettura seguente partiziona IoT Central per cliente finale, che funge da portale di gestione dei dispositivi, comunicazioni dei dispositivi e amministrazione. Questa operazione viene spesso eseguita in modo che il cliente finale che utilizza la soluzione abbia il controllo completo sull'aggiunta, la rimozione e l'aggiornamento dei dispositivi stessi, senza l'intervento del fornitore di software. Il resto della soluzione segue un modello di infrastruttura condivisa standard, che risolve l'analisi dei percorsi ad accesso frequente, le integrazioni aziendali, la gestione SaaS e le esigenze di analisi dei dispositivi.

Ogni tenant ha una propria organizzazione IoT Central, che invia dati di telemetria a un'app per le funzioni condivise e la rende disponibile agli utenti aziendali dei tenant tramite un'app Web.

Vantaggi:

• In genere facile da gestire e gestire, anche se potrebbe essere necessaria una gestione aggiuntiva per i componenti a tenant singolo.
• Opzioni di ridimensionamento flessibili, perché i livelli vengono ridimensionati in base alle esigenze.
• L'impatto degli errori dei componenti è ridotto. Anche se un errore di un componente condiviso influisce su tutti i clienti, i componenti ridimensionati orizzontalmente influiscono solo sui clienti associati a istanze di scalabilità specifiche.
• Miglioramento delle informazioni dettagliate sul consumo per tenant per i componenti partizionati.
• I componenti partizionati offrono personalizzazioni più semplici per tenant.

Rischi:

• Prendere in considerazione la scalabilità della soluzione, in particolare per tutti i componenti condivisi.
• L'affidabilità e la disponibilità elevata sono potenzialmente influenzate. Un singolo errore nei componenti condivisi potrebbe influire su tutti i tenant contemporaneamente.
• La personalizzazione del componente partizionato per tenant richiede considerazioni su DevOps e gestione a lungo termine.

Di seguito sono riportati i componenti più comuni che sono in genere adatti per il partizionamento orizzontale.

Database

È possibile scegliere di partizionare i database. Spesso si tratta dei dati di telemetria e degli archivi dati del dispositivo partizionati. Spesso vengono usati più archivi dati per scopi specifici diversi, ad esempio archiviazione ad accesso frequente o archiviazione o per informazioni sullo stato della sottoscrizione tenancy.

Separare i database per ogni tenant, per i vantaggi seguenti:

• Supportare gli standard di conformità. I dati di ogni tenant sono isolati tra istanze dell'archivio dati.
• Correggere i problemi del vicino rumoroso.

Gestione, comunicazioni e amministrazione dei dispositivi

hub IoT di Azure servizio Device Provisioning, hub IoT e le applicazioni IoT Central possono spesso essere distribuite come componenti partizionati orizzontalmente. Se si segue questo approccio, è necessario disporre di un servizio aggiuntivo per reindirizzare i dispositivi al servizio Device Provisioning appropriato per il piano di gestione, controllo e telemetria del tenant specifico. Per altre informazioni, vedere il white paper, Scalabilità orizzontale di una soluzione Azure IoT per supportare milioni di dispositivi.

Questa operazione viene spesso eseguita per consentire ai clienti finali di gestire e controllare la propria flotta di dispositivi che sono più direttamente e completamente isolati.

Se il piano di comunicazione del dispositivo è partizionato orizzontalmente, i dati di telemetria devono essere arricchiti con i dati per il tenant di origine, in modo che il processore di flusso conosca le regole del tenant da applicare al flusso di dati. Ad esempio, se un messaggio di telemetria genera una notifica nel processore di flusso, il processore di flusso dovrà determinare il percorso di notifica appropriato per il tenant associato.

Elaborazione dei flussi

Partizionando l'elaborazione del flusso, si abilitano le personalizzazioni per tenant dell'analisi all'interno dei processori di flusso.

Automatizzato a tenant singolo

Un approccio automatizzato a tenant singolo si basa su un processo decisionale e una progettazione simili a una soluzione aziendale.

Ogni tenant ha un ambiente identico e isolato, con un'organizzazione IoT Central e altri componenti dedicati.

Destinazione distribuzione	Modello tenancy	Modello di distribuzione
Sottoscrizione del provider di servizi o del cliente	Tenant singolo per cliente	Semplice

Un punto decisionale critico in questo approccio consiste nella scelta della sottoscrizione di Azure in cui devono essere distribuiti i componenti. Se i componenti vengono distribuiti nella sottoscrizione, si ha un maggiore controllo e una migliore visibilità sul costo della soluzione, ma è necessario avere maggiori problemi di sicurezza e governance della soluzione. Viceversa, se la soluzione viene distribuita nella sottoscrizione del cliente, il cliente è responsabile della sicurezza e della governance della distribuzione.

Questo modello supporta un livello elevato di scalabilità. Ciò è dovuto al fatto che i requisiti di tenant e sottoscrizione sono in genere i fattori di limitazione nella maggior parte delle soluzioni. Pertanto, isolare ogni tenant per offrire un ambito di grandi dimensioni per il ridimensionamento del carico di lavoro di ogni tenant, senza sforzi sostanziali da parte dello sviluppatore della soluzione.

Questo modello ha anche una bassa latenza rispetto ad altri modelli, perché è possibile distribuire i componenti della soluzione in base all'area geografica dei clienti. L'affinità geografica consente percorsi di rete più brevi tra un dispositivo IoT e la distribuzione di Azure.

Se necessario, è possibile estendere la distribuzione automatizzata per supportare una migliore latenza o scalabilità, consentendo la rapida distribuzione di istanze aggiuntive della soluzione, per un cliente in aree geografiche nuove o esistenti.

L'approccio automatizzato a tenant singolo è simile al semplice modello saaS aPaaS. La differenza principale tra i due modelli è che nell'approccio automatizzato a tenant singolo si distribuisce un'istanza di IoT Central distinta per ogni tenant, mentre nel modello SaaS semplice con un modello aPaaS si distribuisce un'istanza condivisa di IoT Central con più organizzazioni IoT Central.

Vantaggi:

• Relativamente facile da gestire e gestire.
• L'isolamento del tenant è essenzialmente garantito.

Rischi:

• L'automazione iniziale può essere complicata per il nuovo personale di sviluppo.
• La sicurezza delle credenziali tra clienti per la gestione della distribuzione di livello superiore deve essere applicata oppure le compromissioni possono estendersi tra i clienti.
• Si prevede che i costi siano più elevati, perché i vantaggi di scalabilità di un'infrastruttura condivisa tra i clienti non sono disponibili.
• Se il provider di soluzioni è proprietario della manutenzione di ogni istanza, potrebbero essere presenti molte istanze da gestire.

Aumentare la scalabilità di SaaS

Quando si espande la scalabilità di una soluzione a distribuzioni molto grandi, esistono sfide specifiche che si verificano in base ai limiti del servizio, alle problematiche geografiche e ad altri fattori. Per altre informazioni sulle architetture di distribuzione IoT su larga scala, vedere Scalabilità orizzontale di una soluzione Azure IoT per supportare milioni di dispositivi.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Michael C. Bazarewsky | Senior Customer Engineer, FastTrack per Azure
• David Crook | Principal Customer Engineer, FastTrack per Azure

Altri contributori:

• John Downs | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Passaggi successivi

• Esaminare le linee guida per la multi-tenancy e Azure Cosmos DB.
• Informazioni sui percorsi di dati ad accesso frequente, ad accesso frequente e ad accesso sporadico con IoT in Azure.
• Fare riferimento alle architetture di riferimento di Azure IoT.
• Vedere la documentazione su come ridimensionare le soluzioni IoT con indicatori di distribuzione.