[ad_1]
Faster Time to Market and Increase Efficiency
In the previous article, we learned about using continuous integration to safely and efficiently merge a new machine-learning model into the main branch.
However, once the model is in the main branch, how do we deploy it into production?
Relying on an engineer to deploy the model so can have some drawbacks, such as:
- Slowing down the release process
- Consuming valuable engineering time that could be used for other tasks
These problems become more pronounced if the model undergoes frequent updates.
Wouldn’t it be nice if the model is automatically deployed into production every time a new model is pushed to the main branch? That is when continuous integration comes in handy.
Continuous deployment (CD) is the practice of automatically deploying software changes to production after they pass a series of automated tests. In a machine learning project, continuous deployment can offer several benefits:
- Faster time-to-market: Continuous deployment reduces the time needed to release new machine learning models to production.
- Increased efficiency: Automating the deployment process reduces the resources required to deploy machine learning models to production.
This article will show you how to create a CD pipeline for a machine-learning project.
Feel free to play and fork the source code of this article here:
Before building a CD pipeline, let’s identify the workflow for the pipeline:
- After a series of tests, a new machine-learning model is merged into the main branch
- A CD pipeline is triggered and a new model is deployed into production
To build a CD pipeline, we will perform the following steps:
- Save model object and model metadata
- Serve the model locally
- Upload the model to a remote storage
- Set up a platform to deploy your model
- Create a GitHub workflow to deploy models into production
Let’s explore each of these steps in detail.
Save model
We will use MLEM, an open-source tool, to save and deploy the model.
To save an experiment’s model using MLEM, begin by calling its save method.
from mlem.api import save
...# instead of joblib.dump(model, "model/svm")
save(model, "model/svm", sample_data=X_train)
Full script.
Running this script will create two files: a model file and a metadata file.
The metadata file captures various information from a model object, including:
- Model artifacts such as the model’s size and hash value, which are useful for versioning
- Model methods such as
predictandpredict_proba - Input data schema
- Python requirements used to train the model
artifacts:
data:
hash: ba0c50b412f6b5d5c5bd6c0ef163b1a1
size: 148163
uri: svm
call_orders:
predict:
- - model
- predict
object_type: model
processors:
model:
methods:
predict:
args:
- name: X
type_:
columns:
- ''
- fixed acidity
- volatile acidity
- citric acid
- residual sugar
- ...
dtypes:
- int64
- float64
- float64
- float64
- float64
- ...
index_cols:
- ''
type: dataframe
name: predict
returns:
dtype: int64
shape:
- null
type: ndarray
varkw: predict_params
type: sklearn_pipeline
requirements:
- module: numpy
version: 1.24.2
- module: pandas
version: 1.5.3
- module: sklearn
package_name: scikit-learn
version: 1.2.2
View the metadata file.
Serve the model locally
Let’s try out the model by serving it locally. To launch a FastAPI model server locally, simply run:
mlem serve fastapi --model model/svm
Go to http://0.0.0.0:8080 to view the model. Click “Try it out” to try out the model on a sample dataset.
Push the model to a remote storage
By pushing the model to remote storage, we can store our models and data in a centralized location that can be accessed by the GitHub workflow.
We will use DVC for model management because it offers the following benefits:
- Version control: DVC enables keeping track of changes to models and data over time, making it easy to revert to previous versions.
- Storage: DVC can store models and data in different types of storage systems, such as Amazon S3, Google Cloud Storage, and Microsoft Azure Blob Storage.
- Reproducibility: By versioning data and models, experiments can be easily reproduced with the exact same data and model versions.
To integrate DVC with MLEM, we can use DVC pipeline. With the DVC pipeline, we can specify the command, dependencies, and parameters needed to create certain outputs in the dvc.yaml file.
stages:
train:
cmd: python src/train.py
deps:
- data/intermediate
- src/train.py
params:
- data
- model
- train
outs:
- model/svm
- model/svm.mlem:
cache: false
View the full file.
In the example above, we specify the outputs to be the files model/svm and model/svm.mlem under the outs field. Specifically,
- The
model/svmis cached, so it will be uploaded to a DVC remote storage, but not committed to Git. This ensures that large binary files do not slow down the performance of the repository. - The
mode/svm.mlemis not cached, so it won’t be uploaded to a DVC remote storage but will be committed to Git. This allows us to track changes in the model while still keeping the repository’s size small.
To run the pipeline, type the following command on your terminal:
$ dvc exp runRunning stage 'train':
> python src/train.py
Next, specify the remote storage location where the model will be uploaded to in the file .dvc/config :
['remote "read"']
url = https://winequality-red.s3.amazonaws.com/
['remote "read-write"']
url = s3://your-s3-bucket/
To push the modified files to the remote storage location named “read-write”, simply run:
dvc push -r read-write
Set up a platform to deploy your model
Next, let’s figure out a platform to deploy our model. MLEM supports deploying your model to the following platforms:
- Docker
- Heroku
- Fly.io
- Kubernetes
- Sagemaker
This project chooses Fly.io as a deployment platform as it’s easy and cheap to get started.
To create applications on Fly.io in a GitHub workflow, you’ll need an access token. Here’s how you can get one:
- Sign up for a Fly.io account (you’ll need to provide a credit card, but they won’t charge you until you exceed free limits).
- Log in and click “Access Tokens” under the “Account” button in the top right corner.
- Create a new access token and copy it for later use.
Create a GitHub workflow
Now it comes to the exciting part: Creating a GitHub workflow to deploy your model! If you are not familiar with GitHub workflow, I recommend reading this article for a quick overview.
We will create the workflow called publish-model in the file .github/workflows/publish.yaml :
Here’s what the file looks like:
name: publish-modelon:
push:
branches:
- main
paths:
- model/svm.mlem
jobs:
publish-model:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Environment setup
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install dependencies
run: pip install -r requirements.txt
- name: Download model
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
run: dvc pull model/svm -r read-write
- name: Setup flyctl
uses: superfly/flyctl-actions/setup-flyctl@master
- name: Deploy model
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
run: mlem deployment run flyio svm-app --model model/svm
The on field specifies that the pipeline is triggered on a push event to the main branch.
The publish-model job includes the following steps:
- Checking out the code
- Setting up the Python environment
- Installing dependencies
- Pulling a model from a remote storage location using DVC
- Setting up flyctl to use Fly.io
- Deploying the model to Fly.io
Note that for the job to function properly, it requires the following:
- AWS credentials to pull the model
- Fly.io’s access token to deploy the model
To ensure the secure storage of sensitive information in our repository and enable GitHub Actions to access them, we will use encrypted secrets.
To create encrypted secrets, click “Settings” -> “Actions” -> “New repository secret.”
That’s it! Now let’s try out this project and see if it works as expected.
Setup
To try out this project, start with creating a new repository using the project template.
Clone the new repository to your local machine:
git clone https://github.com/your-username/cicd-mlops-demo
Set up the environment:
# Go to the project directory
cd cicd-mlops-demo# Create a new branch
git checkout -b experiment
# Install dependencies
pip install -r requirements.txt
Pull data from the remote storage location called “read”:
dvc pull -r read
Create a new model
svm_kernel is a list of values used to test the kernel hyperparameter while tuning the SVM model. To generate a new model, add rbf to svm__kernel in the params.yaml file.
Run a new experiment with the change:
dvc exp run
Push the modified model to remote storage called “read-write”:
dvc push -r read-write
Add, commit, and push changes to the repository in the “experiment” branch:
git add .
git commit -m 'change svm kernel'
git push origin experiment
Create a pull request
Next, create a pull request by clicking the Contribute button.
After creating a pull request in the repository, a GitHub workflow will be triggered to run tests on the code and model.
After all the tests have passed, click “Merge pull request.”
Deploy the model
Once the changes are merged, a CD pipeline will be triggered to deploy the ML model.
To view the workflow run, click the workflow then click the publish-model job.
Click the link under the “Deploy model” step to view the website to which the model is deployed.
Here’s what the website looks like:
View the website.
Congratulations! You have just learned how to create a CD pipeline to automate your machine-learning workflows. Combining CD with CI will allow your companies to catch errors early, reduce costs, and reduce time-to-market.
Source link
