Vă amintiți celebra zicală: "Păstrează-ți prietenii aproape și dușmanii și mai aproape" ? Acesta este un citat extrem de important deoarece ne spune cum trebuie tratat anturajul. În era IoT mai există un personaj important care intră în joc: datele. Acestea sunt generate de fiecare dispozitiv din ecosistemul personal și pot oferi oricui (prieten sau dușman) acces la informație privată dincolo de ceea ce vă puteți imagina.
Deoarece "rufele nu se spală în public", păstrarea datelor acasă ar putea fi o soluție. Acest lucru ar putea funcționa, dar, pentru că "suntem prea săraci pentru a fi ieftini" toți ar trebui să avem un centru privat de date acasă care să faciliteze replicări/duplicări, din moment ce "nu ar trebui să ne punem toate ouăle într-un coș"? Pe baza acestei informații, se pare că ne aflăm în fața unui drum înfundat, dar poate ar trebui să luăm în calcul citatul lui Einstein care spune că "Imaginația este mai importantă decât informația/cunoașterea" (niște zvonuri spun că era destul de deștept) și să ne imaginăm o soluție care poate combina puterea tehnologiilor enterprise cu dispozitive ieftine, pentru a întâmpina cerințele unui centru de date acasă.
Când vorbim de o rețea de senzori, există de obicei 4 nivele implicate:
senzorii, care sunt lansați în mediul înconjurător și care măsoară parametri diferiți în mod pasiv;
nodurile, care au o conexiune legată la senzori, care au rolul de a controla senzorii în mod activ (trezirea la anumite interval și interogarea făcută de senzori pentru a măsura datele) și care trebuie să trimită date la nivele superioare;
căile de acces (gateways) la care nodurile sunt de obicei conectate printr-o soluție wireless și care transmit datele în cloud ;
În ceea ce privește businessul sistemelor de monitorizare există trei canale majore:
canalul de intrare care primește datele în sistem de la senzorii din cache;
canalul de raportare care îi permite utilizatorului să ia datele din cache și să le folosească;
Scopul acestui articol este de a arăta cum se realizează o implementare cum este cea a unui sistem care foloseste tehnologii Java enterprise, precum Spring, engine de persistență, precum MySQL și MongoDB, rularea pe dispozitive ieftine precum Raspberry Pi și Intel Edison și măsurarea performanței sistemului pe diferite topologii și configurări.
Ca implementare de referință am creat o aplicație care să conțină o entitate (Record) care păstrează ID-ul senzorului, momentul masurării precum și valoarea măsurată și un set de controlere pentru fiecare canal (InputController care poate crea un Record, OutputController care este folosit pentru raportare și ca și reprezentant al canalului de configurare am considerat un AuthenticationController care autentifică utilizatorul și returnează un token de autentificare disponibil la nivelul mai multor noduri, care poate fi folosit pe canalul de raportare pentru a se obține datele. Software-ul de testare include un sistem care este capabil să simuleze mai mulți senzori în paralel.
Pentru măsurători de performanță am luat în calcul două cazuri de monitorizare - unul pentru locuințe care vor avea până la 10 senzori și altul al afacerilor mici (e.g.: o fermă) care vor avea până la 200 de senzori. Datele utilizate au provenit din sistemul de încărcare al CPU-ului care manevra cele trei canale.
Ca prim pas, am instalat toate componentele pe un Raspberry Pi 3 care are un microprocesor de 1.2GHz și 1GB de RAM pe care am instalat Raspbian, aplicația bazată Spring Boot și MySQL ca sistem de persistență.
Am rulat teste multiple cu un număr diferit de fire de execuție din care 4 au fost relevante (5, 10, 20 și 50 fire de execuție) și am concluzionat că este suficient să avem 200 de mostre pentru a avea informație suficientă.
Rezultatele au arătat că Raspberry Pi poate manipula până la 10 fire de execuție (ceea ce presupune senzori) cu o încărcare decentă. Dacă mergem dincolo de 10 senzori, sistemul se va supraîncărca și nu va putea fi utilizat deoarece va fi afectată grav experiența de lucru a utilizatorului. În ceea ce privește dimensiunea datelor stocate, după ce am adăugat date suficiente pentru a putea face estimări, concluzia a fost că dimensiunea datelor pentru studiul de caz al afacerilor mici este de 5GB/an, ceea ce poate încăpea pe un hard disk sau stick de memorie. Stocarea pe flash drives ar putea să fie o problemă datorată numărului limitat de editări. Mai jos puteți consulta mărimea necesară pentru stocare:
În timpul testelor am observat că o bună parte din ceea ce se încarcă este realizat de procesul MySQL și am refăcut toate testele utilizând 2 dispozitive RaspberryPi (unul pentru aplicația Spring Boot și unul pentru MySQL). După măsurători, am ajuns la concluzia că 15% din incărcare este produsă de Spring Boot (rulând peste Java), iar restul (85%) de MySQL.
Apoi, am dorit să lucrăm la disponibilitate și am instalat aplicația Spring Boot pe două dispozitive Raspberry Pi similare. Pentru persistență am folosit un set de replicare MongoDB care rulează pe trei Intel Edison (Intel Edison are un microprocesor de 500 MHz, 1GB de Ram și 4GB de Flash din care aproape 1GB este folosit de sistem). De asemenea, am adăugat un load balancer în fața celor două noduri Raspberry Pi.
Rezultatele au fost destul de impresionante atât pentru nodurile Spring Boot cât și pentru nodurile MongoDB. În cadrul graficelor de mai jos se poate observa că gradul de încărcare este sub 2 pe toate sistemele. Pe graficul MongoDB linia albastră reprezintă gradul de încărcare a nodului principal al setului de replicare.
Ultimul test a fost similar cu cel anterior, iar, pe lângă acesta, am adăugat un client de raportare pentru un număr normal de utilizatori pentru fiecare caz (5 pentru casă și 10 pentru afacerile mici). Pentru acest lucru, trebuie să adăugăm un nivel HazelCast între aplicația Spring Boot pentru a distribui tokenul de autentificare. În timpul acestor teste, jurnalele de încărcare în sistem erau similare cu cele ale testului precedent.
După efectuarea acestor teste, suntem încrezători că o configurație de mare disponibilitate pe care să și-o permită oricine este posibilă deoarece tehnologiile enterprise au fost simplificate, au o performanță crescută, iar, pe de altă parte, dispozitivele mici au din ce în ce mai multă putere de calcul și resurse.
Totuși, din moment ce nu suntem mereu acasă, un punct important de luat în calcul este cum aplicăm acest nivel de înțelegere a lucrurilor pe dispozitivele mobile. În ceea ce privește securitatea dispozitivelor mobile, vă sugerez să participați la prezentarea lui Dario Icalza pe tema "Android Application Security, The Right Way" de la conferința MobOS ediția 2017.
Aș dori să revenim la prietenii și dușmanii jocului și să spunem: păstrează-ți prietenii aproape, dușmanii mai aproape, iar datele cel mai aproape.
P.S. Tot acum lansăm Call4Speakers @MobOS 2017. Dacă aveți o prezentare de 10 sau 20 de minute pe o temă pe care doriți să o împărtășiți cu comunitatea mobilă, trimiteți-vă candidatura la hello.mobos@gmail.com înainte de 20 ianuarie 2017! Trimiteți tema, rezumatul, poza voastră și o biografie scurtă. Ne vedem în curând!