tormakris
/
birbnetes-tdk-latex
1
0
Fork 0
Code Releases 2 Activity

overleaf edits
continuous-integration/drone/push Build is passing Details
continuous-integration/drone/tag Build is failing Details

This commit is contained in:
Torma Kristóf 2020-10-28 10:46:16 +01:00
parent 9f5aface07
commit fe30555762
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
13 changed files with 515 additions and 195 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

130
src/bib/mybib.bib
View File

@ -5,12 +5,120 @@
title = {Comparing Virtual Machines vs Docker Containers}
}
@INPROCEEDINGS{8875447, author={H. {Chen} and F. J. {Lin}}, booktitle={2019 International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData)}, title={Scalable IoT/M2M Platforms Based on Kubernetes-Enabled NFV MANO Architecture}, year={2019}, volume={}, number={}, pages={1106-1111}, doi={10.1109/iThings/GreenCom/CPSCom/SmartData.2019.00188}}
@article{doi:10.1002/wsb.529,
author = {Mahjoub, Ghazi and Hinders, Mark K. and Swaddle, John P.},
title = {Using a “sonic net” to deter pest bird species: Excluding European starlings from food sources by disrupting their acoustic communication},
journal = {Wildlife Society Bulletin},
volume = {39},
number = {2},
pages = {326-333},
keywords = {acoustic masking, alarm call, bird strike, deterrent, noise pollution, parametric array, predation risk, starling, Sturnus vulgaris},
doi = {10.1002/wsb.529},
url = {https://wildlife.onlinelibrary.wiley.com/doi/abs/10.1002/wsb.529},
eprint = {https://wildlife.onlinelibrary.wiley.com/doi/pdf/10.1002/wsb.529},
abstract = {ABSTRACT Pest avian wildlife is responsible for substantial economic damage every year in the United States. Previous technologies used to deter starlings have generally failed because birds quickly habituate to startle regimes. In this study, conducted from May to July 2013, we focused on altering the foraging behavior of the European starling (Sturnus vulgaris), a pest bird that is responsible for crop losses and also poses notable risk for bird–aircraft strikes. The goal of our project was to develop an effective system to limit starlings' use of a food patch. Using nonlinear ultrasonic parametric arrays, we broadcast a directional sound that overlapped in frequency with starling vocalizations and was contained in a specific area, creating a “net.” We hypothesized that the “sonic net” would disturb acoustic communication for starlings, causing them to leave and feed elsewhere. Using wild-caught starlings in a large aviary, we deployed the sonic net over one food patch while leaving another food patch unaltered, and assessed their presence and feeding for three consecutive days. The sonic treatment decreased starlings' presence at the treated food patch, on average by 46\%. Additionally, we assessed whether the sonic net disrupted the birds' response to an alarm call. When under the sonic net, starlings did not respond to the alarm call, suggesting that the sonic net disrupted acoustic communication. The sonic net is a promising new method of decreasing foraging activity by pest bird species. © 2015 The Wildlife Society.},
year = {2015}
}
@inproceedings{10.1145/3341105.3373875,
author = {Grambow, Martin and Meusel, Lukas and Wittern, Erik and Bermbach, David},
title = {Benchmarking Microservice Performance: A Pattern-Based Approach},
year = {2020},
isbn = {9781450368667},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/3341105.3373875},
doi = {10.1145/3341105.3373875},
abstract = {Benchmarking microservices serves to understand and check their non-functional properties for relevant workloads and over time. Performing benchmarks, however, can be costly: each microservice requires the design and implementation of a benchmark, possibly repeatedly as the service evolves. As microservice APIs differ, benchmarking tools that assume common interfaces - like ones for databases - do not exist.In this work, we present a pattern-based approach to reduce the efforts for defining microservice benchmarks, while still allowing to measure qualities of complex interactions. It assumes that microservices expose a REST API, described in a machine-understandable way, and allows developers to model interaction patterns from abstract operations that can be mapped to that API. Possible data-dependencies between operations are resolved at runtime. We implement a prototype of our approach, which we use to demonstrate that it can be applied to open-source microservices with little effort. Our work shows that pattern-based benchmarking of microservices is feasible and opens up opportunities for microservice providers and tooling developers.},
booktitle = {Proceedings of the 35th Annual ACM Symposium on Applied Computing},
pages = {232–241},
numpages = {10},
location = {Brno, Czech Republic},
series = {SAC '20}
}
@INPROCEEDINGS{6449437, author={P. {Leitner} and C. {Inzinger} and W. {Hummer} and B. {Satzger} and S. {Dustdar}}, booktitle={2012 Fifth IEEE International Conference on Service-Oriented Computing and Applications (SOCA)}, title={Application-level performance monitoring of cloud services based on the complex event processing paradigm}, year={2012}, volume={}, number={}, pages={1-8}, doi={10.1109/SOCA.2012.6449437}}
@INPROCEEDINGS{7968049, author={C. M. {Aderaldo} and N. C. {Mendonça} and C. {Pahl} and P. {Jamshidi}}, booktitle={2017 IEEE/ACM 1st International Workshop on Establishing the Community-Wide Infrastructure for Architecture-Based Software Engineering (ECASE)}, title={Benchmark Requirements for Microservices Architecture Research}, year={2017}, volume={}, number={}, pages={8-13}, doi={10.1109/ECASE.2017.4}}
@INPROCEEDINGS{8486300, author={Y. {Niu} and F. {Liu} and Z. {Li}}, booktitle={IEEE INFOCOM 2018 - IEEE Conference on Computer Communications}, title={Load Balancing Across Microservices}, year={2018}, volume={}, number={}, pages={198-206}, doi={10.1109/INFOCOM.2018.8486300}}
@INPROCEEDINGS{7557535, author={S. {Hassan} and R. {Bahsoon}}, booktitle={2016 IEEE International Conference on Services Computing (SCC)}, title={Microservices and Their Design Trade-Offs: A Self-Adaptive Roadmap}, year={2016}, volume={}, number={}, pages={813-818}, doi={10.1109/SCC.2016.113}}
@INPROCEEDINGS{6778179, author={M. {Aazam} and I. {Khan} and A. A. {Alsaffar} and E. {Huh}}, booktitle={Proceedings of 2014 11th International Bhurban Conference on Applied Sciences Technology (IBCAST) Islamabad, Pakistan, 14th - 18th January, 2014}, title={Cloud of Things: Integrating Internet of Things and cloud computing and the issues involved}, year={2014}, volume={}, number={}, pages={414-419}, doi={10.1109/IBCAST.2014.6778179}}
@InProceedings{10.1007/978-3-319-29504-6_7,
author="Oweis, Nour E.
and Aracenay, Claudio
and George, Waseem
and Oweis, Mona
and Soori, Hussein
and Snasel, Vaclav",
editor="Abraham, Ajith
and Wegrzyn-Wolska, Katarzyna
and Hassanien, Aboul Ella
and Snasel, Vaclav
and Alimi, Adel M.",
title="Internet of Things: Overview, Sources, Applications and Challenges",
booktitle="Proceedings of the Second International Afro-European Conference for Industrial Advancement AECIA 2015",
year="2016",
publisher="Springer International Publishing",
address="Cham",
pages="57--67",
abstract="Nowadays, Internet of Things (IoT) is growing rapidly. Billions of devices are expected to be associated in the coming future. Smart and sensing devices have impacted the Big Data area through huge data generation and gathering during the communication between new physical object. The challenges in this communication process can be seen in the necessity to handle huge amount of data that can serve different purposes in various fields such as, medical, social, commercial, industrial and scientific fields. This study aims at presenting some of the most recent advances in IoT. We divided the study into four main parts: short history, Big Data concept, IoT sources (hardware and software), and finally some challenges and future expectations. The objective of the study is to give readers an updated description of the IoT and its impact on Big Data.",
isbn="978-3-319-29504-6"
}
@misc{docker-overview,
howpublished = {\url{https://docs.docker.com/engine/docker-overview/}},
note = {Megtekintve 2020-02-22},
title = {Docker overview}
}
@misc{pycurl-comparison,
howpublished = {\url{https://github.com/svanoort/python-client-benchmarks}},
note = {Megtekintve 2020-05-24},
title = {Microbenchmark of different python HTTP clients}
}
@INPROCEEDINGS{7321603, author={A. {Poniszewska-Maranda} and D. {Kaczmarek}}, booktitle={2015 Federated Conference on Computer Science and Information Systems (FedCSIS)}, title={Selected methods of artificial intelligence for Internet of Things conception}, year={2015}, volume={}, number={}, pages={1343-1348}, doi={10.15439/2015F161}}
@Article{Opara-Martins2016,
author={Opara-Martins, Justice
and Sahandi, Reza
and Tian, Feng},
title={Critical analysis of vendor lock-in and its impact on cloud computing migration: a business perspective},
journal={Journal of Cloud Computing},
year={2016},
month={Apr},
day={15},
volume={5},
number={1},
pages={4},
abstract={Vendor lock-in is a major barrier to the adoption of cloud computing, due to the lack of standardization. Current solutions and efforts tackling the vendor lock-in problem are predominantly technology-oriented. Limited studies exist to analyse and highlight the complexity of vendor lock-in problem in the cloud environment. Consequently, most customers are unaware of proprietary standards which inhibit interoperability and portability of applications when taking services from vendors. This paper provides a critical analysis of the vendor lock-in problem, from a business perspective. A survey based on qualitative and quantitative approaches conducted in this study has identified the main risk factors that give rise to lock-in situations. The analysis of our survey of 114 participants shows that, as computing resources migrate from on-premise to the cloud, the vendor lock-in problem is exacerbated. Furthermore, the findings exemplify the importance of interoperability, portability and standards in cloud computing. A number of strategies are proposed on how to avoid and mitigate lock-in risks when migrating to cloud computing. The strategies relate to contracts, selection of vendors that support standardised formats and protocols regarding standard data structures and APIs, developing awareness of commonalities and dependencies among cloud-based solutions. We strongly believe that the implementation of these strategies has a great potential to reduce the risks of vendor lock-in.},
issn={2192-113X},
doi={10.1186/s13677-016-0054-z},
url={https://doi.org/10.1186/s13677-016-0054-z}
}
@misc{iot-hub-azure,
howpublished = {\url{https://docs.microsoft.com/hu-hu/azure/iot-hub/about-iot-hub}},
note = {Megtekintve 2020-03-25},
title = {Mi az Azure IoT Hub?}
}
@misc{stream-hub-azure,
howpublished = {\url{https://docs.microsoft.com/hu-hu/azure/stream-analytics/stream-analytics-introduction}},
note = {Megtekintve 2020-03-25},
title = {Mi az az Azure Stream Analytics?}
}
@misc{linux-namespaces,
howpublished = {\url{http://man7.org/linux/man-pages/man7/namespaces.7.html}},
note = {Megtekintve 2020-02-20},
@ -30,6 +138,14 @@
title = {A microservice architekt{\'u}r{\'a}r{\'o}l di{\'o}h{\'e}jban}
}
@misc{kristofmsc,
author = {Nagy Krist{\'o}f},
howpublished = {\url{https://diplomaterv.vik.bme.hu/hu/Theses/Tomeges-gepgep-kommunikacio-mezogazdasagi}},
note = {MSc Diplomaterv, BME-VIK, 2020},
title = {Tömeges g{\'e}p-g{\'e}p kommunik{\'a}ci{\'o} mezőgazdas{\'a}gi alkalmaz{\'a}sa}
}
@misc{kubernetes-pods,
howpublished = {\url{https://kubernetes.io/docs/concepts/workloads/pods/pod/}},
note = {Megtekintve 2020-02-21},
@ -400,3 +516,17 @@
title = {Time series database (TSDB) explained}
}
@book{Goodfellow-et-al-2016,
title={Deep Learning},
author={Ian Goodfellow and Yoshua Bengio and Aaron Courville},
publisher={MIT Press},
note={\url{http://www.deeplearningbook.org}},
year={2016}
}
@misc{cousins-of-artificial-intelligence,
howpublished = {\url{https://towardsdatascience.com/cousins-of-artificial-intelligence-dda4edc27b55}},
note = {Megtekintve 2020-10-27},
title = {Cousins of Artificial Intelligence},
author = {Seema Singh}
}

2
src/content/abstract.tex
View File

@ -11,7 +11,7 @@
Napjainkban a mezőgazdaságban egyre elterjedtebbek a dolgok internetére (Internet of Things – IoT) épülő megoldások, ezek viszont nagy mennyiségű adatot generálnak, amelyek feldolgozása tradicionális rendszerekkel nehézkes. Erre a problémára tud megoldást nyújtani egy jól skálázódó felhő-natív adatfeldolgozó és elemző rendszer, amelynek tervezése és megvalósítása több kihívást is rejt magában.
Kártevő madarak hang alapján történő gyors és automatikus azonosítása fontos feladat, ugyanis például a seregélyek akár több tízmillió forint kárt is képesek okozni egy nagyobb szőlőbirtoknak. Dolgozatunkban seregélyek hang alapján történő azonosítása és riasztása a kitűzött cél, ezzel segítve a szőlősgazdákat.
Az ilyen rendszerek esetében fontos elvárás a közel valós idejű reakció, különben nem képes hatékonyan támogatni a megfigyelni vagy felügyelni kívánt folyamatokat. Ezért a rendszer komponenseinek telepítése és elhelyezése során biztosítani kell, hogy egy adatpont átfutási ideje és az egyes komponensek válaszideje is bizonyos keretek között maradjon. A rendszer tervezése során további lehetőségeket vetnek fel az az edge cloud megoldások.
Dolgozatunk keretein belül egy ilyen rendszer tervezését és fejlesztését mutatjuk be. Ehhez elkészítettem a rendszer architektúrájának tervét, a komponensek közötti interfészeket. A rendszer kidolgozása során számos általános problémát megoldó komponens készült el, valamint több, a seregélyek hangját felismerő elemet is felhasználtam. Ezen az elkészült rendszeren méréseket végeztünk, hogy annak változó méretű és jellegű terhelés alatti működését felmérjük. Az elvégzett méréseket és azok eredményeinek analízisét automatizáljuk, felgyorsítva ezek értelmezését.
Dolgozatunk keretein belül egy ilyen rendszer tervezését és fejlesztését mutatjuk be. Ehhez elkészítettük a rendszer architektúrájának tervét, a komponensek közötti interfészeket. A rendszer kidolgozása során számos általános problémát megoldó komponens készült el, valamint több, a seregélyek hangját felismerő elemet is felhasználtunk. Ezen az elkészült rendszeren méréseket végeztünk, hogy annak változó méretű és jellegű terhelés alatti működését felmérjük. Az elvégzett méréseket és azok eredményeinek analízisét automatizáljuk, felgyorsítva ezek értelmezését.
A tervezés és fejlesztés során cél kizárólag nyílt forráskódú és szabadon elérhető komponensek, valamint szolgáltatófüggetlen Kubernetes technológiák használata. Így a rendszer felhő szolgáltatók között gyorsan és könnyedén hordozható marad, de komolyabb nehézségek nélkül telepíthető saját Kubernetes fürtbe is.
\vfill

62
src/content/architecture.tex Normal file
View File

@ -0,0 +1,62 @@
\chapter{A madárhang azonosító és riasztó felhő-natív rendszer ismertetése}
A rendszer tervezését olyan alapvető felelősségekkel kezdtük, mint adatok fogadása, ezek tárolása, valamint továbbítása. A fejlesztési folyamat során ezektől haladtunk az egyre specifikusabbak fele, mint a mesterséges intelligencia által használt modellek tárolása és dinamikus frissítése. Ennek a folyamatnak eredményeképp készítettük el a \aref{fig:cloud-arch-redesigned} ábrán látható architektúrát. A rendszer minden komponense egy-egy mikroszolgáltatás. Ezt a tervezési folyamat egy korai lépésében döntöttük el. E döntés mögött két indokunk volt. Az első a fejlesztés során a kooperáció könnyebbsége, hiszen a mikroszolgáltatások interfészeinek egyeztetése után azok egymástól függetlenül fejleszthetők, ezzel a kooperációt is elősegítve. Emellett ettől a döntéstől azt vártuk, hogy amennyiben a rendszer tervezése során követjük a korábban leírt ajánlásokat, a komponensek skálázhatósága jobb lesz, így a nagyobb terhelés esetén nem lesz érzékelhető növekedés a válaszidőben. Ebben a fejezetben szeretnénk bemutatni a hasonló, már létező ilyen megoldásokat és az általunk tervezett architektúrát a beérkező adatok útját bejárva.
\section{Felhő-natív IoT rendszerek áttekintése}
Számos a piacon is elérhető felhő alapú IoT szolgáltatás érhető el. Ezek közül egy az Azure IoT Hub \cite{iot-hub-azure}, ami biztonságos kommunikációt biztosít az eszközök és a felhőben futó komponensek között. Ezek lehetnek saját fejlesztésű szoftverkomponensek vagy más Azure szolgáltatások, például Azure Stream Analytics \cite{stream-hub-azure}, ami adatfolyamok gyors feldolgozására képes szolgáltatás, de számos más lehetőség van. Gyakorlatilag minden népszerű publikus felhőszolgáltatónál léteznek hasonló tudású szolgáltatások, ezek működése is tipikusan igen hasonlít egymásra. Ilyen előre elkészített szolgáltatások használatának előnye, hogy a fejlesztői és az ehhez tartozó mérnöki munkát már elvégezték és a szolgáltatás teljesítményével szemben bizonyos garanciát is gyakran vállalnak.
Fontos figyelembe venni viszont azt is, hogy az ilyen szolgáltatások használata esetén gyakran igen nehéz szolgáltatók között mozogni, különböző szolgáltatóktól keverni szolgáltatásokat pedig ennél is nehezebb. Ezt a jelenséget, amikor a szolgáltató a saját termékcsaládjában próbálja tartani az előfizetőit vendor lock-innek hívjuk, ami az egyik legnagyobb visszatartó ereje a felhő alapú technológiák adopciójának az adatbiztonság és a kontroll elvesztése után \cite{Opara-Martins2016}.
Ezt elkerülhetjük nyílt forráskódú, valamint saját fejlesztésű komponensek használatával, viszont ennek a megközelítésnek hátránya, hogy a rendszert üzemeltetni, támogatni a fejlesztőnek kell. Egy ilyen nyílt forráskódú platform a Kubernetes is.
Kubernetes segítségével olyan IoT eszközöket támogató rendszerek \cite{8875447} készíthetők, amik tradicionális alkalmazásoknál jobban skálázódnak, költséghatékonyabbak. Mesterséges intelligencia alkalmazása egy ilyen rendszerben egy újszerű, érdekes probléma, aminek nem egyértelmű a megoldása. Dolgozatunkban erre teszünk kísérletet.
\section{Felhő-natív rendszerelemek ismertetése}
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/cloud-arch-redesigned.pdf}
\caption{A felhő-natív rendszer architektúrája}
\label{fig:cloud-arch-redesigned}
\end{figure}
A rendszerbe két típusú adat érkezhet. A kihelyezett eszközök által felvett hangadatok a felhő rendszerbe az Input Service-hez kerülnek be, ahol a beérkezett hangfájl és az azt kísérő üzenet formátumának validálása után az alapvető metaadatok – többek között a küldő eszköz azonosítója, beérkezés dátuma, valamint az egész felhő rendszerben használt egyedi azonosító – eltárolódnak. Ezt követően az állomány továbbításra kerül a Storage Service-nek, ahol egy objektumtárban kerül eltárolásra. Ez azért előnyös, mert ha egy mintát szeretnénk többször is feldolgozni, a feldolgozott mintákat meghallgatni validálás céljából, vagy az AI Service-ben használt modellt a rendszer felhasználója pontosítani szeretné a rendelkezésre álló valós mintákkal, akkor lehetőség van azt lekérni egyéb metaadatai mellett az egyedi azonosító segítségével. Erre viszont csak limitált ideig van lehetőség, ugyanis az eltárolt hangfájlok beállítható idő múlva – alapértelmezés szerint egy hét – törlésre kerülnek, hogy a beérkezett minták által elfoglalt lemezterületet kordában tartsuk. A fájl sikeres tárolását követően az Input Service egy üzenetsorra beküldi a minta azonosítóját, ezzel jelezve a feldolgozó komponensnek az új minta beérkezését és azt, hogy milyen azonosítót használhat a Storage Service-től lekérdezéskor.
Az üzenetsoron az AI Service példányai fogadják az üzenetet, ezen komponens felelőssége a minták klasszifikálása többek között seregély, traktor és egyéb zaj kategóriákba. Még mielőtt megkezdhetné a feldolgozást, a Model Service-nél ellenőrzi, hogy elérhető-e újabb modell, amivel dolgozni tud. A Model Service képes több különböző típusú – beleértve a felhő rendszerben és az IoT eszközön található mesterséges intelligenciák által használtakat – modellt tárolni, a modellek verzióját követni, valamint visszaadni REST API-n keresztül. Az éppen használt modell friss állapotának eldöntésére lekéri az alapértelmezett modell metaadatait, amiket összevet a lokálisan meglévő modell metaadataival. Amennyiben valóban elérhető újabb modell, letölti azt és onnan betölti további használatra. E mechanizmus által lehetőség van a rendszer által használt modellek dinamikus frissítésére és cseréjére, valamint a Model Service-ben az alapértelmezett modell korábbira visszaállításával akár korábbira visszatérés is könnyedén lehetséges. A modell ellenőrzése után az AI Service-ben található mesterséges intelligencia elvégzi a hangfájl klasszifikációját. Ennek eredményét a minta azonosítójával egyetemben egy másik üzenetsoron publikálja.
Az üzenetsorra érkező adatokat három mikroszolgáltatás fogadja, de az üzenetsornak hála újabb ilyen komponens illesztése a meglévő a rendszerhez könnyedén lehetséges. A Results Service feladata eltárolni minden egyes minta adatait úgy, hogy azok egyesével lekérdezhetők legyenek. Ennek a mikroszolgáltatásnak a segítségével lehetséges harmadik fél által gyártott szoftverekhez csatolni az általunk fejlesztett rendszert. A Metrics Service felelőssége idősoros adatbázisba illeszteni az eredményeket. Az idősor adatbázisból statisztikai lekérdezések segítségével betekintést nyerhetünk a szőlőben a seregélyek mozgásába, tendenciáiba akár egy harmadik fél által fejlesztett dashboarddal. Az utolsó mikroszolgáltatás, ami megkapja a klasszifikációk eredményeit a Guard Service. Ez a mikroszolgáltatás üzenetsoron küld egy riasztási parancsot annak az eszköznek, ahonnan seregélyként detektált minta érkezett.
Az egyes komponensek közötti kommunikáció alapvetően HTTP feletti REST API-k segítségével történik, kivéve az előzőekben említett helyeken, ahol üzenetsorral. Előbbit olyan esetekben alkalmaztuk, amikor az adott interfész külső alkalmazások felé elérhető, nagy mennyiségű adat átvitele történik, vagy fontos a szinkron kommunikáció. Jó példa a Storage Service interfésze, ugyanis itt fontos tudni, hogy mikor áll készen a mikroszolgáltatás a minta kiszolgálására, valamint egy tipikus JSON formátumú üzenethez képest nagy mennyiségű, bináris adat átvitelét jelenti. Természetesen üzenetsorra is megvalósítható lenne ez a viselkedés, viszont jelentősen bonyolultabb üzleti logikát igényelt volna a megvalósítás, jelentősebb előnyt viszont nem hozna.
Az egyes mikroszolgáltatások közötti üzenetsorok AMQP (Advanced Message Queuing Protocol) felett zajlanak. Emellett akkor döntöttünk, amikor több komponensnek is szüksége van egy művelet eredményére – mint például az AI Service kimenetére reagáló három mikroszolgáltatás –, vagy nem szükséges az adott üzenetre válasznak érkeznie. Ilyen az Input Service által az AI Service-nek küldött értesítés is.
Az interfészek és üzenetek tervezése során kiemelten figyeltünk arra, hogy minden üzenetsoron és REST API-n átvitt adat lehetőleg minél kisebb legyen, csak a szükséges adatok kerüljenek továbbításra. Ezzel is növelve a kommunikáció hatékonyságát és kihasználva a HTTP és üzenetsor előnyeit minimális többletköltség mellett.
A minták fogadásában nem vesz részt a Command and Control Service, felelőssége az egyes eszközök és azok szenzorainak állapot vezérlése, nyomon követése. A kihelyezett IoT eszközök az állapotukat üzenetsoron jelzik. Egy ilyen üzenet például lehet jelzés, hogy az eszköz valamilyen hibás állapotba került és javítást vagy cserét igényel, esetleg egy szenzorról nem képes adatot olvasni, kikapcsolni készül vagy épp most kapcsolt be. Egy másik üzenetsoron hallgatják a parancsokat és végrehajtják azokat. Ilyen parancs lehet a mesterséges intelligencia által használt modell frissítése és a szenzor vagy eszköz kikapcsolása. Az irányító üzenetek küldését REST API segítségével lehet kiváltani. A Command and Control Service indulásakor nem ismeri a rendszerben futó eszközöket, azokat az első üzenetük fogadásakor jegyzi fel egy saját relációs adatbázisba, ahol követi az állapotukat. Azokat az eszközöket, amik öt perce nem küldtek státusz üzenetet, a mikroszolgáltatás hibás állapotba lépteti a belső állapotreprezentációjában. Az egy hétnél tovább el nem érhető eszközöket automatikusan kikerülnek az adatbázisból kivéve, ha a felhasználó API hívás segítségével permanensnek nem jelölte azt.
Az eszközök és a felhőben lévő komponensek közti üzenetsoros kommunikáció MQTT (Message Queue Telemetry Transport) protokollon történik, ami mellett annak flexibilis téma (topic) architektúrája miatt döntöttünk. Lehetőség van az egyes üzenetsorok, vagy másnéven témák, struktúrálására és ezáltal egyszere több témára üzenet küldésére, valamint feliratkozásra. Ezt a Command and Control Service esetében ki is használtuk, ugyanis az egyszere iratkozik fel minden eszköz státuszüzeneteire, valamint a struktúrált témáknak köszönhetően minden vezérlőüzenetet csak a céleszköz kap meg, ami csökkenti a szükséges hálózati forgalmat és az eszközök által feldolgozandó üzenetek számát.
\section{Internet of Things eszköz ismertetése}
Az IoT eszköz architektúrájának tervezése során a legfontosabb szempont az új szenzorok bevezetése volt. Emiatt úgy döntöttünk, hogy az egyes szenzorokat teljesen külön kezeljük. Három alapvető lépést határoztunk meg egy mért adat útja során. Az első a szenzor általi mérés elvégzése, amit az opcionális előfeldolgozás követ. Végezetül, a szoftvernek döntést kell hoznia, hogy az eredményt tovább küldje-e felhőbe, majd a döntést végre is kell hajtsa.
Azért, hogy ez a folyamat minél flexibilisebb legyen, egy külön osztály fogja össze és indítja az egyes lépéseket, valamint a mintavételezéseket egy központi, belső óra vezérli.
Itt konkrét, hardveres implementációval nem foglalkoztunk, azt a szoftver tervezése és fejlesztése során elabsztracháltnak tekintettük.
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/cloud-arch-class.pdf}
\caption{Az IoT eszközön futó szoftver osztálydiagrammja}
\label{fig:cloud-arch-class}
\end{figure}
A felvázolt koncepciót a fenti osztálydiagramon valósítottuk meg. Új szenzor felvétele esetén az ISensor, IPreProcessor, ISender interfészek implementálásával és SignalProcessor osztályból leszármazással, valamint ezek az Application osztályba regisztrálásával lehetséges. Új riasztásra képes forgatókönyv esetében az IActuator interfész implementálásával van lehetőségünk a riasztás elvégzésére.
Az Application osztály tartalmazza az eszközök eseményhurkát, ami lehetővé teszi a szenzorok ismételt mintavételét, előfeldolgozását és a minta felhőbe küldését. Az általunk megvalósított viselkedés során egy ütemben a SoundProcessor vezényli a hangminták kezelését. Az ütem elején egy másodperc hosszú hangmintát vesz az előre bekonfigurált mikrofonról, amit egy mesterséges intelligencia bekategorizál többek között traktor, emberhang, méhek és madárcsicsergés kategóriákba. A madárcsiripelés kategóriába sorolt mintákat továbbítja a felhőbe a SoundSender, ahol az előbbiekben leírt folyamat kerül végrehajtásra. Ez a forgatókönyv \aref{fig:cloud-arch-sequence} ábrán látható. Minden harmadik ütem végén küld az eszköz státusz frissítést a felhőnek.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/cloud-arch-sequence.pdf}
\caption{Az IoT eszköz egy futásának szekvenciája}
\label{fig:cloud-arch-sequence}
\end{figure}
Az eszköz indulásakor az Application osztály a beállított üzenetsoron elküldi, hogy éppen bekapcsolt, hamarosan elkezd adatokat küldeni és képes parancsok végrehajtására. Utóbbi külön szálon történik, emiatt szükség volt a szenzorok offline és online állapotainak szálbiztos kezelésére a SignalProcessor leszármazottjaiban és az ezeket nyilvántartó listának is hasonlóan szálbiztosnak kell lennie. Az offline szenzorok forgatókönyve kikerül az ütemezett forgatókönyvek közül, viszont futó forgatókönyvet az alkalmazás nem szakít meg.

152
src/content/benchmarks.tex Normal file
View File

@ -0,0 +1,152 @@
% !TeX root = ../thesis.tex
\chapter{A rendszer teljesítménymérése}
Dolgozatunk e fejezetében bemutatunk egy olyan módszertant és eszközöket, amelyek segítségével egy komplex mikroszolgáltatásokból álló rendszerben megtalálhatók az esetleges gócpontok, valamint azok orvoslására javaslat tehető. Célunk egy olyan eljárás kidolgozása volt, amely a mikroszolgáltatás architektúrában fejlesztett szoftverek esetében gyakran előforduló szűk keresztmetszeteket a DevOps eszköztárával agilisan képes felderíteni és iteratívan javítani rajta. Emellett bemutatjuk az ennek kidolgozásához és ellenőrzéséhez felhasznált eszközöket is.
\section{Mérési környezet ismertetése}
A fejlesztés és teljesítménymérés idejére létrehoztunk egy Kubernetes klasztert, amiben futtattuk a rendszert. A klaszterben három Master és ugyanennyi Worker volt, mindegyik virtuális gépen futott, Microsoft Hyper-V hypervisorban. A Mastereknek kettő processzormagja és nyolc gigabájt memóriája volt, a Workereknek négy magot, valamint tizenhat gigabájt memóriát allokáltunk. A klaszter három fizikai gépen futott, mindegyikben Intel Xeon E5-2450L processzor, valamint 64 gigabájt memória volt. Egy Master és egy Worker példányt telepítettünk mindegyik fizikai gépre.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/cloud-arch-phys.pdf}
\caption{A felhő rendszer architektúrája}
\label{fig:cloud-arch-phys}
\end{figure}
A fizikai hosztgépek két egy gigabites Ethernet hálózaton kerültek összekötésre. Amint az \aref{fig:cloud-arch-phys} ábrán is látható, az egyik hálózaton a hypervisorok és a virtuális gépek az internetet érték el, ezt csak frissítések és csomagok letöltésére használtuk. Emellett egy fizikailag teljesen különálló hálózat állt a virtuális gépek rendelkezésére a klaszter forgalmának lebonyolítására.
Mivel a fürtnek számos tagja volt, telepítettünk egy külön fizikai gépre egy HAProxy HTTP és TCP terheléselosztót, ami a kéréseket roundrobin algoritmussal osztotta el az egyes node-ok között. Ennek segítségével volt elérhető az egyes mikroszolgáltatások API-ja és az MQTT broker az IoT eszközök számára. Ebben a fizikai gépben egy Intel Core i5 2550K és 16 gigabájt ram volt.
A Kubernetes klaszterben a Calico hálózati implementációt használtuk, ami nem hoz létre virtuális hálózatot a meglévő fölé, hanem az egyes alkalmazások és kompnensek között különálló IP alhálózatok és útvonalválasztás segítségével biztosítja a megfelelő izolációt. Emellett NGINX Ingress Controllert használtunk. Ez egy NGINX webszerver konfigurációjával realizálja az Ingress Controller funkcionalitását.
A mikroszolgáltatásokat kiszolgáló relációs adatbázisokat egy külön virtuális gépen futó PostgreSQL szolgálta ki, aminek 2 processzormagot és két gigabájt memóriát allokáltunk.
A méréseket futtató számítógépben egy Core i7 3770 és 16 gigabájt ram volt, valamint csatlakozott mind a publikus, mint a magánhálózatra.
\section{Mérőszoftver ismertetése}
Mint azt az előző fejezetben ismertettük a leghosszabb út, amit egy minta és az arra generált válasz megtehet, egy seregélyként kategorizált minta esetében fordul elő. Ebből következik, hogy egy kritikus mérés a beküldött HTTP kérések és az érkező MQTT üzenetek között eltelt idő lehet. Olyan kész mérőeszköz viszont, ami ennek a mérésére képes nem elérhető, ezért egy saját mérőeszköz fejlesztése mellett döntöttünk.
Annak érdekében, hogy a lehető leggyorsabban legyen képes a szoftver kéréseket generálni, indulás után először kigenerálja azok törzsét az Input Service elvárt sémában található eszközazonosító kitöltésével és a séma egyéb mezőit és a multipart kérés más részeit előre beállított sablont érintetlenül hagyásával. Parancssori paraméterként megadható a használni kívánt konkurenciaszám, ennyi külön folyamat fog futni. Az egyes folyamatok a következő lépésben egy saját listában nyilvántartják az aktuális rendszeridőt, elküldenek egy HTTP kérést az előre elkészítettek közül, majd egy másik listába is feljegyzik a rendszeridő aktuális értékét. Fontos kiemelni, hogy az egyes folyamatok minden kérés végéig blokkolnak, azaz megvárják, amíg megérkezik a válasz. Ezt a lépést addig ismétlik, amíg a mérést felügyelő folyamat – az előre beállított idő leteltével – le nem állítja őket. Ez alatt és után 600 másodpercig, szintén külön folyamatban, a szoftver fogadja az MQTT-n érkező üzeneteket és feljegyzi azok érkezési idejét egy listába.
Miután minden folyamat végzett, a különböző HTTP kéréseket generáló folyamatoktól lekérdezi a küldési és fogadási időpontokat tartalmazó listákat és egyesíti azokat egy-egy nagy listába, amik a kérések elküldése szerint kerülnek rendezésre. Ez úgy lehetséges, hogy a szoftver minden kéréshez rendel egy egyedi azonosítót, amit a listában az időbélyeg mellé csatol. Ugyanez teszi lehetővé az MQTT üzenetek HTTP kérésekhez párosítását, ugyanis a mérni kívánt rendszer a bemeneti API-ján elfogad egy egyedi azonosítót, amit felhasznál az MQTT téma összeállítása során. Amennyiben a mérések során minden esetben egyedi azonosítóval látunk el egy-egy kérést, azok végig egyértelműen azonosíthatók maradnak, lehetővé téve az egyes mérőkomponensek külön szálakra bontását.
\section{Mérőszoftver értékelése}
Amennyiben a mérőszoftver segítségével méréseket futtatnánk, a kapott eredmények csekély információt hordoznának egyéb adatok híján, ugyanis bizonytalan lenne, hogy a mérés a mért rendszer vagy a mérőeszköz legjobb teljesítményét mutatja, nem tudjuk melyik teljesítményét mértük ki. A mérőszoftvert Pythonban készítettük, ezért annak teljesítménye nem feltétlen haladja meg a mért rendszerét.
Ezt a problémát megoldandó elkészítettünk egy a rendszert imitáló webes alkalmazást. Az alkalmazást Kotlinban írtuk, amiben a korutinok segítségével könnyű aszinkron, nem blokkoló kód írása. Ennek köszönhetően az alkalmazás minden HTTP kérést aszinkron módon szolgál ki, ezzel emelve az alkalmazás áteresztőképességét. Amennyiben az alkalmazáshoz GET kérés érkezik, az egy nullás karakterrel tér vissza. Ezt a viselkedést a mérő alkalmazás működésének tesztelésére hoztuk létre. Ha az alkalmazáshoz POST kérés érkezik, ellenőrzi, hogy a kérés megfelel-e az Input Service által elvártaknak. Amennyiben nem, 500-as hibakóddal válaszol. Amennyiben a kérés átmegy a validáción, a kérés törzséből beolvassa az eszközt – vagy ez esetben a kérést – azonosító mező értékét és aszinkron módon küldd egy üzenetet az MQTT brókernek továbbításra a megfelelő témára, majd válaszol a kérésre egy húsz karakter hosszú karakterlánccal. Ez utóbbi célja, hogy a HTTP válasz mérete is nagyságrendileg akkora legyen, mint amekkorát az Input Service küldene. Ennek az alkalmazásnak teszteltük a teljesítményét referenciaként az Apache Benchmark (ab) eszközzel.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/softwarecomparison-benchmarks.png}
\caption{Mikroszolgáltatások késleltetésének összehasonlítása}
\label{fig:softwarecomparison-benchmarks}
\end{figure}
Az \aref{fig:softwarecomparison-benchmarks} ábrán is látható, hogy az ab (ab oszlop) és az általunk készített szoftver (BirbBench – requests oszlop) nagy a különbség teljesítmény téren. Ezt a különbséget nem tartottuk elfogadhatónak. A gyanú gyorsan az általunk használt Python HTTP kliensre, a requests-re terelődött, ugyanis az teljes egészében Pythonban készült, valamint a PyCurlhöz viszonyítva az összehasonlító teljesítménymérésekben \cite{pycurl-comparison} lemarad. Utóbbi egy vékony Python réteg a C-ben implementált libcurl felett. Valóban, a PyCurl használata esetén a mérőeszköz által mért áteresztőképesség jobban megközelítette az ab által elértet, de nem érte azt el, viszont ez nem volt célunk. Ezen mérések által van referenciánk arról, milyen karakterisztikákkal rendelkezik a mérőszoftverünk HTTP kliense.
Az MQTT komponens értékelése során is nem várt anomáliát figyeltünk meg. Amint az \aref{fig:mqtt-latency} ábrán megfigyelhető, az MQTT üzenetek késleltetési ideje a HTTP kérésekhez képest a mérés során szigorúan monoton növekedett, ami arra enged következtetni, hogy vagy a broker áteresztőképességénél nagyobb rátával küldi neki az üzeneteket a Kotlinos alkalmazás, vagy a kliens képes túl lassan fogadni az üzeneteket. Előbbire enged következtetni, hogy a broker folyamata a Workeren egy processzormagot teljesen kihasznál.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/mqtt-latency.png}
\caption{MQTT üzenetek késleltetése}
\label{fig:mqtt-latency}
\end{figure}
A fenti hipotézis ellenőrzésére elkészítettünk egy olyan Kotlin programot, ami letárolja az egy másodperc alatt érkezett üzeneteket, majd ezt összehasonlítottuk a Pythonban készült mérőszoftverrel. Az összehasonlítás során
Ezek alapján arra következtettünk , hogy az általunk használt Apache Artemis MQTT broker egy példányt használva a számunkra elérhető hardveren körülbelül száz egyedi témára érkező üzenetet képes továbbítani.
\section{Skálázódási lehetőségek felmérése}
Méréseinkkel a rendszer skálázhatóságát szerettük volna megvizsgálni, viszont ehhez tudnunk kellett, mely komponenseket érdemes skálázni, melyek azok a mikroszolgáltatások, amk egy adott kérést a legtovább dolgozzák fel, ezzel a rendszerben szűk keresztmetszetként viselkednek. Mivel a mikroszolgáltatásaink egy távoli Kubernetes klaszterben futnak a tradicionális, fejlesztői eszközökbe épített profilozó használata nem lehetséges. Ezt a problémát hivatottak megoldani az Alkalmazás Teljesítmény Monitorozó \cite{6449437} eszközök. Számos ilyen eszköz elérhető, mint például a Jaeger, vagy a mikroszolgáltatásokban keletkezett hibákat is gyűjteni képes Sentry. Ezek között a különbség tipikusan a támogatott nyelvek és a szerverben használt technológiákban rejlik, mindegyik képes egy megjelölt kódblokk futási idejét monitorozni. A projekt fejlesztése során Sentryt használtunk az elosztott hibakeresési képességei, valamint elsőrangú Python támogatása miatt.
Ezen vizsgálatok során a módszertanunk az volt, hogy a rendszerbe beküldtünk egyetlen mintát, valamint a korábban ismertetett mérőeszközzel generáltunk nagyobb terhelést a rendszerben, majd a Sentry által aggregált adatokat összevetettük és értkeltük. Minden mérést húsz alkalommal ismételtünk és az eredmények átlagát vettük annak érdekében, hogy egy-egy kiemelkedő mérés ne befolyásolja aránytalanul a kapott eredményeket.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/microservice-comparison.png}
\caption{Mikroszolgáltatások késleltetésének összehasonlítása}
\label{fig:microservice-comparison}
\end{figure}
Általánosan elmondható volt a tesztek alapján, hogy a hangmintákkal dolgozó, valamint mesterséges intelligenciát alkalmazó mikroszolgáltatások válaszideje nagyságrendekkel nagyobb, mint a csak szöveges adatokkal dolgozóké. Ennek oka valószínű az Input és a Storage mikroszolgáltatások esetében a HTTP kérések mérete lehet, a Classification Service-nél pedig a mesterséges intelligencia futási idejéből adódhat a magas átfutási idő. Ezt ellenőrizendő finomítottuk a használt tranzakciókat, hogy a kérdéses HTTP kérések során elvégzett műveletek ideje pontosan látszódjon.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/input-service-runtime.png}
\caption{Input Service futási idejének összetétele}
\label{fig:input-service-runtime}
\end{figure}
Ez alapján (ahogy az \aref{fig:input-service-runtime} ábrán is látható) megállapítható, hogy valóban a kérés fogadása, valamint a kezelése tart sokáig az Input Service-ben, az egyéb műveletek rövid idő alatt lezajlanak. Ennek okán az egyik skálázásra kijelölt komponenspár az Input és Storage Service-ek voltak.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/storage-service-runtime.png}
\caption{Storage Service futási idejének összetétele}
\label{fig:storage-service-runtime}
\end{figure}
Úgy döntöttünk ezeket közösen érdemes skálázni, hiszen a \aref{fig:input-service-runtime} ábrát összevetve a \aref{fig:storage-service-runtime} ábrával is megfigyelhető, hogy a Storage Service esetében a HTTP kérés fogadásával és a hangfájl multipart kérésből kivételével eltöltött idő igen közel van az Input Service-nél tapasztaltakhoz. Ez egy várható eredmény volt, ugyanis mindegyik mikroszolgáltatás Python nyelven, a Flask webes keretrendszert használva készült, így ezen műveletek implementációja és belső viselkedése nagyon hasonló.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/classification-service-runtime.png}
\caption{Classification Service futási idejének összetétele}
\label{fig:classification-service-runtime}
\end{figure}
A Classification Service-t górcső alá véve a korábbi hipotézisünk beigazolódni látszik, ugyanis a minta feldolgozásával eltöltött idő közel 85\%-át tölti a mesterséges intelligencia futtatásával a mikroszolgáltatás. Ez azt jelenti, hogy nagy számú egyidejű beérkező minta esetén mindenképpen skálázni kell ezt a mikroszolgáltatást is.
A többi mikroszolgáltatás esetében nem tartottuk indokoltnak a skálázás alkalmazását, ugyanis azok nagy számú konkurens kliens esetében is alacsony válaszidővel képesek voltak feldolgozni az egyes kéréseket, így azok a rendszer áteresztőképességét nem korlátozzák.
\section{Input és Storage Service-ek skálázásának vizsgálata}
Száz konkurens kliens esetén az Input Service késleltetése nem növekszik meg lényegesen az egy, vagy húsz konkurens kliensek esetén mérttől, amint azt \aref{fig:input-svc-latency} ábrán is láthatjuk. Ez jó jel a skálázhatóságára tekintve, ugyanis ebből arra következtethetünk, hogy ez a mikroszolgáltatás kiszámíthatóan reagál a változatos terhelésekre. Ez alapján megsejthetjük, hogy amennyiben kettő példányt indítunk a komponensből annak áteresztőképessége közel kétszeresére növekedik. Ehhez viszont ki kell kössük, hogy a Storage Service skálázása is szükséges, ellenben az továbbra is szűk keresztmetszet marad.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/input-svc-latency.png}
\caption{Input Service késleltetésének alakulása}
\label{fig:input-svc-latency}
\end{figure}
A sejtés beigazolódni látszik, ugyanis míg ez a két mikroszolgáltatás egy-egy példányt használtva tíz kérést volt képes feldolgozni másodpercenként, kettő példányt használva húszat, öt esetében pedig negyvennyolcat.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/input-service-rps.png}
\caption{Input Service áteresztőképességének alakulása}
\label{fig:input-service-rps}
\end{figure}
\section{Classification Service skálázásának vizsgálata}
A Classification Service bemeneti interfésze, mivel üzenetsoron kapja a bemeneti adatokat más jellegű, mint az Input vagy a Storage Service-eké. A teljesen aszinkron bemeneti interfészén csak akkor kap adatot, ha épp nem dolgoz fel egy másikat, valamint az aszinkron kimeneti interfésze miatt nem blokkolja másik mikroszolgáltatás sem. Emiatt az üzenetsor egyfajta terheléselosztóként is felfogható.
\begin{figure}[!ht]
\centering
\includegraphics[width=150mm, keepaspectratio]{figures/classification-service-rps.png}
\caption{Classification Service áteresztőképességének alakulása}
\label{fig:classification-service-rps}
\end{figure}
A fent leírtak alapján azt várjuk, hogy a mikroszolgáltatás skálázása esetén a komponens áteresztőképessége a replikák számával arányosan fog nőni. Amint ez \aref{fig:classification-service-rps} ábrán látható, ez így van, amíg egy példány két mintát képes másodpercenként feldolgozni, tíz példány húszat, húsz példány pedig negyvenet.
\section{Eredmények értékelése}
A fejezetben ismertetett mérések eredményeiből számos konzekvencia levonható a rendszerrel kapcsolatban. Az első, hogy a teljesítmény szempontjából szűk keresztmetszetet képző komponensek jól skálázódnak. A szűk keresztmetszet megszüntetésére vagy enyhítésére viszont egyéb alternatívák is láthatók. Az Input és Storage Service-ek vizsgálata esetén érdemes lehet meggondolni azok összevonását, ugyanis ezzel a lépéssel az Input Service válaszideje érdemben csökkenthető. Az eredeti 130 milliszekundum válaszidőből ezzel megtakarítható a kérés fogadására és a file kivételére fordított idő, ezáltal körülbelül 50 milliszekundummal kevesebb lenne az adott mikroszolgáltatás futási ideje. Ezen túl a komponens skálázásával jól növelhető az áteresztőképessége.
A Classification Service esetében javasoljuk a Kubenetesben egyedi metrika alapján történő automatikus skálázás alkalmazását, ugyanis egy esetleges rövid idő alatt nagy számú beérkező hangminta esetében nehéz előrejelezni, hogy hány példány lenne azt képes gyorsan feldolgozni. A skálázáshoz szükséges egyedi metrikákat kellene megfogalmazni, például az üzenetsoron egységnyi idő alatt beérkező üzenetek számát, és ez alapján lehet a skálázási logikát programozni. Egy ilyen megoldás nem csak a szűk keresztmetszet problémáját kezeli, hanem elkerüli a klaszter erőforrás pazarálását is, mert az automatikus skálázó logika terhelésmentes időszakban leállítja a felesleges példányokat. Ennek a skálázódásnak implementációjánál viszont figyelni kell arra, hogy az új példányok az első minta feldolgozása során le kell kérjék az aktuális modellt a Model Service-től, ami késleletetésben és adatforgalomban mérhető extra költséget jelent.
\section{A teljesítménymérési módszer alkalmazása általános rendszerekre}
A dolgozatunkban bemutatott módszer jól felhasználható más hasonló mikroszolgáltatásokra épülő szoftverek esetében is.
Első lépésként valamilyen Alkalmazás Teljesítmény Monitorozó megoldás használata és integrálása kulcsfontosságú. Ezek segítségével megállapítható, hogy mely mikroszolgáltatások vizsgálata szükséges skálázási szempontból, melyek jelenthetik a szűk keresztmetszetet. Természetesen a skálázás előfeltétele, hogy a mikroszolgáltatásaink állapotmentesek legyenek. A szűk keresztmetszetet alkotó mikroszolgáltatások azok lehetnek, melyek legalább egy nagyságrenddel nagyobb idő alatt dolgoznak fel egységnyi kérést a rendszerben, ezek lehetnek érdemesek további vizsgálatra.
Második lépésként meg kell vizsgáljuk a kérdéses komponensek miként viselkednek skálázás esetében. Ezt terheléstesztek segítségével érhetjük el. Amennyiben egy komponens nem skálázódik jól, annak refaktorálására lehet szükség.
Az itt leírt tesztek segítségével elég adatot gyűjthetünk ahhoz, hogy javaslatokat tegyünk a rendszerben esetlegesen szükséges változtatásokra.

63
src/content/closing.tex
View File

@ -1,60 +1,17 @@
% !TeX root = ../thesis.tex
\chapter{A rendszer teljesítménymérése}
Dolgozatunk e fejezetében bemutatunk egy olyan módszertant és eszközöket, amik segítségével egy komplex mikroszolgáltatásokból álló rendszerben megtalálhatók az esetleges gócpontok, valamint azok orvoslására javaslat tehető. Emellett bemutatjuk az ennek kidolgozásához és ellenőrzéséhez felhasznált eszközöket.
\section{Mérési környezet ismertetése}
A fejlesztés és teljesítménymérés idejére létrehoztunk egy Kubernetes klasztert, amiben futtattuk a rendszert. A klaszterben három Master és ugyanennyi Worker volt, mindegyik virtuális gépen futott, Microsoft Hyper-V hypervisorban. A Mastereknek kettő processzormagja és nyolc gigabájt memóriája volt, a Workereknek négy magot, valamint tizenhat gigabájt memóriát allokáltunk. A klaszter három fizikai gépen futott, mindegyikben Intel Xeon E5-2450L processzor, valamint 64 gigabájt memória volt. Egy Master és egy Worker példányt telepítettünk mindegyik fizikai gépre.
<Ábra a fizikai architektúráról>
A fizikai hosztgépek kétszer egy gigabites hálózaton kerültek összekötésre. Amint az <ÁBRAHIVATKOZÁS> -n is látható, az egyik hálózaton a hypervisorok és a virtuális gépek az internetet érték el, ezt csak frissítések és csomagok letöltésére használtuk. Emellett egy fizikailag teljesen különálló hálózat állt a virtuális gépek rendelkezésére a klaszter forgalmának lebonyolítására.
Mivel a fürtnek számos tagja volt, telepítettünk egy külön fizikai gépre egy HAProxy HTTP és TCP terheléselosztót, ami a kéréseket roundrobin algoritmussal osztotta el az egyes node-ok között. Ennek segítségével volt elérhető az egyes mikroszolgáltatások API-ja és az MQTT broker az IoT eszközök számára. Ebben a fizikai gépben egy Intel Core i5 2550K és 16 gigabájt ram volt.
A Kubernetes klaszterben a Calico hálózati implementációt használtuk, ami nem hoz létre virtuális hálózatot a meglévő fölé, hanem az egyes alkalmazások és kompnensek között különálló IP alhálózatok és útvonalválasztás segítségével biztosítja a megfelelő izolációt. Emellett NGINX Ingress Controllert használtunk. Ez egy NGINX webszerver konfigurációjával realizálja az Ingress Controller funkcionalitását.
A mikroszolgáltatásokat kiszolgáló relációs adatbázisokat egy külön virtuális gépen futó PostgreSQL szolgálta ki, aminek 2 processzormagot és két gigabájt memóriát allokáltunk.
A méréseket futtató számítógépben egy Core i7 3770 és 16 gigabájt ram volt, valamint csatlakozott mind a publikus, mint a magánhálózatra.
\chapter{Zárszó}
\section{Mérőszoftver ismertetése}
Mint azt az előző fejezetben ismertettük a leghosszabb út, amit egy minta és az arra generált válasz megtehet egy seregélyként kategorizált minta tesz meg. Ebből következik, hogy egy kritikus mérés a beküldött HTTP kérések és az érkező MQTT üzenetek között eltelt idő lehet. Olyan kész mérőeszköz viszont, ami ennek a mérésére képes nem elérhető, ezért egy saját mérőeszköz fejlesztése mellett döntöttünk.
Annak érdekében, hogy a lehető leggyorsabban legyen képes a szoftver kéréseket generálni azokat indulás után először kigenerálja azok törzsét az Input Service elvárt sémában található eszközazonosító kitöltésével, a többi mező és rész előre beállított sablont érintetlenül hagyásával. Parancssori paraméterként megadható a használni kívánt konkurenciaszám, ami egy külön folyamatot jelent. Az egyes folyamatok a következő lépésben egy saját listában nyilvántartják az aktuális rendszeridőt, elküldenek egy HTTP kérést az előre elkészítettek közül, majd egy másik listába is feljegyzik a rendszeridő aktuális értékét. Fontos kiemelni, hogy az egyes worker folyamatok minden kérés végéig blokkolnak, azaz megvárják, amíg megérkezik a válasz. Ezt a lépést addig ismétlik, amíg a mérést felügyelő folyamat – az előre beállított idő leteltével – le nem állítja őket. Ez alatt és után 600 másodpercig, szintén külön folyamatban, a szoftver fogadja az MQTT-n érkező üzeneteket és feljegyzi azok érkezési idejét egy listába.
Miután minden folyamat végzett, a különböző HTTP kéréseket generáló folyamatoktól lekérdezi a küldési és fogadási időpontokat tartalmazó listákat és egyesíti azokat egy-egy nagy listába, amik a kérések elküldése szerint kerülnek rendezésre. Ez úgy lehetséges, hogy a szoftver minden kéréshez rendel egy egyedi azonosítót, amit a listában az időbélyeg mellé csatol. Ugyanez teszi lehetővé az MQTT üzenetek HTTP kérésekhez párosítását, ugyanis a mérni kívánt rendszer a bemeneti API-ján elfogad egy egyedi azonosítót, amit felhasznál az MQTT téma összeállítása során. Amennyiben a mérések során minden esetben egyedi azonosítóval látunk el egy-egy kérést, azok végig egyértelműen azonosíthatók maradnak lehetővé téve az egyes mérőkomponensek külön folyamatba választását.
\section{Összefoglalás}
Dolgozatunkban egy olyan mikroszolgáltatásokra épülő felhő-natív megoldást mutattunk be, amely képes seregélyek hangjának felismerésére és a madarak automatizált elriasztására. Megmutattuk, hogy a rendszer teljesítménye szempontjából kritikus komponensek jól skálázódnak. A tervezési és megvalósítás mérnöki folyamata egy, a DevOps szemléletbe illő, általunk kidolgozott módszert követett.
\section{Mérőszoftver értékelése}
Amennyiben a mérőszoftver segítségével méréseket futtatnánk a kapott eredmények csekély információt hordoznának egyéb adatok híján, ugyanis bizonytalan lenne, hogy a mérés a rendszer vagy a mérőeszköz legjobb teljesítményét mutatja, nem tudjuk melyik teljesítményét mértük ki. A mérőszoftvert Pythonban készítettük, ezért annak teljesítménye nem feltétlen haladja meg a mért rendszerét.
Ezt a problémát megoldandó elkészítettünk egy a rendszert imitáló webes alkalmazást. Az alkalmazást Kotlinban írtuk, amiben a korutinok segítségével könnyű aszinkron, nem blokkoló kód írása. Ennek köszönhetően az alkalmazás minden HTTP kérést aszinkron módon szolgál ki, ezzel emelve az alkalmazás áteresztőképességét. Amennyiben az alkalmazáshoz GET kérés érkezik, az egy nullás karakterrel tér vissza. Ezt a viselkedést a mérő alkalmazás működésének tesztelésére hoztuk létre. Ha az alkalmazáshoz POST kérés érkezik, ellenőrzi, hogy a kérés megfelel-e az Input Service által elvártaknak. Amennyiben nem, 500-as hibakóddal válaszol. Amennyiben a kérés átmegy a validáción, a kérés törzséből beolvassa az eszközt – vagy ez esetben a kérést – azonosító mező értékét és aszinkron módon küldd egy üzenetet az MQTT brókernek továbbításra a megfelelő témára, majd válaszol a kérésre egy húsz karakter hosszú karakterlánccal. Ez utóbbi célja, hogy a HTTP válasz mérete is nagyságrendileg akkora legyen, mint amekkorát az Input Service küldene.
Ennek az alkalmazásnak referenciaként teszteltük a teljesítményét az Apache Benchmark (ab) eszközzel.
<barchart: BirbBench – requests: 130, BirbBench – pycurl: 560, ab: 698>
Az <ÁBRAHIVATKOZÁS> n is látható, hogy az ab (ab oszlop) és az általunk készített szoftver (BirbBench – requests oszlop) nagy a különbség teljesítmény téren. Ezt a különbséget nem tartottuk elfogadhatónak . A gyanú gyorsan az általunk használt Python HTTP kliensre, a requests-re terelődött, ugyanis az teljes egészében Pythonban készült, valamint a PyCurlhöz összehasonlító teljesítménymérésekben lemarad. Utóbbi egy vékony Python réteg a C-ben implementált libcurl felett. Valóban, a PyCurl használata esetén a mérőeszköz által mért áteresztőképesség jobban megközelítette az ab által elértet, de nem érte azt el, viszont ez nem volt célunk. Ezen mérések által van referenciánk arról, milyen karakterisztikákkal rendelkezik a mérőszoftverünk HTTP kliense.
Az MQTT komponens értékelése során is nem várt anomáliát figyeltünk meg. Amint az <ÁBRAHIVATKOZÁS>n megfigyelhető, az MQTT üzenetek késleltetési ideje a HTTP kérésekhez képest a mérés során szigorúan monoton növekedett, ami arra enged következtetni, hogy vagy a broker áteresztőképességénél nagyobb rátával küldi neki az üzeneteket a Kotlinos alkalmazás, vagy a kliens képes túl lassan fogadni az üzeneteket. Előbbire enged következtetni, hogy a broker folyamata a Workeren egy processzormagot teljesen kihasznál.
<ábra: mqtt latency megy fel, mint a 21-es busz a normáfra>
A fenti hipotézis ellenőrzésére elkészítettünk egy olyan Kotlin programot, ami letárolja az egy másodperc alatt érkezett üzeneteket, majd ezt összehasonlítottuk a Pythonban készült mérőszoftverrel. Az összehasonlítás során
Ezek alapján arra következtettünk , hogy az általunk használt Apache Artemis MQTT broker egy példányt használva a számunkra elérhető hardveren körülbelül száz egyedi témára érkező üzenetet képes továbbítani.
\section{További kutatási irányok}
\section{Skálázódási lehetőségek felmérése}
Méréseinkkel a rendszer skálázhatóságát szerettük volna megvizsgálni, viszont ehhez tudnunk kellett, mely komponenseket érdemes skálázni, melyek azok a mikroszolgáltatások, amk egy adott kérést a legtovább dolgozzák fel, ezzel a rendszerben szűk keresztmetszetként viselkednek. Mivel a mikroszolgáltatásaink egy távoli Kubernetes klaszterben futnak a tradicionális, fejlesztői eszközökbe épített profilozó használata nem lehetséges. Ezt a problémát hivatottak megoldani az Alkalmazás Teljesítmény Monitorozó eszközök. Számos ilyen eszköz elérhető, mint például a Jaeger, vagy a mikroszolgáltatásokban keletkezett hibákat is gyűjteni képes Sentry. Ezek között a különbség tipikusan a támogatott nyelvek és a szerverben használt technológiákban rejlik, mindegyik képes egy megjelölt kódblokk futási idejét monitorozni. A projekt fejlesztése során Sentryt használtunk az elosztott hibakeresési képességei, valamint elsőrangú Python támogatása miatt.
Ezen vizsgálatok során a módszertanunk az volt, hogy a rendszerbe beküldtünk egyetlen mintát, valamint korábban ismertetett mérőeszközzel generáltunk nagyobb terhelést a rendszerben, majd a Sentry által aggregált adatokat összevetettük és értkeltük. Minden mérést húsz alkalommal ismételtünk és az eredmények mértani közepét vettük annak érdekében, hogy egy-egy kiemelkedő mérés ne befolyásolja aránytalanul a kapott eredményeket.
<barchart késleltetések 50. és 95. percentiliséről, egy kérés esetén>
Általánosan elmondható volt a tesztek alapján, hogy a hangmintákkal dolgozó, valamint mesterséges intelligenciát alkalmazó mikroszolgáltatások válaszideje nagyságrendekkel nagyobb, mint a csak szöveges adatokkal dolgozóké. Ennek oka valószínű az Input és a Storage mikroszolgáltatások esetében a HTTP kérések mérete lehet, a Classification Service-nél pedig a mesterséges intelligencia futási idejéből adódhat a magas átfutási idő. Ezt ellenőrizendő finomítottuk a használt tranzakciókat, hogy a kérdéses HTTP kérések során elvégzett műveletek ideje pontosan látszódjon.
<input-service futási idő waterfall chart>
Ez alapján (ahogy az <ÁBRAHIVATKOZÁS> is látható) megállapítható, hogy valóban a kérés fogadása, valamint a kezelése tart sokáig az Input Service-ben, az egyéb műveletek rövid idő alatt lezajlanak. Ennek okán az egyik skálázásra kijelölt komponenspár az Input és Storage Service-ek voltak.
<storage service futási idő waterfall chart>
Úgy döntöttünk ezeket közösen érdemes skálázni, hiszen az <ÁBRAHIVATKOZÁS>t összevetve az <ÁBRAHIVBATKOZÁS>val is megfigyelhető, hogy a Storage Service esetében a HTTP kérés fogadásával és a hangfájl multipart kérésből kivételével eltöltött idő igen közel van az Input Service-nél tapasztaltakhoz. Ez egy várható eredmény volt, ugyanis mindegyik mikroszolgáltatás Python nyelven, a Flask webes keretrendszert használva készült, így ezen műveletek implementációja és belső viselkedése nagyon hasonló.
<classification service waterfall chart>
A Classification Service-t górcső alá véve a korábbi hipotézisünk beigazolódni látszik, ugyanis a minta feldolgozásával eltöltött idő közel 85\%-át tölti a mesterséges intelligencia futtatásával a mikroszolgáltatás. Ez azt jelenti, hogy nagy számú egyidejű beérkező minta esetén mindenképpen skálázni kell ezt a mikroszolgáltatást is.
A többi mikroszolgáltatás esetében nem tartottuk indokoltnak a skálázás alkalmazását, ugyanis azok nagy számú konkurens kliens esetében is alacsony válaszidővel képesek voltak feldolgozni az egyes kéréseket, így azok a rendszer áteresztőképességét nem korlátozzák.
Az elkövetkező időszakban szándékunkban áll megtervezni és implementálni az előző fejezetben javasolt módosításokat, valamint azok hatékonyságának értékelését is el szeretnénk végezni.
\section{Input és Storage Service-ek skálázásának vizsgálata}
Száz konkurens kliens esetén az Input Service késleltetése nem növekszik meg lényegesen az egy, vagy húsz konkurens kliensek esetén mérttől, amint azt <ÁBRAHIVATKOZÁS>n is láthatjuk. Ez jó jel a skálázhatóságára tekintve, ugyanis ebből arra következtethetünk, hogy ez a mikroszolgáltatás kiszámíthatóan reagál a változatos terhelésekre. Ez alapján megsejthetjük, hogy amennyiben kettő példányt indítunk a komponensből annak áteresztőképessége közel kétszeresére növekedik. Ehhez viszont ki kell kössük, hogy a Storage Service skálázása is szükséges, ellenben az továbbra is szűk keresztmetszet marad.
<input service latency benchmarkok>
A sejtés beigazolódni látszik, ugyanis míg ez a két mikroszolgáltatás egy-egy példányt használtva tíz kérést volt képes feldolgozni másodpercenként, kettő példányt használva húszat, öt esetében pedig negyvennyolcat.
<input service rps benchmarkok>
Úgy gondoljuk, hogy a rendszerben számos további lehetőség rejlik, amit érdemes lenne kiaknázni, ezért további funkciókkal szeretnénk bővíteni mind az IoT eszközön futó szoftvert, mind a felhő-natív rendszert. Egy elemzés alatt levő bővítési irány további szenzor adat integrálása, például időjárási adatok alapján javítani a seregélyek detekciójának pontosságát.
\section{Classification Service skálázásának vizsgálata}
A Classification Service bemeneti interfésze, mivel üzenetsoron kapja a bemeneti adatokat más jellegű, mint az Input vagy a Storage Service-eké. A teljesen aszinkron bemeneti interfészén csak akkor kap adatot, ha épp nem dolgoz fel egy másikat, valamint az aszinkron kimeneti interfésze miatt nem blokkolja másik mikroszolgáltatás sem. Emiatt az üzenetsor egyfajta terheléselosztóként is felfogható.
<cnn rps benchmarkok>
A fent leírtak alapján azt várjuk, hogy a mikroszolgáltatás skálázása esetén a komponens áteresztőképessége a replikák számával arányosan fog nőni. Amint ez <ÁBRAHIVATKOZÁS>n látható, ez így van, amíg egy példány két mintát képes másodpercenként feldolgozni, tíz példány húszat, húsz példány pedig negyvenet.
\section{Köszönetnyilvánítás}
K\"osz\"onjük a konzulenseinknek a seg\'itők\'esz hozz\'a\'all\'as\'at \'es \'utmutat\'as\'at Dr. Maliosz Markosznak és Dr. Simon Csabának. K\"osz\"onjük sz\"uleinknek \'es a bar\'atainknak a t\'amogat\'ast.
\section{Eredmények értékelése}
A fejezetben ismertetett mérések eredményeiből számos konzekvencia levonható a rendszerrel kapcsolatban. Az első, hogy a teljesítmény szempontjából szűk keresztmetszetet képző komponensek jól skálázódnak. A szűk keresztmetszet megszüntetésére vagy enyhítésére viszont egyéb alternatívák is láthatók. Az Input és Storage Service-ek vizsgálata esetén érdemes lehet meggondolni azok összevonását, ugyanis ezzel a lépéssel az Input Service válaszideje a felére csökkenthető. Ezen túl a komponens skálázásával jól növelhető az áteresztőképessége.
A Classification Service esetében javasoljuk a Kubenetesben automatikus skálázás alkalmazását, egyedi metrikákat megfogalmazva az üzenetsoron egységnyi idő alatt beérkező üzenetek alapján. Ez megoldja a szűk keresztmetszet problémáját amellett, hogy nem pazarol feleslegesen erőforrást a klaszterben. Ennek a skálázódásnak implementációjánál viszont figyelni kell arra, hogy az új példányok az első minta feldolgozása során le kell kérjék az aktuális modellt a Model Service-től.
A dolgozatban ismertetett eredmények a Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Balatonfüredi Hallgatói Kutatócsoport szakmai közössége keretében jöttek létre a régió gazdasági fejlődésének elősegítése érdekében. Az eredmények létrehozása során figyelembe vettük a balatonfüredi központú Rendszertudományi Innovációs Klaszter által megfogalmazott célkitűzéseket, valamint a párhuzamosan megvalósuló EFOP 4.2.1-16-2017-00021 pályázat támogatásával elnyert „BME Balatonfüredi Tudáscentrum” térségfejlesztési terveit.
\section{A módszer általános leírása}
Az általunk itt alkalmazott módszer jól felhasználható más hasonló mikroszolgáltatásokra épülő szoftverek esetében. Első lépésként valamilyen Alkalmazás Teljesítmény Monitorozó megoldás használata és integrálása kulcsfontosságú. Ezek segítségével megállapítható, mely mikroszolgáltatások szükségesek vizsgálatra skálázási szempontból, melyek jelenthetik a szűk keresztmetszetet. Természetesen a skálázás előfeltétele, hogy a mikroszolgáltatásaink állapotmentesek legyenek. A szűk keresztmetszetet gyanúsan alkotó mikroszolgáltatások azok lehetnek, melyek legalább egy nagyságrenddel nagyobb idő alatt dolgoznak fel egységnyi kérést a rendszerben, ezek lehetnek érdemesek további vizsgálatra.
Második lépésként meg kell vizsgáljuk a kérdéses komponensek miként viselkednek skálázás esetében. Ezt terheléstesztek segítségével érhetjük el. Amennyiben egy komponens nem skálázódik jól, annak refaktorálására lehet szükség.
Az itt leírt tesztek segítségével elég adatot gyűjthetünk ahhoz, hogy javaslatokat tegyünk a rendszerben esetlegesen szükséges változásokra.
A kutatás az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával valósult meg (EFOP-3.6.2-16-2017-00013, Innovatív Informatikai és Infokommunikációs Megoldásokat Megalapozó Tematikus Kutatási Együttműködések).

10
src/content/introduction.tex
View File

@ -3,8 +3,12 @@
\chapter{\bevezetes}
%----------------------------------------------------------------------------
A felhő alapú technológiák elterjedésével egyre növekszik az ilyen megoldások iránti igény. Az ebbenrejlő lehetőségek kihasználására képes alkalmazások fejlesztése egyedi és új kihívásokat jelent. Az ilyen alkalmazások komponensei általában egymástól elválasztottak, lazán kötődnek és állapotmentesek. Ez tipikusan, de nem szükségszerűen mikroszolgáltatás alapú alkalmazás architektúrát, agilis fejlesztési folyamatokat, konténer alapú technológiák használatát jelenti.
Szőlőtulajdonosoknak éves szinten jelentős kárt okoznak a seregélyek, akik előszeretettel választják táplálékul a megtermelt szőlőt. Az ilyen kártevő madarakat elriasztó eszközök általában folyamatos ultrahang kibocsájtásával érik el a kívánt hatást. Ezekhez képes egy intelligens, célzottan működő rendszer a környezetre kisebb ráhatással is elérhet hasonló eredményeket, hiszen nincs szükség a többi állatot is zavaró ultrahang kibocsájtására, ha a kártevők nincsenek jelen. Emellett az Internet of Things és a felhő adta lehetőségeket kihasználva a szőlőültetvények számára az általunk készített rendszer további hozzáadott értéket is hordoz.
A felhő alapú technológiák elterjedésével egyre növekszik az ilyen megoldások iránti igény. Az ebben rejlő lehetőségek kihasználására képes alkalmazások fejlesztése egyedi és új kihívásokat jelent. Az ilyen alkalmazások komponensei általában egymástól elválasztottak, lazán kötődnek és állapotmentesek. Ez tipikusan, de nem szükségszerűen mikroszolgáltatás alapú alkalmazás architektúrát, agilis fejlesztési folyamatokat, konténer alapú technológiák használatát jelenti.
Szőlőtulajdonosoknak éves szinten jelentős kárt okoznak a seregélyek, akik előszeretettel választják táplálékul a megtermelt szőlőt. Az ilyen kártevő madarakat elriasztó eszközök általában folyamatos ultrahang kibocsájtásával \cite{doi:10.1002/wsb.529} érik el a kívánt hatást. Ezekhez képes egy intelligens, célzottan működő rendszer a környezetre kisebb ráhatással is elérhet hasonló eredményeket, hiszen nincs szükség a többi állatot is zavaró ultrahang kibocsájtására, ha a kártevők nincsenek jelen. Emellett az Internet of Things és a felhő adta lehetőségeket kihasználva a szőlőültetvények számára az általunk készített rendszer további hozzáadott értéket is hordoz.
Az Internet of Things eszközökről általánosságban elmondható, hogy olyan mindennapi használati tárgyak vagy ipari eszközök, amelyeket hálózati kapcsolattal és számítási kapacitással is felruháztak. Az említett hálózati kapcsolat lehet többek között egyes eszközök közötti, vagy akár egy felhőben lévő rendszerhez is kapcsolódhatnak a készülékek. Nagy számú eszközpark esetén megoldandó probléma a készülékek állapotának megfigyelése és központi irányítása is.
Azért, hogy a riasztás effektív legyen elengedhetetlen a relatív alacsony körbefordulási idő a rendszer és az egyes eszközök között. Ahhoz, hogy megtudjuk egy adott rendszerben ez az érték miként alakul méréseket kell végezzünk. Mikroszolgáltatás alapú rendszerek esetében az is érdekes információ lehet, hogy az egyes mikroszolgáltatások mennyi idő alatt képesek egy adatpontot feldolgozni, hogy reagálnak nagy terhelésre és mennyire skálázhatóak, valamint ezeknek milyen hatása van az egész rendszerre.
Feladatunk egy seregélyeket hang alapján felismerni és elriasztani képes rendszer megtervezése és fejlesztése volt, amely kizárólag nyílt komponenseket használ fel. Kiemelten fontos volt, hogy az általunk elkészített rendszerbe későbbi fejlesztések során könnyedén illeszthetők legyenek más típusú adatok és kimenetek. A rendszer architektúráját ezen szempontok és a korábban ismertetett követelményeket figyelembe véve készítettük el. A rendszer elkészülte után megterveztünk és elvégeztünk méréseket, amiknek a célja a rendszer nagy számú szenzor melletti viselkedésének vizsgálata és az egyes komponensek skálázásának az adatok körülfordulási idejére gyakorolt hatásának elemzése volt. Ezek alapján ajánlásokat fogalmazunk meg a saját rendszerünkre, valamint hasonló rendszerek fejlesztésére vonatkozóan.
Célunk egy seregélyeket hang alapján felismerni és elriasztani képes rendszer megtervezése és fejlesztése volt, amely kizárólag nyílt komponenseket használ fel. Kiemelten fontos volt, hogy az általunk elkészített rendszerbe későbbi fejlesztések során könnyedén illeszthetők legyenek más típusú adatok és kimenetek. A rendszer architektúráját ezen szempontok és a korábban ismertetett követelményeket figyelembe véve készítettük el. A rendszer elkészülte után megterveztünk és elvégeztünk méréseket, amiknek a célja a rendszer nagy számú szenzor melletti viselkedésének vizsgálata és az egyes komponensek skálázásának az adatok körülfordulási idejére gyakorolt hatásának elemzése volt. Ezek alapján ajánlásokat fogalmazunk meg a saját rendszerünkre, valamint hasonló rendszerek fejlesztésére vonatkozóan.

44
src/content/theory.tex
View File

@ -3,22 +3,38 @@
\label{sec:theory}
\section{Felhő}
A felhőalapú számítástechnikában 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. Három alapvető szolgáltatási modellt különböztetünk meg: SaaS (Software as a Service, Szoftver, mint Szolgáltatás, például: Office 365), PaaS (Platform as a Service, Platform, mint Szolgáltatás, például: Oracle Cloud Platform) és 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.
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.
<ábra példa k8s klaszterről>
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 legalább egy Masterből és Workerből épül fel, ezek több komponensből állnak. A Kubernetes Master felelős a klaszterben lezajló folyamatok irányításáért, valamint a Slave-ek - vagy más néven Workerek - és 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 multimaster mode - csak az API Server és az 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 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 localhoston keresztül elérik 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 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. 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.
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:
Horizontális skálázás,
Konfiguráció és szenzitív adatok menedzsmentje,
Háttértár orkesztráció,
Szolgáltatások név alapján történő felderítése.
Ingress 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.
\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 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, 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 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.
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 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ős 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 termosz, 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.
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.

BIN
src/figures/cloud-arch-sequence.pdf Normal file
View File

Binary file not shown.

56
src/huplain.bst
View File

@ -20,18 +20,18 @@
% !! don't remove double-accent in T1 encoding: \'{\`a}}
% !! sort year
% !! make sure about Hungarian typography of {proceedings} and {inproceedings}
% it is better now to have talked=1, (Elhangzott a ... címû konferencián)
% it is better now to have talked=1, (Elhangzott a ... címû konferencián)
% !! also remove space after \ae before calling purify$
% !! crossrefs
% !! ` type '
% !! hu ordering: author, year, title if author is present
% title, year if author is missing!
% !! use and document ``address''
% !! MSZ 3401--81. A bibliográfiai tételek betûrendbe sorolásának szabályai.
% !! MSZ 3402--80. Könyvek bibliográfiai adatközlése és belsõ elrendezése.
% !! MSZ 3424/*-*. Bibliográfiai leírás. *.
% !! MSZ 3432-85. Szavak és szókapcsolatok rövidítése a bibliográfiai leírásban.
% !! MSZ 3440/*-*. A bibiliográfiai leírás besorolási adatai. *.
% !! MSZ 3401--81. A bibliográfiai tételek betûrendbe sorolásának szabályai.
% !! MSZ 3402--80. Könyvek bibliográfiai adatközlése és belsõ elrendezése.
% !! MSZ 3424/*-*. Bibliográfiai leírás. *.
% !! MSZ 3432-85. Szavak és szókapcsolatok rövidítése a bibliográfiai leírásban.
% !! MSZ 3440/*-*. A bibiliográfiai leírás besorolási adatai. *.
% !! abbrv style for J.-P. Sartre
% !! test all entry types
% !! optional \uppercase or \textsc
@ -42,16 +42,16 @@
% !! \include...
% !! bibgerman.sty, gerplain.bst, language = "german" | "USenglish" | "english" etc.
% \selectlanguage{...} \bibitem...
% !! doc: parametric volume: `kötet' (volumeisyearly={1}) instead of `évf.'
% !! doc: parametric volume: `kötet' (volumeisyearly={1}) instead of `évf.'
% OK: smaller space for \newblock
% OK: huname: name in hungarian order
% SUXX: cannot read current (overridden) MACRO values from .bst
% SUXX: #161 int.to.chr$ doesn't work (out of bounds), stupid BibTeX...
% Dat: @preamble { "..." # "..." }
% Dat: bibtex removes spaces from end of field contents
% Dat: `volume=' is `évfolyam'
% Dat: `volume=' is `évfolyam'
% Dat: Doc: key={{ }.}
% Dat: Doc: write non-decaptilized titles: title = {Fejtõ {Ferenc} és a szociáldemokrácia},
% Dat: Doc: write non-decaptilized titles: title = {Fejtõ {Ferenc} és a szociáldemokrácia},
% Dat: print debug messages with "foo" warning$
%
@ -208,7 +208,7 @@ FUNCTION {rmacc4.latinx} { % ****pts****
ss
}
%** Changes "á" to "{\'a}" etc.
%** Changes "á" to "{\'a}" etc.
%** @param #1 a string
%** @return a string
FUNCTION {rmacc4} { % **** pts ****
@ -690,7 +690,7 @@ FUNCTION {n.dashify}
% Dat: possible months formats in .bib:
% month = jun # "-" # aug, --> "j\'unius--\allowbreak augusztus" !!
% month = jun, --> "j\'unius"
% month = "8~" # feb, --> "február 8."
% month = "8~" # feb, --> "február 8."
% month = nov # ", " # dec, --> "november\nobreak\hskip--\allowbreak december"
FUNCTION {format.date}
@ -758,7 +758,7 @@ FUNCTION {format.series} { % ****pts****
FUNCTION {format.bvolume} { % ****pts****
volume empty$ number empty$ and {
series empty$ 'skip$ { format.series output new.block } if$
% ^^^ Dat: don't emphasize {Osiris kézikönyvek sorozat}, because it's after the book title.
% ^^^ Dat: don't emphasize {Osiris kézikönyvek sorozat}, because it's after the book title.
numvolumes empty$ { "" }
{ "\bibNumVolumes {" numvolumes "}." * * } if$ % ****pts****
} {
@ -781,7 +781,7 @@ FUNCTION {format.edition}
{ edition rmacc4 "t" change.case$ }
if$
add.period$
" kiad." * % Dat: " kiad.": Gyurgyák János: Szerkesztõk és szerzõk kézikönyve, 533. oldal, 2. sor.
" kiad." * % Dat: " kiad.": Gyurgyák János: Szerkesztõk és szerzõk kézikönyve, 533. oldal, 2. sor.
}
if$
}
@ -858,7 +858,7 @@ FUNCTION {format.in.ed.booktitle} {
booktitle empty$
{ "" }
{ editor empty$
% vvv "In ": Gyurgyák János: Szerkesztõk és szerzõk kézikönyve, 130. oldal, 12. sor.
% vvv "In ": Gyurgyák János: Szerkesztõk és szerzõk kézikönyve, 130. oldal, 12. sor.
{ "In " booktitle rmbrace.accs emphasize * }
'format.in.edited if$
} if$
@ -941,8 +941,8 @@ FUNCTION {format.in.talked.booktitle} {
swap$ * " c{\'i}m{\H u} konferenci{\'a}n" *
} if$ } if$ } if$ } if$
%% duplicate$ warning$
% Dat: now "a~{\em Foo Konferencián}"
% or "a~{\em Foo} címû konferencián"
% Dat: now "a~{\em Foo Konferencián}"
% or "a~{\em Foo} címû konferencián"
%% "alma" string.length warning$
"Elhangzott " swap$ *
} 'format.in.edited if$
@ -1156,7 +1156,7 @@ FUNCTION {addresss} { %*type*
FUNCTION {books.tail} { % ****pts****
crossref missing$ {
format.bvolume output % includes functionality of format.number.series
new.block % no comma in `1--4. köt., 7. kiad.'
new.block % no comma in `1--4. köt., 7. kiad.'
} 'skip$ if$
type$ "book" = {
chapter empty$ 'skip$
@ -1542,7 +1542,7 @@ FUNCTION {sortify}
duplicate$ % ****pts****
rmbrace.extrat1 % ****pts****
purify$
% Dat: purify$ removes á from "várom", keeps `varom' in "v\'arom","v{\'a}rom"
% Dat: purify$ removes á from "várom", keeps `varom' in "v\'arom","v{\'a}rom"
% Dat: purify$ changes {\ss} to ss, but {\dj} to empty
"l" change.case$
" " *
@ -1854,15 +1854,15 @@ FUNCTION {begin.bib}
% "\def\bibAnd#1{\ifcase#1 , \else\space\'es \fi}" write$ newline$
% "\def\bibEtAl#1{ et~al.}" write$ newline$ % Dat: or `et al.' (meaning: et alii)
"\def\bibEtAl#1{ \'es m\'asok}" write$ newline$
% ^^^ Dat: botht \bibEtAl confirmed by Gyurgyák (p. 137)
% ^^^ Dat: botht \bibEtAl confirmed by Gyurgyák (p. 137)
"\def\bibEd#1{ (szerk.)}" write$ newline$
% "\def\bibEd#1{ (szerk\ifcase#1 .\else eszt\H{o}k\fi)}" write$ newline$ % (szerk.) or (szerkesztõk)
% "\def\bibEd#1{ (szerk\ifcase#1 .\else eszt\H{o}k\fi)}" write$ newline$ % (szerk.) or (szerkesztõk)
% "\let\bibNewBlock\newblock" write$ newline$
"\def\bibNewBlock{\unskip\space}" write$ newline$
% "\def\bibVolume#1{k\" quote$ "otet}" * * write$ newline$
"\def\bibVolume#1#2{#1 k\" quote$ "ot.} \let\bibNumVolumes\bibVolume" * * write$ newline$
% "\def\bibTechRep#1{Technical Report}" write$ newline$
"\def\bibTechRep#1{Jelent\'{e}s}" write$ newline$ % Dat: `.' után van => nagybetû
"\def\bibTechRep#1{Jelent\'{e}s}" write$ newline$ % Dat: `.' után van => nagybetû
"\def\bibInSelf#1{In u\H{o}: }" write$ newline$
"\csname bibOverride\endcsname" write$ newline$
}
@ -1883,7 +1883,7 @@ EXECUTE {end.bib}
% #****pts**** !!
FUNCTION {what} {
% "dr. Köpeczi, Béla and Jules Verne and Kossuth, Lajos and gróf Széchenyi, István and John von Neumann and Donald E. Knuth and Strunk, Jr., William and Knézy, ifj., Jenõ and L. R. McColvin and Tinódi Lantos, Sebestyén and Molnár-Sáska, Balázs and Claude Lévi-Strauss and Kis, Péter Pál and Mary-Claire van Leunen and Paul Gerhard Hoel and G. Bernard Godfrey and II., János-Pál and {Szerencsejáték Rt.} and {\empty Earl of} Traquair and Horace [pseud.] Hunt and Verne, {\empty Gy}ula" 's :=
% "dr. Köpeczi, Béla and Jules Verne and Kossuth, Lajos and gróf Széchenyi, István and John von Neumann and Donald E. Knuth and Strunk, Jr., William and Knézy, ifj., Jenõ and L. R. McColvin and Tinódi Lantos, Sebestyén and Molnár-Sáska, Balázs and Claude Lévi-Strauss and Kis, Péter Pál and Mary-Claire van Leunen and Paul Gerhard Hoel and G. Bernard Godfrey and II., János-Pál and {Szerencsejáték Rt.} and {\empty Earl of} Traquair and Horace [pseud.] Hunt and Verne, {\empty Gy}ula" 's :=
% init.nfmts s #1 nfmt0 format.name$ warning$
% ss #385 #1 substring$ warning$
% "fo{\'o}\oe{\H u}s{\HON}{\HANT}" rmbrace.accs warning$ % to "fo\'o\oe\H us{\HON}{\HANT}"
@ -1891,17 +1891,17 @@ FUNCTION {what} {
% "bar" #-1 #1 substring$ warning$
% "5~janu\'ar" #1 "{ll~~}{ff{}}" format.name$ warning$
% "janu\'ar" #1 "{ll}{~ff.}" format.name$ warning$
% "{\null Gy}urgyák" #1 "{l}/" format.name$ warning$
% "AzBÁrvíztûrõ~tükörfúrógép" rmacc.latin2 warning$
% "{\null Gy}urgyák" #1 "{l}/" format.name$ warning$
% "AzBÁrvíztûrõ~tükörfúrógép" rmacc.latin2 warning$
% "fogbar" #3 #1 substring$ warning$
% "Az Árvíztûrõõ tükörfúrógépí" sortify warning$
% "Marjai, Imre and Pataky, Dénes" rmacc.latin2 warning$
% "Az Árvíztûrõõ tükörfúrógépí" sortify warning$
% "Marjai, Imre and Pataky, Dénes" rmacc.latin2 warning$
% "{\empty\'\i}purify" purify$ warning$
% "grof Szechenyi, Istvan" #1 "{ll}/{ff}/{jj}/{vv}" format.name$ warning$
% "John von Neumann" #1 "{ll}/{ff}/{jj}/{vv}" format.name$ warning$
% "Tinódi Lantos, Sebestyén" #1 "{ll}/{ff}/{jj}/{vv}" format.name$ warning$
% "Tinódi Lantos, Sebestyén" #1 "{ll}/{ff}/{jj}/{vv}" format.name$ warning$
% "II., Janos., Pal" #1 "{ll}/{ff}/{jj}/{vv}" format.name$ warning$
% "álom" "u" change.case$ warning$ % "áLOM"
% "álom" "u" change.case$ warning$ % "áLOM"
% "{\'a}lom" "u" change.case$ warning$ % "{\'A}LOM"
%"alma{\ss}t" purify$ warning$ % alma{\ss}t
%"alma{\dj}t" purify$ warning$ % almat (!)

4
src/include/tdk-variables.tex
View File

@ -1,8 +1,8 @@
%--------------------------------------------------------------------------------------
% TDK-specifikus változók
%--------------------------------------------------------------------------------------
\newcommand{\tdkszerzoB}{Második Szerző} % Második szerző neve; hagyd üresen, ha egyedül írtad a TDK-t.
\newcommand{\tdkev}{2014} % A dolgozat írásának éve (pl. "2014") (Ez OTDK-nál eltérhet az aktuális évtől.)
\newcommand{\tdkszerzoB}{Pünkösd Marcell} % Második szerző neve; hagyd üresen, ha egyedül írtad a TDK-t.
\newcommand{\tdkev}{2020} % A dolgozat írásának éve (pl. "2014") (Ez OTDK-nál eltérhet az aktuális évtől.)
% További adatok az OTDK címlaphoz (BME-s TDK-hoz nem kell kitölteni)
\newcommand{\tdkevfolyamA}{IV} % Első szerző évfolyama, római számmal (pl. IV).

28
src/include/titlepage.tex
View File

@ -10,20 +10,20 @@
\textmd{\vik}\\
\textmd{\viktanszek}\\[5cm]
\vspace{0.4cm}
{\huge \bfseries \vikcim}\\[0.8cm]
\vspace{0.5cm}
\textsc{\Large \vikdoktipus}\\[4cm]
{
\renewcommand{\arraystretch}{0.85}
\begin{tabular}{cc}
\makebox[7cm]{\emph{\keszitette}} & \makebox[7cm]{\emph{\konzulens}} \\ \noalign{\smallskip}
\makebox[7cm]{\szerzo} & \makebox[7cm]{\vikkonzulensA} \\
& \makebox[7cm]{\vikkonzulensB} \\
& \makebox[7cm]{\vikkonzulensC} \\
\end{tabular}
}
\vspace{0.4cm}
{\huge \bfseries \vikcim}\\[0.8cm]
\vspace{0.5cm}
\textsc{\Large \vikdoktipus}\\[4cm]
{
\renewcommand{\arraystretch}{0.85}
\begin{tabular}{cc}
\makebox[7cm]{\emph{\keszitette}} & \makebox[7cm]{\emph{\konzulens}} \\ \noalign{\smallskip}
\makebox[7cm]{\szerzo} & \makebox[7cm]{\vikkonzulensA} \\
& \makebox[7cm]{\vikkonzulensB} \\
& \makebox[7cm]{\vikkonzulensC} \\
\end{tabular}
}
\vfill
{\large \today}

138
src/magyar.ldf
View File

@ -58,7 +58,7 @@
% This file is quite long, because it implements a lot of parametric features
% related to typesetting Hungarian text with \LaTeX. Sorry.
%
% Motto: ``There is a lot to do in the future'' -- by Gyöngyi Bujdosó and
% Motto: ``There is a lot to do in the future'' -- by Gyöngyi Bujdosó and
% Ferenc Wettl in their conference proceedings article ``On the localization
% of TeX in Hungary'', presented at EuroBachoTeX 2002.
%
@ -159,7 +159,7 @@
%** amstocnumskip=\enskip, % TeX code or --empty--
%** amstocnumlang=all, % or =hu
%** amspostsectiondot=no, % or =unchanged
%** appendixdot=yes, % or =no % !! dokumentálni
%** appendixdot=yes, % or =no % !! dokumentálni
%** az=weak, % or =yes or =no
%** babelmarkfix=yes, % or =unchanged
%** captionfix=yes, % or =unchanged
@ -1309,7 +1309,7 @@
%** Adds definite article for a word #1#2#3 if #1 is in [A..Z]. Spaces
%** between #1, #2 and #3 can be -- fortunately -- ignored.
%** This is used to distinguish single-letter labels from text labels.
%** Dat: by pts: `\Az{Sz} betû' emits `Az Sz betû'; `\az{szólam}' is also OK
%** Dat: by pts: `\Az{Sz} betû' emits `Az Sz betû'; `\az{szólam}' is also OK
%** @param #1#2#3 doesn't contain \hbox (but may contain space)
%** @param #1 #2 #3 never lower case
\def\@@magyar@azuc#1#2#3{%
@ -1376,7 +1376,7 @@
\if5\noexpand#1z% Dat: emit `az 5'
\@@magyar@swaprelax\@@magyar@ignorehbox@pre
\else\if1\noexpand#1%
% Dat: properly handle `az 1001 éjszaka', `az 1234567 éves bolygó'
% Dat: properly handle `az 1001 éjszaka', `az 1234567 éves bolygó'
\@@magyar@swaprelax\@@magyar@eatddd@pre
\else\ifnum1<1\noexpand#1 % a different digit, emit `a '
\@@magyar@swaprelax\@@magyar@ignorehbox@pre
@ -1441,7 +1441,7 @@
% \label will be redefined to write another line to .aux file:
% \hunnewlabel{...}{...}: similar to \newlabel{sectionStructNr}{pageNr},
% where the roman numerals are replaced by their arabic representations, so
% \aref and \apageref will work (`a II. rész'). The name \hunnewlabel is a
% \aref and \apageref will work (`a II. rész'). The name \hunnewlabel is a
% legacy.
%
% We have to redefine \refstepcounter, which defines \@currentlabel, so we
@ -1596,7 +1596,7 @@
\def\ccname{K\"orlev\'el--c\'\i mzettek}% ??
\def\headtoname{C\'\i mzett}%
\def\proofname{Bizony\'\i t\'as}% AMS-\LaTeX
\def\glossaryname{Sz\'ojegyz\'ek}% glosszárium, (magyarázatos) szójegyzék
\def\glossaryname{Sz\'ojegyz\'ek}% glosszárium, (magyarázatos) szójegyzék
% vvv All these are start with a small letter
\def\figurename{\'abra}%
\def\chaptername{fejezet}%
@ -1613,7 +1613,7 @@
% --- Changing the order of the table numbers; tablecaptions=
\if0\magyar@opt@@tablecaptions\@@magyar@skiplong\fi
% Wee need `1. táblázat' instead of `Table 1'
% Wee need `1. táblázat' instead of `Table 1'
\if1\magyar@opt@@tablecaptions
\def\@@magyar@fnum@table{\thetable.~\tablename}%
\else \def\@@magyar@fnum@table{\tablename\nobreakspace\thetable}\fi
@ -1684,7 +1684,7 @@
% --- amsuppercasefix=
% Fix for small \'\i in capitalized title (no fix needed for \'i and í):
% Fix for small \'\i in capitalized title (no fix needed for \'i and í):
% \documentlcass{amsart} % amsart.cls
% \usepackage{t1enc}
% \usepackage[latin2]{inputenc}
@ -1801,7 +1801,7 @@
% --- captionfix=
%
% Fix ``1. ábra'' order in \caption defined by caption.sty 2004/07/16 v3.0c.
% Fix ``1. ábra'' order in \caption defined by caption.sty 2004/07/16 v3.0c.
%
% The manual fix would be:
%
@ -1842,10 +1842,10 @@
\ifx\magyar@caption@centering\@empty\@@magyar@skiplong\fi
\def\magyar@caption@hsizecheck{\hsize}
% We don't emit the two dots of `1. táblázat.' here, because
% We don't emit the two dots of `1. táblázat.' here, because
% has already been emitted by \fnum@table etc.
% We apply some formatting depending on the longcaption= option.
% Dat: Gyurgyák, p95. says: `11. ábra. Hajtási változatok.'
% Dat: Gyurgyák, p95. says: `11. ábra. Hajtási változatok.'
\let\@@magyar@do@makecaption\relax% before .toc
\expandafter\addto\csname extras\CurrentOption\endcsname{%
\@@magyar@do@makecaption}
@ -2748,25 +2748,25 @@
\fi\fi
%
%** A hyphen, but hyphenation is OK at both sides
%** reported and asked by Józsa Márton <jozsineni@freemail.hu>
%** reported and asked by Józsa Márton <jozsineni@freemail.hu>
\@@magyar@declare@shorthandx ={\leavevmode\nobreak-\hskip\z@skip}
% ^^^ Dat: no need for \nobreak\hskip\z@skip, because of the empty discretionary
%** \shu?-- typesets an endash (--) with a small space around it (the one to
%** the right is breakable). \shu?- typesets a normal hyphen, having
%** hyphenation OK at both sides.
%** @example Kiss Elõd\shu?--Nagy Pál
%** @example közgazdaság\shu?-tudományi
%** @example Kiss Elõd\shu?--Nagy Pál
%** @example közgazdaság\shu?-tudományi
\def\@@magyar@shorthandminus{%
\ifmmode \mskip2.4mu plus3.6mu minus1.8mu \else % ,`- is just a space in math mode
\if-\noexpand\@Lang@tmp \leavevmode\nobreak\,\nobreak\hbox{--}\,\expandafter\expandafter\expandafter\@gobble% Dat: \@gobble -
\else \leavevmode\nobreak-\hskip\z@skip\fi% Dat: e.g hegyes`-szögû
\else \leavevmode\nobreak-\hskip\z@skip\fi% Dat: e.g hegyes`-szögû
\fi
}
\@@magyar@declare@shorthandx -{\futurelet\@Lang@tmp\@@magyar@shorthandminus}%
%** A hyphen that is displayed in both next and current lines. Hyphenation
%** is OK at both sides. This differs from ukraineb.ldf.
%** \showhyphens{nátrium`|klorid} -> nát-ri-um--klo-rid
\@@magyar@declare@shorthandx |{\leavevmode\nobreak-\nobreak\discretionary{}{-}{}\nobreak\hskip\z@skip}% Dat: all \nobreak s are important % e.g egyszer`|kétszer
%** \showhyphens{nátrium`|klorid} -> nát-ri-um--klo-rid
\@@magyar@declare@shorthandx |{\leavevmode\nobreak-\nobreak\discretionary{}{-}{}\nobreak\hskip\z@skip}% Dat: all \nobreak s are important % e.g egyszer`|kétszer
\@@magyar@declare@shorthandx _{\leavevmode\nobreak\-\nobreak\hskip\z@skip}
\@@magyar@declare@shorthandx <{\flqq}
\@@magyar@declare@shorthandx >{\frqq}
@ -2845,7 +2845,7 @@
\else\if\noexpand#1eE%
\else\if\noexpand#1hH%
\else\if\noexpand#1kK%
\else\if\noexpand#1mM% mínusz
\else\if\noexpand#1mM% mínusz
\else\if\noexpand#1nN%
\else\if\noexpand#1oO%
\else\if\noexpand#1sS% sokadik
@ -2854,7 +2854,7 @@
\fi\fi\fi\fi\fi\fi\fi\fi\fi
}
%** For \pagenumbering{huordinal}. Expands to the Hungarian ordered numeral,
%** spelled out in letters (i.e 1 --> first --> elsõ). Suitable for numbering
%** spelled out in letters (i.e 1 --> first --> elsõ). Suitable for numbering
%** \part{}s and \chapter{}s of a book (\def\thepart{\@Huordinal\c@part}})
%** @param #1 a number (input for \number) in -9999..9999
\def\@huordinal#1{%
@ -2874,11 +2874,11 @@
\ifnum#1#2>9999 sokadik\else
\@@magyar@egyjegyu#1%
\ifnum#2=0 ezredik\else
ezer\ifnum#1>1 -\fi% kétezer-harmadik
ezer\ifnum#1>1 -\fi% kétezer-harmadik
\ifnum#2<100
\expandafter\@@magyar@tizesedik\number#2%
\else
\ifnum#2<200 egy\fi% ezerszázadik -> ezeregyszázadik
\ifnum#2<200 egy\fi% ezerszázadik -> ezeregyszázadik
\@@magyar@szazasodik#2%
\fi
\fi
@ -2905,7 +2905,7 @@
\else\ifnum#1#2=20 huszadik%
\else\ifnum#1#2>10 tizen\@@magyar@egyesedik#2.%
\else\ifnum#1#2=10 tizedik%
\else \@@magyar@egyesedik#2a% ``kétszázadik''
\else \@@magyar@egyesedik#2a% ``kétszázadik''
\fi\fi\fi\fi\fi\fi\fi\fi\fi\fi\fi
}%
\def\@@magyar@egyesedik#1#2{%
@ -2923,7 +2923,7 @@
\def\Huordinal#1{\expandafter\@Huordinal\csname c@#1\endcsname}
%** For \pagenumbering{hunumeral}. Expands to the Hungarian ordered numeral,
%** spelled out in letters (i.e 1 --> first --> elsõ). Suitable for numbering
%** spelled out in letters (i.e 1 --> first --> elsõ). Suitable for numbering
%** \part{}s and \chapter{}s of a book (\def\thepart{\@Hunumeral\c@part}})
%** @param #1 a number (input for \number) in -9999..9999
\def\@hunumeral#1{%
@ -2940,11 +2940,11 @@
\ifnum#1#2>9999 sokadik\else
\@@magyar@egyjegyu#1%
\ifnum#2=0 ezer\else
ezer\ifnum#1>1 -\fi% kétezer-harmadik
ezer\ifnum#1>1 -\fi% kétezer-harmadik
\ifnum#2<100
\expandafter\@@magyar@tiz\number#2%
\else
\ifnum#2<200 egy\fi% ezerszázadik -> ezeregyszázadik
\ifnum#2<200 egy\fi% ezerszázadik -> ezeregyszázadik
\@@magyar@szaz#2%
\fi
\fi
@ -2971,7 +2971,7 @@
\else\ifnum#1#2=20 h\'usz%
\else\ifnum#1#2>10 tizen\@@magyar@egy#2%
\else\ifnum#1#2=10 t\'iz%
\else \@@magyar@egy#2% ``kétszázadik''
\else \@@magyar@egy#2% ``kétszázadik''
\fi\fi\fi\fi\fi\fi\fi\fi\fi\fi\fi
}%
\def\@@magyar@egy#1{%
@ -3062,7 +3062,7 @@
\def\@@magyar@suffix@A#1#2{%
\ifcase#2 \'a\or j\'e\or \'a\or \'a\or \'e\or \'e\or \'a\or \'e\or \'a\or \'e\or \'e\or \'e\or \'e\or \'a\or \'e\or \'a\or\'a\or\'a\or\'a\or\'e\or\'a\fi
\ifx#1\@@magyar@suffix@at t\else
\ifx#1\@@magyar@suffix@an n\else% Dat: suffix overload: 2-a-an => 2-án
\ifx#1\@@magyar@suffix@an n\else% Dat: suffix overload: 2-a-an => 2-án
\expandafter#1\ifcase#2 3\or 1\or 1\or 3\or 1\or 1\or 3\or 1\or 3\or 1\or 1\or 1\or 1\or 3\or 1\or 3\or 3\or 3\or 3\or 1\or 3\fi
\fi\fi
}%
@ -3458,23 +3458,23 @@
%** \refstruc doesn't work inside it, because \refstruc isn't expandable
%** @example \told4+a+a+a+a+adik raises strange error
%** @example no -en is provided for -an/-on, to avoid ambiguity
%** @example \told4+adik: 0-adik 1-sõ 2-odik 3-adik 12-edik 10^8-adik
%** @example \told4+adik: 0-adik 1-sõ 2-odik 3-adik 12-edik 10^8-adik
%** @example augusztus \told20-a: 1-je 2-a 3-a 4-e 5-e 6-a ... (augusztus 20-a)
%** @example \told3+as: 0-s(??) 1-es 2-es 3-as 4-es 5-ös 10^6-s
%** @example \told0+ad: 0-ad 1-ed 2-ed 3-ad 5-öd 10^6-ad
%** @example \told1000+hoz: 0-hoz 3-hoz 6-hoz 8-hoz 100-hoz 10^6-hoz 10^9-hoz 1-hez 4-hez 7-hez 9-hez 10-hez 1000-hez 2-höz 5-höz
%** @example \told3+as: 0-s(??) 1-es 2-es 3-as 4-es 5-ös 10^6-s
%** @example \told0+ad: 0-ad 1-ed 2-ed 3-ad 5-öd 10^6-ad
%** @example \told1000+hoz: 0-hoz 3-hoz 6-hoz 8-hoz 100-hoz 10^6-hoz 10^9-hoz 1-hez 4-hez 7-hez 9-hez 10-hez 1000-hez 2-höz 5-höz
%** @example \told5+an: 5-en 2-en 100-an 10^6-n
%** @example \told5+on: 5-ön 2-n 3-on 100-on 10^6-n
%** @example \told0+at: 0-t 2-t 10^6-t 1-et 4-et 7-et 9-et 10-et 1000-et 3-at 8-at 6-ot 10^9-ot 5-öt
%** @example \told5+on: 5-ön 2-n 3-on 100-on 10^6-n
%** @example \told0+at: 0-t 2-t 10^6-t 1-et 4-et 7-et 9-et 10-et 1000-et 3-at 8-at 6-ot 10^9-ot 5-öt
%** @example \told1000+ban: 1000-ben
%** @example \told7+ba: 7-be
%** @example \told5+nak: 7-nek
%** @example \told2+ra: 2-re
%** @example \told4+nal: 4-nél
%** @example \told7+bol: 7-bõl
%** @example \told5+tol: 5-tõl
%** @example \told3+rol: 3-ról
%** @example \told2+ul: 0-ul 1-ül 2-ül 3-ul
%** @example \told4+nal: 4-nél
%** @example \told7+bol: 7-bõl
%** @example \told5+tol: 5-tõl
%** @example \told3+rol: 3-ról
%** @example \told2+ul: 0-ul 1-ül 2-ül 3-ul
%** @example \told5+odik+hoz
%** @example \told{300}+szor
%** @example -i and -ig don't change have alternate forms
@ -3687,7 +3687,7 @@
}
\let\@@magyar@toldas\@gobble
\def\@@magyar@strucname@part{r\'esz\@@magyar@toldas{4}}% SUXX: may not contain \-; !! résszel (vs. részszel)
\def\@@magyar@strucname@part{r\'esz\@@magyar@toldas{4}}% SUXX: may not contain \-; !! résszel (vs. részszel)
\def\@@magyar@strucname@chapter{fejezet\@@magyar@toldas{9}}% !! fejezettel
\def\@@magyar@strucname@appendix{f\"ug\-gel\'ek\@@magyar@toldas{4}}% !! fuggelekkel
\def\@@magyar@strucname@section{szakasz\@@magyar@toldas{20}}%
@ -3697,13 +3697,13 @@
\def\@@magyar@strucname@paragraph{bekezd\'es\@@magyar@toldas{4}}%
\def\@@magyar@strucname@subparagraph{albekezd\'es\@@magyar@toldas{4}}%
\def\@@magyar@strucname@subsubparagraph{alalbekezd\'es\@@magyar@toldas{4}}%
\def\@@magyar@strucname@figure{\'ab\-ra\@@magyar@toldas{4}}% !! ábrában etc.
\def\@@magyar@strucname@figure{\'ab\-ra\@@magyar@toldas{4}}% !! ábrában etc.
\def\@@magyar@strucname@table{t\'ab\-l\'azat\@@magyar@toldas{6}}%
\def\@@magyar@strucname@equation{egyenlet\@@magyar@toldas{7}}%
\def\@@magyar@strucname@footnote{l\'ab\-jegy\-zet\@@magyar@toldas{7}}%
\def\@@magyar@strucname@item{elem\@@magyar@toldas{4}}% !! elemmel etc.
\def\@@magyar@strucname@FancyVerbLine{sor\@@magyar@toldas{8}}% !! sorral
\def\@@magyar@strucname@theorem{t\'e-tel\@@magyar@toldas{4}}% !! tétellel
\def\@@magyar@strucname@theorem{t\'e-tel\@@magyar@toldas{4}}% !! tétellel
%** Must be expandable.
%** @param #1 `section' etc.
@ -4042,21 +4042,21 @@
%** Usage: \magyar@emitdate{FMT}{DATE} or \magyar@emitdate[SUFFIX]{FMT}{DATE}
%** @example [\emitdate{b}{October 25, 2003}]
%** @example %[\emitdate{b}{x-y-z}]% ! Package magyar.ldf Error: Unrecognised date: x-y-z.
%** @example A mai dátum: [\emitdate{b}{\today}].
%** @example A mai dátum: [\emitdate{b}{\today}].
%** @example [\emitdate[e]{g}{1848.15.3}] a nap, mikor elhangzott a Nemzeti dal.
%** @example [\emitdate{b}{1956-10-23}]
%** @example \told{\@@magyar@date@g{1848}{3}{115}}+a{}
%** @param SUFFIX any suffix for \told, e.g `e' or `adik+an'
%** @param DATE date in any format, will be expanded
%** @param FMT a single letter, specifies the format of the emitted date
%** a: 1848-03-15 (ISO dátumformátum, 2002-tõl(?) a magyar helyesírás része)
%** b: 1848.\ március 15.
%** c: 1848.\ márc.\ 15.
%** a: 1848-03-15 (ISO dátumformátum, 2002-tõl(?) a magyar helyesírás része)
%** b: 1848.\ március 15.
%** c: 1848.\ márc.\ 15.
%** d: 1848.\ III.\ 15.
%** e: 1848.\ 03.\ 15.
%** f: 1848. március közepe
%** g: 1848. március 15[-e reggele]
%** h: 1848 március [hónapjának közepe, márciusának közepe, márciusában stb.] birtokos rag
%** f: 1848. március közepe
%** g: 1848. március 15[-e reggele]
%** h: 1848 március [hónapjának közepe, márciusának közepe, márciusában stb.] birtokos rag
%** english.ldf: `October 25, 2003' or [UK]: `25th October 2003'
\def\@@magyar@emitdate{%
\@ifnextchar[\@@magyar@emitdate@opt{\@@magyar@emitdate@opt[]}%]
@ -4275,7 +4275,7 @@
\fi
}
% `Szerkesztõk és szerzõk kézikönyve, p. 116' says this about Hungarian
% `Szerkesztõk és szerzõk kézikönyve, p. 116' says this about Hungarian
% footnotes. Implementation notes are marked with [...]. See better docs
% in magyarldf-doc.tex
%
@ -5439,7 +5439,7 @@
% vvv cjhebrewfix= % by pts@fazekas.hu at Tue Apr 19 18:26:54 CEST 2005
% thanks to Zoltán Hamar for reporting the problem
% thanks to Zoltán Hamar for reporting the problem
% Dat: the ultimate solution is active=onlycs, but it limits other
% functionality
% Dat: use \def\h{\cjRL} in the preamble to abbreviate \cjRL
@ -5619,7 +5619,7 @@
% !! doc: (\string!)
% !! doc: \umlautlow is much more important in OT1 cmr fonts than in T1
% !! %** @example értelmezés\/beállítás
% !! %** @example értelmezés\/beállítás
% \def\per{/\penalty\exhyphenpenalty\hskip\z@skip}
% !! \itemize identation
% !! layout.sty
@ -5639,19 +5639,19 @@
% % ^^^ \def`{\abbreviation}, but with active `
% \@@magyar@saved@mathoptions@on
%}
% !! doc: hegyes`-szögû
% !! doc: hegyes`-szögû
% !! option to detect new magyar.ldf from a TeX file
% !! book.cls \appendix \chapter, sub-numbers into TOC, need dot after `A. függelék'? Gyurgyák recommends `1. függelék'.
% !! book.cls \appendix \chapter, sub-numbers into TOC, need dot after `A. függelék'? Gyurgyák recommends `1. függelék'.
% !! \MathReal, frenchb.ldf, \nombre
% !! \told\ref{foo}+ban{}, if \foo expands to empty (no \section etc. in .tex file)
% !! french.ldf number decimal comma etc.
% !! \hunnewlabel should store `table', `figure', `section', `equation' etc.
% !! letter.cls
% !! should \newlabel emit a `.' ? (now doesn't) -- compatibility
% `\aref{ekezetek}.\ táblázat' needs explicit `.'
% `\aref{ekezetek}.\ táblázat' needs explicit `.'
% !! alternative solutions for meny-nyi (possibly defining ligatures?)
% !! baseline grid?
% !! Bujdosó`--Wettl: http://www.math.bme.hu/~wettl/plcv/pdf/BWfinal.pdf
% !! Bujdosó`--Wettl: http://www.math.bme.hu/~wettl/plcv/pdf/BWfinal.pdf
% !! some comments not related to magyar.ldf, but to *hyph.tex etc.
% !! add their postpara symbols
% !! section title sizes
@ -5690,7 +5690,7 @@
% !! tmagyar.tex \tableofcontents wide \section
% !! \restoreparindent in \item in \itemize
% \edef\restoreparindent{\parindent\the\parindent\relax} in \@listi
% !! 1848 március+ának közepe
% !! 1848 március+ának közepe
% !! should \told insert \, ?? (no, only \told*??)
% !! \told45{-ed-hez} ??
% !! \told{45}-ed-hez ??
@ -5710,8 +5710,8 @@
% <inserted text>
% \par
% l.48 Ld. \ref{tab}
% !! > Kipróbáltam, s tényleg pontosan ugyanaz a fájl magyar.ldf (texmf fában) és
% > magyar-0510.ldf (aktuális könyvtárban) néven más eredményt ad.
% !! > Kipróbáltam, s tényleg pontosan ugyanaz a fájl magyar.ldf (texmf fában) és
% > magyar-0510.ldf (aktuális könyvtárban) néven más eredményt ad.
% (cjhebrew)
% !! a4wide.sty doesn't compile
% \documentclass[12pt,a4paper]{article}
@ -5729,10 +5729,10 @@
% !! doc: `- not suitable in .bib files etc.
% !! \cite{foo,bar} -> `[2, 1]' increasing order preferred
% Imp: indent using the maximum footnotemark *** count on the current page
% Imp: generate ,,harmincháromból'' by \told{\@huordinal{33}}+bol etc.
% Imp: generate ,,harmincháromból'' by \told{\@huordinal{33}}+bol etc.
%
% Dat: \mathcode`\,="013B % és így a tizedes törtekben matematikai módban sem lesz köz
% Dat: \mathchardef\comma="613B % a veszõ (,) ami matematikai módban elválasztó karakterként használható
% Dat: \mathcode`\,="013B % és így a tizedes törtekben matematikai módban sem lesz köz
% Dat: \mathchardef\comma="613B % a veszõ (,) ami matematikai módban elválasztó karakterként használható
% Dat: additive \PassOptionsToPackage{foo=bar}{magyar.ldf}
% Dat: for book.cls and article.cls: the user has to run \pagestyle{headings} after \selectlanguage{magyar} -- for performance reasons
% Dat: doc: \let\@@magyar@setup@psheadings\relax maybe needed in the preamble
@ -5759,17 +5759,17 @@
% \usepackage[hungarian,magyar]{babel}
% Dat: argument of \az and \told may not contain \if..., \else and \fi
% OK: works with article.cls: (mathbrk=fix)
% \noindent és ebbõl a további három rész területe
% \noindent és ebbõl a további három rész területe
% $\displaystyle{1\over3}-{1\over 4}={1\over 12}$,
% $\displaystyle{1\over 2}-{1\over 4}={1\over 4}$ és
% $\displaystyle{1\over 2}-{1\over 4}={1\over 4}$ és
% $\displaystyle{1\over 4}+\bigg({1\over 2}-{1\over 3}\bigg)={1\over 4}+{1\over 6}}=\displaystyle{5\over 12}$
% területegység.
% területegység.
% OK: doc in magyarldf-doc.tex: enumeration in math, see $a,\ b$ in nath.sty
% OK: mathbrk=fix +\\+ (all binary ops and relations) in math, \nobreak\cdot, \nobreak\slash
% OK: footnote text indented, asterisks on pages
% OK: Kiss Elõd\nobreak\,\nobreak--\,Nagy Pál ...
% OK: Kiss Elõd\nobreak\,\nobreak--\,Nagy Pál ...
% OK: \partname in book.cls (seems to work now)
% OK: Elsõ rész
% OK: Elsõ rész
% OK: smartly disable active chars in preamble
% OK: \@inpenc@undefined defined and != latin2 => recommend \usepackage[latin2]{inputenc}
% OK: \encodingdefault != T1 => recommend \usepackage{t1enc}
@ -5781,17 +5781,17 @@
% OK: compatibility with latex.ltx, theorem.sty, ntheorem.sty, amsthm.sty
% OK: \PackageWarning if \magyarOptions defined too late
% OK: like frenchb.ldf \declare@shorthand{french}{;}{
% OK: \told\ref{hellopart}+es{} részt olvasd el.
% OK: \told\ref{hellopart}+es{} részt olvasd el.
% OK: \told appends suffixes to numbers
% OK: activeacute, activegrave babel options
% OK: even more parts made conditional
% OK: \@hunumeral \@huordinal \@Hunumeral \@Huordinal
% OK: negative numbers \told-5-nek, `mínusz kettedik' etc.
% OK: negative numbers \told-5-nek, `mínusz kettedik' etc.
% OK: magyar.ldf defaults=hu-min (mathbrk=define) $x+116=\break x-97$ adds space only to BOL; added \nobreak before \discretionary -- and the problem was solved
% OK: fixed. varioref.sty (2001/09/04 v1.3c) mustn't be loaded with option
% [magyar], because that option contains a stupid \AtBeginDocument hook
% added to \extrasmagyar
% OK: Bujdosó`--Wettl: add their {itemize} symbols and {enumerate} styles
% OK: Bujdosó`--Wettl: add their {itemize} symbols and {enumerate} styles
% OK: spacing around excl. marks in math mode ! closing(5) -> punct(6)
% better solution (found in nath.sty): \def!{\mathchar20513\relax\mathopen{}\mathinner{}},
% because it doesn't need braces

21
src/thesis.tex
View File

@ -8,9 +8,7 @@
% Set the main variables
\newcommand{\vikszerzoVezeteknev}{Torma}
\newcommand{\vikszerzoKeresztnev}{Krist\'of}
\newcommand{\tdkszerzoB}{Pünkösd Marcell}
\newcommand{\vikszerzoKeresztnev}{Kristóf}
\newcommand{\vikkonzulensAMegszolitas}{Dr.~}
\newcommand{\vikkonzulensAVezeteknev}{Maliosz}
@ -26,10 +24,10 @@
\newcommand{\vikcim}{Madárhang azonosító és riasztó felhő-natív rendszer} % Cím
\newcommand{\viktanszek}{\bmetmit} % Tanszék
\newcommand{\vikdoktipus}{\msc} % Dokumentum típusa (\bsc vagy \msc)
\newcommand{\vikdoktipus}{\tdk} % Dokumentum típusa (\bsc vagy \msc)
\newcommand{\vikmunkatipusat}{szakdolgozatot} % a "hallgató nyilatkozat" részhez: szakdolgozatot vagy diplomatervet
%\input{include/tdk-variables}
\input{include/tdk-variables}
%\newcommand{\szerzoMeta}{\vikszerzoVezeteknev{} \vikszerzoKeresztnev} % egy szerző esetén
\newcommand{\szerzoMeta}{\vikszerzoVezeteknev{} \vikszerzoKeresztnev, \tdkszerzoB} % két szerző esetén
@ -57,8 +55,8 @@
%Titlepage -- choose one from below
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\input{include/titlepage} % Szakdolgozat/Diplomaterv címlap
%\include{include/titlepage-tdk} % TDK címlap
%\input{include/titlepage} % Szakdolgozat/Diplomaterv címlap
\include{include/titlepage-tdk} % TDK címlap
%\include{include/titlepage-otdk} % OTDK címlap
@ -67,6 +65,7 @@
\tableofcontents\vfill
\clearpage
\onehalfspacing
% Declaration and Abstract
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -81,14 +80,14 @@
%import your own content
\input{content/introduction}
\input{content/theory}
\input{content/preparation}
\input{content/results}
\input{content/architecture}
\input{content/benchmarks}
\input{content/closing}
% Acknowledgements
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\input{content/acknowledgement}
%\input{content/acknowledgement}
% List of Figures, Tables
@ -104,7 +103,7 @@
% Appendix
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\input{content/appendices}
%\input{content/appendices}
%\label{page:last}
\end{document}