Automatic Horizontal Scaling

Automatic Horizontal Scaling

Automatic horizontal scaling increases or decreases the number of application nodes automatically according to the workload. It helps maintain application availability during demand spikes while reducing unnecessary infrastructure usage during quieter periods.

The platform evaluates resource consumption across the selected application layer and applies predefined scaling rules. New instances can be added when utilisation rises above a specified threshold and removed when the load falls below a separate threshold.

Instances belonging to the same layer should be distributed across available hosts using anti-affinity logic wherever supported. This reduces concentration on a single host and improves resilience.

Application nodes distributed across multiple hosts
Example: application instances distributed across available infrastructure hosts.

Scaling decisions are controlled through configurable triggers. The monitoring service periodically calculates average resource usage for the selected layer and checks whether the configured scale-out or scale-in condition has been met.

Configure Automatic Scaling Triggers

i

Note

Before enabling automatic scaling, confirm that the application architecture, load-balancing method and data-storage approach support multiple application nodes.

1

Open the environment settings

From the environment or application list, select the required environment and open its Settings panel.

2

Open Auto Horizontal Scaling

Navigate to Monitoring → Auto Horizontal Scaling. The page displays all scaling triggers currently configured for the selected environment.

Use the toolbar to add, edit, remove or refresh trigger records.

AddCreate a new automatic scaling trigger.
EditModify the selected trigger and its threshold conditions.
RemoveDelete a trigger that is no longer required.
RefreshReload the trigger list and its latest status.
3

Select the layer and monitored resource

Select the application layer to be scaled. Then choose the resource that the platform should monitor, such as CPU, memory, network throughput, disk input/output or disk operations.

Resource type selection for automatic scaling
Select the application layer and resource used for the trigger.

Tip

Review recent utilisation data before defining thresholds. This helps prevent unnecessary scaling and ensures additional capacity is created before the application reaches a critical load.

4

Review utilisation history

Use the resource graph to review historical consumption. Select an appropriate time range and hover over the chart to inspect usage at a specific time.

Use this information to establish realistic upper and lower thresholds.

Resource utilisation graph
Historical resource consumption helps determine suitable scaling thresholds.

Define Scale-Out and Scale-In Conditions

Each trigger can contain two independent conditions:

  • Add Nodes: increases the node count when average utilisation remains above the configured threshold.
  • Remove Nodes: decreases the node count when average utilisation remains below the configured threshold.
Scale-out and scale-in conditions
Configure independent scale-out and scale-in conditions.
Load threshold The resource-usage percentage or value that activates the condition.
Duration The minimum time for which the average usage must remain above or below the threshold.
Maximum nodes The highest number of instances that automatic scale-out is permitted to create.
Minimum nodes The lowest number of instances that automatic scale-in is permitted to retain.
Scale by The number of nodes added or removed during one trigger execution.

Recommended practice

Maintain a meaningful gap between the scale-out and scale-in thresholds. A wider gap helps prevent frequent addition and removal of nodes when resource usage fluctuates near a single value.

When configuring the trigger, also consider whether the application layer is stateless or stateful. Stateful node creation may require additional time because application data or configuration may need to be copied to the new instance.

Configure Notifications

Enable email notifications when administrators should be informed about scaling activity. Notifications can be disabled when the events are already monitored through another operational system.

Email notification option
Enable or disable email notifications for trigger activity.

After completing the configuration, use the available action button to save the trigger. Depending on the interface, the final action may be labelled Add, Apply or Save.

Review Scaling Event History

The event-history section provides a record of automatic scaling activity for the selected environment. It can be used to confirm that triggers are working correctly and to review the conditions that caused each action.

1

Open Events History

Navigate to Settings → Monitoring → Events History and select Horizontal Scaling as the event type. Use the date filters to limit the displayed period.

2

Review the event information

Each record should identify the execution date and time, the performed action, the affected node group and the trigger condition. Additional details may include the resource value at execution and the resulting node count.

Date and timeWhen the scaling event was executed.
ActionWhether nodes were added or removed.
Layer or node typeThe application group affected by the event.
Trigger informationThe threshold and monitored resource that caused execution.
Resulting node countThe number of active nodes after the action was completed.
i

Important

Scale-out and scale-in conditions are evaluated independently. Configure sufficient separation between their thresholds and durations to avoid repeated topology changes during normal workload fluctuations.

Expected Result

After the trigger is saved, the platform continuously monitors the selected resource. Nodes are added or removed automatically when the configured threshold, duration and node-count conditions are satisfied. Every execution is recorded in the event history.