40 lines
9.0 KiB
TeX
40 lines
9.0 KiB
TeX
% !TeX root = ../thesis.tex
|
|
\chapter{Cloud-native rendszerekről}
|
|
\label{sec:theory}
|
|
|
|
\section{Felhő}
|
|
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.
|
|
|
|
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:
|
|
\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 \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 \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. |