〜Kubernetesが創るGPUコンテナの未来〜」が開催された。4人のスペシャリストが語った、AI/機械学習とコンテナの現状、課題、展望とは。〜Kubernetesが創るGPUコンテナの未来〜」だ。Networks(PFN)、日本ヒューレット・パッカード(HPE)、レッドハットという各分野のエキスパートが、AI、マシンラーニング(機械学習)、ディープラーニング(深層学習)において、コンテナがどのような効果をもたらすのか、現在の課題や今後の展望を語った。エグゼクティブエディターの三木泉(以下、三木)が務めた。エンジニア「最先端の技術を最短路で実用化する」ことを目指し、深層学習の活用をさまざまな領域で進めるPFN。交通システム、製造業、バイオ・ヘルスケアといった分野で事業を展開し、パーソナルロボットの研究開発にも取り組んでいる。大村氏は、社内向けGPU(グラフィックスプロセッシングユニット)クラスタ(約1500GPU)の開発、運用、Chainerのクラウド環境でのユーザビリティ向上、「Kubeflow」のコンポーネントである「chainer-operator」の開発を担当している。HPC担当マーケティングマネージャオークリッジ国立研究所のSummitやローレンスリバモア国立研究所のSierraといった世界トップのスーパーコンピュータに採用されるGPUを開発するNVIDIA。佐々木氏は、TSUBAME2.0のTOP500チャレンジでGPUコンピューティングと出会い、同社に入社。AI、HPC(ハイパフォーマンスコンピューティング)領域のマーケティング活動を担当する。Instituteの責任者も務める。顧客向けサービスデリバリーのPointnext事業部門で設計、構築を担当。顧客案件に従事した後、オープンソース技術を専門に扱う現在の部署に配属。クラウドに携わる他、コンテナ、AI、ディープラーニングに関する技術アーキテクト活動も行う。アーキテクトOpenShiftにおけるハイブリッドクラウドのソリューション開発やコンサルティングを推進。OpenShiftのインフラ、運用に関するアーキテクトとして活動。OpenShiftやGitLabなどを始めとしたコミュニティー運営なども行う。著書、共著に『Ansible/GitLab実践ガイド』(インプレス)『インフラCI実践ガイド』(翔泳社)がある。最初のテーマは「AI/機械学習の実装においてコンテナを選択する理由は何か」です。コンテナを使う必要はなく、オンプレミスであったり、クラウドの仮想マシンを使ったりするケースもあります。コンテナを使うのでしょうか。実際にはAI/機械学習の実装において、コンテナである必要はありません。機械学習のタスクで時間を費やしがちな作業は、実際の学習フェーズやモデルの精度を高めることではなく、ツールやライブラリのインストールです。「GPUで機械学習やってみた」「文字認識をやってみた」などのブログやWebエントリーを見ても、内容の半分以上がセットアップで占めています。したインフラの構築やライブラリの管理を何とかしたいというニーズは確実にあり、今それを解決する有力な手段の一つがコンテナになっています。MXNet」と機械学習ライブラリ「TensorFlow」をそれぞれインストールするのは簡単です。両方を自分のマシンに実装しようとすると、それぞれがNVIDIAの「CUDAライブラリ」の異なるバージョンが必要になることがあります。環境ごとにこうしたバージョン問題を切り分けられれば、仮想マシンでもいいのですが、仮想マシンはセットアップにも時間がかかり、重く使いにくいものです。そこで、セットアップの容易なコンテナの利点を活用します。CLOUD(NGC)」というクラウド上から、深層学習で使うコンテナイメージを提供しています。Service)のクラウド環境ではなく、NVIDIAが動作確認を行ったコンテナイメージが展開されているコンテナレジストリです。これによって、自分の使いたい環境を気軽に持ってこられるのがコンテナの便利なところです。AI/機械学習の取り組みでは、何かと試行錯誤することが多い。このようなシーンでもコンテナのスピード感や俊敏性は生きてきますか。環境やソフトウェアを素早く切り替えながら、すでに構築した環境に影響を与えずに、いつでも再構築できる。した機動性の高さはコンテナの大きな魅力です。AI/機械学習の業界は発展途上であり、フレームワークのバージョンアップが激しい状況です。そのため、アップグレードで落とし穴にハマることもありますが、コンテナであれば新しいバージョンのコンテナイメージをNGCからダウンロードし、使うことができます。環境の再現性が高く、ワークロードをコンテナにタグ付けして管理できるところはメリットです。PFNの研究者の多くは、実験コードを変えながら、実験を繰り返します。そのときエンジニアなら、「この前のコンフィグやコードがどうだったか」という履歴をすぐにGitなどで見られます。研究者全員がGitを得意としているわけではありません。研究者の書いたコード、必要な環境、設定をコンテナイメージ化することで、後から同じ環境で再実行できるところはメリットの一つです。次のテーマは「オンプレミスとパブリッククラウドの使い分け」です。パブリッククラウドでの機械学習系のサービスがいろいろと出てきていますが、使い分けはどうすればいいのでしょうか。「HPEはサーバハードウェアを提供しているので、オンプレミス」と言いたいところですが、実際にはユースケース次第です。スモールスタートですぐに使う場合は、パブリッククラウドが向いています。コストが見合えばクラウドは選択肢になるでしょう。逆にオンプレミスが選ばれるケースとしては、自律走行車のようにデータがオンプレミスで大量に発生する場合です。毎日、数十TBのデータをパブリッククラウドに上げ続けるのは現実的ではないので、発生元と同じオンプレミスに機械学習の環境を作ってデータをためていく方が最適です。その他、データを外に出したくないというセキュリティの観点もありますし、AIも含めたシステム全体をオンプレミスで管理したいというケースもあります。AIと監視カメラを連動させて人の検知をする場合、判別(推論)のレイテンシを低くするために、GPUを積んだ小さいサーバボックスをオンプレミスで動かすことで、高速に人の識別を行うことが可能になります。Twitterユーザーからも質問が来ていますが、そもそも機械学習でコンテナの比率はどれくらいあるのでしょうか。PFNではかなりの割合の機械学習がコンテナで動いています。特殊なワークロードだけがベアメタルで動いていて、ほとんどは内製しているプラットフォームで動くか、Kubernetes上で動くので、大部分はコンテナで実行されています。基本的にはクラウドは使っていないのでしょうか。深層学習のワークロードを動かすという観点ではほとんど使っていません。PFNの環境というのもありますが、みんな、息を吸うように分散学習しています。32台や64台のGPU環境を日常的に使う人も少なくありません。ジョブ期間が長いものでは数週間を超えるものもあります。したワークロードが定常的に発生しているため、パブリッククラウドを使うというのはコストパフォーマンスが低いです。分散学習はGPUがたくさんあればいいわけではありません。現実的な時間で深層学習のジョブを実行するには、GPUマシン同士のインターコネクトがものすごく速くないといけません。PFNではInfiniBandを利用していますが、そういった技術はパブリッククラウドですぐに利用できません。その場合、オンプレミスのクラスタを使う方が現実的だと思います。「コンテナで性能は出る?」という質問が来ましたが、どうでしょうか。Kubenretesのクラスタ内ネットワークは、利用するネットワークプラグインによってオーバーヘッドがある可能性があります。私たちが分散学習で使っているInfiniBandのネットワークは、クラスタ内ネットワークとは分離されている状態で利用しているので、オーバーヘッドがない状態で使えています。コンテナオーケストレーターとしてKubernetesがデファクトスタンダードになり、GPUを活用する環境も整ってきました。KubernetesでのGPU活用環境は現在どういう状況にあるのでしょうか。Dockerを使っているとお分かりかと思いますが、普通にDockerのコンテナを作るとホスト側に装着しているGPUも隔離されてしまうので見えません。これではGPU環境が整っていてもコンテナの中から利用できないため、NVIDIAではそこの改善から取り組みました。「nvidia-docker」というランタイムを提供したのは、この取り組みの成果です。nvidia-dockerは、ホスト側のGPUを分離されたコンテナの中でも利用できる仕組みを提供しています。次に取り組んだのが、Kubernetesによって管理されているノードが持っているGPUデバイスを見せるという仕組みです。Kubernetesのバージョン1.8から、ホストが持っている固有のデバイスを統一的な仕組みでコンテナにスケジューリングする「デバイスプラグイン」の機構が作られました。Kubernetes(k8s-device-plugin)」です。ここで少しKubernetesのデバイスプラグインを説明します。Kubernetesは、APIを通して各コンテナの情報をスペック(spec)という共通の規格で取り扱います。CPUやメモリはデフォルトで定義できますが、GPUは定義されておらず、コンテナノード側の「kubelet」もGPUを監視してくれません。そこでNVIDIAのデバイスプラグインを使い、「NVIDIA_VISIBLE_DEVICES」という変数を使って、どのGPUを割り当てるかを指定します。デバイスプラグインがGPUの数や仕様状況を監視し、アロケートできるものを振り分けてkubeletにわたすことで、スケジューリングされたGPUがアタッチされる仕組みです。Hatでは、「OpenShift」でGPUのサポートを開始しています。これはkubeletがk8s-device-pluginを含むデバイスプラグインのAPIを受け付けることに対してのサポートを行うものです。パートナーが作成したデバイスプラグインは、そのパートナーがサポートすることになります。大村さんはKubernetesやGPUを実際にどのように運用されているのですか。Pluginのおかげです。私たちのクラスタには約1500枚のGPUがありますが、目立った問題もなくスムーズに使えています。使っていて幾つかコツもあるので紹介します。P100」など複数あったり、メモリのスペックが違っていたりする場合があります。Resourceの名前)を付ける方法があります。その方法の場合、スケジューリングするときにKubernetesから別々のデバイスとして見えてしまいます。この状態では「どれでもいいから動かしたい」という要求には応えにくくなります。Pluginでもそのようになっています。特定のGPUで動かしたいというニーズに対しては、ホストにインストールされているNVIDIAドライバのバージョンや、GPUのモデル名、メモリの量をノードにタグ付けして、ユーザーが選択できるようにします。このようなノードのタグ付けを自動で行うコンポーネントをPFNでは自作しています。分散深層学習では、コンテナ同士の近さがパフォーマンスに影響します。そこでInfiniBandのトポロジー情報を自動で収集し、あらかじめノードにタグ付けしておくことによって、同じスイッチの下に分散ジョブのコンテナを配置するなどしています。NVIDIAのDockerイメージをローカルマシンで使うときには注意が必要です。公式イメージではNVIDIA_VISIBLE_DEVICESに「all」という値が付いていて、GPUを要求していないPodに対してもGPUのマウントが起こり得ます。Webhook」という仕組みを使って「none」を指定するといった運用上の工夫も行っています。Twitterユーザーからの質問ですが、コンテナからGPUをオーバーコミットできるのでしょうか。仮想マシンでのGPU仮想化(vGPU)のように、複数コンテナで1つのGPUを共有できないかという質問です。この質問、やっぱり来ましたね。現時点の技術ではオーバーコミットはできません。GPUをビジーにし続けることがスループットをあげるためには重要だと理解していて、その方法は現時点では2つあります。一つは、仮想環境が前提ですが、vGPUは演算目的での利用もサポートしているので、その機能を使って、GPUを複数人で共有する方法です。一つは、最近発表したばかりの方法で、画像認識や音声認識などでモデルに対する推論の要求および、複数のユーザー、複数のマシンからの要求を1つの「インファレンスサーバ」で受けて、それを集約し、1つのGPUでまとめて高密度に実行する仕組みです。コンテナからのGPUオーバーコミットはまだできませんが、複数のユーザーからの要求を1つのGPUで受けて効率的に使うニーズに応える方法は提供され始めています。スケジューリングについては、HPCの世界の人と、クラウド/コンテナの世界の人でアプローチが違うようです。従来のHPCクラスタはオンプレミスで構成されていて、大量ではあるものの有限のリソースをいかに無駄なく、効率的にスケジューリングし、共有して使うかを重視します。PFNさんもそういう観点でKubernetesのスケジューラーに手を入れているのだと思います。一方で、KubernetesはもともとGoogleが設計した「Borg」と呼ばれるクラスタ管理システムを基にした、オープンソースソフトウェアです。Googleは「横に無限にスケールする」リソースを扱う発想に基づいており、効率的にスケジューリングする方向性とは違います。KubernetesはHPCほど、細かくスケジューリングするのが難しく、まだ進化の過程だと思います。Kubernetes自体は、Webサービスをメインなワークロードとして、フォールトトレラント、ハイアベイラビリティーでデプロイできるように進化してきました。HPCの人たちは、環境構築の手間をコンテナ化したいと思っていて、実際にワークロードをコンテナ化しようという動きもあります。確かにKubernetesは、ジョブスケジューラーとしては最適化されていないと思うことはあります。惣道氏が話されたように、横に無限にスケールするような環境では、どこにどうコンテナを配置するかは、ケアする必要があまりありません。PFNのように、オンプレミスでエラスティック性が柔軟でない環境では、GPUリソースプールの中で、コンテナをいかにスケジューリングできるかが重要になります。Kubernetesを使い始めて1年くらいですが、そこに対してはまだ取り組んでいる途中です。その中で今できていることとして、Kubernetesの「プライオリティー」という概念を使った取り組みがあります。このプライオリティーは、落ちてほしくないクリティカルなシステムといった優先度の高いワークロードを維持するため、クラスタに空きがないときに、優先度の低いワークロードを動的に停止する機能(プリエンプション)です。PFNではこの機能を活用して、優先度の高いプロジェクトにおいて研究開発のスピードを落とさないような工夫をしています。プリエンプションする際に「どの低いワークロードを自動で停止するのか」はとても難しい問題です。誰も自分のジョブを勝手に止められたいとは思わないからです。PFNではこの「どれを自動で停止するのか」というポリシーをカスタマイズしています。分散深層学習では1個ずつコンテナを配置するとデッドロックが起きるので、コンテナ群をまとめて配置する、いわゆる「ギャングスケジューリング」を考えています。それに向けて「kube-scheduler」を拡張する準備を進めています。データサイエンティスト支援で今後求められる機能、今後の利用で期待できることは何でしょうか。われわれが普段接しているお客さまは、大きく3つのカテゴリーに分けられます。それは、ビジネスで利用する「ビジネス」、データを解析する「データサイエンティスト」、データをクレンジングする「データエンジニアリング」です。それぞれで求められる機能や期待は違います。ユーザーの立場としてこのように分けていますが、それはどうなのでしょうか。PFNさんではどう分けられていますか。PFNでは、データサイエンティストという専業の人はいなくて、それぞれの研究者がやっています。コンピュータサイエンス、機械工学など多岐にわたります。そのため、ビッグデータのプラットフォームを大規模に構築しても、コストパフォーマンスが良くないという事情があります。Sparkクラスタを用意したのでぜひ使ってください」と言われても使えない研究者も居ます。した背景により、データサイエンティスト向けというよりは、PFNの研究者それぞれのリテラシーに合わせて、幾つかのツールや環境を提供しています。Service」を提供したり、細かい設定までコントロールして、自分でビルドしたコンテナを使いたい人向けにはKubernetesのAPIを提供したりしています。ありがとうございます。われわれはOpenShiftを提供する中で、データを処理する人、機械学習をする人、ビジネスに活用する人と概念的には分けています。「データをどう管理するのか」「データをどう活用するのか」という観点で見ると、アプリケーションの開発と同じようにCI/CD(継続的インテグレーション/継続的デリバリー)のパイプラインで、開発からデプロイまでをつないでいくことが重要になってきます。そこでOpenShiftでは、KubernetesでのGPUのアロケートだけにとどまらず、コンテナ環境を、CI/CDによってビジネスで活用するところまでの開発環境基盤を提供しています。OSSとしてはKubeflowがあります。大村さんはKubeflowのコンポーネントであるchainer-operatorの開発に携わっていますが、PFNではKubeflowはかなり使っているのでしょうか。そこまで大規模には使っていなくて一部のコンポーネントのみの利用にとどまっています。データ処理から学習サイクル、アプリ展開までそれぞれの部分でのOSSは発達しているものの、それら全部を一貫してサポートするOSSはあまり見かけません。そこをカバーするのがKubeflowですが、まだまだ発展途上のプロジェクトです。1.0に向かって走っている途中で、むしろ、皆さんのコントリビュートが必要です。NVIDIAでも、「RAPIDS」というOSSのGPUアクセラレーションプラットフォームを提供しています。今は学習サイクルを回すときにGPUを使っていますが、その前段にデータ処理フェーズが必ずあります。このフェーズでGPUが役立てられないかというプロジェクトです。GPU対応データフレームとアルゴリズムをどんどん実装していっています。足りないと思ったらぜひコントリビュートしてほしいです。今後はどういった環境が整備されていくのでしょうか。各社ともAIを活用する基盤については4社4様に、データの蓄積、学習、活用へアプローチしています。HPEもコンテナはもちろん、データを蓄積するためのプラットフォームを提供しています。一方で、今後のAI基盤の方向性という観点では、リソース提供の抽象化や詳細の隠蔽化が進んでいくと思います。Hadoop”のようないわゆる「民主化」が起こったように、AIについてもより利用者の裾野を広げるような民主化が進むと思います。いろいろなものがOSSを通して育ち、必要な機能も充実していくでしょう。いろいろなプロダクトやサービスの進化をこれからも見守っていただきたいと思います。メールマガジンをご購読ください。申し込みページへ利用規約ITmediaはアイティメディア株式会社の登録商標です。