Prípadová štúdia
Multi-tenantná IoT platforma pre správu zariadení
Kompletná IoT platforma postavená na zelenej lúke, pokrývajúca konektivitu cez mobilné a LPWAN siete, správu zariadení, ingestiu, vizualizáciu, downlink riadenie a riadenie prístupov, pre desiatky tisíc zariadení naprieč viacerými tenantmi na OpenShifte.
- MQTT
- Protobuf
- LoRaWAN
- NB-IoT / LTE-M
- OPA
- Kafka
- Redis
- RabbitMQ
- Prometheus
- Zabbix
- OpenShift
Kontext
Greenfield program s cieľom postaviť jednu platformu pokrývajúcu všetko medzi zariadením v teréne a grafom pred operátorom: konektivitu, provisioning, ingestiu, ukladanie, vizualizáciu a k tomu model identity a oprávnení okolo toho všetkého, pre množstvo zákazníckych organizácií zdieľajúcich jedno nasadenie.
Výzva
Každá etapa tejto cesty je samostatný systém a každá zužuje priestor tej ďalšej. Správa zariadení určuje, čomu smie ingestia veriť. Multi-tenancia určuje, čím musí byť ohraničený každý dopyt, každý alert aj každá notifikácia. Downlink znamená, že platforma zapisuje späť do fyzických zariadení, takže identita a oprávnenia musia platiť v momente zápisu, nie až na hranici používateľského rozhrania. Stavať jednotlivé časti oddelene a integrovať ich neskôr by tieto hranice umiestnilo na nesprávne miesta.
Obmedzenia
- desiatky tisíc zariadení hlásiacich nepretržite, pri stovkách správ za sekundu
- zariadenia pripájajúce sa cez 2G, 4G, NB-IoT, LTE-M a LoRaWAN, pričom každý nosič má vlastný rozpočet na payload a vlastnú spoľahlivosť
- park zariadení rozdelený medzi protokoly: MQTT tam, kde ho linka uniesla, vlastné UDP tam, kde nie
- izolácia tenantov vynútená na každej ceste čítania, zápisu aj notifikácie
- downlink príkazy, ktoré menia stav fyzických zariadení
- autentifikácia a autorizácia, ktoré sa museli správať rovnako v každej službe
- stav platformy aj zariadení, ktorý operátori potrebovali vidieť v nástrojoch, ktoré už prevádzkovali
Prístup
- Platformu som postavil ako ohraničené služby pre správu zariadení, ingestiu, vizualizáciu a identitu, s tenantom ako explicitným rozmerom v každom modeli, nie ako filtrom doplneným dodatočne.
- Konektivitu som riešil naprieč 2G, 4G, NB-IoT, LTE-M a LoRaWAN: MQTT tam, kde linka uniesla jeho réžiu, a vlastné UDP protokoly s Protobuf payloadmi na úzkopásmových nosičoch, kde sa platil každý bajt.
- Kafku som použil ako chrbticu eventov medzi službami a RabbitMQ na zaradenú prácu a notifikácie, namiesto tlačenia oboch úloh do jedného brokera.
- Oddelil som autentifikáciu od autorizácie: identita sa ustanovila raz pri vstupe požiadavky do platformy a Open Policy Agent potom rozhodoval, čo tá identita smie, takže si služby pýtali rozhodnutie namiesto toho, aby každá niesla kópiu pravidiel.
- Pred horúce čítacie cesty, stav zariadení a vyhľadávacie dáta, som postavil Redis, aby sa vysokofrekvenčné čítanie nikdy nedostalo k primárnym úložiskám.
- Služby som inštrumentoval pre Prometheus a stav zariadení aj infraštruktúry som posielal do Zabbixu, aby sa park zariadení a platforma pod ním dali sledovať spolu.
- Každý downlink príkaz som sledoval až po potvrdenie zo zariadenia, pretože správa, ktorá hýbe fyzickým zariadením, sa nedá odoslať a zabudnúť.
Architektúra
Zariadenia sa na platformu pripájajú cez 2G, 4G, NB-IoT, LTE-M a LoRaWAN, pričom hovoria MQTT tam, kde to linka dovolí, a vlastnými UDP protokolmi s Protobuf payloadmi tam, kde nie. Služby bežia na OpenShifte, Kafka medzi nimi nesie eventy a RabbitMQ obsluhuje zaradenú prácu a notifikácie. Redis stojí pred vysokopriepustnými čítacími cestami a Open Policy Agent odpovedá na autorizáciu každej požiadavky ohraničenej tenantom, keď je identita ustanovená. Prometheus a Zabbix pokrývajú monitoring platformy aj parku zariadení a správa zariadení, downlink riadenie aj vizualizácia sú sprístupnené cez API zdieľajúce jeden model tenancie.
Kľúčové rozhodnutia
- tenancia zabudovaná do domény od prvej služby, nikdy nedoplnená spätne
- autentifikácia a autorizácia držané ako oddelené veci, s politikami vyňatými do OPA
- MQTT, Kafka a RabbitMQ, každý na úlohe, ktorej vyhovovali jeho záruky doručenia
- Protobuf cez vlastné UDP na úzkopásmových nosičoch, kde nebola réžia MQTT únosná
- každý downlink príkaz potvrdený skôr, než sa považoval za vybavený
Detaily sú anonymizované. Ďalší kontext je dostupný pod NDA.
Súvisiaca expertíza
Zaujíma vás, čo by AI dokázala vo vašej firme?
Prineste otázky – aj tie, ktoré vám pripadajú príliš základné. Za 30 minút si prejdeme, ako dnes pracujete, vyberieme úlohu s najväčším prínosom a načrtneme, čo by jej otestovanie obnášalo. Žiadne presviedčanie, žiadny záväzok.
Radšej email? hello@nxtinno.com