学内インフラとしてのスパコンの対話的利用による利便性向上
安良岡 由規 1) , 野村 哲弘 2) , 遠藤 敏夫 2)
1) 東京工業大学 オープンファシリティセンター
2) 東京工業大学 学術国際情報センター
yyasurao@o.cc.titech.ac.jp

Usability Improvement in Interactive Use of Supercomputer as
University Infrastructure
Yoshinori Yasuraoka1) , Akihiro Nomura2) , Toshio Endo2)
1) Open Facility Center, Tokyo Institute of Technology
2) Global Scientiﬁc Information and Computing Center, Tokyo Institute of Technology

概要
東京工業大学の TSUBAME3 では，ノード使用率の上昇によるノード枯渇のためにビジュアライズやデバッグ等のインタラクティブな利用が困難な状況となっていた．本稿ではインタラクティブ利用ユーザやスパコン初心者に対する利便性向上施策として行った 1) インタラクティブジョブ実行専用キューの創設 2) 利用者ポータル経由でのSSH 等を経由しない Web アプリケーション (Jupyter Lab 等) 実行基盤の構築 について報告する．
Ꮫෆʀ㻿㻵㻺㻱㼀㻡 ΃㻝㻜㻜㻳㼎㼜ંକ

1 背景
東京工業大学学術国際情報センター (以下，「本センター」という) では，「みんなのスパコン」を合言葉とし，使いやすさと高性能を両立したスーパーコンピュータ

TSUBAME シリーズを構築・運用しており，2017 年
8 月からは現行の TSUBAME3.0 [1] [2] [3] を供用しϓϫϱφΦϱχϋρφϭʖέExtreme Networks Black Diamond X8
ΰʖφ
ΤΥ΢
γʖώ

؇ཀྵϋρφϭʖέ Extreme Networks Summit X450
‫ࢋܯ‬όʖχ
SGI ICE XA
12.1 PFlops
㻡㻠㻜όʖχ

߶ଐηφϪʖζ㻰㻰㻺㻌㻿㻲㻭㻝㻠㻷㼄㻱㻗㻌㻱㼤㼍㻿㼏㼍㼘㼑㼞㻔㻸㼡㼟㼠㼞㼑㻕㻔㻡㻼㻮㻌㼤㻌㻟㻕

ϙʖϞ྘Ү
DDN
GridScaler

ӣ༽؇ཀྵ
γʖώ

૮‫߻݃ޕ‬໤ Intel Omni-Path Full Bisec!on

図 1 TSUBAME3.0 全体構成ている．2006 年に導入された TSUBAME シリーズの初代である TSUBAME1.0 以来，TSUBAME は学内外で約 2,000 名のユーザ（2019 年度 SSH ログイン

GPU 間相互結合網である NV-Link などを活用し，高ユーザ数）に利用されるシステムとなっている．

度に最適化されたプログラムに対しては有効ではある

TSUBAME3.0 [4] の全体構成は図 1 に示す通りでが，単一の GPU や CPU のみを想定したプログラム

あり，540 台の計算ノードと各種ストレージおよびそでは，ノード性能の大半を持て余してしまうことから，

れらを高速に結合する OmniPath による相互結合網

図 3 に示すようにジョブスケジューラである Univaなどからなる．

Grid Engine [5](以下，「UGE」という) 経由で Linux

全ての計算ノードは，フルバイセクション・ファッ
トツリートポロジで接続されており，任意の計算ノー

cgroups を活用したノード分割を積極的に行うことで，有休資源の最小化に努めている．

ドから任意の計算ノードおよびストレージサーバにこのような努力にもかかわらず，近年の「京」コン

ポート当たり 100Gbps のスピードで接続することがピュータからスーパーコンピュータ「富岳」への移行

できる．

期に伴う HPCI 課題などの学内外の計算需要の高まり

ノード構成は図 2 に示すとおりであり，1 ノードあを受けて，TSUBAME3.0 の利用率は図 4 に示すようたり 4 つの GPU，4 つの OmniPath HFI が接続されに，年度全体で 80% 超，最繁忙期では 96% を上回るている非常に大きなノードとなっている．このように非常に高い水準で推移している [6]．このようなジョ

複数の GPU 等を擁する巨大なノードは，ノード内のブの滞留傾向により，TSUBAME3.0 ではジョブの投入から実行開始までに 24 時間以上の待ち時間がかかは，計算ノードを全てバッチジョブに配分し，ログイ
ンノードは計算ノード群の外に，GPU を備えない比較的非力なノードを 2 台のみ設置し，ユーザには高負荷処理をログインノード上で行わないようアナウンスする [8] など，インタラクティブ処理の需要に十分に応えられていない実情があった．

14 cores

本 報 告 で は ，こ の よ う な 状 況 を 鑑 み て ，TSUB-

AME3.0 において 2020 年初頭に導入したインタラ
クティブジョブ実行専用キューおよび Web アプリ
14 cores

ケーション実行基盤について，その設計および実装を示すとともに，制約や問題点についても共有する．

2 インタラクティブジョブ実行専用キュー
図 2 TSUBAME3.0 計算ノードのブロックダイアグラム

2.1

従来のインタラクティブジョブ実現方法

従来，インタラクティブジョブはバッチジョブの特

GPU
GPU

OPA
HFI
CPU 14αΠOPA
HFI

別な形として，ジョブ実行中のノードへの ssh 接続を許可する，もしくはジョブ実行時のターミナルをH確保した計算ノードに接続する形で提供されてきた．

TSUBAME3.0 における UGE においても qrsh コマ
F

GPU

7αΠ

CPU
GPU

2αΠ
4αΠ

OPA
HFI
OPA
HFI

Q

ンドおよび，スケジューラへの-now オプションによって，確保した計算ノードへの接続や，即時に実行されず，実行キューで待ち状態になったジョブの自動キャ

G
C4

図 3 TSUBAME3.0 計算ノードの資源分割イメージ

ンセルが行われ，またノードの資源分割を行わなかった場合には，ジョブ実行期間中のみログインノードから各計算ノードへの ssh を許可することで，このようなインタラクティブ操作の機能を提供してきた．
しかし，このような形で提供されるインタラクティ

り，デバッグや計算結果のビジュアライズなどのインブジョブも，ジョブスケジューラの観点からは単なる

タラクティブ処理を満足に行うことができない状態がバッチジョブの一類型に過ぎず，システムの混雑時に続いていた．

はまとまったノード時間を即時に確保することは難一方で，インタラクティブ処理の需要は従来のデ

しく，ジョブをキューに入れて数時間後に実行が開始

バッグや計算結果のビジュアライズだけではなく，IoTするまで待たされるなど，インタラクティブな操作が分野におけるセンサデータ類のオンタイム処理や，AIできるまでの待ち時間が許容できない状況となって分野を中心に広く用いられている Jupyter Lab [7] ないた．

どの統合開発環境経由での利用など，広がりを見せて

2.2

おり，大学における「みんなのスパコン」としてユーザ層を拡げていくうえでは解決が必須な課題である．
先代の TSUBAME2.0/2.5 においては，外部からバッチジョブおよびインタラクティブジョブの特性

通常のバッチジョブとインタラクティブジョブでは，求められるジョブの特性が異なる．

ssh を受け付けるログイン用の計算機はインタラク

通常のバッチジョブでは，確保した計算資源を安定

ティブノードと呼ばれる，計算ノードと同一構成のして最大限に活用できるよう，ジョブが開始した後はノードを 20 台割り当て，ロードバランサ経由で割り外乱がなくノード性能の 100% がジョブに費やされ，当てることで，ログイン用ノードとインタラクティ

同じワークロードであれば同じ経過時間 (≃ 課金額)

ブ処理用ノードを兼ねさせる形にすることで，この問で終了することが期待される一方で，ジョブが投入さ題に対応してきた．一方で，計算ノード数が TSUB-

れてから即時に実行されることは，望ましい性質ではAME2.0/2.5 の約 40% しかない TSUBAME3.0 であるものの混雑時には実現不可能であり，ユーザから

図 4 TSUBAME3.0 計算ノード利用率 (2019 年度) 黄色はメンテナンス期間

も前者の性質ほどには期待されていない．
他方，インタラクティブ処理においては，ユーザの操作 (ジョブの投入やコンソールでの入力) に対して，即時に反応が返ってくることが重要である一方，計算リソースの使用は間欠的であり，計算ノードを占有していたとしてもその大半の時間はユーザの操
作待ちのアイドル時間というジョブが多く，前章のTSUBAME2.0/2.5 におけるインタラクティブノード
の例のように，他のインタラクティブジョブと資源を共有しても問題にならない．
このような差異は，計算資源に余裕があるうちは両者の性質が同時に満たされるために顕在化しないが，計算資源が逼迫してくるに従って，従来のシステムではインタラクティブジョブを通常のバッチジョブと同じ方法でスケジューリングした結果，インタラクティ
ブジョブを実質的に利用できない状況に陥った．

2.3

インタラクティブジョブ実行専用キューの設計

前節のような検討の結果，インタラクティブジョブ

下の方針でインタラクティブジョブ実行専用キューを設計した．

• インタラクティブジョブ実行専用に計算ノードを切り出し，バッチジョブ用とは独立したキューを構成する• インタラクティブジョブ実行専用ノードでは多数のジョブが 1 ノード内で同時に実行される (オーバーコミット状態)• 1 つのインタラクティブジョブがノードの全資源を使いつくさないよう，ジョブ当たりの利用可能
資源量に制限をかける• 1 ユーザあたり同時に投入・実行可能なインタラ
クティブジョブ数は 1 に制限する• インタラクティブジョブに対しては性能の保証を一切行わない• 試行期間中はインタラクティブジョブ実行専用
キューに対して課金を行わないの実行に求められる最高優先度の要件は，実行要求時

上記指針に基づき，UGE 上で通常のバッチジョブに即時に実行されることであり，この実現のためには，用のキュー (all.q) とは別のキュー interactive.q

システム内にインタラクティブジョブ実行のための計を作成し，540 ノード中，4 ノードを interactive.q

算資源を常時確保しておくことが必要となった．他方に移動した．interactive.q においては，ノードを論

で，インタラクティブジョブ同士は資源の共有を行っ

理分割し，図 3 における Q 相当の論理ノードが 16 台，ても問題にならず，少数の計算ノードで多数のインタ

各論理ノードにつき最大 7 ジョブのインタラクティ

ラクティブジョブを処理することは現実的である．そブジョブが実行されるよう設定した．なお，7 ジョブ

こで，本センターでは 50 人〜100 人規模の計算科学・の制限は，UGE におけるジョブスケジューリング計

高性能計算に関する講義・実習時に受講者が同時にイ

算時に CPU コアを 1 コア以上占有することが必要

ンタラクティブジョブを利用できることを目標に，以であったための，実装上の制約から来たものである．

各論理ノードにおけるリソース制限は，従来と同様になっている．

cgroups で行い，同じ論理ノードで実行される最大 7

今回，性能保証を行わないサービスにおける課金ポ

ジョブが 7CPU コア (Hyper-Threading を含めるとリシの策定が間に合わず，学内ユーザ限定の試行とい14 論理コア)，1GPU を共有する．

う形で導入したが，今後は利用状況の詳細な把握を行

ジョブの最大実行時間は 24 時間とし，長時間のイ

い，課金モデルの設計をすすめ，学外からの利用者にンタラクティブ処理をジョブ中断によるストレスなく向けての開放の是非についても議論する予定である．

実施できるようにするとともに，ジョブの終了忘れに

͹΄ཤ༽਼

500

よる残留が長期間にわたって発生することがないよう
にした．

400
350

CPU メモリに関してはプロセッサコアと違い時分300
਼݇

割で共有することができないため，1 ジョブ当たりの

ཤ༽਼

450

CPU メモリ使用量を 60GB に制限した．通常のバッ

250
200
150

チジョブ用のノードでは性能低下につながるためス100

ワップファイルを用いていないが，インタラクティブ

500

ジョブ用のノードにおいてはメモリ需要が逼迫するこ

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23࣎ࠃ

とを想定し，ノードのローカル SSD の大部分 (1.5TB)をスワップファイルに廻すことで使用メモリ量の増大

図 5 インタラクティブジョブ実行専用キューの時に備えた．なお，実際にすべてのジョブがメモリを最間帯別利用数 (2020 年 4 月から 8 月合計)

大量まで使うことは想定しておらず，利用者数が少な
い間はスワップ領域の利用による性能低下は起こらな
いと期待している．
他方で，GPU メモリに関しては現時点のシステム
ソフトウェアおよびプログラムの書かれ方では，ジョ3 Web アプリケーション実行機能
3.1

Linux 初心者がスパコン利用で求められる前提
知識

ブ当たりのメモリ量を制限したりスワップデバイスに

TSUBAME3.0 を含む現在の Linux ベースのスパ

退避したりすることが現実的ではなく，「早い者勝ち」

コンの利用のためには，以下のような膨大な前提知識という状況になっており，今後必要に応じて制約手法が要求され，このことが今まで Linux を利用していなを検討する必要がある課題となっている．

かった初学者および非 HPC ユーザの参入障壁となっ

2.4 利用状況ている．

2019 年 11 月にインタラクティブジョブ実行専用
キューの試行サービスを学内ユーザに向けて開始し，• cd, mv 等の Linux の基礎的なコマンド

2019 年度中は 54 名，2020 年 4 月から 8 月の期間は• SSH クライアント・ターミナルのインストールお188 名の利用があった．これは同期間の TSUBAME
利用歴のあるユーザ数のそれぞれ 2.6%，17.3% に相当し，2020 年度になってから利用者が急増しているこ

よび操作法• SSH 公開鍵認証方式および鍵ペアの作成・管理・
アップロードとがわかる．利用者増加の主因は，高性能計算に関す• ジョブスケジューラの概念・ジョブスクリプトる講義が同期間に行われ，講義内で本機能についての• 実際に動かしたいドメイン・アプリの知識紹介が行われたことと考えられ，ノードの混雑期であ

このうち，最後のアプリケーション自体の知識以外

る 2019 年度末以上の伸びを見せていることがわかる．

は，長期的に知っておくことが望ましい内容ではある

図 5 にインタラクティブジョブ実行専用キューの時が，本来のスパコン利用においては枝葉末節にあたり，間帯別の利用回数 (2020 年 4 月から 8 月合計) を示す．

これらをいかに簡便にできるかが「みんなのスパコン」

講義が行われた 10 時，11 時に利用が集中しているもとしての裾野の広さに直結する．

のの，それ以外の時間帯でも終日利用があることから加えて，ビジュアライズを行う X アプリケーション

一般の利用者にも利用されており，授業の実施以外のにおいては，ローカル X Window System サーバおよ用途にも有効に利用されうることが期待される．今後

び X 転送，Jupyter Lab のような Web ベースのアプ機能の存在をいかに利用者にアピールするかが課題とリケーションでは，SSH のポートフォワーディングに関する知識も要求されるようになり，そのハードルはクタの専用 URL を提示し，ユーザが中継コネクタにア

さらに大きなものとなってしまう．

クセスすることで，中継コネクタが HTTPS Reverse

3.2

プロトタイプ: jupyterrun スクリプト

Proxy として動作し，計算ノード内のジョブで動作す

本センターでは，2019 年 6 月に，Jupyter Note-book の 計 算 ノ ー ド で の 利 用 法 を 例 示 す る た め に ，jupyterrun というスクリプトを作成し，公開した [9]．
本ツールはコマンド本体とそこから起動されるジョブ
スクリプトの 2 つのスクリプトからなり，後者のスクリプトで Jupyter Notebook を起動しつつ，そこへのる Web アプリケーションに外部ネットワークからアクセスすることができるようになる．
:HE१‫ش‬অ५ਹ৷ਭહ
:HE१‫ش‬অ५भକ৿ "
:HE॔উজॣ‫ش‬३ঙথॖথॱছॡॸॕঈਹ৷௧৷य़গ‫ش‬

接続に必要なポートフォワーディングオプションを含ਹ৷ৎ৑めた TSUBAME3.0 への ssh コマンドを表示し，ユーથ೥१‫ش‬অ५ਹ৷

ザに別ターミナルから当該 ssh コマンドの実行を促すॢঝ‫ش‬উ৭උ

だけのものであった．しかしながら，Web 上にはスパৢଞঀ‫ॻش‬ਹ৷

コン上での Jupyter Notebook(もしくは Jupyer Lab)

ৱ౺ॱॖউ
ਹ৷ৎ৑

の起動方法に関する公式 [10] もしくはユーザ作成の非੒৺ঀ‫ॻش‬ਹ৷

公式な記事が林立しており，このような知識に関する$5,'

需要がかなり大きいことがうかがえる．

3.3

ৱ౺ॱॖউ

設計

ਹ৷ৎ৑

前節の jupyterrun スクリプトでは，Linux のコマ

उ૥खਹ৷

ンド操作や SSH 関係についてはユーザの習熟を要す

ৱ౺ॱॖউ

るものであった．そこで我々は，対象 Web アプリケー
ション (Jupyter Lab を想定) の起動から終了までをਹ৷ৎ৑ঀ‫ॻش‬ન৳ଷ૷ৎ

य़কথ७ঝ૬ऎऽदୄਃ

全てブラウザ上の TSUBAME 利用者ポータル上の操図 7 Web アプリケーション起動画面

作で完結させることを目標に，Web アプリケーション
実行機能を設計した．
ʴϛʖνϩʵ
-XS\WHUཤ༽ण෉
ંକ85/3257఑ࣖ

768%$0(ཤ༽ंϛʖνϩ
‫ع‬ଚʀ8,ࡠ੔γʖϑηʀώρέΦϱχ
ॴཀྵ͹ࣰߨͳয়ସ؄ࢻ
ᶆγʖϑηًಊғབᶋγʖϑη६ඍ‫׮‬྅γʖϑηαϱφϫʖϧ

図 6 に Web アプリケーション起動画面のイメージを示す．ここでは，利用する Web アプリケーション
イメージ (本稿執筆時点では Jupyter Lab のみ) および，ジョブ作成時に qsub コマンドもしくはジョブスᶈًಊ‫׮‬྅Ϥʖδ஦‫ܩ‬αϋέν

5HYHUVH3UR[\‫ࢋܯ‬όʖχ৏Ͳًಊ͢ͱ͏Ζ-XS\WHU /DE΃௪৶஦‫ܩ‬ᶇζϥϔًಊ

‫ࢋܯ‬όʖχ-XS\WHU

ʴ768%$0(‫ࢋܯ‬όʖχʵ
-XS\WHU /DEΝࣰߨͤΖζϥϔΝًಊ

図 6 Web アプリケーション実行機能の構成

クリプトのオプションで指定する各種パラメータを設定できる．ジョブは本報告の前半で導入したインタラ
クティブジョブ実行専用キューでも実行することができる．
インタラクティブジョブ実行専用キューを用いない

図 6 に Web アプリケーション実行機能の全体像を場合は，(論理) ノードを占有できるのでより安定した示す．図中のサービスコントローラ，中継コネクタ

性能を期待できる一方で，混雑時にはジョブの実行開の 2 つが本機能の実装のために新たに作成したコン

始まで待ちが発生することが起こりうる．待ち時間がポーネントであり，TSUBAME 管理ネットワークお発生したときにジョブを継続すべきかどうかは利用者

よび外部ネットワークに接続された専用ノードで動作の状況によって異なるため，起動画面の最下部のオプ

する．ユーザが利用者ポータル上で Web アプリケー

ションによって待ち発生時の動作を選択できるようにションの起動を指示すると，その情報はサービスコン

した．(UGE の qsub の-now y オプションに相当)

トローラに引き継がれ，スケジューラ経由で計算ノー

3.4

Jupyter Lab の機能と制約事項

ド上に専用のジョブを起動し，ジョブの起動を受けてJupyter Notebook の発展形である Jupyter Lab で中継コネクタ内にジョブと HTTP ポートのマッピン

は，ノートブック形式で Python を対話的に利用す

グを作成する．利用者にはジョブに対応する中継コネ

ることに加えて，簡易的なファイルブラウザおよびLinux のコマンドラインシェルを起動する機能も備え利用者にも有効であることが示された．

ている．このため，Web アプリケーション実行機能でまた，Web アプリケーション実行機能の約 8 割がイ起動する Jupyter Lab を SSH およびローカルの端末

ンタラクティブ専用キューに投入されていた．インタ

エミュレータの代替として利用することができる．

ラクティブ専用キューにおける Web アプリケーショ

Jupyter Lab(および Notebook) で利用する Python

ン利用の占める割合は約 3 割となった．

カーネルは，原則的に Jupyter Lab を起動する際に

͹΄ཤ༽਼

250

ཤ༽਼

利用した Python の環境を継承する．TSUBAME3.0
では CUDA を含む各種ライブラリは Environment

200

Modules(module コマンド) で明示的に読み込む設計

150
਼݇

となっており，Jupyter Lab 起動時の環境では CUDA
等のライブラリへのパスが通っておらず，CuPy など

100の GPU を利用する機械学習関連パッケージの利用50ができない．このため，Jupyter Notebook から利用
0

できる t3jpttools Python モジュールを提供し，こ0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
࣎ࠃ

の中で各種ライブラリの Environment module を指定して読み込んだ Python カーネルを定義できるよ

図 8 Web アプリケーション実行機能の時間帯別利

うにした．CUDA ライブラリへのパスが通っている

用数 (2020 年 4 月から 8 月合計)

Python 環境において，Jupyter Notebook のシェルエ
スケープなどを経由して pip コマンドを実行すること
で，CuPy などのサードパーティの Python モジュー
ルをインストールすることができる．

Python の 実 行 環 境 は ，virtualenv, pyenv, Anaconda など様々な手段で作成され利用されているが，

3.6

関連研究

中田らは，自動ポートフォワーディング手法およびJupyter Hub をクラウド上に設置する手法で ABCI
上の Jupyter Notebook の外部からの利用を実現した [11]．

本稿執筆時点では上記の制約により環境の選択に対応

自 動 ポ ー ト フ ォ ワ ー デ ィ ン グ 手 法 は ，我 々 のしていない．また，本機能は Python 3.6.5 で実装されjupyterrun の手法をさらに自動化すべく推し進めているが，それ以外の任意のバージョンの Python をた形となっているが，そのために利用者の手元にも小カーネルとして指定する機能も実装されていない．こ規模なスクリプトを保存することを要求し，利用者のれらは，変更先の環境においても Jupyter が必要とす

手元環境に一定の仮定を置いている．

る Python モジュール ( ipykernel launcher など) が後者の Jupyter Hub 設置手法では，我々の手法とインストールされていることを保証する必要があり，同様にターミナルの操作を極力省く設計となっている

現状では個別の Python バージョン等に対して必要なが，ブラウザの接続先の Jupyter Hub を対象システ

モジュールを都度構築する対応が必要となっている．

ムである ABCI の外に置く設計となっているために，

3.5

ユーザの動向ユーザ管理が Jupyter Hub 側と ABCI 側で多重に必2020 年 8 月末日時点での，TSUBAME3.0 の年度

要となり，その間をパスフレーズのない SSH 鍵ペア

内アクティブユーザ数 (ログインノードもしくは Webで結ぶ必要があり，セキュリティ面および初学者の参アプリケーション実行機能のいずれかの利用歴がある

入コストの面で問題がある．我々の手法では，Web ア

ユーザ数) は 1082 名であり，うち 155 名が Web アプ

プリケーション実行機能を TSUBAME3.0 の利用者

リケーション実行機能を利用していた．また，このう

ポータル内に組み込むことで，ユーザ認証の問題を解

ちの 54 名のユーザは SSH によるログインノードへの決し，ジョブの投入も直接 Web アプリサーバが実行

接続歴がなく，本機能の実装により 5 か月間で新たにする形となっており，SSH 鍵ペアの管理に関する問題

5% のユーザを獲得できたといえる．

も発生しない．

図 8 に Web アプリケーション実行機能の時間帯別

また，同文献にて記載されていることではあるが，1

利用数 (2020 年 4 月から 8 月合計) を示す．インタラ

つの計算機アカウントを Jupyter Hub の利用者で共クティブジョブ実行専用キュー同様に 10 時，11 時の有する構造となっているため，1 アカウントの利用者

講義利用に集中しているがそれ以外の時間帯の一般のは自然人 1 名に限ると利用細則で厳格に定められている TSUBAME3.0 においては，利用者ごとに別アカウ
ントを利用するようにする改変を行わない限り，複数人での利用は難しい．

あり，利便性向上のための改良を続けていきたい．

参考文献

Google Colab [12] は，Google の機械学習指向の[1] 東京工業大学学術国際情報センター. TSUBAME

Jupyter Notebook 環境であり，Jupyter カーネルの計算サービス. https://www.t3.gsic.titech.

切り替えの要領でアクセラレータなし・GPU・TPU

ac.jp/.

のそれぞれのインスタンスへの切り替えが実行可能に[2] 藤田 和宏ほか. 新スーパーコンピュータ TSUB-

なっている．Notebook のフロントエンドを実行する

AME3.0 の概要. 大学 ICT 推進協議会 2017 年度

ノードと，Python カーネルを実行するノードを別に年次大会, 2017.

する設計を行うことで実装可能で，このことにより計[3] 阿部 公一ほか. TSUBAME3.0 における計算資

算ノードの利用効率が向上する可能性もあるように思

源分割の検証. 大学 ICT 推進協議会 2018 年度年

えるが，一度 Python カーネルを起動した後はいずれ次大会, 2018.

の方式においても Python カーネルの実行のために資[4] 松岡聡, 遠藤敏夫, 額田彰, 三浦信一, 野村哲弘, 佐源が占有された状態でユーザの入力待ちとなるため，藤仁, 實本英之, Aleksandr Drozd. HPC とビッ

大きな差はないものと考えられる．文献 [11] におい

グデータ・AI を融合するグリーン・クラウドスパては，Colab 方式のほうがインスタンス切り替え時にコン TSUBAME3.0 の概要. 情報処理学会研究報

ユーザの Notebook を開き直す必要があるためにユー

告, 第 2017-HPC-160 巻, pp. 1–6, Jul 2017.

ザ経験が大きく劣ると結論付けているが，Python カー[5] Univa Corporation. Univa grid engine. http:ネル切り替え時にはいずれにせよ内部状態が失われて//www.univa.com/products/.

しまうため，インタラクティブジョブ実行専用キュー[6] 東京工業大学学術国際情報センター. TSUB-のようにリソースのオーバーコミットを行うことで，AME3.0 モニタリングページ. https://www.

サイズの違う資源とのマイグレーションを行う必要が

t3.gsic.titech.ac.jp/monitoring.

ない (課金方式を含めた) 設計を行うほうが良いと考える．

4 おわりにTSUBAME3.0 におけるインタラクティブ利用の利便性向上のために行った，インタラクティブジョブ実[7] Project Jupyter. Home. https://jupyter.
org/.
[8] 東京工業大学学術国際情報センター. ログイン
ノードで cpu を占有する利用は行わないでくだ
さい. https://www.t3.gsic.titech.ac.jp/

loginnode-limit.

行専用キューの導入と Web アプリケーション実行機[9] 東京工業大学学術国際情報センター. 計算ノー能による Jupyter Lab の提供を通じて，「みんなのス

ドでの jupyter notebook の起動. https://www.

パコン」としてのユーザ体験の向上について報告した．

t3.gsic.titech.ac.jp/jupyter_notebook.

インタラクティブジョブ実行専用キューを導入する[10] 産業技術総合研究所. ABCI user guide: Jupyter

ことで，資源の占有よりも応答性が優先されるインタ

notebook の利用. https://docs.abci.ai/ja/

ラクティブジョブを通常のバッチジョブから隔離し，

tips/jupyter-notebook/.

インタラクティブタスクの実行者のユーザ体験を向上させることができた．

Web アプリケーション実行機能の導入により，初学[11] 中田秀基, 滝澤真一朗, 小川宏高. 大規模計算ク
ラスタにおけるユーザ利便性向上. 情報処理学
会研究報告, 第 2020-HPC-174 巻, pp. 1–6, May者等に対して SSH クライアントのインストールや公2020.

開鍵，Linux のコマンド類の学習を行うことなくスパ[12] Google.

コン上の GPU を含む計算資源への対話的なアクセスを直接提供することができるようになり，GPU スパ
コンの利用の敷居を下げることができた．
いずれの施策においても，現時点では効果を定量的に示すには至っていないが，TSUBAME3.0 の利用者のストレスの軽減に資することができていれば幸いでColaboratory.

research.google.com/.

https://colab.