meta-something

論文とか研究とか趣味のネタとか

SIGBIO54: 生命情報解析分野におけるコンテナ型仮想化技術の動向と性能検証(口頭発表)

2018年6月に沖縄科学技術大学院大学(OIST)で開催された第54回バイオ情報学研究会(SIGBIO)の研究会にて口頭発表を行いました。

第54回バイオ情報学研究会(SIGBIO 54)

今回は(も?)以下の研究会との合同開催です。

  • 数理モデル化と問題解決研究会(MPS)
    • MPS: Mathematical Modeling and Problem Solving
  • 情報論学的学習理論と機械学習研究会(IBISML)
    • IBISML: Information-Based Induction Sciences and Machine Learning

概要

ソフトウェアの依存環境をシステムから隔離し,軽量かつ高速に動作するコンテナ型仮想化が生命情報解析の応用研究において普及しはじめている.本報告では,特にHPC分野と生命情報学分野で利用されるコンテナ型仮想化の例としてDocker, Shifter, Singularityを対象に最新動向の紹介し、実際のタンパク質間相互作用予測ソフトウェア(MEGADOCK)における実行性能の検証を行う.

発表資料

  • 青山健人, 大上雅史, 秋山泰, "生命情報解析分野におけるコンテナ型仮想化技術の動向と性能検証", 情報処理学会研究報告 バイオ情報学(BIO), 2018-BIO-54(47), 1-7.

  • Kento Aoyama, Masahito Ohue, Yutaka Akiyama, "Survey and Performance Comparison of Container Technologies in Bioinformatics Field, IPSJ SIG Technical Report, 2017-BIO-54(47), pp.1–7. 2018.

内容について

生命情報科学のような計算科学に関連する分野では雑誌に掲載される研究内容の再現性、ひいてはアプリケーションの再現性の重要性が増してきており、近年ではNatureやNature Biotechnologyなどの著名なジャーナルでも再現性向上の手法や要素技術に関する論文が掲載されるなど、ますます注目を集めています。

情報分野で言うと、よく言われる 「論文に掲載されている機械学習の結果(精度)が再現できない」 問題ですね。 特に現実データを解析した結果が重要な研究内容の場合、依存するライブラリなどソフトウェア環境によって計算結果に影響が出てしまうことが研究再現性において重大な問題となる場合もあります。

こうした背景から、近年ではクラウド仮想マシンやコンテナなどによるソフトウェア環境の仮想化技術、継続インテグレーション(CI)などのソフトウェアの品質を維持する手法を取り入れる思想が研究分野でも普及しはじめており、情報生命科学分野にも波及してきています。

本報告では、情報生命科学分野で研究再現性などの向上を狙ってコンテナ仮想化を利用した事例について複数紹介を行い、おまけとして前半で取り上げた中にある複数のコンテナ仮想環境上でアプリケーションの実行性能計測を行った結果について発表しました。

取り上げたコンテナ仮想化の利用事例は以下のとおりです。

1. 理研バイオインフォマティクス研究開発ユニット(BiT)の研究再現性向上の取り組み

現場の解析チームと計算環境の運用チームが手を組む、(Sci)DevOpsの例として理研の二階堂研を紹介しました。 二階堂研では、データ解析チームが使うツール群をDockerコンテナ化して利用しつつ、それらを毎日実行されるCIのジョブで検証し続けることで、計算機環境に縛られず再現可能な研究ワークフローを構築する取り組みを行っています。

最近では、自然科学研究を現代的な計算機運用による効率化を目的とするHPC OPS研究会を開催しており、資料等も多くが一般公開されているので、興味がある方にはとてもおすすめです(参加費無料)。

2. 東京大学医科学研究所ヒトゲノム解析センターのHPC基盤へのSingularity導入

東大のヒトゲノム解析センターにあるスーパーコンピュータに、Dockerと互換性のあるイメージが利用できる(DockerHubからPullできる)HPC向けコンテナ環境 Singularity が提供されたよ、という紹介もしました。また、ジョブスケジューラと合わせたときのワークフローとして、UGE+ (Docker / Singularity) のケースを簡単に紹介しました。

Singularity 利用開始のお知らせ | ニュース | ヒトゲノム解析センター

3. オミックス解析パイプラインNextflowのコンテナ仮想化利用

小規模なツールはコンテナに全部まとめて管理することも多いですが、多数のツールで構成されるパイプラインの場合は一部が更新される度に全体を構成し直すのは非効率的になる場合があります。最近では、それぞれのツール環境を個別のコンテナ環境で構築して、パイプラインは全体のワークフローと個別のバージョン(タグ)を管理する、という形態も増えつつあります。

今回は後者の例としてDSLを使ったオミックス解析パイプライン Nextflow を紹介しました(この分野だとGalaxyが有名ですね)

Nextflow - A DSL for parallel and scalable computational pipelines

Galaxy Community Hub

4. タンパク質相互作用予測ソフトウェアMEGADOCKにおけるコンテナ仮想化の取り組み

我々のラボ(東工大秋山研)で開発されたツールです。GitHub上でGPLv3で公開しており、過去に発表したMicrosoft Azure上の仮想マシンを利用した並列分散やDocker Swarmによるコンテナ並列分散計算を例として簡単に紹介しました。

いずれの事例においても、ソフトウェアの依存環境の隔離や解析ツールの共通化と言った「アプリケーションレベルの仮想化による恩恵」が研究者の作業レベルでも良好に受け止められていると言えます。いくつか取り上げたHPC基盤側が採用しはじめる動きもあって、今後も順当に普及が進んでいきそうです。

一方で、今回の報告では、Dockerが特に利点を持つ独立したサービスを提供するホストとしての振る舞い、コンテナのオーケストレーションを利用したより高度な管理やデプロイに関する機能にはあまり触れませんでした。現状HPC基盤においては運用上の事情から、ソフトウェア環境のパッケージング技術としてのみコンテナが利用されているケースが多いためです(UGE + Docker, Singularityなど)。クラウドの文脈に近いクラスタ管理としてOpenStack, Apache Mesos, Kubernetesなどを採用するケース(PFNのMN-1など)もあるのですが、HPCの文脈ではまだ主流ではない現状、と認識しています。


後半では、我々の研究室で開発されたタンパク質相互作用予測ソフトウェアMEGADOCKにおけるコンテナ仮想化の利用あるいは商用クラウド上の並列分散処理の報告の紹介をしつつ、複数のコンテナ仮想環境(Docker, Singularity, Shifter)上におけるアプリケーションの実行性能計測を行いました。

…しかしながら、今回は計測自体が小規模な(単一ノード上の)実行であり、また詳細な性能解析が行えていないため、内容は単純な実行時間比較のみとなりました。 (しかもコンテナ仮想環境で計測した方がベアメタル環境よりもほんの少し速かった。。実行プロファイルを眺めながら考察していましたが、まだ明確な原因はわかっていません。)

おまけ

余談ですが、現時点で個人的に抱いているコンテナ仮想環境の性能への期待としては以下のような感覚です。

指標 性能への期待
単純な計算ワークロード Shifter >= Singularity(1) >= Docker
通信律速のワークロード Shifter = Singularity >= Docker(2)
File I/O律速のワークロード Shifter = Singularity >= Docker(3)
利便性やその他の機能性 Docker >>> Singularity >>> Shifter

1) Singularityは設定で namespace の有効/無効を切り替え可能
2) ネットワークのルーティング設定に依存する(ホストにバインドすれば影響小)
3) ホストのデバイスに出力すれば影響はない

(参考文献)

この辺をちゃんと解析してある論文もどこかにあるとは思うのですが、詳細なコールスタックの解析とか実装に踏み入って議論している文献はあんまり見当たらないんですよね。。

論文紹介「Is Singularity-based Container Technology Ready for Running MPI Applications on HPC Clouds?」

タイトル

"Is Singularity-based Container Technology Ready for Running MPI Applications on HPC Clouds?"

著者

  • Jie Zhang, Xiaoyi Lu, Dhabaleswar K. Panda
    • from Network-Based Computing Laboratory, The Ohio State University

Network-Based Computing Laboratory は MVAPICH, OSU Benchmark などを開発(発表)しているHPC業界では有名なラボです。

掲載雑誌、国際会議の情報等

Proceedings of the10th International Conference on Utility and Cloud Computing (UCC '17) (ACM)

本論文はUCC'17で "Best Student Paper Award" を受賞しています。

概要

HPC向けコンテナ技術Singularityの性能への影響をHPC向けのハードウェア環境上でMPIアプリケーションを実行して実験した結果、nativeからの性能低下は最大でも8%程度だった。

もうちょっと詳しく

一般にコンテナ型仮想化技術として有名なDockerとイメージの互換性があり、HPC領域向けのコンテナ技術として有望視されているSingularityを用いたHPC向けアプリケーションのベンチマーク論文。実験ではMPIによる1対1通信,集団通信,HPCアプリケーション(Graph500NASベンチマークなど)を実行しており、また一般的なIntel Haswell CPU*2+InfiniBandのクラスターと、Intel KNL+Intel Omni Path搭載のクラスター環境で動かしている。多くの場合にSingularityを利用したケースはnativeとほぼ同等の性能を示していたが、一部では0~8%程度の性能低減が見られた。

個人的な感想

論文では様々なハードウェアアーキテクチャ(KNLの特殊なメモリ構成、大量のメニーコア)、高速なインターコネクト、仮想化技術の有無で実験を評価したと述べているが、Singularityが内部的に利用する仮想化技術がどのように他の要素に影響を及ぼすのか、に対する考察がない。また、0-8%程度の性能低減が過去文献と比較してリーズナブルであるか否かについても議論がない。そこを最も知りたかった、、

singularity.lbl.gov

Singularity公式ページのUser Guideによれば、Singularityのプロセスの流れは以下の通り。

1. Singularity application is invoked
2. Global options are parsed and activated
3. The Singularity command (subcommand) process is activated
4. Subcommand options are parsed
5. The appropriate sanity checks are made
6. Environment variables are set
7. The Singularity Execution binary is called (sexec)
8. Sexec determines if it is running privileged and calls the SUID code if necessary
9. Namespaces are created depending on configuration and process requirements
10. The Singularity image is checked, parsed, and mounted in the CLONE_NEWNS namespace
11. Bind mount points are setup so that files on the host are visible in the container
12. The namespace CLONE_FS is used to virtualize a new root file system
13. Singularity calls execvp() and Singularity process itself is replaced by the process inside the container
14. When the process inside the container exits, all namespaces collapse with that process, leaving a clean system

大雑把な流れは以下の通り(おそらく)

No. 処理
1~6 プロセス起動、サブコマンド・環境変数・オプションのパースなどの事前準備
7~10 バイナリが実行され、プロセスの名前空間を隔離する(オプションで無効化可能)
11~12 コンテナイメージのファイルシステムをホストにマウントし、プロセスから見えるルートファイルシステムを隔離する
13 コンテナの中で execvp() してコマンド実行
14 プロセスが終了すると関連プロセスおよびマウントポイント等を削除する

上の処理を見ると、性能に影響するかもしれないと考えられるのは以下の2点

後者についてはおそらく chroot() を呼んでいるだけではないか(予想)と思うが、これはファイルI/Oに特に影響を及ぼさないはず。

前者の影響がどの程度あるのかが問題になるが、プロセスの名前空間の隔離ならば以前のIBMのDocker性能評価の論文[Felter, 2015]を引用すれば、単純な計算において性能への影響は0-3%程度におさまると予想できる。IBMの論文では通信レイテンシ等のオーバーヘッドが大きいことを報告していたが、Singularityではホストに依存する通信関連の設定や依存ライブラリ・バイナリは、ホストのものをコンテナ内部にそのままマウントする形なので、事実上、仮想化による性能の影響はない(というよりも、仮想化を行っていない)はず。

論文に何も議論がなかったのでこれ以上は議論のしようがないが、今回の性能の低減は何が原因で発生しているのかを知りたい。ので、近く実験をしてみよう。

紹介スライド

www.slideshare.net

インターンの成果が欧州スパコンの本番環境で使えるようになった

前回の記事で紹介した3ヶ月のスイスのCSCS滞在中にHPC運用チームで取り組んだ成果が、無事に同機関のスーパーコンピュータPizDaintの本番環境上で利用可能になったようです。

metavariable.hatenablog.com

はじめは期間が長いと思っていたインターンも、作業を進めるうちに「3ヶ月では足りない、もっとやりたいことが…」となり帰国後もしばらくスイスに心を置いてきた感覚でしたが、無事に国際会議発表も本番環境への提供もできたという報告をチームメンバーから貰えて一安心と言ったところです。

ちなみに国際会議の発表を取り上げた記事中に発表の録画映像があるのですが、発表者のAlberto氏(チームメンバー)が冒頭で以下のように触れて頂けたことに(共著ではないものの)少し嬉しみを感じました。

"... and I would like to acknowledge the efforts of Kento AOYAMA from Tokyo Tech who made big contributions to our work during his internship at CSCS."

insidehpc.com

国際会議の発表スライド (by Alberto Madonaa)

www.slideshare.net

PizDaint上のShifterのユーザーガイド

Shifter

Advanced Shifter User Guide