Brownout^CC: Cascaded Control for Bounding the Response Times of Cloud Applications

Abstract

Abstract-Cloud computing has emerged as an inexpensive and powerful computing paradigm, to the point that now even applications with hard deadlines are executed in the cloud. It may happen, due to unexpected events, that an application becomes popular and receives a lot of attention and client requests in a short period of time. Provisioning computing capacity for such applications is quite a difficult task, because content popularity cannot be easily predicted. One of the main problems in case content has to be served with a hard deadline is to ensure that this deadline is respected, even in the presence of popularity spikes. To this end, partial computation and graceful degradation were exploited, originating the brownout framework. Applications would degrade the user experience in the presence of load variations, to guarantee that deadlines are met. Two different control paradigms were applied to brownout: discrete-time control of optional content percentage over a period and event-based queue management. The first one had reasonable performance providing formal guarantees about the solution. The second one was able to improve the performance and keep the response time at the setpoint better, but suffered from the drawback of not providing formallygrounded mathematical guarantees. In this work we combine the best of both worlds, providing a cascaded controller for brownout, based on a more precise model of the cloud application with respect to the original design. The Brownout CC controller achieves performance comparable with the eventbased version, without sacrificing formal guarantees.

Cloud Application Predictability through Integrated Load-Balancing and Service Time Control

“…that each request is supposed to spend 90% of its time in the waiting process and 10% of its time being served) as well as γ = 0.7, as we expect great variations in service times between each scenario. The other evaluated strategies are state of the art solutions from the literature [11,28,35], using the architecture in Figure 2. The evaluated strategies are: ILAC-γ: The integrated load-balancing and service time control (ILAC) architecture of this paper, with the marked γ parameter.…”

“…We use both γ = 0.9 and γ = 0.7. Brownout CC + EPBH: A solution that employs cascaded control, Brownout CC [35], paired with a brownoutaware weighted probability algorithm for load balancing (EPBH) [11]. Brownout CC + SQF: The Brownout CC controller, with the SQF algorithm for load balancing.…”

“…Replicas implement a replica controller, that takes care of selecting -for each request -when to serve optional content. In the simulator, we used the replica controller described in [35] and used the suggested tuning parameters. For the control strategy presented in Section III-B, we use a sampling period of 0.25 s. The controller code developed in the simulator can be directly plugged into brownout-aware applications like RUBiS 3 and RUBBoS 4 .…”

“…FIFO and standard PS are then simply the special cases M C = 1 and M C = ∞ respectively. For further details, see [35].…”

“…as in Figure 2, with n = 5. The local controllers are using the feedback control strategy from [35], that determines the optional content computation. Each replica in the simulation takes on average 0.014 s to compute the optional content part of the response (with a variance of 0.01s 2 ), and 0.0002s on average for the mandatory part (with a variance of 0.001s 2 ).…”