イベントレポート | Microsoft Machine Learning Meetup 学習編 #dllab

はじめに

だんないよ、nikkieです。
dllabさんのイベント「Microsoft Machine Learning Meetup」
(マイクロソフトの機械学習系ソリューションを1日で知る日)のメモをブログとして公開します。
まずは「学習編」です。

勉強会の概要

Microsoft Machine Learning Meetup - connpass

5－6月は開発者にとって大変忙しかったですね！マイクロソフトもBuild と de:code という年1の開発者イベントを行いました。今回は、そこで発表されたものから機械学習系のソリューションを紹介します。Brainwave/FPGAやQuantumなども紹介したいですが、今回はスキップして、明日から使える、データ整備/蓄積・学習・推論を支えるAzureのプラットフォームをご紹介します。

学習編：Azure GPU クラスタ、Data Science VM、Batch AI、Low Priority VM
AzureではGPUやInfiniBandを搭載したハイスペックなインフラでディープラーニングを行うことできます。本セッションでは、GPUやInfiniBandを搭載したインフラの種類やパフォーマンスについてご説明します。さらに、それらを最大限活用できるソリューション群：環境構築済み仮想マシンのデータサイエンスVM、クラスター・深層学習のトレーニングジョブの実行を自動化するBatch AI、それらで使える低優先度仮想マシンをご紹介します。

データ前処理編、学習編、推論編と3部構成でした。
学習編の資料はこちらです。

Deep Learning Lab MeetUp 学習編 AzureインフラとBatch AI from 喜智大井

配信はこちらです: https://www.youtube.com/watch?v=f398XHjSX74

学習編 AzureインフラとBatch AI

学習のツール

Data Science 仮想マシン(DSVM)
VMSC(スケールセット) 100台立ち上げることも可能
Machine Learning ブラウザで機械学習
Batch AI: セッションのメイン

Azureはこれらのツールが簡単に使えるだけでなく、強力なインフラをもつ
どんなインフラがあり、どんなハイパフォーマンス¹なことができるのかという話

どうやったら性能が伸びるか <- 処理にかかるスピードの話

アムダールの法則: 処理を並列化するとどのくらい性能が伸びるか 1-p + p/n (並列化できるpの部分をn並列) スピードアップS
- 実際はオーバヘッドでp/nにはならない
並列化できない: 依存関係がある File I/Oなど
並列化できる: 依存関係なし <- DeepLearningでは並列化利用できる
100%にはならない(128並列で128倍にはならない。99%並列で60倍程度) pの領域をいかに増やすか(スピードアップのポイント)
スケーラビリティの観点ではpの領域をいかに増やすか
インフラの観点
- 並列化できる処理にGPUを用いる
- ノード間通信にInfiniband
- ストレージの最適化
高速ネットワーク(SR-IOV)
- 通常は仮想のネットワークスイッチをはさむ(性能のネックになる)
- スイッチをはさまないことでネットワークの高速化 17倍性能上昇
- ノード間通信も高速化できる
InfiniBand
- RDMA: 直接メモリにアクセスする通信 216倍の性能上昇
- 仮想マシンHシリーズ(Rがついたもの) 512コアでも性能劣化しない(100%の直線に近い)
- High Performance Linpack(HPL): ベンチマーク
GPU インスタンス
- NVIDIA: Kepler(K80), Maxwell(M60), Pascal(P100), Volta(V100)
- 仮想化したマシンの上で性能が出るのが強み
- ChainerMN GPU増やしても(並列増やしても)性能が劣化しない(100%の直線に近い線)
- DeepLearningはNCシリーズ、NVシリーズ NVシリーズは東日本(ドキュメントは可視化用途だが、単精度²のDeepLearningは可能) InfiniBandは使っていない
VOLTA TENSORコア
TENSORコア
- 行列の積和演算を一気に行える D = AB + C
- ディープラーニングの性能向上(早くなる)

Azure Batch AI

手元でディープラーニングのテストをするとき、仮想マシンで十分
大量データがあるとき、複数の仮想マシンを設定するのは手間
-> Batch AIによる簡略化

メリット

クラスタをすぐ展開できる
クラスタのオートスケールジョブ開始に反応してノード数を増やし、ジョブ終了でノード数を0に
低優先度仮想マシン: 80%割引で仮想マシン(GPU)が使える (Batch AIとスケールセットからのみ割引が使える)
コンテナ利用、展開早い

キーワード(1週間前にAPI変更)

リソースの管理の単位はリソースグループ
ワークスペース(Batch AIで一番大きい単位。プロジェクト単位)
ワークスペースのオブジェクトとしてクラスタ、NFS
エクスペリメント: ジョブの集合体。ジョブを入れて管理する箱

ステップ

Quotaの確保: Portalから引き上げ依頼(ノード数の上限が決まっている)
リソースグループ、ワークスペース、Experimentを作成
ストレージの作成(ここがポイント)
- GPUについて速度は変わらない。ストレージの選択で性能が変わる
  - Azure Files: ファイルサーバのPaaS。マウントをして使う。Portalから簡単に作れるが、I/Oやスループットに厳しい条件がある
  - Blob Fuse: Blobストレージ(オブジェクトストレージ。HTTPアクセス。画像やPDFを置く。管理の単位はコンテナ)をLinuxマシンからマウント。おすすめ
  - Single Node NFS: Fuseが使えなければ、仮想で立てる
- Blob Fuseが早い理由
  - 元データはBlobのコンテナにある。ファイルオープンでローカルキャッシュに落とす。書き込みをし、ファイルクローズではじめてストレージ側に反映する。
  - = 直接Azureのストレージに書き込まず、ローカルに差分を用意し、閉じるときにストレージに書き込むということ
  - 他方、Azure Filesは排他制御ができる。そのため遅い
Dockerイメージ／OSイメージ
- 1週間前のAPI変更まではDockerおすすめ DSVMではバージョン管理ができない
- 変更によりOSのカスタムイメージが作れるようになった
- Dockerイメージの保管場所: Docker HubはVMからは遠い。Azure Container Registry(従量課金) 1秒を縮めるのに使う
クラスタの作成(同じサイズの仮想マシンの集合体。GPUや低優先度仮想マシン一部だけ混ぜることはできない)
- オートスケールには10分程度ラグがある。学習時間がシビアであれば、手動でスケールする(消し忘れると課金発生)
Job(JSONファイル)

参考情報

Key Vault: パスワードの管理の利用
- 本番プロダクトでのKey(パスワード)の管理では検討を
Batch AIのチュートリアルはGitHubの方が充実。フレームワークごとのExampleあり

まとめ

AzureはGPUの取り揃え、パブリッククラウドでは1位と思われるとのこと: GPUについて幅広い選択肢
Infiniband
Batch AIはいかに簡単にディープラーニングを行うか

ハンズオン

Batch AIでMNISTに取り組みました。
ハンズオン資料はこちらです。
https://github.com/DLL-BatchAI-Hand-on/Chainer/blob/master/Chainer-GPU-Distributed/cli-instructions.md

ハンズオン資料に沿ってCloud Shellで以下のコマンドを実行していきました。

ワーキングディレクトリ変更
- cd /usr/$USER/clouddrive
batchai.recipesリソースグループを作成
- az group create -n batchai.recipes -l eastus
- リソースグループはメタ情報を管理する箱。管理されるリソースはどのリージョンにあってもいい
- リソースグループはどこでもいいが、ワークスペースの場所は性能にとって重要(通信にかかる時間)
BatchAI ワークスペースを作成
- az batchai workspace create -g batchai.recipes -n recipe_workspace -l eastus
GPUクラスタ作成(低優先度仮想マシン指定)
- az batchai cluster create -n nc6 -g batchai.recipes -w recipe_workspace -s Standard_NC6 -t 2 --generate-ssh-keys
  - -tでつくるノード数
  - --generate-ssh-keys sshキーをストレージに保管
- エラーが出た場合
  - バッチで検索 -> クオータの確認
- 低優先度仮想マシンだと費用を抑えられるということだったので、指定しました(オプションに気づかずリソースグループごと消して作り直しました)
- 仮想マシンが起動している間(アイドル状態も含む)は課金される
ストレージアカウント作成(nikkie20180627dllabとして作成³)
- az storage account create -n nikkie20180627dllab --sku Standard_LRS -g batchai.recipes -l eastus
- ストレージアカウント名は全世界で一意にする必要がある(小文字と数字のみ、大文字や記号は使えない)
- ストレージはクラスタと同じリージョンにつくる(Azureのデータセンターの構成はリージョンに閉じている)
- ストレージはVMとは別で課金される永続的なもの
学習スクリプトの取得
- wget https://raw.githubusercontent.com/chainer/chainermn/v1.3.0/examples/mnist/train_mnist.py
Blobコンテナ作成、学習スクリプトデプロイ
- az storage container create -n scripts --account-name nikkie20180627dllab
- az storage container create -n data --account-name nikkie20180627dllab
- az storage blob upload -f train_mnist.py -n chainer/train_mnist.py --account-name nikkie20180627dllab --container scripts
  - -> scriptsとdataはコンテナの名前の指定(この後、job.jsonで指定する)
- BlobストレージはオブジェクトがURLをもつ
- URL中に/の区切りを入れることでディレクトリのようになる
- Azure Filesはログの吐き場所としてのみ利用する
  - az storage share create -n logs --account-name nikkie20180627dllab
Experiment作成
- az batchai experiment create -g batchai.recipes -w recipe_workspace -n chainer_experiment
job.json書き換え
- 取得: wget -O job.json https://raw.githubusercontent.com/DLL-BatchAI-Hand-on/Chainer/master/Chainer-GPU-Distributed/job.json
- <AZURE_BATCHAI_STORAGE_ACCOUNT>と<Storage Account Name>: ストレージアカウント名(nikkie20180627dllab)にする
- <Container Name (For Script)>: scripts(先のaz storage account create -nコマンド)
- <Container Name (For Data)>: data(先のaz storage account create -nコマンド)
- <Storage Account Key>: 以下のコマンドの結果参照
  - az storage account keys list -g batchai.recipes --account-name nikkie20180627dllab
Jobの実行
- az batchai job create -n distributed_chainer -c nc6 -g batchai.recipes -w recipe_workspace -e chainer_experiment -f job.json --storage-account-name nikkie20180627dllab
実行中のJobの監視（ブログ末尾参照）
- az batchai job file stream -j distributed_chainer -g batchai.recipes -w recipe_workspace -e chainer_experiment -f stdout.txt
モデルの確認
- az batchai job file list -j distributed_chainer -g batchai.recipes -w recipe_workspace -e chainer_experiment -g batchai.recipes -d MODEL
- または az batchai job show -n distributed_chainer -g batchai.recipes -w recipe_workspace -e chainer_experiment --query jobOutputDirectoryPathSegment

参考情報

おまけ: Batch AIの裏のVMにSSHする
- 完全なブラックボックスではなく、中にはいって確認できる
- Cloud ShellからVMにSSHしてdocker execすればいい
Keplerは空いているので低優先度で使いたい放題とのこと

感想

Azureの売り（強力なインフラ、GPU インスタンスの充実）の話が聞けたのが、一番ありがたかったです。
Cloud Shellからリソースつくると管理がラクな印象です。積極的に使っていこう
BatchAIから使う低優先度仮想マシン、今後kaggleのコンペに取り組む際に選択肢に上るかもしれません。
ハンズオン込みの充実したセッションをどうもありがとうございました。

参考: 実行中のJobの監視の様子

==========================================
Num process (COMM_WORLD): 2
Using GPUs
Using hierarchical communicator
Num unit: 1000
Num Minibatch-size: 100
Num epoch: 20
==========================================
Downloading from http://yann.lecun.com/exdb/mnist/train-images-idx3-ubyte.gz...
Downloading from http://yann.lecun.com/exdb/mnist/train-labels-idx1-ubyte.gz...
Downloading from http://yann.lecun.com/exdb/mnist/t10k-images-idx3-ubyte.gz...
Downloading from http://yann.lecun.com/exdb/mnist/t10k-labels-idx1-ubyte.gz...
epoch       main/loss   validation/main/loss  main/accuracy  validation/main/accuracy  elapsed_time
1           0.22513     0.107383              0.933267       0.9664
   18.5095
2           0.0754279   0.0671796             0.9765         0.9774
   30.0267
3           0.0478487   0.0705339             0.984834       0.9778
   40.7548
4           0.0314334   0.0904751             0.9896         0.9764
   51.4043
5           0.0229979   0.0666332             0.992967       0.9813
   62.6438
 : <省略>
16          0.00927721  0.0899814             0.997167       0.9825
   182.325
17          0.00889213  0.0872269             0.9973         0.9819
   192.866
18          0.00727136  0.0930194             0.9975         0.9821
   202.713
19          0.00774408  0.1048                0.997367       0.9819
   212.526
20          0.0097215   0.11702               0.9973         0.977
   222.365