Azure IoT-referensarkitektur

Blob Storage
Functions
IoT Hub
Logic Apps
Stream Analytics

Den här referensarkitekturen visar en rekommenderad arkitektur för IoT-program på Azure med PaaS-komponenter (plattform som en tjänst).

Diagram över arkitekturen

IoT-program kan beskrivas som saker (enheter) som skickar data som genererar insikter. De här insikterna genererar åtgärder för att förbättra ett företag eller en process. Ett exempel är en motor (saken) som skickar temperaturdata. Dessa data används för att utvärdera om motorn fungerar som förväntat (insikten). Insikten används för att proaktivt prioritera underhållsschemat för motorn (åtgärden).

Den här referensarkitekturen använder Azure PaaS-komponenter (plattform som en tjänst). Ett annat rekommenderat alternativ för att skapa IoT-lösningar i Azure är:

  • Azure IoT Central. IoT Central är en fullständigt hanterad SaaS-lösning (programvara som en tjänst). Den abstraherar de tekniska valen så att du kan fokusera enbart på lösningen. Den här enkelheten medför en kompromiss eftersom den är mindre anpassningsbar än en PaaS-baserad lösning.

På en hög nivå finns det två sätt att bearbeta telemetridata, het sökväg (hot path) och kall sökväg (cold path). Skillnaden har att göra med krav på svarstid och dataåtkomst.

  • Den heta sökvägen analyserar data nästan i realtid, när de anländer. I den heta sökvägen måste telemetri bearbetas med mycket kort svarstid. Den heta sökvägen implementeras vanligtvis med en strömbearbetningsmotor. Utdata kan utlösa en avisering eller skrivas till ett strukturerat format som kan efterfrågas med analysverktyg.
  • Den kalla sökvägen utför batchbearbetning med längre intervall (varje timme eller varje dag). Den kalla sökvägen hanterar vanligtvis stora mängder data, men resultatet behöver inte vara lika snabbt som den heta sökvägen. I den kalla sökvägen inhämtas råtelemetri och skickas sedan till en batchprocess.

Arkitektur

Den här arkitekturen består av följande komponenter. Vissa program kanske inte kräver alla komponenter som anges här.

IoT-enheter. Enheter kan på ett säkert sätt registrera med molnet, och kan ansluta till molnet för att skicka och ta emot data. Vissa enheter kan vara gränsenheter som utför viss databehandling på själva enheten eller i en fältgateway. Vi rekommenderar Azure IoT Edge för gränsbearbetning.

Molngateway. En molngateway tillhandahåller en molnhubb så att enheter kan ansluta säkert till molnet och skicka data. Den tillhandahåller också funktioner för enhetshantering, bland annat kontroll av enheter. För molngatewayen rekommenderar vi IoT Hub. IoT Hub är en värdbaserad molntjänst som matar in händelser från enheter och fungerar som en asynkron meddelandekö mellan enheter och serverdelstjänster. IoT Hub tillhandahåller säkra anslutningar, händelseinmatning, dubbelriktad kommunikation och enhetshantering.

Enhetsetablering. För registrering och anslutning av stora uppsättningar enheter rekommenderar vi att du använder IoT Hub Device Provisioning Service (DPS). Med DPS kan du tilldela och registrera enheter till specifika Azure IoT Hub-slutpunkter i stor skala.

Bearbetning av dataströmmen. Strömbearbetning analyserar stora strömmar med dataposter och utvärderar regler för de strömmarna. För strömbearbetning rekommenderar vi Azure Stream Analytics. Stream Analytics kan köra komplexa analyser i stor skala, med hjälp av tidsfönsterfunktioner, strömsammansättningar och externa datakällkopplingar. Ett annat alternativ är Apache Spark på Azure Databricks.

Maskininlärning gör det möjligt att köra förutsägande algoritmer för historiska telemetridata, vilket möjliggör scenarier som exempelvis förutsägande underhåll. För maskininlärning rekommenderar vi Azure Machine Learning.

Varm sökvägslagring innehåller data som måste vara tillgängliga direkt från enheten för rapportering och visualisering. För varm sökvägslagring rekommenderar vi Cosmos DB. Cosmos DB är en globalt distribuerad databas för flera modeller.

Kall sökvägslagring innehåller data som sparas på längre sikt och används för batchbearbetning. För kall sökvägslagring rekommenderar vi Azure Blob Storage. Data kan arkiveras i Blob Storage på obestämd tid till låg kostnad och är lättillgängliga för batchbearbetning.

Datatransformering ändrar eller aggregerar telemetriströmmen. Exempel innefattar protokolltransformering, till exempel konvertering av binärdata till JSON eller kombinering av datapunkter. Om data måste transformeras innan de når IoT Hub rekommenderar vi att du använder en protokollgateway (visas inte). Annars kan data transformeras efter att de når IoT Hub. I så fall bör du använda Azure Functions, som har inbyggd integrering med IoT Hub, Cosmos DB och Blob Storage.

Affärsprocessintegration utför åtgärder baserat på insikter från enhetsdata. Det kan omfatta att lagra informationsmeddelanden, utlösa larm, skicka e-post- eller SMS-meddelanden eller integrera med CRM. Vi rekommenderar att du använder Azure Logic Apps för affärsprocessintegration.

Användarhantering begränsar vilka användare eller grupper som kan utföra åtgärder med enheter, till exempel uppgradera inbyggd programvara. Den definierar också funktioner för användare i program. Vi rekommenderar att du använder Azure Active Directory för att autentisera och auktorisera användare.

Säkerhetsövervaknings-Azure Security Center för IoT är en säkerhetslösning från hela vägen för IoT-arbetsbelastningar och förenklar skyddet genom att leverera enhetlig synlighet och kontroll, anpassningsbart hotskydd och intelligent hotidentifiering och svar mellan arbetsbelastningar från lövenheter via Edge och upp via molnen.

Skalbarhetsöverväganden

Ett IoT-program bör skapas som diskreta tjänster som kan skalas oberoende av varandra. Tänk på följande skalbarhetspunkter:

IoTHub. För IoT Hub bör du tänka på följande skalningsfaktorer:

  • Maximal dagskvot för meddelanden till IoT Hub.
  • Kvot för anslutna enheter i en IoT Hub-instans.
  • Inmatningsdataflöde — hur snabbt IoT Hub kan mata in meddelanden.
  • Bearbetningsdataflöde — hur snabbt inkommande meddelanden bearbetas.

Varje IoT-hubb etableras med ett visst antal enheter på en specifik nivå. Nivå och antal enheter avgör den maximala dagskvoten för meddelanden som enheter kan skicka till hubben. Mer information finns i Kvoter och begränsningar för IoT Hub. Du kan skala upp en hubb utan att avbryta befintliga åtgärder.

Stream Analytics. Stream Analytics-jobb skalas bäst om de är parallella vid alla punkter i Stream Analytics-pipelinen, från indata till fråga till utdata. Ett fullständigt parallellt jobb gör det möjligt för Stream Analytics att dela upp arbetet på flera beräkningsnoder. Annars måste Stream Analytics kombinera strömdata på ett och samma ställe. Mer information finns i Utnyttja frågeparallellisering i Azure Stream Analytics.

IoT Hub partitionerar automatiskt enhetsmeddelanden baserat på enhets-ID. Alla meddelanden från en viss enhet anländer alltid på samma partition, men en enskild partition har meddelanden från flera enheter. Därför är enheten för parallellisering partitions-ID.

Functions. Vid läsning från Event Hubs-slutpunkten finns det ett maximum för funktionsinstans per händelsehubbpartition. Maximal bearbetningsfrekvens avgörs av hur snabbt en funktionsinstans kan bearbeta händelserna från en enskild partition. Funktionen bör bearbeta meddelanden i batchar.

Cosmos DB. Om du vill skala ut en Cosmos DB-samling skapar du samlingen med en partitionsnyckel och anger partitionsnyckeln i varje dokument du skriver. Mer information finns i Metodtips när du väljer en partitionsnyckel.

  • Om du lagrar och uppdaterar ett enskilt dokument per enhet är enhets-ID en bra partitionsnyckel. Skrivningar fördelas jämnt mellan nycklarna. Storleken på varje partition är strikt begränsad, eftersom det finns ett enskilt dokument för varje nyckelvärde.
  • Om du lagrar ett separat dokument för varje enhetsmeddelande skulle gränsen på 10 GB per partition snabbt överskridas med enhets-ID som partitionsnyckel. Meddelande-ID är en bättre partitionsnyckel i så fall. Vanligtvis skulle du fortfarande ange enhets-ID i dokumentet för indexering och frågor.

Azure Time Series Insights (TSI) är en analys-, lagrings- och visualiseringstjänst för tidsseriedata som tillhandahåller funktioner som SQL-liknande filtrering och aggregering, vilket gör att du kan minska behovet av användardefinierade funktioner. Time Series Insights en datautforskare för att visualisera och fråga efter data samt REST-fråge-API:er. Förutom tidsseriedata passar TSI också bra för lösningar som behöver fråga aggregeringar över stora datamängder. Med stöd för lagring i flera lager, omfattande API:er, modeller och integrering med Azure IoT-ekosystemet, utforskaren för visualiseringar och utökningsbarhet via Power BI osv. TSI är vår rekommendation för lagring och analys av tidsseriedata.

Säkerhetsöverväganden

Tillförlitlig och säker kommunikation

All information som tas emot från och skickas till en enhet måste vara tillförlitlig. Om en enhet inte kan hantera följande kryptografifunktioner bör den begränsas till lokala nätverk och all internätverkskommunikation bör gå via en fältgateway:

  • Datakryptering med en bevisbart säker, offentligt analyserad och brett implementerad krypteringsalgoritm med symmetrisk nyckel.
  • Digital signatur med en bevisbart säker, offentligt analyserad och brett implementerad signaturalgoritm med symmetrisk nyckel.
  • Stöd för antingen TLS 1.2 för TCP eller andra strömbaserade kommunikationsvägar eller DTLS 1.2 för datagrambaserade kommunikationsvägar. Stöd för hantering av X.509-certifikat är valfritt och kan ersättas med det beräknings- och överföringseffektivare läget med i förväg delade nycklar för TLS, som kan implementeras med stöd för AES- och SHA-2-algoritmerna.
  • Uppdateringsbart nyckellager och nycklar per enhet. Varje enhet måste ha unikt nyckelmaterial eller token som identifierar den mot systemet. Enheterna bör lagra nyckeln på ett säkert sätt på enheten (till exempel med hjälp av ett säkert nyckellager). Enheten bör kunna uppdatera nycklar eller token med jämna mellanrum eller reaktivt i nödsituationer, till exempel ett systemintrång.
  • Inbyggd programvara och program på enheten måste tillåta uppdateringar för att möjliggöra reparation av identifierade säkerhetsrisker.

Men många enheter är för begränsade för att kunna hantera de här kraven. I så fall bör en fältgateway användas. Enheter ansluter på ett säkert sätt till fältgatewayen via ett lokalt nätverk och gatewayen möjliggör säker kommunikation till molnet.

Fysiskt manipuleringsskydd

Vi rekommenderar starkt att enhetens design har funktioner som skyddar mot försök till fysisk manipulering, för att säkerställa säkerhet, integritet och tillförlitlighet för hela systemet.

Exempel:

  • Välj mikrostyrenheter/mikroprocessorer eller extra maskinvara som ger säker lagring och användning av kryptografiskt nyckelmaterial, till exempel TPM-integrering (Trusted Platform Module).
  • Säkert startprogram och säker programinläsning, förankrade i TPM.
  • Använd sensorer för att identifiera intrångsförsök och försök att manipulera enhetsmiljön med aviseringar och potentiell ”digital självförstörelse” av enheten.

Ytterligare säkerhetsöverväganden finns i Säkerhetsarkitektur för Sakernas Internet (IoT).

Övervakning och loggning

Loggnings- och övervakningssystem används för att fastställa om lösningen fungerar och för att felsöka problem. Övervaknings- och loggningssystem hjälper dig att besvara följande frågor om drift:

  • Är enheter eller system i ett feltillstånd?
  • Är enheter eller system korrekt konfigurerade?
  • Genererar enheter eller system korrekta data?
  • Uppfyller system både företagets och slutkundernas förväntningar?

Loggnings- och övervakningsverktyg består vanligtvis av följande fyra komponenter:

  • Visualiseringsverktyg för systemets prestanda och tidslinje för att övervaka systemet och för grundläggande felsökning.
  • Buffrad datainmatning, för att buffra loggdata.
  • Persistencelager för att lagra loggdata.
  • Sök- och frågefunktioner, för att visa loggdata för användning i detaljerad felsökning.

Övervakningssystem ger insikter i en IoT-lösnings hälsa, säkerhet, stabilitet och prestanda. De här systemen kan också ge en mer detaljerad vy, där de registrerar ändringar av komponentkonfiguration och tillhandahåller extraherade loggningsdata som kan lyfta fram potentiella säkerhetsproblem, förbättra incidenthanteringsprocessen och hjälpa systemets ägare att felsöka problem. Omfattande övervakningslösningar innehåller möjligheten att efterfråga information för specifika undersystem eller aggregering över flera undersystem.

Utveckling av övervakningssystem bör börja med att definiera felfri drift, regelefterlevnad och granskningskrav. Mått som samlas in kan vara:

  • Fysiska enheter, gränsenheter och infrastrukturkomponenter som rapporterar konfigurationsändringar.
  • Program som rapporterar konfigurationsändringar, säkerhetsgranskningsloggar, begärandefrekvenser, svarstider, felfrekvenser och skräpinsamlingsstatistik för hanterade språk.
  • Databaser, persistencelager och cacheminnen som rapporterar fråge- och skrivprestanda, schemaändringar, säkerhetsgranskningslogg, låsningar eller deadlocks, indexprestanda, CPU, minne och diskanvändning.
  • Hanterade tjänster (IaaS, PaaS, SaaS och FaaS) som rapporterar hälsomått och konfigurationsändringar som påverkar beroende systems hälsa och prestanda.

Visualisering av övervakningsmått uppmärksammar operatörer på systemproblem och underlättar incidenthantering.

Spårningstelemetri

Spårningstelemetri gör att en operatör kan följa förloppet för telemetri från att den skapades och genom systemet. Spårning är viktigt för felsökning. För IoT-lösningar som använder Azure IoT Hub och SDK:erna för IoT Hub-enheter kan spårningsdatagram ha sitt ursprung som meddelanden från moln till enhet och ingå i telemetriströmmen.

Loggning

Loggningssystem är avgörande för att förstå vilka åtgärder eller aktiviteter en lösning har utfört, fel som har inträffat och kan ge hjälp med att åtgärda de felen. Loggar kan analyseras för att förstå och åtgärda fel, förbättra prestanda och säkerställa att regler och förordningar följs.

Oformaterad loggning har mindre påverkan på utvecklingskostnader i förskott, men det är svårare för en dator att parsa/läsa. Vi rekommenderar att strukturerad loggning används, eftersom insamlad information både kan parsas av datorer och läsas av människor. Strukturerad loggning lägger till situationssammanhang och -metadata i logginformationen. I strukturerad loggning är egenskaper ”first class citizens” formaterade som nyckel/värde-par eller med ett fast schema, för att förbättra sök- och frågefunktioner.

DevOps-överväganden

Använd infrastruktur som kod (IaC). IaC är hantering av infrastruktur (nätverk, virtuella datorer, lastbalanserare och anslutningstopologi) med en deklarativ metod. Mallar ska vara versionshantering och en del av versionspipelinen. De mest tillförlitliga distributionsprocesserna är automatiserade och idempotenta. Ett sätt är att Azure Resource Manager mall för etablering av IoT-resurser och infrastrukturen.

Om du vill automatisera distributionen av infrastruktur kan du använda Azure DevOps Services, Jenkins eller andra CI/CD-lösningar. Azure-pipelines ingår i Azure DevOps Services och kör automatiserade versioner, tester och distributioner.

Överväg att mellanlagra dina arbetsbelastningar genom att distribuera till olika faser och köra valideringar i varje steg innan du går vidare till nästa steg. på så sätt kan du skicka uppdateringar till produktionsmiljöerna på ett mycket kontrollerat sätt och minimera oväntade distributionsproblem. Blå-grön distribution och Canary-versioner rekommenderas distributionsstrategier för att uppdatera live-produktionsmiljöer. Överväg också att ha en bra återställningsstrategi för när en distribution misslyckas. Du kan till exempel automatiskt distribuera om en tidigare, lyckad distribution från distributionshistoriken. Flaggparametern --rollback-on-error i Azure CLI är ett bra exempel.

Överväg att övervaka din lösning med hjälp av Azure Monitor. Azure Monitor är den huvudsakliga källan för övervakning och loggning för alla dina Azure-tjänster tillhandahåller den diagnostikinformation för Azure-resurser. Du kan till exempel övervaka de åtgärder som utförs i din IoT-hubb. Det finns specifika mått och händelser som Azure Monitor stöder, samt tjänster, scheman och kategorier för Azure-diagnostikloggar.

Mer information finns i DevOps-avsnittet i Microsoft Azure Well-Architected Framework.

Kostnadsöverväganden

I allmänhet använder du priskalkylatorn för Azure för att beräkna kostnader. Andra överväganden beskrivs i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Det finns sätt att optimera kostnaderna för de tjänster som används i den här referensarkitekturen.

Azure IoT Hub

I den här IoT Hub är molngatewayen som matar in händelser från enheter. IoT Hub faktureringen varierar beroende på typen av åtgärd. Skapa, uppdatera, infoga och ta bort är kostnadsfria. Lyckade åtgärder som enhet-till-moln- och moln-till-enhet-meddelanden debiteras.

Meddelanden från enheten till molnet som skickats debiteras i 4 KB-segment vid ingress till IoT Hub. Till exempel debiteras ett meddelande på 6 KB som två meddelanden.

IoT Hub underhåller tillståndsinformation om varje ansluten enhet i ett JSON-dokument för enhetstvilling. Läsåtgärder från ett enhetstvillingdokument debiteras.

IoT Hub erbjuder två nivåer: Basic och Standard.

Överväg att använda standardnivån om din IoT-arkitektur använder dubbelriktade kommunikationsfunktioner. Den här nivån erbjuder också en kostnadsfri version som passar bäst för testning.

Om du bara behöver enkelriktad kommunikation från enheter till molnet använder du Basic-nivån, som är billigare.

Mer information finns i IoT Hub priser.

Azure Stream Analytics

Azure Stream Analytics används för bearbetning av dataströmmar och utvärdering av regler. Azure Stream Analytics prissätts efter antalet strömningsenheter (SU) per timme, vilket tar hänsyn till beräkning, minne och dataflöde som krävs för att bearbeta data. Azure Stream Analytics på IoT Edge debiteras per jobb. Faktureringen startar när ett Stream Analytics-jobb distribueras till enheter oavsett jobbstatus, körs, misslyckades eller stoppas.

Mer information om priser finns i Stream Analytics priser.

Azure Functions

Azure Functions används för att transformera data när de når IoT Hub. Ur ett kostnadsperspektiv rekommenderar vi att du använder förbrukningsplanen eftersom du bara betalar för de beräkningsresurser som du använder. Du debiteras baserat på resursförbrukningen per sekund varje gång en händelse utlöser körningen av funktionen. Bearbetning av flera händelser i en enda körning eller batchar kan minska kostnaderna.

Azure Logic Apps

I den här Logic Apps används för affärsprocessintegrering.

Prissättningen för logic apps fungerar med modellen där du betalar per användning. Utlösare, åtgärder och anslutningskörningar mäts varje gång en logikapp körs. Alla lyckade och misslyckade åtgärder, inklusive utlösare, betraktas som körningar.

Logikappen bearbetar till exempel 1 000 meddelanden per dag. Ett arbetsflöde med fem åtgärder kostar mindre än 6 USD.

Mer information finns i Logic Apps priser.

Datalagring

För kall sökvägslagring är Azure Blob Storage det mest kostnadseffektiva alternativet.

Överväg att använda Azure Cosmos DB för varm sökvägslagring. Mer information finns i Cosmos DB priser.

Nästa steg