Prvý problém: príjem správ je spojený s ich spracovaním
Pri prvých zariadeniach funguje všetko. Pripájajú sa, posielajú dáta a dashboard sa priebežne aktualizuje. MVP vyzerá úspešne.
Potom zariadení pribudne. A architektúra, ktorá zvládala 200 zariadení bez jediného incidentu, začne spôsobovať problémy, ktoré sa v testovacom prostredí neobjavujú, nehlásia jasné chyby a nemajú zjavné riešenia. Latencia postupne rastie. Stavové údaje prestávajú byť aktuálne. Upozornenia prichádzajú neskoro alebo vôbec. Administrácia ukazuje zariadenia ako online, hoci sa celé hodiny neozvali.
Toto nie sú chyby v kóde. Sú to predvídateľné dôsledky architektúry navrhnutej na overenie konceptu, nie na záťaž. Najhoršie je, že keď si ich všimnete, produkčná prevádzka už beží na systéme, ktorý potrebuje zásadné zmeny.
Pozrime sa, čo zvyčajne prestáva fungovať, v akom poradí a čo s tým môžete urobiť skôr, než vás to vyjde draho.
Prvý problém: príjem správ je spojený s ich spracovaním
Väčšina MVP platforiem používa jedno API na všetko. Zariadenie pošle správu cez HTTPS. API ju overí, skontroluje dáta, zapíše ich do databázy, aktualizuje stav zariadenia a vráti odpoveď. Jeden endpoint, jeden tok.
Na začiatku je to správna voľba. Rýchlo sa vyvíja, ľahko ladí a lacno prevádzkuje. Znamená to však, že príjem a spracovanie zaisťuje tá istá služba. Pri malom počte zariadení to neprekážalo. S rastom ale každá špička v prevádzke priamo zvyšuje latenciu API aj záťaž databázy.
Sledovače majetku, ktoré posielajú dáta každých 60 sekúnd, nezaťažujú systém rovnomerne. Zariadenia s časovanými intervalmi sa zvyknú ozývať naraz. Jednu minútu API spracuje 50 požiadaviek, ďalšiu 800. Medzi prijatím správy a jej spracovaním nie je žiadny buffer. Databáza dostáva každý nápor v reálnom čase.
Ako sa to prejaví v prevádzke: Latencia príjmu na P95 pomaly rastie. Niektoré správy začnú zlyhávať. Zariadenia opakujú odosielanie, čím zvyšujú záťaž. Dashboard občas zobrazuje neaktuálne údaje. Prevádzkový tím nevie rozlíšiť, či je zariadenie naozaj offline, alebo platforma ešte nespracovala jeho poslednú správu.
Čo pomôže: Oddelenie príjmu od spracovania. Front medzi nimi znamená, že prijímacia vrstva má jedinú úlohu: prijať správu a zaradiť ju do frontu. Spracovanie beží asynchrónne tempom, ktoré workery zvládnu. Nárazová prevádzka naplní front namiesto toho, aby zaťažila databázu. Je to najúčinnejšia architektonická zmena pri škálovaní IoT platformy.
Druhý problém: riešenie zlyhaní závisí od zariadenia
V synchrónnej architektúre musí pri zlyhaní spracovania v API zariadenie odoslanie zopakovať. Znie to rozumne, kým sa nezamyslíte, čo opakovanie znamená pre zariadenie v teréne, ktoré používa mobilné pripojenie a firmvér, ktorý sa nedá ľahko aktualizovať.
Väčšina prvých verzií firmvéru to rieši základnou logikou opakovania. Platforma však nemá prehľad o tom, čo sa stratilo. Chýba front nedoručiteľných správ, mechanizmus opätovného spracovania aj spôsob, ako odlíšiť neprijatú správu od prijatej správy, ktorej spracovanie zlyhalo.
Ako sa to prejaví v prevádzke: Medzery v histórii telemetrie. Chýbajúce dáta, ktoré sa odhalia až o týždne neskôr pri analýze. Zariadenia, ktoré vyzerajú ako offline, hoci dáta poslali, ale platforma ich zahodila.
Čo pomôže: Pravidlá opakovania priamo vo fronte so spracovaním nedoručiteľných správ. Spracovanie neúspešných správ sa opakuje s rastúcim odstupom. Opakovane zlyhávajúce správy skončia v DLQ, kde ich možno skontrolovať a spracovať znova. Obnovu po zlyhaní rieši platforma, nie zariadenie.
Tretí problém: jeden protokol na všetko
HTTPS funguje pri odosielaní telemetrie. Keď sa však použitie rozšíri nad rámec základného reportovania, musí aj platforma vedieť osloviť zariadenia. Aktualizácie firmvéru, zmeny konfigurácie a diagnostika vyžadujú, aby platforma odoslala dáta konkrétnemu zariadeniu. Pri samotnom HTTPS musí všetko iniciovať zariadenie. Musí sa pravidelne pýtať na aktualizácie. Platforma sama nič odoslať nedokáže.
Ako sa to prejaví v prevádzke: Nasadzovanie firmvéru trvá dni namiesto hodín. Zmeny konfigurácie sa prejavia až pri ďalšom cykle odosielania dát. Konkrétne zariadenie neviete rýchlo diagnostikovať bez čakania na jeho ďalšie pripojenie.
Čo pomôže: Pridanie MQTT popri HTTPS. Trvalé spojenia, smerovanie podľa tém a obojsmerná komunikácia. Každé zariadenie odoberá správy vo vlastnom mennom priestore. Platforma posiela dáta, keď potrebuje. HTTPS zostáva dostupné tam, kde dáva väčší zmysel.
Štvrtý problém: treba škálovať všetko naraz
Keď sú príjem a spracovanie previazané, škálovanie znamená zväčšovať všetko naraz. Ak sa spracovanie spomalí (zložitejšia validácia, náročnejšie zápisy, viac typov zariadení s rôznymi schémami), musíte pridať ďalšie inštancie API, hoci úzkym miestom je iba zápis. Platíte za nepotrebnú kapacitu príjmu, len aby ste získali vyššiu priepustnosť spracovania.
Ako sa to prejaví v prevádzke: Náklady na infraštruktúru rastú rýchlejšie než počet zariadení. Kapacitu sa nedá plánovať, pretože neviete oddeliť časť systému, ktorá nestíha.
Čo pomôže: Nezávislé škálovanie príjmu a spracovania. Pri samostatných službách škálujete workery podľa veľkosti frontu a kapacitu príjmu podľa prevádzky. Keď pridáte nový typ zariadenia s náročnejším spracovaním, pridáte workery. Prijímacia vrstva sa nemení. Náklady zodpovedajú skutočnej potrebe.
Do čoho sa oplatí investovať vopred
Nie všetko treba vybudovať hneď v prvý deň. Niektoré rozhodnutia sa však neskôr menia výrazne drahšie:
Navrhnite endpoint na príjem s jasným rozhraním. Aj v synchrónnej architektúre udržujte pipeline „prijať, overiť, spracovať, uložiť“ jasnú a rozdeliteľnú. Keď príde čas pridať front, potrebujete zreteľné miesto na oddelenie, nie spleť navzájom prepletenej logiky.
Pri každom stave zariadenia ukladajte čas správy. Každý stavový údaj by mal obsahovať časovú pečiatku správy, ktorá ho nastavila. Na začiatku je to jednoduché, doplniť to spätne je takmer nemožné. Bez toho nezvládnete správy prichádzajúce v nesprávnom poradí ani nerozoznáte aktuálnu aktualizáciu stavu od zastaranej.
Oddeľte identitu zariadenia od cesty príjmu dát. Autentifikácia každého zariadenia a autorizácia obmedzená na konkrétne témy nie sú len bezpečnostné funkcie. Sú základom správy zariadení, cielených aktualizácií a riešenia incidentov vo veľkom rozsahu. Ak ich začnete dopĺňať až po dodaní zariadení so spoločnými prihlasovacími údajmi, môže to byť problém vyžadujúci stiahnutie zariadení z prevádzky.
Zaveďte meranie skôr, než ho budete potrebovať. Úspešnosť príjmu, latencia spracovania na P95 a P99, podiel online zariadení, miera neaktívnych zariadení. Tieto metriky zbierate lacno, no keď sa niečo zhorší, sú neoceniteľné. Škálovacie problémy včas zachytia tímy, ktoré ich už priebežne sledujú.
Problémy často prichádzajú postupne: pri 200 zariadeniach všetko funguje, pri 1 000 sa objavia prvé obmedzenia a pri 5 000 už systém nestíha. Rozhodujúce je včas rozpoznať časti architektúry, ktoré budú rast brzdiť. Samotné pridávanie vývojárov ich nevyrieši.
