Want to know more about Autotune ? You've come to the right place !
Autotune is an Autonomous Performance Tuning Tool for Kubernetes. Autotune accepts a user provided "sla" goal to optimize application performance. It uses Prometheus to identify "layers" of an application that it is monitoring and matches tunables from those layers to the user provided sla. It then runs experiments with the help of a hyperparameter optimization framework to arrive at the most optimal values for the identified tunables to get a better result for the user provided sla.
Autotune can take an arbitrarily large set of tunables and run experiments to continually optimize the user provided sla in incremental steps. For this reason, it does not necessarily have a "best" value for a set of tunables, only a "better" one than what is currently deployed.
- Goal
The user has an application that is deployed to minikube and is looking to improve some aspect of performance of the application. The user specifies an "objective function" in an "Autotune object" that defines the performance aspect of the application that needs to be optimized. Autotune then analyzes the user application, breaks it down into its component layers and provides tunables associated with each layer that can help optimize the user provided objective function. - Steps
This demo installs Autotune along with Prometheus and Grafana to minikube. It also deploys two example REST CRUD applications, quakus galaxies and springboot petclinic, to the minikube cluster. It then deploys the "Autotune Objects" that define the objective function of the performance tuning that needs to be done for each application. - What does it do ?
It provides a list of URLs that defines the tunables for a user provided sla. See the docs for the definition of the REST API associated with these URLs.
Info: Access Autotune tunables at http:https://192.168.39.138:30110/listAutotuneTunables
Info: Autotune is monitoring these apps http:https://192.168.39.138:30110/listApplications
Info: List Layers in apps that Autotune is monitoring http:https://192.168.39.138:30110/listAppLayers
Info: List Tunables in apps that Autotune is monitoring http:https://192.168.39.138:30110/listAppTunables
Info: Autotune searchSpace at http:https://192.168.39.138:30110/searchSpace
Info: Access autotune objects using: kubectl -n default get autotune
Info: Access autotune tunables using: kubectl -n monitoring get autotuneconfig
- What does it not do ?
It does not kick off any experiments with the tunables (as yet). Stay tuned !! - pre-req
It expects minikube to be installed with atleast 8 CPUs and 16384MB Memory.
An objective function specifies a tuning goal in the form of a monitoring system (Eg Prometheus) query.
apiVersion: "recommender.com/v1"
kind: Autotune
metadata:
name: "galaxies-autotune"
namespace: "default"
spec:
sla:
objective_function: "request_sum/request_count"
sla_class: "response_time"
direction: "minimize"
function_variables:
- name: "request_sum"
query: rate(http_server_requests_seconds_sum{method="GET",outcome="SUCCESS",status="200",uri="/galaxies",}[1m])
datasource: "prometheus"
value_type: "double"
- name: "request_count"
query: rate(http_server_requests_seconds_count{method="GET",outcome="SUCCESS",status="200",uri="/galaxies",}[1m])
datasource: "prometheus"
value_type: "double"
mode: "show"
selector:
matchLabel: "app.kubernetes.io/name"
matchLabelValue: "galaxies-deployment"
matchRoute: ""
matchURI: ""
matchService: ""
In the above yaml from the benchmarks repo, the overall goal or sla for the IT Admin is to minimize response time of the application deployment galaxies-deployment. The objective function defines what exactly constitutes response time. In this example it is a regular expression request_sum/request_count. The function_variables section helps to resolve the individual variables of the expression. In this case, request_sum represents the value returned by the prometheus query rate(http_server_requests_seconds_sum{method="GET",outcome="SUCCESS",status="200",uri="/galaxies",}[1m]) and request_count represents the value returned by the prometheus query rate(http_server_requests_seconds_count{method="GET",outcome="SUCCESS",status="200",uri="/galaxies",}[1m]).
See the benchmarks repo for more examples on how to define Autotune objects. Look for ${benchmark_name}/autotune dir for example yamls.
A Layer is a software component of an application stack. In Autotune, we currently have 4 layers defined.
layer 0 = Container (Fixed and is always present)
layer 1 = Language Runtime (Eg. Hotspot JVM, Eclipse OpenJ9 JVM, nodejs...)
layer 2 = App Server / Framework (Quarkus, Liberty, Springboot...)
layer 3 = Application
A layer is defined by an AutotuneConfig object in Autotune. See the layer template if you want to add a new layer.
A tunable is a performance tuning knob specific to a layer. Autotune currently supports double and integer tunables. Tunables of these two types require a range to be specified in the form of a upper_bound and a lower_bound. This forms the valid range of values inside which the tunable operates. Tunables are defined in the AutotuneConfig object and are associated with a layer. Eg. The Quarkus AutotuneConfig yaml currently defines three tunables. See the layer template if you want to add a new tunable.
sla_class is associated with a tunable and is one or more of response_time, throughput and resource_usage. It represents the impact a tunable has on the outcome for any given workload. For example, we know based on prior experiments that the hotspot tunable, MaxInlineLevel has an impact on both throughput and response_time but has a negligible impact on resource_usage.
# To setup the demo
$ ./minikube_demo_setup.sh
# If you want to access the Prometheus Console
$ ./minikube_demo_setup.sh -sp
# To terminate the demo
$ ./minikube_demo_setup.sh -t
- autotune-demo
This repo. - autotune
Main repo for Autotune sources. - benchmarks
Benchmark scripts for running performance tests with Autotune. - autotune-results
Results of experiments run with Autotune.