この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
最初に
こんにちはデータアナリティクス事業本部のyoshimです。
re:Invent2019にて行われた「AWS infrastructure for large-scale distributed training at Facebook AI」という「Session」の内容についてご紹介します。
動画はyoutubeから確認できます。
概要
本セッションの概要は下記の通りです。
In this session, the Facebook AI team discusses its major machine learning models and workloads and the infrastructure challenges it faced with large-scale distributed training. They share details of how they tested these ML workloads on AWS infrastructure and the results of this benchmarking. Then we discuss how the deep breadth of AWS infrastructure for ML workloads in compute, networking, and storage helps address large-scale ML challenges. Specifically, we dive deep into the AWS machine learning stack to choose the right Amazon EC2 platform to fit your ML workload while leveraging 100 Gbps networking and high-performance file systems to efficiently scale from a single GPU to hundreds or thousands.
Google翻訳したものも載せておきます。
このセッションでは、Facebook AIチームが主要な機械学習モデルとワークロード、および大規模な分散トレーニングで直面するインフラストラクチャの課題について説明します。彼らは、AWSインフラストラクチャでこれらのMLワークロードをテストした方法の詳細と、このベンチマークの結果を共有しています。次に、コンピューティング、ネットワーク、およびストレージのMLワークロード向けのAWSインフラストラクチャの広範な機能が、大規模なMLの課題にどのように対処するかについて説明します。具体的には、AWS機械学習スタックを深く掘り下げて、MLのワークロードに適した適切なAmazon EC2プラットフォームを選択し、100 Gbpsネットワーキングと高性能ファイルシステムを活用して、単一のGPUから数百または数千に効率的に拡張します。
「AWSを使った機械学習のための大規模な分散学習基盤」というものを実現するにあたっての技術スタックについて非常に参考になるセッションでした。前半はFacebookの大規模分散システムについて、後半はAWS上で大規模分散機械学習基盤を作る上での参考情報、といった形の報告です。
「AWS上での大規模分散システムについて興味がある」、といった方にオススメです。
目次
1.アジェンダ
- Session overiew
- Facebook ML workloads & challenges
- AWS Elastic Compute Cloud(Amazon EC2) portfolio for ML
- AWS networking infrastracture
- AWS storage infrastracture
- AWS ML inference
2.内容
Session overiew
最初は本セッションの概要からです。
まず、近年流行している「Deep Learning」はあくまでも「Machine Learning」のうちの一手法であり、「Deep Learning ≠ AI」ということについて言及し、
また、「Deep Learning」という単語は「AlexNet」の登場以降、「この手法は他の分野でも適用できるのでは」という考えから、論文によく出てくるようになったことや、
「Deep Learning」は「データ量やモデルの複雑さ」が上がると精度が上がる特徴がある、といった点に言及していました。(データ量が少なかったり、パラメータ数が少なくてモデルの複雑さが低いうちは、既存手法に負けることもある)
しかしながら、「データ量やモデルの複雑さが上がる」ということは、「コンピューティングリソースの負荷が大きくなる」といった問題にも繋がってしまいます...。
ここまでは、まずDeepLearningに関する一般的な部分の話でした。
Facebook ML workloads & challenges
続いて、Facebookの内部に関する報告に移ります。
近年はFacebookでも機械学習の利用が増えているそうです。
2018年には「Facebookがデータウェアハウスに管理しているデータ量のうちの30％」がMLに利用されていましたが、2019年には50％にまで増えました。
更に、データウェアハウスに格納するデータ量自体も倍増したため、エンジニアの数やモデルの学習のワークロード、利用するコンピュートリソース量がそれぞれ2〜3倍程度にまで増えたそうです。
MLの利用が拡大しているため、「ストレージ」、「ネットワーク」、「コンピューティングやメモリ」等のパフォーマンス向上や柔軟性を得る必要がある、と課題提議がなされました。
また、Facebookにおいては「ランキング学習、レコメンド」、「画像分類、物体検出、動画認識」、「翻訳、音声認識、コンテンツ認識」等の様々なMLワークロードが実行されているそうなのですが、
その中でも「ランキング学習」や「レコメンド」は特にリソースを割かれており、その重要性が伺えます。
また、Facebookにおけるワークロード中のリソース消費量についての棒グラフも紹介されました。
一番リソースを消費しているのは「全結合層の行列乗算」なのですが、それに畳み込み層のリソース消費量を足してもまだ「消費リソース量の過半数」にも達しません。
以上のことから、「消費リソース量やハードの見直しをする際に、ここにばかり注目していてはいけない」と言及していました。
また、「レコメンド」、「画像認識」、「自然言語」系のタスクそれぞれで、どれくらいコンピューティングリソースを使うか、といった点も整理していました。
レコメンドは「他のモデルと比較してもとにかくメモリをたくさん使いがちであり、メモリ以外においても平均的に他のモデルよりもリソースを消費しがち」、画像や動画を扱うタスクについては、「Inputデータがでかいためにメモリの利用量が大きくなりがちであり、かつコンピューティングリソースも大量に必要」、自然言語は「全般的に高いスペックが求められる」とのことでした。
また、ここで「開発者やリサーチャーに速さと柔軟性の両方を実現するインフラを提供することが大事」と述べていました。
続いて、具体的なインフラの話に移ります。
大規模な分散システムを検討する上では、「インスタンス間の通信」が重要となります。
Facebookでは、P3dnインスタンスと「Elastic Network Adapter」、「Elastic Fabric Adapter」等を使って検証をしていました。
というのも、今後グラフ系アルゴリズムの利用も検討しており、その際は「インスタンス間の通信」が今以上に重要となると考えているためだそうです。
AWS Elastic Compute Cloud(Amazon EC2) portfolio for ML
登壇者が変わり、ここからはAWSにおける全般的な話になりました。
まず、機械学習タスクに対するEC2インスタンスの話からです。
モデルの学習時には「P3、P3dn」系インスタンスが「スペックが高いのでモデルの学習中の待機時間が減る（インスタンスのコストよりも人の待機時間のコストの方が高い）からオススメ」、また「比較的小規模なタスク（大きなメモリが不要、サーバー間通信もそこまで強くなくていい）の学習にはG4インスタンスも費用対効果がいいのでオススメ」とのことです。
また、推論については「機械学習の全ワークロードの費用のうち90％が推論で消費される」とのことで、どのようなインスタンスを使うかはかなり重要です。
「G4インスタンス」は「推論時の費用対効果を上げる」ことを念頭に開発されたものであり、既存のP2インスタンスと比較すると「高いパフォーマンス、低いレイテンシー、低い料金」を実現できます。
また、「inf1インスタンス」も推論に特化したインスタンスであり、低いレイテンシーやコストの低減を実現できます。
AWS networking infrastracture
また、大規模な学習をするにあたっては、ネットワーク面もしっかり検討しなくてはなりません。
なぜなら分散学習をさせている場合は、「データ量が大きければ大きいほどデータ転送がボトルネックになりやすいから」です。
下記はP3dnインスタンスで分散学習をさせた際のパフォーマンス比較の検証結果です。
二つの棒グラフはそれぞれ複数のP3dnインスタンスを使って分散学習をさせた際の学習にかかった時間ですが、青い棒グラフは「TCP」、黄色い棒グラフは2019年4月にGAとなった「Elastic Fabric Adapter」を使っています。
見てわかる通り、いずれも処理が大規模になっても処理時間がちゃんと低減されているのですが、黄色い棒グラフの方が処理時間が短くなっていることが確認できます。
「Elastic Fabric Adapter」は高度なEC2インスタンス間の通信を要するアプリケーションのために提供されているEC2インスタンスのネットワークインターフェイスです。
そのため、HPC（ハイパフォーマンスコンピューティング）なアプリケーションや機械学習等に利用でき、上記のような大規模な分散学習をさせる際は効果を発揮します。
AWS storage infrastracture
学習を始める前にデータをLOADする、といった点がボトルネックにならないようにストレージについても一工夫することが可能です。
大規模なMLワークフローを実現するためには、EBSやEFSでは十分ではないかもしれないからです。
「Amazon FSx for Lustre」は、「機械学習やハイパフォーマンスコンピューティング (HPC)なワークロードの高速処理に最適化されたハイパフォーマンスファイルシステム」です。「フルマネージドサービスなので管理が楽」であり、「操作もシンプル」、「S3バケットとも連携している」といった特徴があります。
こちらは大規模なMLクラスターの構成例です。
要点としては下記の通りです。
- S3にソースデータを格納し、「Amazon FSx for Lustre」を並列ファイルシステムとして利用する。
- インスタンスはクラスタープレイスメントグループでまとめる
- 「Elastic Fabric Adapter」を使ってEC2インスタンス間通信のパフォーマンスを上げる
- インスタンスはP3/P3dnインスタンスを利用
- これらのインスタンスを「AWS Batch」、「ECS」、「EKS」等を使って管理する
AWS ML inference
最後に推論についてです。
G4インスタンスは推論向けに作られていることもあり、基本的にオススメできるインスタンスタイプです。
ただ、Inf1インスタンスはG4と比較すると3倍のスループット、推論処理あたりのコスト40％低減、といったメリットがあるため、推論ワークロード内に「CUDA」、「TensorRT」、「その他いくつかのNvidia製ライブラリ」に強い依存関係が無いようなら「Inf1」インスタンスがオススメ、とのことでした。
さはさりながら、G4インスタンスも機械学習の推論に適したインスタンスタイプであり、GPU数やvCPU数等の選択肢が多いため、各アプリケーションのワークロードにぴったりのインスタンスサイズを指定することが可能です。
3.まとめ
大規模な分散学習基盤を実現するために、「インスタンス間の通信」の重要性をヒシヒシと感じることができました。
機械学習に携わっているとこういった面は見落としがちですが、イノベーションのスピードを上げていくためには避けては通れない道なのだと実感します。
3
