Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

MATSUMOTO Ryosuke

July 19, 2019
Tweet

More Decks by MATSUMOTO Ryosuke

Other Decks in Research

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

    View full-size slide

  2. 1. Introduction
    2. Load distribution and operation technology
    3. FastContainer: Proposed method
    4. Experiment
    5. Conclusion
    2
    ໨࣍

    View full-size slide

  3. 1.
    Introduction

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  8. 2.
    Load distribution and operation
    technology

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  14. 3.
    FastContainer: Proposed method

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  19. FastContainer Flow
    19
    8FC1SPYZ
    ʢOHY@NSVCZ

    $.%#
    ʴ
    "1*
    8FC%JTQBUDIFS
    OHY@NSVCZ

    $MJFOU $POUBJOFS
    $POUBJOFS
    $POUBJOFS
    w 5IFDPOUBJOFS
    DPOpHVSBUJPOJOGPSNBUJPO
    JTBDRVJSFEGSPNUIF
    $.%#
    )551 4

    3FRVFTUT
    w USBOTGFSTUIFSFRVFTUUPUIF
    TQFDJpFEDPOUBJOFSJGUIFDPOUBJOFS
    JTBDUJWF
    w *GJUJTOPUBDUJWBUFE UIFOUIF
    DPOUBJOFSDPOpHVSBUJPOJOGPSNBUJPO
    JTBDRVJSFEGSPNUIF$.%# UIF
    SFRVFTUJTUSBOTGFSSFEBGUFS
    BDUJWBUJOHUIFDPOUBJOFSpSTU
    $POUBJOFS&OHJOF
    IBDPOJXB

    4IBSFE4USBHF

    View full-size slide

  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

    View full-size slide

  21. 4.
    Experiment

    View full-size slide

  22. Prototype for evaluation of FastContainer
    22

    View full-size slide

  23. Evaluation of scale processing
    23
    0OUIFDPOUBJOFSJO$PNQVUF
    BDUJWBUF"QBDIF
    JOTUBMM1)1
    POMZFYFDVUFTUIFQIQJOGP
    GVODUJPO
    $16MJNJUFEUPPGDPSF
    5IF#FODINBSLJOH
    TJNVMUBOFPVTDPOOFDUJPO
    UPUBMSFRVFTUT
    DPSSFTQPOEFODFPGUIFTDBMFPVU
    UZQFBOEUIFTDBMFVQUZQF8IFOUIF
    OVNCFSPGQSPDFTTJOHSFRVFTUT
    FYDFFET

    View full-size slide

  24. 24
    Scale-out order in 334 s
    starting scale-out in 340 s

    View full-size slide

  25. 25
    the response time transition
    when scaling up the CPU
    maximum usage rate to 60% at
    the horizontal axis 301 s.

    View full-size slide

  26. Evaluating startup speed from images
    26

    View full-size slide

  27. 5.
    Conclusion

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide