USENIX OpML'19 登壇・参加報告会のメモ

USENIX OpML'19 登壇・参加報告会（Hadoopソースコードリーディング 第26回）

• https://www.eventbrite.com/e/usenix-opml19-hadoop-26-tickets-62192922706

USENIX OpML全体紹介

• 参加者：210名
• 日付：2019.5.20
• 場所：サンタクララ
• 採択率は約5割。投稿62件
• Practiceの傾向が強かった
• 参加者もシステム系の人の方が多かった印象

USENIX OpML発表資料

• OpML '19 Conference Program | USENIX

登壇内容紹介：Low-latency Job Scheduling with Preemption for the Development of Deep Learning

薮内 秀仁 /東京大学大学院

発表資料はUSENIXのページで公開されている

• 本論文はPFNでインターンしていた時の研究内容
• 効率的なリソースマネジメントがDL開発では重要
• 最適なパラメータ探索のためにジョブを多数実行する。Try & Error(TE)
• それ以外ではパラメータ決定後に大規模データで評価するBest-Effortなジョブ（BE)
• TEとBEなジョブの混在環境において、スケジューリングするアルゴリズムを提案
  • TE jobの時間をLow-latencyにするために、BE jobはサスペンドされ得ることを許容した
• System Model
  • k8sのようなシステムを想定
  • サスペンドにはDL frameworkの多くがサポートしているチェックポイントを利用
• Grace Period
  • サスペンドする前の停止前処理が実行される期間のこと
• Fitting Grace Period Preemption(FitGpp)
  • BE jobが多数ある時に、サスペンドするBEを選択するアルゴリズムが必要
  • サスペンドされたBE jobはキューの先頭に戻され、次に再度、実行される
• Minimizing Re-scheduling Intervals
  • サスペンドするのは少ないリソースを要求するBEが望ましい
  • 大きいとリソースを停止、またすぐに実行するというオーバーヘッドが大きくなってしまうから
  • （BE jobの要求リソースは大きい傾向があるものなのでは？）
  • サスペンドするBE jobは小さすぎてもダメで、次に実行されるTEのリソースに不足が発生しないような BE jobをサスペンドする必要がある
• Avoiding Starvation
  • １つのBE jobがサスペンドされる最大回数を設定
• Evalution
  • PFNで実際に実行されていたジョブの傾向を見て、それをシミュレーションした環境で評価

登壇内容紹介：A Distributed Machine Learning for Giant Hogweed Eradication

梅森 直人 /NTTデータ

発表資料はUSENIXのページで公開されている

分散学習の話。

Giant Hogwed Eradication Project

• デンマークでのプロジェクト
  • Hogweedという毒性のある植物を手作業で切り出している
• デンマーク国土：3217 km平方メートル。農耕地は62%。これをターゲットとした
• 課題：データ量：200TB
  • ドローンが撮影した4K動画
• 課題：Preparation of Supervised Data
  • 空撮動画から判別するのが困難
  • Hogweedに詳しくない人でもラベリングできるツールを開発
• 課題：Coordinate Calculation at Pinpoint
  • 空撮動画の撮影範囲が20m程度あるので、正確な位置座標がわからない
• 考察
  • データ量が200TBなので、マシンは自然と複数台構成の分散構成となる
    • 単一ノードとは性質が異なる
  • 運用はどうする
• Data Pipelines
  • NTTデータにはビッグデータに対応するためのData Pipelinesアーキテクチャがある
    • プロジェクトによって、必要に応じて取捨選択などしている
• Distributed-ML Code
  • シーケンス図を書いて、コンポーネント間のやりとりが複雑になることがわかった
  • これを出発点として、やりとりが減るようにパイプラインの設計を改良した

OpML 聴講内容紹介：参加者による注目すべきセッションの紹介

Relevance Debugging and Explainable xxx

• Linkedinのシステムで、ユーザの関連情報提供サービスのデバッグ
• 関連情報を提供するアーキテクチャは階層化されており、複雑。デバッグ難しい
• デバッグの難しさ
  • 複雑なインフラ
  • 再現性。その時の本番データでないと再現できないことが多い
  • 時間がかかる
• デバッグのための仕掛け
  • 各コンポーネントで発生したログをKafkaに集約し、後からトレースできるようにする
  • ログの可視化機能
    • 各リクエストの成否の表示
    • 時間のかかっている箇所の表示
    • など
  • 比較
    • モデルやクエリを変えた時の結果の違いを比較表示
  • Replay
    • あるユーザの操作で表示される画面を再現
• MPP: Model Performance Predictor
  • 機械学習をプロダクションで運用する際に、モデルの良し悪しを知りたい
  • しかし、プロダクションでは正解データがない
  • パフォーマンス値自体を推定しよう
  • 推定時と同じ特徴量を入力として、出力は推定が正解、不正解になるという２値判定を行う

MLOp Lifecycle xxx

• Sumsungの話
• 製造した製品の不良検知に機械学習を適用
• 課題：ステークホルダーごとにニーズが異なる
• ステークホルダー
  • Product inspector（品質検査官）
  • Model developer（機械学習モデル開発者）
  • Product manager
  • Operations manager
• ステークホルダーごとにシステムアーキテクチャを分けた

Deep Learning Inference xxx

• Microsoftの話
• 早く、自由に組み替えられるアーキテクチャが必要
• Deep Learning Inference Service(DLIS)アーキテクチャ
• モデルによって必要なハードウェアが異なるので、最適配置を行う
  • CNN型のニューラルネットワークモデルであればGPU
  • 再帰型のニューラルネットワークモデルであればFPGA, CPU
• 数万のモデルインスタンスを用いて秒間数百万のリクエストを処理できる
• QA
  • オンラインの推論処理の話

Tensorflow Extended(TFX)

• ML-metadata
  • Data driven。ある処理の出力（artifact）があったら、次の処理が動く
• TFXではTask drivenでもサポートする

Katib: A Distributed General AutoML Platform on Kubernetes

• kubeflowのコンポーネントとして実装
• AutoML Workflows
  • Hyperparameter Tuning
  • Neural Architecture Search
• 類似品に対する強み：k8s native
• k8sとして実行するので、一部が死んでも系全体は活き続ける