Productify

Appearance

Scaling Policies ​

Advanced scaling policy configuration and patterns for the Productify Autoscaler.

Generated with your job

Since the Wave 3 release train the scaling block is rendered into the application job from the deployment spec's scaling {enabled, min, max} fields (pfy nomad render|deploy) — you do not hand-write it. The block below is reference output: it is the shape the renderer produces. See Generated Artifacts.

Policy Structure ​

Based on Nomad's autoscaling block with the productify-scaler strategy:

hcl
scaling {
  enabled = true
  min     = <minimum instances>
  max     = <maximum instances>

  policy {
    evaluation_interval = "<how often to evaluate>"
    cooldown            = "<minimum time between actions>"

    check "<check name>" {
      source = "nomad-apm"  # or "prometheus"
      query  = "<metric query>"

      strategy "productify-scaler" {
        optimizer_token = "<optimizer API token>"      # or set in agent config
        optimizer_url   = "<optimizer service URL>"    # or set in agent config
        min             = <min replicas>
        max             = <max replicas>
        metric_app_name = "<application name for metrics>"
        cache_size      = <seconds to cache predictions>  # optional, default: 10
      }
    }
  }
}

Strategy Configuration ​

Required Parameters ​

The productify-scaler strategy requires the following configuration:

hcl
strategy "productify-scaler" {
  optimizer_token = "supersecrettoken"       # Required (here or in agent config)
  optimizer_url   = "http://optimizer:8015"  # Required (here or in agent config)
  min             = 0                        # Required
  max             = 10                       # Required
  metric_app_name = "my-app"                 # Required
}
ParameterRequiredDefaultDescription
optimizer_tokenYes*-Authentication token for the optimizer API
optimizer_urlYes*-URL of the optimizer service
minYes-Minimum number of replicas
maxYes-Maximum number of replicas
metric_app_nameYes-Application name for metrics queries
cache_sizeNo10Number of seconds to cache predictions

* optimizer_token and optimizer_url may instead be set centrally in the autoscaler agent's strategy "productify-scaler" plugin config block (see config/autoscaler.hcl), in which case they can be omitted from the check.

Optional Parameters ​

hcl
strategy "productify-scaler" {
  optimizer_url   = "http://optimizer:8015"
  min             = 1
  max             = 20
  metric_app_name = "web-app"
  cache_size      = 15  # Cache predictions for 15 seconds
}

Complete Example from Code ​

From autoscaler/nomadscaler/config/test.hcl:

hcl
job "webapp" {
  datacenters = ["dc1"]

  group "demo" {
    count = 3

    network {
      port "webapp_http" {}
    }

    scaling {
      enabled = true
      min     = 0
      max     = 10

      policy {
        evaluation_interval = "3s"
        cooldown            = "10s"

        check "productify-scale-check" {
          source = "nomad-apm"
          query  = "avg_cpu-allocated"

          strategy "productify-scaler" {
            min             = 0
            max             = 10
            metric_app_name = "test"
            cache_size      = 10
          }
        }
      }
    }

    task "webapp" {
      driver = "docker"

      config {
        image = "hashicorp/demo-webapp-lb-guide"
        ports = ["webapp_http"]
      }

      resources {
        cpu    = 100
        memory = 16
      }
    }
  }
}

Advanced Configuration ​

Cache Size Tuning ​

Adjust the number of seconds to cache predictions:

Longer cache (more stable):

hcl
strategy "productify-scaler" {
  optimizer_url   = "http://optimizer:8015"
  min             = 2
  max             = 20
  metric_app_name = "my-app"
  cache_size      = 30  # Cache 30 seconds of predictions
}

Shorter cache (more responsive):

hcl
strategy "productify-scaler" {
  optimizer_url   = "http://optimizer:8015"
  min             = 2
  max             = 20
  metric_app_name = "my-app"
  cache_size      = 5   # Cache 5 seconds of predictions
}

Predictive Scaling ​

The productify-scaler strategy automatically uses SARIMAX forecasting for predictive scaling:

  • Historical metrics are analyzed to identify patterns
  • Future demand is forecasted at second-level granularity
  • MILP optimization determines optimal scaling decisions
  • Predictions are cached for smooth scaling transitions

No additional configuration needed - forecasting is built-in.

Best Practices ​

Cooldown Periods ​

  • Fast-changing workloads: 30-60s
  • Stable workloads: 2-5 minutes
  • Database scaling: 5-15 minutes

Min/Max Bounds ​

  • Min: Set to handle baseline load + small buffer
  • Max: Set to cost limit or infrastructure capacity
  • Gap: Ensure sufficient room for scaling (min < max * 0.5)

Evaluation Interval ​

  • Latency-sensitive: 2-30s
  • Throughput-focused: 30-60s
  • Cost-optimized: 60-120s

Metric Selection ​

  • Single metric: Use one primary metric per scaling policy
  • Choose wisely: Select the metric that best represents service health
  • metric_app_name: Must match the application name in your metrics system

Troubleshooting ​

Over-Scaling ​

Symptoms:

  • Frequent scale-up beyond necessary
  • High costs

Solutions:

  • Lengthen cooldown
  • Increase the startup/replica cost weights in the MILP
  • Review metric accuracy

Under-Scaling ​

Symptoms:

  • High latency/errors
  • Maxed-out instances

Solutions:

  • Shorten evaluation interval
  • Increase max instances
  • Review the MILP SLA violation penalty

Oscillation ​

Symptoms:

  • Rapid up/down scaling
  • Unstable instance count

Solutions:

  • Increase cooldown period
  • Increase cache size
  • Smooth metrics (longer query windows)

See Also ​