68 lines
12 KiB
TeX
68 lines
12 KiB
TeX
% !TeX root = ../thesis.tex
|
||
\chapter{A laboratóriumi munka környezetének ismertetése, a munka előzményei és kiindulási állapota}
|
||
\label{sec:first}
|
||
|
||
\section{Bevezető}
|
||
Szőlőtulajdonosoknak éves szinten jelentős kárt okoznak a seregélyek, akik előszeretettel választják táplálékul a megtermelt szőlőt. Az ilyen kártevő madarakat hangjuk alapján detektáló rendszert dolgozott ki diplomamunkája során Nagy Kristóf, amely a mesters\'eges intelligencia eszköztárát hívja segítségül. Féléves munkánk az Ő kutatására alapul.
|
||
|
||
A Kristóf által megalkotott detekciós algoritmus gyakorlati felhasználását egy olyan rendszerben látjuk, ahol költséghatékony módon kis számítási kapacitású Internet of Things eszközök gyűjtik a hangmintákat a termőföldekről, és továbbítják egy nagyobb számítási kapacitású központi feldolgozó egység felé, amely kiértékeli őket, és figyelmeztet a veszélyre, akár képes valamilyen formában automatizáltan beavatkozni.
|
||
|
||
Féléves munkánk során a központi feldolgozó egységen dolgoztunk. Célunk olyan rendszer megalkotása volt, amely kihasználja a manapság nagy népszerűségnek örvendő felhő alapú szolgáltatások előnyeit.
|
||
|
||
A projekten ketten dolgoztunk Pünkösd Marcell-lel, aki az MI komponens mikroszolgáltatásokra darabolásával, valamint a modellek és bemeneti hangfájlok tárolásával, valamint ezzel kapcsolatos felhő-natív technológiákkal foglalkozott. Én a félév során a rendszer bemeneti és az MI által adott eredményt feldolgozó mikroszolgáltatásokkal, valamint ezek felhő-natív megoldásával foglalkoztam.
|
||
|
||
\section{Elm\'eleti \"osszefoglal\'o}
|
||
|
||
\subsection{Felhő}
|
||
A felhőalapú számítástechnikában a felhasználó elől elrejtve, a szolgáltató erőforrás halmazán elosztva megvalósított szolgáltatásokat értjük, amit jellemzően virtualizációs technológiára építenek. Három szolgáltatási modellt különböztetünk meg: SaaS (Software as a Service \cite{saas}, Szoftver, mint Szolgáltatás, például: Office 365), PaaS (Platform as a Service, Platform, mint Szolgáltatás \cite{paas}, például: Oracle Cloud Platform) és IaaS (Infrastructure as a Service \cite{iaas}, Infrastruktúra, mint Szolgáltatás, például: Microsoft Azure).
|
||
|
||
\subsection{Kubernetes}
|
||
A Kubernetes egy Go nyelven írt, nyílt forráskódú konténer orkesztrációs platform, amely képes konténerek automatikus konfigurációjára, skálázására, valamint bizonyos hibák automatikus elhárítására is. Több konténer technológiát \cite{kubernetes-runtimes} támogat, köztük a Dockert is. Nagyon népszerű, gyors fejlesztés alatt álló projekt. Emiatt felhasználói és programozói interfésze gyakran változik, megkövetelve a ráépülő megoldásoktól a hasonló sebességű fejlesztést. Jól definiált interfésze miatt sok ráépülő, azt kiegészítő projekt létezik. A Kubernetes kiváló keretet nyújt mikroszolgáltatás alapú alkalmazások fejlesztésére.
|
||
|
||
Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet több darab, de legalább egy-egy példány kötelező. A \ref{fig:k8s-chart} \'abr\'an l\'athat\'o, hogy egy Kubernetes klaszter \cite{kubernetes-nodes} legal\'abb egy Masterből \'es Workerből \'ep\"ul fel, ezek több komponensből állnak.
|
||
|
||
A Kubernetes Master felelős a klaszterben lezajló folyamatok \cite{kubernetes-concepts} irányításáért, a Slave-ek vagy más néven Worker-ek, valamint az alkalmazások állapotának nyilvántartásáért. A klaszterben történő eseményekre válaszul klaszterszintű választ ad - például egy pod elindítása. Egy Master node számos komponensből áll, ezek a Master egy-egy feladatáért felelnek. Több Master node futtatása esetén - úgynevezett multimaster mode - csak az API Server \cite{kubernetes-api} és az etcd \cite{etcd} komponensekből jön létre több példány, a többiből egyszerre csak egy példány lehet aktív.A Pod \cite{kubernetes-pods} egy vagy több konténert összefogó logikai hoszt. Egy podon belül lévő konténerek osztoznak a hálózaton és a háttértáron, valamint azonos a futtatási specifikációjuk. Ez azt jelenti, hogy az egy podon belüli konténerek localhost-on keresztül elérik egymást, valamint van lehetőség, hogy a konténerekben futó alkalmazások lássák a másik konténerben futó folyamatokat. Egy Kubernetes rendszerben a Pod a legkisebb egység, amit futásra lehet ütemezni.
|
||
|
||
A Deployment \cite{kubernetes-deployment} segítségével deklaratívan leírható egy alkalmazást felépítő podok és azok kívánt állapota. Lehetőség van megadni, hány replikát hozzon létre a rendszer. Hasonló módon lehet a podok állapotát frissíteni vagy egy korábbi állapotra visszatérni. Egy Deploymentben lehetőség van több pod definiálására, ami az alkalmazás komponensek lazább csatolását teszi lehetővé.
|
||
|
||
A podok bármikor törlődhetnek, valamint új példány jöhet belőlük létre \cite{kubernetes-service}. Minden pod saját IP címmel rendelkezik, viszont szükség van valamilyen módszerre, aminek segítségével nyomon lehet követni, hogy egy pod által nyújtott szolgáltatás milyen címen érhető el. Erre a problémára nyújt megoldást a Service, ami absztrakciót jelent a podok felett.
|
||
|
||
Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
|
||
\begin{itemize}
|
||
\item Horizontális skálázás,
|
||
\item Konfiguráció és szenzitív adatok menedzsmentje,
|
||
\item Háttértár orkesztráció
|
||
\item Szolgáltatások név alapján történő felderítése
|
||
\end{itemize}
|
||
|
||
\subsection{Mikroszolg\'altat\'asok}
|
||
A mikroszolgáltatás vagy mikroszolgáltatás szoftverarchitektúra egy alkalmazás architektúra \cite{microservices-intro}, amelynek segítségével a komplex, skálázható alkalmazások fejlesztése egyszerűbb, valamint a kódbázis növekedésével átlátható marad. Ezt úgy éri el, hogy az alkalmazást kisebb, önálló komponensekre bontja, ezeket lazán, tipikusan REST API-val, vagy üzenet sorok (message queue) segítségével illeszti egymáshoz. Az architektúra alkalmazása esetén felmerülnek bizonyos problémák, mint például az egyes szolgáltatásoknak meg kell egymást találniuk, vagy több példány futtatása esetén megoldandó a terheléselosztás is. Az így fejlesztett alkalmazások kiválóan illeszkednek a felhő alapú rendszerekhez, például a Kuberneteshez.
|
||
|
||
Mikroszolgáltatás architektúra esetében figyelni kell az úgynevezett hidden monolitra, amikor a fejlesztett alkalmazás viselkedéséből adódóan igazából nem mikroszolgáltatás alapú. Például, ha minden mikroszolgáltatás függ egytől, akkor az adott architektúra rejtett monolit jellegű.
|
||
|
||
Pozitív tulajdonsága a mikroszolgáltatásoknak, hogy jól definiált API-k \cite{microservices-apply} mellett az egyes szolgáltatások a saját adatszerkezetüket a nekik legmegfelelőbb módon képesek kezelni, nincs szükség kompromisszumokra az egész alkalmazást figyelembe véve.
|
||
|
||
\subsection{Message Queue}
|
||
A message queue, vagy üzenetsor \cite{microservices-messagequeue} egy olyan szoftver vagy szoftverkomponens, amely az egyes önálló folyamatok közötti kommunikációt teszi lehetővé aszinkron üzenetek küldésével és fogadásával. Az ilyen rendszerek aszinkron jellegének hála nem szükséges a küldőnek és a fogadónak egyszerre kapcsolatban lennie az üzenetsorral, ugyanis egy-egy üzenet addig tárolódik az üzenetsorban, amíg a fogadó fél nem fogadja azokat. Ilyen módon nem csak egy-egy kommunikáció megvalósítása lehetséges, hanem egy-több is a küldő és fogadó felek minimális módosításával, mert az üzenetek sokszorosítását az üzenetsor rendszer végzi. Egy ilyen szoftver a RabbitMQ.
|
||
|
||
A message queue elősegíti a mikroszolgáltatás alapú rendszerek fejlesztését az aszinkronitás, valamint az egy a többhöz kommunikáció megvalósításával. Ezek gyakran előforduló problémák, melyeket üzenetsor nélkül bonyolult lenne megoldani. Tegyük fel például, hogy egy küldő fél által produkált adatokat egyszerre több módon szeretnénk feldolgozni. Ennél bonyolultabb eset lehet, ha a feldolgozó nagy erőforrásigényű műveleteket végez, ami miatt szeretnénk a példányszámát skálázni. Message queue nélkül a fejlesztőknek kéne a küldő komponensben nyilván tartani, hogy kinek kell elküldeni az adatokat, valamint a fogadók példányszámának növekedésével a küldés is egyre hosszadalmasabb lenne. Ezen problémákat hivatott megoldani a message queue.
|
||
|
||
\subsection{Timeseries Adatb\'azis}
|
||
Egy timeseries adatbázis olyan adatbázis, amely idő függvényében változó adatokat vagy adatsorokat képes hatékonyan tárolni és lekérdezni. Ilyen adatbázisban tipikusan valamilyen metrika jellegű adatot tárolnak. Általában az ilyen rendszerek elválasztják a konstans, diszkrét és a folyamatos adatokat pontok halmazába. Egy timeseries adatbáziskezelő \cite{microservices-timeseriesdb} rendszer az InfluxDB, amelynek sajátossága, hogy SQL-szerű lekérdezőnyelvvel rendelkezik. Van lehetőség ún. retention policy megadására, amik segítségével megadható, milyen pontossággal lehet lekérdezni az egyes múltbéli adatokat. Minél régebbi adatokat szeretnénk kinyerni, annál kisebb pontossággal lehet azt megtenni.
|
||
|
||
Feltételezve, hogy a régebbi adatokra nincs szükségünk túl nagy részletességgel, például tized másodperces felbontással, azokat elég órás vagy még régebbi adatok esetén akár napos felbontásban összegezve is letárolni. Ilyen lehetőségeket úgynevezett retention policy-k segítségével tudunk definiálni, ami ezt a viselkedést valósítja meg, ez által csökkentve az adatbázis tárhelyigényét.
|
||
|
||
Timeseries adatbázis használata nagyban megkönnyíti különböző kimutatások, grafikonok létrehozását, hiszen az adatok tárolási módjából adódóan készen állnak a grafikon kirajzolására. Az InfluxDB aszinkron REST API-jának köszönhetően kifejezetten nagy mennyiségű adatot képes befogadni adott idő alatt.
|
||
|
||
\subsection{Api Gateway}
|
||
Mikroszolgáltatás alapú rendszerekben fontos, a felhasználók számára egységes API kiszolgálása, viszont a belső rendszerek API-jait az egyes szolgáltatások saját és egymás működését segítő módon érdemes definiálni. Így minden belső API és rendszer jól definiált lehet. Emellett lehetséges, hogy egy kliens olyan információkra kíváncsi, amelyhez több szolgáltatáshoz kell fordulnia, hogy összeszedje mindet. Ugyanígy a rendszer növekedésével az egyes klienseknek szükséges lenne ismerni az általuk használni kívánt szolgáltatások elérhetőségét.
|
||
|
||
Ezeket a problémákat hivatott feloldani az API Gateway \cite{microservices-apigateway}, melynek feladata az egységes API kialakítása. Az API Gateway feladata többek között a kliensek leválasztása a konkrét rendszerarchitektúráról, egyes mikroszolgáltatások elérési információjának ismerete – a kliensek helyett és a különböző protokollt használó API-k esetében protokollfordítás.
|
||
|
||
Mindemellett fontos még az úgynevezett circuit breaker logika biztosítása, amely megnöveli a felhasználói élményt, ugyanis az API Gateway képes észlelni, ha egy mikroszolgáltatás túl sokáig nem válaszol vagy nem elérhető, és ez esetben valamilyen logika alapján választ tud adni a klienseknek.
|
||
|
||
\section{A munka állapota, készültségi foka a félév elején}
|
||
A félév elején rendelkezésünkre álltak a Nagy Kristóf által tanított modellek, az általa használt audio fájlok és a futtató szoftver. Így a mesterséges intelligencia komponense a projektnek gyakorlatilag kulcsra készen rendelkezésre állt kezdéskor. A projekt kezdésekor Linuxos és Dockerrel kapcsolatos tudásunk jelentős volt. Kubernetessel Bsc Témalaboratórium tantárgy keretein belül ismerkedtem meg, azóta napi szinten használom. Kristóf által a hangfájlok analízisére használt szoftver Python nyelven készült.
|
||
|
||
Python programnyelven Marcell és én kényelmesen tudunk fejleszteni, tanulmányaink során számos szoftvert fejlesztettünk e nyelven, ezért úgy döntöttünk, hogy a mikroszolgáltatások nagy részét is e nyelven fejlesztjük le.
|