GPU を搭載した計算機の効率的な運用方法の検討と実装
當山 達也 1) , 尾形 幸亮 1) , 疋田 淳一 1)
1) 京都大学 企画・情報部
tohyama.tatsuya.6x@kyoto-u.ac.jp

Design and implementationfor eﬃcient operation of the GPU servers
Tatsuya Tohyama1) , Kosuke Ogata1) , Junichi Hikita1)
1) Planning and Information Management Department, Kyoto Univ.

概要
スーパーコンピュータは，様々な研究分野において用いられており，計算処理だけではなく，数値計算モデルの生成や計算結果の可視化といった処理にも多く利用されている．そのため，スーパーコンピュータを運用する多くの機関では，計算用途の計算機に加えて，画像処理装置 (GPU) を搭載した計算機を導入している．京都大学 学術情報メディアセンターでも，可視化の需要は増えてきており，GPU を搭載した計算機 (以下，GPU サーバ) の供用を 2018 年 12 月から開始した．しかし，需要に対して用意した GPU サーバは少なく，需要と供給のバランスを平準化させるためには，効率的な運用を行う必要がある．本稿では，GPU サーバを導入するにあたり，効率的な運用の実現に向けて検討した内容を述べ，検討結果を元に実装した予約システムを紹介する．て検討した内容ならびに結果を述べ，本センターで構

1 はじめに築した効率的な運用を支援する予約システムについて

スーパーコンピュータを利用する研究分野は，近年大幅に増加しており，従来のように高速に計算を行い計算結果を出力すれば良いといった単純なものから，数値計算モデルの生成 (プリプロセッサ) を行い，計算結果を可視化 (ポストプロセッサ) するアプリケーションの利用まで，多種多様なニーズが存在する．

紹介する．

2 スーパーコンピュータシステムの概要
2.1 構成図 1 に，本センターが所有するスーパーコンピュータのシステム構成を示す．

そこで，京都大学 学術情報メディアセンター (以下，本センター) では，GPU を搭載した計算機（以下，GPU サーバ) を現行システムに追加で用意し，可視化用途として 2018 年 12 月から供用を開始した．しかし，プリポスト処理を行う利用者数に対して，導入した GPU サーバは 2 台であり，1 台の機器を 1 利用者に割り当てると機器が早々に枯渇する状況が考えられ，多くの利用者が利用できるよう，効率的な運用が求められる．
本センターでは，スーパーコンピュータ利用者向けにサービス申請などを行うことが可能なポータルサイ

図1

スーパーコンピュータシステムの構成図

ト (以下，利用者ポータル)[1] を運用している．そこ
で，GPU サーバの予約機能を利用者ポータルに追加構築し，利用者が自由に GPU サーバを予約可能な仕組みを整えることで，効率的な運用を実現した．

すべてのサブシステムには，Intel 社製の CPU を搭載しており，GPU は搭載していない．また，各サブシ

本稿では，GPU サーバの効率的な運用手法につい365

ステムのログインノードも同様の構造となっている．

2.2 新たに導入した GPU サーバの諸元

算ノードで VNC サーバを立ち上げ，リモートデスク

本センターでは，可視化需要の増加に対応するべく，2018 年 12 月ならびに 2019 年 4 月に 1 台ずつ GPUサーバの供用を開始した．GPU サーバの諸元は，表1 ならびに 表 2 のとおりである．

CPU
メモリ

GPU3 GPU サーバの運用手法の検討
3.1

GPU サーバの運用設計

プリポスト処理を行う GUI アプリケーションは比表 1 1 号機の諸元OSトップ機能を用いた操作を行うことも可能である．

較的多くのメモリを消費する傾向にある．このため，

RedHat Enterprise Linux7

利用者自身が利用する GUI アプリケーションに応じIntel(R) Xeon(R) Gold 6140てメモリを確保することが好ましく，単純に搭載メモ

2.30GHz (18 コア) x 2

リ量からシステムで用いるメモリ量を減算し，1 人あ512GBたりに割り当てる固定のメモリ量で按分して，最大利NVIDIA Quadro P4000

用者数を求めれば良いというわけにはいかない．この(8 GB GDDR5) x 2

ため，利用者が確保したいメモリ量を自由に設定することが可能で，搭載メモリ量を上回らないように利用者の受入判断を行う仕組みが必要である．

表 2 2 号機の諸元

OSCPU
メモリ

GPU

そこで，利用者ポータルに，GPU サーバの予約シ

RedHat Enterprise Linux7ステムを追加実装することで解決できると考える．まIntel(R) Xeon(R) Silver 4110

た，利用者が予約処理を始めた段階で計算機の現在の2.10GHz (8 コア) x 2

利用者数，ならびにメモリの利用量，事前に予約済み512GBのリソースを取得できるように予約システムを設計す

NVIDIA Quadro GV100ることで，現時点のリソースに空きがあり，受入が可(32 GB GDDR5) x 2

能であれば，現時点からの予約を受け入れる事が可能となるのが望ましい．

GPU サーバは，Laurel2(System B) や，Cinnamon

これに加えて，GPU に強く依存するような GUI ア2(System C) と同じ OS ならびに互換のあるプロセッ

プリケーションを実行する利用者にむけて，GPU をサを採用することによって，従来動作していた GUI ア専有できるような仕組みが必要であると考える．ただプリケーションが，GPU サーバでも問題なく動作すし，GPU のすべてを専有可能な設計とした場合，当るように配慮した．

該計算機の最大利用者数は GPU の数となる．効率的

また，Camphor2(System A) については，従来からな運用という観点から考えると，最低 1 つの GPU はGUI アプリケーションの利用をサポートしていないた共有利用が可能となるように実装するのが望ましい．

め，当該機器に搭載されている OS ならびにプロセッサに類似した GPU サーバの導入は見送った．

3.2 効率的な運用に向けた検討
3.1 節で述べた運用設計をもとに，多くの利用者が2.3 現行システムの可視化手法

GPU サーバを効率良く利用することが可能な手法をプリポスト処理を行う GUI アプリケーションを
起 動 す る 際 に は ，ジ ョ ブ 投 入 用 の コ マ ン ド で は な
く，”xrun”と呼ばれるコマンドを用意している．当該コマンドが実行された場合は，ログインノードを通して X Window が利用者の端末まで転送されるような実装となっている．
また，Linux の GUI を利用者の端末に転送するには，X Window System が必要となるため，本センター
では，OpenText 社の Exceed onDemand[2] を利用者に提供している．その他の方法として，Windows であれば，Xming[3]，MacOS であれば，XQuarz[4] といっ
た X window アプリケーションの利用や，利用者が計366検討する必要がある．

3.2.1 制御可能なリソースの調査
GPU サーバに複数の利用者を収容してリソースを共有するにあたり，他の利用者の影響を受けないよう，論理的に GPU サーバのもつリソースを分離して提供する必要がある．リソースの利用を制限・隔離する機能として Linux OS 環境で広く利用されている

cgroup[5] を調査したところ，CPU コア，メモリについては，制御可能であることを確認した．
次に，GPU に関する制御機能について調査を行った．cgroup を用いて制御可能な項目としては，デバイスの利用可否のみとなっており，GPU のコア単位搭載しているメモリ量ならびに，現在のメモリの利用での利用制御や，GPU メモリの利用制限は困難であ状況から算出することが望ましい．

ることを確認した．また，GUI アプリケーションをGPU サーバで実行するにあたり，VirtualGL[6] を用いて描画処理を行うことで，可視化環境が大幅に改善

3.2.3 利用者に割り当てる CPU コア数の検討
本センターでよく利用されている GUI アプリケー
ションの推奨値は，表 3 のとおりである．

されることを確認している [7]．そこで，VirtualGL によるリソース制御の可否についても調査を実施した．

VirtualGL の実行パラメータを用いることで，利用す表3

プリポスト処理を行うアプリケーションの動作推奨値 (CPU)る GPU の制御を行うことは可能だが，cgroup と同様アプリケーション名推奨値に GPU のコア単位での利用制御や GPU メモリの利ANSYS [9]4-12 コア

用制限は，困難であることを確認した．

AVS/Express記載なし

ENVI/IDL [10]複数コア推奨MATLAB [11]4 コア

GaussView

記載なし

以上の結果から，システムとして制御可能なリソースは，下記の 3 点であると考える．

• CPU コア• メモリ

表 3 の結果から，4 コア程度の CPU コアを利用者• GPU(デバイス単位)に割り当てることで，プリポスト処理を行う GUI アプ
リケーションは問題なく動作するものと考えられる．

3.2.2 最大同時利用者数の検討
通常，Linux OS でアプリケーションを実行する際3.2.4 予約を受け付ける際に制限すべき項目の検討には，CPU，メモリ，GPU，GPU メモリをそれぞれ関連文献 [12] を参考に検討した結果から，予約を受使用する．これらのリソースのうち，3.2.1 節での調け付ける際に制限すべき項目として，以下の 3 点が考査において，システムとして制御可能と判定された

えられる．

CPU，メモリ，GPU のいずれかを用いることで，状況に応じた最大同時利用者数を算出することが可能か検討した．
まずはじめに，CPU ならびに GPU について検討• 予約受付期間• 最大連続利用時間• 同時予約数を行った．CPU や GPU については，コア数よりもまずはじめに，予約受付期間ならびに最大連続利用多数のスレッドが存在した場合は細かく時間を区切っ時間について検討を行った．本センターが提供するて順番に実行させることから，多数の利用者がアプリ

スーパーコンピューターのサービスコースを利用し，ケーションを同時に実行したとしても，動作速度の低従来の計算ノードでプリポスト処理を行う GUI アプ

下は見られるが，強制終了されることはない．このた

リケーションを実行した際の最大連続利用時間は，336

め，CPU や GPU については最大同時利用者数を判時間 (14 日) となっている [13]．しかし，GPU サーバ断するにあたって，一定の目安を設定する必要はあるを用いることによって，従来よりも計算時間は短縮さが，最大同時利用者数を算出するにあたって重要であれると考えられ，公平性の観点から最大連続利用期間るとは考えられない．

を 72 時間 (3 日) として設定し，利用状況に応じて再次に，メモリについて検討を行った．Linux OS の度検討するといった対応を行うこととした．

場合，メモリが不足してシステムの維持が困難になる

次に，同時予約数について検討を行った．複数の予とシステムが判断した場合には，メモリリソースを多約を許可すると，一人の利用者が機器を専有利用するく消費しているプロセスを強制的に終了させる機能可能性が考えられ，多くの利用者へ利用機会を提供す(OOM Killer[8]) が搭載されている．このため，シスるといった観点から，好ましくないと考える．そこで，テムに搭載しているメモリ量を超過してメモリを確

予約については最大 1 件とし，当該予約の期間満了ま保すると，アプリケーションの実行に多大な影響を及たは，利用者がキャンセル処理を行うと，改めて予約ぼす可能性が高く，最大同時利用者数を算出するにあが可能となるように処理するのが望ましい．

たって適していると考えられる．

以上の結果から，予約を受け付ける際には，表 4 に以上の検討結果から，最大同時利用者数は計算機に367挙げた項目を満たす必要があると考えられる．

表4

メモリ量の受入可否を時間毎に計算し，表形式で表示予約を受け付ける際に制限すべき項目

予約受付期間2 週間先まで最大連続利用時間

3 日間同時予約数1件する仕組みを整えた．これによって，GPU サーバのリソースに空きがあれば，利用者が必要な時に必要なリソースを最大限確保可能となる．
最後に，GPU の専有利用について紹介する．3.1 節での検討結果から，GPU のうち，最低 1GPU は共有利用として確保しておく必要がある．本実装では，GPU

4 GPU サーバ予約システムの概要

サーバごとに利用可能な GPU 数を管理するデータ

第 3 章での検討結果から，GPU サーバを効率的にベースを構築し，利用可能な GPU 数が閾値以上であ運用する手法として，GPU サーバの予約システムをれば，専有利用することができるように実装した．具

利用者ポータルに組み込むことにより，利用者が必要体的には，GPU を専有利用する予約処理を利用者がとするリソースを確保する仕組みの構築が必要と考え選択した場合は，データベースの利用可能な GPU 数られる．そこで，実際に 3.1 節で検討した運用設計をが 2 以上となっている期間のみ，予約可能とすること

元に，予約システムの実装を行った．

で，共有利用で使用する GPU を確保する仕組みを整

本章では，実際に実装した予約システムの特徴について説明を行い，実際に利用者に提供する予約画面の一部を紹介する．

えた．

4.2 予約の流れ
利用者は利用者ポータルにログインし，サービス申請欄から GPU サーバの予約ページへ遷移すること

4.1 GPU サーバ予約システムの実装
予約システムを構築するにあたっては，REST APIで，GPU サーバの予約を行うことができる．

を持った Web アプリケーションを，利用者ポータルならびに GPU サーバに実装・配備することで，情報の円滑なやりとりを実現した．また，システム間での情報のやり取りは，基本的に json 形式を用いて行い，多種の情報を一度に送受信するような実装とした．
次に，GPU サーバを運用するにあたって，一番重要と考えたメモリ管理について紹介する．本実装では，GUI アプリケーションの実行リクエストを利用者が GPU サーバへ投入した際に，予約状況ならびに予約として確保したメモリ量を，利用者ポータルからREST API を通して取得する仕組みとした．利用者

図2

リソース予約画面 (リソース指定欄)

ポータルから取得した利用可能なメモリ量は，cgroupの管理コマンドを用いて，アプリケーションの起動前に GPU サーバに設定することで，柔軟かつ確実なメ予約ページは，図 2 のようになっており，利用者はモリ割当を実現した．また，利用時間のコントロール利用したい GPU サーバを選択し，確保するメモリ量については，Linux OS で利用可能な timeout コマンを入力する．また，GPU の専有利用を希望する場合

ドを利用し，引数に利用可能時間 (秒) を渡すことで，は，GPU 欄のドロップダウンリストを専有に変更すアプリケーションが利用予定時間を越えて実行されなることで，専有予約が可能な日程を表示することが可い仕組みを取り入れた．

能となる．

次に，予約について紹介する．本実装では，利用リソースの予約が完了すると，日時を選択する画者が予約システムを用いて予約処理を実行する際に，面に遷移する．日時予約画面を表示する前に，利用者

REST API を用いて GPU サーバに現状の利用者数なポータルと GPU サーバとの間で，現在使われているらびに，メモリの利用状況を確認する．取得した結果リソース量の突き合わせが行われる．その結果とすでと利用者ポータルに登録されている予約内容を突き合に予約されているリソースを鑑み，利用者が希望するわせ，時間ごとに最大となる利用者数ならびにメモリリソースが利用可能な日時には”○”を，利用不可能なの利用量を計算した上で，新規予約希望者が希望する日時には”×”を表示した日程表を 14 日分生成し表示368する．生成された日程表の例を，図 3 に示す．

図5

リソース予約完了画面

5 まとめ
図3

リソース予約画面 (日時指定選択前)

本稿では，GPU サーバの効率的な運用にむけた検討ならびに，予約システムの実装について紹介した．
実際に GPU サーバの運用を開始すると，現時点では表示された日程表から，開始日時と終了日時を選択する仕様とすることで，予約期間外の日時を指定できないように工夫した．これに加えて，開始日時と終了日時を選択すると，予約期間が図 4 のように青く塗られ，予約した期間を利用者が直感的に認識できるよう意図しない問題が多く発生すると考えられる．これらの問題の解消は当然のことながら，利用者の要望ならびに利用実態を元に積極的な改善を進めることで，よりよい可視化環境を利用者に提供できるよう進めていく．に実装した．

参考文献[1] 京都大学学術情報メディアセンター スーパーコ
ンピュータシステム 利用者ポータル

https://web.kudpc.kyoto-u.ac.jp/
portal/(2019 年 8 月 9 日閲覧)
[2] OpenText Exceed onDemand
https://www.macnica.net/opentext/eod.
html(2019 年 8 月 9 日閲覧)
図4[3] Xming

リソース予約画面 (日時指定選択後)

http://www.straightrunning.com/
XmingNotes/
予約開始ならびに終了日時を選択し，利用者が予約確定ボタンを押下すると，予約処理が実行される．予(2019 年 8 月 9 日閲覧)
[4] XQuartz

約処理が正常に終了すると，利用者ポータルの GPU

https://www.xquartz.org/

サーバ予約ページに自動的に遷移し，予約完了の旨と(2019 年 8 月 9 日閲覧)

予約状況が 図 5 のように表示される．

[5] CGROUPS

また，利用者ポータルの GPU サーバ予約ページは，https://www.kernel.org/doc/

表示時間以降の予約がない場合はリソース予約画面

Documentation/cgroup-v1/cgroups.txtとして機能し，表示時間以降の予約がある場合は，予(2019 年 8 月 9 日閲覧)

約情報表示ならびに予約取消を行う画面として機能す[6] VirtualGLるようになっている．これによって，一人の利用者がhttps://www.virtualgl.org重複予約を行うことができないような仕組みとなって(2019 年 8 月 9 日閲覧)[7] 疋田淳一, 當山達也, 尾形幸亮. VirtualGL を用いる．

369

いたリモート可視化環境の改善，AXIES2018，2018．
[8] Out Of Memory Management
https://www.kernel.org/doc/gorman/html/understand/understand016.html(2019 年 8 月 9 日閲覧)
[9] ANSYS System Hardware Requirements
https://www.ozeninc.com/
ansys-system-hardware-requirements/(2019 年 8 月 9 日閲覧)
[10] ENVI System Requirements
https://www.harrisgeospatial.com/docs/
using_envi_PlatformSupportTable.html(2019 年 8 月 9 日閲覧)
[11] System Requirements for MATLAB R2019ahttps://jp.mathworks.com/
support/requirements/
matlab-system-requirements.html(2019 年 8 月 9 日閲覧)
[12] 平島智将, 原田浩睦, 小野真, 上田将嗣, 南里豪志.
可視化サーバ予約システムの導入と運用, AX-IES2015, 2015.
[13] 京都大学情報環境機構 コンピューティングサー
ビス サービスコース選択ガイド

http://www.iimc.kyoto-u.ac.jp/ja/services/comp/apply/guide.html(2019 年 8 月 9 日閲覧)370