豊橋技術科学大学における小規模研究用システムの運用
中村 純哉 1) , 小林 真佐大 1) , 土屋 雅稔 1)1) 豊橋技術科学大学 情報メディア基盤センター{junya, kobayashi, tsuchiya}@imc.tut.ac.jp

Operation of Small Research System for Toyohashi University of Technology
Junya Nakamura1) , Masahiro Kobayashi1) , Masatoshi Tsuchiya1)
1) Information and Media Center, Toyohashi University of Technology

概要
科学研究における大規模計算処理の重要性は，シミュレーションの大規模化 · 高精度化および機械学習への応用という 2 つの要因から，近年ますます拡大している．それに伴って，大規模計算処理を行う研究用システムに対する要求も複雑化しており，多様な計算需要に応えられる柔軟な研究用システムが求められている．そのような研究用システムを実現するには，コンテナ環境と連携し，対話型ジョブに対応したジョブスケジューラと，仮想化アプリケーションの配信システムの 2 点が重要である．本稿では，この 2 点を実装した小規模研究用システムの運用状況について報告する．

ラと，仮想化アプリケーション配信システムによって1 はじめに対応することを提案している [10]．

近年，科学研究における大規模計算処理（High Per-

本稿は，筆者らが提案する小規模研究用システム（以formance Computing; HPC）の役割は，重要になる一下，本システムという）の 2022 年の運用状況につい方である．特に，深層学習を始めとする機械学習の応て報告する．本稿の構成は，以下の通りである．2 節用による影響は大きい．画像生成 [7]，自然言語理解で本システムの概要について説明し，3 節で本システ[4, 2]，ゲーム [3] などの各種の分野において，大規ムの利用状況について考察する．最後に，4 節で結論模な深層学習モデルの利用が広がっている．初期の小を述べる．

規模モデルは研究室規模の計算機環境でも学習できたが，近年の大規模モデルを学習するには，大規模な学2 システム概要

習データを高速に入出力する I/O 性能と，大規模な計

この節では，本システムの概要について説明する．

算を高速に実施する計算能力を兼ね備えた HPC 環境

本システムの概要は，図 1 の通りである．本システが必須である．

ムは，アクセラレータとして GPU を搭載した小規模これらの大規模な計算需要に対応するため，アクセクラスタシステムと，仮想化アプリケーションの配信ラレータとして GPU を搭載したクラスタシステムがシステムからなる．GPU を搭載したクラスタシステ

広く採用されている [11, 1]．このようなシステムでムの利用上の問題点を解決するため，ソフトウェアスは，(1) 従来のソフトウェアスタックと GPU を利用すタックをコンテナ化した上で，計算ノード上の対話型るソフトウェアスタックの性質の相違，(2) ソフトウェジョブとしてソフトウェアの作成を行うという方針でア作成時に利用する GPU に対する排他制御の必要性，設計している．加えて，クラスタシステムでは処理困という 2 つの理由から，従来のクラスタシステムとは難な，GUI によるインタラクティブな処理が重要なソ異なった設計が必要になる．加えて，従来は共用ワー

フトウェアについては，仮想化アプリケーションを配

クステーションを用意していた商用アプリケーション

信 · 提供している．

については，利便性と維持コストの問題から，オンラ2.1 クラスタシステムのハードウェア仕様

インで利用できる環境を整備することが要請されている．これらの課題に対して，筆者らは，コンテナ環境と連携し，対話型ジョブに対応したジョブスケジュー

170

この節では，クラスタシステムのハードウェア仕様について述べる．

サーバ
ネットワークSSH/RDPInfiniBand
ネットワーク
計算ノード
計算ノード
計算ノード
15台
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード
計算ノード

ログイン
ログイン
ログイン
ログイン
ログイン
ログイン
ノード
10台
ログイン
ノード
ログイン
ノード
ログイン
ノード
ノード
ノード
ノード
ノード
ノード

ジョブ実⾏

ファイルアクセス（NFS）

仮想化アプリの取得

MPI通信

ストレージ
システム

ファイルアクセス（Spectrum Scale）

ジョブ
スケジューラ

仮想化アプリ配信システム

ジョブ投⼊

ユーザ情報の参照

コンテナ
レジストリ

コンテナイメージの取得
LDAP/ADサーバ

仮想化基盤

図 1 システム構成

表 1 システム構成

表 3 計算ノード仕様

項目台数

項目

仕様

ログインノード
計算ノード

1015

機種名

DELL PowerEdge R740
Intel Xeon Gold 6132 2.60 GHz 14 コア × 2
NVIDIA Tesla V100 HBM2 16GB × 2
DDR4-2666 192 GiB
256 GiB (RAID 5)
RedHat Enterprise Linux 7
Singularity 3.3.0, Docker 18.09
Intel X710
InﬁniBand EDR

CPUGPU

ログインノード仕様

メモリ
ローカルディスク

項目仕様

OS

機種名

仮想マシン（VMware）

コンテナ環境CPU
GPUIntel Xeon Gold 6148 2.40 GHz 4 コア

NICなし

インターコネクト

メモリ
ローカルディスク

DDR4-2400 8 GiB
200 GiB
CentOS Linux 7

表2OS

表 4 ストレージシステム構成

図 1 に示す通り，クラスタシステムは，ログインノード，計算ノード，インターコネクトおよびストレージシステムからなる標準的な構成である．表 1 に，ログインノードおよび計算ノードの台数を示す．本学では，研究用途だけでなく，UNIX システムの CLI 演習
用途にもログインノードを併用しているため，ログイ項目仕様

ソフトウェア
ファイルシステム
ストレージアレイ
総容量

DDN GridScaler
IBM Spectrum Scale
DDN SFA14KX
2PB
1920 GiB × 13
8 TB NL-SAS × 325 (RAID 6, 8D+2P)
InﬁniBand EDR

SSD
HDD
インターコネクト

ンノードを多数ユーザが同時に利用する状況が想定される．そのため，同等規模のクラスタシステムに比べドを同時に利用した並列演算および高速 · 大規模なて，多数のログインノードを用意している．
ログインノードの仕様を，表 2 に示す．本システ
ムでは，自家製アプリケーションの開発 · デバッグ作

ファイルアクセスの必要性を考慮し，インターコネク
トは InﬁniBand EDR を採用している．

業は，計算ノード上で実行する対話型ジョブによってストレージシステムの仕様を，表 4 に示す．予算上対応する．そのため，ログインノードには，アクセラの制約から，本システムのワーク領域と，本システムレータを搭載しない限定された構成の仮想マシンを採および教育用端末のホーム領域を，同一のストレージ用している．

システム上に確保せざるを得なかった．教育用端末の計算ノードの仕様を，表 3 に示す．大規模な行列ホーム領域については，ユーザが誤って削除したファ演算を行うことを考慮して，アクセラレータとしてイルを救済するため，スナップショット機能が必要でNVIDIA Tesla V100 を搭載している．また，複数ノーある．そのため，スナップショット機能を備えた高速171

並列ファイルシステムとして，IBM Spectrum Scale *1

表 5 キュー構成
教育用

研究用

≤8
≤2
≤ 56
≤4
≤ 384

≤ 336
≤ 13
≤ 364
≤ 26
≤ 2496可有（2 ノード）

不可無を採用している．

2.2 クラスタシステムのキュー構成
この節では，クラスタシステムのジョブを管理する
ジョブスケジューラのキュー構成について述べる．
キュー構成を，表 5 に示す．本システムで用意されているキューは，教育用キューと研究用キューの 2 系

実行時間 [時間]ノード数
CPU コア数
GPU 数
メモリ [GB]
対話型ジョブの可否
予約ノードの有無

統に大別できる．教育用キューは，ログインノードにログインできる利用者全員が，小規模ジョブを投入でを意図している．

きるキューである．それに対して，研究用キューは，2.3 クラスタシステムのコンテナ環境

研究利用登録済み利用者のみが，大規模ジョブを投入できるキューである．

本システムでは，コンテナ環境として Docker[6] とSingularity[5] の両方に対応している．これは，本シス本システムのジョブスケジューラにジョブを投入す

テム設計時（2018 年）におけるコンテナ環境の完成度る時，(1) 当該ジョブの種別（対話型ジョブまたはバッから，片方に限定することは不安がある状況だったこチジョブの別），(2) 当該ジョブを実行するコンテナ環とが理由である．また，本システムで利用できるコン境，(3) 当該ジョブが利用する予定の計算資源，といテナイメージは，専用のコンテナレジストリ（図 1）にう 3 種類の情報の指定を要する．キュー毎に指定で登録されたコンテナイメージに限定しており，ユーザきる 1 ジョブあたり計算資源の上限値を，表 5 に示が作成したコンテナイメージを自由に実行することはす．GPU 数については，CPU コア数等の他の計算資許可していない．この制限は，本システムの設計時に源とは異なり，零の指定も可能である．コンテナ環境

はまだ，マルウェアなどの不正なコードが混入したコと連携し，予約されていない計算資源については，当ンテナイメージでも安全に実行できる機能 *2 が未実装

該ジョブからは参照できないようになっている．よっだったことが理由である．て，CPU を主として利用するジョブと，GPU を主と本システムで利用できるコンテナイメージの内訳として利用するジョブが，1 台の計算ノードを同時に共

概要を，表 6 に示す．本システムには，2022 年 10 月用することも可能である．

現在，68 種類のコンテナイメージがインストールされ本システムでは，自家製アプリケーションの作成作ている．これらのイメージは，(1) NVIDIA NGC *3 で業は，計算ノード上の対話型ジョブとして実行するこ

公開されているコンテナイメージ（33 種類）と，(2)とを想定している．そのため，対話型ジョブは，ジョ管理者が登録したコンテナイメージ（35 種類）の 2 系

ブ投入直後に利用を開始できる必要がある．ただし，

統に大別できる．

対話型ジョブは，ユーザによるコマンド入力待ち時間

2.4 仮想化アプリケーション配信システムが発生するため，計算資源の利用効率は低く，長時間

アプリケーション仮想化の実装としては，Nume-の対話型ジョブにより計算ノードを占有する使い方は

cent Cloudpaging *4 ，Microsoft Application Virtualiza-

好ましくない．つまり，対話型ジョブは，実行時間をtion (App-V) *5 ，VMware ThinApp *6 などがある．この

厳しく制限した上で，ジョブ投入から実行までの待ち中から，本論文の目的と合致する実装として，実行時間を短くすることが適当である．この要請は，クラ端末上の GPU を利用することができる Cloudpaging

スタシステムを用いる演習や講習会におけるジョブとを採用する．Cloudpaging では，アプリケーションは共通している．以上より，本システムでは，第 1 に，対パッケージ化された後，配信サーバを通じて配信さ話型ジョブの実行は，教育用キューのみに制限していれ，実行端末にインストールされた軽量のエージェンる．この制限は，長時間の対話型ジョブを禁止するこトソフトウェアを介して仮想化アプリケーションとしとを意図している．第 2 に，一部の計算ノードを，教て実行される．パッケージ化したアプリケーションの育用キューの予約ノードとして確保し，研究用キューのジョブの実行を禁止している．この制限は，教育用キューおよび対話型ジョブの待ち時間を短縮すること*1 https://www.ibm.com/products/spectrum-scale

172*2 Rootless Docker*3 https://catalog.ngc.nvidia.com/*4 https://www.numecent.com/cloudpaging/*5 https://docs.microsoft.com/ja-jp/windows/
application-management/app-v/appv-for-windows
6* https://www.vmware.com/jp/products/thinapp.html

表 6 コンテナイメージの内訳
分類
ログインノード
科学計算用
並列計算用

CUDAPyTorch
Anaconda
その他
計

種類数

2
16
51312
11968

概要
ログインノードと同等の環境
商用アプリケーションの実行環境
MPI ライブラリを用いた並列計算環境

CUDA ライブラリを用いたプログラムの開発・実行環境
深層学習ライブラリ PyTorch による深層学習環境
科学計算向け Python 実装 Anaconda による開発・実行環境
その他の機械学習ライブラリなど

6000

実行することができ，必要に応じてバックエンドで残5000りのパッケージがダウンロードされる．なお，一度ダウンロードされれば，オフライン環境でも実行可能である．

3 利用状況

総ログイン時間 [h]5%∼10% 程度の容量があれば，アプリケーションを学生
教職員
その他

4000
3000
2000
1000

本システムの仕様策定は，2018 年 4 月から 2019 年

03 月にかけて行った．調達は，予算の制約から分割し1月

2月

3月

4月

5月

6月

7月

8月て実施することになったが，本システムを構成するク
図 2 利用者種別ごとの総ログイン時間の推移

ラスタシステムのほとんどの部分は，2019 年 9 月に運用を開始した．仮想化アプリケーション配信システムについては，2021 年 11 月に運用を開始した．この節

1800
1500

設計方針および仕様の妥当性について検討する．ま1200

た，この節におけるデータの集計期間は 2022 年 1 月

ジョブ数

では，本システムの実際の利用状況を説明した上で，教職員

その他

900から 8 月である．

600

3.1 クラスタシステムの利用状況

300

この節では，クラスタシステムの利用状況について

学⽣

0
1⽉

2⽉

3⽉

4⽉

5⽉

6⽉

7⽉

8⽉

述べる．ログインノードに対する総ログイン時間の推移を図 2 に示す．なお，教育研究目的での利用状況を

図3

利用者種別ごとのジョブ数の推移調査するため，管理者によるログインは除外して集計した．この期間中におけるクラスタシステムの利用者は，学生 394 人，教職員 18 人，その他利用者 5 人，合計 417 人であった．本学では，卒業研究発表会は 12月に，修士論文審査会は 2 月に行われる．図 2 から，総ログイン時間のピークは 1 月と 7 月に観察される．

1 月のピークは修士論文審査会に向けての利用と考えられ，3 月の修了に伴い学生の利用が減少し，その後増加していることがわかる．
同様の傾向は，ジョブの実行状況からも読み取れる．
ジョブ数の推移を図 3 に示す．異常終了したと推定されるジョブを除外するため，実行時間が 5 分以内のジョブは除外して集計した．期間中に実行されたジョブは 27078 件，そのうち集計対象のジョブは 8737 件だった．図 3 より，1 月をピークに 3 月の修了に向け173てジョブ数が減少している様子が見られ，その後増加している．ただし，5 月から 7 月はほぼ横ばいとなっている．また，総ログイン時間の推移（図 2）とジョブ数の推移（図 3）を比較すると，総ログイン時間の推移の内訳は学生が過半数を占めるのに対して，ジョブ数の推移の内訳は教職員が多数を占めることがわかる．特に，この傾向は学生が卒業 · 修了した 4 月以降に顕著である．

3.2 対話型ジョブの利用状況
ジョブ種別と GPU の関係を，図 4 に示す．教育用
キューに投入されたジョブについて観察すると，GPUを必要とする場合は，91% のジョブが対話型ジョブとして実行されていた．それに対して，GPU を必要としない場合は，20% のジョブのみが対話型ジョブとして

100%
1800
1500
ジョブ数

ジョブ数

75%
50%

教育⽤GPUなし

教育⽤GPUあり

研究⽤GPUなし

研究⽤GPUあり

1200
900
600

25%

対話型

バッチ型

300

0%

0

教育⽤GPUなし

図4

教育⽤GPUあり

1⽉

ジョブ種別と GPU の必要性の関係

2⽉

3⽉

4⽉

5⽉

7⽉

8⽉

図 6 キューごとのジョブ数の推移

800

5000
教育⽤4000

教育⽤GPUあり

研究⽤

600

3000

ジョブ数

ジョブ数

6⽉

2000

研究⽤GPUあり

400
200

1000
00〜1

1〜6060〜720 720〜1440

01440〜1

キュー待ち時間 [min]図5

図7

ジョブ種別と待ち時間の関係

2
GPU数

3以上

要求 GPU 数の分布実行されていた．このように，短時間ジョブの実行状が多数を占めるのに対して，3 月以降は教職員の利用

況において，GPU を必要とする場合と GPU を必要とが過半数を占めるのがわかる．したがって，次に GPUしない場合を比較すると，対話型ジョブの出現率に顕の利用が活発になるのは卒業研究が活発になる 10 月

著な違いがある．これは，GPU を利用する自家製アプから 12 月であると考えられる．

リケーションの大部分がスクリプト言語によって作成

3.4 プログラムの並列化状況されており，開発 · デバッグ作業のために，実際の実GPU を要求しているジョブを対象として，要求 GPU行環境と同一の環境を必要とするためと解釈できる．

数によってジョブを分類した結果を，図 7 に示す．図 7

ジョブ種別とキューに投入されてから実行開始までより，ジョブが要求する GPU 数は 1 基か 2 基のみでの待ち時間の関係を，図 5 に示す．教育用キューにあり，3 基以上は存在しないことがわかる．表 3 に示投入されたジョブについて見ると，99% のジョブは，す通り，本システムの計算ノードはノードあたり 2 基

キューに投入されてから実行開始までの待ち時間が 1の GPU を搭載している．近年の GPU 向けフレーム分未満だった．これは，教育用キューの待ち時間を短ワーク層の多くはノード内の複数 GPU に対応してい縮するために，予約ノードを用意した方針（2.2 節）のるため，利用者は特別な対応をすることなく自然に，妥当性を示している．

ノード内の複数 GPU を利用した並列化が利用できる．

3.3 GPU の利用状況

しかし，複数ノードにまたがる GPU の並列化につい

教育用キューと研究用キューに投入されたジョブをては，本論文の執筆時点において，フレームワーク層対象として，GPU の要不要に基づいて分類した場合によるサポートは充実していない．図 7 は，上記のよのジョブ数の推移を図 6 に示す．図 6 から，1 月と 2

うな GPU 向けフレームワーク層の状況を反映してい月には，研究用に GPU が利用されているが，それ以ると考えられる．

降の月ではほぼ利用されていないことがわかる．これ要求ノード数によってジョブを分類した結果を図 8

は，学生が 2 月の修士論文審査会に向けて GPU を利に，要求 CPU コア数によってジョブを分類した結果用していたが，3 月の修了に伴い GPU の利用者がいなを図 9 に示す．図 8 より，複数の計算ノードにまたがくなったためであると考えられる．実際，図 3 のジョる並列化を行っている利用者は，非常に限られている

ブ数の推移の内訳を見ると，1 月と 2 月は学生の利用ことがわかる．同様の傾向は，図 9 からも確認できる．

174

10000100%

ジョブ数8000コンテナイメージ利⽤⽐率

教育⽤GPUなし
教育⽤GPUあり
研究⽤GPUなし

6000

研究⽤GPUあり

4000
2000
01

科学計算⽤
並列計算⽤

50%

PyTorchCUDA

25%

Anaconda
その他

0%

2以上

GPUなし

ノード数

図8

ログインノード
75%

要求ノード数の分布

図 11GPUあり

コンテナイメージの利用率

6000
教育⽤GPUなし
ジョブ数

4500
3000

教育⽤GPUあり

図 9 から，CPU コアを 1 つしか使わないジョブが多研究⽤GPUなし

数実行されていることがわかる．そこで，1 コアのみ研究⽤GPUあり利用しているジョブを対象として，経過時間によって1500ジョブを分類した結果を，図 10 に示す．図 10 より，CPU コアを 1 つしか使わないジョブは，その経過時間0
12

3〜4

5〜8

9〜14 15〜28 29〜もきわめて短いことがわかる．利用者に利用状況をヒCPUコア数

アリングしたところ，多数のファイルを対象として集図 9 要求 CPU コア数の分布計を行う実験を行っており，対象となるファイル集合を保持しているマスタージョブと，ファイルごとの集4000

ジョブ数

3000

教育⽤GPUなし

計処理を行うスレーブジョブからなる，マスター · ス

教育⽤GPUありレーブ型の並列化をジョブスケジューラを利用して実研究⽤GPUなし
2000現しているという回答を得た．このような I/O 集約的研究⽤GPUありな処理は，Hadoop などの専用フレームワークを利用
1000することが多いが [9, 8]，高性能な並列ファイルシス
テムと汎用ジョブスケジューラの組み合わせも有効で

0〜1

1〜2

2〜4

4〜8

8〜16 16〜32 32〜あることが判明した．

経過時間 [h]3.5 コンテナの利用状況
図 10 CPU コアを 1 つしか利用しないジョブの経本システムでは，ジョブの種別に関係なく，全ての過時間の分布ジョブはコンテナ環境で実行される．ジョブが参照しているコンテナの比率を，図 11 に示す． 本システム

表 3 に示す通り，本システムの計算ノードはノードあでは，2022 年 10 月現在，68 種類のコンテナイメージ

たり 28 コアを有しているが，複数ノードを同時に確が利用できるが（表 6），図 11 は，それらのコンテナ保する必要がある 29 コア以上の CPU コアを要求してイメージを機能別に分類した結果である．

いるジョブは 0.4% しかない．なお，ノード内の複数

図 11 から，GPU を利用しないジョブの場合，ロCPU コアを用いた並列化を行っているジョブ（すなわ

グインノードと同様の環境を提供するためのログイ

ち，2 ∼ 28 コアを要求しているジョブ）は，41% でンノード相当のコンテナが 50% 利用されていることある．よって，本システムにおいては，ノード内でのがわかる．このジョブの多くは，I/O 集約的なジョブ

CPU の並列化はある程度利用されているものの，複（3.4 節）であり，ログインノード上で作成したソース数ノードにまたがる CPU の並列化は，ほとんど利用を，そのまま計算ノード上で実行する使い方をしていされていないことがわかる．したがって，複数の計算る． 2.1 節で述べた通り，本システムのログインノーノードにまたがる並列化を想定した設計方針を改める

ドは，仮想化基盤上の仮想マシンであり，ストレージか，または，複数の計算ノードにまたがる並列化を行システムに対するファイルアクセスはイーサネットをえるように利用者支援を充実するか，どちらかの対応

経由した NFS プロトコルで行われる．それに対して，が必要と考えられる．

計算ノード上でバッチジョブとして実行した場合は，

175

コンテナイメージ利⽤⽐率

コンテナイメージ利⽤⽐率

100%
80%
60%
40%20%0%
1⽉
ログインノード
PyTorch
その他

2⽉

3⽉

4⽉

科学計算⽤
CUDA

5⽉

6⽉

7⽉

100%
80%60%
40%20%0%

8⽉

1⽉

並列計算⽤
Anaconda

2⽉

ログインノード
PyTorchその他

図 12 コンテナイメージ利用率の推移（GPU なし）

図 13

3⽉

4⽉

科学計算⽤
CUDA

5⽉

6⽉

7⽉

8⽉

並列計算⽤
Anaconda

コンテナイメージの利用率の推移（GPU あり）

100%
80%
ジョブ割合

ファイルアクセスは InﬁniBand を経由した Spectrum

Scale プロトコルで行われる．そのため，I/O 集約的な処理を実行するには，計算ノード上でバッチジョブと60%40%20%して実行することが有利である．また，本システムで0%は計算資源として GPU を確保することなくジョブを2〜3実行することができるため（2.2 節），このような使い

4602281619〜6〜9〜13264
8〜0〜
96
12
162〜19要求メモリ容量 [GiB]

方によって計算資源が無駄になることはない． 商用ア
0〜20%

プリケーションがインストールされている科学計算用
コンテナは 45%，MPI ライブラリがインストールされ20〜40%

40〜60%

60〜80%

80〜100%

図 14 ジョブごとのメモリ利用状況ている並列計算用コンテナは 2% 利用されている．
図 12 および図 13 に，それぞれのコンテナイメージの利用割合の推移を示す．利用頻度の高いイメージは

3.6 メモリの利用状況常に同じではなく，時期によって使われるイメージはジョブ投入時に利用者が要求したメモリ容量と，実大きく異なることがわかる．特に GPU ありキューの際に利用されたメモリ容量の関係を，図 14 に示す．図移り変わりは大きい．期間前半は PyTorch が主に利用

では，要求メモリ容量に対する利用メモリ容量の割合されていたが，期間後半は科学計算用やその他イメー（以下，実利用割合という）によってジョブを 20% ごジの利用頻度が増している．本学は小規模大学であとに 5 つのクラスに分類し，各クラスが全体に占めるるために，このように時期によって利用者の需要が変割合を示した．図 14 から，要求メモリ容量が 32 GiBわってしまうと考えられる．

以下の場合は，要求したメモリ容量と実際に利用さ図 11 から，GPU を利用するジョブの場合，PyTorchれた容量の一致度が高く，適切に計算資源を利用できがインストールされているコンテナが 87% 利用されていることがわかる．一方で，64 GiB, 128 GiB，196ており，最も利用率が高い．また，ライブラリ層のみGiB など，切りの良い要求メモリ容量において，実利がインストールされている CUDA コンテナは 4% 利用割合の低いジョブが増加する傾向が見られる．これ用されている．CUDA コンテナの利用者は，フレーは実行するジョブの傾向に基づいて利用者が適切に要ムワーク層およびアプリケーション層を各自の領域に求メモリ容量を調整せずに，サンプルコードなどの記独自にインストールする必要があるが，フレームワー載をそのまま流用したためと考えられる．なかでも，ク層およびアプリケーション層を自由に選択できる．

192 GiB を指定して実行されるジョブが多く，全ジョPython では，そのためのモジュール（venv）が用意さブの約 5% を占めた．図 5 に見られるように，集計期れているため，そのような使い方も比較的容易である．

間中の待ち時間は短かったため大きな問題とはならな

このように，コンテナ技術の導入によって，利用者各いが，利用者が増え多くのジョブが投入されるように自が必要とするソフトウェアスタックを柔軟に利用でなると，非効率な計算資源の指定はジョブの待ち時間きていることがわかる．

を増加させ，利用者も不満を持つ．そのような場合に

176

700

境が必要であり，かつ，開発用 GPU の排他制御が必

総実行時間 [h]ANSYS HFSS600

ANSYS Multiphysics

要となるため，ログインノード上ではなく，計算ノー

500

COMSOL Multiphysics

ド上の対話型ジョブとして実行するように設計した．

Materials Studio
400

参考文献

300

[1] TSUBAME3.0 ハードウェアおよびソフトウェア

200の仕様, 2019. https://www.gsic.titech.ac.

100

jp/sites/default/files/spec30j.pdf.

0
1月

2月

3月

4月

5月

6月

7月

[2] T. Brown, et al. Language models are few-shot

8月

learners. In Advances in Neural Information Pro図 15

アプリケーションごとの総実行時間の推移

cessing Systems, Vol. 33, pp. 1877–1901, 2020.
[3] Y. Chen, A. Huang, Z. Wang, I. Antonoglou,

は，投入したジョブの実利用割合を利用者にフィード

J. Schrittwieser, D. Silver, and N. de Freitas.

バックしたり，実利用割合が低い利用者に何らかのペ

Bayesian optimization in AlphaGo, 2018.

ナルティを課すなど，今後何らかの検討が必要となる[4] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova.と予想される．

BERT: Pre-training of deep bidirectional trans-3.7 仮想化アプリケーション配信システムの利用状況

formers for language understanding. In Proc. of

この節では，仮想化アプリケーション配信システ

NAACL-HLT2019, Vol. 1, pp. 4171–4186, 2019.

ム（以下，配信システムという）の利用状況について[5] G. M. Kurtzer, V. Sochat, and M. W. Bauer. Sin-

述べる．配信しているアプリケーションは，ANSYS

gularity: Scientiﬁc containers for mobility of com-

HFSS，ANSYS Multiphysics，COMSOL Multiphysics，

pute. PLOS ONE, 12(5):1–20, 05 2017.

Materials Studio の 4 種類である．図 15 にアプリケー[6] D. Merkel. Docker: lightweight linux containers

ションごとの配信システムの総実行時間を示す．なfor consistent development and deployment. Linux

お，実行時間が 0 秒のデータに関しては集計から除外

Journal, 239(2):2, 2014.

した．図 15 より，総実行時間は 5 月の利用が最も少な[7] A. Ramesh, P. Dhariwal, A. Nichol, C. Chu, andく，逆に 8 月の実行時間が他の月に比べて 2 倍以上にM. Chen. Hierarchical text-conditional image gen-多いことがわかる．また，利用されたアプリケーショ

eration with CLIP latents, 2022.

ンは ANSYS Multiphysics と COMSOL Multiphysics[8] 土屋. HPC クラスタシステム上で動作する仮想に集中している．基本的には，毎月一定時間実行さマシンを用いた Hadoop クラスタの構築. 情報処れている．したがって，端末室ではなく研究室などの理学会研究報告, 第 2013–HPC141–9 巻, pp. 1–4,ユーザの端末上で実行が可能な配信システムは有用で2013.

あると考えられる．今後は，配信する商用アプリケー[9] 土屋. IaaS 基盤としても利用できる HPC クラスションの種類を充実させていくことを検討している．

タシステムの構築. 第 3 回地域間インタークラウ

また，商用アプリケーションとクラスタシステムの連

ドワークショップ, 2013.

携についても，利用者の状況変化に応じて実装してい[10] 土屋, 中村, 小林. 多様なジョブ類型を考慮した小規模研究用システムの構築と運用. 学術情報処理

く予定である．

研究, 25, 2022.

4 むすびに[11] 小川, 松岡, 佐藤, 高野, 滝澤, 谷村, 三浦, 関口. 世

本論文では，商用アプリケーションおよび自家製ア界最大規模のオープン AI インフラストラクチャ

プリケーションを含む多様なジョブ類型を考慮した小AI 橋渡しクラウド（ABCI）の概要. 情報処理学

規模研究用システムの 2022 年の利用状況について報会研究報告, 第 2018-HPC-165 巻, pp. 1–7, 2018.

告した．本システムは，アクセラレータとして GPU を搭載したクラスタシステムと，仮想化アプリケーションの配信システムからなる．自家製アプリケーションの作成 · デバッグにあたっては，実行環境と同一の環

177