Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【輪講】Ray: A Distributed Framework for Emerging ...

【輪講】Ray: A Distributed Framework for Emerging AI Applications

Tomoya Ishizaki

June 21, 2019
Tweet

More Decks by Tomoya Ishizaki

Other Decks in Programming

Transcript

  1. リファレンス • Philipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov,

    Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, and Ion Stoica, UC Berkeley • 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’18)
  2. 背景(1)ビックデータとAI / ML • ビックデータの時代 ◦ 大規模データの分散処理のために様々なフレームワークが開発 ▪ MapReduce ▪

    Apache Spark • AI / MLの分野の発展 ◦ 教師あり機械学習のために様々なフレームワークが開発 ▪ TensorFlow ▪ PyTorch ▪ Apatch MXNet
  3. 課題 • 強化学習のシステム構築は , 既存のフレームワークでは不十分 ◦ サービングやシミュレーションには向かない ▪ MapReduce, Apache

    Spark や TensorFlow, MXNet ◦ トレーニングやシミュレーションには向かない ▪ TensorFlow Serving, Clipper ◦ フレームワークを組み合わせて使用 ▪ 例:Horovod + Clipper + CIEL • ユースケース毎の独自実装 ◦ 単純に開発コストがかかる ◦ 複数のフレームワークを組み合わせることで スケジューリングやフォールトトレランス性 などが難しくなる
  4. 提案 • Ray ◦ 汎用クラスタコンピューティングフレームワーク • 強化学習のワークロードをサポート ◦ 処理を二種類に抽象化 ◦

    ステートレスなタスク ◦ ステートフルなアクター • スケーラビリティとフォールトトレランス性を実現 ◦ グローバルコントロールストア ◦ ボトムアップ分散スケジューラー
  5. タスクとアクター タスク アクター 状態 ステートレス ステートフル ロードバランシング 細かい 粗い ローカリティ

    高い 低い 更新時のオーバーヘッド 大きい 小さい 失敗時のオーバーヘッド 小さい 大きい
  6. Ray API usage ray.remote() futures = f.remote(args) actor = Class.remote(args)

    futures = actor.method.remote(args) ray.get() objects = ray.get(futures) ray.wait() ready_futures = ray.wait(futures, k, timeout)
  7. Ray API - タスク @ray.remote def zeros(shape): return np.zeros(shape) @ray.remote

    def dot(a, b): return np.dot(a, b) id1 = zeros.remote([5, 5]) id2 = zeros.remote([5, 5]) id3 = dot.remote(id1, id2) ray.get(id3) • 二つの行列を非同期で生成( id1, id2) • 二つの行列の内積を非同期で計算( id3) • id1, id2, id3はどれも「future」 • getで処理の終了を待機、結果を取得
  8. Ray API - アクター @ray.remote(num_gpus=1) class Counter(object): def __init__(self): self.value

    = 0 def inc(self): self.value += 1 return self.value c = Counter.remote() id1 = c.inc.remote() id2 = c.inc.remote() id3 = c.inc.remote() ray.get([id1,id2,id3]) # [1,2,3] • CounterクラスはGPUを使用 • Counterクラスのアクターを生成( c) • incメソッドを非同期で呼び出し • アクターの状態は各メソッドで共有
  9. アーキテクチャ • アプリケーションレイヤー ◦ ドライバー ◦ ワーカー ◦ アクター •

    システムレイヤー ◦ インメモリ分散オブジェクトストア ◦ ボトムアップ分散スケジューラー ◦ グローバルコントロールストア
  10. ボトムアップ分散スケジューラー • Spark, CIEL, Dryad ◦ 中央集権的にスケジューリングするため パフォーマンスに課題 • Stealing,

    Sparrow, Canary ◦ パフォーマンスは高いが それぞれ制約が存在 • ボトムアップスケジューラー ◦ 二つのスケジューラーで二段階に処理 ▪ ノード毎のスケジューラー ▪ システム共通のスケジューラー ◦ まずはローカルスケジューラー ◦ 処理不可のときグローバルスケジューラー
  11. グローバルコントロールストア • システム全体のステートを管理する • Redisで実装 ◦ pubsub機能を持ったKVS ◦ + シャーディング

    ◦ + チェーンレプリケーション • 状態を一元管理し, その他を ステートレスに • 状態が一箇所に集まっているため デバッグなどが容易
  12. E2Eでの実行例 • タスクの呼び出しと実行 ◦ (1)ローカルスケジューラーにタスクを送信 ◦ (2)グローバルスケジューラにタスクを送信 ◦ (3, 4)GCSを確認しスケジューリング

    ◦ (5, 6, 7)オブジェクトストアに引数を格納 ◦ (8, 9)ワーカーでタスクを実行 • タスクの結果を取得 ◦ (1, 2) オブジェクトストアとGCSを確認し, なければコールバックを登録する ◦ (3, 4, 5) タスク終了をトリガーにコールバック ◦ (6, 7)結果を取得してドライバーに返す
  13. 評価(2)既存フレームワークとの比較 • トレーニング ◦ ResNet-101 ◦ OpenMPI 3.0, TF 1.8,

    NCCL2 ◦ Horovod+TF以上, Distributed TFの90%以上 • サービング ◦ 4KBと100KBのインプット ◦ Ray >> Clipper • シミュレーション ◦ Pendulum-v0 ◦ 256CPUのとき1.8倍のスループット
  14. 評価(3)RLアプリケーション • 進化戦略アルゴリズム ◦ リファレンス実装は2048コアで失敗したのに対し , Rayは8192コアまでスケールアウト ◦ リファレンス実装は10分のベスト記録に対し ,

    Rayは半分以下の3.7分 ◦ リファレンス実装では数百行のコード変更に対し , Rayでは7行の変更のみ • PPOアルゴリズム ◦ Rayは全ての場合で最適化された MPI実装の パフォーマンスを上回る ◦ MPI実装はフォールトトレランス性を持たないため オンデマンドインスタンスが必要 ◦ Rayはスポットインスタンスを利用出来 , 1/18倍までのコスト削減が可能
  15. 関連研究 • ダイナミックタスクグラフ ◦ CIEL: a universal execution engine for

    distributed data-flow computing ▪ Murray, Derek G., et al. 8th ACM/USENIX Symposium on Networked Systems Design and Implementation. 2011. ▪ Rayと同様にリネージベースのフォールトトレランス性をサポート ▪ ステートフルな処理やマスターノードの分散化はサポートしていない • スケジューリング ◦ Omega: flexible, scalable schedulers for large compute clusters ▪ Schwarzkopf, Malte, et al. ▪ Rayと同様にグローバルな共有ステートを用いてスケジューリング ◦ Sparrow: Distributed, Low Latency Scheduling ▪ Ousterhout, Kay, et al. Twenty-Fourth ACM Symposium on Operating Systems Principles. ACM, 2013. ▪ 一般的なクラスタコンピューティングシステムでは中央集権的なスケジューラー