Container-Based Cloud Platform For Mobile Computation .

Transcription

2017 IEEE International Parallel and Distributed Processing SymposiumContainer-Based Cloud Platform for MobileComputation Offloading Song Wu , Chao Niu , Jia Rao† , Hai Jin and Xiaohai Dai Services Computing Technology and System Lab, Cluster and Grid Computing LabSchool of Computer Science and Technology, Huazhong University of Science and Technology Wuhan, 430074, ChinaEmail: {wusong, chaoniu, hjin, seafooler}@hust.edu.cn† The University of Texas at Arlington, USAEmail: jia.rao@uta.eduAbstract—With the explosive growth of smartphones andcloud computing, mobile cloud, which leverages cloud resourceto boost the performance of mobile applications, becomes attractive. Many efforts have been made to improve the performanceand reduce energy consumption of mobile devices by offloadingcomputational codes to the cloud. However, the offloading costcaused by the cloud platform has been ignored for many years.In this paper, we propose Rattrap, a lightweight cloud platformwhich improves the offloading performance from cloud side. Toachieve such goals, we analyze the characteristics of typical offloading workloads and design our platform solution accordingly.Rattrap develops a new runtime environment, Cloud AndroidContainer, for mobile computation offloading, replacing heavyweight virtual machines (VMs). Our design exploits the ideaof running operating systems with differential kernel featuresinside containers with driver extensions, which partially breaksthe limitation of OS-level virtualization. With proposed resourcesharing and code cache mechanism, Rattrap fundamentallyimproves the offloading performance. Our evaluation showsthat Rattrap not only reduces the startup time of runtimeenvironments and shows an average speedup of 16x, but alsosaves a large amount of system resources such as 75% memoryfootprint and at least 79% disk capacity. Moreover, Rattrapimproves offloading response by as high as 63% over the cloudplatform based on VM, and thus saving the battery life.cloud are the long VM startup time and high virtualizationoverhead. Interactivity and mobility are the keys to thesuccess of mobile cloud computing, but heavyweight VMsolutions cannot meet these requirements [5, 6]. Though prestarting VMs can reduce the VM startup time, it wouldinevitably incur high resource cost because the number ofoffloading requests is probably large [4].OS-level virtualization, a.k.a, container-based virtualization[7–10] has recently attracted much attention due to its nearnative performance and low virtualization overhead. Building a mobile cloud using container-based virtualization isa promising idea, but presents several challenges. First, thecontainer must run the same OS as the host. Much effortis needed to customize a container to support mobile apps.Second, OS containers offer less isolation between mobileOSes, making it possible to exploit optimizations betweenmobile apps to further improve performance. However, therelacks a comprehensive study of offloading performance toguide the optimizations.In this paper, we address the above two challenges anddesign Rattrap, a mobile offloading cloud platform based onOS containers. To support the execution of mobile apps inthe cloud, we develop Cloud Android Container, a mobileOS environment built directly on general purpose server OS.We perform a comprehensive study of offloading performance in representative mobile workloads, which motivatesthe development of two optimizations for mobile offloading:shared resource layer between multiple apps and mobilecode cache. Experimental results using LXC container andAndroid apps show significant performance improvement oncode offloading compared to VM-based cloud platforms. Thestartup time of the mobile OS is reduced from more than 28susing VMs to less than 2s with Cloud Android Container.Our container-based cloud saves as much as 75% memoryfootprint and at lease 79% disk usage by hosting the mobileOS in the cloud. Moreover, the performance of code executionhas been improved by as much as 40%. In summary, thispaper makes the following contributions: We discuss the behaviors of mobile cloud applications,characterize representative offloading workloads, andsummarize the problems current cloud platform faces.These provide the guidelines of how to make the cloudside better serve offloading requests.I. I NTRODUCTIONMobile cloud computing, which offloads computation onmobile devices to a cloud platform, can enable executionof computationally intensive applications on mobile deviceswith enhanced user experience.The challenges lie in how toseamlessly integrate mobile runtime environments into cloudplatforms and how to perform mobile computation offloadingin a cost-effective manner. Existing work mainly focused onthe design of code offloading frameworks and addressed theissues of code partitioning, offloading decision and methodology. The design of a cloud platform to support mobilecomputation offloading has largely been ignored. Previousstudies assumed that computation from the cloud is ubiquitousand always ready to use.Many practical issues arise when building a real mobilecloud. The cloud should provide on-demand execution environments for mobile computation codes, e.g., the Androidmobile OS. Many offloading studies [1–4] used virtual machines (VMs) to host mobile OS in the cloud. Hardwarevirtualization allows different guest OSes to co-exist in thecloud platform. The main drawbacks of using VMs in mobile1530-2075/17 31.00 2017 IEEEDOI 10.1109/IPDPS.2017.47123

We devise the idea of dynamically extending the hostOS kernel with mobile OS drivers and make the mobilecloud platform based on OS-level virtualization cometrue. By implementing drivers for various kernel features,containers can run certain different OSes, which partiallybreaks the kernel limitation of OS-level virtualization.With containers running mobile environments, we propose a set of techniques to improve its efficiency, including customization of mobile OS, sharing commonresources, and code cache mechanisms, which makes ourwork no longer a simple code runtime environment.III. W ORKLOAD A NALYSISIn this section, we perform a characterization of benchmarkapplications in used in previous mobile offloading research,and discuss the problems of existing cloud platforms based onVM. As will be discussed later in Section IV, these findingsabout offloading workloads motivated our system design.A. Experiment SetupIn this series of experiments, four representative Androidapplications of four different categories, which have beenwidely adopted by previous researches [1, 12–14], are usedas our benchmark workloads. Image tools are the most common benchmarks usedin previous researches and represent the computationintensive workloads with file transfer. OCR (OpticalCharacter Recognition) is based on the Google Tesseractlibrary whose real computation is implemented with JavaNative Interface (JNI) code written in C . Games interact with user continually, representing workloads with intensive network communications. ChessGame is an Android port of the CuckooChess Enginewhich ranks top 200 in Computer Chess Rating Lists40/401 . Anti-Virus has been adopted increasingly since the rapidmalware emergence. VirusScan checks the target withvirus database search and spawns more I/O requests thanother benchmarks. Mathematical tools, like Linpack, are implemented inordinary Android Java. They are often used to representpure computation.The client applications run on 5 Android devices and usethe Java reflection techniques to enable the offloading ofcomputation codes. The mobile code runtime environmentson the cloud is based on Android-x86 [16] VM. More detailsabout experimental settings, like the configuration of cloudservers, can be found in Section VI.II. BACKGROUNDA. Basic Offloading MechanismWith the rise of mobile cloud computing, the idea ofoffloading computation has been a research hotspot for a longtime. Unlike existing mobile applications which run locallyand directly request data from content providers, mobiledevices can offload parts of the workloads to the cloud,making cloud a powerful worker to process computationtasks. Generally, a basic offloading system [2, 3, 11–14]is composed of two parts. The client side runs on mobiledevices, which controls offloading computational code to thecloud when needed. The cloud side is responsible for handlingoffloading requests and provides runtime environments.Much research effort has been duplicating mobile runtimeenvironments in the cloud to support offloading. To achievethis, many frameworks [2, 3] leverage the virtualizationtechnology, namely mobile OS virtual machine. The cloudplatforms in these frameworks have nearly the same runtimeenvironments as mobile devices, which makes it straightforward to run mobile code on the cloud side. However, to usea VM instance, the cloud has to install and boot a guest OSin the VM, which incurs substantial delay. For example, aStandard Medium instance (m1.medium) on Amazon EC2 hasan average setup time of 28.4 seconds, which is undesirablefor mobile requests. Therefore, on-demand deploying VMs isan expensive operation and not suitable for real-time mobileoffloading [6].B. Performance Penalty of Runtime PreparationAs described in [6], the key reason that existing cloudapproaches are not suitable for mobile cloud applications isthe unacceptable long startup time of VMs. In this section, weadopt all 4 workloads and evaluate how runtime preparationaffects the performance. The experiment is performed withstable LAN WiFi, in which we suppose the best networkenvironment is provided and take no account of the instabilityof network.We divide the process of offloading into 4 phases. Computation Execution is the pure execution stage of offloadedtasks on the cloud. Runtime Preparation is the setup phase formobile code runtime after the offloading requests arrive. Network Connection is the process of establishing a connectionbetween mobile devices and cloud resources. Data Transferis the time spent to transfer necessary data for offloadingtasks. Figure 1 shows phase details and offloading speedups ofB. OS-level VirtualizationWhile the traditional system virtualization provides strongfault isolation, OS-level virtualization is much more efficient,especially for server consolidation. Containers, as the center of OS-level virtualization, have recently emerged as alightweight alternative to hypervisor-based virtualization [15].Unlike virtual machines, containers usually imposes muchless overhead, since they share the host OS kernel and donot suffer the overhead of resource virtualization.Unfortunately, the requirement of sharing host OS kernelmakes OS-level virtualization unsuitable for mobile cloud, asgeneral purpose OSes are incompatible with the mobile OSand does not support running mobile code. This limitation isa vital challenge of designing a container-based platform formobile cloud computing.1 http://www.computerchess.org.uk/ccrl/4040/124

10 01500010000300002500010 02000015000100005000Mobile Code0510Request(#)152010 -100(a) OCR51015Request(#)20Control MessageVirusScan1.250000File and Parameter1.4Normalized Composition3500025000200001Computation Execution 10Runtime PreparationNetwork ConnectionData TransferOffloading Speedup40000Offloading SpeedupTime(ms)3000010 1Time(ms)Computation ExecutionRuntime PreparationNetwork ConnectionData TransferOffloading Speedup35000Offloading Speedup4000010 -1(b) ChessGameOCRChessLinpack10.80.60.40.2300003000010 0250002000015000250002000010 01500010000000510Request(#)152010 -1005(c) VirusScan1015Request(#)20In this subsection, we analyze the impact of offloadingon cloud server load in previous experiments, and discussthe properties of offloading tasks. Figure 2 describes thetimeline graphs (with one second granularity) of CPU andI/O utilization on the cloud server.Observation 2: During the boot of VMs (0-30s), the serverloads show similarities between different workloads. After thestage of runtime preparation, offloading tasks are handled andthe CPU load increases to 100% once new request arrives. InChessGame, the computation are relatively small, leading tothe high fluctuation in the CPU load.In terms of system I/O load, after the startup, it appears anI/O increase for a short period of time because of receivingmobile codes and loading them into runtime by ClassLoader2 .After this, workloads show different I/O loads. OCR andVirusScan, which demand more migrated data for execution,incur short-term I/O boosts when requests arrive. In contrast,other workloads call for few data transfer and bring aboutsmall I/O loads.Implication 2: The experiment results suggest that most ofoffloading tasks are computation-intensive jobs initially andfollowed by a short-term I/O-bound phase. Considering theperformance loss caused by VMs, especially the overheadof I/O virtualization, the cloud platform should take bothcomputing performance and I/O performance as the prioritiesof performance improvement.10 -1(d) Linpack3080206040102006090120Timeline [s]150206040100030206040102006090120Timeline [s]6090120Timeline [s]15001801500180CPUI/O ReadI/O Write30100CPU util [%]80(c) VirusScan30(b) ChessGameI/O Write1003030200180Disk I/O [MB/s]I/O ReadI/O Write80(a) OCRCPUI/O Read80206040102000306090120Timeline [s]150Disk I/O [MB/s]30CPU100Disk I/O [MB/s]I/O WriteCPU util [%]I/O ReadDisk I/O [MB/s]CPU100CPU util [%]1 2 3 4 5C. Cloud Server LoadFig. 1. Phase details and offloading speedups when running differentworkloads with the existing cloud platform. The first 20 offloading requestsare investigated.CPU util [%]1 2 3 4 55000500001 2 3 4 5Fig. 3. Composition of migrated data with different workloads.1000001 2 3 4 5VM IdOffloading Speedup350001Computation Execution 10Runtime PreparationNetwork ConnectionData TransferOffloading Speedup35000Time(ms)40000Time(ms)10 1Computation ExecutionRuntime PrepareNetwork ConnectionData TransferOffloading Speedup45000Offloading Speedup500000180(d) LinpackFig. 2. System load in offloading process of different applications.different workloads. Offloading speedup refers to the ratio oflocal execution time and offloading response time. When offloading speedup is larger than 1, code offloading outperformslocal execution; otherwise, we call it an offloading failure.Observation 1: Through Figure 1, it is clearly observedthat each VM encounters a serious offloading failure for thefirst request, which is caused by the long runtime preparation.Each time a new code execution environment is needed, offloading requests have to face the cold start of cloud runtime.Since the cloud platform is based on Android-x86 VM, whichis a relatively heavyweight resource model, the startup timeusually lasts even longer than the pure computation time. Thisleads to poor user experience of mobile apps.D. Duplicate Code TransferWe now look into data transfer in the process of offloading.From Figure 1, we notice that the first computational task inVM comes with significantly more data transfer time, becausethe new runtime lacks the mobile code to be executed. Tounderstand whether all migrated data is necessary, we evaluatethe composition of migrated data of each Android VM oncloud, as shown in Figure 3. The migrated data includesmobile codes to be executed, files and parameters that specifyoffloading tasks and control messages managing offloadingprocedures. Since our offloading framework is based on Javareflection, the mobile codes in the experiment are app files.Observation 3: Through Figure 3, it is clearly observedthat in the process of offloading, the transmission of the sameImplication 1: In light of the above, we believe thatthe long startup time of VMs with mobile OS causes theperformance degradation at the beginning stage of offloadingrequests. Pre-loading VMs is an intuitive way to mitigate suchoffloading failures, but it will inevitably reduce the serverresource utilization and increase the complexity of the system.Leveraging a lightweight and fast-boot cloud resource modelmay change the game.2 lassLoader.html125

mobile codes occurs in every VM. This is because VMs arecompletely isolated and clients have to push mobile codes intoeach one of them. For workloads which require no additionalfile transfer, like ChessGame and Linpack, the mobile codeaccounts for more than 50% of migrated data. The duplicatecode transfer causes the long data transfer time every time anew VM is started. We also find that the migrated data size ofsingle request is relatively small due to the limit on networkbandwidth of mobile devices.Implication 3: The duplicate data transfer in existingframeworks is inefficient and ideally the same mobile codeshould be transferred only once. One way to solve thisproblem would be to build the mobile code cache mechanism.)UJK KI[ZOUT ,RU])UTZGOTKX )UTZXUR ,RU]5LLRUGJOTM 8KW[KYZY*OYVGZINKX)UTZGOTKX*( OLO 狥-3UTOZUX 9INKJ[RKX'VV 狣)[YZUSO KJ 59)[YZUSO KJ 59E. Redundancy of Mobile Environments8KW[KYZ HGYKJ 'IIKYY )UTZXURRKXIn this experiment, we carefully profile which part of themobile OS is essential, and which part is less important oreven unnecessary to offloading. After the experiments aboveare finished, we check the last access time of each part ofAndroid OS and try to find which files are never used duringthe offloading process.Observation 4: We find out that 771MB out of 1.1GB files(68.4% of the entire OS) are never accessed by offloadedcodes, which are composed of unnecessary modules andlibraries. Most of them are for the hardware of mobile devices,like Camera support and sensor driver. We also notice thatthe same /system folder occupies 985MB space (87.4% of theentire OS) in each Android VM. This means offloading codesof different applications probably only require a uniformruntime environment on the cloud, while it exists seriousredundancy with current cloud platforms.Implication 4: According to the observation above, itseems to be unwise to run an entire mobile OS in VMsseparately. By removing the unnecessary parts and sharingthe system libraries, we can improve the disk utilization ofcode runtime environment and make it more lightweight. 9NGXKJ8KYU[XIK2G KX5LLRUGJOTM / 5 .UYZ 599NGXKJ2OHXGXOKY8KW[KYZ HGYKJ 'IIKYY )UTZXURRKX)RU[J 'TJXUOJ )UTZGOTKXOTOZ TKZJ \URJ YKX\OIKSGTGMKX MUZK Y YZKSYKX\KX ULLRUGJ IUTZXURRKX9NGXKJ *XO\KXY'VV 狤'VV 狥'VV 狦'VV 狧'VV GXK NU[YK'TJXUOJ )UTZGOTKX *XO\KXFig. 4. Overview of Rattrap architecture.code; Shared Resource Layer packs the shared resources ofcontainers to avoid redundancy and improve performance;App Warehouse implements the code cache mechanism toget rid of duplicate data transfer; and Request-based AccessController secures the cloud platform.In what follows, we will present, in details, the design ofabove core components in Rattrap and handle the followingchallenges: How to deal with the gap between the host OS andAndroid? This is the key step to ensure that CloudAndroid Container actually works on the cloud (§IV-B1). How to adapt Android boot process for container bootand make it as fast as possible? This work meanschanging Android startup procedures from device environments to container environments, while guaranteeingthe efficiency (§IV-B2). How to construct the appropriate OS for mobile computation offloading? Rattrap employs a subset of entireAndroid OS as the runtime environments, just enough tosupport mobile computation offloading (§IV-B3). How to eliminate redundant storage and manage thecommon resources among containers? Shared ResourceLayer considerably reduces the size of single containerby sharing common files, and boosts I/O performancewith sharing offloading I/O (§IV-C). How to implement mobile code cache mechanism? WithApp Warehouse, code cache takes charge of indexing andfetching executed codes for arrived offloading requests(§IV-D).Note that some other components are designed to ensure Rattrap function normally: D

† The University of Texas at Arlington, USA Email: jia.rao@uta.edu Abstract—With the explosive growth of smartphones and cloud computing, mobile cloud, which leverages cloud resource . guide the optimizations. In this paper, we address the above two challenges and . is the time spent