minor modifications

src/content/abstract.tex

@@ -14,7 +14,9 @@ Fennáll viszont a probléma, hogy az egyes részek akkor is készen állnak ké
 
 A Knative ezeket a problémákat aldja meg. Lehetővé teszi az egyes részegységek nullára skálázását, valamint képesek szolgáltatások gyors skálázására a megjelenő konkurens kérésekkel arányosan. 
 
-A szakdolgozat keretein belül a Knative ezen funkciójának működését vizsgálom, összevetve viselkedését a Kubernetes rendszerben elérhető tradicionális megoldással, valamint ezen vizsg\'alattal kapcsolatos munkafolyamatokat automazi\'alom.
+A szakdolgozat keretein belül a Knative ezen funkciójának működését vizsgálom. Ehhez kidolgoztam m\'er\'eseket, melyek betekint\'est ny\'ujtanak a rendszer belső műk\"od\'es\'ebe. Feladatom r\'eszek\'ent a kidolgozott m\'er\'eseket, valamint azok eredm\'enyeinek al\'izis\'et automatiz\'altam, ami felgyors\'itja az eredm\'enyek \'ertelmez\'es\'et.
+
+Dolgozatom kifejezetten hasznos lehet azoknak, akik d\"onteni pr\'ob\'alnak a Knative haszn\'alata mellett, vagy meg szeretn\'ek tudni, hogy műk\"odik ez a rendszer.
 
 \vfill
 \selectenglish
@@ -31,7 +33,9 @@ However, these functions are ready to accept requests even when they are not nee
 
 Knative gives an answer to these problems. It is able to scale application components to zero and scale them quickly proportional to the number of concurrent requests.
 
-In my thesis I analyze these functions of Knative and compare them to traditional scaling available in Kubernetes as well as automate workflows relating to this analysis.
+In my thesis I analyze these functions of Knative and compare them to traditional scaling available in Kubernetes. To do this I devised measurements which provide an insight into the inner workings of Knative. As part of my assignment I automated these measurements and their analysis thereby speeding up interpretation of results.
+
+My thesis may be especially useful for those trying to decide whether to use Knative or not or to those trying to gain an insight into the inner workings of Knative.
 
 \vfill
 \selectthesislanguage

src/content/preparation.tex

@@ -121,7 +121,14 @@ 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. 
+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.
+
+\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

@@ -1,4 +1,7 @@
 \chapter{M\'er\'esi eredm\'enyek ismertet\'ese}
+
+\section{Elk\'esz\'itett f\"uggv\'enyek teljes\'itm\'eny\'enek m\'er\'ese Dockerben telep\'itve}
+
 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. 
@@ -14,6 +17,8 @@ Az ábráról szintén látszik, hogy a prím számoló függvény teljesítmén
 
 É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. 
 
+\section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa egyenletes terhel\'es alatt}
+
 Az \ref{fig:jmeter-for-otodik-chart} \'es \aref{fig:knative-for-negyedik-chart} ábrákon látható a Knative-ba telepített echo típusú függvény skálázódása. A kettő közül először az alsó mérést végeztem el, ahol a hey instabil viselkedése szintén megfigyelhető. A mérés körülbelül felénél látható megemelkedett ráta konzisztensen megismételhető volt több, független Kubernetes klaszteren is. Az ábrák elején jól megfigyelhető a Knative pánik skálázása, amely gyorsan létrehoz öt Podot, majd a hatvan másodperces panic windows lejárta után a már nem szükséges podokat leállítja. Az ezután a Podok számában megfigyelhető hiszterézis a Jmeteres ábrán és egyéb Jmeteres mérések során nem volt tapasztalható. Ez betudható annak, hogy az ObservedStableConcurrency érték a döntési határértéken van. Szintén megfigyelhető, hogy a Podok kiszámításának korábban ismertetett formulája úgy tűnik nem volt helyes. Ez nem helyes következtetés, ugyanis a hey ábrán látható három, valamint a Jmeter ábrán látható kettő kiszámított Podszámhoz hozzáadódik az egy mindig létező Pod. Az ObservedStableConcurrency érték esése a Jmeter ábra esetén is látható, amire a Podok számának csökkentésével reagál a rendszer. Érdekes, hogy itt mind a Podok száma, mint az ObservedStableConcurrency sokkal stabilabbak, cserébe alacsonyabbak. Szintén különbség, hogy a hey esetében a mérés elején tapasztalható alacsony teljesítményű időszak időben hasonló, viszont nincs benne ugrás. Mindkét ábrán látszik, hogy az ObservedStableConcurrency érték mozgó átlag, emiatt lassan változik. Ennek következménye, hogy a terhelés megszűnése után nem szűnnek meg a létrehozott Podok. 
 
 \begin{figure}[!ht]
@@ -48,6 +53,8 @@ Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-
 \label{fig:jmeter-hatodik-py-chart}
 \end{figure}
 
+\section{F\"uggv\'enyek v\'alaszidej\'enek alakul\'asa cold \'es hotstart esetekben}
+
 Ez ut\'an m\'ertem ki, mennyi a k\"ul\"onbs\'eg a f\"uggv\'eny v\'alaszidej\'eben az esetben, hogy null\'ara van sk\'al\'azva, vagy sem. A tapasztalat az volt, hogy 2-3 m\'asodpercig tart a Pod l\'etrehoz\'asa, a v\'alaszidő ennyivel n\"ovekedett meg az echo t\'ipus\'u f\"uggv\'eny eset\'eben. A bevezetett, nagyobb sz\'am\'it\'asig\'enyű f\"uggv\'eny e m\'er\'es sor\'an hasonl\'oan viselkedett, viszont \'atlagosan egy m\'asodperccel tov\'abb tartott a Pod indul\'asa. Ez az\'ert \'erdekes, mert a k\'et f\"uggv\'eny m\'asik futtat\'ok\"ornyezettel rendelkezik, tipikusan a Python interpreter  elind\'it\'asa 1-2 m\'asodpercet vesz ig\'enybe, ez megmagyar\'azza, mi\'ert tapasztalhat\'o ez a k\"ul\"onbs\'eg - amely j\'ol megfigyelhető \aref{fig:go-start-chart} \'es \aref{fig:py-start-chart} \'abr\'akon - a k\'et f\"uggv\'eny k\"oz\"ott.
 
 Az \ref{fig:go-start-chart} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'eny v\'alaszidej\'enek alakul\'asa. A m\'er\'est k\"or\"ulbel\"ul tizenk\'et \'or\'aig futtattam. Ezen \'es \aref{fig:py-start-chart} \'abr\'an megfigyelhető, hogy a v\'alaszidő Hotstart, azaz l\'etező Pod eset\'eben sokkal stabilabb, mint Coldstart, azaz nem l\'etező Pod eset\'eben.
@@ -67,6 +74,8 @@ Az \ref{fig:go-start-chart} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'en
 \label{fig:py-start-chart}
 \end{figure}
 
+\section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa n\"ovekedő terhel\'es alatt}
+
 Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum használta által értem el. Jól látszik, hogy az ObservedStableConcurrency egy lassan változó érték, a mérés végére töredékét érte el annak az értéknek, amit az egyenletes terhelésű mérések során elért. Szintén látható a Podok számából, hogy pánik állapotot sem váltott ki a mérés. Erre nem is lehetett számítani, hiszen a használt konkurencia érték sosem növekedett duplájára hat másodperces időtartam alatt.  
 
 \begin{figure}[!ht]
@@ -85,6 +94,8 @@ A korábbi mérések alapján számítottam rá, hogy a prímszámoló függvén
 \label{fig:hatodik-isprime-knative-climb-chart}
 \end{figure}
 
+\section{Istio \'es Nginx Ingress Controllerek \"osszehasonl\'it\'asa}
+
 Mivel a Knative és Kubeless rendszerek másik Ingress Controllert használtak, szerettem volna kimérni ezek áteresztőképességét is. Ezt úgy vittem véghez, hogy a mérőeszközzel mindkét Ingress Controller végpontját megcéloztam, mint ahogyan azt a függvények teljesítményének mérésénél is tettem, viszont ez esetben általuk nem ismert hosztnév fejlécet adtam meg. Ez által minden kérésre 404-es http kóddal válaszoltak. Az \ref{fig:istio-nginx-chart} ábrákon látható teljesítmény az adott Ingress Controllerek által elérhető legjobb teljesítmény. A Kubeless által használt Nginx Ingress Controller teljesítménye majdnem négyszeresen meghaladja a Knative által használt Isitio. 
 
 \begin{figure}[!ht]
@@ -94,6 +105,8 @@ Mivel a Knative és Kubeless rendszerek másik Ingress Controllert használtak,
 \label{fig:istio-nginx-chart}
 \end{figure}
 
+\section{Kubeless rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa}
+
 Ahogy \aref{fig:kubeless-isprime} ábrán látszik, a Kubeless skálázódása teljesen máshogy működik. Ez esetben a kötelezően meghatározott cpu használati limit miatt a skálázódáson a teljesítményben is érzékelhető a több Pod használata. Szintén látszik, hogy a csúcsteljesítmény, amit elért magasabb, mint a Knative esetében. Cserébe, viszont a skálázódás lassabb, a Horizontal Pod Autoscaler hatvan másodperces átlagolása miatt. 
 
 \begin{figure}[!ht]
@@ -125,6 +138,8 @@ Korábbi mérések során a prímszámoló függvény egy Python folyamatot hasz
 \label{fig:jmeter-pillanat-junky-chart}
 \end{figure}
 
+\section{Knative belső \'allapotainak vizsg\'alata monitoring rendszerekkel}
+
 Kíváncsi voltam, egyes mérések során milyen belső állapotai vannak a Knative egyes alegységeinek. Azért, hogy ezeket megfigyelhessem, telepítettem a Knative Monitoring egységét. Ez után újra elvégeztem bizonyos méréseket. Először a prímszámoló függvény viselkedését vizsgáltam meg. Érdekes, hogy a Workeren elérhető húsz magból összesen hetet sem használnak.
 
 Az \ref{fig:grafana-isprime-controllvsdata} ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata hogyan alakul egymáshoz képest.  Érdekes, hogy együtt is csupán körülbelül tíz processzormagot használnak. A Control Plane az ábrán a Knative Serving egyes komponenseit, az Istio-t, a monitoring eszközöket és a Kubernetes beépített részeit jelenti. A lenti ábrán látható ezen komponensek között miként oszlik el a processzorhasználat.