bugfixes

src/.kile/thesis.kilepr.gui

@@ -160,12 +160,12 @@ TextFolding=[]
 ViMarks=
 
 [view-settings,view=0,item:content/abstract.tex]
-CursorColumn=45
+CursorColumn=27
-CursorLine=37
+CursorLine=14
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]
-ViMarks=.,37,164,[,37,157,],37,164
+ViMarks=.,14,26,[,14,23,],14,26
 
 [view-settings,view=0,item:content/acknowledgement.tex]
 CursorColumn=0
@@ -200,12 +200,12 @@ TextFolding=[]
 ViMarks=.,3,171,[,3,167,],3,171
 
 [view-settings,view=0,item:content/introduction.tex]
-CursorColumn=126
+CursorColumn=488
-CursorLine=13
+CursorLine=9
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]
-ViMarks=.,13,125,[,13,57,],13,125
+ViMarks=.,9,481,[,9,481,],9,481
 
 [view-settings,view=0,item:content/preparation.tex]
 CursorColumn=61
@@ -216,12 +216,12 @@ TextFolding=[]
 ViMarks=.,123,551,[,123,542,],123,551
 
 [view-settings,view=0,item:content/results.tex]
-CursorColumn=19
+CursorColumn=575
-CursorLine=164
+CursorLine=118
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]
-ViMarks=.,140,74,[,140,62,],140,74
+ViMarks=.,118,574,[,118,554,],118,574
 
 [view-settings,view=0,item:content/theory.tex]
 CursorColumn=0

src/content/preparation.tex

@@ -121,14 +121,7 @@ Miután a Knative Autoscaler naplóállománya analizálásának igénye felmer
 
 A Knative Autoscaler a naplóbejegyzéseket json objektumként menti, melyből a Python képes dictionary objektumot készíteni. Amennyiben az adott bejegyzés ts mezője a mérés kezdési és befejezési ideje közé esik, akkor az msg mezőben lévő üzenet feldolgozásra kerül. Az üzenetben kulcs-érték párok vannak szóközzel elválasztva egymástól. A kulcs és az érték között egyenlőségjel van. Ezt egy reguláris kifejezéssel listává lehet konvertálni. Sajnos a Python reguláris kifejezés API-jában nincs arra lehetőség, hogy ilyen esetben dictionary objektumot adjon vissza, így azt kézzel kell konvertálni kihasználva azt, hogy az értékek mindig egy kulcs után következnek. Ezután a Podok száma, valamint a megfigyelt stabil konkurencia érték letárolható. Ennek folyamat\'at \aref{sec:log-analyze} f\"uggel\'ekben l\'atni.
 
-A feldolgozott adatokból a matplotlib Python könyvtár segítségével készíthető grafikon úgy, hogy az adatokat tartalmazó listát átadjuk a megfelelő függvény számára. A grafikon mentése egy másik függvényhívással lehetséges. Szintén külön függvényhívással lehet a grafikon címét, valamint a tengelyek feliratát elhelyezni a grafikonon. Egy ilyen m\'odon gener\'alt grafikon l\'athat\'o \aref{fig:jmeter-for-otodik-rps} \'abr\'an. A diagram c\'ime a m\'er\'est azonos\'itja, ugyanis ezen grafikonok c\'elja a m\'er\'esek eredm\'eny\'enek gyorsan \'altalam elemezhetőv\'e t\'etele volt.
+A feldolgozott adatokból a matplotlib Python könyvtár segítségével készíthető grafikon úgy, hogy az adatokat tartalmazó listát átadjuk a megfelelő függvény számára. A grafikon mentése egy másik függvényhívással lehetséges. Szintén külön függvényhívással lehet a grafikon címét, valamint a tengelyek feliratát elhelyezni a grafikonon.
-
-\begin{figure}[!ht]
-\centering
-\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-for-otodik-rps.png}
-\caption{Az eredm\'enyeket analiz\'al\'o Python program \'altal gener\'alt egyik diagram}
-\label{fig:jmeter-for-otodik-rps}
-\end{figure}
 
 A méréseket elvégző szkript kis módosításával elértem, hogy a mérési eredmények egy általam üzemeltett számítógépre töltődjenek fel archiválásra és az itt részletezett program által feldolgozásra. A feltöltés után a szkript meghívott egy ugyanezen a szerveren futó REST-es végpontot, amely hatására elindult az adatok feldolgozása. Maga a program egy Docker konténerben futott. A kód verziókövetésére Git-et használtam, amelynek előnye az volt, hogy minden alkalommal, mikor egy állapotát mentettem a kódnak, abból a Travis szolgáltatás automatikusan elkészítette a Docker Image-et, valamint feltöltötte a Docker Hub-ra. Így a fejlesztéstől a mérésig teljesen automatizált munkafolyamatot dolgoztam ki. Felmerült ötletként, hogy ezt a Knative rendszerbe telepítsem, viszont szerettem volna, ha a méréseket feldolgozó folyamat független a mért rendszertől és a lehető leglazábban kapcsolódik hozzá. Ez által a két rendszerben történő folyamatok, esetleges hibák nem hatnak ki a másik működésére. 
 

src/content/results.tex

@@ -4,7 +4,7 @@
 
 Mielőtt elkezdtem a Knative és Kubeless rendszerek mérését, annak érdekében, hogy a mérőeszközök, illetve a Knative-hoz készített függvények teljesítményét kimérjem, mindkét mérőeszközzel megmértem mindkét függvényt Docker konténerként indítva. Itt a függvények a harmadik, a Kubernetes klaszterbe be nem csatlakoztatott számítógépen futottak a függvények, a mérések pedig az Kubernetes Masteren futottak. Mind a négy mérés esetében a használt connection objektumok száma negyvenöt. 
 
-Az \ref{fig:docker-chart} ábrából látszik, hogy a várakozásokkal ellentétben a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként ötszáz kérés per másodperces korlátot. Erre a számra úgy jutottam, hogy a hey által használt connection objektumok számát egyre állítottam. Ez esetben a generált kérések száma másodpercenként 510 és 530 között ingadozott, viszont stabilan mindig 500 felett volt. A generált forgalom stabilizálása érdekében az 500-nál húztam meg a határt, melynek szükségességét a korábbi tapasztalatok alapján éreztem, ugyanis a hey teljesítménye megfigyeléseim szerint instabil, mikor nagy sebességgel kell generálja a kéréseket. Továbbá, úgy ítéltem, hogy két különbözően viselkedő mérőeszköz többet fed fel a skálázódási mechanizmusokról. 
+Az \ref{fig:docker-chart} ábrából látszik, hogy a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként ötszáz kérés per másodperces korlátot. Erre a számra úgy jutottam, hogy a hey által használt connection objektumok számát egyre állítottam. Ez esetben a generált kérések száma másodpercenként 510 és 530 között ingadozott, viszont stabilan mindig 500 felett volt. A generált forgalom stabilizálása érdekében az 500-nál húztam meg a határt, melynek szükségességét a korábbi tapasztalatok alapján éreztem, ugyanis a hey teljesítménye megfigyeléseim szerint instabil, mikor nagy sebességgel kell generálja a kéréseket. Ha ezt nem l\'eptem meg, a hey sz\'azhatvanezer k\'er\'est volt k\'epes gener\'alni m\'asodpercenk\'ent. Ezek mellett, úgy ítéltem, hogy két különbözően viselkedő mérőeszköz többet fed fel a skálázódási mechanizmusokról. 
 
 \begin{figure}[!ht]
 \centering
@@ -15,7 +15,7 @@ Az \ref{fig:docker-chart} ábrából látszik, hogy a várakozásokkal ellentét
 
 Az ábráról szintén látszik, hogy a prím számoló függvény teljesítménye alulmarad a kis számításigényű függvényhez képest. Ez az előzetes várakozások szerint alakult. Mivel a Kubeless egy teljes Function as a Service rendszer, az oda telep\'it\'esre sz\'ant f\"uggv\'enyeket csak a rendszerbe telep\'itve lehet futtatni.
 
-Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem. 
+Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb, valamint teljes\'itm\'enye \'ujb\'ol felűlm\'ulja a limit\'alt hey-\'et. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem. 
 
 \section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa egyenletes terhel\'es alatt}
 
@@ -116,7 +116,7 @@ Ahogy \aref{fig:kubeless-isprime} ábrán látszik, a Kubeless skálázódása t
 \label{fig:kubeless-isprime}
 \end{figure}
 
-Sajnos, a Kubeless esetében többször előfordult, hogy csak egy Podot hozott létre az egész mérés során. Ez nem függött attól, hogy mennyi ideig tartott a mérés. Miután véget ért a terhelés, rövid időn belül létre jött a következő Pod. Ennek okát próbáltam kideríteni, egyik hipotézisem az volt, hogy nincs elég cpu ideje a számítógépnek létrehozni a Podot, de ezt kézi megfigyeléseim során elvetettem. Másik probléma a Kubeless esetében, hogy az Nginx Ingress Controller minden beérkező kérésről naplóbejegyzést ír. Ennek következményeképp a Podja Evicted \'allapotba ker\"ul, mert túl sok tárterületet használ. A degrad\'al\'odott teljes\'itm\'eny, melyet ez esetben lehetett tapasztalni, \aref{fig:jmeter-kubeless-hello-hatodik-rps-chart} \'abr\'an l\'athat\'o.
+Sajnos, a Kubeless esetében többször előfordult, hogy csak egy Podot hozott létre az egész mérés során. Ez nem függött attól, hogy mennyi ideig tartott a mérés. Miután véget ért a terhelés, rövid időn belül létre jött a következő Pod. Ennek okát próbáltam kideríteni, egyik hipotézisem az volt, hogy nincs elég cpu ideje a számítógépnek létrehozni a Podot, de ezt kézi megfigyeléseim során elvetettem. Másik probléma a Kubeless esetében, hogy az Nginx Ingress Controller minden beérkező kérésről naplóbejegyzést ír. Ennek következményeképp a Podja Evicted \'allapotba ker\"ul, mert túl sok tárterületet használ. Az Evicted \'allapot azt jelenti, hogy az adott Pod t\'ul sok erőforr\'ast haszn\'alt, ami miatt a Kubernetes rendszer le\'all\'itotta. A degrad\'al\'odott teljes\'itm\'eny, melyet ez esetben lehetett tapasztalni, \aref{fig:jmeter-kubeless-hello-hatodik-rps-chart} \'abr\'an l\'athat\'o.
 
 \begin{figure}[!ht]
 \centering
@@ -125,7 +125,7 @@ Sajnos, a Kubeless esetében többször előfordult, hogy csak egy Podot hozott
 \label{fig:jmeter-kubeless-hello-hatodik-rps-chart}
 \end{figure}
 
-Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek evicted állapotba, hanem akár a network plugin által használt Pod, hiszen a monitorozó rendszer minden Podtól lekérdezi az adatait, valamint a Kubernetes minden Podot evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, json formátumban naplózzon, hanem például használja a gazda gép journald rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes worker node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott Node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a Node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a Node-on lévő Podok kerülhetnek evicted állapotba, a Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás Node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
+Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek Evicted állapotba, hanem akár a network plugin által használt Pod, hiszen a monitorozó rendszer minden Podtól lekérdezi az adatait, valamint a Kubernetes minden Podot Evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, json formátumban naplózzon, hanem például használja a gazda gép journald rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes worker node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott Node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a Node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a Node-on lévő Podok kerülhetnek Evicted állapotba, a Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás Node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
 
 Annak érdekében, hogy a Knative-ba telepített függvények skálázódása az általuk nyújtott teljesítményben is meglátszódjon, szerettem volna limitálni egy-egy Pod teljesítményét. Erre viszont a Knative által létrehozott objektum típusok esetében nincs lehetőség. Emiatt úgy döntöttem, hogy a Knative által létrehozott Kubernetes Deployment objektumot módosítom, ott hozom létre a limiteket. Ez sikerült is, a függvény működött tovább, a megadott korlátozások érvénybe léptek. Viszont az elvárások nem teljesültek, a Podok létrejöttével nem emelkedett meg a függvény teljesítménye. A lenti diagrammon látszik, hogy a függvény végig ezer kérést volt képes kiszolgálni másodpercenként. 
 

src/thesis.tex

@@ -10,7 +10,7 @@
 \newcommand{\vikszerzoVezeteknev}{Torma}
 \newcommand{\vikszerzoKeresztnev}{Krist\'of}
 
-\newcommand{\vikkonzulensAMegszolitas}{dr.~}
+\newcommand{\vikkonzulensAMegszolitas}{Dr.~}
 \newcommand{\vikkonzulensAVezeteknev}{Maliosz}
 \newcommand{\vikkonzulensAKeresztnev}{Markosz}