GitHub Actionsを使用してモデルをデプロイ、昇格、ロールバックする

GitHub環境によって保護されたモデルの登録と運用の昇格により、すべてのユーザーをテストされていないバージョンに公開することなく、予測を提供する準備が整いました。

エンドポイントとデプロイを作成する

マネージド オンライン エンドポイントは、Proseware のスケジューリング システムなどのクライアント アプリケーションが予測を取得するために呼び出す安定した HTTPS アドレスを提供します。 エンドポイント自体はモデルを実行しません。 1 つ以上の デプロイでは、それぞれが特定の登録済みモデル バージョンとコンピューティング構成をペアリングし、自動生成された環境とスコアリング スクリプトである MLflow モデルの場合は、実際のサービスを実行します。 エンドポイント URL を固定したままその背後のデプロイを置き換えられるため、ノーショーモデルを再トレーニングして再デプロイする場合でも、スケジューリング システムを変更する必要はありません。

新しいバージョンを安全に昇格させる

エンドポイントは一度に複数のデプロイをホストでき、各デプロイが受信する受信トラフィックの割合を制御します。 このセットアップでは、運用ソフトウェアの変更をロールアウトするのと同じ方法で、新しいモデル バージョンをロールアウトできます。新しいバージョンを現在のバージョンと共に 0% トラフィックにデプロイし、想定どおりに動作するかどうかを確認してから、トラフィックを徐々に移行します。これは、一般的に ブルーグリーン展開と呼ばれるアプローチです。 新しいバージョンのパフォーマンスが低い場合は、エンドポイントを停止するのではなく、トラフィックを以前のデプロイに戻します。

トラフィックをシフトする前にテストする

新しいデプロイがライブ トラフィックを受信する前に、そのデプロイに直接要求を送信し、その応答を想定した内容と比較します。 新しいデプロイがこれらのチェックに合格した後でのみ、トラフィックの割り当てを増やします。 デプロイが準備完了状態になるまでに数分かかる場合があるため、自動テストでは、要求を送信する前に、デプロイが完了するまで待機する必要があります。

GitHub Actionsを使用してパイプラインを自動化する

再トレーニングされたモデルごとに登録、デプロイ、テストを手動で繰り返してもスケーリングされないため、Proseware のチームは、GitHub Actionsと Azure Machine Learning CLI (v2) を使用してパイプラインを自動化します。 ワークフローを Azure に対して認証する現在推奨されている方法は、OpenID Connect (OIDC) フェデレーション資格情報を使用することです。これにより、GitHub Actions はクライアント シークレットをリポジトリ シークレットとして保存する代わりに、有効期間の短いアクセス トークンを要求できます。 リポジトリとブランチをスコープとするMicrosoft Entra アプリケーションでフェデレーション資格情報を構成し、azure/loginアクションを使用してワークフロー内で参照します。

permissions:
  id-token: write
  contents: read

env:
  RESOURCE_GROUP: ${{ vars.AZURE_RESOURCE_GROUP }}
  WORKSPACE_NAME: ${{ vars.AZURE_WORKSPACE_NAME }}
  ENDPOINT_NAME: ${{ vars.AZURE_ENDPOINT_NAME }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Sign in to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: Register and deploy the model
        run: |
          az extension add -n ml -y
          az ml model create \
            --file model.yml \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
          az ml online-deployment create \
            --name green \
            --endpoint-name $ENDPOINT_NAME \
            --file green-deployment.yml \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
      - name: Test the new deployment
        run: |
          az ml online-endpoint invoke \
            --name $ENDPOINT_NAME \
            --deployment-name green \
            --request-file sample-request.json \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
      - name: Send limited traffic to the new deployment
        run: |
          az ml online-endpoint update \
            --name $ENDPOINT_NAME \
            --traffic "blue=90 green=10" \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME

ワークフローのpermissions ブロックは、Azureからトークンを要求するために必要なid-tokenをジョブに付与します。 azure/loginの手順では、そのトークンを認証されたAzure CLI セッションと交換します。 直接テストが成功すると、ワークフローは 10% のトラフィックを新しい green デプロイに送信します。 運用環境の動作が受け入れ基準を満たした後にのみ、さらに昇格させます。

前のモデルにロールバックする

新しいモデルがその監視期間を完了するまで、以前の blue デプロイを使用できるようにします。 昇格後にエラーまたは許容できない予測が表示される場合は、すべてのトラフィックを blueにルーティングします。

az ml online-endpoint update \
  --name $ENDPOINT_NAME \
  --traffic "blue=100 green=0" \
  --resource-group $RESOURCE_GROUP \
  --workspace-name $WORKSPACE_NAME

トラフィックを変更すると、エンドポイント URL が保持され、エンドポイントを削除して再作成するよりも高速な回復が実現します。 トラフィックが以前のモデルに戻ったら、ユーザーにそれを公開せずに green のデプロイを調査してください。 新しいモデルが必要な観測期間の受け入れ基準を満たした後にのみ、前のデプロイを削除します。