tormakris/birbnetes-tdk-latex
1
0
Fork 0
Code Releases 2 Activity

overleaf edits
Some checks failed
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/tag Build is failing
Details

Browse Source
This commit is contained in:
Torma Kristóf
2020-10-28 10:46:16 +01:00
parent 9f5aface07
commit fe30555762
13 changed files with 515 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
src/content/theory.tex
View File

@@ -3,22 +3,38 @@
\label{sec:theory}
\section{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 alapvető szolgáltatási modellt különböztetünk meg: SaaS (Software as a Service, Szoftver, mint Szolgáltatás, például: Office 365), PaaS (Platform as a Service, Platform, mint Szolgáltatás, például: Oracle Cloud Platform) és IaaS (Infrastructure as a Service, Infrastruktúra, mint Szolgáltatás, például: Microsoft Azure). További szolgáltatási modellek: Container aaS, Function aaS, etc.
A felhő alapú számítástechnikában \cite{cloud} 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. Négy fő szolgáltatási modellt különböztetünk meg: SaaS \cite{saas} (Software as a Service, Szoftver, mint Szolgáltatás, például: Office 365), FaaS \cite{faas} (Function as a Service, Függvény, mint Szolgáltatás, például: Amazon Lambda), PaaS \cite{paas} (Platform as a Service, Platform, mint Szolgáltatás, például: Oracle Cloud Platform) és IaaS \cite{iaas} (Infrastructure as a Service, Infrastruktúra, mint Szolgáltatás, például: Microsoft Azure). %További szolgáltatási modellek: Container aaS, Function aaS, etc.
\section{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 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.
<ábra példa k8s klaszterről>
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 legalább egy Masterből és Workerből épül fel, ezek több komponensből állnak. A Kubernetes Master felelős a klaszterben lezajló folyamatok irányításáért, valamint a Slave-ek - vagy más néven Workerek - és az alkalmazások állapotának nyilvántartásáért. 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 és az 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 Kubernetesben különböző objektumtípusokat definiáltak, ezek közül a legfontosabbakat bemutatjuk a következőkben (Pod, Deployment, Service és Ingress).
A Pod 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 localhoston 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 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. 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.
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 egy-egy feladatot ell\'at\'o komponensekből \'allnak. A Kubernetes Master felelős a klaszterben lezajló folyamatok 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. 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 multi-master mode - csak az API Server \cite{kube-apiserver} é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 Kubernetesben különböző objektumtípusokat definiáltak, ezek közül a legfontosabbakat bemutatjuk a következőkben (Pod, Deployment, Service és Ingress).
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 megtalálják 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:
Horizontális skálázás,
Konfiguráció és szenzitív adatok menedzsmentje,
Háttértár orkesztráció,
Szolgáltatások név alapján történő felderítése.
Ingress erőforrás segítségével klaszteren belüli Service erőforrást lehet azon kívülre kiszolgálni. Ennek módját az Ingress erőforrás határozza meg, amelyet az Ingress Controller nevű klaszter szintű objektum szolgál ki.
\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}
Ingress \cite{kubernetes-ingress-resource} erőforrás segítségével klaszteren belüli Service erőforrást lehet azon kívülre kiszolgálni. Ennek módját az Ingress erőforrás határozza meg, amelyet az Ingress Controller nevű klaszter szintű objektum szolgál ki.
\section{Mikroszolgáltatások}
A mikroszolgáltatás vagy mikroszolgáltatás szoftverarchitektúra egy alkalmazás architektúra, 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 rejtett 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 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.
A mikroszolgáltatás vagy mikroszolgáltatás \cite{microservices-intro} szoftverarchitektúra egy alkalmazás architektúra, 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 \cite{7557535}, 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 \cite{8486300} 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 rejtett 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 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.
\section{Internet of Things}
Az Internet of Things (IoT), vagy magyarul a Dolgok Internete mindennapi eszközök szenzorokkal és internet kapcsolattal ellátását jelenti. Ezek az eszközök képesek automatikusan adatok gyűjtésére és azok továbbítására. Gyakran előfordul, hogy több típusú szenzorból gyűjtött adatok egy felhős rendszerben kerülnek összegzésre és feldolgozásra, ugyanis at IoT eszközök tipikusan alacsony számítási kapacitással és fogyasztással rendelkeznek, ami az egyes eszközök árát is alacsonyan tartja. Jó példa az IoT-ben rejlő lehetőségekre egy olyan okos termosz, amely az online elérhető időjárás előrejelzések és a felhőben tárolt felhasználói profil alapján előre melegíti vagy hűti az általa irányított lakást.
Az Internet of Things (IoT), vagy magyarul a Dolgok Internete mindennapi eszközök szenzorokkal és internet kapcsolattal ellátását \cite{10.1007/978-3-319-29504-6_7} jelenti. Ezek az eszközök képesek automatikusan adatok gyűjtésére és azok továbbítására. Gyakran előfordul, hogy több típusú szenzorból gyűjtött adatok egy felhő \cite{6778179} rendszerben kerülnek összegzésre és feldolgozásra, ugyanis at IoT eszközök tipikusan alacsony számítási kapacitással és fogyasztással rendelkeznek, ami az egyes eszközök árát is alacsonyan tartja. Jó példa az IoT-ben rejlő lehetőségekre egy olyan okos termosztát, amely az online elérhető időjárás előrejelzések és a felhőben tárolt felhasználói profil alapján előre melegíti vagy hűti az általa irányított lakást.
\section{Mesterséges Intelligencia}
Az elmúlt években, ahogy a technológia fejlődött, a mesterséges intelligencia és gépi tanulás eszköztárát segítségűl hívó megoldások is egyre inkább eljterjedtek. Ezek a megoldások lehetőséget adnak arra, hogy olyan problémákat is hatékonyan megoldjunk, amelyekhez eddig nagyon komplex algoritmusok vagy emberi beavatkozás volt szükséges. A mesterságes intelligencia önmagában egy nagyon nagy és szerteágazó tudományág \cite{cousins-of-artificial-intelligence}. Ennek egy kis szeletét, a gépi tanulást használtuk mi fel.
A gépi tanulás témaköre olyan rendszerekkel foglalkozik, amelyek valamilyen bemenet (tapasztalat) alapján valamilyen belső tudást képes alkotni és felhasználni. Ezt a gyakorlatban úgy kell elképzenlni, hogy egy adott tanuló adat alapján egy meghatározott algoritmus szerint matematikai modellt építenek. Ezt a folyamatot leegyszerűsítve "tanulásnak" nevezzük. Ezt a modellt felhasználva a mesterséges intelligencia képes, eddig számára ismeretlen bemenetre is becsléseket alkotni és döntést hozni \cite{Goodfellow-et-al-2016}. Mindezt anélkül, hogy erre explicit programozva lenne.
A munkánk célja nem a mesterséges intelligencia modellek finomítása, testreszabása, hanem a madárhang azonosítás komplex feladatának minden egyes komponensét integráltan kezelő rendszer hatékony, felhő-natív megvalósítása. Egy adott hangminta felismerére a technológia mai állása szerint az egyik legelterjedtebb megoldás a gépi tanulási módszer alkalmazása, a mi munkánkban ezért megjelent a gépi tanulás is, mint felhasznált technológia. Ugyanakkor ezt a módszertant nem mi alkalmaztuk (nem mi alkottuk meg a modellt, nem mi tanítottuk be), hanem egy kollégánk által elért eredményekre támaszkodtunk \cite{kristofmsc}. A kollégánkkal egyeztetve, a már megvalósított modellből kiindulva (lásd a Classification Service és Model Service mikroszolgálatásokat \aref{fig:cloud-arch-redesigned} ábrán) mi készítettük az interfészeket, valamint megvalósítottuk a kapcsolatot a többi komponenssel. A fenti szempontok miatt ebben a részben nem fejtjük ki bővebben a mesterséges intelligencia tematikáját, az arra kíváncsi olvasó az ebben az alfejezetben hivatkozott publikációkban megfelelő mélységű referenciákat találhat.