ヤフーの全社共通レコメンドプラットフォームでのMLOpsの取り組み #mlopsコミュニティ

公開 ヤフーの全社共通レコメンドプラットフォームでの MLOpsの取り組み ヤフー株式会社 サイエンス統括本部 植草 智輝 Copyright (C) 2020 Yahoo © Yahoo Japan Japan Corporation. All Rights Reserved.

公開 アジェンダ 1. ⾃⼰紹介 2. プラットフォームの紹介 3. MLOpsの取り組み 4. 課題点 5. 今後の展望 6. まとめ © Yahoo Japan 2

公開 アジェンダ 1. ⾃⼰紹介 2. プラットフォームの紹介 3. MLOpsの取り組み 4. 課題点 5. 今後の展望 6. まとめ © Yahoo Japan 3

公開 ⾃⼰紹介 植草 智輝 / Tomoki Uekusa 経歴 ヤフー⼊社後、データプラットフォーム本部でコマース系のビッグデータ基盤チームに所属 そこでApache Airflowの新規導⼊やApache Kylin / HBaseの開発・運⽤を担当 その後、全社のビッグデータ処理基盤（Hadoopエコシステム）のDevOpsチームに所属 Hadoopクラスタの運⽤や社内でのApache Spark導⼊などを推進 1年半ほど前からサイエンス組織の全社共通レコメンドプラットフォームのMLOpsチームに所属 組織横断のMLOps推進チームにも所属し、社内MLOpsコミュニティの⽴ち上げ・運営などを実施 趣味 海外ドラマ鑑賞 ／ 筋トレ ／ ゲーム ／ 映画 ／ スポーツ観戦 @tmk_ueks tomueeen93 © Yahoo Japan 4

公開 アジェンダ 1. ⾃⼰紹介 2. プラットフォームの紹介 3. MLOpsの取り組み 4. 課題点 5. 今後の展望 6. まとめ © Yahoo Japan 5

公開 2. プラットフォームの紹介 全社共通レコメンドプラットフォームとは ログデータだけで使えるサービス共通のレコメンドプラットフォーム あなたにおすすめ あなたにおすすめ 共通レコメンドプラットフォームのAPI経由で取得 © Yahoo Japan 6

公開 2. プラットフォームの紹介 プロダクトの特徴 ２０を超えるサービスから利⽤されている リクエスト数は最⼤５億／⽇ほど 各サービスで複数のモデルの管理している ビジネス要件による機能追加もある 新しいサービスでも簡単に導⼊したい ある程度精度の良いレコメンドもしたい © Yahoo Japan 7

公開 考えることが多い。。。 © Yahoo Japan 8

公開 2. プラットフォームの紹介 システム概要 アプリケーション(ロガー) 全社データ処理基盤 モデルストレージ 全社k8s基盤 アプリケーション 全社ABテスト基盤 Object Storage CPU 開発基盤 GPU ジョブオーケストレーション 全社AI基盤 © Yahoo Japan 9

公開 アジェンダ 1. ⾃⼰紹介 2. プラットフォームの紹介 3. MLOpsの取り組み 4. 課題点 5. 今後の展望 6. まとめ © Yahoo Japan 10

公開 3. MLOpsの取り組み MLOpsの改善の検討と取り組み⽅法 Google の MLOps Level や ML Test Score をもとに分析 課題点や改善したい項⽬を絞り優先度をつける 技術調査などで実施内容や実現可能性について検討する PoCとしていくつかのモデル・サービスに適⽤ 効果があれば全モデル・サービスに適⽤ © Yahoo Japan 11

• https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

公開 3. MLOpsの取り組み 項⽬ 優先度 実施カテゴリ 検討内容 デプロイ管理ツール(CuttySark)導⼊ 高 モデルの継続的デリバリー モデルデプロイ管理を⼤きく改善出来る データバリデーション導⼊ 高 データとモデルの検証 データとモデルの検証 ＞データスキーマスキューの検出でやりたい great expectationsの利⽤を検討したい モデルバリデーション導⼊ 高 データとモデルの検証 モデルの性能劣化などのバリデーションやドリフト検知を実施 推論サーバー⼊⼒を監視したりする必要がある 学習データと推論時のデータを同じものにする必要がありそう 開発環境から本番環境の運⽤フロー整備 高 迅速なテスト テストと運⽤の対称性 コンポーネントとパイプライン ⽤のモジュール化されたコード パイプラインのデプロイ モデル開発 → ABテスト → 本番稼働のコストをできるだけ低くする 学習・推論などに再現性を担保 papermillの運⽤フローを検討 リポジトリやスクリプトの整理が重要そう MLflow導⼊ 中 メタデータ管理 モデルのメタデータと実験管理をする デプロイ管理とともに必要となる可能性がある MLflowの利用方法の検討から実施する オフラインモデル検証の改善 中 データとモデルの検証 モデル開発・チューニング時の数字との⽐較ではなく 前回モデルとのパフォーマンスを⽐較してデプロイする まず任意のバージョンのモデルのデプロイ管理が簡単にしてから オンラインモデル検証の導⼊ 中 データとモデルの検証 カナリアリリースでの動作検証やオンラインKPIチェックを実施 オンライン指標を元にした再学習 低 本番環境でのモデルのCT MLパイプライントリガー オンライン指標を元にして、性能が下がったら再学習するようにする 基本的に最新の学習が効果は薄いかもしれない Feature Store作成 低 Feature Store 学習と推論時のデータを同じものにしてStoreから引けるようにする 学習時と推論時で同じ特徴が使えるように保証することを⽬標 ⾃分達で基本的に作ることはせず、社内の共通基盤利⽤を想定 © Yahoo Japan 実施した内容 今回は未実施の内容 12

公開 3. MLOpsの取り組み papermillを使った開発 課題点 本番稼働までの実装コストが⾼かった • モデル検証時はnotebookを利⽤して実⾏ • A/Bテストはpythonに書き換えて専⽤サーバーからcron実⾏ • 本番実⾏時はAirflowからPodを建ててpythonを実⾏ 導⼊モチベーション 「仮説を⽴てて検証する」ことを素早く何度も反復出来る環境をめざす 参考URL︓https://techblog.yahoo.co.jp/entry/2021110830236406/ • notebookをそのままArgo Workflowsでジョブ化できる • 利⽤⽅法はパラメータに使う⽤のセルをタグ付けするだけ • 実⾏時にタグ付けしたセル内の変数をパラメータで上書き可能 © Yahoo Japan 13

公開 3. MLOpsの取り組み papermillを使った開発 実施内容 • モデルはJupyter Notebookと papermillを使った開発⽅法に変更 • 定期実⾏も直接notebookを実⾏出来るよう Argo Workflowsを利⽤ • 同じ処理の部分を 共通の関数・モジュール化 し整備 • データ作成時に実施する テスト内容などを整理 • 開発時と実⾏時で 同じDockerイメージを利⽤して環境の⼀貫性を担保 © Yahoo Japan 14

公開 3. MLOpsの取り組み papermillを使った開発 まとめ • 1モデルの開発に15営業⽇かかる⾒込みが 12営業⽇ほど で完了するように • 約2割程度の⼯数削減 を実現 • 数値以上にモデル開発のスムーズな開発が体感できた • notebookとしても実⾏できるため テストやデバッグなどもしやすく なった • ⼀⽅ github上のレビューは難しくなる • nbdimeや対応しているエディタ上で差分を⾒るなどの⼯夫が必要 © Yahoo Japan 15

公開 3. MLOpsの取り組み データバリデーションの導⼊ 課題点 複数のサービスのログの仕様変更を検知できない • ログの仕様から変更されていることがある • 異なる仕様のデータが混在して学習に悪影響が出る可能性もある • 悪影響が出たことも検知できるとは限らない (例: 仕様では数値のみ → ⽂字列が混⼊) 導⼊モチベーション 基本的なバリデーションは全データに⼊れておきたい • 全ては難しいが最低限のログの仕様変更に気づきたい • データ量に⼤きな変更があった場合には検知したい © Yahoo Japan 16

公開 3. MLOpsの取り組み データバリデーションの導⼊ 実施内容 データソース（処理前のRAWデータ）のバリデーション • • 「集計対象データの⾏数 / データ全体の⾏数」が閾値を下回らないか 確認 中間テーブル（学習前の整理されたデータ） • • NULLを取るべきでない値の NULLチェック • カテゴリカルなデータの値が 指定した集合に含まれるかの確認 • 上記の補填としてカテゴリカルなデータの ユニーク数チェック • 想定した 仕様（正規表現）にデータがあっているか • Jaccard係数を使った異常値の検知（独⾃実装） © Yahoo Japan 参考URL︓https://en.wikipedia.org/wiki/Jaccard_index 17

公開 3. MLOpsの取り組み データバリデーションの導⼊ まとめ • great expeca*onsの設定ファイルを指定するだけなので 簡単に利⽤できた • ログの 仕様変更などを検知できる ようになった • サービスメンテ・事故による ログの減少を素早く検知・確認できた • ログ仕様についての知識の属⼈化が緩和 できた • データソースの ⾏数監視は閾値の設定が難しい • 運⽤しながら 徐々に閾値を調整していくことが必要 だった © Yahoo Japan 18

公開 3. MLOpsの取り組み MLflowの活⽤、デプロイ管理への取り組み 課題点 モデルのデプロイ管理がされていない • 学習時と推論時のTensorflowのライブラリバージョンの管理がしづらい • 任意バージョンのモデルのデプロイが出来ない・ロールバックしづらい • 複数モデルでの性能⽐較ができていない 導⼊モチベーション AIPF/CuttySark (推論サーバ管理基盤[社内専⽤]) デプロイ管理をもっと簡単に出来るようにしたい • MLflowにモデルを登録しバージョン管理 Ø • 参考URL︓https://techblog.yahoo.co.jp/entry/2021083130180585/ 任意のバージョンを簡単に取り出すことが可能に CuttySark(社内専⽤)を利⽤したモデルデプロイ⽅法に変更 Ø 性能⽐較をすることも簡単に出来るように Ø 簡単に任意のバージョンを⽤いた推論サーバーを作成可能 © Yahoo Japan 19

公開 3. MLOpsの取り組み MLflowの活⽤、デプロイ管理への取り組み 実施内容 • すべての学習モデルの結果をMLflowに登録する ようにパイプラインを変更 • 学習のオフラインメトリクスも登録し 新旧モデルで性能⽐較が出来る • モデルのデプロイはCuttySarkを利⽤して推論サーバーを作成 • 現在は⼀部モデルのみに適⽤中 • 今後は新旧の性能⽐較をして 性能向上している場合のみデプロイ する⽅針 © Yahoo Japan 20

公開 3. MLOpsの取り組み MLflowの活⽤、デプロイ管理への取り組み まとめ • MLflowでモデルのバージョン管理を実施することで 性能⽐較が可能になった • CuttySarkを利⽤して 任意のバージョンの推論サーバーを簡単に作成可能 に • モデルに問題が起きた場合に ロールバックすることが容易に出来る • 今後のデプロイ管理や 様々なMLOps改善に向けた前段階の準備が完了 • 再学習や再検証をしやすくするため パイプラインに⼤きめの変更が必要だった © Yahoo Japan 21

公開 アジェンダ 1. ⾃⼰紹介 2. プラットフォームの紹介 3. MLOpsの取り組み 4. 課題点 5. 今後の展望 6. まとめ © Yahoo Japan 22

公開 4. 課題点 • papermillのnotebookの書き⽅は適度に ルール整備・モジュール化が必要 • notebookの レビュー作業には課題が残っている • データバリデーションを⼊れると アラートが多くなり運⽤負荷は上がる • 異常検知の 閾値の設定は難しい • デプロイパイプラインの変更は結構⼤掛かりな作業 となる © Yahoo Japan 23

公開 5. 今後の展望 • データだけでなく モデルのバリデーション を実施して品質を担保 • デプロイ管理が可能になり 再学習・デプロイの⾃動化 を⽬指す • オフライン・オンラインでのモデル性能⽐較 を強化 • MLOps改善のための要件の検討とPoCを継続 していく © Yahoo Japan 24

公開 6. まとめ • 複数サービス・モデルが利⽤するレコメンドプラットフォームのMLOps改善の話 • Googleの MLOps Level や ML Test Score などから実施項⽬を検討 • papermillによるモデル開発 で開発⼯数を約2割程度削減 • great expectationsによるデータバリデーション を実施しデータの品質を向上 • MLflowと社内ツールCuttySarkにて モデルのデプロイ管理を可能に した • MLOps LevelやML Test Scoreの向上を⽬指すと やることはかなり多い © Yahoo Japan 25

公開 © Yahoo Japan