技術コラム

「JetsonとKubernetesで動かすEdge AIプラットフォーム講座」
第1回:Jetsonとコンテナ

Stylez(スタイルズ)

本記事はこんな課題やお困りごとをお持ちのお客様に是非ご覧頂きたい内容です。
・工場をもつ製造業のお客様でAIシステムを利用している
・製造現場の生産性をあげたい、運用の人手不足で困っている
・スマートファクトリーやコンテナ技術に興味はあるが、一体何なのかわかりづらい…

NVIDIA® Jetson™ シリーズを使ったEdge AIプラットフォームについてのあれこれを小ネタから最新情報まで幅広く取り扱います。
できるだけ読者の皆様の疑問に答えてまいりますので、「こんなことが分からない」「ここについて詳しく」などリクエストがございましたら、是非本サイト下部の「お申込みフォーム」までお願いいたします。

第一回目はJetsonにまつわるコンテナの話です。

1.1 AI開発とコンテナ

コンテナは、今やAI開発に欠かせないものとなってきました。その一方で、AI開発は開発言語とフレームワークと密接に関係していて、さらにそのフレームワークが利用するCUDAライブラリー(CUDA Toolkit)もまた切っても切れない関係にあります。
そして、それらの開発言語、フレームワーク、CUDAライブラリー(CUDA Toolkit)は別々に開発、管理、バージョンアップされていくという”辛み(ツラミ)”があります。

※下記URLの資料P.10より
https://www.slideshare.net/takanoriogata1121/190410-mlloft
ここでいう、「おれのかんきょうではうごく問題」です。

そこで脚光を浴びたのが、アプリケーションをOS環境内で分割する機能をもつコンテナで、このコンテナを使いやすく実装したのがDockerです。

Dockerは、コンテナを動かすために必要なものを1つのかたまりとして扱えるようにしました。

これにより何かをコンテナとして実行する場合には、このかたまりをダウンロードして起動する、という操作だけで開発が始められるようになりました。

1.2 コンテナの可搬性

これまでの物理(or 仮想)マシンでは、以下のようなひとかたまりで考える必要がありました。

しかし、Dockerのおかげで、下の図で「水色の部分のみ」を可搬性のあるDockerイメージとして利用でき、このイメージだけあればどこのサーバーでも実行できるようになりました。

これは、アプリケーションとフレームワークを一緒にパッケージングするというDockerイメージの機能によってもたらされたものです。
これを「コンテナの可搬性」といいます。

1.3 CUDAアプリケーションの場合

コンテナによりアプリケーションの可搬性が向上し、開発の現場は様変わりしましたが、CUDAアプリケーションではどうでしょうか?
CUDAアプリケーションの場合はGPUというハードウェアが絡んでくるので複雑です。

一般的なCUDAアプリケーションには、下の図のピンク部分にそれぞれ依存関係があります。

例えば、GPUを使うには、OS側にインストールされたGPUドライバー(NVIDIA Driver)が必要です。 このGPUドライバーに依存しているのがCUDAライブラリー(CUDA Toolkit)で、古いGPUドライバーでは動かない場合もあります。そして、そのCUDAライブラリをフレームワークが、フレームワークをCUDAアプリケーションが利用しています。

この問題が、コンテナでは次のように解決できます。

CUDA Toolkitがコンテナ側に内包されてフレームワークとの依存関係を解消できます。

▼詳細な図は以下リンクの「4. NGC Images」に掲載されています。
 https://docs.nvidia.com/deeplearning/frameworks/user-guide/index.html#nvdocim
 ※日本語版は株式会社HPCテックが以下のURLで公開しています。
 [ユーザガイド] NVIDIA ディープラーニングフレームワークコンテナ日本語版更新
 https://www.hpctech.co.jp/maker/nvidia_user_guide_2022.html

1.4 JetPackとの依存関係

NVIDIA Dockerで依存関係を解消できましたが、Jetsonでコンテナを実行する際、以下のような表記を見たことはないでしょうか?
「You would need to install Jetpack 4.3 to run this demo on Jetson Xavier NX. 」
つまり、「特定のJetPackでのみ動く(もしくは動作確認されている)」と書かれています。
現在のJetsonでは各種GPUに関連するソフトウェアに以下の制限があり、ここに大きな問題があります。

下記のURLに以下のような記述があります。
https://github.com/NVIDIA/nvidia-docker/wiki/NVIDIA-Container-Runtime-on-Jetson#usrlocalcuda-is-readonly
「ベータ版の制限の1つは、ホストからcudaディレクトリをマウントすることです。これは、開発用CUDAコンテナのサイズが3GBであることを考慮したもので、Nanoでは必ずしもそのような巨大なサイズのコンテナを利用することはできません。現在、より小さなCUDAコンテナの作成に向けて作業中です。」

Jetsonでコンテナを実行する際は、下図の通り、通常のNVIDIA Dockerとは異なります。

分かりにくいのですが、上記図の赤枠でコンテナの範囲にCUDA Toolkitが含まれていません。実はCUDA Toolkitはコンテナ基盤側に存在していて、水色のコンテナ内からマウントする仕様になっています。
CUDA Toolkitは3GBと巨大なためコンテナイメージ内ではなくコンテナ基盤側に置き、コンテナ内からマウントすることによって、自動的にマウントします。

コンテナは、可搬性と依存関係の解消を実現できる素晴らしいソフトウェアですが、CUDA Toolkitとフレームワークに依存関係があり、コンテナもコンテナ基盤側であるJetPackに依存してしまうのです。JetPack 4.6.1までの制限で、JetPack 5.0で解消される見込みです。

1.5 JetPack 5.0での変更点

JetPack 5.0では上記のように変更される予定です。

CUDA Toolkitがコンテナ側に移行され、フレームワークとCUDA Toolkitがコンテナ側になることで、JetPackとの依存関係の減少が期待できます。一方で、コンテナ側のサイズが増加する、という課題もでてきます。
▼Jetpack SDK 5.0の変更点に関する詳細はこちら
 JetPack SDK 5.0 Developer Preview | NVIDIA Developer
 https://developer.nvidia.com/jetpack-sdk-50dp


下記は、ディープラーニングに必要なコンテナイメージ置き場であるNVIDIA NGC™ (NVIDIA GPU Cloud)のコンテナイメージのサイズですが、JetPack 5.0用は6.76GBとJetPack 4.6.1の1.71GBから5GB増えています。
▼JetsonとJetPack用の機械学習用コンテナイメージの詳細はこちら
 https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-ml

JetsonはeMMCで動かしていて、容量が限られていることから別の悩みが増えそうです。

第1回の「Jetsonとコンテナ」いかがだったでしょうか。今後も、普段何気なく使っていて、何だろうな?と疑問に思うような内容を取り上げていきたいと思います。

是非、フィードバックをいただければ幸いです。

ページの先頭へ戻る