Runtime Adaptation

The last phase of the runtime support process is to adapt the system and give individual feedback to subscribers. While system adaptation is limited to routing adjustments for satisfied expecta- tions, approved satisfiable expectations require further adaptation. For the sake of clarity, we focus on runtime adaptation to satisfy an expectationXe

i ∈ SAT; adaptation to free up resources

or optimize system utilization is part of future work. Runtime adaptation can be realized in three ways by:

1. adapting the MOM transparently for publishers and subscribers; 2. advising publishers to adapt; or

3. coordinating the adaptation of both MOM and publishers.

In our model, all these different types of adaptations are uniformly represented by the generic

actions we have introduced in Section 3.2.2.

4.4.1 Middleware Self-Adaptation

Some generic properties can be influenced at the MOM using self-adaptation as discussed in Sec- tion 3.2.2. While the MOM can influence some generic properties only in one direction (e.g., de- crease), others can be influenced in both directions (i.e., increased or decreased). Adapting the MOM transparently for participants is necessary when publishers are not able to adapt or if adapting them would violate constraints. In this section, we present three mechanisms to illustrate how self-adaptation by the MOM can be used to enforce requirements.

Adapt Routing

Routing adaptation refers to changing entries in the routing tables of a broker so that particular participants are permitted or excluded from receiving notifications. Routing adaptation in the context of our approach is used to ensure that a subscriber receives notifications only from those publishers that have capability profiles conforming to its requirements. Notifications from other publishers are not routed to the subscriber even though they match that subscriber’s subscription in terms of notification type or content. This contrasts routing adaptation in a typical EBS or DEBS where routing tables are populated based on matching advertisements and subscriptions. Having access to the broker state allows us to build upon the existing routing tree built and maintained by the broker. Routing adaptation increases or decreases the number of alternative publishers a subscriber receives notifications from.

Decrease Sampling Rate Received by Subscribers

Reducing the sampling rate of notifications based on a leaky bucket algorithm, a token bucket algorithm, load shedding, or content aggregation is a widely used mechanism in networked systems [40, 141, 152, 153, 158, 240, 337, 405].

Such a rateController can be used by the MOM to reduce the sampling rate sr_inof notifications to a lower rate sr_out that another participant receives them with. The reduced outgoing rate can be fixed or dynamically changing, depending on why this mechanism is used. While a fixed sr_out can be used to satisfy the requirements about sampling rate defined by a receiving subscriber, a

flexible outgoing rate allows the MOM to adjust the outgoing traffic. For example, to stay within a bandwidth budget [173], or to reduce the total number of notifications to be processed by the receiving broker, i.e., to free up processing resources there [138].

In this dissertation, we use rateControllers with both fixed and flexible srout to reduce the

sampling rate of notifications of type e.

Reduce Forwarding and Path Latency of Notifications

The end-to-end latency of notifications as discussed in Section 3.2.1 can be broken down into processing latency, forwarding latency and path latency [138]. Forwarding latency is added to the publication latency of notifications due to the MOM having to process the notification. The MOM can minimize the forwarding latency. In a DEBS, further mechanisms are available to minimize the additional path latency that is added by dispatching notifications between brokers. Eichholz [138] discusses and evaluates different mechanisms for an EBS and a DEBS.

All available mechanisms can be grouped into two categories: those that aim at prioritizing certain notifications and those that aim at reducing the overall number of notifications to be processed. For example, a single broker can influence the forwarding latency by adapting its internal processing using notification prioritization, aggregation, or traffic shaping. In a DEBS, assigning publishers or subscribers to different brokers in the topology (publisher placement and subscriber placement) can be used to influence the path latency [138].

In this dissertation, we focus on publication and forwarding latency. The publication latency is controlled to some degree by the publisher and cannot be transparently decreased by the MOM. Additional forwarding latency, however, can be transparently minimized using aggregation and load shedding as described and evaluated in detail in [138].

Using a rateController with flexible outgoing rates, the MOM tries to free up resources on the broker to faster process notifications with strict latency requirements. The heuristic is triggered whenever a watchdog detects a latency requirement being violated. The key steps are [138]:

1. Rank all processed types of notifications based on their quantity, volume and cumulative fidelity in descending order.

2. Select the type of notification¯e that generates the least cumulative fidelity.

3. Rank all subscribers of¯e based on their expectations’ utility value in descending order. 4. Aggregate or drop notifications for those subscriber(s) of¯e with the lowest utility value. Note that these steps describe a simple heuristic that tries to free up resources in a lazy fashion whenever a violation is detected for as long as it is detected. The MOM tries to reduce the number of notifications that have to be processed by aggregating or dropping all notifications of a certain type destined for a specific set of subscribers. The heuristic tries to maximize the impact on resource savings while limiting the impact on subscribers and the generated fidelity.

4.4.2 Client Self-Adaptation Using Feedback

In our approach we assume that most publishers can adjust their support for certain generic properties dynamically at runtime by using self-adaptation and additional feedback from the system [2, 3, 35, 62, 79, 96, 99, 109, 261, 362, 415]. For those publishers that are unable to adapt on their own, we assume that wrappers can be deployed.

For example:

• A gmond monitoring agent within the Ganglia [298, 299] open-source monitoring system can adjust the sampling rate of metrics using a wrapper that restarts the agent with new configurations.

• A publisher being part of the FINCoS open-source benchmarking tool [304] can change its sampling frequency, the precision and accuracy of its publications as well as its publication latency at runtime without the need to restart.

In our approach, the MOM triggers runtime adaptation of a publisher by sending a dedicated adaptation advice. As described in Section 3.5.1 and definition 7, such an adaptation advice contains the list of capabilities to adjust together with the required target values. However, an adaptation advice does not specify how this adaptation has to be done by the publisher.

4.4.3 Coordinated Adaptation

Adapting the current value for some generic properties requires coordination between MOM and publishers. Coordinated adaptation can be realized explicitly as a sequence of actions or implicitly by adjusting the costs of capabilities in the runtime negotiation phase.

We illustrate this using an example of a centralized EBS with a single broker, a single publisher

P₁but two subscribers S₁ and S₂ with requirements about sampling rate defined over two closed intervals that are disjoint.

Without coordinated adaptation, the requirements of only one subscriber could be satisfied; by implicitly using coordinated adaptation, the requirements of both subscribers can be satisfied. The initial situation is illustrated in Figure 4.9: publisher P1 provides notifications with a current

sampling rate of 50 notifications per second to two subscribers S1 and S2. Without any adapta-

tion, both subscribers S₁ and S₂ would receive notifications with this sampling rate that exceeds their requirements about the closed intervals[10; 20] (S₁) and[30; 40] (S₂). However, P₁ could adjust the sampling rate between 15 and 60 notifications per second using self-adaptation or the MOM could apply self-adaptation to throttle the sampling rates delivered to each subscriber using a rateController. S2 (closed) CV (maximizing) UB LB satisfiable

( ) ✔

S1 P1 S1 S2 MOM P1 cv = 50 [15; 60] [30; 40] [10; 20] (closed) 50 50 50 satisfiable

( ) ✔

Figure 4.9.: Problem: onlyP₁ available but conflicting requirements about sampling rate. Adapting only P1would not satisfy both subscribers as their ranges of accepted values are defined

over closed intervals and do not overlap. Thus, advising P1to adjust tomax S1= 20 would leave S₂ unsatisfied while adjusting tomin S2= 30 would violate the requirement of S1.

Adapting the MOM would satisfy the requirements of both S₁ and S₂ as the sampling rate that

P₁ sends with is currently greater than the required sampling rate. The scenario is shown in Figure 4.10: while P1 would not adjust its current value and continue to send notifications with

(closed) (maximizing) UB LB satisfied

✔

S1 P1 S1 S2 MOM [15; 60] [30; 40] [10; 20] (closed) 20 40 CV rateController (MOM) satisfied

✔

rateController (MOM) S2 CV S1 P1 CV S1 S2 cv = 50 50 S2 unchanged P1

Figure 4.10.: Potential solution: adaptation of MOM only, trafficP₁ higher than necessary.

a sampling rate of 50 to the MOM, the sampling rates delivered to subscribers are curbed to the maximum values still accepted by each subscriber. While this solution satisfies both subscribers, not adjusting P₁ results in an overhead of 10 notifications per second that have to be dropped or aggregated by the MOM. This overhead wastes resources in terms of network traffic, CPU and energy for P1and MOM.

Alternatively, we could adapt both P1 and the MOM using coordinated adaptation. This scenario

is illustrated in Figure 4.11: while P1 is advised to adjust its sampling rate to 40 to satisfy the

requirement of S2 which is defined over higher values than S1, the MOM additionally adjusts

the sampling rate delivered to S₁. In this case, the requirements of both subscribers are satisfied simultaneously while we do not have to drop surplus notifications at the MOM for S₂. Please note that we adjust to the maximum values in this example as this is going maximize the generated fidelity (cf., Section 3.3.3).

The fact that we consider explicit costs in our model is the enabling factor for coordinated adap- tation: at runtime publishers and the MOM can manipulate the operational costs of a capability (cf., Definition 4) and the adaptation costs of an action (cf., Definition 2).

Adjusting the adaptation costs for the different actions at runtime allows us to switch between the two solutions described above.

Forcing MOM-based adaptation is done by setting the adaptation costs for adaptPublisher to ∞. This forces our negotiation algorithm to choose any other available action. The same applies if a publisher is not able to adapt, too expensive, or deemed too critical (e.g., high FIT score). Forcing coordinated adaptation, on the other hand, is done by adjusting the operational costs of the capability sampling rate. We adjust the cost function for sampling rate once we advise the publisher to adapt for the first time. Depending on the improvement direction we set the operational costs to∞ for all values lower (maximizing improvement direction) or greater (min- imizing improvement direction) than the current value. Thus, we avoid that publishers adapt in a way that would violate already satisfied requirements about the sampling rate

In our example, setting the operational costs for the capability sampling rate to∞ for any value

c< 40 when satisfying S₂ prevents the algorithm to advise the publisher again to adapt to c= 20

when negotiating S₁ (as this would violate the already satisfied requirement of S₁). Please note that this does not keep us from reaching the same state when we negotiate S₁first: upon adapting to satisfy S1, costsad apt Publ isherare set to∞ for any c < 20 while the original cost function remains

S2 (closed) (maximizing) UB LB satisfied

✔

S1 P1 S1 S2 MOM P1 cv = 40 [15; 60] [30; 40] [10; 20] (closed) 20 40 40 rateController (MOM) adaptPublisher ( )P1 satisfied

✔

CV S1 P1 CV S1

Figure 4.11.: Alternative solution: coordinated adaptation of MOM andP₁.

While this iterative approach violates S1 for some time, the system reacts immediately. As P1

updates its capability as soon as the advised adaptation has finished, triggering a re-negotiation. Now, the negotiation algorithm notes that adapting P₁ is too expensive (∞) and searches for alternative actions to reduce the sampling rate again. At this point, any adaptation and op- erational costs defined for other actions are less expensive. In our example, this would result in using a rateController, while a different publisher could also be selected in a setup with multiple publishers.

Please note that we can prevent the system from using a rateController in the same way: setting the operational or adaptation costs for rateController to∞ would prevent the system from using this action.

In document Runtime Support for Quality of Information Requirements in Event-based Systems (Page 123-128)