% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Áttekintés a perem és \gls{felho} rendszerekről}
%----------------------------------------------------------------------------


% TODO: bevezetés

\section{Klasszikus \gls{felho}s megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
\label{sec:tradicionalis_megkozelites}

\subsection{Általánosságban a \gls{felho}ről}

Általánosságban véve az informatikában akkor beszélhetünk \gls{felho}ről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. A tradicionális megközelítés szerint ezek a környezetek az üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által üzemeltetett -- \gls{adatkozpont}ban foglal helyet.

A \gls{felho}szolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
általános hardverelemek használatára visszavezethető alacsonyabb beruházási költség és az automatizált
folyamatok biztosította alacsonyabb üzemeltetési költség\cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.

Gyakran a \gls{felho}szolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.

A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgy nevezett \acrfull{saas} (Szoftver mint szolgáltatás) amely egy előre telepített szoftver eszközt biztosít a szolgáltató \gls{felho} környezetében amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.

Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a \gls{felho} szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen \gls{felho} környezetben futnak\cite{cloudadpotation}.

Amellett, hogy az \gls{felho}szolgáltatások adaptációja növekvő tendenciát mutat. Az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása\cite{iotadpotation}.

Ezek alapján a \gls{felho} szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.


\subsection{Felhős alkalmazásüzemeltetési eszközök}

\subsubsection{Alkalmazás Konténer}

Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalmazza a futtatni kívánt alkalmazást és a futtatásához szükséges szoftver környezetet. A konténerek használata jelentősen megkönnyíti és meggyorsítja az alkalmazás fejlesztési és telepítési ciklust. Mivel magába foglalja a teljes környezetet, amely szükséges a futtatáshoz, így a szoftver  ugyanúgy fut a fejlesztők számítógépein, a tesztkörnyezetben és az éles környezetben is \cite{application_containers}.

Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.

Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.

\subsubsection{Kubernetes}

Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások\cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.

Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával.\cite{kubernetes_docs}

Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.

A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért. 

Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel le írhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.

Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.

\subsubsection{Mikroszolgáltatások}

A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással\cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető

Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.

Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.

A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár a különböző programnyelvekkel is.


\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
\label{sec:peremhalozati_rendszerek}

A \gls{felho}-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a \gls{felho}szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.7\textwidth]{figures/overview_no_edge.pdf}
	\caption{A hagyományos megközelítésben a \gls{vegeszkoz}ök közvetlenül az \gls{adatkozpont}okkal kommunikálnak}
	\label{fig:overview_no_edge}
\end{figure}


A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alkalmazása. A következőkben ismertetésre kerül a rendszer működése, elméleti felépítése és gyakorlati alkalmazása.


\subsection{Használt fogalmak}

A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a \gls{felho} és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}

A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}. 

A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
\begin{itemize}
	\item \textbf{Cloud Computing} (\Gls{felho} számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
	
	\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végleteibe, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
	
	\item \textbf{Edge Cloud} (Perem \gls{felho}): \Gls{felho}-szerű képességek az infrastruktúra peremén amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus \gls{felho} kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-\gls{felho}ként hivatkoznak rá.
	
	\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
	
	\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a \gls{felho}szerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
	
\end{itemize}

\textbf{A dolgozat további részeiben ezek a fogalmak a mérvadóak} (kivéve ahol ez külön jelölve van).

\subsection{Architekturális előnyök} % TODO: cite

Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a \gls{felho} és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve "közel" áll a \gls{vegeszkoz}höz.

Ezt a fajta logikai "közelség" úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a \gls{felho}ig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} "közelebb" helyezése a végeszközökhöz számos előnnyel jár. 

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.7\textwidth]{figures/overview_with_edge.pdf}
	\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a \gls{vegeszkoz} és a központi \gls{felho} közé.}
	\label{fig:overview_with_edge}
\end{figure}

Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak\cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.

Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek\cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.

% TODO: privacy

% Villany használat
% Privacy/Security


\section{\Gls{felho} és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók

Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.

% Itt le kell írni hogy van ez a két dolog
Egy ilyen "szimbiózisban" a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk\cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek kiegészítik a \gls{felho}s alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.

A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi \gls{felho}ből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében ad értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.


\section{Gyakorlati alkalmazás}
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban. 

Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek\cite{liu2019edge}, ipari rendszerek távfelügyelete\cite{hao2020cloud}, betegfelügyelet\cite{wang2020secure}, felhő alapú játék szolgáltatások\cite{edge_gaming}, okos otthonok és városok\cite{shi2016edge} és még sok minden más területen\cite{edge_companies}.

A dolgozatom részeként a \gls{felho} és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a  \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.

\section{Alkalmazás futtatási és fejlesztési keretrendszerek}

% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia

A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban részletezem

\subsection{EdgeX Foundry}

Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek\cite{edgexfoundry_docs}.

A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy akár az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.

A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
\begin{itemize}
	\item \textit{Core Services Layer} (Központi szolgáltatások rétege):
	\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege):
	\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege):
	\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege):
\end{itemize}

Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.

\subsection{Project EVE}

\subsection{Akarino Edge Stack}

\subsection{StarlingX}

\subsection{KubeEdge}

A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit, hogy konténerizált alkalmazásokat peremhálózati rendszerek kezelésével\cite{kubeedge_docs}. Architektúrája két részből épül fel, a központi felhőből és a peremhálózatól.

A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.

A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel.

Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel.

Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével.

\subsection{AWS IoT Greengrass}

\subsection{Azure IoT Edge}