WGS 1 万検体 を解析するための適切な Luster 設計とその運⽤
東京⼤学医科学研究所ヒトゲノム解析センター
シークエンスデータ情報処理分野
准教授 ⽚⼭琴絵

ヒトゲノム解析センター (HGC)

2ü東京⼤学 医科学研究所 ヒトゲノム解析センターはゲノム情報と医療情報に基づいた個別化ゲノム医療など、データサイエンスを広く推進ü医学・⽣命科学研究に最適化したスーパーコンピュータ SHIROKANE を擁し、以下の事業を⾏い、また SHIROKANE を教育研究機関、⺠間企業の研究・事業活動に提供
Ø 個別化ゲノム医療のための次世代ゲノム医学研究の推進
Ø 個別化ゲノム医療のためのメディカルインフォマティクスの研究
Ø 倫理的・法的・社会的問題の研究による公共政策研究üHGC スパコン SHIROKANE のミッションとして
Ø AMED ⾰新的がん医療実⽤化研究事業
Øパーソナルゲノムに基づく個別化医療の推進個別化医療の推進
ü個別化医療の第⼀歩は Whole Genome Sequencing であり、データ解析・解釈、メディカルインフォマティクスが鍵になる。
HGC は病院と連携し、全ゲノム情報解析を SHIROKANE を⽤いて⾏ってる。

3

SHIROKANE の紹介üSHIROKANE は 2018 年 4 ⽉稼働の Shirokane5 と 2022 年 4 ⽉稼働のShirokane6 が合わさったスーパーコンピュータシステムになるüSHIROKANE の特徴
Ø 1.9 PFLOPS 余の総合理論演算性能になる４種類の計算機を⽤意
Ø 30 P バイト以上の⾼速ディスクアレイ装置であるホームディスクを⽤意
Ø 60 P バイト以上の⻑期保存するための巨⼤アーカイブディスクを⽤意
Ø 年間約 9,600 万件 (1⽇あたり約 25 万件)のジョブが実⾏

実⾏ジョブ数

45SHIROKANE の構成
Shirokane4

Shirokane6

今Shirokane5

Shirokane7の多い
メモリ ドーノ算計

30 Pバ
Lustr イトのe のホームディスク

メインの計算ノード

Shirokane5

Shirokane6

100 P バイトを超える拡張ができるデータアーカイブ

6

SHIROKANE の構成
Shirokane4

Shirokane6

今Shirokane5Shirokane7の多い
メモリ ドーノ算計30 P
バLustr イトのe のホームディスク

メインの計算ノード

Shirokane5•••

Shirokane6

MDS/MDT ⽤ ES400NVX を 2 set、OSS/OST ⽤ ES400NVX + SS9012 x 4 を 10 set
全体スループットは 18 GB/s x 10 set = 180 GB/s
ファイル・ディレクトリ作成処理能⼒ともに 160,000 回/s

100 P バイトを超える拡張ができるデータアーカイブ

MDS/OSS の負荷状況
常に MDS/OSS のロードアベレージが⾼い状態でI/O エラーなどユーザの解析に影響があった
問題点①

7

メタデータアクセス
実⾏時間の短いジョブが多く、メタデータアクセスが頻繁に⾏われている状況

8アクセスバンド幅
常に Read で 40 GB/s 程度、Write と合わせて全体で50 GB/s 以上の I/O がある状況

9

10

問題点①
ü状況
Ø⼀部のユーザ が Lustre ファイルシステムへの I/O が多い⼤量の Array ジョブを実⾏し、OSS の過負荷を招いていた

ü問題点
ØOSS の過負荷を発⾒した際に現地 SE で⾼負荷を招いているジョブを⼿作業で特定し、対象ジョブをサスペンドし、ユーザへ連絡していた
Ø現地 SE が業務中では対応できるが、業務時間外の場合対応できていない
ターミナル ー ssh# iostat –mxt 1.
Device:rrqm/s wrqm/s
r/s
w/s
rMB/s
wMB/s avgrq-sz avgqu-sz
await r_await w_await svctm %util.
sfa0000
0.00
0.00 441.00
3.00 349.29
0.01 1611.17
62.68
134.97 135.89
0.33 2.25 100.00
sfa0001
0.00
0.00 142.00
0.00 111.00
0.00 1600.90
2.57
19.24 19.24
0.00 3.50 49.70.
## grep read_bytes /proc/fs/lustre/obdfilter/rshare-OST0027/exports/*/stats | sort k7 -n.
.
/proc/fs/lustre/obdfilter/rshare-OST0015/exports/172.28.4.29@o2ib/stats:read_bytes
5142 samples [bytes] 4096 4194304 21485920256/proc/fs/lustre/obdfilter/rshare-OST0015/exports/172.28.5.132@o2ib/stats:read_bytes
5278 samples [bytes] 4194304 4194304 22137536512

ターミナル ー ssh# qstat –f –u ‘*’ –q ‘*@rc010’ –srqueuenameqtype resv/used/tot. np_load archstates--------------------------------------------------------------------------------mjobs.q@rc010i
BP 0/128/128 0.93 lx-amd6483183224 0.00000 sv_filt_20 user1 r 11/10/2023 08:57:33 683183225 0.00000 sv_filt_20 user1 r 11/10/2023 08:57:33 683183229 0.00000 sv_filt_20 user1 r 11/10/2023 09:27:27 683183230 0.00000 sv_filt_20 user1 r 11/10/2023 09:27:28 683158973 0.00000 Delly_rege user2
r 11/10/2023 10:46:03 1 49883161884 0.00000 Delly_rege user2
r 11/10/2023 11:35:43 1 480.
.
# qmod –sj 83161884# qhold 83161884# qmod –rj 83161884
#

11

問題点①
ü対策
ØLustre の QoS 機能を使⽤し、ユーザまたはグループ単位で I/O 制限する
• QoS で制限してしまうと常に全ユーザで制限がかかってしまうので適応しない⽅針としたØLustre Monitaring 機能を使⽤し、ジョブスケジューラと連携したユーザ・ジョブ
情報から原因となっているユーザを特定し、⾃動対応するスクリプトを作成する• MDS/OSS が過負荷になった場合に⾃動で以下を実施し、ユーザにアナウンス• 特定ユーザを特定し、ジョブをサスペンド• 2 回⽬は、実⾏待ちに戻し、ジョブをホールド• 3 回⽬は、ジョブを削除

ü効果ØLustre 過負荷の頻度が削減
Øアナウンスを実施することで過負荷を与えていたジョブ数が削減• ユーザへの教育ができた

対策前

全ゲノム解析等実⾏計画
üがんの全ゲノム解析等は、⼀⼈ひとりにおける治療精度を格段に向上させ、治療法のない患者に新たな治療を提供するといったがん医療の発展や個別化
医療 の推進など、がんの克服を⽬指したがん患者のより良い医療の推進のために実施する。
全ゲノム解析等により、がん医療への活⽤、⽇本⼈のがん全ゲノムデー タ
ベースの構築、がんの本態解明、創薬等の産業利⽤を進めていく。

12

全ゲノム解析等実⾏計画

2023年7⽉26⽇ 第16回 専⾨委員会 資料1 （全ゲノム解析等に係る検討状況等について）スライド4より

13

14

全ゲノム解析等実⾏計画
 全ゲノムプロジェクト症例内訳とR4年度実施内容
公募の種類

A班：患者還元班（体制構築班）

B班
患者還元班（領域別班）

がん種

令和3年度
500症例
（内新規の患者200症例）
500症例（内新規の患者200症例）
500症例（内新規の患者200症例）

難治がん等

国立がん研
究センター

角南久仁子

難治がん等

静岡がんセンター

浦上研一

難治がん等

がん研有明
病院

上野貴之

消化器がん

東京大学

柴田龍弘

1,400症例

血液がん

京都大学

南谷泰仁

1,400症例

小児がん

東京大学

加藤元博

1,400症例

希少がん

東京大学

松田浩一

1,400症例森誠一

1,400症例河野隆志

1,400症例

井元清哉

A班、B班併せて、9,900症例の解析

婦人科がん
呼吸器がん
他
C班：解析班

代表機関・代表者

がん研有明病院
国立がん研究センター
東京大学医科学研究所(参考：専門委員会（3/2）資料1-1, p6)
令和4年度体制・実施内容

代表：国立がん研究センター
分担：国立がん研究センター東病院
分担：成育医療研究センター

600症例
＋α

代表：静岡がんセンター
分担：近畿大学病院

600症例
＋α

代表：がん研有明病院
分担：慶應義塾病院
分担：大阪大学病院

600症例
＋α

600症例の内訳は、新規の患者400症例と、分担医療機関の新規の患者200症例。
また、進捗状況に応じて、＋αとして、合わせて最大200症例を追加解析予定。

計 9,900
症例

臨床情報の登録を行うとともに、蓄積された全ゲノムデータを用いた研究を行う。
また、A班とも連携しB班全体としての成果をまとめる。

臨床情報を収集するとともに、統一パイプラインによる解析及びレポート作成を行う。また、集中管理システムの構築、全ゲノム解析結果に基づいた臨床応用のための出口戦略の構築を行う。

 各班は連携し、臨床情報等の収集及び高度な横断的解析等を行う。
 各班は、実施状況について「全ゲノム解析等の推進に関する専門委員会」に報告し、当該委員会の方針に沿って解析等を行う。
2022年7⽉7⽇ 第10回 専⾨委員会 資料2−1（AMED提出資料）スライド２より

2

15

全ゲノム解析等実⾏計画
 全ゲノムプロジェクト症例内訳とR4年度実施内容
公募の種類

がん種
難治がん等

A班：
患者還元班
（体制構築班）

B班
患者還元班（領域別班）

国立がん研究センター

角南久仁子

令和3年度
500症例
（内新規の患者200症例）
500症例（内新規の患者200症例）
500症例（内新規の患者200症例）

令和4年度体制・実施内容
代表：国立がん研究センター
分担：国立がん研究センター東病院
分担：成育医療研究センター

600症例
＋α

600症例の内訳は、新規の患者400症例と、分担医療9,900 症例の解析を 8代表：静岡がんセンター
ヶ⽉程度で実施。
600症例 機関の新規の患者200症例。
静岡がんセ
難治がん等
浦上研一
分担：近畿大学病院＋α
ンター
また、進捗状況に応じて、解析領域として DDN Lustre
ファイルシステムを＋αとして、合わせて最大
代表：がん研有明病院
がん研有明
600症例 200症例を追加解析予定。
難治がん等
上野貴之
分担：慶應義塾病院
利⽤しており、解析完了するのに⼤いに役⽴った病院＋α
分担：大阪大学病院
計 9,900
消化器がん 東京大学
柴田龍弘
1,400症例(2023/11時点では12,500 症例以上)
症例
血液がん
京都大学
南谷泰仁
11,400症例
症例あたり 800 GB 以上
小児がん

東京大学
加藤元博1,400症例
WGS (Fastqファイル)：400
GB (Normal 臨床情報の登録を行うとともに、蓄積された全ゲノムデータを用いた研究を行う。
(x30)：80 GB, Tumor (x120)：320 GB
また、A班とも連携しB班全体としての成果をまとめる。
希少がん
東京大学 解析結果
松田浩一
1,400症例(BAMファイル、VCF ファイルなど)：400 GB
婦人科がん
呼吸器がん
他

C班：解析班

代表機関・代表者(参考：専門委員会（3/2）資料1-1, p6)

がん研有明病院
国立がん研究センター
東京大学医科学研究所

森誠一

1,400症例河野隆志

1,400症例

井元清哉

A班、B班併せて、9,900症例の解析

臨床情報を収集するとともに、統一パイプラインによる解析及びレポート作成を行う。また、集中管理システムの構築、全ゲノム解析結果に基づいた臨床応用のための出口戦略の構築を行う。

 各班は連携し、臨床情報等の収集及び高度な横断的解析等を行う。
 各班は、実施状況について「全ゲノム解析等の推進に関する専門委員会」に報告し、当該委員会の方針に沿って解析等を行う。
2022年7⽉7⽇ 第10回 専⾨委員会 資料2−1（AMED提出資料）スライド２より

2

全ゲノム解析⽤システム
1次解析⽤システム (令和3年度に稼働)

SHIROKANEGPU 搭載サーバ

1次解析用ストレージシステム

1次解析用サーバx4x2-DDN EXAScaler 9.3 PB(Bandwidth: Read 42 GB/s, Write 38 GB/s)
ES400NVX x2, SS9012 x8 for MDS/MDT, OSS/OST- SSD (for MDT): 1.92 TB x11- HDD (for OST): 18 TB x712
- HDD (for LORIS): 18 TB x4-

NVIDIA DGX A100 x4
CPU: AMD EPYC 7742 (2.25 GHz, 64 core) x2
Mem: 1.0 TB (64 GB x16)
SSD (OS): 1.92 TB (NVMe SSD 1.92 TB x2[RAID1])- SSD (work): NVMe SSD 3.84 TB x4 [RAID0]-DDN EXAScaler 7.3 PB(Bandwidth: Read 45 GB/s, Write 45 GB/s)
ES400NVX2 x2, SS9024 x8 for MDS/MDT, OSS/OST- SSD (for MDT): 1.92 TB x11- HDD (for OST): 22 TB x422
- HDD (for LORIS): 22 TB x8

2次解析⽤システム (現在構築中)-x4x2

HPE Superdome Flex 280 x9 (1,728 Core)CPU: Intel Xeon 8360H (3.0 GHz, 24 core) x2
Mem: 1.5 TB (32 GB x48) (8 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.6 TB x2

2次解析用サーバ-HPE ProLiant DL385 Gen11 x14 (1,792 Core)CPU: AMD EPYC 9554 (3.1 GHz, 64 core) x2
Mem: 1.5 TB (64 GB x24) (12 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.92 TB x2
-x4x2

-

-

2次解析用ストレージシステム-

16

マスタージョブ用サーバ-

HPE ProLiant DL385 Gen11 x14 (1,792 Core)CPU: AMD EPYC 9554 (3.1 GHz, 64 core) x2
Mem: 384 GB (32 GB x12) (3 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.92 TB x2-

解析⽤途として、SHIROKANE の計算機リソース(⼀部) を利⽤

全ゲノム解析⽤システム
1次解析⽤システム (令和3年度に稼働)

SHIROKANEGPU 搭載サーバ

1次解析用ストレージシステム

1次解析用サーバx4x2-

DDN EXAScaler 9.3 PB(Bandwidth: Read 42 GB/s, Write 38 GB/s)
ES400NVX x2, SS9012 x8 for MDS/MDT, OSS/OST- SSD (for MDT): 1.92 TB x11- HDD (for OST): 18 TB x712
- HDD (for LORIS): 18 TB x4-

NVIDIA DGX A100 x4
CPU: AMD EPYC 7742 (2.25 GHz, 64 core) x2
Mem: 1.0 TB (64 GB x16)
SSD (OS): 1.92 TB (NVMe SSD 1.92 TB x2[RAID1])- SSD (work): NVMe SSD 3.84 TB x4 [RAID0]-x4x2

HPE Superdome Flex 280 x9 (1,728 Core)CPU: Intel Xeon 8360H (3.0 GHz, 24 core) x2
Mem: 1.5 TB (32 GB x48) (8 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.6 TB x2

2次解析用サーバ

マスタージョブ用サーバ

9,900 症例の解析は、初期導⼊の1 次解析⽤ストレージで実施した-DDN EXAScaler 7.3 PB(Bandwidth: Read 45 GB/s, Write 45 GB/s)
ES400NVX2 x2, SS9024 x8 for MDS/MDT, OSS/OST- SSD (for MDT): 1.92 TB x11- HDD (for OST): 22 TB x422
- HDD (for LORIS): 22 TB x8

2次解析⽤システム (現在構築中)-

HPE ProLiant DL385 Gen11 x14 (1,792 Core)CPU: AMD EPYC 9554 (3.1 GHz, 64 core) x2
Mem: 1.5 TB (64 GB x24) (12 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.92 TB x2
-x4x2

-

-

2次解析用ストレージシステム-17-

HPE ProLiant DL385 Gen11 x14 (1,792 Core)CPU: AMD EPYC 9554 (3.1 GHz, 64 core) x2
Mem: 384 GB (32 GB x12) (3 GB/core)
SSD (OS): 480 GB (SSD SATA 480 GB x2[RAID1])- SSD (work): NVMe SSD 1.92 TB x2-

解析⽤途として、
SHIROKANE の計算機リソース(⼀部) を利⽤

18

解析⽤統⼀パイプライン
QC

QC
SNV/Indel

CNV
Annotation

SV

CNV

SV

MSI

QC

解析⽤統⼀パイプライン

同時に実⾏する各ソフトウェアで同⼀のインプットファイル (bam)を読み込みんでいる
問題点②

19

実⾏タイムライン

20

実⾏タイムライン
同⼀ファイルをインプットしたジョブが同時に実⾏される
問題点②

21

ストレージの使い⽅
High Speed

Tier1(NVMe SSD)

・・・統⼀パイプラインの⼀部ソフトウェアのスクラッチ領域として使⽤

Write/Read
Performance

Tier2(Lustre Filesystem)

Tier3(Tape)

・・・統⼀パイプラインの全ソフトウェアのインプット/アウトプット領域として使⽤スクラッチ領域を指定可能なソフトウェアは少なく、解析に重要な領域・・・解析が終了した検体置き場として使⽤

22

⾰新がんのデータ量推移
2回⽬増強(2 PB)
1回⽬増強(1 PB)

23

⾰新がんのデータ量推移
2回⽬増強(2 PB)
1回⽬増強(1 PB)

常に 95%以上の使⽤率の中でやりくりしながら解析を実⾏していた
問題点③24

⾰新がん MDS/OSS の負荷状況
SHIROKANE とは異なり、ジョブ数などを運⽤者側でコントロールできるため、各 MDS/OSS が過負荷となりサービス影響が出ない範囲で運⽤している

25

Lustre のメタデータアクセス
解析に使⽤する 1 ファイルのサイズが⼤きく、SHIROKANE の Lustre に⽐べてメタデータアクセスは少ない傾向にある

26

Lustre のアクセスバンド幅
理論性能が Read 42 GB/s, Write 38 GB/s に対して、常に性能をフルで使⽤し解析を実⾏してきた→ 1 ファイルあたりの容量が 30 GB 以上のファイルが多くLustre として性能を出しやすい解析であった

27

28

問題点②
ü状況

Ø統⼀パイプラインではアライメント後の処理 (変異コール) は、同じ bam ファイルをインプットとして実⾏するØストライプカウントは「1」としている

ü問題点
Ø同⼀の bam ファイルを複数のジョブで読み込むことで、実データが格納された
OST への I/O が増え、OST をマウントしている OSS で過負荷を引き起こす
job
job
job
job
job
job
job
job

bamOSTOSTOSS (VM)

job
job
job
job
job
job
job
job
job
job
job
job

問題点②
ü対策案
Øbam ファイルのストライプカウントを複数の OST でストライプするか検討中• ストライプカウントをいくつにするか未検討。Lustre コミュニティとしてアイデアがあれば教えてほしいØEXA6 の新機能である Hot Nodes が使えないか検討中• クライアント側でキャッシュを持つことでデータを再利⽤できることで OSS 負荷の軽減、統⼀パイプラインのスループット向上を期待• ジョブスケジューラに Altair Grid Engine を使⽤しているが、キャッシュを持っているクライアントに対象ジョブを Dispatch する
⽅法を検討中。
Lustre コミュニティとしてアイデアがあれば教えてほしい29

苦労話 (問題点③)30üHDD 1 回⽬増強時の状況
Øバランスよく OST を増設できず、OSS の OST マウント数に偏りが出てしまった
Ø既設の OST の使⽤率は 95% 以上とかなりひっ迫していた

ü問題点
ØLustre の以下のデフォルト仕様により、増設した OST にのみ新規の I/O が偏り、対象 OST をマウントしている OSS が⾼負荷となり I/O エラーが多発し、解析スループットが 40% 程度に低下した• 100 - (最も使⽤量の少ない OST/最も使⽤量の多い OST) * 100 が 17% 以上であれば
使⽤量の少ない OST にファイルを書き込む
OST

OST

OST

OST

OSS (VM)OSTOSTOSS (VM)

OST

OST

OST

OSS (VM)
OST

OST

OST
OSS (VM)

OST

OST

OST

OSS (VM)
OST

OST

OST
OSS (VM)OSTOSTOSS (VM)
OST

OST

OST
OSS (VM)

OST

苦労話 (問題点③)
ü対策
Ø使⽤率の⾼い OST から使⽤率の低い OST へ実データを移動• lfs migrate コマンドで Read 予定のないデータを選択し移動

Ø既設 OST に書き込まれた解析済みの検体データ (400 GB) を徐々に削除

OST

OST

OST

OST

OSS (VM)OSTOSTOSS (VM)

OST

OST

OST

OSS (VM)
OST

OST

OST
OSS (VM)OSTOSTOSTOSS (VM)
OST

OST

OST
OSS (VM)OSTOSTOSS (VM)
OST

OST

OST

OST

OSS (VM)ü教訓ØOST の使⽤率が⾼い状況で HDD 増強する場合は、増設する新規 OST の数はOSS で均等になるように設計してから実施しないと運⽤上苦しくなる• 予算の関係上から難しい場合もあるが極⼒意識する必要がある

31

Luster コミュニティへのお願い32

üアクセスするケースごとにストライプカウントの推奨値があれば教えてほしいülfs find コマンドを OS 標準の find コマンドと同等のオプションが使えるともう少し便利になりそう謝辞ü株式会社⽇⽴製作所のØシロカネエキスパート（SE）の皆様Ø⾰新がん解析チームの皆様樫村 洋平 様→会場にいます⼩寺 晋平 様関 隆博 様⾨間 則和 様⿊⽥ 哲 様加藤 誉運 様三吉 直紀 様⾼⽊ 公介 様⼤久保 哲 様飯沼 和也 様川⽥ 直⽃ 様⾼岡 春佳 様⼤平 勇⼈ 様⽵内 祐哉 様喜多⾒ 将 様⼩宮⼭ 萌 様⼩松 清隆 様引⽥ 真陽 様孕⽯ 裕昭 様33