FastContainer: A Homeostatic System Architecture High-speed Adapting Execution Environment Changes

FastContainer: A Homeostatic System Architecture High-speed Adapting Execution Environment Changes

Paper: https://www.computer.org/csdl/proceedings-article/compsac/2019/260701a270/1bwKZwTiA1i

2019 43rd IEEE International Conference on Computer Software & Applications

2019/07/16
SAKURA internet inc.
SAKURA internet Research Center
Senior Resarcher
Ryosuke Matsumoto / matsumotory

Transcript

1. SAKURA internet Inc, (C) Copyright 1996-2019 SAKURA Internet Inc Research Center FastContainer: A Homeostatic System Architecture High-speed Adapting Execution Environment Changes 2019/07/16 Ryosuke Matsumoto 2019 43rd IEEE International Conference on Computer Software & Applications
2. 1. Introduction 2. Load distribution and operation technology 3. FastContainer: Proposed method 4. Experiment 5. Conclusion 2 ໨࣍
3. 1. Introduction
4. • Opportunities for users to express themselves on the internet are increasing • along with the diversification of companies and individuals working on the internet. • For individuals, by spreading contents created using Twitter or Facebook • become possible to increase the number of visits to contents efficiently. • become possible to brand-identify individuals • web hosting services and cloud services are used for individuals to serve web contents 4 Background
5. • OS virtualization technology is important • provide stable and secure execution of multiple execution environments of web applications on a single web server • using a container-type virtualization technology • can manage resources by isolating a user area on a per-process basis • can more efficiently accommodate multiple execution environments than virtual machines can 5 Price reduction and performance improvement
6. • For cloud services, users must implement a mechanism of autoscale • autoscale can withstand access concentration • it is necessary to start up a self-built virtual machine internally or to use an external service • it takes time to do scale processing against burst access concentration • it is difficult for users with insufficient technical knowledge to construct a load distribution mechanism quickly 6 Autoscale problems
7. • on the premise • people with knowledge sufficient to use only the standard web hosting service distribute web contents • without technical expert knowledge • propose a system architecture by which service users need not construct a load distribution system and operate/manage libraries • quickly adapt to changing the execution environment by reactively determining startup of a container in an HTTP request 7 FastContainer: Proposed method
8. 2. Load distribution and operation technology
9. • The server becomes a massive load state and access becomes difficult • The opportunity of valuable content diffusion is missed • In this section, we organize the autoscale and related operation technologies for load balancing • in web hosting service and cloud service 9 In situations in which access is most concentrated
10. • It is difficult to control the resources used on a per-host basis properly or to investigate the cause quickly • The content of the service user is accommodated in a specific web server • Autoscale corresponding to the load is difficult in terms of data consistency • when updating the library, the effect of restarting the server process becomes large • many hosts run on a single server process 10 Web hosting services
11. • although it has a high degree of freedom in terms of being able to design the system individually for load balancing • it requires expert knowledge • cloud providers provide the function of increasing or decreasing instances according to the load • Even if a virtual machine starts up under a high load situation, the process itself for autoscale can not catch up at times of sudden high loads • such as the influence of television broadcasting • often leading to service stoppage 11 Cloud services
12. • can define detailed conditions for scaling by external service cooperation • using containers exists to solve the difficulty of starting time of virtual machines • the startup processing of web application server processes such as Ruby on Rails on containers is still slow • Immediacy is low against a sudden load • a method of activating a virtual machine of an expected amount to some degree is taken in advance • difficult to form an appropriate estimate from the balance of limited costs 12 Related works
13. • determines the computer resource automatically by installing an application by the notation specified by the provider • automatically scaling the computer resource on the provider side under high load such as AWS Lambda • these services are intended for engineers who have technical knowledge • challenging to autoscale after publishing web contents without technical knowledge for users targeted by the web hosting service 13 Related services: Serverless Architecture
14. 3. FastContainer: Proposed method
15. 1. The architecture can scale-up and scale-out instances quickly with a granularity of HTTP request units. 2. The architecture monitors the instance at a granularity of HTTP request units and issue scale processing instruction of the instance. 3. To improve the resource efficiency of servers, the architecture stops unnecessary instances. It can activate the instances with an HTTP request trigger when necessary. 15 The requirements for architecture
16. 1. The service provider supports server operation, such as by update of OS and the library. 2. The service provider supports a widely used general web application such as WordPress. 3. The service provider supports autoscale when the load concentrates, even if there is no specialized technical knowledge related to the load distribution. 16 More features details for service
17. 4. The service provider supports pay-per-use at the granularity of about the web application execution time. 5. The service reduces hardware costs by increasing the host accommodation efficiency. 6. The service updates OS and libraries to ensure security at high frequencies. 17 More features details
18. FastContainer architecture 18 )PTU
    " )PTU
    " )PTU
    " )PTU
    " )PTU
    " 5IF
    *OUFSOFU )PTU
    " )PTU
    " )PTU
    " stop periodically start reactively scale-up reactively Server A Server B HTTP(S) requests scale-out reactively • This architecture reactively determines changes of states such as web application container startup, startup duration, the number of containers, and scale processing judgment for each HTTP request • can adapt quickly to changes in the execution environment. • It has homeostasis
19. FastContainer Flow 19 8FC
    1SPYZ
    ʢOHY@NSVCZ $.%#
    ʴ
    "1* 8FC
    %JTQBUDIFS
    OHY@NSVCZ $MJFOU $POUBJOFS $POUBJOFS $POUBJOFS w 5IF
    DPOUBJOFS
    DPOpHVSBUJPO
    JOGPSNBUJPO
    JT
    BDRVJSFE
    GSPN
    UIF
    $.%# )551 4
    3FRVFTUT w USBOTGFST
    UIF
    SFRVFTU
    UP
    UIF
    TQFDJpFE
    DPOUBJOFS
    JG
    UIF
    DPOUBJOFS
    JT
    BDUJWF
    w *G
    JU
    JT
    OPU
    BDUJWBUFE
    UIFO
    UIF
    DPOUBJOFS
    DPOpHVSBUJPO
    JOGPSNBUJPO
    JT
    BDRVJSFE
    GSPN
    UIF
    $.%#
    UIF
    SFRVFTU
    JT
    USBOTGFSSFE
    BGUFS
    BDUJWBUJOH
    UIF
    DPOUBJOFS
    pSTU $POUBJOFS
    &OHJOF
    IBDPOJXB 4IBSFE
    4USBHF
20. • the startup processing of web application server processes such as Ruby on Rails on containers is still slow • Even for containers, immediacy is low against a sudden load • uses CRIU to image the process state immediately after finishing the startup of the process • CRIU restore the process from that image. • Even if using software with a long startup time such as Ruby on Rails, it can be started at high speed 20 High-speed state transition
21. 4. Experiment
22. Prototype for evaluation of FastContainer 22
23. Evaluation of scale processing 23 0O
    UIF
    DPOUBJOFS
    JO
    $PNQVUF
     BDUJWBUF
    "QBDIF
    
     JOTUBMM
    1)1
    
     POMZ
    FYFDVUFT
    UIF
    QIQJOGP
    
    GVODUJPO
     $16
    MJNJUFE
    UP
    
    PG
    
    DPSF
    5IF
    #FODINBSLJOH
     
    TJNVMUBOFPVT
    DPOOFDUJPO
      
    UPUBM
    SFRVFTUT
     DPSSFTQPOEFODF
    PG
    UIF
    TDBMFPVU
    UZQF
    BOE
    UIF
    TDBMFVQ
    UZQF
    8IFO
    UIF
    OVNCFS
    PG
    QSPDFTTJOH
    SFRVFTUT
    FYDFFET
     
24. 24 Scale-out order in 334 s starting scale-out in 340 s
25. 25 the response time transition when scaling up the CPU maximum usage rate to 60% at the horizontal axis 301 s.
26. Evaluating startup speed from images 26
27. 5. Conclusion
28. • This study examined our proposed FastContainer of a container management architecture • allows the user environment composed of containers to autoscale at HTTP request timing • without requiring specialized knowledge for service users in web hosting service • the time of the auto scale-out with reactivity is considerably short by CRIU • resource efficiency of FastContainer is higher by discarding the container during a certain period 28 Conclutions
29. • it is necessary to clarify the standing position of container related software • the comparison target and to make the cooperation of each layer more generalized • we plan to continue research and development while considering collaboration with other tools and technical background firmly • in addition to discussion with tool developers like Kubernetes and Docker 29 Future works