AI／機械学習にコンテナは必要か？――4人のスペシャリストが語るGPUコンテナの未来：KubernetesでGPUをどう活用できるのか？

2018年11月8日に行われた「Red Hat Forum 2018 Tokyo」で、パネルディスカッション「AI/マシンラーニング開発基盤を支える技術 〜Kubernetesが創るGPUコンテナの未来〜」が開催された。4人のスペシャリストが語った、AI／機械学習とコンテナの現状、課題、展望とは。

[PR／＠IT]

PR

　2018年11月8日に行われ盛況のうちに幕を閉じた「Red Hat Forum 2018 Tokyo」。そのセッションの一つとして開催されたのがパネルディスカッション「AI/マシンラーニング開発基盤を支える技術 〜Kubernetesが創るGPUコンテナの未来〜」だ。エヌビディア（NVIDIA）、Preferred Networks（PFN）、日本ヒューレット・パッカード（HPE）、レッドハットという各分野のエキスパートが、AI、マシンラーニング（機械学習）、ディープラーニング（深層学習）において、コンテナがどのような効果をもたらすのか、現在の課題や今後の展望を語った。

　登壇者は以下の通り。モデレーターは＠IT編集部 エグゼクティブエディターの三木泉（以下、三木）が務めた。今回はTwitterのハッシュタグ「#RHF_TECH」を使って会場からリアルタイムで質問も募った。

登壇者

大村伸吾氏（以下、大村氏）

Preferred Networks エンジニア

「最先端の技術を最短路で実用化する」ことを目指し、深層学習の活用をさまざまな領域で進めるPFN。交通システム、製造業、バイオ・ヘルスケアといった分野で事業を展開し、パーソナルロボットの研究開発にも取り組んでいる。大村氏は、社内向けGPU（グラフィックスプロセッシングユニット）クラスタ（約1500GPU）の開発、運用、Chainerのクラウド環境でのユーザビリティ向上、「Kubeflow」のコンポーネントである「chainer-operator」の開発を担当している。

佐々木邦暢氏（以下、佐々木氏）

エヌビディア HPC担当マーケティングマネージャ

オークリッジ国立研究所のSummitやローレンスリバモア国立研究所のSierraといった世界トップのスーパーコンピュータに採用されるGPUを開発するNVIDIA。佐々木氏は、TSUBAME2.0のTOP500チャレンジでGPUコンピューティングと出会い、同社に入社。AI、HPC（ハイパフォーマンスコンピューティング）領域のマーケティング活動を担当する。ディープラーニングのハンズオントレーニングを提供するDeep Learning Instituteの責任者も務める。

惣道哲也氏（以下、惣道氏）

日本ヒューレット・パッカード Pointnext事業統括 テクノロジーアーキテクト部 部長

顧客向けサービスデリバリーのPointnext事業部門で設計、構築を担当。ソフトウェア開発R&D部門、通信、金融、放送業界などの顧客案件に従事した後、オープンソース技術を専門に扱う現在の部署に配属。OSS（オープンソースソフトウェア）の調査、検証、提案、構築、クラウドに携わる他、コンテナ、AI、ディープラーニングに関する技術アーキテクト活動も行う。HPE社内技術コミュニティーのJapan Leadも務める。

北山晋吾氏（以下、北山氏）

レッドハット OpenShift アーキテクト

OpenShiftにおけるハイブリッドクラウドのソリューション開発やコンサルティングを推進。主にOpenShiftのインフラ、運用に関するアーキテクトとして活動。OpenShiftやGitLabなどを始めとしたコミュニティー運営なども行う。著書、共著に『Ansible/GitLab実践ガイド』（インプレス）『インフラCI実践ガイド』（翔泳社）がある。

登壇者（左から、モデレーターの三木、北山氏、惣道氏、佐々木氏、大村氏）

AI／機械学習でコンテナを選択する理由は？

エヌビディア HPC担当マーケティングマネージャの佐々木邦暢氏

三木　最初のテーマは「AI／機械学習の実装においてコンテナを選択する理由は何か」です。必ずしもコンテナを使う必要はなく、オンプレミスであったり、クラウドの仮想マシンを使ったりするケースもあります。なぜコンテナを使うのでしょうか。

佐々木氏　実際にはAI／機械学習の実装において、コンテナである必要はありません。ただ、機械学習のタスクで時間を費やしがちな作業は、実際の学習フェーズやモデルの精度を高めることではなく、ツールやライブラリのインストールです。「GPUで機械学習やってみた」「文字認識をやってみた」などのブログやWebエントリーを見ても、内容の半分以上がセットアップで占めています。そうしたインフラの構築やライブラリの管理を何とかしたいというニーズは確実にあり、今それを解決する有力な手段の一つがコンテナになっています。

　例えば、深層学習フレームワーク「Apache MXNet」と機械学習ライブラリ「TensorFlow」をそれぞれインストールするのは簡単です。でも、両方を自分のマシンに実装しようとすると、それぞれがNVIDIAの「CUDAライブラリ」の異なるバージョンが必要になることがあります。環境ごとにこうしたバージョン問題を切り分けられれば、仮想マシンでもいいのですが、仮想マシンはセットアップにも時間がかかり、重く使いにくいものです。そこで、セットアップの容易なコンテナの利点を活用します。

ソフトウェアのバージョン管理が大変

　ちなみにNVIDIAでは「NVIDIA GPU CLOUD（NGC）」というクラウド上から、深層学習で使うコンテナイメージを提供しています。NGCはIaaS（Infrastructure as a Service）のクラウド環境ではなく、NVIDIAが動作確認を行ったコンテナイメージが展開されているコンテナレジストリです。これによって、自分の使いたい環境を気軽に持ってこられるのがコンテナの便利なところです。

NVIDIA GPU CLOUD

三木　AI／機械学習の取り組みでは、何かと試行錯誤することが多い。このようなシーンでもコンテナのスピード感や俊敏性は生きてきますか。

佐々木氏　そうですね。環境やソフトウェアを素早く切り替えながら、すでに構築した環境に影響を与えずに、いつでも再構築できる。そうした機動性の高さはコンテナの大きな魅力です。

惣道氏　AI／機械学習の業界は発展途上であり、フレームワークのバージョンアップが激しい状況です。そのため、アップグレードで落とし穴にハマることもありますが、コンテナであれば新しいバージョンのコンテナイメージをNGCからダウンロードし、使うことができます。環境の再現性が高く、ワークロードをコンテナにタグ付けして管理できるところはメリットです。

大村氏　PFNの研究者の多くは、実験コードを変えながら、実験を繰り返します。そのときエンジニアなら、「この前のコンフィグやコードがどうだったか」という履歴をすぐにGitなどで見られます。しかし、必ずしも研究者全員がGitを得意としているわけではありません。研究者の書いたコード、必要な環境、設定をコンテナイメージ化することで、後から同じ環境で再実行できるところはメリットの一つです。

オンプレミスとパブリッククラウドの使い分けは？

日本ヒューレット・パッカード Pointnext事業統括 テクノロジーアーキテクト部部長の惣道哲也氏

三木　次のテーマは「オンプレミスとパブリッククラウドの使い分け」です。パブリッククラウドでの機械学習系のサービスがいろいろと出てきていますが、使い分けはどうすればいいのでしょうか。

惣道氏　「HPEはサーバハードウェアを提供しているので、オンプレミス」と言いたいところですが、実際にはユースケース次第です。スモールスタートですぐに使う場合は、パブリッククラウドが向いています。コストが見合えばクラウドは選択肢になるでしょう。

　逆にオンプレミスが選ばれるケースとしては、自律走行車のようにデータがオンプレミスで大量に発生する場合です。毎日、数十TBのデータをパブリッククラウドに上げ続けるのは現実的ではないので、発生元と同じオンプレミスに機械学習の環境を作ってデータをためていく方が最適です。

　その他、データを外に出したくないというセキュリティの観点もありますし、AIも含めたシステム全体をオンプレミスで管理したいというケースもあります。例えば、AIと監視カメラを連動させて人の検知をする場合、判別（推論）のレイテンシを低くするために、GPUを積んだ小さいサーバボックスをオンプレミスで動かすことで、高速に人の識別を行うことが可能になります。

三木　Twitterユーザーからも質問が来ていますが、そもそも機械学習でコンテナの比率はどれくらいあるのでしょうか。

大村氏　PFNではかなりの割合の機械学習がコンテナで動いています。特殊なワークロードだけがベアメタルで動いていて、ほとんどは内製しているプラットフォームで動くか、Kubernetes上で動くので、大部分はコンテナで実行されています。

三木　基本的にはクラウドは使っていないのでしょうか。

大村氏　深層学習のワークロードを動かすという観点ではほとんど使っていません。PFNの環境というのもありますが、みんな、息を吸うように分散学習しています。32台や64台のGPU環境を日常的に使う人も少なくありません。またジョブ期間が長いものでは数週間を超えるものもあります。そうしたワークロードが定常的に発生しているため、パブリッククラウドを使うというのはコストパフォーマンスが低いです。

　また、分散学習はGPUがたくさんあればいいわけではありません。現実的な時間で深層学習のジョブを実行するには、GPUマシン同士のインターコネクトがものすごく速くないといけません。PFNではInfiniBandを利用していますが、そういった技術はパブリッククラウドですぐに利用できません。その場合、オンプレミスのクラスタを使う方が現実的だと思います。

三木　「コンテナで性能は出る？」という質問が来ましたが、どうでしょうか。

大村氏　Kubenretesのクラスタ内ネットワークは、利用するネットワークプラグインによってオーバーヘッドがある可能性があります。しかし、私たちが分散学習で使っているInfiniBandのネットワークは、クラスタ内ネットワークとは分離されている状態で利用しているので、オーバーヘッドがない状態で使えています。

KubernetesでのGPU活用環境の整備状況は？

三木　コンテナオーケストレーターとしてKubernetesがデファクトスタンダードになり、GPUを活用する環境も整ってきました。では、KubernetesでのGPU活用環境は現在どういう状況にあるのでしょうか。

佐々木氏　Dockerを使っているとお分かりかと思いますが、普通にDockerのコンテナを作るとホスト側に装着しているGPUも隔離されてしまうので見えません。これではGPU環境が整っていてもコンテナの中から利用できないため、NVIDIAではそこの改善から取り組みました。「nvidia-docker」というランタイムを提供したのは、この取り組みの成果です。nvidia-dockerは、ホスト側のGPUを分離されたコンテナの中でも利用できる仕組みを提供しています。

　次に取り組んだのが、Kubernetesによって管理されているノードが持っているGPUデバイスを見せるという仕組みです。Kubernetesのバージョン1.8から、ホストが持っている固有のデバイスを統一的な仕組みでコンテナにスケジューリングする「デバイスプラグイン」の機構が作られました。この機構を活用して、ホスト上にあるGPUの利用情報をKubernetesクラスタに提供する仕組みが「NVIDIA device plugin for Kubernetes（k8s-device-plugin）」です。

NNVIDIA device plugin for Kubernetes

北山氏　ここで少しKubernetesのデバイスプラグインを説明します。Kubernetesは、APIを通して各コンテナの情報をスペック（spec）という共通の規格で取り扱います。CPUやメモリはデフォルトで定義できますが、GPUは定義されておらず、コンテナノード側の「kubelet」もGPUを監視してくれません。

　そこでNVIDIAのデバイスプラグインを使い、「NVIDIA_VISIBLE_DEVICES」という変数を使って、どのGPUを割り当てるかを指定します。デバイスプラグインがGPUの数や仕様状況を監視し、アロケートできるものを振り分けてkubeletにわたすことで、スケジューリングされたGPUがアタッチされる仕組みです。

　なお、Red Hatでは、「OpenShift」でGPUのサポートを開始しています。これはkubeletがk8s-device-pluginを含むデバイスプラグインのAPIを受け付けることに対してのサポートを行うものです。パートナーが作成したデバイスプラグインは、そのパートナーがサポートすることになります。

GPU Allocate Architecture

KubernetesのGPU活用のコツ、課題は？

Preferred Networks エンジニアの大村伸吾氏

三木　大村さんはKubernetesやGPUを実際にどのように運用されているのですか。

大村氏　KubernetesでGPUをうまくスケジュールできるのはNVIDIA Device Pluginのおかげです。私たちのクラスタには約1500枚のGPUがありますが、目立った問題もなくスムーズに使えています。使っていて幾つかコツもあるので紹介します。

　まず、GPUの世代の種類が「NVIDIA Tesla V100」「NVIDIA Tesla P100」など複数あったり、メモリのスペックが違っていたりする場合があります。そこで、GPUそれぞれにデバイス名（Extended Resourceの名前）を付ける方法があります。しかし、その方法の場合、スケジューリングするときにKubernetesから別々のデバイスとして見えてしまいます。この状態では「どれでもいいから動かしたい」という要求には応えにくくなります。NVIDIA Device Pluginでもそのようになっています。

　一方、特定のGPUで動かしたいというニーズに対しては、ホストにインストールされているNVIDIAドライバのバージョンや、GPUのモデル名、メモリの量をノードにタグ付けして、ユーザーが選択できるようにします。このようなノードのタグ付けを自動で行うコンポーネントをPFNでは自作しています。

　また分散深層学習では、コンテナ同士の近さがパフォーマンスに影響します。そこでInfiniBandのトポロジー情報を自動で収集し、あらかじめノードにタグ付けしておくことによって、同じスイッチの下に分散ジョブのコンテナを配置するなどしています。

　NVIDIAのDockerイメージをローカルマシンで使うときには注意が必要です。公式イメージではNVIDIA_VISIBLE_DEVICESに「all」という値が付いていて、GPUを要求していないPodに対してもGPUのマウントが起こり得ます。そこでKubernetesの「Dynamic Webhook」という仕組みを使って「none」を指定するといった運用上の工夫も行っています。

三木　Twitterユーザーからの質問ですが、コンテナからGPUをオーバーコミットできるのでしょうか。つまり、仮想マシンでのGPU仮想化（vGPU）のように、複数コンテナで1つのGPUを共有できないかという質問です。

佐々木氏　この質問、やっぱり来ましたね。現時点の技術ではオーバーコミットはできません。ただ、GPUをビジーにし続けることがスループットをあげるためには重要だと理解していて、その方法は現時点では2つあります。

　一つは、仮想環境が前提ですが、vGPUは演算目的での利用もサポートしているので、その機能を使って、GPUを複数人で共有する方法です。もう一つは、最近発表したばかりの方法で、画像認識や音声認識などでモデルに対する推論の要求および、複数のユーザー、複数のマシンからの要求を1つの「インファレンスサーバ」で受けて、それを集約し、1つのGPUでまとめて高密度に実行する仕組みです。コンテナからのGPUオーバーコミットはまだできませんが、複数のユーザーからの要求を1つのGPUで受けて効率的に使うニーズに応える方法は提供され始めています。

HPCの世界とクラウド／コンテナの世界でのアプローチの違いは？

三木　スケジューリングについては、HPCの世界の人と、クラウド／コンテナの世界の人でアプローチが違うようです。どう考えますか。

惣道氏　従来のHPCクラスタはオンプレミスで構成されていて、大量ではあるものの有限のリソースをいかに無駄なく、効率的にスケジューリングし、共有して使うかを重視します。PFNさんもそういう観点でKubernetesのスケジューラーに手を入れているのだと思います。

　一方で、KubernetesはもともとGoogleが設計した「Borg」と呼ばれるクラスタ管理システムを基にした、オープンソースソフトウェアです。Googleは「横に無限にスケールする」リソースを扱う発想に基づいており、効率的にスケジューリングする方向性とは違います。KubernetesはHPCほど、細かくスケジューリングするのが難しく、まだ進化の過程だと思います。

大村氏　Kubernetes自体は、Webサービスをメインなワークロードとして、フォールトトレラント、ハイアベイラビリティーでデプロイできるように進化してきました。HPCの人たちは、環境構築の手間をコンテナ化したいと思っていて、実際にワークロードをコンテナ化しようという動きもあります。

　確かにKubernetesは、ジョブスケジューラーとしては最適化されていないと思うことはあります。惣道氏が話されたように、横に無限にスケールするような環境では、どこにどうコンテナを配置するかは、ケアする必要があまりありません。

　一方PFNのように、オンプレミスでエラスティック性が柔軟でない環境では、GPUリソースプールの中で、コンテナをいかにスケジューリングできるかが重要になります。Kubernetesを使い始めて1年くらいですが、そこに対してはまだ取り組んでいる途中です。

　その中で今できていることとして、Kubernetesの「プライオリティー」という概念を使った取り組みがあります。このプライオリティーは、落ちてほしくないクリティカルなシステムといった優先度の高いワークロードを維持するため、クラスタに空きがないときに、優先度の低いワークロードを動的に停止する機能（プリエンプション）です。

　PFNではこの機能を活用して、優先度の高いプロジェクトにおいて研究開発のスピードを落とさないような工夫をしています。また、プリエンプションする際に「どの低いワークロードを自動で停止するのか」はとても難しい問題です。誰も自分のジョブを勝手に止められたいとは思わないからです。PFNではこの「どれを自動で停止するのか」というポリシーをカスタマイズしています。

　また、分散深層学習では1個ずつコンテナを配置するとデッドロックが起きるので、コンテナ群をまとめて配置する、いわゆる「ギャングスケジューリング」を考えています。それに向けて「kube-scheduler」を拡張する準備を進めています。

データサイエンティスト支援で今後求められる機能は？

レッドハット OpenShift アーキテクトの北山晋吾氏

三木　データサイエンティスト支援で今後求められる機能、今後の利用で期待できることは何でしょうか。

北山氏　まずわれわれが普段接しているお客さまは、大きく3つのカテゴリーに分けられます。それは、ビジネスで利用する「ビジネス」、データを解析する「データサイエンティスト」、データをクレンジングする「データエンジニアリング」です。それぞれで求められる機能や期待は違います。ユーザーの立場としてこのように分けていますが、それはどうなのでしょうか。PFNさんではどう分けられていますか。

大村氏　PFNでは、データサイエンティストという専業の人はいなくて、それぞれの研究者がやっています。また、研究者とひとくくりにいっても、数学、物理、化学、医療、コンピュータサイエンス、機械工学など多岐にわたります。そのため、ビッグデータのプラットフォームを大規模に構築しても、コストパフォーマンスが良くないという事情があります。みんながソフトウェアエンジニアリングのスキルを持っているわけではないので、「Apache Sparkクラスタを用意したのでぜひ使ってください」と言われても使えない研究者も居ます。

　こうした背景により、データサイエンティスト向けというよりは、PFNの研究者それぞれのリテラシーに合わせて、幾つかのツールや環境を提供しています。例えば、GitとPythonが分かっていれば使えるようなデータセットと、コード管理から実験管理までサポートするジョブスケジューラーのツールを内製で作ったり、Jupyterが欲しい人に向けてJupyterHubをKubernetesに載せて「Jupyter as a 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基盤の方向性という観点では、リソース提供の抽象化や詳細の隠蔽化が進んでいくと思います。

　また、ツールに限らず、それを活用する組織全体での観点で見ても、かつてビッグデータで“SQL on Hadoop”のようないわゆる「民主化」が起こったように、AIについてもより利用者の裾野を広げるような民主化が進むと思います。いろいろなものがOSSを通して育ち、必要な機能も充実していくでしょう。いろいろなプロダクトやサービスの進化をこれからも見守っていただきたいと思います。