遺伝研スパコンの『ここが困った！』事例集と今後への提言

遺伝研スパコンの
『ここが困った！』事例集と
今後への提言
@2014/7/31DDBJスパコンユーザーズミーティング
笠原雅弘
東京大学大学院
新領域創成科学研究科
情報生命科学専攻

はじめに
「『ここが困った！』事例集」と銘打ってはいますが、
ＤＤＢＪスパコンはゲノム解析向けの日本一スパコンです。
他の（ゲノム解析研究者にとって酷い）スパコンには
提言しに行く気も起きない。

従来型ＨＰＣと
ゲノム解析ＨＰＣの違い
従来型ＨＰＣゲノム解析ＨＰＣ
計算力と使いやすさ計算力が大事。計算より計算できるまでの
お膳立てが大変。使いや
すさもとても重要。
アクセラレータ当たり前に使う。
GPGPU/Phi/…
使いにくい。
ただし今後は必要に。
メモリー小〜中規模。大きく必要。
ソフトウェア互換性なくても良い応用も多い。とても必要。
通信バンド幅かなり必要。あまり要らない。
ファイルシステムバルクアクセスが多い。細かいアクセス
＋バルクアクセス
＋超大容量
資源管理主にCPU 主にメモリ/ストレージ
耐故障性チェックポイント等大事

スパコンあれこれ
スパコン名称・設置サイト不満点
遺伝研 DDBJ この中では一番よい。
東大医科学研究所 HGC 大規模メモリノードが（事実上）無い。
東工大 Tsubame2-KFC 大規模メモリノードが無い。
ストレージ容量・帯域・単価が良くない。
Amazon EC2 ネットワーク単価が高すぎてウェブサーバー以外の
大規模運用は今のところ非実用的。
東大情報基盤センター
Oakleaf
SPARCアーキテクチャであり、x86_64 が動かないた
め、あらゆるソフトの移植を自分で行う必要がある。
従って我々にはゴミ同然。
京コンピューター同上
FOCUS 産業向け。
京大・筑波大など小規模。ストレージ容量・帯域・単価が良くない。
統数研ストレージ容量・帯域が良くない。

私の使用（活用）例：
PacBio RS を用いたゲノム解読
 PacBio RS
 世界初の商用１分子リアルタイム
DNAシークエンサー
 Continuous Long Read (CLR) は
Sanger リードを大きく超える
リード長(N50 read len: 8 kb)
 塩基エラー率~15%に対処する特別
なアルゴリズムが必要に
[http://files.pacb.com/pdf/PacBio_RS_II_Brochure.pdf]
 Sprai: PacBio エラー訂正ソフト
 ゲノム 10x 以上の PacBio リード
からシークエンシングエラーを取
り除く
 エラー除去したリードを Celera
Assembler 等でアセンブリ

PacBio & Google による
ヒトゲノムの de novo アセンブリ
405,000 CPU hours! Amazon EC2 で 800万円

Sprai
・http://zombie.cb.k.u-tokyo.ac.jp/sprai より公開中
・１０以上の機関、１５以上の研究室で既に稼働している
・真核生物ゲノムのアセンブリでは HGAP より高性能
（原核だと大差ない・・・）
・ゲノムサイズ <1Gbp のレンジで N50 contig 500kb ぐらいは
ルーチンになってきた。

DDBJスパコンで困った事例１c
 Univa Grid Engine (UGE) の仕様がダメで
困っている。
 200CPU core を使う並列プログラム（実際には違
うが仮にMPIジョブとします。）をジョブに投げる。
 200CPU 空いていればすぐに実行される。
 100CPU しか空いていないと待たされる。
 待っている間に 1 CPU とか 8 CPU のジョブがどんどん
実行されていく→永遠に出番が回ってこない。
 X10, Chapel 等の先進的な並列言語の恩恵が受
けられない。

DDBJスパコンで困った事例１c
困っている。
 200CPU core を使う並列プログラム（実際には違
うが仮にMPIジョブとします。）をジョブに投げる。
 200CPU 空いていればすぐに実行される。
 100CPU しか空いていないと待たされる。
 待っている間に 1 CPU とか 8 CPU のジョブがどんどん
実行されていく→永遠に出番が回ってこない。
 X10, Chapel 等の先進的な並列言語の恩恵が受
けられない。
本当に困っている。
ギャングスケジューリングや
バックフィルなど、対方法は
既に知られている。
UGE を投げ捨てるべき。
編注： DDBJスパコン+UGE の組み合わせでも
管理者が予約コマンドを発行すれば一応ＯＫ．
一般ユーザー権限だけでできるべき、というのが趣旨。

DDBJスパコンで困った事例１d
困っている。
 常駐するデーモン類を立てることができない。
 Hadoop や Spark をはじめとする並列分散計算ミドル
ウェアは CPU 負荷がほとんどないデーモンプロセスを
要求する→ＤＤＢＪスパコンでは立てられない
 PacBio SMRT Portal は mysqld サーバーを立てる必要
があるが、ログインノードに立てると落とされる、計算
ノードに立てると時間制限がある。
 子のジョブから mysql をはじめとしたデーモンのアドレ
スを指定する場面があるが、qsub で mysqld を立てる
と子のジョブからアドレスを安全に取る手段がない。
 Lustre のロックが locallock に設定されている。

DDBJスパコンで困った事例２
 Lustre が高負荷時にエラーを吐く
 stat(2) などのファイル操作命令がたまに失敗する
 エラーを想定しているソフトウェアなどは（自分のソフト
ウェアも含めて）ほとんど無いので、エラーメッセージ
が出ないが、解析結果がおかしい、という場合が結構
ある。
 ファイルシステムの負荷で、プログラムが実行さ
れないことがある。酷いとログインすらできない。

Heterogeneous cluster
Big memory
Small memory
Small memory
Small memory
Small memory
File server
for production
pipelines
File server
for pipeline
development
File server
for home
directory
(configuration file,
program sources)
・
・
・
Web server
I/O server
Big memory
Offline HDDs
Small memory
Small memory
Gigabit Ethernet Switches
1 or 2
as many as possible
a few
1 or 2
The internet
2008年分子生物学会での笠原の講演
「Computer system design for efficient data-driven discovery using next-generation sequencers」
より。

Heterogeneous cluster
Big memory
Small memory
Small memory
Small memory
Small memory
File server
for production
pipelines
File server
for pipeline
development
File server
for home
directory
(configuration file,
program sources)
・
・
・
Web server
I/O server
Big memory
Offline HDDs
Small memory
Small memory
Gigabit Ethernet Switches
1 or 2
as many as possible
a few
1 or 2
The internet
より。
プログラムを格納し、バックアップも付く
ユーザーあたり 20GB ぐらいの quota の
小規模ファイルサーバー(/home)
パイプライン開発をする人のための
200TB 規模のファイルサーバー
(/debug)
既存のソフトウェアを流す人のための
PB級のファイルサーバー
(/data)

DDBJスパコンで困った事例３
 インストールされているソフトウェアが勝手に
バージョンアップする
 科学論文では再現性（reproducilibity）が重要
 bowtie2, TopHat, Cufflinks など、バージョンアップでア
ルゴリズムの挙動が変わるソフトウェアはバージョンを
固定したい。少なくとも論文に使ったバージョンを記載。
 バイオインフォマティクスをよく知らないＳＥは
「最新バージョン」＝「一番良いソフトウェア」
 我々
「最新バージョン」＝「検証されていなくて怖い」
＝「過去の計算もやり直し」

望ましい解決策
 Docker のような軽量コンテナベースの
仮想環境
 カーネルモジュールが必要なのと UGE と連携し
ないので、今入れると多分地獄。
 次に入れるシステムには必ず入れるべき。
 アメリカではもう２０カ所以上の研究機関で使わ
れている。BCM と DNA Nexus の例など超大規
模な実用例も既にある。
 14,000 サンプルの WES/WGS,
 仮想マシンはダメ
 理由は時間が無いので割愛。

望ましい解決策
 Docker のような軽量コンテナベースの
仮想環境
 カーネルモジュールが必要なのと UGE と連携し
ないので、今入れると多分地獄。
 次に入れるシステムには必ず入れるべき。
 アメリカではもう２０カ所以上の研究機関で使わ
れている。BCM と DNA Nexus の例など超大規
模な実用例も既にある。
 14,000 サンプルの WES/WGS,
 仮想マシンはダメ
 理由は時間が無いので割愛。
編注：他人が作ったＶＭイメージをそのまま使い、
自分では全くいじらない、という前提ならＶＭは
大変便利。ただし、開発者やアーリーアダプターは
一部だけのアップデート（セキュリティアップデート含む）
や他のコンポーネントとの組み合わせを試すので
ＶＭイメージ単位で扱うと手間と時間のロスが大きく、
イメージの中身をいじり始めると手間が減らない。
正直なところ Docker コンテナでもまだ面倒。
（しかしよりよい方法も今のところない）

LPM: Local Package Manager
 バイオインフォマティクス系の解析ソフトを
１コマンドでインストールするソフトウェア。
Linux 専用。
http://www.kasahara.ws/lpm/
メジャーなソフトやライブラリを１コマンドで
インストールできる。
例）
lpm install samtools
lpm install velvet
lpm install allpathlg
lpm install soapdenovo127
lpm install trans-abyss
lpm install bwa
編注：今は Mac もサポートされている。

LPM でできること
 プロジェクト別に異なるバージョンの同じソフト
ウェアを（ワンタッチで切り替えて）共存できる
 RNA-seq のプロジェクトでは
bowtie ver X, tophat ver Y, cufflinks ver Z
 ゲノムアセンブリでは
bowtie ver A, sprai ver B, Celera assembler ver C
 などなど

DDBJスパコンで困った事例４
 運用側のセキュリティの意識が低い。
 ユーザーが root 権限を奪取できるバグが放置。
 私が指摘した後は迅速な対応を頂きました。
 bugtraq とまでは言わないが RHEL Security
Advisory ぐらいはさすがに毎日目を通して。
翌月だったか翌々月に発生していた
事件。
(1) ユーザーのアカウント乗っ取り
(2) 正規アカウントから root 奪取
(3) やりたい放題
(4) ユーザーのデータも盗み放題

不具合ではないが要望１
 各種公共データベースのミラーが欲しい
 1000genomes や UCSC/Ensembl など、頻繁に使
われるデータベースは daily mirror があってもよ
いと思う（東大HGCではNCBIの一部DBなどでミ
ラーを提供）。
 昼間にネットワーク帯域が混雑するのを防ぐ。
 同じデータベースへの複数ユーザーからの爆撃防止。
 GenBank/DRA は実質的にミラーがあるのであま
り問題ではない（か？）
編注：その後のＤＤＢＪスタッフからの説明で、既に
意外にいろいろカバーされていることが分かった。

不具合ではないが要望２
 Web サーバーが欲しい。
 ユーザーの ~/public_html など。
編注：ゲノムブラウザーなど、データが大量で
手元にコピーする時間は無いが一部の閲覧を
高速に行いたい、というようなケースで
スパコンに Web サーバーが欲しい。
また、Jupyter （iPython Notebook）のような
インタラクティブノート上でスパコンに演算を
させて結果表示（可視化）できると
研究のスピードが大きく上がる。

ゲノム解析では
ヘテロジーニアスクラスターが必要
 大メモリーノード
 ゲノムアセンブリーなど大容量メモリーの要求に応える。
高いので必然的に台数は少なめ。
 ＣＰＵノード
 コストパフォーマンスに優れた構成でＣＰＵコア数とノード数を稼ぐ。メモリー
容量も実はそこそこ必要。
 ファイルサーバー
 大規模解析パイプラインが走っているときにファイルサーバー過負荷でログ
インすらできないのではストレスフル。
 (A) プログラムや設定ファイル用ファイルサーバー（小容量・バックアップ有）
(B) デバッグ用ファイルサーバー（中容量・バックアップ無） (C) プロダクション
用ファイルサーバー（大容量・バックアップ無）の３つに分けるのを推奨。
 使用頻度の低い保存データはオフラインＨＤＤ（電源を入れないハードディス
ク）に移して保管する。テープはトータルで高いのでたいてい得しない。
 Web サーバー
 解析結果の可視化のために Web サーバーが必須。
 その他（ログインノードなど）
2008年分子生物学会での笠原の講演を１枚スライドで要約

Visualization
 Wiki / Genome browser
より。

まとめと次期システムへの提言
 ゲノム情報解析に必要な要件が従来のＨＰＣ
と大きく異なってしまっている。
 「すでにある」ソフトウェアの組み合わせでは
ゲノム研究の需要を満たすことはできない。
 ゲノム研究のニーズにあわせて攻めの姿勢で、
従来型のＨＰＣ研究をしている人達に頼るのでは
なく、ＨＰＣハードウェア・ソフトウェアのシステムを
「これから作る」ことを目指してほしい。

懺悔
 アンケート集計結果を読みました。
 「GPUキューにGPUを使わない不埒な奴が居る」
 「fatノードに大規模メモリを使わないジョブを投げている不
埒な奴が居る」
 すみません、配慮したつもりですが一部は私です。
 (1)通常のキューにジョブをたくさん投げる
 (2)他人の Job は全部、資源要求も含めて丸見えなので、
キューに溜まっている Job を調べる。
 (3)GPUを要求する Job が溜まっていない、あるいは fat
ノードに溜まっている Job はメモリ要求量が高すぎて当分
走りそうに無いときに、qalter コマンドで投入キューを変更
し、短時間の Job を振り替えていた。
 ↑一応迷惑を掛けないようにしたつもりだが、運用上よろし
くないならやめます・・・。

まとめ（事後編集済）
 DDBJスパコンはゲノム屋にとって神
 ユーザビリティの改善点
 スケジューリング
 複数コアを使うジョブの処理が管理者頼み。
 UGEで共有ファイルシステムを使わないで欲しい→scalable でない。
 バイオインフォでメモリー使用量を事前に見積もるのは大変難しい→
チェックポインティングでなんとかしてはどうか？
 デーモンやサーバー
 Spark （を使いたいわけでは無いが）的な、デーモンを１カ所必要とす
るソフトウェアが使えない→実行時間制限の無いノードが欲しい
 可視化で Web サーバーが欲しい。安全はP制限で対処？
 仮想化
 Docker でも Xen でも、何か仮想環境が無いと辛い時代に。
 セキュリティ
 ユーザーが多ければユーザーも信用できないので Local exploit を
放置は論外。

遺伝研スパコンの『ここが困った！』事例集と今後への提言

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to 遺伝研スパコンの『ここが困った！』事例集と今後への提言

Similar to 遺伝研スパコンの『ここが困った！』事例集と今後への提言 (20)

Recently uploaded

Recently uploaded (9)

遺伝研スパコンの『ここが困った！』事例集と今後への提言