データサイエンスとDevOpsの融合：Jupyter、Git、Kubernetesを用いたMLOps

背景 レコンシラーによるレジリエントシステムの構築 DAGは存在しない GitOps：プルリクエストによる運用 統合：レコンシラー + GitOps = MLのためのCI/CD 差分の計算 アクチュエーション モデルトレーニング モデルデプロイ 制御ループ 独自のCI/CDパイプラインを構築する 次のステップ 系譜追跡 参考文献 Kubeflowは、Kubernetes上での機械学習のデプロイと管理を容易にする急成長中のオープンソースプロジェクトです。 Kubeflowの爆発的な人気により、GitHubイシューが大量に流入し、トリアージして適切な専門家に割り振る必要が生じました。下のグラフは、過去1年間に新規に作成されたイシューの数を示しています： ![](/images/2020-08-01-data-science-meets-devops/fig1.num-issues.png) 図1: Kubeflowイシューの数 この流入に対応するため、機械学習を使用してイシューに自動的にラベルを付ける「Issue Label Bot」というGitHubアプリへの投資を開始しました。最初のモデルは、GitHub上の人気のあるパブリックリポジトリのコレクションを使用してトレーニングされ、一般的なラベルのみを予測しました。その後、Google AutoMLを使用してKubeflow固有のモデルをトレーニングし始めました。新しいモデルは、平均精度72％、平均再現率50％でKubeflow固有のラベルを予測できるようになりました。これにより、Kubeflowメンテナのイシュー管理に関連する負担が大幅に軽減されました。以下の表は、ホールドアウトセットに対するKubeflow固有ラベルの評価指標を含んでいます。以下の精度と再現率は、私たちのニーズに合わせて調整した予測しきい値に対応しています。 area-centraldashboard area-components area-sdk-dsl-compiler 表1: 様々なKubeflowラベルの評価指標 新しいイシューが到着する速度を考えると、モデルを定期的に再トレーニングすることが優先事項となりました。この新しいデータを活用するためにモデルを継続的に再トレーニングしデプロイすることは、モデルの有効性を維持するために重要であると考えています。 私たちのCI/CDソリューションを図2に示します。MLワークフローのステップ（前処理、トレーニング、検証、デプロイなど）を接続するために、有向非巡回グラフ（DAG）を明示的に作成することはありません。代わりに、一連の独立したコントローラーを使用します。各コントローラーは、望ましい世界の状態を宣言的に記述し、実際の世界の状態をそれに一致させるために必要なアクションを実行します。この独立性により、各ステップに最も適したツールを自由に使用することが容易になります。具体的には以下を使用しています： モデル開発にはJupyterノートブック。 継続的インテグレーションとデプロイにはGitOps。 基盤となるインフラストラクチャにはKubernetesとマネージドクラウドサービス。 ![](/images/2020-08-01-data-science-meets-devops/fig2.ci-cd.png) 図2: 私たちのCI/CDの方法を示しています。現在のパイプラインは、独立して動作する2つのコントローラーで構成されています。トレーナー（左側）は、どのモデルが存在すべきか、つまり私たちのモデルが「新鮮である」とはどういうことかを記述することで設定します。トレーナーは定期的に、トレーニング済みモデルのセットが十分に新鮮かどうかをチェックし、そうでない場合は新しいモデルをトレーニングします。同様に、デプロイヤー（右側）を設定して、デプロイされたモデルがトレーニング済みモデルのセットと同期している状態を定義します。正しいモデルがデプロイされていない場合は、新しいモデルをデプロイします。 モデルトレーニングとデプロイの詳細については、以下の「アクチュエーション」セクションを参照してください。 レコンシラーによるレジリエントシステムの構築 レコンシラーは、レジリエントなシステムを構築する上で非常に有用であることが証明されている制御パターンです。レコンシルパターンは、Kubernetesの動作の中心にあります。図3は、レコンシラーがどのように機能するかを示しています。レコンシラーは、まず世界の状態（例：現在デプロイされているモデル）を観察することで機能します。次に、レコンシラーはこれを望ましい世界の状態と比較して差分を計算します（例：ラベル「version=20200724」のモデルがデプロイされるべきだが、現在デプロイされているモデルはラベル「version=20200700」を持っている）。その後、レコンシラーは世界を望ましい状態に導くために必要なアクションを実行します（例：デプロイされたモデルを変更するためのプルリクエストを作成する）。 ![](/images/2020-08-01-data-science-meets-devops/fig3.reconciler.png) 図3. 私たちのデプロイヤーによって適用されるレコンシラーパターンの図解。 レコンシラーは、システムがどのように乱されても最終的に望ましい状態に戻るという高い確信度を提供するため、レジリエントなシステムを構築する上で非常に有用であることが証明されています。 DAGは存在しない コントローラーの宣言的な性質は、DAGを明示的に作成することなく、データが一連のコントローラーを通過できることを意味します。DAGの代わりに、一連のデータ処理ステップは、以下の図4に示すように、一連の望ましい状態として表現することができます： ![](/images/2020-08-01-data-science-meets-devops/fig4.data-pipeline.png) 図4: DAGを明示的にエンコードすることなく、独立したコントローラーからパイプラインがどのように生じるかを示しています。ここには2つの完全に独立したコントローラーがあります。最初のコントローラーは、すべての要素aiに対して要素biが存在すべきことを保証します。2番目のコントローラーは、すべての要素biに対して要素ciが存在すべきことを保証します。 このレコンシラーベースのパラダイムは、多くの従来のDAGベースのワークフローに比べて以下の利点を提供します： 障害に対する回復力：システムは継続的に望ましい状態を達成し維持しようとします。 エンジニアリングチームの自律性の向上：各チームは、自分たちのニーズに合ったツールとインフラストラクチャを自由に選択できます。レコンシラーフレームワークは、コントローラー間の結合を最小限に抑えながら、表現力豊かなワークフローを記述できるようにします。 実戦でテストされたパターンとツール：このレコンシラーベースのフレームワークは、何か新しいものを発明するものではありません。Kubernetesには、コントローラーを簡単に構築できるようにすることを目的とした豊富なツールエコシステムがあります。Kubernetesの人気は、このパターンとサポートツールに精通した大規模で成長中のコミュニティが存在することを意味します。 GitOps：プルリクエストによる運用 GitOps（図5）は、インフラストラクチャを管理するためのパターンです。GitOpsの核となる考え方は、ソース管理（Gitである必要はありません）が、インフラストラクチャを記述する設定ファイルの信頼できる情報源であるべきだということです。コントローラーはソース管理を監視し、設定の変更に応じて自動的にインフラストラクチャを更新できます。これは、変更を加える（または変更を元に戻す）ためには、単にプルリクエストを開けばよいことを意味します。 ![](/images/2020-08-01-data-science-meets-devops/fig5.gitops.png) 図5: Label Botに新しいモデルをプッシュするには、使用したいAuto MLモデルのIDを格納している設定マップを更新するPRを作成します。PRがマージされると、Anthos Config Management（ACM）が自動的にそれらの変更をGKEクラスターにロールアウトします。その結果、それ以降の予測は新しいモデルを使用して行われます。（画像提供：Weaveworks） 統合：レコンシラー + GitOps = MLのためのCI/CD 背景を説明したので、レコンシラーとGitOpsのパターンを組み合わせてMLのためのCI/CDをどのように構築したかについて詳しく見ていきましょう。 解決する必要があった問題は3つありました： 望ましい状態と実際の状態の差分をどのように計算するか？ 実際の状態を望ましい状態に一致させるために必要な変更をどのように実行するか？ 1と2を継続的に実行する制御ループをどのように構築するか？ 差分の計算 差分を計算するために、私たちは単に必要なことを正確に行うラムダを記述します。したがって、この場合、2つのラムダを記述しました： 最初のラムダは、最新モデルの経過時間に基づいて再トレーニングが必要かどうかを判断します。 2番目のラムダは、最新のトレーニング済みモデルと、ソース管理にチェックインされた設定マップにリストされているモデルを比較することによって、モデルを更新する必要があるかどうかを判断します。 これらのラムダを単純なWebサーバーでラップし、Kubernetesにデプロイします。このアプローチを選択した理由の1つは、Kubernetesのgit-syncに依存して、リポジトリをポッドボリュームにミラーリングさせたかったからです。これにより、すべてのGit管理はgit-syncを実行するサイドカーによって処理されるため、ラムダは非常にシンプルになります。 必要な変更を適用するために、私たちはTektonを使用して

データサイエンスとDevOpsの融合：Jupyter、Git、Kubernetesを用いたMLOps

背景や根拠まで確認しますか？

調べる

選ぶ

サイト