既製の機械学習 (ML) ソリューションは続々と登場していて、みなさんのニーズを満たしてくれるものも少なくないでしょう。それでも、ML に対して本格的かつ長期的に投資を行っている組織は、保有するデータと求める結果にぴったり合った独自ワークフローの構築を進めています。この投資を最大限に活かすためには、ML モデルを最新の状態に保つとともに、現時点で最も新しいデータでモデルが動作するようにしなければなりません。

このチュートリアルのパート 1 では、継続的インテグレーション （Cl） パイプラインを作成するために ML ワークフローをステップに分解し (ML モデルのビルド、トレーニング、テスト、パッケージ化)、それらを CircleCI で自動化する方法について説明しました。今回は、継続的デプロイメント (CD) のためにデプロイを追加してステップを再トレーニングすることで、この ML ワークフローを完成させます。その後、ML ワークフローの各ステージを CircleCI で監視する方法について説明します。CircleCI の Web コンソールを使用すれば、プロセス全体を関係者が確認したり、モデルの更新を承認したり、問題解決を迅速に行ったりすることができます。

CD の概要および CD を ML モデルとワークフローに役立てる方法

継続的インテグレーションと継続的デプロイメント (CI/CD) プラットフォームを使用すれば、コミットしたコードのテスト、ビルド、デプロイを自動化することができます。こうすることで、ソフトウェア開発が高速化するとともに、製品の品質が確保されます。ML モデルはソフトウェアであるため、正確さを保ちつつモデルのトレーニングとデプロイを高速化するうえで、CI/CD プラットフォームは理想的です。

MLOps では、自動テストの手法を活用することで ML モデルを自動的に再トレーニングし、正確性をテストします。新しいデータが取り込まれたときやモデルが更新されたときに、モデルの再ビルドや再トレーニングが自動で行われ、仕様に適合しているかどうかのテストが完了するとデプロイされます。データのテストおよびモデルの再検証のタスクをスケジュール実行できるので、エンジニアに必要な労力がさらに軽減されます。

したがって ML のエキスパートが、パイプラインの実行、データのテスト、入念にテスト済みモデルのデプロイを手動で行う必要がなくなります。新しいデータが取り込まれるたびに既存のモデルを手動で再トレーニングしてテストする代わりに、モデルの正確性向上に集中することができます。

ML ワークフローの自動化には、将来まで有効というメリットもあります。定期的な更新はデータに限った話ではなく、新しい ML ツールや手法が次々と誕生しているため、それらの導入とテストを自動化すれば稼働のスピードが劇的に上がります。CircleCI では、GPU 対応の環境を含め、ローカルとマネージドクラウド環境の両方で ML パイプラインを実行できます。これにより、ML のトレーニングタスクを大幅に高速化するのみならず、インフラストラクチャ管理の負担なしに最新かつ最も優れた ML ツールチェーンを使用可能です。

パート 1 の振り返り: CI ワークフローでビルド、テスト、トレーニング、パッケージ化を自動化

このチュートリアルのパート 1 では、シンプルな ML ワークフローを継続的インテグレーション (CI) のステップ、つまり “ML モデルのビルド、トレーニング、テスト、パッケージ化” へと分解し、各ステップを CircleCI によって自動化しました。そしてこの記事では、継続的デプロイメント (CD) のステップ (ML コードや入力データに変更が行われたときの MLモデルの再ビルド、再トレーニング、パッケージ化) について扱い、このステップを CircleCI の自動化ワークフローで実装する方法を説明します。

A diagram showing how ML workflows are greatly accelerated by integrating CI/CD tools and best practices

ML ワークフローにデプロイと再トレーニングを追加する

チュートリアルのパート 2 となる本記事では、パート 1 のワークフローにデプロイのステップを追加します。また、別個の再トレーニングワークフローの作成も行います。サンプルリポジトリにある ML ワークフローのサンプルを使って方法を説明していきます。

このチュートリアルでは、ML モデルの開発ではなく、ML ワークフローを分解して CircleCI で自動化する方法のみを扱います。サンプルで使用する ML ワークフローは、TensorFlow のドキュメントから取得して、ステップごとに個々の Python スクリプトに分解しています。

前提条件とセットアップ手順

サンプルの ML リポジトリでは、4_package.py スクリプトが、トレーニングおよびパッケージ化が完了しモデルを SSH 経由でサーバーにアップロードします。これはチュートリアルのパート 1 で扱った最後のステップでした。ここからは次のステップとして、パッケージ化したモデルを TensorFlow Serving サーバーにデプロイします。わかりやすいように、このサーバーが実行されている Docker コンテナは、パート 1 においてパッケージ化したモデルをアップロードしたホスト上にあるものとします。

Tensorflow Serving のセットアップ

TensorFlow Serving を実行する Docker コンテナを、サンプル用の Bash スクリプトでスピンアップします。

bash ./tools/install_server.sh

初めに、お使いのプラットフォーム向けのインストール手順に従って Docker をインストールする必要があることに注意してください。

ML のデプロイと Python スクリプトの再トレーニングには、パート 1 でパッケージ化したモデルのアップロードに使用した SSH 資格情報を使用します。これらの資格情報は、CircleCI 環境変数として保存され .env 構成に書き込まれており、デプロイ用サーバーで Docker とやり取りするために使用します。

パッケージ化したモデルのデプロイ

デプロイ環境をセットアップした後は、パッケージ化したモデルをデプロイして使用できます。この段階では、トレーニングとパッケージ化を行ったモデルを本番の ML 環境にデプロイします。

サンプルのリポジトリにおいて、パッケージ化したモデルのアップロード先は TensorFlow Serving がモデルを読み込むディレクトリです。

このステップ用の Python コードは ml/5_deploy.py にあります。

デプロイしたモデルのテスト

ダウンタイムを防止するためには、デプロイを確実に成功させることが重要です。したがってこのサンプルでは、簡単な HTTP POST リクエストを TensorFlow Serving に送信し、応答を受け取れるか確認しています。

リクエストが成功しなかった場合、Python スクリプトによってエラーが返されます。

このステップ用の Python コードは ml/7_test_deployed_model.py にあります。

新しいデータによるデプロイ済みモデルの再トレーニング

ML は、”デプロイすれば終わり” といった類のタスクではありません。顧客データやユーザーの行動を分析する場合でも、科学上の目的でモデリングを行う場合でも、新しく高品質なデータが手に入った際には、初期のデータセットに縛られないよう既存のモデルを再トレーニングすべきです。

いったん新しいデータを取り込んで検証したら、再トレーニングしたモデルを既知のデータで再びテストし、正確さが保たれていることを確認しなければなりません。

ここで扱っているサンプルでは新しいデータを読み込むことはできませんが、再トレーニングおよび再テスト用のファイルとパイプラインを提供することは可能です。

再トレーニングと、再トレーニング済みデータのテストを実行する Python コードは 6_retrain.py ファイルにあります。

注意:_ このスクリプトは、テストステップが失敗するように設計されていることに注意してください。このような設計にしている理由は、スクリプトが CircleCI のジョブに追加されたとき、ジョブが失敗するとどうなるかをご覧いただきたいためです。_

CircleCI の CI/CD で ML モデルのデプロイを自動化する

いずれの CircleCI パイプラインも CircleCI コンフィグファイルではコードとして定義されます。このためステップ、ジョブ、ワークフローを追加および変更してから、バージョン管理システムにコミットしテストとデプロイを行うことが可能です。

チュートリアルのパート 1 に続き、デプロイと再トレーニング用の Python スクリプトをジョブとして定義して、その後ワークフローに追加できます。

CircleCI コンフィグファイルにデプロイと再トレーニングを追加する

以下では、既存の build-deploy ワークフローの中に、package ステップの後に実行するように deploy および test-deployment ステップを追加しています。

# Do not deploy without manual approval - you can inspect the console output from training and make sure you are happy to deploy
- deploy:
    requires: 
        - package 
- test-deployment:
    requires:
        - deploy

retrain-deploy ワークフローも、新しいスクリプトを含めるために定義しています。サンプルでは、このワークフローは cron 構文を使用して定義したスケジュールに従ってトリガーされます。このワークフローのスケジュール実行を機能させるには、Git リポジトリに retrain という名前のブランチを作成する必要があります。

retrain-deploy:
    # Trigger on a schedule or when retrain branch is updated
    triggers:
        - schedule:
            cron: "0 0 * * *" # Daily
            filters:
            branches:
                only:
                - retrain
    jobs:
        - install-build
        - retrain:
            requires:
            - install-build
        # Do not redeploy without manual approval - you can inspect the console output from training and make sure you are happy to deploy the retrained model
        - hold: # A job that will require manual approval in the CircleCI web application.
            requires: 
            - retrain
            type: approval # This key-value pair will set your workflow to a status of "On Hold"
        - package:
            requires:
            - hold
        - deploy:
            requires:
            - package
        - test-deployment:
            requires:
            - deploy

retrain-deploy パイプラインでは、retrain および package ステップの間に hold ステップを追加しています。パイプラインの実行は、CircleCI の Web コンソールで進行が承認されるまでこのステップで停止します。これは、再トレーニング済みのモデルを使用する前にその正確さを検証する必要がある ML パイプラインにおいて非常に便利です。

このワークフロー内で呼び出している retrain ジョブでは、on_fail 条件を使用しています。次のように、ジョブが失敗した場合に特定のアクションを行うことができます。

   - run:
          # You could trigger custom notifications here so that the person responsible for a particular job is notified via email, Slack, etc.
          name: Run on fail status
          command: |
              echo "I am the result of the above failed job" 
          when: on_fail

ML スクリプトの出力を詳細に指定することで、モデルの使用準備が整っているかどうか確認するために必要な情報をユーザーに確実に提供できます。再トレーニング条件が満たされていない場合は例外をスローするようにすれば、パイプラインを完全に終了させて、本番環境へのデプロイ前に修正することができます。

スケジュール実行、ブランチ、手動でのパイプライン実行

上記のコードのように、retrain-deploy パイプラインはユーザー定義のスケジュールに従って実行されます。これは、指定されたブランチの更新時にのみ実行されるパート 1 の build-deploy パイプラインとは異なります。

また CircleCI の Web コンソールから、いつでも手動でパイプラインをトリガーしたり、失敗したジョブを再実行したりすることができます。パイプラインの実行を CircleCI API でトリガーすることも可能です。 CircleCI API を使用すれば、新しいデータを取り込んだときに CircleCI パイプラインを外部からトリガーするデータ取り込みツールを構築できます。

A screenshot of the CircleCI web console indicating where to manually trigger a pipeline.

ニーズに応じてビルドをカスタマイズする

CircleCI ができることはこのチュートリアルの範囲内に到底収まるものではなく、柔軟なプラットフォームとして、完全に独自の ML ワークフローを完成させるお手伝いをします。各ジョブはコンソールコマンドなので、任意の言語、プラットフォーム、ライブラリを利用して、ほとんどの動作をスクリプト化することができます。

CircleCI のコンセプトと機能では、ほぼすべての種類の ML ワークフローを構築可能です。既存の機能だけでは構築が難しい場合でも、必要な動作を再利用可能なコマンドやジョブとしてスクリプト化して、CircleCI コンフィグファイルに追加すれば対応できます。

CircleCI で ML の CI/CD パイプラインを監視する

CircleCI コンフィグファイルを Git リポジトリにコミットすると、コンフィグファイルで定義したワークフローが、定義済みのフィルターとスケジュールに基づいて実行されます。CircleCI で実行されたタスクの出力は、Web コンソールで確認できます。

A screenshot showing that two concurrent tasks have been completed successfully in the CircleCI console.

ジョブをクリックすると、実行中に生成されたコンソール出力が表示されます。exit code が 0 の場合はすべてが期待どおりに動作したことを意味し、0 以外は基本的に失敗を示します。

A screenshot of the console output produced by a CircleCI job.

ジョブは承認待ちで保留することができます。ジョブが失敗した場合には、CircleCI Web アプリでワークフローの失敗した部分のみを再実行して、問題への速やかな対応と確認を行えます。

A screenshot showing how to rerun a failed job in the CircleCI web console.

失敗したジョブを再実行すると、ワークフロー全体をもう一度実行するのではなく失敗した時点から再開できるため、時間の節約になります。

A screenshot showing a CircleCI job that was held and has been approved by the user.

ジョブを承認待ちにして、CircleCI にログ記録された出力を確認してからパイプラインを再開することも可能です。これにより、ML ビルドとテストの各ジョブの結果を出力して確認し、要件を満たした場合のみパッケージ化とデプロイに進むことができます。

ML の要件とワークフローが拡張する一方なら、CircleCI パイプラインでトリガーするスクリプトに、増え続ける ML の管理および監視タスクを任せることをお勧めします。こうすることでワークロードが大幅に軽減されるうえに、データ取り込みのタイミングや指定のスケジュールに従って自動化したタスクが実行および完了され、問題があったときのみ対処するだけでよくなります。自動化を行えば、ML システムの運用と監視にかかる時間が大幅に短縮されるので、開発の時間を増やすとともに、管理に費やす時間を減らすことができます。

通知のカスタマイズ

既定では、ジョブが失敗したときや承認が必要な場合に、既定の CircleCI 用メールアドレスに通知が送られるようになっています。通知の動作はこの他にも構成可能であり、パイプラインについての通知を受け取るチームメンバーを追加したり、Web 通知を設定したり、CircleCI パイプラインを Slack や IRC と連携したりできます。

失敗したジョブの修正依頼を確実に担当者に送り、ML システムの正確さと可用性を確保するために、通知をカスタマイズすることをお勧めします。

本番環境での問題への対応

モデルのデプロイ後、監視とログ記録は ML プラットフォームが対応します。TensorFlow でのこれらの構成については、こちらのガイドをご覧ください。

CircleCI API を使用して、CircleCI パイプラインの実行をトリガーするように運用監視ツールを構成することができます。こうすることで、インシデントの発生時にすばやくモデルのロールバック、再トレーニング、または再デプロイを行えます。

クラウドホスト型の GPU クラスおよびオンサイトの処理能力を活用する

ML モデルの再トレーニングは、コンピューティング負荷が高いタスクです。そのため、GPU の処理能力を活用することでプロセスを格段にスピードアップし、再トレーニングを高速化できるほか、複数のデータセットのトレーニングとテストを並行して行えます。ML タスクの処理が迅速な CircleCI の GPU クラスを CircleCI コンフィグファイルに追加すれば、クラウドの GPU リソースに即座にアクセスすることができます。ローカルのコンピューティングリソースをセットアップして管理する必要はありません。

セルフホストランナーをクラウドの GPU リソースおよび CircleCI のワークスペース機能と組み合わせると、クラウドリソースに内部データストアへのアクセス権を付与する複雑なインフラストラクチャを用意することなく、オンサイトで ML トレーニングデータにアクセスして準備し、クラウドで使用することができます。クラウドのコンピューティングコストが問題になった場合は、その逆に、データをクラウドからオンサイトに移行し、CircleCI のセルフホストランナーによりローカルの GPU で ML タスクを実行しましょう。

CI/CD で機械学習を自動化してデータを最新の状態に保つ

ML のベストプラクティス、特に CI/CD の採用に腰が重い組織は、データへの投資を活かしきれていません。ML モデルに利用するコードには、CI のベストプラクティスで定期的に更新と統合を行う必要があります。本番環境のモデルは、最新かつ高品質のデータで常に再トレーニングして、結果が古くなるのを防がなければなりません。

MLOps 戦略を使用して ML ワークフローを CI/CD ツールで自動化すれば、プロセスが効率化します。つまり、データの使用と検証が高速化し、モデルがひっきりなしに新しい情報を取り込んで学習して、問題が迅速に解決されます。

CircleCI は ML ワークフローの管理と自動化においてトップクラスの CI/CD プラットフォームです。わずか数分のセットアップで毎月最長 6,000 分にわたって無料で使用し、機能をお試しいただけます。