Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 大規模並列実験を支えるクラウドサービスと基盤技術
Semelhante a 大規模並列実験を支えるクラウドサービスと基盤技術 (20)
大規模並列実験を支えるクラウドサービスと基盤技術
- 2. 2 ▪ 加納龍一 (かのうりゅういち) ▪ DeNAに入社→Mobility Technologiesに出向 ▪ 交通移動体データの解析や、それらを活用した機械学習システムの社会実装 ▪ (昔話) 2年前から始まった社内DS勉強会の、ひとりめの発表者でした ▪ 張り切って準備した当時の発表資料: https://www.slideshare.net/RyuichiKanoh/lightgbm-124545133 自己紹介
- 5. 5 ▪機械学習において、万能な手法は存在しない (No Free Lunch) ▪ 何をするにあたっても、試行錯誤は必要 ▪Kaggle、実サービスの開発など、全て限られた時間の中での取り組み 試行錯誤の速度の重要性 ハイパーパラメータひとつで、 結果は大きく変わる https://myrtle.ai/learn/how-to-train-your-resnet-5-hyperparameters/
- 6. 6 ▪ 何かを導入すると、適切なパラメータがずれる ▪ 決め打ちで評価しても、よくわからない ▪ 偶然に左右される よくあるケース parameter A parameter A parameter B parameter B 従来手法 新規手法 この点のみで評価 この点のみで評価
- 7. 7 [1] 手持ちのインスタンスで直列に実験 ▪ pros: お手軽 ▪ cons: 死ぬほど時間がかかる [2] クラウドサービスを使用しインスタンスを大量に作成し並列化 ▪ pros: 高速に実験ができる ▪ cons: 下手にやると、かえって手間が増える アプローチ ここをいかにスマートに行うかが、今日のテーマ
- 8. 8 ▪ 一度デプロイして終わりではない ▪ 季節変動 ▪ 突発的イベント ▪ サービス地域拡大 ▪ 大型施設が新規開店 ▪ などなど、日々変化する状況に適応し続けていく必要がある ▪ モデル再デプロイごとに手動でパラメータを調整するのは大変 ▪ 規模が大きくなってもスケールする形での探索が、社会実装には必須 大量の実験が必要になるケース (サービスの継続的展開)
- 9. 9 ▪ 単純にひとつの指標のみを最適化すれば良い場合は少ない ▪ よくあるのが、下図のようなケース ▪ いくつかのケースを提示して、トレードオフを決める 大量の実験が必要になるケース (事業部への複数の結果の提示) 指標A 指標B 指標の間にトレードオフがある
- 10. 10 ▪ 一年前、KaggleDaysというイベントでワークショップを担当 ▪ https://kaggledays.com/events/tokyo2019/ ▪ その際のテーマは、「ラベルノイズに対しての手法」 ▪ 複数手法の効果をKaggleのデータを用いながら紹介するもの ▪ 大量のケーススタディを実施 大量の実験が必要になるケース (手法の検証)
- 12. 12 ▪ 複数モデルを用いたアンサンブル学習 ▪ Cross-Validationにおいて、Foldごとに学習を分散 ▪ 各手法の実験的探索(モデル構成、ハイパラ、前処理...) 大量の実験が必要になるケース (コンペティション) https://developer.ibm.com/technologies/artificial-intelligence/articles/stack-machine-learning-models-get-better-results/
- 13. 13 ▪ Compute EngineなどでVMインスタンスを立てまくる しかし、よく考えてみると... ▪ インスタンスの種類を変えるときには全部立て直す？ ▪ 実行した後にインスタンスを自動で落とすスクリプトを仕込む？ ▪ 環境構築、やればできるがいちいち面倒では？ 一番最初に思いつく方法 管理コストが尋常じゃない
- 14. 14 ▪ GCPのクラウド環境を利用した、様々な機能の集合 ▪ 訓練、予測API作成、パラメータ調整、分析環境構築... ▪ “AI Platform”と名前はついているが、機械学習以外でも活躍 便利なサービス：Google Cloud AI Platform
- 15. 15 各種機能 AI Platform Training https://cloud.google.com/ai-platform/training/docs?hl=ja Prediction https://cloud.google.com/ai-platform/prediction/docs?hl=ja Optimizer https://cloud.google.com/ai-platform/optimizer/docs?hl=ja Notebooks https://cloud.google.com/ai-platform/notebooks/docs?hl=ja Pipelines https://cloud.google.com/ai-platform/pipelines/docs?hl=ja Data Labeling Service https://cloud.google.com/ai-platform/data-labeling/docs?hl=ja Deep Learning Containers https://cloud.google.com/ai-platform/deep-learning-containers/docs?hl=ja Deep Learning VM Image https://cloud.google.com/ai-platform/deep-learning-vm/docs?hl=ja
- 16. 16 各種機能 (今日の話) AI Platform Training https://cloud.google.com/ai-platform/training/docs?hl=ja Prediction https://cloud.google.com/ai-platform/prediction/docs?hl=ja Optimizer https://cloud.google.com/ai-platform/optimizer/docs?hl=ja Notebooks https://cloud.google.com/ai-platform/notebooks/docs?hl=ja Pipelines https://cloud.google.com/ai-platform/pipelines/docs?hl=ja Data Labeling Service https://cloud.google.com/ai-platform/data-labeling/docs?hl=ja Deep Learning Containers https://cloud.google.com/ai-platform/deep-learning-containers/docs?hl=ja Deep Learning VM Image https://cloud.google.com/ai-platform/deep-learning-vm/docs?hl=ja
- 18. 18 ▪ 概観 AI Platform Training Local Machine AI Platform TrainingContainer Registry push pull command: ・マシンタイプ ・Docker image ・実行引数 job execution (CLI or python function) 所定のマシンでコンテナを動かし、 終わったらマシンを自動で消す CLIコマンド例 ＊カスタムコンテナを使うことが多いので、その場合を説明
- 19. 19 ▪ jobを複数投入すれば、複数同時に実行することが可能 ▪ 大量のインスタンスを用いた実験が簡単に！ AI Platform Training とある実験のスクリーンショット 30程度のインスタンスが同時に動作 ダッシュボードをクリックすれば、 ジョブごとのログや入出力なども確認できて便利
- 20. 20 ▪ AI Platform Trainingを用いて、大規模にパラメータ探索 AI Platform Optimizer 並列で実験を行い、 結果を最適化にフィードバック parameter_search.py (optunaなどを使ってもOK) command: ・マシンタイプ ・Docker image ・実行引数 (ここを調整) AI Platform Training feedback pull Container registry multiple suggest job execution
- 21. 21 ▪ 並列パラメータ探索実験結果の可視化 (wandbを使用) AI Platform Optimizer XGBoost MLP ばらつき ~ 0.008 ばらつき ~ 0.040
- 22. 22 ▪ 典型的なモデルについては、DockerImageが公開されている ▪ pathなどを引数で渡すことで、そのまま使用可能 ▪ 最近、微分可能な決定木を基盤としたモデルが標準実装された ▪ 表形式データに対する手法として期待 ▪ E2Eで様々なタスクに柔軟に対応 ▪ 階層構造を持った解釈性を持つ ▪ モデルの定期的なfinetuneがしやすい ▪ など、嬉しい点は色々ありそう ▪ 参考：(https://www.slideshare.net/RyuichiKanoh/miru2020-tutorial-237272385) Built-in algorithms in AI Platform Training Input: x Inner Node filter: w bias: b Leaf value: rl Leaf value: rr 1-σ(wx+b) σ(wx+b) Output [1-σ(wx+b)]*rl + [σ(wx+b)]*rr
- 23. 23 (余談) 微分可能な決定木の可視化, epoch=0 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 24. 24 (余談) 微分可能な決定木の可視化, epoch=1 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 25. 25 (余談) 微分可能な決定木の可視化, epoch=2 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 26. 26 (余談) 微分可能な決定木の可視化, epoch=10 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 27. 27 (余談) 微分可能な決定木の可視化, epoch=30 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 28. 28 (余談) 微分可能な決定木の可視化, epoch=60 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 29. 29 (余談) 微分可能な決定木の可視化, epoch=90 ＊このモデルは自分で実装したものなので、built-in algorithmとは違います
- 30. 30 ▪ 並列で実験を回したい際には、AI Platform Trainingが便利 ▪ GCP上で、任意のインスタンスを任意の数だけ立てて処理を実行できる ▪ VMを自分で複数立てるよりも、かなり管理コストが低い ▪ ハイパーパラメータ調整の枠組みとの親和性も高い ▪ 組込アルゴリズムも存在 ▪ 自分で実装しにくいようなものについても、パッと試すことができる 中間まとめ[1]
- 31. 31 ▪ 個人的には、シンプルなタスクに対してであれば十分だと思う ▪ “学習して予測精度を評価するだけ”の場合などは特に便利 ▪ しかし、凝ったことをしようと思うと、欲が出てくる ▪ 複数のコンテナ間で依存関係を保ちながら、よしなに動いてほしい ▪ 前処理、学習、評価、解析、シミュレーション... ▪ AI Platform Trainingのジョブ投入から起動までのラグ(~5min)が気になる ▪ 複数インスタンスを用いた分散学習がしたい ⇨Dockerで管理できる内容の外側に意識が広がる AI Platform Trainingで十分か？
- 32. 32 ▪ Dockerコンテナの運用管理のためのオープンソースシステム ▪ Cluster, Node, Podという構成要素 ▪ Cluster: インスタンスの集合 ▪ Node: ひとつのインスタンス ▪ Pod: インスタンスで実行される処理単位 Kubernetes (k8s)
- 33. 33 ▪ できることの例 ▪ ジョブを投入したら、PodをどのNodeで動かすか自動で割り当ててくれる ▪ AI Platform Trainingで顕著なjob投入後のラグは少ない ▪ 処理の状況に応じて、Nodeの数をオートスケールして増やす/減らす ▪ 使用量が少ないときにはコストはきちんと少なくなる ▪ 実験用途だけでなく、サービスのデプロイなどに使われることも多い ▪ リカバリなどが充実 ▪ クラウドサービスとの連携は必ずしも必要ない ▪ ここには詳しく書ききれないほど多機能 Kubernetes (k8s)
- 34. 34 ▪ コンテナ間の依存関係を解決しながらパイプラインを動かす ▪ 並列で動かせる部分は並列で ▪ 実行に失敗したものについてはリトライ ▪ 可視化との連携 ▪ メトリクス ▪ 実行関係 ▪ メタデータ 実験観点で実現したいこと
- 35. 35 ▪ Kubernetes環境でパイプラインを構築し実行するツール ▪ DAGのコンポーネントがコンテナに対応 ▪ 裏ではArgoが動いている ▪ DAGのデプロイが簡単 ▪ Airflow(Composer)と比べると実験向き Kubeflow Pipeline
- 36. 36 Kubeflow Pipeline 組込の可視化機能に加えて、 実験結果分析用のjupyter notebook実行を DAGの一部にしておくと 自由度の高い可視化がUI上で表示できて便利
- 37. 37 ▪ GCP managedなKubeflow Pipeline ▪ GKE(Google Kubernetes Engine)などを使用しながら、GCP内で完結 AI Platform Pipeline https://cloud.google.com/ai-platform/pipelines/docs/introduction?hl=ja
- 38. 38 ▪ 実験基盤としての観点 (私見) ▪ 両者は排他ではないので、合わせて使うことも多い ▪ Kubeflow Pipelineの一部でAI Platform Trainingを使用するなど AI Platform Trainingのみか、Kubeflow Pipelineまで使うか pros cons Kubernetes ・Kubeflowが相当便利 ・１コンテナで収まらない複雑な処理にスケール ・pipeline以外にも色々と機能が充実 ・ひとつのインスタンスで複数を処理できる ・必ずしもクラウドは不要 (自社サーバーとかでも) ・サービスをデプロイする際にそのまま横展開が可 ・クラスタの構築が手間 ・「少し強いマシンに変えようかな？」が面倒 ・学習コストがかかる ・組織に使用を強いると、少し大変な場合も AI Platform Training ・準備が楽 ・ジョブ投入時にマシンタイプを選べるなど ・管理コストが低い ・ひとつのインスタンスで複数処理はできない ・ジョブ投入から起動までにラグが5minほど存在 ・preemptibleインスタンスは使用不可
- 40. 40 ▪ タクシー乗務員へ向けた経路推薦サービス ▪ どこを通れば乗客を見つけやすいか、リアルタイムに推薦 ▪ ざっくりとしたエリアでなく、道路単位での経路を推薦 お客様探索ナビ (https://dena.com/jp/press/004550)
- 43. 43 ▪ 一度デプロイして終わりではない ▪ 季節変動 ▪ 突発的イベント ▪ サービス地域拡大 ▪ 大型施設が新規開店 ▪ などなど、日々変化する状況に適応し続けていく必要がある ▪ モデル再デプロイごとに手動でパラメータを調整するのは大変 ▪ 規模が大きくなってもスケールする形での探索が、社会実装には必須 社会実装に向けた課題(再掲)
- 44. 44 ▪ Kubeflow Pipeline + Optuna ▪ 最近ブログも公開されました：Blog, Slide ▪ 複雑な構成をうまく管理しながらパラメータを探索し、収益向上に貢献 各種ツールの活用例 ・パラメータ探索・経路シミュレーションによる評価 ・MDP parameterの抽出 ・各処理の実行関係整備、並列実行 シミュレーション結果 パラメータ推薦
- 45. 45 ▪ 複雑な構成をひとつの処理単位で回し切るのは厳しい ▪ 複数処理の連携を考えたい ⇨ Dockerの外側まで意識が広がる ▪ Kubeflow pipelineで、複数処理をつなげたパイプラインを構築 ▪ Kubernetesの恩恵を受けながら、便利な機能をいくつも持つ ▪ AI Platform Pipelineを使うと、使用のハードルもある程度下がる ▪ Kubeflow Pipeline + Optunaを活用したサービス例を紹介 ▪ 詳細はBlogに 中間まとめ[2] GCP managed Kubeflow Pipeline
- 46. 46 03 周辺ツール
- 47. 47 ▪ 処理基盤が整っても、それらを動かすのは人間 ▪ ときには、そこが面倒くささの大部分を占めてしまうことも ▪ 大量の実行引数設定 ▪ 結果の集計がカオス ▪ 複雑すぎるMakefile ▪ などなど なぜ周辺ツールの話？
- 48. 48 タスクランナー ▪ Invoke, Fabric (http://www.pyinvoke.org/) ▪ pythonでMakefileを定義できるようなツール ▪ fstringの使用など (shell scriptでもできるが、直感的) ▪ yamlを入力とすると、その内容が含まれたdictを自動的に持つ ＊別ツールだが、python-fireも似た感じで便利 tasks.py @taskデコレータをつけた関数がCLIから呼べる
- 49. 49 ▪ Hydra (https://github.com/facebookresearch/hydra) ▪ yamlと組み合わせて、argparseまわりをシンプルに書ける ▪ 実行ごとに自動でディレクトリを分けてくれる (好みが別れる) 実行引数まわりの整備 argparseは数が増えてくると視認性が悪い... コードも長くなる
- 51. 51 ▪ Kubeflow Fairing ▪ 同じことを別のバックで実施する際、実装をできるだけ共通化 お作法の隠蔽
- 52. ▪ waitしてから次の処理を実施すると、マージンが生じる ▪ 並列処理数を保ちながら連続的にジョブを投入したい際には、 GNU parallelを使うと便利 (https://www.gnu.org/software/parallel/) ▪ seq 1 1 10 | parallel --jobs 3 "sleep {}" みたいな感じで使える 52 複数ジョブの並列実行 6 5 4 2 3 4 wait
- 53. 53 ▪ 基本的には、重い処理を先に実行すると良いことが多い 複数ジョブの並列実行 10 8 9 7 6 5 4 3 2 1 10 8 9 7 6 5 4 3 2 1
- 54. 54 結果の集約、可視化 ▪ wandb, mlflow, comet-mlなどを活用し結果を集約 ▪ kubeflow pipelineを使っている場合は、そこに集めてもよい ▪ 指標をBigQueryを使用して集計したり多くの人が結果を利用する 場合などは、BigQueryやGoogle Spread Sheetに直接飛ばすことも
- 57. 57 ▪ papermill (https://github.com/nteract/papermill) ▪ 実行時引数を渡してnotebookの処理を切り替えることができる 結果の集約、可視化 https://qiita.com/MasafumiTsuyuki/items/7e8f7fd043243128450d
- 58. 58 単純機能の共通化について ▪ 実行引数以外に必要な入力が存在しない機能が幾つかある ▪ Slack通知やBigQueryを用いたSQLクエリの発行など ▪ 使い回しの効くDockerImageをGCRにpushしておくと管理が楽に ▪ Kubeflow Pipelineなどで使用する場合、イメージを参照するだけ ▪ 毎回冗長な実装をする必要がなくなる ▪ このあたりのentrypointを実装する際にも、invokeなどは便利
- 59. 59 ▪ 簡素に使いやすい処理体系を実装することは重要 ▪ 計算基盤が構築されたとしても、処理体系が複雑ならば手間は残る ▪ 便利と思うツールを紹介 ▪ タスクランナー ▪ 実行引数の管理 ▪ 可視化 ▪ などなど 中間まとめ[3]
- 60. 60 04 まとめ
- 61. 61 ▪ もろもろの効率化は重要 ▪ 実験的な試行錯誤から逃れることは難しい ▪ 実験効率化のいくつかの例を紹介 ▪ Google Cloud AI Platformの活用 ▪ AI Platform Training, Optimizer, Pipeline... ▪ 各種周辺ツールの利用 ▪ 煩わしい処理を減らすことに貪欲に まとめ
- 62. 62 EOF