はじめに： 人工知能は近年非常にホットなテクノロジー分野であり、この分野の急速な進化を促進する原動力には、NVIDIA GPUに代表される異種コンピューティング能力、TensorFlowとPytorchに代表される機械学習フレームワーク、および大量のデータセットが含まれます。。さらに、KubernetesとDockerに代表されるコンテナ化されたインフラストラクチャもデータサイエンティストの最初の選択肢になっているという傾向も発見しました。標準化と規模の2つの主な要因があります。たとえば、PytorchのソフトウェアリリースプロセスであるTensorFlowには、主にコンテナの標準化された特性に依存するコンテナバージョンを含める必要があります。一方、Kubernetesをベースにしたクラスタースケジューリング技術により、大規模な分散トレーニングが可能になります。

頭のpicture.png

著者|
Che Yang
AlibabaCloudシニアテクニカルエキスパートFanBin Alluxio創設メンバー、オープンソースコミュニティ
ソース担当副社長| AlibabaCloudネイティブ公式アカウント

クラウドでディープラーニングを加速する理由

人工知能は近年非常にホットなテクノロジー分野であり、この分野の急速な進化を促進する原動力には、NVIDIA GPUに代表される異種コンピューティング能力、TensorFlowとPytorchに代表される機械学習フレームワーク、および大規模なデータセットが含まれます。さらに、KubernetesとDockerに代表されるコンテナ化されたインフラストラクチャもデータサイエンティストの最初の選択肢になっているという傾向も発見しました。標準化と規模の2つの主な要因があります。たとえば、PytorchのソフトウェアリリースプロセスであるTensorFlowには、主にコンテナの標準化された特性に依存するコンテナバージョンを含める必要があります。一方、Kubernetesをベースにしたクラスタースケジューリング技術により、大規模な分散トレーニングが可能になります。

バックグラウンド

まず、下の図を観察します。これは、シミュレーションデータの下での深層学習モデルのトレーニング速度です。いわゆるシミュレーションデータは、このテストでIOの影響がないことを意味します。この図から、2つの結果を得ることができます。

GPUハードウェアアップグレードの加速効果は重要です。1枚のカードの計算能力の観点から、pascalアーキテクチャで表されるP100は1秒あたり300枚の画像しか処理できませんが、voltaアーキテクチャのv100は1秒あたり1200枚の画像を処理できます。これは4倍の増加です。
分散トレーニングは、加速するための効果的な方法でもあります。シングルカードP100から分散32カードv100まで、トレーニング速度が300倍に向上したことがわかります。

1.シミュレーションデータのトレーニング速度

トレーニング時間の観点から、同じデータと同じトレーニング目標で、1枚のカードP100は108時間4日半を必要とします。V100の32枚のカード分散トレーニングは1時間しかかかりません。コストの観点から、1枚のカードP100のコストは1,400元に近く、8枚のカードV 100は600元で、半分以下です。

更新されたGPUハードウェアは、より効率的であるだけでなく、実際にコストを節約できることがわかります。これは、Huang Jiaozhuが、購入すればするほど節約できると言ったことかもしれません。クラウドリソースの観点からは、それは理にかなっています。

2.シミュレーションデータのトレーニング時間

ただし、以前のテスト結果では、実際にはいくつかの仮定が行われていました。つまり、データ遅延の影響はありません。実際の状況では、モデルトレーニングは大量のデータへのアクセスと切り離せません。実際には：

強力なコンピューティング能力には、一致するデータアクセス機能が必要です。レイテンシーであろうとスループットであろうと、より高い要件が提唱されています。次の図に示すように、クラウドディスクデータの読み取りの場合、GPUトレーニング速度は元の速度の3分の1に直接低下します。GPUの使用率も高いです。
クラウド環境では、コンピューティングとストレージが分離された後、データのローカリゼーションがなくなると、I / Oの影響が大幅に悪化します。
現時点で、たとえばossutilがデータをGPUマシンにコピーする場合など、データをコンピューティングノードに直接ロードできる場合、コンピューティングのニーズを満たすことができますか？実際、データセットを完全に制御することはできませんが、AIシナリオでは完全なデータセットであるため、まだ十分ではありません。エビクションメカニズムが導入されると、パフォーマンスが向上します。影響は実際には非常に重要です。そのため、K8で分散キャッシュを使用することの重要性を認識しました。

Alluxioとは

Alluxioは、AIおよびビッグデータアプリケーション向けのオープンソースの分散メモリレベルのデータオーケストレーションシステムです。多くのシナリオで、Alluxioはこれらのアプリケーションを高速化する分散キャッシュとして非常に適しています。このプロジェクトは、カリフォルニア大学バークレー校のAMPLabで博士号を取得するために勉強していたHaoyuanLi博士によって設立されました。最初の名前はTachyonでした。AMPLabは、SparkやMesosなどの優れたオープンソースプロジェクトをインキュベートしてきた功績のあるラボでもあります。2015年、トップベンチャーキャピタルのアンドリーセンホロウィッツが投資し、Alluxioプロジェクトの主な貢献者は、サンフランシスコベイエリアにAlluxioを設立しました。

1.Alluxio-分散キャッシングのリーダー

2.Alluxioの紹介

AlluxioがビッグデータとAIエコシステムのどこにあるかを簡単に見てみましょう。ビッグデータソフトウェアスタックでは、Alluxioは新しいレイヤーであり、データオーケストレーションレイヤーと呼ばれます。Spark、Presto、Hive、Tensorflowなどのコンピューティングアプリケーションと上向きにドッキングし、AlibabaのOSSやHDFSなどのさまざまなストレージと下向きにドッキングします。この新しく追加されたデータオーケストレーションレイヤーを通じて、コンピューティングとストレージの間の強い関連性を切り離すことができることを願っています。そのため、コンピューティングとストレージの両方を独立して、より機敏に展開および進化させることができます。データアプリケーションは、データストレージの特定のタイプ、プロトコル、バージョン、地理的な場所などを気にし、維持する必要はありません。データのストレージは、データオーケストレーションレイヤーを介して、さまざまなアプリケーションでより柔軟かつ効率的に使用することもできます。

3.Alluxioのコア機能

1）分散データキャッシュ

Alluxioのコア機能を紹介しましょう。Alluxioのコアサービスは、データアプリケーションを高速化するための分散データキャッシュを提供することです。Spark、Presto、Tensorflowなどのデータ集約型アプリケーションの場合、非ローカルデータソースを読み取るときに、Alluxioは元のデータファイルを読み込み、シャーディングして分割し、アプリケーションに近いAlluxioサーバーに保存して拡張することができます。これらのアプリケーションのデータの局所性。

たとえば、この例では、ファイル1とファイル2がフラグメント化され、異なるAlluxioサーバーに保存され、アプリケーションは、対応するデータフラグメントを保存する最も近いサーバーからそれらを読み取ることができます。アプリケーションに必要な読み込みに明らかなホットデータがある場合、キャッシュレイヤーを追加すると、リソースを大幅に節約し、効率を向上させることができます。

2）柔軟で多様なデータアクセスAPI

Alluxioの2番目のコアアプリケーションは、ビッグデータの分野で最も一般的なHDFSインターフェイス、AIおよびモデルトレーニングシナリオで一般的に使用されるPOSIX標準ファイルシステムインターフェイスなど、アプリケーションにさまざまなタイプのデータインターフェイスを提供することです。

このようにして、同じデータが準備されると、複数の処理やETLの代わりに、異なる形式でアプリケーションに提示できます。

3）統一されたファイルシステムの抽象化

Alluxioの3番目のコア機能は、ユーザーに対して透過的な方法で、複数の異なるストレージシステムをファイルシステムの抽象化に統合することです。これにより、複雑なデータプラットフォームがシンプルになり、保守が容易になります。データコンシューマーは、データに対応する論理アドレスを知っているだけでよく、最下層が接続されているときにストレージシステムを気にする必要はありません。

たとえば、企業が同時に複数の異なるHDFSデプロイメントを持ち、AlibabaのOSSサービスにオンラインでアクセスする場合、Alluxioのマウント機能を使用して、これらのシステムを統合された論理Alluxioファイルシステム抽象化に接続できます。各HDFSは、異なるAlluxioディレクトリに対応します。

クラウドAIトレーニングシナリオにおけるAlluxioのパフォーマンス上の利点

Alluxioのコア機能を紹介した後、クラウドAIトレーニングシナリオに焦点を当て、Alluxioの考えられるメリットを確認しましょう。モデルトレーニングシナリオでは、メモリアクセラレーションはGPUに必要な高スループットを満たすことができます。オブジェクトストアから通常のネットワークを介してデータを転送する場合、約300MB /秒をサポートできます。これは、トレーニングリソース、特にGPUの高スループット特性を十分に活用するにはほど遠いものです。ただし、Alluxioを使用して分散データキャッシュのレイヤーを構築すると、トレーニングを担当するコンテナープロセスとAlluxioワーカーコンテナープロセスが非常に高速でデータを交換できるようになります。たとえば、2つが同じ物理ホスト上にある場合、1秒あたり1〜6GBに達する可能性があります。他のalluxioworkerからの読み取りは、通常1〜2GB /秒に達する可能性があります。

さらに、Alluxioは、キャッシュ置換戦略の設定、データの有効期限の設定、特定のディレクトリ内のデータの先読みまたは排出など、非常にシンプルで便利な分散キャッシュ管理を実現できます。これらは、モデルトレーニングに効率の向上と管理の利便性をもたらすことができます。

KubernetesでのAlluxioのアーキテクチャ

AlluxioをKubernetesでネイティブに使用するには、最初にK8sにデプロイする必要があります。したがって、最初のステップは、ユーザーID、パラメーター、階層キャッシュ構成を一律に構成できるAlluxioチームをHelmchartに提供することです。

左の図から、Alluxioのマスターはステートフルセットモードで展開されています。これは、Alluxiomasterが最初に安定している必要があり、ディザスタリカバリなどの複雑なシナリオに対応できる一意のネットワークIDを持っているためです。ワーカーとFuseはデーモンセットモードでデプロイされ、データアフィニティを使用できるように、2つはpodaffinityによってバインドされます。

KubeNode-救済オペレーター

アプリケーションがヘルドされた後、それをデプロイすることは非常に簡単なことです。cong.yamlを記述し、helminstallを実行するだけで、ワンクリックでAlluxioをKubernetesにデプロイできます。興味がある場合は、alluxioのドキュメントを確認するか、Alibaba Cloud ContainerServiceのドキュメントから学ぶことができます。

Alluxioは、AIモデルトレーニングシナリオの課題をサポートします

パフォーマンス評価では、GPUハードウェアをNVidiaP100からNVidiaV100にアップグレードすると、1枚のカードの計算速度とトレーニング速度が3倍以上向上することがわかりました。コンピューティングパフォーマンスの大幅な向上は、データストレージアクセスのパフォーマンスに圧力をかけます。これはまた、AlluxioのI / Oに新たな課題をもたらします。

次の図は、合成データとAlluxioキャッシュのパフォーマンスの比較を示しています。横軸はGPUの数を表し、縦軸は1秒あたりに処理される画像の数を表します。合成データとは、トレーニングプログラムによって読み取られるデータがプログラム自体によって生成され、I / Oオーバーヘッドがなく、モデルトレーニングパフォーマンスの理論上の上限を表すことを意味します。Alluxioキャッシュを使用すると、トレーニングプログラムによって読み取られるデータが取得されます。 Alluxioシステムから。GPUの数が1と2の場合、Alluxioと合成データの比較を使用すると、パフォーマンスのギャップは許容範囲内にあります。しかし、GPUの数が4に増えると、2つの間のギャップがより明白になります。Alluxioの処理速度は4981画像/秒から3762画像/秒に低下しました。GPUの数が8に達すると、Alluxioでのモデルトレーニングのパフォーマンスは合成データの30％未満になります。現時点では、システムモニタリングを通じて、システム全体のコンピューティング、メモリ、およびネットワークがボトルネックに達するにはほど遠いことがわかりました。これは、Alluxioを使用するだけでは、V100スタンドアロン8カードトレーニングシナリオを効率的にサポートすることが難しいことを間接的に示しています。

チューニング戦略

1.メタデータをキャッシュしてgRPCの相互作用を減らします

Alluxioは単なるキャッシュサービスではありません。これは、完全なメタデータ管理、ブロックデータ管理、UFS管理（UFSは基盤となるファイルシステムの略）、ヘルスチェックメカニズムを含む分散仮想ファイルシステムであり、特にそのメタデータ管理の実装は、多くの基盤となるファイルシステムよりも優れています。これらの機能はAlluxioの利点と特徴ですが、分散システムを使用するオーバーヘッドも意味します。たとえば、Alluxioクライアントを使用してデフォルト設定でファイルを読み取ると、データがローカルのAlluxioワーカーにキャッシュされている場合でも、クライアントはマスターノードと複数のRPC対話を行い、ファイルのメタ情報を取得してデータの整合性を確保します。。従来のビッグデータシナリオでは、読み取り操作全体を完了するためのリンクオーバーヘッドは明らかではありませんが、学習シナリオでの深遠な高スループットと低遅延の要件は拡大しているように見えます。したがって、クライアント側のメタデータキャッシュ機能を提供する必要があります。

2.Alluxioキャッシュの動作制御

ディープラーニングのトレーニングシナリオでは、各トレーニングの反復は完全なデータセットの反復であるため、数テラバイトのデータセットをキャッシュするには、1つのノードのストレージスペースには短すぎます。また、Alluxioのデフォルトのキャッシュ戦略は、ビッグデータ処理シナリオ（クエリなど）でのホットデータとコールドデータの明確なニーズに合わせて設計されています。データキャッシュは、Alluxioクライアントが配置されているローカルノードに保存され、次の記事を読んでください。具体的には：

alluxio.user.ufs.block.read.location.policyのデフォルト値はalluxio.client.block.policy.LocalFirstPolicyです。これは、AlluxioがAlluxioクライアントが配置されているローカルノードにデータを保存し続けることを意味します。キャッシュされたデータを近づける飽和状態になると、ノードのキャッシュはジッター状態になり、スループットと遅延が大幅に低下し、マスターノードへの圧力も非常に高くなります。したがって、location.policyをalluxio.client.block.policy.LocalFirstAvoidEvictionPolicyに設定し、alluxio.user.block.avoid.eviction.policy.reserved.size.bytesパラメーターを指定する必要があります。このパラメーターは、ローカルノード。特定のレベルに達した後、ローカルキャッシュが削除されないように、ある程度のデータを予約します。通常、このパラメーターは、ノードキャッシュ制限X（100％-ノードエビクション制限のパーセンテージ）よりも大きくする必要があります。
alluxio.user.file.passive.cache.enabled追加のデータコピーをAlluxiのローカルノードにキャッシュするかどうかを設定します。このプロパティはデフォルトでオンになっています。したがって、Alluxioクライアントがデータを要求すると、そのノードは他のワーカーノードにすでに存在するデータをキャッシュします。この属性をfalseに設定すると、不要なローカルキャッシュを回避できます。
alluxio.user.file.readtype.defaultデフォルト値はCACHE_PROMOTEです。この構成には2つの潜在的な問題があります。1つは、同じノード上の異なるキャッシュレベル間でデータが移動する可能性があることです。2つ目は、データブロックのほとんどの操作をロックする必要がある一方で、Alluxioソースコードの操作をロックすることです。重量があり、多数のロックおよびロック解除操作は、同時実行性が高い場合に多くのオーバーヘッドをもたらします。データが移行されていない場合でも、追加のオーバーヘッドが発生します。したがって、これをCACHEに設定して、moveBlock操作によって引き起こされるロックオーバーヘッドを回避し、デフォルトのCACHE_PROMOTEを置き換えることができます。

3.ヒューズのパフォーマンスチューニング

1）FUSEメタデータの有効時間を延長する

Linuxの中の各開いているファイルには、メタデータ情報の2種類があり、カーネルで：struct dentryそしてstruct inode彼らは、カーネル内のファイルに基づいています。ファイルに対するすべての操作では、最初にファイルの2つの構造を取得する必要があります。したがって、ファイル/ディレクトリのiノードとdentryが取得されるたびに、FUSEカーネルモジュールはlibfuseとAlluxioファイルシステムから完全な操作を実行します。これにより、データアクセスの高遅延と高同時実行性の下でAlluxioマスターに大きなプレッシャーがかかります。。–o entry_timeout=T –o attr_timeout=T最適化するように構成できます。

2）構成は`max_idle_threads`、頻繁なスレッド作成を回避し、CPUオーバーヘッドの導入を破壊します

これは、FUSEがマルチスレッドモードで1つのスレッドで実行を開始するためです。使用可能なリクエストが3つ以上ある場合、FUSEは自動的に他のスレッドを生成します。各スレッドは一度に1つのリクエストを処理します。リクエストを処理した後、各スレッドはmax_idle_threads（デフォルトでは10）を超えるスレッドがあるかどうかを確認します。ある場合は、スレッドがリサイクルされます。この構成は、実際にはユーザープロセスによって生成されたアクティブなI / Oの数に関連しており、ユーザー読み取りスレッドの数として構成できます。残念ながら、 max_idle_threadsそれ自体はlibfuse3のみをサポートしていますが、AlluxioFUSEはlibfuse2のみをサポートしているため、libfuse2がmax_idle_threads構成をサポートするようにコードを変更しました。

総括する

Alluxioを最適化した後、ResNet50シングルマシン8カードパフォーマンスのトレーニングパフォーマンスが236.1％向上し、スケーラビリティの問題が解決されました。トレーニング速度を4マシン8カードに拡張できるだけでなく、パフォーマンスも向上できます。このシナリオの合成データと比較した損失は3.29％です（31068.8画像/秒対30044.8画像/秒）。SSDクラウドディスクにデータを保存する場合と比較して、4台のマシンと8枚のカードのシナリオではAlluxioのパフォーマンスが70.1％向上します（クラウドSSD17667.2イメージ/秒対30044.8イメージ/秒）。

エンドツーエンドの最適化ソリューション

Alluxioを介してKubernetesでディープラーニングを加速することに興味がある場合は、QRコードをスキャンして中国のコミュニティに参加してください。シナリオと問題について一緒に話し合いましょう。

著者について

ファン・ビン、Alluxioの創立メンバーは、一度グーグルで働いていた、初期の頃にAlluxioのアーキテクチャ設計を担当した、と今Alluxioオープンソースコミュニティの操作に焦点を当てています。

Che Yangは、Alibaba Cloudコンテナサービスチームで働いており、クラウドネイティブテクノロジーとAIおよびビッグデータシナリオの組み合わせに焦点を当てています。

元のリンク：https ：//developer.aliyun.com/article/782518？

著作権表示： この記事の内容は、Alibaba Cloudの実名登録ユーザーによって自発的に提供されています。著作権は元の作成者に帰属します。AlibabaCloud開発者コミュニティはその著作権を所有せず、対応する法的責任を負いません。具体的なルールについては、「Alibaba Cloud DeveloperCommunityユーザーサービス契約」および「AlibabaCloudDeveloperCommunity知的財産保護ガイドライン」を参照してください。このコミュニティで盗用の疑いがある場合は、侵害の申し立てフォームに記入して報告してください。確認されると、コミュニティは侵害の疑いのあるコンテンツをすぐに削除します。