Compare commits
5 Commits
| Author | SHA1 | Date |
|---|---|---|
 Torma Kristóf
|
27c40dfdcb
|
|
|
Torma Kristóf
|
3080431fc3
|
|
|
Torma Kristóf
|
517e6d5d22
|
|
|
Torma Kristóf
|
06d8a8ffa0
|
|
|
Torma Kristóf
|
e5c7495af9
|
|
|
@ -16,7 +16,7 @@ steps:
|
|||
api_key:
|
||||
from_secret: GITEA_APIKEY
|
||||
base_url: https://git.kmlabz.com
|
||||
files: pdf/*
|
||||
files: pdf/thesis.pdf
|
||||
when:
|
||||
event: tag
|
||||
checksum:
|
||||
|
|
|
|||
|
|
@ -1,8 +1,6 @@
|
|||
# knative-report-latex
|
||||
2019 Szakdolgozat Latex
|
||||
|
||||
[](https://travis-ci.com/tormachris/knative-report-latex)
|
||||
# birbnetex-latex
|
||||
2020 Önlab latex
|
||||
|
||||
Drone:
|
||||
|
||||
[](https://drone.kmlabz.com/tormakris/knative-report-latex)
|
||||
[](https://drone.kmlabz.com/tormakris/birbnetes-onlab1-beszamolo)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
% !TeX root = ../thesis.tex
|
||||
\chapter{A laboratóriumi munka környezetének ismertetése, a munka előzményei és kiindulási állapota}
|
||||
\section{A laboratóriumi munka környezetének ismertetése, a munka előzményei és kiindulási állapota}
|
||||
\label{sec:first}
|
||||
|
||||
\section{Bevezető}
|
||||
\subsection{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.
|
||||
|
|
@ -11,15 +11,15 @@ Féléves munkánk során a központi feldolgozó egységen dolgoztunk. Célunk
|
|||
|
||||
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{Elm\'eleti \"osszefoglal\'o}
|
||||
|
||||
\subsection{Felhő}
|
||||
\subsubsection{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}
|
||||
\subsubsection{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.
|
||||
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ő. 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.
|
||||
|
||||
|
|
@ -35,33 +35,33 @@ Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
|
|||
\item Szolgáltatások név alapján történő felderítése
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Mikroszolg\'altat\'asok}
|
||||
\subsubsection{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}
|
||||
\subsubsection{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}
|
||||
\subsubsection{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}
|
||||
\subsubsection{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}
|
||||
\subsection{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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
% !TeX root = ../thesis.tex
|
||||
\subsection{Csatlakozó egyéb elkészült dokumentációk / fájlok / stb. jegyzéke}
|
||||
\label{sec:third}
|
||||
|
||||
|
||||
Az elk\'esz\'itett API defin\'ici\'ok el\'erhetők az al\'abbi linken: \url{https://swagger.kmlabz.com/}
|
||||
|
||||
Az \'altalunk k\'esz\'itett dokumentációk az al\'abbi linken \'erhetők el: \url{https://xwiki.kmlabz.com/bin/view/Projektek/Birbnetes\%20Projekt/}
|
||||
|
||||
Az elk\'eszult k\'od megtekinthető itt: \url{https://git.kmlabz.com/birbnetes/}
|
||||
|
|
@ -1,49 +1,49 @@
|
|||
% !TeX root = ../thesis.tex
|
||||
\chapter{Az elvégzett munka és eredmények ismertetése}
|
||||
\section{Az elvégzett munka és eredmények ismertetése}
|
||||
\label{sec:second}
|
||||
|
||||
\section{Rendszer tervezése}
|
||||
\subsection{Rendszer tervezése}
|
||||
A \ref{fig:birbnetes-architecture} ábrán látható architektúrát logisztikai okokból kifolyólag a mesterséges intelligenciát megvalósító szoftver ismerete nélkül alkottuk. Úgy tekintettünk rá, mint egy fekete dobozra, amely képes fájlokat beolvasni valamilyen módon és a vizsgálat eredményét is közli a felhasználóval valamilyen módon. Fontos szempont volt, hogy az egyes mikroszolgáltatások belső működése tetszőlegesen refaktorálható legyen anélkül, hogy az másik komponensben módosítást tenne szükségessé.
|
||||
|
||||
Jelenleg a rendszer csővezetékként működik, egyik végén beérkeznek a bemeneti adatok, amin a mesterséges intelligencia klasszifikációt hajt végre, majd ennek az eredményét továbbítja a kimenetet feldolgozó szolgáltatások felé, akik a pipeline másik vége.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width=120mm, keepaspectratio]{figures/architecture-simple.png}
|
||||
\includegraphics[width=\textwidth]{figures/architecture-simple.pdf}
|
||||
\caption{A rendszer komponensei \'es azok k\"oz\"otti kapcsolatok}
|
||||
\label{fig:birbnetes-architecture}
|
||||
\end{figure}
|
||||
|
||||
A rendszer tervezésekor célunk volt a bővíthetőség minél jobb támogatása, ezért megadtuk a lehetőségét annak, hogy a beérkező hangfájlt több mesterséges intelligencia is megvizsgálja párhuzamosan, az ilyen lehetséges elágazási pontokon üzenetsort használtunk. Így, ha a jelenleg egyenes pipeline-t szeretnénk leágaztatni, a megfelelő helyekre fel kell iratkoztatni az új komponenseket. Lentebb olvashatók részletesen az általam javasolt komponensek.
|
||||
|
||||
\subsection{Input Service}
|
||||
\subsubsection{Input Service}
|
||||
Fogadja a bemeneti hangfájlokat, ezeket továbbítja a hosszú idejű tárolást megvalósító Storage Service felé. Ezen felül ellátja egy egyedi azonosítóval is és minimális validációt végez.
|
||||
|
||||
Kapcsolódik egy relációs adatbázishoz, amelyben lementi az információkat, amelyeket fogadott a hangfájllal együtt. Ezeket összerendeli az egyedi azonosítóval, amelyet ő adott a hangfájlnak.
|
||||
|
||||
Miután a Storage Service lementette a hangfájlt, a service publikál egy üzenetet az üzenetsorba, amely tartalmazza a mentett hangfájl címkéjét. A feliratkozott komponensek ezekután a tag használatával letölthetik a lementett hangot és folytathatják rajta a feldolgozást.
|
||||
Miután a Storage Service lementette a hangfájlt, a service publikál egy üzenetet az üzenetsorba, amely tartalmazza a mentett hangfájl címkéjét. A feliratkozott komponensek ezekután a c\'imke használatával letölthetik a lementett hangot és folytathatják rajta a feldolgozást.
|
||||
|
||||
\subsection{Independent Results Service}
|
||||
\subsubsection{Independent Results Service}
|
||||
Feldolgozza a mesterséges intelligencia kimenetét, letárolja azt egy tetszőleges relációs adatbázisban. Lekérdezhető tőle - egymástól függetlenül - az egyes hangfájlokról hozott döntés. Az itt tárolt adatok összevethetők az Input Service-ben található adatokkal. Ez segíthet a hiba keresésben, valamint az itt található adatok segítségével a rendszerbe tanulás illeszthető.
|
||||
|
||||
\subsection{Results Statistics Service}
|
||||
\subsubsection{Results Statistics Service}
|
||||
Feldolgozza a mesterséges intelligencia kimenetét. Az eredményeket egy idősoros adatbázisban tárolja le. Ez az adatbázis sokkal alkalmasabb és hatékonyabb az eredmények "mérés" szerű kezelésén, de cserébe nem lehet lekérni tőle egyesével a hangfájlokról hozott döntéseket. Használata lehetővé teszi dashboardok készítését, ahol heat-map vagy más grafikonok segítségével tájékozódhat a felhasználó.
|
||||
|
||||
\section{API-k tervez\'ese}
|
||||
Mivel a projekten ketten dolgoztunk, fontos volt számunkra az egyes szolgáltatások API-jainak definiálása. Erre Swagger-t használtunk, ami egy jól dokumentált, nyitott definíciós eszköztár RESTful API-k leírására. Itt lényeges volt számomra, hogy az elvárt bemeneti formátumon felül minden lehetséges visszatérési státusz kódja és üzenetformátuma dokumentálva legyen az általam fejlesztett szolgáltatásoknak, ugyanis ez megkönnyíti a fejlesztést és a lehetséges félreértéseket is elkerüli. A rendszerben bevezettük a címkék vagy tagek fogalmát, amely egyedi azonosítója minden beküldött hangfájlnak. Az egyes tagekhez tárolt metaadatokat is le lehet kérdezni egy endpoint segítségével.
|
||||
\subsection{API-k tervez\'ese}
|
||||
Mivel a projekten ketten dolgoztunk, fontos volt számunkra az egyes szolgáltatások API-jainak definiálása. Erre Swagger-t használtunk, ami egy jól dokumentált, nyitott definíciós eszköztár RESTful API-k leírására. Itt lényeges volt számomra, hogy az elvárt bemeneti formátumon felül minden lehetséges visszatérési státusz kódja és üzenetformátuma dokumentálva legyen az általam fejlesztett szolgáltatásoknak, ugyanis ez megkönnyíti a fejlesztést és a lehetséges félreértéseket is elkerüli. A rendszerben bevezettük a címkék fogalmát, amely egyedi azonosítója minden beküldött hangfájlnak. Az egyes c\'imk\'ekhez tárolt metaadatokat is le lehet kérdezni egy endpoint segítségével.
|
||||
|
||||
Az Input Service API-ján kifejezetten sokat gondolkodtam, ugyanis a fájlok és az azokat kísérő metaadatok fogadására több alternatíva létezik. Állományok feltöltése miatt adódik a http mulipart form használata, viszont a metaadatok kerülhetnek külön részbe a kérésnek, vagy egybe valamilyen JSON formátumú adatstruktúrában. Végül az utóbbi mellett döntöttem, ugyanis Pythonhoz rendkívül kiforrott JSON sémavalidációs könyvtárak érhetők el, ezzel szemben ilyen eszközt, ami elegánsan képes multipart formok sémáját validálni, nem találtam.
|
||||
|
||||
A Results Statistics Service nem szolgál ki REST-es API-t, csupán fogadja a message queue-n érkező eredményeket és azokat letárolja a hozzá kapcsolódó timeseries adatbázisban.
|
||||
|
||||
Ez előbbivel szemben az Independent Results Service egyik legfontosabb tulajdonsága, hogy egy REST API-t nyújt. Itt kihasználva a relációs adatbázis által nyújtott lehetőségeket definiáltam olyan végpontokat, melyek visszaadnak minden pozitív vagy negatív eredményt, valamint adott dátum előtt, illetve után rögzített eredményeket. A cél az volt, hogy le lehessen kérdezni azegyes hangfájlokhoz tartozó adatokat, és ezt egy olyan endpoint segítségével lehet megtenni, amelyben a hangfájl tagje alapján azonosítható ez be.
|
||||
Ez előbbivel szemben az Independent Results Service egyik legfontosabb tulajdonsága, hogy egy REST API-t nyújt. Itt kihasználva a relációs adatbázis által nyújtott lehetőségeket definiáltam olyan végpontokat, melyek visszaadnak minden pozitív vagy negatív eredményt, valamint adott dátum előtt, illetve után rögzített eredményeket. A cél az volt, hogy le lehessen kérdezni azegyes hangfájlokhoz tartozó adatokat, és ezt egy olyan endpoint segítségével lehet megtenni, amelyben a hangfájl c\'imk\'eje alapján azonosítható ez be.
|
||||
|
||||
\section{Fejleszt\'es folyamata}
|
||||
\subsection{Fejleszt\'es folyamata}
|
||||
Fejlesztés során igyekeztem arra figyelni, hogy az általam írt kód helyes legyen, ezért a projekthez beállítottam egy folyamatos integrációs rendszert, amely minden git commitra lefuttatott teszteket, és amennyiben a kód átment ezeken a tesztken, container image-et épített és publikált az általam beállított container registry-be. Később a Kubernetes rendszerbe is innen kerültek be az egyes mikroszolgáltatások.
|
||||
|
||||
Az egyes komponensek futásakor keletkező kivételeket és hibaeseményeket egy központi rendszerben gyűjtöttük, ami képes volt kimutatások készítésére és egyes eseményekről értesítések küldésére. Mivel a rendszer Kubernetesben futott, jelentősen megkönnyítette a hibakeresési folyamatot, hogy a rendszer képes volt rámutatni arra a kódsorba, amely a hibát kiváltotta, valamint az aktuális környezetet és a hibaüzenetet is tárolta.
|
||||
|
||||
\subsection{Input Service}
|
||||
\subsubsection{Input Service}
|
||||
Az Input Service implementálásához a Flask nevű Python web mikroframeworköt használtam. A Flask csak a webes rétegét valósítja meg egy alkalmazásnak, ORM-et (Object-relation mapping) vagy validációt nem nyújt a fejlesztőknek, viszont egyszerűen kiegészíthető tetszőleges beépülő modulokkal. Ebben a mikroszolgáltatásban viszont szükség volt adatbázissal történő kommunikációra és a kapott adatok sémájának validációjára.
|
||||
|
||||
Előbbire az SQLAlchemy nevű könyvtárat használtam, melynek kényelmes Flask-os pluginja van. Emiatt csupán definiálnom kellett az általam használt sémát, megadni a Flask-nak az adatbázis elérési helyét, ez után tetszőleges metódusban lehetett lekérdezni, beilleszteni és frissíteni rekordokat az adatbázisba.
|
||||
|
|
@ -66,7 +66,7 @@ A választás végül a RabbitMQ-ra esett, amely egy Erlang nyelven készült, n
|
|||
|
||||
A metaadatok validációjára Marshmallow-t használtam. Ez a könyvtár képes előre definiált séma alapján JSON-ből betölteni adatokat, valamint szerializálni őket. A fejlesztés során előkerült egy olyan probléma, hogy az SQLAlchemy segítségével lekérdezett rekordokat a Flask nem tudta automatikusan JSON-ba szerializálni a Python beépített szerializálójával. Erre is megoldást jelentett a Marshmallow, ugyanis létezik egy Marshmallow-SQLAlchemy nevű könyvtár, amely definiál olyan SQLAlchemy sémaosztályokat, amiket a Marshmallow képes JSON-be szerializálni és betölteni.
|
||||
|
||||
\subsection{Independent Results Service}
|
||||
\subsubsection{Independent Results Service}
|
||||
A mikroszolgáltatás architektúra lehetővé teszi divergens technológiák együttműködését. Ezt kihasználva az Independent Results Service mikroszolgáltatást nem Python, hanem Kotlin nyelven írtam. Ez azt jelentette, hogy a teljes eszköztár, melyet megismertem nem voltak használhatók e komponens fejlesztése esetében, viszont utóbbi programnyelvben elérhető coroutine-ok olyan előnyt jelentettek, ami miatt megérte megtanulni az új eszköztár használatát. Például a Kotlin esetében a webes logika megvalósítására a legnépszerűbb könyvtár a Ktor, melynek szolgáltatáskészlete hasonlít a Flaskhoz.
|
||||
|
||||
A Kotlin egy a Java Virtual Machine-t használó modern programnyelv, amelynek célja a Java hiányosságait, hátrányait javítani. A Java-hoz képest a legnagyobb különbség a null-safe viselkedése és a coroutine-ok használata. Utóbbi használatával könnyedén fejleszthető nagy teljesítményű alkalmazást. Mivel a Kotlin egy fiatal nyelv, valamint leginkább Android appok fejlesztésére használják, így az egyes könyvtárak nem feltétlen olyan fejlettek, mint a Python esetében. Ilyen volt például az általam használt ORM megoldás, az Exposed. Ennek előnye, hogy jól illeszkedik a kotlinos programozási paradigmákhoz, viszont nem képes connection poolingra másik library-k használata nélkül, a Postgresql-t viszont natívan támogatja.
|
||||
|
|
@ -77,7 +77,7 @@ A Kotlin használata akkor fizetődött ki, miután a REST API-t kiszolgáló r
|
|||
|
||||
A mikroszolgáltatás fejlesztése során sok időt töltöttem az adatbázis réteg fejlesztésével, mert nehézkesen tudtam csak működésre bírni az Exposed könyvtárat a connection poolinggal és a JSON szerializációval.
|
||||
|
||||
\subsection{Result Statistics Service}
|
||||
\subsubsection{Result Statistics Service}
|
||||
Timeseries adatbázist a rendszerben csak ez a mikroszolgáltatás használ, így ennek kiválasztása ezen komponens fejlesztése során történt. A kiválasztás során a szempontok csak a mikroszolgáltatás saját szempontjai voltak. Próbáltam kiválasztani a lehető legegyszerűbb megoldást, ugyanis nincs szükség például komplex adatstruktúrák támogatására, viszont a retention policy-k használatának lehetősége és a nagy teljesítmény követelmény volt.
|
||||
|
||||
Először a Prometheust vizsgáltam meg, amely egy népszerű timeseries adatbázis rendszer, amit főleg metrikák tárolására használnak. Emiatt támogatja a retention policy-ket, viszont nagy erőforrás lábnyomba van és a lehetőségeinek kis százalékát tudnám csak kihasználni.
|
||||
|
|
@ -90,7 +90,7 @@ A Result Statistics Service mikroszolgáltatást először C\# nyelven kezdtem e
|
|||
|
||||
E mikroszolgáltatás esetében az üzleti logika eleve nem bonyolult, az üzenetsoron érkező üzenetben található adatot az aktuális idővel megcímkézve be kell illeszteni az InfluxDB-be. Ezt viszont szerettem volna aszinkron módon megtenni, ugyanis elképzelhető az üzenetsoron nagy számú üzenet érkezése rövid idő alatt. Ennek implementációját is elvetettem, ugyanis az InfluxDB, ahogy kutatásom során kiderült, olyan nagy számú kérést képes feldolgozni rövid idő alatt, hogy nem érné meg aszinkron logikával bonyolítani a mikroszolgáltatást \cite{influxdb-performance} .
|
||||
|
||||
\section{Kubernetes}
|
||||
\subsection{Kubernetes}
|
||||
Az általunk használt Kubernetes klaszter egy fizikai számítógépen futott négy virtuális gépen. A rendszerben egy Master node és három Worker node volt. A tárterületet ugyanerről a fizikai gépről osztottuk ki a fürt számára NFS-sel, a Persistent Volume-okat statikusan definiáltuk. Az általam fejlesztett mikroszolgáltatásokat és az azokhoz kapcsolódó komponenseket magam telepítettem a klaszterbe.
|
||||
|
||||
Az általunk fejlesztett rendszer számára létrehoztam egy Kubernetes névteret, ahova telepítettük az általunk fejlesztett mikroszolgáltatásokat és minden általuk használt komponenst.
|
||||
|
|
@ -113,16 +113,18 @@ A Kubernetes-natív kategóriába sorolható API Gatewayek közé tartozik a Kon
|
|||
|
||||
Alternatíva az Ambassador használata, ami a háttérben Envoy-t használ. Szintén támogat minden fontos képességet, viszont hátránya, hogy konfigurációja label-be ágyazott YAML segítségével lehetséges. Ez nem kívánatos, hiszen erre Custom Resource Definitionöket hibabiztosabban és flexibilisebben lehetne használni.
|
||||
|
||||
Megvizsgáltam továbbáa Gloo-t, aminek különleges előnye, hogy képes automatikusan alkalmazások API-jának automatikus felismerésére OpenAPI definíciók segítségével, amiket mi a fejlesztési folyamat elején definiáltunk.
|
||||
Megvizsgáltam továbbá a Gloo-t, aminek különleges előnye, hogy képes automatikusan alkalmazások API-jának automatikus felismerésére OpenAPI definíciók segítségével, amiket mi a fejlesztési folyamat elején definiáltunk.
|
||||
|
||||
A választásom végül a Kong-ra esett, mert számomra szimpatikus volt, hogy egy egyszerű NGINX webszerver segítségével oldja meg funkcióit. A telepítést ez után az Ingress objektumok definiálásával és a klaszterbe telepítésével folytattam.
|
||||
|
||||
\section{Elkészült rendszer próbája}
|
||||
\subsection{Elkészült rendszer próbája}
|
||||
A mikroszolgáltatások fejlesztése közben önmagukban teszteltem őket és próbáltam ki működésüket. A fejlesztési folyamat végén viszont közösen kipróbáltuk, hogy működnek együtt az általunk fejlesztett komponensek, milyen hibák jönnek itt elő.
|
||||
|
||||
Előkerültek olyan hibák, amik eltérő feltételezésekből következnek. Ezen esetekben egyeztettük a konvencióink, majd a javítás után újra teszteltük a működést.
|
||||
|
||||
\section{\"Osszefoglal\'as}
|
||||
A folyamat eredm\'enyek\'ek\'ent kaptunk egy műk\"odő rendszert, aminek minden komponense k\'epes volt egym\'assal egy\"uttműk\"odni. Beadtunk p\'eld\'aul egy olyan hangf\'ajlt, amely sereg\'ely \'eneket \'es egy olyat, amin motorhang volt. R\"ovid idő eltelt\'evel lek\'erzhető volt az eredm\'eny az Independent Results Service-től, mindkettőt motorhangk\'ent klasszifik\'alta az MI. Ugyanekor az InfluxDB-ből lek\'erezhető volt az időpontokban t\"ort\'ent m\'er\'esek. Ez nem probl\'ema a mi projekt\"unk szempontj\'ab\'ol, elv\'egre a f\'el\'ev elej\'en kiindul\'o felt\'etelez\'es\"unk volt, hogy az MI modellek adottak, azokon nem c\'elunk v\'altoztatni, azokat jav\'itani.
|
||||
|
||||
\subsection{\"Osszefoglal\'as}
|
||||
A félév során számos új tudással bővültem, többek között elsajátítottam a Kotlin nyelv alapszintű működését, valamint megtanultam, hogy kell mikroszolgáltatás alapú rendszert tervezni, fejleszteni és az ezek Kubernetesbe telepítésével kapcsolatos megontolásokat is részletesebben megismertem. Több technológia működésébe nyertem betekintést, ezzel tágítva az eszköztáram.
|
||||
|
||||
Elkészítettem több újra használható Kubernetes Deploymentet és a hozzájuk tartozó egyéb API objektumokat, ami a későbbi munkám során segítségemre lehet. Megterveztem és végrehajtottam az általunk fejlesztett komponensek automatikus Kubernetesbe telepítését és a frissítések automatikus elvégzését.
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
|
|
@ -1,12 +1,11 @@
|
|||
% !TeX spellcheck = hu_HU
|
||||
% !TeX encoding = UTF-8
|
||||
% !TeX program = xelatex
|
||||
\documentclass[11pt,a4paper,oneside]{report} % Single-side
|
||||
\documentclass[11pt,a4paper]{article} % Single-side
|
||||
%\documentclass[11pt,a4paper,twoside,openri\cite{microservices-apply}ght]{report} % Duplex
|
||||
|
||||
\input{include/packages}
|
||||
|
||||
|
||||
% Set the main variables
|
||||
\newcommand{\vikszerzoVezeteknev}{Torma}
|
||||
\newcommand{\vikszerzoKeresztnev}{Krist\'of}
|
||||
|
|
@ -40,6 +39,9 @@
|
|||
\newcommand{\szerzoMeta}{\vikszerzoVezeteknev{} \vikszerzoKeresztnev} % egy szerző esetén
|
||||
%\newcommand{\szerzoMeta}{\vikszerzoVezeteknev{} \vikszerzoKeresztnev, \tdkszerzoB} % két szerző esetén
|
||||
|
||||
\markright{\szerzoMeta~(\vikszerzoNeptun)} % egyoldalas fejléc!!!
|
||||
|
||||
|
||||
%Language configuration -- choose one
|
||||
% Beállítások magyar nyelvű dolgozathoz
|
||||
\input{include/thesis-hu}
|
||||
|
|
@ -67,7 +69,7 @@
|
|||
|
||||
%Titlepage -- choose one from below
|
||||
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
\input{include/titlepage-tmit} % Szakdolgozat/Diplomaterv címlap
|
||||
\input{include/titlepage-tmit} % TMIT Onlab címlap
|
||||
%\include{include/titlepage-tdk} % TDK címlap
|
||||
%\include{include/titlepage-otdk} % OTDK címlap
|
||||
|
||||
|
|
@ -99,8 +101,10 @@
|
|||
|
||||
% Bibliography
|
||||
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
\addcontentsline{toc}{chapter}{\bibname}
|
||||
\addcontentsline{toc}{section}{\bibname}
|
||||
\section{Irodalom, és csatlakozó dokumentumok jegyzéke}
|
||||
\bibliography{bib/mybib}
|
||||
\input{content/included}
|
||||
|
||||
% Appendix
|
||||
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in New Issue