marci-dipterv-latex/src/content/overview.tex

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


% TODO: bevezetés

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

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

Általánosságban véve az informatikában akkor beszélhetünk felhő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}. Ebben a megközelítésben a környezet üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által fenntartott -- \gls{adatkozpont}ban foglal helyet.

A felhő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 felhő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}.

% TODO: Ide simán shameless módon betolhatom a részletesebb leírást, amit már hatszor leglalább leadtam.
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 úgynevezett \acrfull{saas} (Szoftver mint szolgáltatás), amely egy előre telepített szoftver eszközt biztosít a szolgáltató felhő 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 felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak \cite{cloudadpotation}.

Amellett, hogy a felhő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 felhő 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ég tekintetében 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ő alapú 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.

% TODO: Átírni OCI-re
\textit{Docker} használatakor az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Kezdetben ez a képfájl formátum a \textit{Docker} projekt által tervezett saját formátum volt. Később erre alapozva jött létre az \acrfull{oci} által készített \textit{Image Format Specification} (képfájl formátum specifikáció), amelyet a manapság használt szinte minden kontér futtató környezet támogat \cite{oci_format_docs}. Ennek köszönhetően a \textit{Docker} környezetben épített képfájlok használhatóak más alternatíváknál is, mint példáula \textit{Podman} \cite{podman_docs}.

Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépek képfájlaihoz képest kisebb méretűek. Építése során a kívánt szoftver komponenseket (lefordított bináris, scriptek program fájlok, könyvtárak stb.) egy kiinduló képfájlba másoljuk bele. Ez a kiinduló képfájl lehet egy üres környezet, de lehet valamilyen operációs rendszer disztribúció felhasználói módú program környezete. Olyan képfájlok is léteznek, amelyekbe egy adott futtatókörnyezet már előre telepítve van, így csak a kész programunkat kell a megfelelő helyre tenni. Futtatáskor a konténer futtató környezet ezeket a képfájlokat használja fel a konténer fájlrendszerének felépítéséhez, a benne található alkalmazás futtatásához \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ő platfrom 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 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) szerepek. 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. 

A klaszterünk felügyelete és kezelése az általa kiszolgált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával történik. Ezt az interfészt elérhetik a klaszterben futó szoftverek, de akár a klaszteren kívüli alkalmazások és azokon keresztül pedig a klaszter adminisztrátorai. 

Egy \textit{Kubernetes} környezetben, az \acrshort{api}-n keresztül különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezeket az objektumokat a \textit{Kubernetes} dekleratív módon kezeli. Azaz, az objektumok segítségével egy állapotot írhatunk le, amely a klaszter elvárt állapotát határozza meg. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani. 

Ezek az objektumok közül a legegyszerűbb példa 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 erőforrás névtereken, ilyen a hálózati vagy a folyamatok névtere. Azaz, az egy \textit{Pod}-on belül futó két konténer a megfelelő rendszerhívásokkal tájékozódhat a másik konténerben futó folyamatok létezéséről, illetve a hálózati kommunikációs erőforrásokat közösen használják.

A \textit{Podok} életciklusának (létrehozás, törlés) kezelésére a \textit{Deployment} objektum nyújt megoldást. A \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le: milyen \textit{Podból} mennyi példánynak kell futnia. 

Ezek mellett még rengeteg alkalmazás specifikus objektumot kezel a \textit{Kubernetes}. Sőt, mindemellett lehetőség van arra, hogy egyedi erőforrás objektumokat is definiáljunk, amelyekkel könnyedén bővíthetjük a klaszterünk funkcionalitását.


\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 \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 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 \acrshort{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 az alkalmazott programnyelv tekintetében is.

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

A felhő 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 felhő 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 felhő é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 beleértik \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 \enquote{\textit{Open Glossary of Edge Computing}}\footnote{\url{https://www.lfedge.org/openglossary/}} néven. 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} (Felhő 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 a hálózat logikai végpontjaiba, 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 nyújtott alkalmazásoknak és szolgáltatásoknak. [\dots]
	
	\item \textbf{Edge Cloud} (Perem felhő): felhő-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 felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhő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 és lehetővé teszik a felhő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 felhő és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve \enquote{közel} áll a \gls{vegeszkoz}höz.

Ez a fajta logikai \enquote{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 felhő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} \enquote{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 felhő közé.}
	\label{fig:overview_with_edge}
\end{figure}

Az egyik ilyen jelentős előny a késeltetés csökkentése. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mindaz, 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 internet 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{Felhő é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 \enquote{szimbiózisban} a peremhálózati rendszerekre, mint a felhő alapú 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 felhő alapú 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 kiszervezzünk a központi felhő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 adnak é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 javulá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 két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demonstrálható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}
\label{sec:frameworks}

Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati környezetben futtatni, érdemes egy már létező keretrendszert használni. Az ilyen keretrendszerek nagyban megkönnyítik a fejlesztést, hiszen az adott alkalmazási terület általánosan felmerülő problémáit és kérdéseit megoldják. Így az alkalmazás fejlesztőinek nem szükséges azzal foglalkozni, hogy pontosan hogy indul el az alkalmazásuk egyik vagy másik helyen, mert ezt elfedi előlük a keretrendszer.

Egy ilyen keretrendszernél szükség van arra, hogy lehetőséget biztosítson egyes alkalmazás komponenseket a peremhálózati adatközpontban futtatni, másokat pedig a központi felhőben. Biztosítson valamilyen beavatkozható logikát arra, hogy egy alkalmazás mely adatközpontban kerül futtatásra és fedje el az egyes futtató adatközpontok sajátosságait.

A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban 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 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): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért, illetve a konfiguráció kezeléséért.
	
	\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira, hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
	
	\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege): Ebben a rétegben található szolgáltatások felelnek a az információ külső szolgáltatásba való továbbításáért: a gyűjtött adatok feldolgozásáért, átalakításáért és továbbküldéséért. Az itt elhelyezkedő szolgáltatások \enquote{funkcionális csővezetéket} valósítanak meg. Ami azt jelenti, hogy minden feldolgozandó adat egy folyamatot indít el, amelynek során az funkciókon keresztül jut el végül a küldésig.
	
	\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege):  A rétegben elhelyezkedő szolgáltatások feladata a többi eszközzel, szenzorral való interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat, annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatásoknak a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra.
\end{itemize}

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

% TODO: Savazni

\subsection{Project EVE}

A \textit{Project EVE} célja egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása erősen kezdetleges.

A projekt tervezése során kiemelt figyelmet fordítottak a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben arra, hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek a rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.

Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszer képes egyszerre több backendhez csatlakozni egy időben. Ilyen backend lehet a felhőben vagy helyileg telepített. Egyszerre képes futtatni Kubernetes klaszterben lévő alkalmazásokat, virtuális gépeket és konténereket. 

A különböző backendek támogatása azzal jár, hogy ezeket egységes absztrakt interfészen keresztül kell tudnia kezelnie. Ennek az lehet a hátránya, hogy az elérhető funkcionalitások között a legkisebb közös halmazt szolgálja ki a felhasználó számára. A konkrét platformok egyéni előnyeinek kiaknázásra nem sok lehetőséget ad.

% TODO Savazni

\subsection{Akarino Edge Stack}

A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy specifikáció halmaz, amely igyekszik a peremhálózati rendszerek fejlesztése során gyakran felmerülő problémákra tervezési mintákat adni.

Ezek a specifikációk lefednek számos, a peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.

Lévén ezek csak specifikációk és tervrajzok, az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok között és ezeket ingyenesen elérthetjük.

% TODO Majd megemlíteni, hogy ezt is megnéztem esküTM

\subsection{KubeEdge}

A \textit{KubeEdge} egy \textit{Kubernetesre} épülő rendszer, amely kiterjeszti annak képességeit peremhálózati rendszerek kezelésével \cite{kubeedge_docs}. Így lehetővé teszi a konténerizált alkalmazások futtatását a peremhálózaton. 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. Illetve 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. Ahhoz, hogy ezt megoldja, a \textit{Kubernetes} klaszteren belül használt hálózati plugin segítségével kiterjeszti és összekapcsolja a \textit{Pod} hálózatot. 

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. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni \cite{kubeedge_crds}.

\subsection{\acrshort{aws} \acrshort{iot} Greengrass}

Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} egy az \textit{Amazon} által fejlesztett menedzselt (\acrshort{paas}) \acrshort{iot} platform. Segítségével a fejlesztés során lehetőség van az alkalmazáskomponensek helyi tesztelésére, valamint azok üzemeltetési folyamatainak felügyeletére is lehetőséget kínál. Az egyes telepített komponensek távoli frissítése is megoldott.

A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó szolgáltatások halmaza, a másik pedig a peremhálózati rendszerre telepíthető\footnote{Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} támogatja azt a megközelítést is ahol a peremhálózat maga a végeszközök rendszere. Ennek megfelelően a \enquote{kliens} alkalmazást oda is lehet telepíteni.} (itt átjáróként hivatkozott) \enquote{kliens} szoftver. Az \acrshort{iot} eszközök ezen az átjárón futó szoftverrel kommunikálnak. Az itt futó peremhálózati szolgáltatások pedig az interneten keresztül kommunikálnak az \acrshort{aws} felhőben futtatott többi komponenssel.

A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.

A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet.

\subsection{Azure \acrshort{iot} Edge}

Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen leírás csak a teljesebb kép bemutatását szolgálja.

Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget ad egyes eszközökön. 

A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface}, amely a rendszer távoli monitorozásáért és kezeléséért felel.

A rendszer üzembe helyezéséhez az \acrshort{iot} eszközökön kizárólag az \textit{Azure \acrshort{iot} Edge} csomag telepítése szükséges. Az eszköz regisztrálása után központilag van lehetőség alkalmazásmodulok telepítésére.

Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldásról van szó, viszont a belső működése a szolgáltatásnak zárt. Az árazás szintekbe van sorolva, az ingyenes szinten naponta csupán nyolcezer üzenetet lehet átvinni a felhőben futó rendszer és a peremen\footnote{A dolgozat értelmezésében a végeszközök.} található eszközök között.


\subsection{Kubernetes Federation}
% Nem erre való, de jó erre

A \textit{Kubernetes Federation} (Röviden \textit{KubeFed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon, ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}. 

Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klasztert. Ez lesz az irányító klaszter (nagyjából olyan szerepe van mint a mester node-nak a klaszteren belül). Ehhez csatlakozik be a többi klaszter. Az egyes federált funkcionalitások megvalósítására egyedi \acrshort{api} objektumokat hoz létre. Ilyen objektumokkal tudjuk kezelni egységesen a multiklaszter erőforrásokat \cite{kubefed_userguide}. 

Implementáció szempontjából a federáció vezérlőre telepít és futtat olyan szolgáltatásokat, amelyek hozzáférnek a \textit{Kubernetes} \acrshort{api} felületéhez, illetve a megfelelő proxykon keresztül a többi klaszter \acrshort{api} felületéhez is. Így képesek olvasni az ott meghatározott egyedi objektumokat és annak megfelelően a megfelelő klaszterekben natív objektumokat létrehozni.

Egy federált \textit{Kubernetes} környezetnek több felhasználása is lehet, de a felhasználási mintákban szinte alapvető, hogy az önálló klaszterek földrajzilag elhatárolva üzemelnek \cite{kubernetes_why_federation}. Ez megfeleltethető annak, ahogy a peremhálózati rendszerek és a felhő rendszerek is különállóan üzemelnek.

Bár egyértelműen látszik, hogy a \textit{KubeFed} elsősorban nem a peremhálózati rendszerek által nyújtott elvárások kielégítésre lett kifejlesztve, általános klaszter federációs megoldásként viszont képes arra, hogy az ezen a téren támasztott elvárásoknak is megfelel.

Népszerűségének köszönhetően sok dokumentáció, leírás és egyéb segítség létezik hozzá. Emellett erősen épít a \textit{Kubernetes} szolgáltatásaira és tervezési mintáira. Ezeknek köszönhetően az üzemeltetése viszonylag egyszerű a \textit{Kubernetes} klaszterek terén jártas üzemeltetők számára.


% TODO: Még lehetne írni jókat erről

\textbf{A feladatom megoldásához én ezt a keretrendszert választottam}, ennek okát \aref{sec:cloud_framework}.\ alfejezetben részletezem.