機械学習を扱うプラットフォーム開発と運用事例

LINEヤフーにおける機械学習プラットフォームの開発・運用事例を紹介します。Batch ML基盤を軸に、Job QueueやAirflowによるジョブ管理、モデルリリースやData Layer、リソース追跡サービスなど、安定したML提供を支える技術的取り組みを解説します。

Transcript

1. © LY Corporation 機械学習を扱う プラットフォーム開発と 運用事例 LINEヤフー株式会社 データグループ DSV統括本部3本部Machine Learning Platform部 開発1チーム 櫻井義孝
2. © LY Corporation 2 櫻井 義孝 Sakurai Yoshitaka LINEヤフー株式会社 データグループ DSV統括本部3本部 Machine Learning Platform部 開発1チーム 2020年4月 LINE株式会社 新卒入社 Data Scienceセンター Machine Learning室 ML1配属
3. © LY Corporation Agenda Machine Learning Platformチーム 開発事例紹介 Batch ML基盤 Batch ML基盤のアーキテクチャ Batch MLとJob Queue Batch MLとモデル管理 Batch MLと定期実行 Batch MLとData Layer Batch MLとリソース追跡 3
4. © LY Corporation • Machine Learning Platform（以降MLPFと呼ぶ） • MLの持続的な開発・活用をサポートするためのプラットフォーム • MLPFチーム • MLPFのうち「ML以外の部分」を担当。MLエンジニアではなくSWE・SREとしての役割 • 今回は開発事例としてBatch ML基盤の開発におけるMLPFチームの取り組みを中心に話します 4 Machine Learning Platformチーム
5. © LY Corporation • Batch ML以前 • MLエンジニアがサービス毎にモデルの実装から・特徴量の準備・Training・推論・validation・スト レージへの出力などまで行っていた • サービス毎にMLエンジニアがMLパイプラインを一通り実装する必要がありモデルの開発に集中し にくい • Batch ML基盤 • 推薦・分類・予測・embeddingなどのML部門が提供するML SolutionにWeb APIインターフェース を通じてアクセスできる仕組み • ユーザーはMLのパイプラインの実装が不要 • MLエンジニアはモデルの開発に集中できる 5 開発事例: Batch ML基盤
6. © LY Corporation Batch ML基盤 アーキテクチャ API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
7. © LY Corporation Batch MLとJob Queue(1) API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
8. © LY Corporation 役割 • APIの非同期化 • MLジョブの同時実行数を制御 → リソースを調整 • プロジェクトごとに優先度を制御 課題: リクエストされたジョブが長時間実行されない • Batch MLはサービスに提供するデータを生成するジョブがあるためキューを挟んでいても極端に実行ま での時間を長くするわけにはいかない • 優先度が低いにも関わらず実行枠を占めてしまうジョブが出現した • 例えばOptunaでのハイパラチューニング • 当初は優先度を極端に下げて対応しようとしたが、他のジョブがない時にリクエストされると実行枠を 占めてしまう ⇒ Job Queueを目的毎に別のQueue自体を分割できるよう改修 ⇒ Optuna Queueは同時実行上限を1にしてリソースを減らす Job Queueの課題と解決 8 Batch MLとJob Queue(2) 実行枠 Job Queue Optuna Jobが実行 枠を占めてしまう ジョブが実行されずサービス に提供するデータが作れない
9. © LY Corporation Batch MLとモデル管理(1) API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
10. © LY Corporation Batch MLはモデルを以下の情報の組み合わせを管理 • モデル名 • モデルタイプ（recommendation, classification, regression, …) • バージョン • 対応するDockerイメージ ユーザーからのリクエストで指定されたモデルに対応するDockerイメージでMLジョブを起動 モデルの定義 10 Batch MLとモデル管理(2)
11. © LY Corporation モデルのリリースが大変 • YAMLでモデルのリリースを管理 • リリースのためのPull Requestのサイズが大きい • 変更をWikiと照らし合わせる • モデル数が多い • Batch MLが管理するモデル数が非常に多い • 1回のPRで大量のモデルを変更 • リリース時の変更が多く目視での確認ではエラーが発生しやすい モデルの管理も手間 • Git管理しているモデルをデータベースに自動で登録 • リリースミス時に修正のための固有の対応を求められる モデルのリリース方法 11 Batch MLとモデル管理(3)
12. © LY Corporation • モデルのリリースのためのYAMLを改善 • 同じDockerイメージを複数のモデルで利用している ⇒ モデルをグループ化して一括でDockerイメージを変更可能にする • モデルのリリースの修正を簡単に反映されるようにする • モデルのリリース内容を修正してたら生成されるモデルのカタログも自動で更新したい ⇒ Kubernetes CRDを開発。モデルのカタログはConfigMapとして出力される ⇒ Argo CDでモデルリリースを管理可能 モデルのリリース方法の変更 12 Batch MLとモデル管理(4) backendの導入で ghee-models backendのモデルを 一括で更新可能に
13. © LY Corporation Batch MLと定期実行(1) API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
14. © LY Corporation MLPFはAirflowを運用 • 機械学習を含む定期的なジョブをサポート • Batch ML以外も入れると700以上のDAGが存在。(DAGとはAirflowのジョブの概念) 運用上の課題が非常に多い。以下は課題の例。 Airflow運用の課題 14 Batch MLと定期実行(2) バージョンアップ • DBマイグレーションscriptのエラー • DAGのスケジュール挙動が変わり動かなくなる 新規にAirflowインスタンスとDBインスタンスを構 築した上で過去データをコピーして更新 git-sync • GitHub Enterpriseのメンテナンスがジョブに 影響 • GitHub Enterpriseからの取得周期の問題 • Shared Storage(Persistent Volume)にGitSync でリポジトリをcloneし続けるがShared Storageの安定性の問題で障害が多発 git-mirrorを開発 指定したリポジトリをコピーしてcloneできるよう にするサーバー DAGロードに時間がかかる • AirflowはDAGファイルを1つずつ探してpython execでロードするのでファイルを置いてから反 映まで時間がかかる • YAMLに設定を書いてDAGから参照するコード のSyncが遅い Import pandasを消すなどのキャンペーン
15. © LY Corporation • Airflowの運用課題をどうするか？ • Argo Workflowsなど他のツールに移るのも選択肢の1つ • 頻繁にツールを変更するのはマイグレーションコストが大きすぎる • 全てのDAGを移行する必要 • 過去にAzkabanからAirflowへのマイグレーションを経験 • Schedulerサービスの開発に着手 • インターフェースとバックエンドへの繋ぎ込みを開発してバックエンドを切り替えられるように • バックエンドは必要に応じて切り替えられる 15 Batch MLと定期実行(3) Scheduler Service Backend Argo Events Backend Airflow Backend Argo Workflows
16. © LY Corporation Batch MLとData Layer(1) API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
17. © LY Corporation Batch MLへのリクエストにはHDFSパスが出現 • ストレージであるHDFSを意識する必要→ 導入障壁 • データの経路をKafkaに統一したい ⇒ Data Layerサービスの開発に着手 Data Layerでは • 各種ストレージのデータのメタデータを扱う • Kafka / HDFS / Hive Table / S3 • データをバージョン管理 17 Batch MLとData Layer(2) Data Layer Kafka S3 HDFS HDFS Batch ML HDFSとは？ 大きなデータを分散して保存する Hadoopのファイルシステム
18. © LY Corporation Batch MLとリソース追跡(1) API Server Job Queue Job Worker ML Jobs 学習用Pod GPUクラスタ 全社データ基盤 MySQL モデル・リクエスト管理 定期実行 GitHub Enterprise モデルのメタ情報登録 Web UI LINE DEVDAY2021 RPC Library for Distributed Processing Used for Machine Learning ユーザー モデル開発者 モデル登録 Airflow Ray
19. © LY Corporation • MLのためのリソースが必要量よりも大幅に確保されているケース • 他のジョブの設定を真似る • とりあえず動くように多めに取っておく • MLジョブはKubernetesやYARNなど複数のレイヤーでリソースを取得しているのでリソース取得に関す る全体像の把握が難しい ⇒ ジョブ毎のリソース追跡用のサービスを開発 • 各プラットフォームで利用した リソースをジョブ毎に追跡ができる • Kubernetes(CPU/GPU/MEM) • SparkのためのYARN(CPU/MEM) • その他Private Cloudの利用量 19 Batch MLとリソース追跡(2)
20. © LY Corporation 20 他にもこんなことをやっています • Realtime基盤での取り組み • Kubernetesの運用 • アラート • プロファイリング