meta-something

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

第2回HPC OPS研究会の参加記録

2018年7月2日に開催されたHPC OPS研究会に参加してきました。初回は見逃してしまって参加できなかったので今回が初参加なのですが、折角なので簡単なレポートを残しておきます。

HPC OPS研究会は、科学者の研究効率を最大化するためにコンテナ仮想化やクラウド環境の利用、配布ソフトウェアへのCIパイプラインの導入など、ソフトウェア開発のエンジニアリングの知見を用いて研究作業を楽にする話をしましょう!という集まりです。理研BiTの二階堂先生が中心となって、日本マイクロソフトの協賛で開催です。

第2回 HPC OPS研究会

  • 日時:2018年7月2日(月)13時30分 - 18時
  • 場所:日本マイクロソフト(品川)
  • その他:詳細は下記の開催ページに(スライドなど追加される予定です)

概要

 HPC OPS (えいちぴーしー おぷす) 研究会は、自然科学の研究成果を最大化するための科学計算環境やその構築技術についての研究会です。計算環境構築の時間やコストを低下させ、本来の研究活動に多くの時間を割けられるよう科学計算環境の開発・運用のノウハウを共有します。
 コンテナ型仮想計算やクラウドでのHigh Performance Computing、DevOps による科学計算環境の自動構築、データ解析ワークフローエンジンの実装や利用、最適なオンプレミスPCクラスタの運用構築などについて議論します。産学官などの垣根を越えて、クラウドやDevOps, HPCに関わる技術者や科学者などからの参加を広く募集します。

発表題目など

発表者 題名
二階堂愛(理化学研究所 オープニング
海津一成(理化学研究所 細胞シミュレーションソフトウェアE-Cell4の技術
白石友一(国立がん研究センター Extraction Transformation Load (ETL)アプローチに基づくがんゲノム解析パイプラインの開発
近藤宇智朗(udzura)(GMOペパボ株式会社) コンテナランタイムとアーキテクチャを新規に開発した結果、見えてきた世界について
日本マイクロソフト TBA(タイトル不明)
奥野 慎吾(エクストリーム-D株式会社) XTREME-Dが提供するクラウドHPCサービス
政谷好伸(国立情報学研究所 NIIでの計算機環境の運用及び、Literate Computing(for reproducible infrastructure)について
佐藤仁(産業技術総合研究所 AI橋渡しクラウド(ABCI)における高性能計算とAI/ビッグデータ処理の融合

発表スライドは研究会のページで順次公開されています。

興味のあった発表について

いくつかの発表は既に別の場所で聞いていました(言い換えれば界隈の有名どころで)が、全体的に自分の興味のある分野と被っていたので大変楽しかったです。 細胞シミュレーションソフトウェアの配布や開発形態をアレコレ工夫したり、既存のゲノム解析パイプラインをクラウド上で構築したり、Jupyter Notebookのプラグインを開発して、実行可能かつロギングなど様々な機能がついた形式でドキュメントを管理したり。あとおなじみのABCIでSingularityでHPCコンテナの文化を支援する話とか。

どれも内容は面白かったですが、個人的には初めて聞いたGMOペパボの@udzuraさんの発表が特に興味深かったです。@udzuraさんはDSLによる詳細なコンテナ環境の設定を可能とするOSS Haconiwaの開発者です。Haconiwaについてはちょっと前に解説記事を目にしていました。

他のお話が科学技術計算をテーマにしてコンテナのインフラ環境やソフトウェアのメンテナンス、デプロイなどについて述べていた中で、Webサービスホスティングという流れで自社のLollipop!クラウドの中でのコンテナの役割を考察されていたのと、個人的な興味に合致していたので記憶に残りました。

コンテナとアーキテクチャを開発し、見えてきた世界 / why-we-create-our-container-and-architecture - Speaker Deck

今回のトーク内容は開発したHaconiwaそのもの…ではなく、同社の提供するLollipop!クラウドで採用するFastContainerアーキテクチャの中のコンテナ(Haconiwa)の役割について。

FastContainerアーキテクチャは同社で働くまつもとりーさん(博士(工学))の提唱している概念で、ホスティングサービスで管理するコンテナの状態をリクエストに応じて動的に管理して(また再配置しやすいように資源を配置し)自動的な負荷分散を目指すものです(私の理解では)。

当日のトークでは、上述のホスティングサービスにおけるコンテナ(プロセス)の振る舞いや利用技術の特性を示しながら従来の単純なプロセスからの役割の変化を考察し、近年のコンテナの進化は『ホストから独立したより軽量な仮想化技術としての文脈クラウド的文脈)』と『システム上で動作する、より安全かつ利便性の高いプロセス技術ホスティング、またはHPC的文脈)』の両方の文脈がある、と述べていました(自己流の解釈が多分に含まれます)。

FastContainerアーキテクチャ自体も面白かったのですが、まとめを聞いた時に「そうなんだよなー。だから界隈によってコンテナの定義もブレてたり、聴衆によって求める特性が違ったりで発表が難しいんだよなー……。」という気持ちを抱きました。

これは例えば後者の文脈であげられるソフトウェア(SingularityとかBareMetalContainerとかShifter)は”仮想化”を目的としていないので、内容や運用の話をすると前者の仮想化の文脈では「これはコンテナなのか…?」みたいな反応になってしまうので、発表の導入に注意しないといけない。みたいなことを指します。

個人的には両方の文脈で興味があって、旧来は少し異なる思想を持っていた両者の文化が発展と共に同じ技術に辿り着いて、徐々に技術的に融合しつつある現状(クラウド環境をHPC的に利用するとか、逆にHPC環境をクラウドを介して提供する話とか、クラウドのソフトウェアスタックをHPC方面に提供するとか)が面白いと思っています。が、何処に話を位置付けて発表するのかはっきり意識しないと聴衆が混乱しはじめるので、気を付けないといけないですね。

が、最近はこの分野は一人で何でもかんでもやれるものではないなーと限界を感じつつあります。

ということで、HPS OPS研究会は大変楽しかったです。研究界隈のDevOps的な話を聞くだけでもエンジニアリングの興味を刺激されるので、個人的にとてもおすすめです。

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