スーパーコンピュータ OCTOPUS の混雑緩和に向けた取り組み
勝浦 裕貴 1), 寺前 勇希 1), 木越 信一郎 1), 伊達 進 2)
1) 大阪大学情報推進部情報基盤課
2) 大阪大学サイバーメディアセンター
katsuura-y@cmc.osaka-u.ac.jp

efforts to reduce congestion of OCTOPUS
Yuki Katsuura, Yuki Teramae1), Shinichiro Kigoshi1), Susumu Date2)
1) Department of Information and Communications Technology Services, Osaka Univ.
2) Cybermedia Center , Osaka Univ.
概要
大阪大学サイバーメディアセンターでは 2017 年 12 月よりスーパーコンピュータシステ
ム OCTOPUS の運用を開始した。OCTOPUS は多くの研究者の方々からご好評いただき、
運用開始から非常に高い利用率を誇っているが、その結果としてジョブ実行までの待ち時間が深刻な問題となっている。本稿ではこの待ち時間の削減に向けた取り組みについてまとめる。
これらの様々なアーキテクチャを利用できるヘはじめにテロジニアスな構成や、低めの料金設定、広く普大阪大学サイバーメディアセンターでは 2017

及している Intel 社製のプロセッサを導入している

年 12 月 よ り ス ー パ ー コ ン ピ ュ ー タ シ ス テ ム

ことなどから、サービス開始以来非常に人気の高OCTOPUS の稼働を開始した[1]。OCTOPUS は合いシステムとなっている。前述の通り比較的小規

計 319 ノードの比較的小規模なシステムであるが、模なシステムなこともあって毎年のように資源の1

汎用 CPU ノード群、GPU ノード群、Xeon Phi ノー

売り切れが発生しており、2020 年度は 5 月 18 日

ド群、大容量主記憶搭載ノード群という 4 つのノ時点で資源が売り切れてしまい、新規の利用申請

ード群で構成されており、ユーザは OCTOPUS へを停止する事態となった。人気が高いことは運用の利用申請でこれらのノード群を横断的に利用すする身としては嬉しい限りなのだが、その反面、ることができる。各ノード群の概要を図 1 に示す。

多数のユーザが多数のジョブを投入することによる待ち時間の長時間化が悩みの種となっている。
当センターでは年度末にユーザ向けのアンケー
トを実施しており、その中で OCTOPUS の不満点に関する設問を用意している。図 2 が 2018 年度のアンケートにおける OCTOPUS の不満点に関する回答の集計結果である。
「不満点なし」が約 2 割であるのに対し、7 割以上が「ジョブ実行」を不満点として回答している。コメントでもジョブ実行までの待ち時間の改善に関する要望が多く、
OCTOPUS の運用において大きな課題となっている事は間違いない。逆に、「計算資源の性能」や「開発環境」なども選択肢として用意していたが、これらを不満点として選択したユーザはおらず、新

図 1.OCTOPUS の概要

たな共用計算機としては十二分な性能を備えていたと言える。そのため、システムの性能向上よりも、ジョブの待ち時間を始めとした混雑の解消こそが OCTOPUS にとって最も対処すべき課題であした時点で利用申請の受付を停止するという運用ると考えられる。

を行っている。これが前述の資源の売り切れである。しかし、年度の前半は購入した資源を温存し、年度後半に集中的に利用するというユーザが一定

ストレージ
4.8%
ソフトウェ
ア
4.8%

数存在する。そのため、年度前半にはノードに空

なし
19.0%

きができて提供可能時間を無駄にしてしまう一方で、年度後半は混雑して長時間の待ちが発生するという現象が起こる。これによる長時間の待ちが

ジョブ実行
71.4%

不満になっているのはもちろん、購入したポイン
トは年度末で失効するため、混雑で思うようにジョブ実行が進まず余らせたポイントが無駄になっ図 2.OCTOPUS の不満点（2018 年度アンケートの集計結果からの抜粋）てしまうという点も不満を加速させていると思われる。
また、利用時期の偏りだけでなく、利用するノード群の偏りも大きな問題となっている。2018 年
度のノード群ごとの月別利用率を図 4 に示す。

OCTOPUS の状況と課題

2

2018 年度の OCTOPUS において、待ち時間が 24
時間を超えたジョブの件数と、全ジョブの平均待ち時間を月別に集計したグラフを図 3 に示す。

100%
80%
60%

8000

35h

7000

30h
25h

5000

20h

4000

15h

3000

10h

2000

GPU
XeonPhi
大容量主記憶0%

4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 1 月 2 月 3 月

図 4. OCTOPUS の 2018 年度利用率

5h

1000
0

汎用CPU

20%

待ち時間

ジョブ件数

6000

40%

4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月

待ち時間が24時間以上のジョブ件数

0h

平均待ち時間

汎用 CPU ノード群は 1 年を通して高い利用率を保っているが、GPU ノード群、Xeon Phi ノード群、
大容量主記憶搭載ノード群については年度前半の図 3.OCTOPUS の平均待ち時間と待ち時間利用率が低くなっている。このように汎用 CPU ノが 24 時間以上のジョブ件数（2018 年度）

ード群だけに利用が集中すると他のノード群に空きができてしまい、提供可能時間が無駄になって正式サービスの開始が 2018 年 4 月からというしまう一方、汎用 CPU ノード群では長い待ち時間こともあり、年度前半は比較的落ち着いているもが発生してしまう。こうなるとユーザのポイントのの、年度後半になると待ち時間が急増しており、消費が思うように進まず、ポイントを余らせない

特に 12 月～2 月には平均で 24 時間以上の待ち時ために年度後半は更に躍起になってジョブを投入間が発生してしまっている。

するようになり、年度前半にポイントを温存して当センターの計算機は従量課金制ではなく、利用する資源（OCTOPUS ポイント[2]）を事前に購いたユーザのジョブとあわせて年度後半の混雑が更にひどいものになる。

入し、そのポイントを消費して利用する、所謂プ1 年間の提供資源量の上限は全てのノード群がリペイド式の利用負担金制度をとっている。当た100%利用される前提で計算しているため、ノード

り前だが、OCTOPUS が 1 年間で動作できる時間に空きができ、提供可能時間を無駄にしてしまうは限りがある（319 ノード×365 日）ため、1 年間

ことは、年度末の混雑に直結する。当センターにで提供可能な資源量上限を予め設定し、上限に達限った話ではないと思うが、11 月～2 月頃は学生

の論文シーズンなこともあって利用が集中するたノードが利用されているかどうか”を表しており、め、利用時期の偏りはある程度仕方のない部分でGPU ノードで実行されているジョブが GPU を利はある。しかし、この利用時期の偏り、そして利用用するかどうかに関わらず、ジョブが実行されてノード群の偏りを緩和し、提供可能時間の無駄をいれば利用率として計上している。

減らすことが、年度後半の待ち時間の緩和にもつながると考えられる。

図 4 からも分かる通り、4～5 月は GPU ノードの利用率が非常に低かったため、当初は全ての

なお、2018 年度後半には Xeon Phi ノード群、大GPU ノードに対し、汎用 CPU ノードに投入され容量主記憶搭載ノード群の利用率が向上しているたジョブ（以下、「汎用 CPU ジョブ」という）がが、これはセンター側で何か対策を実施したとい実行されるよう設定変更を行った。これにより汎う訳ではなく、繁忙期に入り混雑を極めた汎用用 CPU ジョブの待ち時間は減少したものの、GPU

CPU ノード群の待ち時間にしびれを切らし、空いノードに投入されたジョブ（以下、「GPU ジョブ」ている Xeon Phi ノード群、大容量主記憶搭載ノーという）の待ち時間が大幅に増加することになっド群にユーザが流れたことが原因と考えられる。

た。この時点では GPU ジョブの数が少なかったた

この時期に Xeon Phi ノード群へ大量にジョブを投め影響は大きくなかったのだが、運用を続けてい入していたユーザに話を聞く機会があったが、るうちに GPU ジョブが増加するだけでなく、それ

Xeon Phi に最適化されたプログラムではないためを遥かに上回る速度で汎用 CPU ジョブも増加し

実行時間自体は伸びてしまうものの、待ち時間をていったため、「GPU ノードなのに汎用 CPU ジョ

加味すると汎用 CPU ノード群よりも遥かに早くブばかり実行されていて肝心の GPU ジョブが流ジョブが終わるとのことであった。また、GPU ノれない」という問題が表面化するようになった。

ード群は 6 月から急激に利用率が上昇しているが、この対策として GPU ジョブ専用ノードの確保やこの原因については後述する。

GPU ジョブのアサイン可能時間の延長等を実施し、3混雑緩和に向けた取り組みと成果

GPU ジョブが実行されやすくなるよう調整した。
GPU ジョブが増えたとはいえ、汎用 CPU ジョブ

第 2 章で述べた OCTOPUS の課題について、2018の数が圧倒的に多いことは変わりないため、上述

年度～2019 年度に行ったいくつかの取り組みを行した対策のノード数や時間などを適宜調整し、ジった。本章ではこれらの詳細について報告する。

ョブのバランスを取りながら運用を行っている。
ノードの基本的な構成を同一にしなければならな

3.1 GPU ノードを汎用 CPU ノードとして利用可能にいという制約はあるが、ノード群間での負荷分散

図 1 を見ると、GPU ノード群は汎用 CPU ノーや利用率向上において非常に有効であるため、複ド群と基本的な構成が同一となっている事が分か

数ノード群で構成されるシステムの構築を行う際る。というのも、OCTOPUS の調達活動を行っていは、複数のノード群の役割をこなせるノード設計

た段階から汎用 CPU ノード群が最も利用されるにすることが望ましいのではないかと思う。

のではないかと予想していたため、そういった場
合に GPU ノードを汎用 CPU ノードとしても利用できるよう仕様を定めたためである。

3.2 季節係数の導入
OCTOPUS の共有利用制度では、前述の通り

予想通り、正式サービス以前の無料開放期間

OCTOPUS ポイントと呼ばれる資源をユーザが購（2017 年 12 月～2018 年 3 月）からすでにこの傾入し、それを消費しながら OCTOPUS を利用する

向が表れており、正式サービスを開始してからもプリペイド式の利用負担金制度となっている。ジ

汎用 CPU ノード群のみ待ち時間が発生するといョブを実行した際のポイントの消費量は下記の計

う状況が続いたため、2018 年 6 月から GPU ノー

算式によって算出される。

ドを汎用 CPU ノードとしても利用できるよう設
定変更を行った。その結果、図 4 のように GPU ノード群の利用率が 6 月から急激に上昇することとなった。この説明からも分かると思うが、GPU ノ

消費量 = 使用ノード時間 × 消費係数 × 季節係数

「消費係数」は各ノード群の消費電力を元に定ード群の利用率の大半は汎用 CPU ノードとしてめられた値である。例えば、GPU ノードは汎用利用されたものである。図 4 の利用率はあくまで”

CPU ノードに対して約 4 倍の電力を消費するため、

消費係数も約 4 倍に設定されている。それによって、同じ時間、同じノード数の利用でも、汎用 CPU
ノードの約 4 倍のポイントを消費するという仕組みである。これは、ノード群毎の個別の利用申請を必要とせず、“OCTOPUS ポイント”という一元的な資源で管理して 4 つのノード群を横断的に利用できるようにすることを目的とし導入した係数である。なお、汎用 CPU ジョブが GPU ノード群で実行された場合は、汎用 CPU ノード群の係数が適用される。

100%
80%
60%
40%
汎用CPU
GPU

20%
0%

XeonPhi
大容量主記憶4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 1 月 2 月 3 月

図 5. OCTOPUS の 2019 年度利用率

一方、「季節係数」は利用時期と利用ノード群の偏りの緩和を目指して導入された係数である。前

利用率を見る限りでは一定の成果はあったよ

年度の各ノード群の利用率を元に 0 より大きい１

うに見受けられる。特に Xeon Phi ノード群は季節以下の値が設定され、特定期間、特定のノード群

係数の低い 4~6 月の利用率が昨年に比べて大きくのポイント消費量が割引されるという仕組みであ上昇しており、利用時期の偏りにはある程度の効る。正式サービス開始初年度でなる 2018 年度は通果はあったと言える。一方で、4~6 月に Xeon Phi

年 1 で運用したが、2019 年度の季節係数は 2018 年

を利用していたユーザの殆どが前年度にも同ノー度の利用率を元に学内の委員会で議論し、表 1 のド群を利用していたユーザであり、季節係数の低値で運用することとした。

さを目的として普段利用しているノード群以外にジョブ投入を試みるユーザはごく一部であるとい

ノード群

4～

7～

10～

1～

うことも分かった。つまり、利用ノード群の偏り

6月

9月

12 月

3月

に対してはほとんど効果が得られなかったということになる。

汎用 CPU

1GPU
Xeon Phi

1
0.5

0.7

1

1

抑えられるため、その分だけユーザが利用できる

大容量主記憶

0.8

0.8

1

1

ノード時間は増えることになる。季節係数の導入

また、季節係数を低くするとポイント消費量が

表 1. 2019 年度の季節係数

によって利用時期の偏りがある程度解消され、閑汎用 CPU ノード群及び（汎用 CPU ジョブと共できるノード時間が増えている以上、それが繁忙用となった後の）GPU ノード群については常に高期の混雑の解消にも効果があったとは言い切るこい利用率を保っていたため、引き続き通年 1 での運用とした。一方、2018 年度前半の利用率が低かった Xeon Phi ノード群は 4～6 月を 0.5、7～9 月を0.7 とした。大容量主記憶搭載ノード群も同じく低かったが、もともと 2 ノードしかないことを考慮
し、下げ幅は控えめにして 0.8 とした。この場合、
例えば 4～6 月に Xeon Phi ノード群で実行したジ
ョブは、そのポイント消費量が 5 割引される。上
表の内容で 2019 年度は運用することを 2019 年 2月にユーザへ周知し、１年間運用を行った結果、
ノード群ごとの月別利用率は図 5 のようになった。

散期の利用率アップにはつながったものの、利用とは難しいかもしれない。とはいえ、繁忙期の待ち時間は 2018 年度と比べると多少は短くなっていたため、一定の効果はあったと言える。
この季節係数に関して、「年度末の混雑を避ける
ため、年度末の季節係数を 1 より大きくすることに賛成か、反対か」という問いを 2019 年度のアンケートに設けた。季節係数が 1 より大きくなるということはポイント消費量が通常よりも割高になるということであり、ポイント消費量という点ではユーザにとってデメリットでしかない。当然筆者も反対多数を予想していたのだが、その結果は賛成 56%、反対 41%、どちらとも言えないが 3%と、賛成多数の結果となった。賛成派の意見としては、年度初めからの計画的な利用を促せる、年度末の混雑緩和に繋がるというものが多数であった。一方、反対派の意見には下記のようなものが見られた。

のみであったが、2020 年 9 月より新たに Oracle
Cloud Infrastructure[5]（以下、「OCI」という）








年度末以外の利用は増えるかもしれないが、年との連携も可能となった。
Azure 上のクラウドノー

度末に混雑するのは変わらないと思う。

ドは OCTOPUS の汎用 CPU ノードにできるだけ料金の問題でなく、年度末近くに論文提出や学近い構成のインスタンスを選択しているが、仮想会が多いのが問題であり、季節係数増加による化環境と物理環境という差異が原因となり、プロ抑制効果は小さいのではないか。

グラムによっては計算結果に違いが出る、エラー

年度末は（資源が売り切れているため）ポイン

で実行できないなどの問題が発生していた。新たトの追加購入ができなくなるのに、その年度末に連携可能となった OCI 上の計算ノードはベアメにポイントが不足する事態に陥りかねない。まタルサーバである為、この仮想と物理の差異に起た、そのような事態に注意しながら利用したく因する問題が解決されるのではないかと期待され

ない。

ている。

研究計画にも影響するので、上限値は 1 で固定

本機能は未だ実証実験の段階ではあるが、純粋してもらいたい。負担金を増やすか、全体の提に”混雑時に一時的に計算ノードが増える”ことに供時間を減らすかして対応するべき。

なるため、混雑の緩和に効果的であることは言うまでもない。一般ユーザ向けに機能開放するに当本設問はあくまでユーザの意識調査を目的としたっては、前述の技術的な問題の解決はもちろん、て設けたものであり、現時点では季節係数を 1 よクラウドノードの利用料金の扱いやジョブの転送

り大きく設定する予定はないが、アンケートの結ポリシーと利用方法の検討、それらに伴う利用規果としては非常に興味深いものであった。2020 年定の改正やユーザへの周知等、やるべきことは多9 月現在調達を行っている高性能計算・データ分

く残されているが、混雑緩和だけでなく様々な目析基盤システム（以下、「次期スパコン」という）的に応用できる機能であり、引き続きクラウドバ

は OCTOPUS と同じく特徴の異なる複数のノード

ースティング機能の検証・検討を進めることとす

群から構成されるシステムを予定しており、課金る。差し当たり、OCI について当センターのユー制度についても OCTOPUS と同様に一元的なポイザを対象に実証実験を行う予定である。

ント制となることを想定している。次期スパコンの課金制度をより使いやすいものとするためにも、

3.4 その他の対策

アンケートの意見も参考にしつつ OCTOPUS を運

ここまでいくつか混雑緩和に向けた取り組み

用し、季節係数等のポイント制度の運用ノウハウを紹介したが、直接的に混雑の緩和にはつながらを蓄積しておきたい。いずれにしても、ユーザのないまでも、これ以外にも様々な混雑対策を行っ研究計画に悪影響を及ぼすことは避けなければなている。

らないため、季節係数については引き続き慎重に運用を進めていくこととする。

例えば、DBG キュー（デバッグキュー）及びDBG キュー専用ノードの新設である。OCTOPUS
ではフロントエンドノード（プログラムのコンパ

3.3 クラウドバースティング機能の実装

イル、ジョブ投入等を行う作業用のノード）での“クラウドバースティング機能”とは OCTOPUS

プログラム実行を禁止しているため、ジョブスクが混雑した際にジョブの一部をパブリッククラウ

リプトを用いてジョブ投入し、計算ノードで実行

ド上の計算ノード（以下、「クラウドノード」といする必要がある。しかしながら、汎用 CPU ノードう）に割り当て、OCTOPUS の計算負荷を肩代わり

群は全ノードのスケジュールが埋まっていることさせる機能である。この機能は本センターの伊達がよくあり、簡単なプログラムの実行ですら数日

進准教授主導のもと実装した機能であり、2019 年の待ち時間が発生することも珍しくない状況であ度の AXIES 年次大会に投稿した論文「OCTOPUSった。これではプログラムの動作確認やデバッグのクラウドバースティング拡張」[3]にて転送の仕もままならないため、1 ノード実行かつ最長 10 分

組みや環境構築について解説しているため、詳細までのジョブのみ投入可能な DBG キューを新設

についてはここでは触れない。

した。また、キューを新設してもノードに空きが本機能の実装当初は Microsoft Azure[4]との連携

なくては意味がないため、DBG キュー専用のノードもあわせて用意している。流石に DBG キュー専
用ノードは頻繁に空きができている（=提供可能時
間を無駄にしている）が、利便性を考えると必要なノードであるのは間違いない。
他にも、ジョブスクリプトに記載する経過時間
リクエストと実際のジョブの実行時間に大きな乖離があるユーザへの個別連絡なども行っている。
OCTOPUS のスケジューラは基本的には先入れ先

4 結果
4.1 取り組みの成果
以上、2019 年度までに行ったいくつかの混雑対策を紹介した。取り組みの効果の指標として、2018
年度と 2019 年度の平均待ち時間を比較したグラ
フを図 6 に示す。

実行方式でノードが確保され、ジョブが実行され35hる。ノードの確保はジョブスクリプトに記載され30hている経過時間や並列数のリクエストを元に行わ25h

れるのだが、大規模なジョブが投入されると空き

20h

ノード数などの関係で隙間時間ができることがあ15hる（図 4, 5 において慢性的に混雑している汎用
CPU ノード群の利用率が 100%に満たないのはこのためである）。ここで新たにジョブが投入された
場合、通常は大規模ジョブの後にスケジューリン
グされるが、経過時間リクエストが隙間時間内におさまる短時間ジョブであった場合はこの隙間時間にスケジューリングされ、実行される。長時間に設定した場合よりも早く実行が始まるだけでな
く、運用側にとってもこういった隙間時間を有効活用できると（微々たるものだが）混雑緩和にもつながるため、実際の実行時間が短い傾向であるにも関わらずジョブスクリプトの経過時間リクエ
ストが長時間になっているユーザには積極的に連絡を行っている。
また、これは混雑対策を主目的にしたものではないが、ユーザサポートの一環としてプログラム
チューニング支援サービスを行っている。当セン
ターのユーザを対象にプログラムを募集し、
OCTOPUS のベンダーである日本電気（株）のエンジニアがチューニングを施すというもので、作業内容はユーザの希望によって様々だが、多くの場
合は並列化や OCTOPUS への最適化などである。
応募するのは当センターのヘビーユーザの方が多く、こういった方のプログラムを高速化すること
で他のユーザも待ち時間が減るという恩恵も得られ、間接的に待ち時間対策になっているとも言える。本サービスは 2016 年度から毎年数件行っており、今後も継続して実施する予定である。その他、キューごとのアサイン数、実行数上限の定期的な調整などの細々とした対策も適宜行っており、混雑している中でもできる限り使いやすい環境になるよう取り組んでいる。

10h
5h
0h

4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月

2018年度

2019年度

図 6. 2018 年度と 2019 年度の平均待ち時間
結果としては待ち時間の解消に対してあまり良い成果を挙げられなかったと言わざるをえない。
また、2018 年度は OCTOPUS の正式サービス開始
初年度であり、特に年度前半は利用者の絶対数が少ないため単純比較はできないが、2 章で問題点として挙げた利用時期の偏りについては概ね解消
され、繁忙期の混雑の軽減と閑散期の利用率向上には成功したと言える。しかしその結果として、
ほぼ 1 年を通して平均待ち時間が 10 時間を超えるという事態となった。最大の要因はやはり汎用
CPU ノード群への利用の偏りであるが、なかなか有効な解決策を打てないでいる。
4.2 今後の対策
今後着手しようとしている取り組みとしては、
コア単位でのジョブ実行が挙げられる。当センタ
ーは長らく 1 ノード 1 ジョブ運用を行っており、
これは、あるジョブが実行されているノードは当該ジョブに占有され、他のジョブと同時利用されることがないというものである。複数ジョブでの同時利用による性能低下の心配がない、利用時間の管理が簡単などのメリットがあるが、ジョブの利用資源量に関わらずノードが占有されるという大きなデメリットがある。例えば、OCTOPUS の汎
用 CPU ノードは 1 ノードあたり 24 コア有しているが、並列化されていない 1 コア実行のジョブで考の余地はあるが、本案もシステム改修など大掛あっても 1 ノード（= 24 コア）占有するため、そかりな作業を伴うため、いずれにしてもメリット/の間は 23 コア分の実行時間が無駄になっている

デメリットをしっかりと考えたうえで判断する必と言っても過言ではない。ここで、ノード単位で要がある。

はなくコア単位で資源を確保するよう設定し、1 ノ

また、今回はジョブの平均待ち時間を成果の簡ードで複数のジョブが同時実行されるようにする

単な指標として示したが、これだけで混雑状況をことでこの問題は回避できる。先の例で言えば無正確に把握することは難しい。大規模並列の長時駄になっていた 23 コア分の実行時間を活用でき

間ジョブはノードの確保が難しく待ちが長時間化るようになるということであり、混雑緩和への効してしまう一方、1 ノードの短時間ジョブは待ち果を期待できる。

時間が短くなりやすいほか、Xeon Phi などの空い複数ジョブで 1 ノードを共有することで性能がているノード群に投入されたジョブが多いほど平低下し、ジョブあたりの実行時間が長くなる可能

均待ち時間も短くなるなど、同じ 1 件のジョブと性はあるが、待ち時間の短縮に比べれば無視できして扱うには各ジョブの実行条件が違いすぎる。

るレベルのものであると思われる。実行時間が長

それでもなお平均して 10 時間以上の待ちが発生

くなるとポイントの消費量が増えるというデメリ

しているのは大問題だが、状況を詳しく把握し、ットもあるが、ノード単位での利用か、コア単位

有効な対策を考えるにはジョブの実行条件を加味での利用かをユーザ側で選択できるようにすればした統計的な分析が必要であると考えられる。コ

問題ない。先のアンケートでもポイント消費量よ

ア単位での提供に対応したところで、１コア～数り待ち時間の削減を優先するユーザが多かったた

コア利用のジョブが少なければ期待した効果は得

め、選択式にしても一定のユーザはコア単位でのられないし、GPU の分割提供も同様である。対策

利用を選択すると考えられる。また、コア単位で効果の予測のためにも、より詳細な分析が必要での提供に対応することで GPU の分割提供も可能ある。もちろん統計データの収集は行っているが、となる。GPU ノードには 4 基の GPU が搭載され各種資料の作成等に利用しているに過ぎず、デーているが、現状は 1 基のみ利用するジョブが多い

タを有効活用できていないというのが現状である。

ように見受けられるため、GPU ジョブの混雑緩和にも効果的であると思われる。
しかしながら、システムの設定変更や利用制度

5 まとめの新設、規定の改正等の作業が伴うため、実装し

本稿では OCTOPUS の混雑緩和に向けて行った

た場合に起こりうる問題やデメリットなどを十分

様々な取り組みを紹介した。結果としては大きなに吟味した上で進める必要がある。また、あくま

成果を挙げられず、2020 年度も変わらず混雑した

で 1 ノードで複数ジョブが同時に実行されるよう状況が続いている。OCTOPUS の運用においては、にすることで提供可能なノード時間を擬似的に増ヘテロジニアスなシステム特有の各ノード群の需

やすという対症療法的な対策であり、利用ノード

要や特色の違いに起因する扱いの難しさを痛感す

群の偏りに対する根本的な解決にはならない。

ると同時に、結局のところ、高性能な加速器や特利用ノード群の偏りによる混雑を解決するだ

殊なアーキテクチャの計算機よりも純粋に性能のけであれば、OCTOPUS ポイントでの一元的な管高い、使い慣れたスカラ型プロセッサを搭載した

理を廃止し、ノード群ごとの個別の利用申請にすシステムが（少なくとも当センターのユーザでは）るという案がある。これによりそれぞれ個別に提頭一つ抜けて需要が高いということを知らしめら

供資源量上限を設けられるため、汎用 CPU ノード

れる結果となった。

群の申請量が上限に達した時点で申請受付を打ち

また、今回様々な取り組みや改善案を述べてき

切れば、利用時期の集中による一時的な混雑はあたが、個人的には 2021 年度に運用開始予定の次期るにせよ、慢性的な混雑は解消すると予想される。

スパコンが OCTOPUS の混雑をすっかり解消して

しかし、これでは OCTOPUS の一つの売りであるしまうのではないかと思っている。次期スパコン

複数のアーキテクチャを横断的に利用できる自由

も OCTOPUS と同じくヘテロジニアスなシステム度の高さを犠牲にすることになる。今の OCTOPUSとなる予定だが、OCTOPUS の反省を活かし、スカにとっては混雑の解消が最重要課題であるため一ラ型プロセッサを搭載したノード群は非常に大規模なものになるよう仕様を定めている。搭載されるプロセッサも OCTOPUS より新しい世代のものになるよう調達を進めており、このシステムが稼働を始めたあかつきには多くのユーザが
OCTOPUS から流れることが予想される。現在は利用率の高さに頭を悩ませているが、場合によっては利用率の低さに悩まされることになるかもしれない。
前述の通り、次期スパコンは OCTOPUS の運用
経験を活かして調達を行っているシステムである
ので、OCTOPUS の運用を通して次期スパコンにも通用するノウハウを蓄積しつつ、また、次期ス
パコンとの同時運用が始まっても多くのユーザに利用される人気なシステムであり続けられるよう、引き続き OCTOPUS の課題解決と改善に向けた様々な機能追加/改修、制度改正等の取り組みを進めることとする。

参考文献[1] 伊達進,木越信一郎, 全国共同利用大規模並列計算システム調達の背景, 大学推進 ICT 推進協議会 2017 年度年次大会, 2017 年 12 月．
[2] OCTOPUS ポイントについて, http://www.hpc.c
mc.osaka-u.ac.jp/system/manual/octopus-use/octo
pus_point/[3] 伊達進, 片岡洋介, 五十木秀一, 勝浦裕貴, 寺前勇希, 木越信一郎, OCTOPUS のクラウドバ
ースティング拡張, 大学推進 ICT 推進協議会
2019 年度年次大会, 2019 年 12 月．
[4] Microsoft Azure, https://azure.microsoft.com/jajp/[5] Oracle Cloud Infrastructure, https://www.oracle.com/jp/cloud/infrastructure/iaas/overview/