Machine Learning in the Cloud using Azure ML Studio
Last Updated on December 7, 2020 by Editorial Team
Author(s): Ranganath Venkataraman
Cloud Computing
Model training and deployment for a new Nanodegree from Udacity and Microsoft

After completing a Foundations course launched in July that enrolled~ 10,000 students worldwide, I was one of 300 selected in October for a scholarship to get a Nanodegree. After completing the capstone yesterday and graduating, Iโm writing this article to document my experience with the mechanics of AzureML. Hereโs the link to my projectโs repo.
Context
As evident in my previous posts, my self-taught journey to date focused on building predictors and visualizations using machine learning algorithms with Python. My interface was the Jupyter notebook, and my work lived on my laptop. As I was getting ready to practice and learn deploying models, I started the Nanodegree thatโโโamong other conceptsโโโcovered the deployment of models inย Azure.
How this article is organized
Topics covered in this article about Nanodegreeโs Capstone projectย are:
- Purpose
- Setting up for theย project.
- DevelopmentโโโHyperDrive andย AutoML
- Deployment
- Conclusions
Throughout this article, Iโll discuss points that were good learning opportunities for my fellow students andย me.
Purpose
The capstone project is the culmination of training on various concepts; therefore, it tested our abilityย to:
- run a HyperDrive experiment to comb through the hyperparameter search space to find settings that maximize the performance of a pre-selected scikit-learn algorithm on a problem ofย choice
- use AutoML to find the best algorithm that maximizes performance on the aforementioned problem
- deploying the best performing model as an active endpoint that can be queried by anybodyโโโgetting the product out of my laptop so anybody can useย it
Setting up for the Capstoneย project
The first step was to select a problem and dataset: I chose the problem of predicting vehicle fuel efficiency with the Auto MPG dataset from the UCI repository. Since I was familiar with this dataset from a prior post, I could focus on the mechanics of Azureโs Machine Learning (ML)ย Studio.
Microsoft and Udacity provide a virtual machine for the capstone: Standard DS3V2 with 14 GB RAM that can provide up to 4 CPU nodes. After launching a workspace that uses this virtual machine, the next setting-up step is to upload and register the dataset, which currently is aย .csv file on myย desktop.
Once completed, AzureML provides the user with the necessary code to consume the registered dataset, as seen in Figure 1 below. The line declaring the Experiment is my own and not necessary to consume a registered dataset.

With the dataset ready for use and a workspace launched on a running virtual machine โcompute,โ we are ready to develop theย project.
DevelopmentโโโHyperDrive
Setting up the HyperDrive experiment for this problem in Azure ML Studio entails setting the search space for model hyperparametersโโโsimilar to GridSearchCVโโโand selecting an Early Stopping policy to halt the experimentโs runs upon achieving a certain performance factor. These two factors, along with a max number of trials, provide means of configuring the HyperDrive run, as observed in Figureย 2.

Other settings needed to configure the HyperDrive run include the primary metric name, our goal with the metric, i.e., maximize or minimize, and the estimator. The number of max_concurrent_runs must be less than or equal to the maximum number of nodes that can be provisioned by the available compute, in this case,ย 3<4.
Continuing with this articleโs focus on the mechanics of AzureML, letโs discuss the estimator. As you see above, itโs declared using AzureMLโs SKLearn class and uses an entry script as input. That entry script is the actual code that cleans the data, splits data into training and testing sets, trains the pre-selected scikit-learn algorithm, and evaluates performance on a test set. Letโs look at part of the entry script in Figure 3 below, with the whole code available in train_11_29_FINAL.py script, found in the projectย repo.

As observed above, I chose to vary tree depth and learning rate when searching for the bestย model.
I also used the default scorer used by GradientBoosting Regressor, which returns an R-square value. This score must be logged in the entry script with the same name as the name used as the primary_scoring_metric in the HyperDriveConfigโโโcompare Figures 2 andย 3.
Experiments are โsubmittedโ to launch HyperDrive runs. When these runs fail, the main console returns messages that can be inadequate for diagnosis. The user opens a given link that has a list of HyperDrive runs, click on a failed run, and open that failed runโs output logs. Those logs point out the specific line with theย error.
The best-performing run can then be retrieved from the HyperDrive experiment as seen in Figure 4 below, with the corresponding hyperparameter settings specified in an instance of the algorithm and saved to the active directory as a model using joblib. Figure 5 shows the ID and performance of the bestย run.


A HyperDrive-optimized GradientBoosting Regressor has an R-squared value ofย 0.82
DevelopmentโโโAutoML
AutoML in Azure ML Studio entails cleaning the dataset, specifying configuration settings through AutoMLConfig, and submitting an experiment with these settings. Figure 6 below goes through this processโโโbecause there is no training script submitted with AutoML, we have to sanitize the data before feeding it as training_data.

The entire output is in the linked repoโโโgetting the best model from the AutoML experiment reveals that itโs an XGBoost Regressor that produces an R-squared value of 0.87. This top-performing model is saved to the active directory using joblib.dump

Deployment
With the best performing, AutoML saved to the working directory, I then registered the model and created the necessary environment with the required packages to use in deploying the registered model as a web service. This web service is an active HTTP endpoint that can be queried with data to receive the modelโs prediction.
Registering the model creates a โcontainerโ with the application and libraries/dependencies needed for execution. The registered model is also saved on the working directory for subsequent use in deployment.
The Model classโs deploy method, as used in this project, takes the following inputs: a workspace, the registered model, an inference configuration, and a deployment configuration. Letโs take each of these at aย time:
- workspace = already definedย earlier
- registered model = coveredย above
- inference configuration = represents settings of the โcomputerโ used for deployment. The InferenceConfig class is used, whichโโโfor our purposesโโโtakes two inputs: an entry script and a curated environment. Weโll cover both of theseย short
- deployment configurations = configures the web service that hosts the registered model and entry script. For our purposes, weโll use the Azure Container Instance.
Now letโs discuss the inputs to the InferenceConfig class:
- the entry script takes data from the user and passes it to the model. The resulting prediction from the model is โreturnedโ as the output of the entry scriptโโโsee below for a snippet from the score.py entry script, which can be found at this projectโs repo.

- the curated environment is expected to support the algorithms used by the model. In my case, since the best AutoML model is an XGBoost Regressor, I chose the โAzureML-AutoMLโ package, which covers this algorithm.
Figure 9 below shows the creation of the environment, inference configuration, and deployment configuration. These creations are fed along with the registered model into the deploy method of the Modelย class.

As seen below, deployment was successful with a healthy endpoint. Upon my asking, AzureML provides the scoring URI for use in querying theย model.

Passing a request to this scoring URI runs the entry script, which launches the registered model from its saved home in the working directory in the init() command. The run() command is then executed to actually generate a prediction on data passed to the active endpoint.

Figure 11 demonstrates that any user who uses the files at the project repo can pass data on a car and get the predicted mileage. Key learning for the group was the importance of passing in a dataframe that can be dumped into a JSON file while being transferred to the score script, which then unpackages, i.e., dumps the JSON file and transfers it back into a dataframe.
Conclusions
I entered this Nanodegree with no experience in deploying models and have come out with experience in one medium. While challenging, this Nanodegree was enjoyable, and Iโm looking forward to learning deployment with otherย tools.
Machine Learning in the Cloud using Azure ML Studio was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Published via Towards AI