Skip to main content

Adaptive Edge Engine

The Adaptive Edge Engine (AEE) is a collection of components that manage different aspects of operating your Project on our dynamic, multi-provider, global hosting platform.

  1. LocationOptimizer manages the selection of locations where the Projects run.
  2. HealthChecker monitors Project health.
  3. TrafficDirector manages the routing of traffic to healthy Projects wherever they are deployed.

The components listed above work together as follows:

  • The LocationOptimizer selects locations for your Project based upon your strategy definition in your location-optimizer ConfigMap (see below). The locations selected by the AEE may be ones where the workload is currently running, or they may be new ones.
  • Next, the Project is deployed to any newly selected locations. The Project deployments are tested by the HealthChecker, and when they become healthy they are classified as "ready to receive traffic".
  • Once an instance of a Project is ready to receive traffic, the TrafficDirector updates Internet routing information so traffic can be "directed" to instances of your Project.

If the selected locations are the same as your current locations, you will see no changes.

Other components of the AEE manage additional dimensions of your Project in the background such as location orchestration and scaling.

LocationOptimizer​

The LocationOptimizer calls the SolverServiceV1 strategy to solve for the locations of servers for your Project. This strategy implements various policies that deliver different deployment styles. You define your Project's location strategy via parameters passed to the LocationOptimizer. The policies and their parameters are discussed in more detail below.

Policy descriptions and examples​

Dynamic​

This policy uses traffic data (e.g., http requests per second) to find an optimal set of locations for your Project subject to your parameter specifications. The optimization function selects locations to minimize the geographic distance travelled by the requests sent by your end users. With the dynamic policy, the selected set of locations is expected to change over time as your Project's traffic patterns change. See here for more information on the traffic signal used for dynamic location selection.

Special handling is required when the Project traffic data is NULL or 0. In cases of no traffic signal (e.g., the Project is not receiving any HTTP requests) the LocationOptimizer will meet the minimumLocations condition by selecting arbitrary locations. The mustInclude parameters will be honored if present, but if there are fewer of these than minimumLocations, additional locations will be chosen regardless of geography.

When the mustInclude conditions are infeasible, as from misspecification or network limitations, the LocationOptimizer will aim to meet all feasible conditions, while also returning at least the minimumLocations number of locations.

{"strategy":"SolverServiceV1","params":{"policy":"dynamic"}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
  • Optional parameters
    • minimumLocations: minimumLocations ensures that the Project will be deployed to a minimum number of locations to ensure availability. Default is 2.
    • maximumLocations: maximumLocations can be used to set a coarse upper limit on the number of locations. Default is 5.
    • mustInclude: mustInclude conditions represent “include this in my solution” conditions. Multiple conditions can be specified as key:value pairs. The LocationOptimizer selects one location per condition specified in the mustInclude array. For example, mustInclude = [{"region": "europe"},{"region": "northamerica"},{"region": "northamerica"}] will result in 3 locations, one in Europe and 2 in North America. See table of available terms here. With the dynamic policy, your selected locations may include additional locations determined by traffic. Default is NULL.
    • mustNotInclude: These represent conditions that must not appear in the solution set. They are specified in the same manner as the mustInclude conditions. Default is NULL.
    • chooseFrom: This feature is only available on the Enterprise plan.

A dynamic LocationOptimizer configuration specifying all parameters looks like this (note that minimumLocations and maximumLocations are equal to their defaults in this example):

location-optimizer.yaml
{
apiVersion: v1
kind: ConfigMap
metadata:
  name: location-optimizer
  namespace: default
data:
  strategy: |
    {
      "strategy":"SolverServiceV1",
      "params": {
        "policy": "dynamic",
        "mustInclude": [
          {"region":"europe"}
        ],
        "mustNotInclude": [
          {"region":"asia"}
        ],
        "minimumLocations": 2,
        "maximumLocations": 5
      }
    }
}

Static​

This policy results in a set of locations that that are used consistently until you change the strategy or something changes with the network (e.g., a location goes out of service). The AEE deploys your Project to a fixed set of locations that meet the strategy conditions without consideration of traffic flows. Upon the first implementation of the static policy, the LocationOptimizer will solve for a set of locations that meets the strategy specifications. In the example below, the LocationOptimizer will choose one location in Europe and one in Oceania. These specific locations will be used until your strategy or the underlying network change. You would not bounce among many possible European locations, for example. The explicit intent is to identify a set of locations and stay there.

Again, looking at the example below, all European and all Oceanian locations are considered equally acceptable. The selection of a location within Europe is arbitrary as is the selection within Oceania. Once suitable locations have been selected, they will remain as the selection for your Project until the strategy or the network change.

{"strategy":"SolverServiceV1","params":{"policy":"static", "mustInclude":[{"region":"europe"},{"region":"oceania"}]}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
  • Optional parameters
    • mustInclude: With the static policy, the mustInclude parameter is the only input used to define the desired result. mustInclude conditions represent “include this in my solution” conditions. Multiple conditions can be specified as key:value pairs. The LocationOptimizer selects one location per condition specified in the mustInclude array. For example, mustInclude = [{"region": "europe"},{"region": "northamerica"},{"region": "northamerica"}] will result in 3 locations, one in Europe and 2 in North America. See table of available terms here. The terms in the linked table are supported but may not be available due to momentary changes in network availability.
    • chooseFrom: This feature is only available on the Enterprise plan.

Anycast​

This policy is available on the Enterprise plan. It should only be used under specific circumstances and requires supporting actions such as changing your DNS records. See the Anycast explanation to know if and how you should use our Anycast networks.

This policy results in a set of locations that are part of our Anycast network.

{"strategy":"SolverServiceV1","params":{"policy":"anycast","network":"global-045"}}
  • Required parameters
    • policy: This is required to obtain the desired solution methods.
    • network: Indicates which Anycast IP space you are using in your DNS records as explained here.
  • Optional parameters
    • None

TrafficDirector​

The TrafficDirector is responsible for routing traffic to edge deployments and it has multiple strategies it can execute to manage this. Two DNS-based strategies are currently available with the default being a geo-DNS strategy that selects routes based on geographic proximity.

HealthChecker​

The HealthChecker executes one or more strategies for each Project to determine if the Project has been deployed/scheduled successfully and is ready to accept traffic. The HealthChecker also executes additional background strategies to monitor the health of the locations hosting Projects.

Two strategies are currently available to the HealthChecker configuration. Those strategies are:

  • deploymentMetricsHealthCheck: Monitors platform metrics to detect that the minimum replicas per container are running for each deployment.
  • envHTTPHealthCheck: An agent queries the Project with an HTTP POST request and monitors and interprets the response

The deploymentMetricsHealthCheck is included by default for all Project. The envHTTPHealthCheck is included by default for HTTP Projects.