Spelling suggestions: "subject:"apache blink StateFun"" "subject:"apache plink StateFun""
1 |
Improving Availability of Stateful Serverless Functions in Apache Flink / Förbättring av Tillgänglighet För Tillståndsbaserade Serverlösa Funktioner i Apache FlinkGustafson, Christopher January 2022 (has links)
Serverless computing and Function-as-a-Service are rising in popularity due to their ease of use, provided scalability and cost-efficient billing model. One such platform is Apache Flink Stateful Functions. It allows application developers to run serverless functions with state that is persisted using the underlying stream processing engine Apache Flink. Stateful Functions use an embedded RocksDB state backend, where state is stored locally at each worker. One downside of this architecture is that state is lost if a worker fails. To recover, a recent snapshot of the state is fetched from a persistent file system. This can be a costly operation if the size of the state is large. In this thesis, we designed and developed a new decoupled state backend for Apache Flink Stateful Functions, with the goal of increasing availability while measuring potential performance trade-offs. It extends an existing decoupled state backend for Flink, FlinkNDB, to support the operations of Stateful Functions. FlinkNDB stores state in a separate highly available database, RonDB, instead of locally at the worker nodes. This allows for fast recovery as large state does not have to be transferred between nodes. Two new recovery methods were developed, eager and lazy recovery. The results show that lazy recovery can decrease recovery time by up to 60% compared to RocksDB when the state is large. Eager recovery did not provide any recovery time improvements. The measured performance was similar between RocksDB and FlinkNDB. Checkpointing times in FlinkNDB were however longer, which cause short periodic performance degradation. The evaluation of FlinkNDB suggests that decoupled state can be used to improve availability, but that there might be performance deficits included. The proposed solution could thus be a viable option for applications with high requirements of availability and lower performance requirements. / Serverlös datorberäkning och Function-as-a-Service (FaaS) ökar i popularitet på grund av dess enkelhet att använda, skalbarhet och kostnadseffektiva fakturerings-model. En sådan platform är Apache Flink Stateful Functions. Den tillåter applikationsutvecklare att köra serverlösa funktioner med varaktigt tillstånd genom den underliggande strömprocesseringsmotorn Apache Flink. Stateful Functions använder en inbyggd RocksDB tillståndslagring, där tillstånd lagras lokalt på arbetarnoderna. Ett problem med denna arkitektur är att tillstånd förloras om en arbetarnod krashar. För att återhämta sig behöver systemet hämta en tidigare sparad tillståndskopia från ett varaktivt filsystem, vilket kan bli kostsamt om tillståndet är stort. I denna uppsatts har vi designat och utvecklat en ny prototyp för att separat hantera tillstånd i Apache Flink Stateful Functions, med målet att öka tillgängligheten utan att förlora prestanda. Prototypen är en vidareutveckling av en existerande separat tillståndshantering för Flink, FlinkNDB, som utökades för att kunna hantera Stateful Functions. FlinkNDB sparar tillstånd i en separat högtillgänglig database, RonDB, istället för att spara tillstånd lokalt på arbetarnoderna. Detta möjliggör snabb återhämtning då inte stora mängder tillstånd behöver skickas mellan noder. Två återhämtningsmetoder utvecklades, ivrig och lat återhämtning. Resultaten visar att lat återhämtning kan sänka återhämtningstiden med upp till 60% jämfört med RocksDB då tillståndet är stort. Ivrig återhämtning visade inte några förbättringar i återhämtningstid. Prestandan var liknande mellan RocksDB och FlinkNDB. Tiden för checkpoints var däremot längre för FlinkNDB vilket orsakade korta periodiska prestandadegraderingar jämfört med RocksDB. Evalueringen av FlinkNDB föreslår att separat tillståndshantering kan öka tillgängligheten av Stateful Functions, men att detta kan innebära vissa prestanda degraderingar. Den föreslagna lösningen kan således vara ett bra alternativ när det finns höga krav på tillgänglighet, men lågra krav på prestanda.
|
Page generated in 0.0659 seconds