Synchrónny prístup: jednoduchý, rýchlo hotový a s jasnými limitmi
Priame spracovanie je jednoduché. Zariadenie pošle HTTPS správu na váš API endpoint. API overí požiadavku, skontroluje dáta, zapíše pôvodné aj normalizované údaje do databázy, aktualizuje posledný stav zariadenia a pridá záznam do histórie telemetrie. Jedna požiadavka, jeden tok, hotovo.
V AWS to znamená pomerne málo komponentov: ALB pred ECS Fargate, na ktorom beží API, databázu Aurora PostgreSQL a bežnú sieťovú konfiguráciu so správou tajných údajov. Ak máte skúsenosti s tvorbou webových aplikácií, vyzerá to presne ako tvorba webovej aplikácie. A práve o to ide.
Prečo to na začiatku funguje
Ladenie je priamočiare. Príde požiadavka a v rámci jednej služby sledujete jej cestu cez autentifikáciu, validáciu až po uloženie. Nemusíte skúmať zbernicu správ, prepájať logy workerov ani sledovať veľkosť frontu. Keď sa niečo pokazí, viete, kde hľadať.
Nasadenie je jednoduché. Jedna služba, jedna databáza, jedna infraštruktúra. Váš tím nemusí riešiť pravidlá doručovania správ vo frontoch, spracovanie nedoručiteľných správ ani eventual consistency. Pre malý počet zariadení, ktoré pravidelne posielajú telemetriu, to úplne stačí.
Kde sa začínajú problémy
Problémy vyplývajú z architektúry, nie z náhody. Príjem a spracovanie správ sú pevne previazané, takže latencia API a počet zlyhaní rastú priamo so záťažou databázy. Ak sa spomalí spracovanie (zložitá validácia, náročné zápisy, zmeny schémy), spomalí sa aj príjem. Zariadeniam začnú vypršávať časové limity.
Chýba vyrovnávacia pamäť na nárazovú záťaž. Ak sa naraz ozve 500 zariadení (a ozve sa, najmä pri časovaných intervaloch), všetky správy zasiahnu API aj databázu súčasne. Špičku nemáte kde zachytiť a postupne spracovať.
Škálovať musíte aj časti, ktoré to nepotrebujú. Keď spracovanie nestíha, pridávate kapacitu celému API, hoci problémom je iba zápis do databázy. Každý ďalší odberateľ dát, či už upozornenia, analytika alebo integrácie, navyše vyžaduje zmenu logiky API. Rozposielanie dát sa tak rýchlo komplikuje.
Spracovanie cez fronty: viac komponentov, ale každý škáluje samostatne
Asynchrónny model prácu rozdelí. Zariadenie pošle správu (HTTPS alebo MQTT) do prijímacej vrstvy. Tá overí zariadenie, uplatní pravidlá tém a vloží správu do frontu. Samostatný worker ju vyzdvihne, rozparsuje, overí schému a zapíše do úložiska stavov a telemetrie. Ak spracovanie zlyhá, správa skončí vo fronte nedoručiteľných správ, odkiaľ ju možno spracovať znova.
V AWS pribudne IoT Core (s vlastnými authorizermi a pravidlami tém), SQS pre hlavný front a DLQ a samostatné workery na ECS Fargate. Prijímacia a spracovateľská vrstva sú teraz nezávislé služby, ktoré sa škálujú samostatne.
Čo získate
Zvládanie nárazovej záťaže. Front slúži ako vyrovnávacia pamäť. Tisíc zariadení posielajúcich dáta naraz nezaťaží priamo databázu. Naplnia front a workery ho spracúvajú udržateľným tempom. Latencia príjmu zostáva stabilná, pretože prijímacia vrstva má jedinú úlohu: prijať správu a zaradiť ju do frontu.
Flexibilita protokolov. S prijímacou vrstvou na vstupe nie ste odkázaní len na HTTPS. Podpora MQTT prináša trvalé spojenia, nižšiu réžiu, smerovanie podľa tém a obojsmernú komunikáciu napríklad pri aktualizáciách firmvéru či konfigurácie. Zariadenia publikujú do devices/{deviceUid} a ďalšie smerovanie rieši platforma.
Zlyhanie spracovania nezastaví príjem správ. Ak worker spadne alebo sa nepodarí migrácia databázy, správy zostanú vo fronte. Nič sa nestratí. DLQ zachytí správy, ktorých spracovanie opakovane zlyháva, a po oprave ich môžete spracovať znova. V synchrónnom modeli musí pri zlyhaní spracovania opakovať odoslanie zariadenie (ak vôbec zistí, že sa niečo pokazilo).
Nezávislé škálovanie. Príjem zvládne desaťnásobnú prevádzku bez zásahu do workerov. Workery môžete optimalizovať na priepustnosť bez vplyvu na latenciu príjmu. Škálujete časť, ktorá skutočne nestíha, nie celý stack.
Prehľadná distribúcia dát. Potrebujete pridať systém upozornení? Dashboard v reálnom čase? Integráciu s externou službou? Prihlásite odber témy alebo pridáte konzumenta frontu. Cesta príjmu správ sa nemení.
Čo vás to bude stáť
Zložitosť je reálna a nedá sa obísť. Musíte myslieť na veci, ktoré v synchrónnom modeli neexistovali:
Idempotencia. Doručenie aspoň raz znamená, že správa môže prísť dvakrát. Spracovanie musí vedieť bezpečne zvládnuť duplicity. Ak zariadenie pošle rovnakú aktualizáciu stavu a worker ju zapíše dvakrát, zostane stav správny?
Poradie a zastarané údaje. Správy môžu prísť v inom poradí. Správa o stave z 10:01 sa môže spracovať skôr než správa z 10:00. Ak úložisko stavov bez kontroly zapisuje poslednú prijatú správu, novšie údaje prepíšete staršími. Riešením sú pravidlá aktuálnosti podľa časovej pečiatky: stav aktualizujte len vtedy, ak je prichádzajúca časová pečiatka novšia než uložená.
Parsovanie cez ovládače. Rôzne typy zariadení posielajú rôzne formáty dát. Aj rôzne verzie firmvéru rovnakého typu zariadenia môžu posielať dáta podľa odlišných schém. Potrebujete parsovanie cez ovládače, ktoré podľa typu a verzie zariadenia nasmerujú správu do správneho parsera. Validácia schémy pre každý typ udalosti zabráni ukladaniu neplatných dát.
Správa DLQ. Fronty nedoručiteľných správ sú skvelé, kým sa nenaplnia a nikto si ich nevšimne. Potrebujete monitoring, upozornenia na veľkosť DLQ a mechanizmus opätovného spracovania. DLQ bez súvisiaceho procesu je len miesto, kam sa schovávajú problémy.
Ako sa rozhodnúť
Rozhoduje najmä to, v akej fáze je váš produkt a akú záťaž musí zvládať.
Ak overujete produktový koncept s 50 až 200 zariadeniami, zvoľte synchrónny prístup. Budete napredovať rýchlejšie, jednoduchšie ladiť a menej platiť za infraštruktúru. Limity vás zatiaľ neobmedzia. Najväčším rizikom v tejto fáze je vyvinúť nesprávny produkt, nie zvoliť nesprávnu architektúru.
Ak smerujete do produkcie s rastúcim počtom zariadení, viacerými typmi hardvéru alebo potrebujete ďalších odberateľov dát okrem administračného dashboardu, zvoľte fronty. Úvodná investícia do pravidiel doručovania, idempotencie a návrhu workerov sa vráti pri prvej špičke, ktorú zvládnete bez výpadku či straty dát.
Najhoršie je vybudovať systém s frontmi, keď vám stačí synchrónny. Strávite týždne infraštruktúrou, ktorá váš produkt nezlepší. Druhé najhoršie je zostať pri synchrónnom prístupe príliš dlho a jeho limity objaviť pri produkčnom incidente o druhej ráno.
Záleží aj na ceste migrácie
Na jednu vec sa oplatí myslieť vopred: ak začnete synchrónne, navrhnite API tak, aby mal endpoint na príjem správ jasné rozhranie. Nerozptyľujte validáciu a biznis logiku po controlleroch. Tok „prijať správu, overiť, spracovať, uložiť“ držte v jednej pipeline, ktorú neskôr rozdelíte pred krokom spracovania vložením frontu.
Prechod sa komplikuje, keď je príjem správ natoľko previazaný so spracovaním, že sa nedajú ľahko oddeliť. Ak ich od začiatku navrhnete ako samostatné kroky, front neskôr pridáte oveľa jednoduchšie.
Článok vychádza z architektúry reálnej IoT platformy pre pripojené zariadenia v teréne s periodickou telemetriou aj telemetriou spúšťanou udalosťami vrátane sledovačov majetku, telematických jednotiek a priemyselných monitorovacích uzlov. Opísané vzory boli overené pri validácii s malým počtom zariadení aj v produkčnom nasadení vo veľkom rozsahu.
