The Design of the Autoscaling Application Block

Retired Content
This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

On this page:
Design Highlights - Data Collection, Rule Evaluation, The ConstraintRule Class, The ReactiveRule Class, Common Features, Logging, Service Information

The Autoscaling Application Block is designed to achieve the following goals:

• Encapsulate the logic for autoscaling Microsoft Azure applications with minimal changes to your Azure applications.
• Allow autoscaling behavior to be determined through configuration, and allow changes to autoscaling behavior without redeploying your Azure applications.
• Allow the Autoscaling Application Block to be hosted either in Azure or in an on-premises application.
• Enable collecting of detailed log information about the autoscaling activities.
• Enable the developer to create extensions to the default autoscaling functionality.

This topic describes the design of the Autoscaling Application Block, describing the highlights. Other topics in this section include "The Stabilizer" and "The Request Tracking Process."

Design Highlights

This topic describes the design of the data collection function, the rules evaluation function, and some additional features that are common to both.

Data Collection

The following diagram shows the relationships between some of the key classes in the Autoscaling Application Block that relate to the data collection process.

Data collection classes in the Autoscaling Application Block

The Autoscaler class is a façade for the Autoscaling Application Block. You can create an instance of this class to initialize and then start the autoscaling behavior in your application by calling the Start method.

The Metronome class runs activities on a regular schedule and it is responsible for launching all of the activities that the Autoscaling Application Block performs. Each activity can have its own schedule; for example, one activity could run every 10 seconds, while another runs every 5 minutes. To ensure that only one instance of the Metronome can run at any given time in any role instance in your Azure environment, it uses a lease on an Azure blob. For details of this mechanism, see Building a Scalable, Multi-Tenant Application for Microsoft Azure. In the Autoscaling Application Block, the Metronome object schedules the following activities:

• Data point collection for each collector
• Rule evaluation
• Request tracking

Note

The Metronome class itself has no dependencies on Azure. Therefore, you can easily host the Metronome class in an on-premises application as well as in an Azure worker role. If you run it in an on-premises application and you plan to run multiple instances of the block, you should replace the lease on an Azure blob with another mechanism to ensure that the Metronome class is a singleton.

The Sampler class is responsible for collecting data points from your Azure environment and then saving the data points to a repository. The SamplerManager class creates Sampler instances for the Metronome class to run. Each Sampler instance is associated with a data point collector that implements the IDataPointsCollector interface, and a store for the collected data points that implements the IDataPointsStore interface. The block includes the following implementations of the IDataPointsCollector interface: the PerformanceCounterDataPointsCollector that collects performance counter data from Azure roles, the QueueLengthDataPointsCollector class that collects the current length of Azure queues, and the RoleInstanceCountDataPointsCollector class that collects a count of the current number of instances of Azure roles. Each data point collector class specifies a sampling rate that determines how frequently it collects data points.

The AzureStorageDataPointsStore class is the default implementation of the IDataPointsStore interface; it uses Azure tables to store the data points collected by the Sampler instance.

Rule Evaluation

The following diagram shows the relationships between some of the key classes in the Autoscaling Application Block that relate to the rule execution process.

Rule execution classes in the Autoscaling Application Block

The same instance of the Metronome class that schedules data collection tasks is also responsible for scheduling rule evaluation tasks. The RulesEvaluator class evaluates and executes the autoscaling rules. When the rules evaluation task runs, the RulesEvaluator class uses an IRulesStore instance to retrieve the autoscaling rules from a rules store. In the Autoscaling Application Block, the BlobXmlFileRulesStore class is the default implementation of the rules store; it uses an Azure blob to store the autoscaling rules in an XML document. The RulesEvaluator class deserializes the rules from the store into ConstraintRule and ReactiveRule instances.

The Evaluate method of the RulesEvaluator class determines which of the constraint rules from the rules store it should evaluate by comparing the current date and time with the timetable attached to the rule. The Evaluate method must complete before the Metronome instance can invoke it again. Each constraint rule that is evaluated uses a SetScaleRangeAction instance to return a result**.**

The Evaluate method of the RulesEvaluator class evaluates all the currently enabled reactive rules in the rules store. The rule evaluation process uses aggregate values that it calculates from data points that it retrieves through an IDataPointsStore instance. The data points to use are determined by the rule's condition. Each reactive rule that is evaluated uses a ReactiveRuleAction instance to return a result.

Note

Reactive rules can have actions that perform scaling operations on Azure roles (the ScaleInstancesAction class), or actions that initiate throttling behavior in your application (the ChangeSettingAction class), or custom actions.

The RulesEvaluator class consolidates the results from all of the rules that it evaluates to determine what scaling actions it should perform. Because there could be many, possibly conflicting, results from the rules, the RulesEvaluator class must reconcile the results before initiating any scaling operations.

The Scaler class is responsible for initiating the autoscaling operation on your Azure application and changing the number of current role instances. The RulesEvaluator class passes the Scaler class a list of scaling requests that it obtained from the most recent execution of the autoscaling rules. The Scaler class then uses the Azure Service Management API to forward the requests to your Azure environment. Optionally, the block can track the success or failure of these scaling requests using the ServiceManagementRequestTracker class.

Note

You can also configure the Scaler class to send notifications of proposed scaling operations instead of performing the scaling operations.

The ConstraintRule Class

The ConstraintRule class implements constraint rules that specify a maximum and minimum number of role instances based on a timetable. When the rules evaluation task evaluates a ConstraintRule rule, it uses the Timetable instance associated with the rule to determine whether the rule is currently active. To provide a more sophisticated way to specify when the constraint rule is active, the Timetable class uses recurrence patterns; the classes DailyRecurrence, WeeklyRecurrence, FixedDayMonthlyRecurrence, RelativeMonthlyRecurrence, and RelativeYearlyRecurrence in the Autoscaling Application Block all define recurrence patterns.

A ConstraintRule instance has a list of one or more SetScaleRangeAction instances; each SetRoleInstancesRangeAction instance specifies a target, and a minimum and maximum number of instances for that target. The constraint rule returns the target and the minimum and maximum instance count values to the RulesEvaluator class.

The ReactiveRule Class

The ReactiveRule class implements reactive rules that try to increment or decrement the number of role instances based on the data points retrieved from Azure or your application. When the rules evaluation task evaluates a ReactiveRule rule, it uses an expression to determine whether it should try to change the number of role instances of a target. An expression compares an aggregate value derived from a set of data points against a threshold value. Expressions can consist of multiple, nested expressions to define complex rules. Classes that implement the IRuleCondition interface handle the comparisons performed in the expression.

A ReactiveRule instance has a list of one or more ReactiveRuleAction instances; each ReactiveRuleAction instance specifies a target, and a suggested change to the number of instances of the target. The reactive rule returns the target and the suggested change to the number of instances to the RulesEvaluator class.

Common Features

The logging feature and the service information are used by both the data collection and rule evaluation components in the Autoscaling Application Block.

Logging

The Autoscaling Application Block uses an implementation of the ILogger interface to log details of its activities. The block includes two alternative implementations that you can select from in the block configuration: the SystemDiagnosticsLogger class uses the System.Diagnostics namespace, and the LoggingBlockLogger class uses the Enterprise Library Logging Application Block.

This service information is necessary for the block to be able to retrieve the data points.

The block uses an implementation of the ILogger interface to write log information about its data collection activities.

Service Information

The IServiceInformationStore interface defines how classes in the block can retrieve the information they need about the current Azure environment such as role names and subscription details. For example, the RulesEvaluator class uses an IServiceInformationStore instance to retrieve any information that it requires about your application's Azure roles and hosted service.

Next Topic | Previous Topic | Home

Last built: June 7, 2012