Azure IoT-referentiearchitectuur

Blob Storage
Functions
IoT Hub
Logic Apps
Stream Analytics

Deze referentiearchitectuur is een aanbevolen architectuur voor IoT-toepassingen in Azure die PaaS-componenten (Platform-as-a-Service) gebruiken.

Schema van de architectuur

IoT-toepassingen kunnen worden beschreven als dingen (apparaten) die gegevens verzenden die inzichten genereren. Deze inzichten genereren acties waarmee een bedrijf of proces kan worden verbeterd. Een voorbeeld is een motor (het ding) die temperatuurgegevens verzendt. Deze gegevens worden gebruikt om te beoordelen of de motor werkt zoals verwacht (het inzicht). Het inzicht wordt gebruikt om proactief prioriteit toe te kennen aan de onderhoudsplanning voor de motor (de actie).

Deze referentiearchitectuur maakt gebruik van Azure PaaS-componenten (Platform-as-a-Service). Een andere aanbevolen optie voor het bouwen van IoT-oplossingen in Azure is:

  • Azure IoT Central. IoT Central is een volledig beheerde SaaS-oplossing (Software-as-a-Service). De oplossing verzorgt alle technische keuzes zodat u zich exclusief kunt richten op uw oplossing. Het compromis van deze vereenvoudigde werkwijze is dat deze oplossing minder flexibel is dan een PaaS-oplossing.

In algemene zin zijn er twee manieren om telemetrische gegevens te verwerken: dynamisch en niet-dynamisch. Het verschil heeft te maken met vereisten voor latentie en gegevenstoegang.

  • Bij de dynamische aanpak worden gegevens bijna in realtime geanalyseerd, op het moment dat ze binnenkomen. In dit geval moet de telemetrie worden verwerkt met een zeer lage latentie. De dynamische aanpak wordt meestal geïmplementeerd met behulp van een engine voor de verwerking van gegevensstromen. De uitvoer kan een waarschuwing activeren of worden weggeschreven naar een gestructureerde indeling die kan worden bevraagd met analytische tools.
  • Bij de niet-dynamische aanpak worden batches verwerkt met langere intervallen (elk uur of dagelijks). Deze aanpak wordt meestal gebruikt voor de verwerking van grote hoeveelheden gegevens, maar de resultaten hoeven niet zo snel beschikbaar te zijn als bij de dynamische aanpak. Bij de niet-dynamische aanpak worden onbewerkte telemetriegegevens vastgelegd, die vervolgens worden aangeboden aan een batchproces.

Architectuur

Deze architectuur bestaat uit de volgende onderdelen. Voor sommige toepassingen zijn mogelijk niet alle hier vermelde onderdelen nodig.

IoT-apparaten. Apparaten kunnen veilig worden geregistreerd bij de cloud en kunnen verbinding maken met de cloud voor het verzenden en ontvangen van gegevens. Sommige apparaten kunnen edge-apparaten zijn die een beperkte mate van gegevensverwerking uitvoeren op het apparaat zelf of op een veldgateway. Het is raadzaam Azure IoT Edge te gebruiken voor verwerking aan de rand.

Cloudgateway. Een cloudgateway biedt een cloudhub waarmee apparaten veilig verbinding kunnen maken met de cloud om gegevens te verzenden. De gateway biedt ook functies voor apparaatbeheer, waaronder controle over apparaten. Voor de cloudgateway adviseren wij IoT Hub. IoT Hub is een gehoste cloudservice die gebeurtenissen opneemt van apparaten en zo fungeert als een berichtenbroker tussen apparaten en back-endservices. IoT Hub biedt veilige connectiviteit, opname van gebeurtenissen, bidirectionele communicatie en beheer van apparaten.

Apparaatinrichting. Als u grote sets met apparaten wilt registreren en verbinden, raden we aan om de IoT Hub Device Provisioning Service (DPS) te gebruiken. Met DPS kunt u op schaal apparaten toewijzen aan specifieke Azure IoT Hub-eindpunten en registreren.

Stroomverwerking. Stroomverwerking zorgt voor de analyse van grote stromen met gegevensrecords en evalueert regels voor deze stromen. Wij adviseren Azure Stream Analytics voor de verwerking van gegevensstromen. Stream Analytics kan complexe analyse op schaal uitvoeren met behulp van time windowing-functies, stroomaggregaties en joins van externe gegevensbronnen. Een andere optie is Apache Spark met Azure Databricks.

Machine learning maakt het mogelijk om voorspellende algoritmen uit te voeren op historische telemetriegegevens, om zo bijvoorbeeld scenario's voor voorspellend onderhoud te realiseren. Voor machine learning is Azure Machine Learning de aanbevolen optie.

Pad voor dynamische opslag: bevat gegevens die direct vanaf het apparaat beschikbaar moeten zijn voor rapportage en visualisatie. Voor dit type opslag adviseren wij Cosmos DB. Cosmos DB is een wereldwijd gedistribueerde, multi-model database.

Pad voor koude opslag: bevat gegevens die op de langere termijn worden bewaard en worden gebruikt voor batchverwerking. Voor dit type opslag adviseren wij Azure Blob Storage. Gegevens kunnen in een blobopslag voor onbepaalde tijd tegen lage kosten worden gearchiveerd en zijn eenvoudig toegankelijk voor batchverwerking.

Gegevenstransformatie manipuleert of aggregeert de telemetriestroom. Voorbeelden zijn protocoltransformatie, zoals het converteren van binaire gegevens naar JSON, of het combineren van gegevenspunten. Als de gegevens moeten worden getransformeerd voordat ze aankomen bij IoT Hub, is het raadzaam een protocolgateway (niet weergegeven) te gebruiken. Anders kunnen gegevens worden getransformeerd nadat ze IoT Hub hebben bereikt. In dat geval raden wij aan Azure Functions te gebruiken, omdat dit ingebouwde integratie heeft met IoT Hub, Cosmos DB en Blob Storage.

Integratie van bedrijfsprocessen voert acties uit op basis van inzichten van de apparaatgegevens. Hierbij kan het gaan om het opslaan van informatieve berichten, het activeren van waarschuwingen, het versturen van e-mail of sms-berichten, of integratie met CRM. Wij adviseren Azure Logic Apps voor de integratie van bedrijfsprocessen.

Gebruikersbeheer beperkt welke gebruikers of groepen acties kunnen uitvoeren op apparaten, zoals het bijwerken van de firmware. Deze component definieert ook mogelijkheden voor gebruikers in toepassingen. Wij adviseren het gebruik van Azure Active Directory om gebruikers te verifiëren en te autoriseren.

Beveiligingsbewaking Azure Security Center for IoT biedt een end-to-end beveiligingsoplossing voor IoT-workloads en vereenvoudigt de beveiliging door uniforme zichtbaarheid en controle, adaptieve bedreigingspreventie en intelligente detectie van bedreigingen en respons te bieden voor workloads van leaf-apparaten via Edge en via de clouds.

Schaalbaarheidsoverwegingen

Een IoT-toepassing moet worden gebouwd als een discrete service die onafhankelijk kan worden geschaald. Houd rekening met de volgende aandachtspunten voor schaalbaarheid:

IoTHub. Houd rekening met de volgende schaalfactoren voor IoT Hub:

  • Het maximale dagelijkse quotum van berichten naar IoT Hub.
  • Het quotum van verbonden apparaten in een IoT Hub-instantie.
  • Opname-doorvoer — hoe snel IoT Hub berichten kan opnemen.
  • Verwerkingsdoorvoer — hoe snel de binnenkomende berichten worden verwerkt.

Elke IoT-hub is ingericht met een bepaald aantal eenheden in een bepaalde laag. De laag en het aantal eenheden bepalen het maximale dagelijkse quotum voor berichten dat apparaten naar de hub kunnen verzenden. Raadpleeg de quota en beperkingen vaoor IoT HuB voor meer informatie. U kunt een hub opschalen zonder dat bestaande bewerkingen worden onderbroken.

Stream Analytics. Voor een optimale schaling van Stream Analytics-taken moeten deze op alle punten in de pijplijn van Stream Analytics parallel zijn, van invoer tot query en uitvoer. Bij een volledig parallelle taak kan het werk door Stream Analytics worden verdeeld over meerdere rekenknooppunten. Anders moet Stream Analytics de stroomgegevens op één locatie combineren. Zie Query-parallellisatie gebruiken in Azure Stream Analytics voor meer informatie.

Berichten van apparaten worden op basis van de apparaat-id automatisch in partities verdeeld door IoT Hub. Alle berichten vanaf een bepaald apparaat worden altijd in dezelfde partitie bezorgd, maar één partitie kan berichten van meerdere apparaten bevatten. De eenheid van parallellisering is daarom de partitie-id.

Functies. Bij het lezen van gegevens van het eindpunt van Event Hubs, geldt er een maximum voor het aantal exemplaren van de functie per Event Hub-partitie. De maximale verwerkingssnelheid wordt bepaald door hoe snel een functie-exemplaar de gebeurtenissen uit een enkele partitie kan verwerken. De functie moet berichten in batches verwerken.

Cosmos DB. Als u een Cosmos DB-verzameling wilt uitschalen, maakt u de verzameling met een partitiesleutel en neemt u deze partitiesleutel op in elk document dat u wegschrijft. Zie Partitionering en horizontaal schalen in Azure Cosmos DB voor meer informatie.

  • Als u één document per apparaat opslaat en bijwerkt, is de apparaat-id een goede partitiesleutel. Schrijfbewerkingen worden gelijkmatig verdeeld over de sleutels. De grootte van elke partitie wordt strikt begrensd, omdat er één document is voor elke sleutelwaarde.
  • Als u voor elk apparaatbericht een afzonderlijk document opslaat, zou de limiet van 10 GB per partitie snel worden overschreden bij gebruik van de apparaat-id als een partitiesleutel. De bericht-id is in dat geval een betere partitiesleutel. Het is wel gebruikelijk om toch de apparaat-id op te nemen in het document, maar dan voor indexerings- en querydoeleinden.

Azure Time Series Insights (TSI) is een service voor analyse, opslag en visualisatie voor tijdreeksgegevens, die mogelijkheden biedt, waaronder SQL-achtige filtering en aggregatie, waardoor de noodzaak van door de gebruiker gedefinieerde functies wordt voorkomen. Time Series Insights biedt een data explorer om gegevens te visualiseren en op te vragen, evenals REST Query-API's. Naast tijdreeksgegevens is TSI ook geschikt voor oplossingen die query's moeten uitvoeren op statistische gegevens voor grote gegevenssets. Met ondersteuning voor opslag met meerdere lagen, uitgebreide API's, modellen en integratie met het Azure IoT-ecosysteem, verkenner voor visualisaties en extensibility via Power BI, enzovoort. TSI is onze aanbeveling voor de opslag en analyse van tijdreeksgegevens.

Beveiligingsoverwegingen

Betrouwbare en veilige communicatie

Alle gegevens die worden ontvangen en verzonden naar een apparaat, moeten betrouwbaar zijn. Tenzij een apparaat de volgende cryptografische mogelijkheden kan ondersteunen, moet de reikwijdte van het apparaat worden beperkt tot lokale netwerken en moet alle communicatie tussen netwerken via een veldgateway verlopen:

  • Versleuteling van gegevens met een aantoonbaar veilig, openbaar geanalyseerd en breed geïmplementeerd versleutelingsalgoritme op basis van een symmetrische sleutel.
  • Digitale handtekening met een aantoonbaar veilig, openbaar geanalyseerd en breed geïmplementeerd ondertekeningsalgoritme op basis van een symmetrische sleutel.
  • Ondersteuning voor TLS 1.2 voor TCP of andere op stromen gebaseerde communicatiepaden of DTLS 1.2 voor op datagrammen gebaseerde communicatiepaden. Ondersteuning voor de verwerking van x.509-certificaten is optioneel en kan worden vervangen door de modus met vooraf gedeelde sleutels voor TLS. Deze modus kan worden geïmplementeerd met ondersteuning voor AES- en SHA-2-algoritmen en is niet alleen efficiënter op het gebied van rekenkracht, maar ook voor verzending van gegevens via een bekabelde verbinding.
  • Archief met sleutels die kunnen worden bijgewerkt en apparaatsleutels. Elk apparaat moet uniek sleutelmateriaal hebben of tokens die het apparaat identificeren bij het systeem. De apparaten moeten de sleutel veilig opslaan op het apparaat (bijvoorbeeld met behulp van een beveiligd sleutelarchief). Het apparaat moet de sleutels of tokens periodiek kunnen bijwerken of reactief in noodsituaties, zoals bij een schending van het systeem.
  • De firmware en toepassingssoftware op het apparaat moeten updates toestaan om het herstellen van vastgestelde beveiligingsproblemen mogelijk te maken.

Veel apparaten hebben echter te veel beperkingen voor de ondersteuning van deze vereisten. In dat geval moet een veldgateway worden gebruikt. Apparaten maken via een lokaal netwerk veilig verbinding met de veldgateway en de gateway zorgt voor beveiligde communicatie met de cloud.

Bescherming tegen fysieke manipulatie

Het wordt sterk aangeraden om een apparaat te gebruiken dat beschikt over ingebouwde functies voor bescherming tegen pogingen tot fysieke manipulatie, om de integriteit van de beveiliging en de betrouwbaarheid van het systeem als geheel te garanderen.

Bijvoorbeeld:

  • Kies microcontrollers/microprocessors of aanvullende hardware die veilige opslag en gebruik van cryptografische sleutelmateriaal biedt, zoals TPM-integratie (Trusted Platform Module).
  • Beveiligde boot-loader en veilig laden van software, verankerd in de TPM.
  • Gebruik sensoren voor het detecteren van pogingen tot binnendringing en manipulatie van de omgeving van apparaten, met waarschuwingen en mogelijk zelfs 'digitale zelfvernietiging' van het apparaat.

Zie Internet of Things-beveiligingsarchitectuur (IoT) voor aanvullende beveiligingsoverwegingen.

Bewaking en registratie

Systemen voor logboekregistratie en bewaking worden gebruikt om te bepalen of de oplossing werkt en om problemen op te lossen. Deze systemen helpen bij het beantwoorden van de volgende vragen:

  • Is er sprake van een foutstatus voor apparaten of systemen?
  • Zijn de apparaten of systemen correct geconfigureerd?
  • Genereren de apparaten of systemen nauwkeurige gegevens?
  • Voldoen de systemen aan de verwachtingen van zowel het bedrijf als eindklanten?

Hulpprogramma's voor logboekregistratie en bewaking bestaan meestal uit de volgende vier onderdelen:

  • Hulpprogramma's voor systeemprestaties en tijdlijnvisualisatie voor bewaking van het systeem en voor eenvoudige probleemoplossing.
  • Opname van gegevens via buffers, om logboekgegevens op te slaan in een buffer.
  • Persistentiearchief voor het opslaan van logboekgegevens.
  • Zoek- en querymogelijkheden om logboekgegevens weer te geven voor gebruik bij gedetailleerde probleemoplossing.

Bewakingssystemen bieden inzicht in de status, beveiliging en stabiliteit en prestaties van een IoT-oplossing. Deze systemen kunnen ook een meer gedetailleerde weergave geven, wijzigingen in de configuratie van clientcomponenten vastleggen en geëxtraheerde logboekgegevens aanbieden die potentiële beveiligingsproblemen kunnen aantonen, het incidentbeheerproces kunnen verbeteren en de eigenaar van het systeem kunnen helpen bij het oplossen van problemen. Uitgebreide bewakingsoplossingen bieden de mogelijkheid om gegevens op te vragen voor specifieke subsystemen of gegevens van meerdere subsystemen samen te voegen.

De ontwikkeling van bewakingssystemen moet beginnen met het beschrijven van de juiste werking, naleving van regelgeving en controlevereisten. Voorbeelden van metrische gegevens die worden verzameld:

  • Fysieke apparaten, edge-apparaten en onderdelen van de infrastructuur die configuratiewijzigingen melden.
  • Toepassingen die wijzigingen in de configuratie melden, auditlogboeken voor de beveiliging, aanvraagsnelheid, reactietijden, foutfrequenties en statistieken van garbagecollection voor beheerde talen.
  • Databases, persistentiearchieven en caches die meldingen geven van query- en schrijfprestaties, schemawijzigingen, controlelogboek voor de beveiliging, vergrendelingen of impasses, indexprestaties, CPU, geheugen en schijfgebruik.
  • Beheerde services (IaaS, PaaS, SaaS en FaaS) melden metrische statusgegevens en configuratiewijzigingen die invloed hebben op de status en prestaties van afhankelijke systemen.

Visualisatie van metrische bewakingsgegevens maakt operators attent op instabiliteit van het systeem en geeft hen de mogelijkheid te reageren op incidenten.

Tracering van telemetrie

Tracering van telemetrie biedt een operator de gelegenheid om het traject van bepaalde telemetriegegevens te volgen vanaf het punt dat de gegevens zijn gemaakt in het systeem. Tracering is belangrijk voor foutopsporing en probleemoplossing. Voor IoT-oplossingen die gebruikmaken van Azure IoT Hub en de apparaat-SDK's van IoT Hub kunnen traceringsdatagrammen worden gemaakt op basis van cloud-naar-apparaat-berichten en kunnen deze worden opgenomen in de telemetriestroom.

Logboekregistratie

Systemen voor logboekregistratie zijn onmisbaar om te begrijpen welke acties of activiteiten een oplossing heeft uitgevoerd en welke fouten er zijn opgetreden. Deze informatie is essentieel voor het oplossen van fouten. Logboeken kunnen worden geanalyseerd om foutsituaties te begrijpen en te verhelpen, prestatiekenmerken te verbeteren, en naleving van regels en regelgeving af te dwingen.

Hoewel logboekregistratie van platte tekst gunstig is voor de ontwikkelingskosten, is het wel lastiger om deze tekst te parseren/lezen met een computer. Wij adviseren daarom gestructureerde logboekregistratie, aangezien de op deze manier verzamelde gegevens kunnen worden gelezen door zowel computers als mensen. Gestructureerde logboekregistratie houdt in dat er situationele context en metagegevens worden toegevoegd aan de logboekgegevens. Bij gestructureerde logboekregistratie zijn eigenschappen 'first class citizens' die zijn opgemaakt als sleutel-waardeparen, of met een vast schema, teneinde de zoek en querymogelijkheden te verbeteren.

DevOps overwegingen

Gebruik infrastructuur als code (IaC). IaC is het beheer van infrastructuur (netwerken, virtuele machines, load balancers en verbindingstopologie) met een declaratieve benadering. Sjablonen moeten versie-versies hebben en deel uitmaken van de release-pijplijn. De meest betrouwbare implementatieprocessen zijn geautomatiseerd en idempotent. Eén manier is om een sjabloon Azure Resource Manager maken voor het inrichten van de IoT-resources en de infrastructuur.

Als u de implementatie van infrastructuur wilt automatiseren, kunt u Azure DevOps Services, Jenkins of andere CI/CD-oplossingen gebruiken. Azure Pipelines maakt deel uit van Azure DevOps Services en voert automatische builds, tests en implementaties uit.

Overweeg fasering van uw workloads door in verschillende fasen te implementeren en validaties in elke fase uit te stellen voordat u verder gaat met de volgende; Op die manier kunt u updates naar uw productieomgevingen pushen op een zeer gecontroleerde manier en onverwachte implementatieproblemen minimaliseren. Blue-green implementatie en Canary-releases zijn aanbevolen implementatiestrategieën voor het bijwerken van live productieomgevingen. Overweeg ook om een goede strategie voor terugdraaien te gebruiken wanneer een implementatie mislukt; U kunt bijvoorbeeld automatisch een eerdere, geslaagde implementatie uit uw implementatiegeschiedenis opnieuw implementeren. De vlagparameter --rollback-on-error in Azure CLI is een goed voorbeeld.

Overweeg uw oplossing te bewaken met behulp van Azure Monitor. Azure Monitor de belangrijkste bron van bewaking en logboekregistratie is voor al uw Azure-services, biedt het diagnostische informatie voor Azure-resources. U kunt bijvoorbeeld de bewerkingen bewaken die plaatsvinden in uw IoT-hub. Er zijn specifieke metrische gegevens en gebeurtenissen Azure Monitor worden ondersteund, evenals services, schema's en categorieën voor Diagnostische logboeken van Azure.

Zie de sectie DevOps in Microsoft Azure Well-Architected Framework voor meer informatie.

Kostenoverwegingen

Over het algemeen gebruikt u de Azure-prijscalculator om de kosten te schatten. Andere overwegingen worden beschreven in de sectie Kosten in Microsoft Azure Well-Architected Framework.

Er zijn manieren om de kosten te optimaliseren die zijn gekoppeld aan de services die in deze referentiearchitectuur worden gebruikt.

Azure IoT Hub

In deze architectuur is IoT Hub de cloudgateway die gebeurtenissen van apparaten opspoort. IoT Hub facturering varieert afhankelijk van het type bewerking. Maken, bijwerken, invoegen, verwijderen is gratis. Geslaagde bewerkingen, zoals apparaat-naar-cloud- en cloud-naar-apparaat-berichten, worden in rekening gebracht.

Verzonden apparaat-naar-cloud-berichten worden in segmenten van 4 kB in rekening gebracht bij ingress in IoT Hub. Een bericht van 6 kB wordt bijvoorbeeld in rekening gebracht als twee berichten.

IoT Hub houdt statusinformatie bij over elk verbonden apparaat in een JSON-document voor apparaattweeling. Er worden kosten in rekening gebracht voor leesbewerkingen van een document van een apparaat dubbel.

IoT Hub biedt twee lagen: Basic en Standard.

Overweeg het gebruik van de standard-laag als uw IoT-architectuur gebruikmaakt van bi-directionele communicatiemogelijkheden. Deze laag biedt ook een gratis editie die het meest geschikt is voor testdoeleinden.

Als u alleen unirichtingscommunicatie van apparaten naar de cloud nodig hebt, gebruikt u de basic-laag, wat goedkoper is.

Zie Prijzen voor IoT Hub voor meer informatie.

Azure Stream Analytics

Azure Stream Analytics wordt gebruikt voor de verwerking van stromen en voor de evaluatie van regels. Azure Stream Analytics prijs wordt berekend op basis van het aantal streaming-eenheden (SU) per uur, waarbij rekenkracht, geheugen en doorvoer nodig zijn om de gegevens te verwerken. Azure Stream Analytics op IoT Edge per taak wordt gefactureerd. Facturering begint wanneer een Stream Analytics taak wordt geïmplementeerd op apparaten, ongeacht de taakstatus, de taakstatus, de taak is uitgevoerd, mislukt of is gestopt.

Zie prijzen voor Stream Analytics informatie over prijzen.

Azure Functions

Azure Functions wordt gebruikt om gegevens te transformeren nadat deze de IoT Hub. Vanuit het oogpunt van kosten is de aanbeveling om gebruik te maken van een verbruiksplan, omdat u alleen betaalt voor de rekenbronnen die u gebruikt. Er worden kosten in rekening gebracht op basis van het resourceverbruik per seconde telkens wanneer een gebeurtenis de uitvoering van de functie activeert. Het verwerken van verschillende gebeurtenissen in één uitvoering of batches kan de kosten verlagen.

Azure Logic Apps

In deze architectuur wordt Logic Apps gebruikt voor integratie van bedrijfsprocessen.

De prijzen van Logic Apps werken op basis van het model voor betalen per gebruik. Triggers, acties en connectoruitvoeringen worden gemeten telkens als een logische app wordt uitgevoerd. Alle geslaagde en mislukte acties, inclusief triggers, worden beschouwd als uitvoeringen.

Uw logische app verwerkt bijvoorbeeld 1000 berichten per dag. Een werkstroom van vijf acties kost minder dan $ 6.

Zie prijzen voor Logic Apps meer informatie.

Gegevensopslag

Voor opslag met een niet Azure Blob Storage pad is dit de meest rendabele optie.

Voor opslag met warm pad kunt u overwegen om Azure Cosmos DB. Zie prijzen voor Cosmos DB meer informatie.

Volgende stappen